You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?).
The text was updated successfully, but these errors were encountered:
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.
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: