Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Contact API #337

Closed
3 of 5 tasks
beverloo opened this issue Jan 23, 2019 · 26 comments
Closed
3 of 5 tasks

Contact API #337

beverloo opened this issue Jan 23, 2019 · 26 comments
Assignees
Labels
Progress: propose closing we think it should be closed but are waiting on some feedback or consensus Provenance: Fugu Review type: CG early review An early review of general direction from a Community Group Topic: powerful APIs APIs that reach into your life. Venue: WICG

Comments

@beverloo
Copy link

beverloo commented Jan 23, 2019

こんにちはTAG!

I'm requesting a TAG review of:

Further details (optional):

We'd prefer the TAG provide feedback as (please select one):

  • open issues in our Github repo for each point of feedback
  • open a single issue in our Github repo for the entire review
  • leave review feedback as a comment in this issue and @-notify [github usernames]
@kenchris kenchris self-assigned this Jan 23, 2019
@torgo torgo self-assigned this Feb 5, 2019
@travisleithead travisleithead self-assigned this Feb 5, 2019
@torgo torgo added this to the 2019-02-05-f2f milestone Feb 5, 2019
@dbaron dbaron self-assigned this Feb 5, 2019
@hadleybeeman hadleybeeman self-assigned this Feb 5, 2019
@kenchris
Copy link

kenchris commented Feb 5, 2019

@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

@travisleithead
Copy link
Contributor

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: #300 (comment)

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.

@cynthia cynthia removed the extra time label Feb 5, 2019
@kenchris
Copy link

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

@torgo
Copy link
Member

torgo commented May 21, 2019

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

@torgo
Copy link
Member

torgo commented May 21, 2019

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?

@beverloo
Copy link
Author

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.

@torgo
Copy link
Member

torgo commented May 21, 2019

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?

@torgo
Copy link
Member

torgo commented May 21, 2019

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

@torgo torgo added the Review type: CG early review An early review of general direction from a Community Group label May 21, 2019
@beverloo
Copy link
Author

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

@torgo
Copy link
Member

torgo commented May 21, 2019

@hober to leave some additional feedback and questions.

@dbaron dbaron mentioned this issue Jun 18, 2019
5 tasks
@rayankans
Copy link

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.

@plinss
Copy link
Member

plinss commented Jun 24, 2019

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

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

@rayankans
Copy link

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

@torgo
Copy link
Member

torgo commented Dec 3, 2019

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:
image

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.

@plinss
Copy link
Member

plinss commented Dec 3, 2019

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.

@torgo torgo added Progress: pending external feedback The TAG is waiting on response to comments/questions asked by the TAG during the review and removed Venue: WICG labels Dec 16, 2019
@rayankans
Copy link

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.

@torgo
Copy link
Member

torgo commented Jan 27, 2020

@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?

@rayankans
Copy link

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.

@dbaron
Copy link
Member

dbaron commented Mar 3, 2020

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"?).

@rayankans
Copy link

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.

@torgo
Copy link
Member

torgo commented May 26, 2020

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?

@dbaron
Copy link
Member

dbaron commented May 26, 2020

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

  • Contact API #337 (comment) 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

@torgo torgo added Progress: propose closing we think it should be closed but are waiting on some feedback or consensus and removed Progress: in progress labels May 26, 2020
@rayankans
Copy link

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

To reply directly to @dbaron's points

  • Contact API #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!

@torgo torgo mentioned this issue May 26, 2020
1 task
@torgo
Copy link
Member

torgo commented May 26, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Progress: propose closing we think it should be closed but are waiting on some feedback or consensus Provenance: Fugu Review type: CG early review An early review of general direction from a Community Group Topic: powerful APIs APIs that reach into your life. Venue: WICG
Projects
None yet
Development

No branches or pull requests