Consider Web Intents

[darobin]

Have you considered previous proposals to address this use case, notably using Web Intents (as proposed by the Chrome team)?

Having the ability to select contacts from the OS is one thing, but being able with the same method to also select contacts Web-based providers would be a huge plus in social network portability. Established as a standard, it would actually play very well with GDPR portability requirements.

[rayankans]

Considering the privacy concerns around this API, I think everything should go through the OS. The spec does not specify the source of the contacts, so the OS could potentially allow users to choose the source of the contacts (including web-based providers). This also has the added benefit of keeping the API concise and easy-to-use.

[aarongustafson]

100% agree with @rayankans that the OS should be the proxy here… always.

It’s unclear to me if @darobin’s suggestion is that other web apps could register themselves as contact providers, I think that’s another thing (and probably a separate spec). Even in that scenario, the app should provide the data to the OS and then the OS can handle the handoff to another app. Along that line, we might even want to look at where there might be overlap with Share Target when it comes to the VCARD format. But, again, I think those use cases probably make more sense in isolated specs.

[darobin]

It's unclear to me why you would trust your OS over your browser. For instance, if you trust Android more than Firefox you're missing a big part of the privacy threat model.

You're working in an area that has been the subject of a lot of prior work. After a lot of smart people tried a lot of option, Web Intents looked like the best solution. All I'm saying is that you'll save yourselves a lot of work by learning about the past. See https://github.com/PaulKinlan/webintents for a start (ping @PaulKinlan!)

[rayankans]

@darobin it's not about trust as much as it is about having a proxy. As @aarongustafson mentioned, the OS is acting as a proxy, and that will make it very clear which contacts a user will be sharing. With web intents, as things currently stand, the web-based provider might expose all of the user's contacts to the developer, without making that explicit or asking for consent. That's really something we should avoid for privacy reasons.

[npdoty]

I think the intent (so to speak) with Web Intents is that you would be directed to the provider (in a sheet or otherwise handled by the browser) where you already have your contacts, and use their interface to select the contacts (and specific contact details) that you want to share, and then the browser would fulfill the promise/callback in the JavaScript API and return just those contacts (not all your contacts!). That seems very similar to the contact picker approach here, but the browser would help bridge the gap for users of Web-based contacts system. Contacts providers could register themselves declaratively, but it's also pretty similar to registerProtocolHandler. I don't see the special interest in the OS being the proxy rather than the browser, but willingness to implement seems especially important.

If browser implementers are willing to move forward with Web Intents or a specific sub-version just for Contacts, having support for Web-based providers would seem like a big advantage. If they aren't, then maybe the existing specs (i.e. https://www.w3.org/TR/2012/WD-contacts-api-20120712/) can just be useful sources in terms of data types/vocabularies.

[aarongustafson]

having support for Web-based providers would seem like a big advantage

I agree that supporting web-based contacts services is a good idea and I’d also support PWAs being able to advertise themselves as providers as well as consumers of contact info.

[marcoscaceres]

Closing as there is no action here.