Web Share API for sharing content to arbitrary destination

We’d like to discuss an API for triggering a “share” action, to send content (e.g., text, URLs, images) to a destination of the user’s choice (e.g., social networking, messaging, note taking apps). I’ve put together an explainer here:

Web Share API Explainer

Initially this would just be useful for sending content to native apps that can handle sharing (e.g., Android intents, iOS shares, Windows share contracts). I hope that eventually websites will also be able to handle sharing but I’m keeping that separate for now.

I’d like to incubate this proposal in the WICG and soon will start experimenting with this in Chrome.

Thanks
Matt Giuca
The Chrome Ballista Team

I think jointly to the JS API it would be good to also specify <button type="share">Share this</button> with title, text and url as attributes (possibly also have url default to window.location.href). It would of course be an easy polyfill to add but would add a nice bit of semantics especially considering the point is to be able to implement a share button. This would also be a good hook for accessibility purposes where screenreaders etc would easily be able to call out this specific CTA.

Also wondering if at least initially URL should be limited in scope to one of the following options:

1. HTTPS only
2. Same origin
3. Origin + pathname (still allow for querystring and hash differences)

As a user I’d expect that if I’m sharing something I’m sharing the page that I’m on, but as things stand I could be on a page with a cute cat video, share to my friends and they instead open a link to a malicious site. It’d be easier at least while experimenting to keep this more restricted and open it out as some of these issues are worked through than to pull it back once in the wild.

Consideration also needs to go into what is allowed to trigger a share action so that you can’t navigate to a page that spams shares like when pages used to spam pop-ups or alerts.

That might be nice to have. I’m not sure it’s worth tacking that on to the same proposal, though (I wouldn’t want the basic API feature to be derailed by the HTML part, especially since it is easy to polyfill). I’m new to this, but my understanding is that we should be adding low-level capabilities to the web and letting library authors provide nice abstractions on top of them (The Extensible Web Manifesto).

Yeah, I think you’re right; allowing sites to share a link to a different origin might give them too much power for not a lot of benefit. I’d be happy to just limit it to same origin for simplicity. (HTTPS doesn’t guarantee it isn’t a malicious site.)

Yeah, I imagine share would only be callable from an “allowed to show a popup” context (which seems to have recently been renamed to “triggered by user activation”).

I’m also quite new to this as well, you do make a good point about not bogging it down with the HTML part. I think it would still be good to nudge developers in that direction somewhat though. Perhaps by expanding the example code slightly to include selecting elements on type=“share” would be a good balance. This keeps the HTML proposal completely out of the spec but would encourage semantic usage.

I’m super excited about the potential for this API.

I work closely with lots of 3rd party developers and have heard many request this capability, in particular for publishers and photo sharing.

I’ve also heard requests to ensure it is possible to trigger sharing from an action button on a notification, which I suspect will just work by default but is worth bearing in mind!

Wondering I’ve I as a developer of a web app could develop sth like a receiver for the navigator.share() action, e.g.:

On some random Website https://share-some.info the Share API is called:

navigator.share({
    title: document.title,
    text: "Hello World",
    url: window.location.href
}).then(() => console.log('Successful share'))
.catch(() => console.log('Error sharing:', error));

Then the browser handles the request as described but, additionally shows web apps between the native apps installed on the users device:

Share using: Whatsapp, Save to Google Keep, ShareRecieverWA, Inbox, …

And in the Share receiver web app https://share-using-wa.new: sw.js

self.addEventListener('share', function(evt) {
    // TODO: add share logic here
});

I think this would be awesome as we currently have this new Share API and more and more sites register a service worker on their sites and this would improve the experiences for web apps.

What do you think about such a feature?

We are proposing exactly that feature for an upcoming web standard: Web Share Target. (We always planned to do this, but we separated it out into two proposals so we could focus on getting the basic sharing working first.)

We’re working on a similar pattern for “payments” as opposed to “shares” in the Web Payments WG.

It would be useful to compare notes and try to settle on a common pattern for this as originally envisioned by Web Intents.

Latest Payment Apps spec is here: https://w3c.github.io/webpayments-payment-apps-api/

Hi Adrian,

Yeah that might be good but it looks like yours is based on a dynamic registration (including sites generating new registrations for each credit card). I was hoping to do a declarative one which is why I target the web app manifest.

Can you contact me via email to discuss? mgiuca at chromium.org

Matt

I don’t know if it is possible, but a important thing is the possibility to add custom metrics in the canonical URL for some apps. i.e: utm_source=whatsapp, utm_source=messenger

