-
Notifications
You must be signed in to change notification settings - Fork 65
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
Comments
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. |
Maybe worth to gather usage data for that. |
@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. |
Emailed ping to get resolution. |
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:
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?).The text was updated successfully, but these errors were encountered: