Intent to Implement: Contacts API

281 views
Skip to first unread message

Finnur Thorarinsson

unread,
Nov 13, 2018, 2:24:06 PM11/13/18
to blin...@chromium.org, Peter Beverloo

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

unread,
Nov 13, 2018, 4:28:23 PM11/13/18
to Finnur Thorarinsson, blin...@chromium.org, Peter Beverloo
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

unread,
Nov 13, 2018, 6:20:18 PM11/13/18
to blink-dev
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

unread,
Nov 14, 2018, 2:20:08 PM11/14/18
to Owen Campbell-Moore, blin...@chromium.org
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.

Joshua Bell

unread,
Nov 14, 2018, 2:23:55 PM11/14/18
to Joe Medley, owenc...@gmail.com, blin...@chromium.org

a...@google.com

unread,
Nov 18, 2018, 7:52:29 AM11/18/18
to blink-dev, pe...@chromium.org
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

unread,
Nov 18, 2018, 4:05:43 PM11/18/18
to a...@google.com, blin...@chromium.org, Peter Beverloo
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.

Jeffrey Yasskin

unread,
Nov 20, 2018, 4:47:25 PM11/20/18
to Artur Janc, blin...@chromium.org, pe...@chromium.org
"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

unread,
Nov 21, 2018, 7:22:47 AM11/21/18
to jyas...@chromium.org, blin...@chromium.org, pe...@chromium.org
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

unread,
Nov 21, 2018, 9:42:42 AM11/21/18
to Artur Janc, Jeffrey Yasskin, blin...@chromium.org, Peter Beverloo
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.

Daniel Vogelheim

unread,
Nov 23, 2018, 8:05:12 AM11/23/18
to fin...@google.com, blin...@chromium.org, pe...@chromium.org
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.

Christian Dullweber

unread,
Nov 23, 2018, 8:29:54 AM11/23/18
to Daniel Vogelheim, Finnur Thorarinsson, blin...@chromium.org, pe...@chromium.org
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.
Reply all
Reply to author
Forward
0 new messages