This public vulnerability report by Pawel Wylecial proposes (with proof of concept) the following attack using Web Share:

1. A malicious website shares a payload containing a url field whose URL would be inaccessible to the website, e.g. a file URL. For example: navigator.share({url: 'file:///etc/passwd'}).
2. The user chooses a native application, such as iOS's Mail.app, as the share target.
3. The target application automatically fetches the contents of the URL (in this example, fetching the contents of the user's password database) and attaches it to the email.
4. The user sends the email, sending the contents of their private file inadvertently, to a recipient controlled by the user.

A couple of things to note:

• This isn't specifically a vulnerability in the browser (despite the above report calling it a Safari issue). The browser is just sending a well-known URL, which is effectively the same thing as sending plain text. (The URL itself is not a secret, but it points to a file whose contents is.)
• The vulnerability is due to apparent misbehaviour of the native app, which is not subject to same-origin policy and is therefore able to fetch any URL it wants, including local files. Native apps should not trust incoming intents (which could be coming from any app), but from the browser side, we have no control over the behaviour of native apps.
• This isn't very severe, as it doesn't allow the website access to the contents of the file, unless they are also able to convince the user to email it to them, by manually typing in the malicious website's email address.
• This isn't just a problem with file URLs. It affects any "private" URL, such as URLs located on the user's private network (e.g., router configs), and public URLs that may divulge private information if accessed with the appropriate cookies (e.g., what if the native app had cookies to a website the user stores data on, and was able to access a REST endpoint divulging user data).

Things I don't understand:

• The blog says this affects both Mail.app and Gmail on iOS. I don't understand if both Mail.app and Gmail are both doing the same behaviour and fetching the contents of the URL and setting it as an attachment, or if this is actually Safari fetching the contents of the URL and attaching it to the system intent that it sends to any application. (I am assuming it's the former, since I don't see why Safari would do the latter.)

Proposed solutions:

A. Do nothing (adding a security and privacy consideration to the spec), taking the approach that native apps should not trust incoming URLs.
B. Do nothing at the spec level, but individual implementations can filter out URLs unilaterally.
C. Add a requirement that the implementation filters out file URLs.
D. Add a requirement that the implementation filters out all URLs that are not same-origin as the sending site.

I think C is "theatre", it isn't going to solve the whole problem, just cover up an obvious example.

I think D is the only proper way to prevent this, but would that limit the utility of the API too severely? (It is highly likely that sites are mostly using this to share same-origin URLs, but we don't have data on this.)