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

Mitigating user expectation mismatches with shared URL #186

Closed
melanierichards opened this issue Sep 30, 2020 · 4 comments · Fixed by #245
Closed

Mitigating user expectation mismatches with shared URL #186

melanierichards opened this issue Sep 30, 2020 · 4 comments · Fixed by #245
Assignees
Labels
privacy-needs-resolution Issue the Privacy Group has raised and looks for a response on.

Comments

@melanierichards
Copy link

melanierichards commented Sep 30, 2020

Raising this item as a result of PING's privacy review

It appears that the Web Share API could be used to share an arbitrary URL. A nefarious website could encourage a user to share some piece of content, and provide a URL that would not match the user’s expectations. For example, the user thinks they are sharing a link to the current article, but inadvertently sent their friend a link to a scam site. Not all native OS share surfaces will have UI through which the user can review what URL exactly they are sharing. We should try to provide some kind of mitigation for this type of bait-and-switch, from within the user agent's scope of control.

Some ideas:

  • The spec could require that the user agent show intermediary UI through which the user can verify the shared content, if the OS-level UI does not provide this functionality.
  • The value of the url member could be limited to same-origin URLs. That doesn't protect the user from nefarious paths at the same origin, but at least would limit scenarios where the user is sent to another origin altogether. I read that in Shared URLs can be auto-fetched by native applications without respecting same-origin policy #173 there are use cases for non-same-origin URLs (e.g. a property which uses a bespoke URL shortener), but perhaps there are clever means of supporting these use cases (pre-fetch content and observe any redirects? Maybe some kind of integration with First Party Sets?).
@melanierichards melanierichards added the privacy-needs-resolution Issue the Privacy Group has raised and looks for a response on. label Sep 30, 2020
@marcoscaceres
Copy link
Member

It's probably too limited to restrict to same origin - where even if same origin, it could be redirected after the share successfully happens (before the user has a chance to activate the link).

Presumedly, shared URL will eventually end up being navigated a web browser where "safe browsing" might catch it.

@saschanaz
Copy link
Member

Maybe worth to gather usage data for that.

@marcoscaceres
Copy link
Member

@melanierichards, I've created #245 to address this feedback.

As per the W3C Process, could you please review and let us know if you/PING approves.

Cc'ing @samuelweiler for tracking purposes.

@marcoscaceres marcoscaceres self-assigned this Jul 1, 2022
@marcoscaceres
Copy link
Member

Emailed ping to get resolution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
privacy-needs-resolution Issue the Privacy Group has raised and looks for a response on.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants