@beverloo what is the exact use-case for limiting the API to not allow selecting multiple contacts? Even when emailing it is common to email more than one. Maybe you could clarify this in the explainer

Thanks for filing this review!

We note that this is not the first time the web has seen a proposal for a Contact picker. Sadly, the previous efforts have not gained traction for various reasons. We would love to see some background on what differentiates this proposal (e.g., how will this proposal capture implementer interest and why?)

There was a note about requiring a user activation before allowing the contact picker. We've discussed how this can be tricky for multiple implementations with different perspectives on user activation. Perhaps modelling this as a Permission could also be considered? See: https://github.com/w3ctag/design-reviews/issues/300#issuecomment-448430352

One thing that came to mind is it would be nice if the model could potentially provide a mechanism to screen (filter) out specific contact lists. (e.g. To be able to pick out contacts from your private Google contacts list, but not your corporate one.) I don't know how platforms provide this, and whether or not this is consistently feasible across different platforms but it is a use case that might be worth looking into.

Spec is available now but I am not sure whether it is published anywhere, but it can be read here:

https://rawcdn.githack.com/beverloo/contact-api/1783682958337fc4daef58a5431232245981b4c1/spec/index.html

Working on this in the TAG f2f meeting right now. Is this in WICG? If so, please provide links @beverloo ...

Other potential issue: checking the errors that are being thrown - SecurityError means an operation is insecure. It may be better to use NotAllowedError instead as the WakeLock spec. Maybe same for InvalidStateError?

This draft has not yet been adopted by WICG, but should be (soon). The spec is a WIP that's been worked on for the past ~week or so.

We remain concerned about the potential misuse of this API - especially by bad actors. There should be a stronger mitigation against misuse, specifically against invocation of this API on first load. We don't want people getting prompted to share their contacts when they first load a page (as has been the case with notifications.) The requirement for activation is a good step, but things like clicking away the 'cookie warning' dialog will count as user activation so this potentially isn't good enough to mitigate against misuse. Have you considered integrating with the permissions API such that a browser could for example reject if the application is not installed as a PWA?

@beverloo should we put this review on hold until the spec is more complete?

We remain concerned about the potential misuse of this API...

Thank you for that feedback, @torgo! We very much agree and are still finalizing our (Google's) position on what we find acceptable, but wanted to make sure we enable others to provide early feedback as well. There has been good discussion in the issues as well.

@beverloo should we put this review on hold until the spec is more complete?

I think we should see this as an early review, particularly because it's an especially powerful feature. Would that be OK?

/cc @rayankans who is doing the spec writing

@hober to leave some additional feedback and questions.

I filed a new issue a few days ago to get a spec review started. I'm wondering if I should keep using this issue, or the new one.

Let's keep using this issue. I'll close the other one.

Current spec URL: https://beverloo.github.io/contact-api/spec/

The spec URL is now: https://wicg.github.io/contact-api/spec/

Picking this up at our f2f.

Good to see that the spec is progressing and that it is moving to WICG.

The 2 use cases described in the explainer are:

1. 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.
2. An e-mail application could allow the user to select recipients for a message without needing its own address book.

We would like to see more discussion in the explainer or spec of how this specification will mitigate against social networks "gaming" user behaviour to harvest contact data (considering many social networks are notorious abusers of this capability in native apps).

We would like to see additional discussion in the explainer and / or spec about how to mitigate against abuse (as described above - e.g. not allowing use on first load).

Thanks @torgo. The spec covers these concerns in a spread out manner within the appropriate sections, so I expanded the explainer to consolidate all the mitigations against abuse.

Hi @rayankans - We're just reviewing the explainer again here at our f2f. It looks like there is still not enough detail on the potential abuse cases.

This is an example of how the permissions request for UI is being gamed by unsavoury individuals:

This sort of thing is happening because people like us didn't do enough work in the first place thinking about all the abuse cases and designing to mitigate against these abuse cases. This has led to a messy situation. While we consider adding exciting new APIs to the platform, we therefore need to be especially mindful of how these APIs can be abused.

One of the purposes of an explainer is to help implementers understand where the risks are. Another is to guide the security & privacy considerations in the spec itself (which doesn't seem to currently exist in the spec). Please explain the abuse scenarios and explain how to mitigate them, how the spec itself mitigates against them, or whether they can be mitigated.

@plinss will write some additional comments on the API design itself.

I saw the <input type=file> alternative, and I'd like to re-open that. I'm fine with this being a JS API, and agree that 'type=file' is not the right approach, but having an additional input type, e.g. <input type=contact> would allow authors to use this feature without having to use client-side script. This could be shipped in parallel with the JS API allowing authors to feature detect the input type by detecting the JS API.

The CSSWG is exploring something similar for the font picker API.

Thanks @torgo

I've expanded the Abuse section in the explainer to cover potential scenarios, explained how the spec protects against those, and what implementers should be wary of.

The spec does have a privacy section. I've added some extra UI requirements that tie in to the abuse scenarios.

@rayankans thanks for those edits – they are really helpful and I think address the concerns I had. Can you also address @plinss's question, maybe with some addtional explanation of why that path was not chosen?

There's not much to add to @plinss' comment. An <input type=contact> would be useful, and would definitely be nice to have alongside the JS API, but it has some restrictions. One which was already mentioned is that it would require an accompanying JS API for feature detection. Another is that it's more geared for sharing the user's contact info rather than any contact's info (assuming it's something like how autofill works). Also giving the user control over the shared data would be more difficult.

There was also some discussion about this in issue 20 and issue 21.

An <input type=contact> would be useful, and would definitely be nice to have alongside the JS API, but it has some restrictions. One which was already mentioned is that it would require an accompanying JS API for feature detection.

It seems like the existing JS idiom for feature-detecting a new input type is to do something like:

  function inputSupportsType(t) {
    let i = document.createElement("input");
    i.setAttribute("type", t);
    return i.type == t;
  }

While it's not great, it does seem to work.

Another is that it's more geared for sharing the user's contact info rather than any contact's info (assuming it's something like how autofill works). Also giving the user control over the shared data would be more difficult.

It seems like the same sorts of picker UI could be used for an input that would be used for the Contact Picker API. Presumably there would need to be an attribute to control what fields of information were sent or something like that, with some "reasonable" default (maybe "email"?).

It seems like the same sorts of picker UI could be used for an input that would be used for the Contact Picker API.

Yeah, I agree having an input can be useful, and there are some imperfect workarounds for the concerns I raised. However, it will still force website's UX decisions (by forcing them to use forms/inputs), which isn't always the best option, and depends on the use-case. That's why I still think that it should be something to use alongside the JS API.

Hi @rayankans @beverloo can you give us any update on this? Looks like this might have an intent to ship but the spec itself hasn't been updated since Jan? We appreciate the additional info on abuse that you've included in the explainer. Is there any intention to respond to the issues raised in this review? Is there a venue for this work beyond WICG? Is there any signal of multiple implementation at this point?

And as far as issues raised in this review, I suppose I see three major ones:

• https://github.com/w3ctag/design-reviews/issues/337#issuecomment-460555385 raising the issue of how this differs from previous contacts proposals
• risks of abuse, which seems to have led to updates to the explainer
• <input type=contact> alternative

Hi @torgo. Sorry for the miscommunication, I thought the issues raised had been resolved.

To reply directly to @dbaron's points

• #337 (comment) raising the issue of how this differs from previous contacts proposals There's an entire section in the explainer dedicated to previous attempts, some context around them, and how this proposal differs: https://github.com/WICG/contact-api#previous-standardization-attempts

• risks of abuse, which seems to have led to updates to the explainer The explainer has also been updated to cover the points brought up.

• <input type=contact> alternative Although I agree this has some benefits, and could work nicely in conjunction with the JS API, it still has some shortcomings as discussed in the thread above, and in the explainer. Considering it's more of a "nice-to-have" alternative than anything, I'm a bit hesitant to include it in the proposal unless there are signs of developer/implementer interest.

Is there a venue for this work beyond WICG? Is there any signal of multiple implementation at this point?

There are no signs of multiple implementation yet, which is why it's still in the WICG. This is something we can get more clarity on during the upcoming TPAC.

Thanks!

Ok thanks @rayankans - as noted we are broadly OK with the design. We're still concerned with the lack of additional implementations so we would encourage you to think about the <input type=contact> alternative as that might encourage additional implementers to come on board. We look forward to reviewing such a proposal.