Intent to Implement: Contacts API

[Finnur Thorarinsson]

Contact emails

fin...@chromium.org, pe...@chromium.org

Summary

We’re proposing a way for websites to indicate that they require information about the user’s contact(s) and provide a UI for the user to share those details in a way that makes it clear what is being shared with the website. This could be used for bootstrapping a friends list on a social network or (in an email/messaging application) to select message recipients.

Design doc/Spec

Explainer

We're still iterating on the details of our proposal, for which we are soliciting developer feedback. The explainer will continue to be updated throughout this process.

Motivation

There are many new users coming online for the first time in emerging markets. They’ve never used a desktop before, and instead are limited to mobile devices with very limited resources -- particularly storage. As such, the applications installed on their devices will be restricted to those absolutely necessary for continuous use.

When they sign up to a social network for the first time, it’s likely going to be done through a Web browser. In our case, through Chrome. This creates a bootstrapping problem: because websites cannot get access to their contacts, the process of adding their friends becomes a challenge.

Motivation

There are two primary use-cases that we want to address:

• Social networks could use contact information to bootstrap a user's social graph. This is particularly important for emerging markets, where users might prefer a PWA over a native app due to storage constraints.
  
  

• An e-mail application could allow the user to select the recipients for a message without needing to maintain their own address book, or asking the user to manually enter contact information.

Contact information is highly sensitive, which is why we’re pursuing a picker model rather than sharing an iterable list of contacts with the website. This means we can limit sharing information to the minimum possible amount, and design a user interface that highlights to the user what will be shared.

Interoperability and Compatibility

We're careful in designing an API that can be supported on any operating system. The data will be returned to JavaScript, where it can be converted to a preexisting contact sharing format (vCard, schema.org, etc) if desired. The primary risk, as is the case with any new API, is lack of adoption by other browser vendors, but we're actively soliciting feedback as part of this project.

Edge: No signals.

Firefox: No signals.

Safari: No signals.

Web / Framework developers: Signals positive.

Will this feature be supported on all six Blink platforms?

This is Android only, for now. Desktop support will not be considered initially, but could be included as a follow-up.

Feature dashboard entry:

https://www.chromestatus.com/feature/6511327140904960

[Tom Jones]

I have received two emails today from "friends" asking me to check out some suspect web site. This feature is complete evil. Until it is clear who is getting the contact list this "feature" should be disabled.

thx ..Tom (mobile)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB2L5-YEV%2BEk_yDjwtXQtmRJLq7OUjBC_y5X5rBFTAxY7zK9SA%40mail.gmail.com.

[owenc...@gmail.com]

Looks awesome! The picker model looks great to make this safe and easy for the user to understand what they’re sharing, and this feature is a huge deal for some apps!

One more reason not to build a native app...

[Joe Medley]

Finnur,

Do you have a tracking bug for this feature?

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

On Tue, Nov 13, 2018 at 3:20 PM <owenc...@gmail.com> wrote:

Looks awesome! The picker model looks great to make this safe and easy for the user to understand what they’re sharing, and this feature is a huge deal for some apps!

One more reason not to build a native app...

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/50b78997-a093-48c9-8518-43e30be8911d%40chromium.org.

[Joshua Bell]

Tracking bug is: https://bugs.chromium.org/p/chromium/issues/detail?id=860467

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJUhtG9ZVMNsU-xHVzvHH2OXUkXO45UmywJRh3u8bJ%2BX_Fy5Fw%40mail.gmail.com.

[a...@google.com]

The picker pattern seems like a reasonable choice for this API. In addition to requiring a user gesture, have you considered restricting this to top-level contexts? (I think it could reduce the potential for attacks from frames embedded in trusted applications.)

[Tom Jones]

I would strongly endorse the suggestion to limit this to top level domains.

thx ..Tom (mobile)

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/38c20561-ada7-4305-b638-4527176a9d63%40chromium.org.

[Jeffrey Yasskin]

A "default allowlist" of "self" (from Feature Policy) has nearly this effect, but allows access from same-origin subframes and from explicitly allowlisted cross-origin subframes. Does that sound good to you, or do you see a reason to really allow only top-level frames?

Jeffrey

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

[Artur Janc]

I like this idea, allowing same-origin frames and explicit delegation make the API more flexible while addressing the main concern about misuse via less-trusted frames.

[Ian Clelland]

Same-origin frames are almost never an effective security boundary in any case -- especially for an API like this, they can usually just execute script in their parent page's context and extract whatever data the parent has access to already.

Explicit delegation will also make it easier to share when necessary -- mutually-trusting sites won't need to build a postMessage-based bridge to get around the top-level-only restriction.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPYVjqrfwCOMtu-x0RJuMj6f6D3a7ZxeXZn%2BS__Yfo6AsMqm0g%40mail.gmail.com.

[Daniel Vogelheim]

Hi Finnur,

This feature would seem to have privacy (& possibly security) implications. Could you please sign up for privacy & security reviews, once you're ready?

Thanks.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB2L5-YEV%2BEk_yDjwtXQtmRJLq7OUjBC_y5X5rBFTAxY7zK9SA%40mail.gmail.com.

[Christian Dullweber]

Privacy review is already in progress :)

You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/brKChSa9_d0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPMk%3DqZa1K%2Bc6M2A6ctq69M-FOxS72k1gjou4hbHCLZetg%40mail.gmail.com.