What do you think?

The spec allows you to set the URL being shared so you can add any related query string parts there

I agree this is important but I’m not clear on the details. Do you mean the share sender can add metric parameters to the URL being shared, so when the user shares the URL to social media it has a parameter in it?

You can do that as chaoaretasty@ mentioned, but you won’t be able to customize it for the target app (because by design, you won’t know what the target app is). So you could set url: 'https://example.com?utm_source=webshare', but you wouldn’t be able to set utm_source=whatsapp or similar, because you won’t actually know what app it is being shared to.

Does that satisfy your question?

That’s exactly what I was trying to say.

It’s awesome to know who is coming from whatsapp or messenger. That’s the only penalty I’ve noted for this API.

Thanks

Interesting, so you basically want to customize the shared URL based on the target, so that when users share to social media then their friends click it, the incoming requests tell you which social media site it was posted to… correct?

The problem is there’s likely a privacy issue with letting the sharing site know what the target is that the user chose (we want to not leak the apps the user has installed). Can you use the Referer of the incoming requests instead of a URL parameter? Maybe doesn’t work when incoming from a mobile app?

Correct. There are no referrer. It will be the first visit. It will be count as direct access.

If we could add like this… ?utm_source=[APP_NAME] it would be great…

I think you’re suggesting that the API injects “?utm_source=[APP_NAME]” into the URL in-flight (so the sending app wouldn’t see it, but once it arrives on the receiving app side, it is visible). We could do a thing like that, but I’m worried it might still be a privacy issue because as soon as someone clicks the link the sender will see the app name. (But it’s less of a concern, because it’s separated from the user of the sending site.) Will consider this.

I’ve filed an issue on the Web Share GitHub. Please continue discussion there:

Have been playing around with this - seems to work quite well.

One thing I’m not sure if is possible (but would be interesting to me) would be to be able to specify the package name of a destination app (similar to how the setPackage() method on Intent in Android) that could be used as an override. This way, I could implement a button on a page for a specific app (e.g. Facebook) and then fall-back to a URL (e.g. the mobile website or marketplace) should that app not be available.

The only other feedback I have at this time is it would be nice if the Origin Trials were available in WebView. One of the scenarios that this particular feature would be useful for is to allow more native integration in a Cordova hosted web app without having to implement a plugin.

One thing I’m not sure if is possible (but would be interesting to me) would be to be able to specify the package name of a destination app (similar to how the setPackage() method on Intent in Android) that could be used as an override. This way, I could implement a button on a page for a specific app (e.g. Facebook) and then fall-back to a URL (e.g. the mobile website or marketplace) should that app not be available.

Interesting suggestion. You can sort of do this now using the intent: URL syntax as documented here. The problem is you can’t combine the two (open the Facebook app with a fallback to web share) because you can’t tell whether opening Facebook app failed or not.

I don’t really want to put a feature into Web Share for specifying an Android app. That would go against both the open standard (that it is a web standard, it should not include Android-specific features) and the federated nature of Web Share. Our philosophy is that the user should be able to choose where to share to, not the site doing the share. If the site were to target the Facebook app, only falling back to user choice when it doesn’t exist, that would be diverting away from user choice. It would also make for a confusing user experience (would the button be a Facebook button that sometimes shows an app picker? Or a Share button that sometimes directly opens Facebook? Neither is a very good experience.)

I’d prefer to leave this be and just tell developers to make two buttons: a facebook share button and a generic share button that triggers web share.

The only other feedback I have at this time is it would be nice if the Origin Trials were available in WebView. One of the scenarios that this particular feature would be useful for is to allow more native integration in a Cordova hosted web app without having to implement a plugin.

I think we don’t put Origin Trials in WebView because we don’t want developers to rely on it (to have it spread to other applications). This is supposed to be a public trial, not something you should be depending upon. I will raise it with the Origin Trials team to see if they have this in mind or whether it’s just an oversight.

Thanks for the feedback @nanabite! It’s super helpful to hear what people think

If you want to share with a specific package that’s probably best done with the proprietary Android Intent syntax that Paul documented on his blog: https://paul.kinlan.me/launch-app-from-web-with-fallback/. As Matt says we’d like to avoiding building Android-specific concepts into this API.

The question of Origin Trials in a WebView is interesting. I’ve started a thread in the official Origin Trials mailing list to continue the discussion: https://groups.google.com/a/chromium.org/forum/#!topic/experimentation-dev/H2mycA91IXk