Intent to Implement: Web Share Level 2

281 views
Skip to first unread message

Eric Willigers

unread,
Jan 18, 2019, 12:08:10 AM1/18/19
to blink-dev


Contact emails

{ ericwilligers, raymes, mgiuca }@chromium.org


Explainer

https://github.com/WICG/web-share/blob/master/docs/explainer.md


Spec

https://wicg.github.io/web-share/level-2/


There was a TAG review for the initial Web Share API. Level 2 is a minimal extension to support sharing of files. File sharing was also discussed in the TAG review for Web Share Target.


Summary

It is now possible to share files, using the new 'files' member of ShareData dictionary that is passed to navigator.share().

The feature detection method navigator.canShare() has been added.


Motivation

A web site might like their users to be able to share their pictures and other files through social media, email, chat, etc.


In Level 1, only text and a URL could be shared. To share files, a website would have needed to upload them to cloud storage, and then share a URL. This is beyond the capability of many sites, and doesn't give the same experience.


The immediate use case for the canShare() API involves authors detecting if sharing of files is supported by the browser. When file sharing is not supported, users can be shown a different UI.


Risks

Interoperability and Compatibility

This feature was well received at the Web Platform Working Group discussion at TPAC 2018 (minutes).


Edge: No signals

Firefox: under consideration (discussion, bug). The canShare() method was requested by Marcos.

Safari: Level 1 of the Web Share spec (text and URL sharing) is implemented in Safari Preview.

Web / Framework developers: The ability to share images and files has been a consistent request.


See also the blink-dev Intent to Implement discussion for Level 1. Usage of Level 1 has been growing.


Ergonomics

The Web Share Target API complements this API. Web applications can register to receive share requests. It is implemented (but not shipped) in Chrome for Android.


Activation

The API is straightforward and feature detectable, developers should be able to make use of it immediately, without degrading the experience of users running older browsers.


Debuggability

No DevTools changes are required.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

This feature will initially be implemented on Android only. (Similarly, Blink has only shipped Level 1 on Android.) Sharing on other platforms is outside the scope of this Intent.


Feature dashboard

Web Share API Level 2


Requesting approval to ship?

No


Jochen Eisinger

unread,
Jan 28, 2019, 3:39:24 AM1/28/19
to Eric Willigers, blink-dev
Are there plans to protect against malicious content being sent over this API? E.g. executables, or similar?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAyiQQPuDED-soEmtHjnQwYeHG_Kqk8Dt%2B4hXNpjxtukc57J_g%40mail.gmail.com.

Ashley Gullen

unread,
Jan 28, 2019, 9:22:35 AM1/28/19
to Eric Willigers, blink-dev
The most important extension to Web Share for us is the ability to share images. It sounded like this was mentioned in passing, but to be clear, is this definitely supported? I suppose we would encode a compressed image as a blob (e.g. calling canvas.toBlob()), convert it to a file (e.g. new File([blob], "myfile.png")), and then add it to the files array of the share data?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Tom Jones

unread,
Jan 28, 2019, 4:08:47 PM1/28/19
to Eric Willigers, blink-dev
This sounds very DANGEROUS to me. Quote " A web site might like their users to be able to share their pictures and other files through social media, email, chat, etc.  "
Isn't that what gets us all into trouble?
If we had a proposal to allow fully-informed users to make a sharing decision, that would sound much better that letting the web site decide.

I suggest we re-think this one.
Peace ..tom


Eric Willigers

unread,
Jan 28, 2019, 9:16:23 PM1/28/19
to Tom Jones, blink-dev
On Tue, Jan 29, 2019 at 8:08 AM Tom Jones <thomascli...@gmail.com> wrote:
If we had a proposal to allow fully-informed users to make a sharing decision, that would sound much better that letting the web site decide.

A "Share via ..." dialog is shown to the user, so they can select a share target, or cancel the share. This is described in the spec, and is already shipped in Web Share Level 1: 
Present the user with a choice of one or more share targets, selected at the user agent's discretion. The user MUST be given the option to cancel rather than choosing any of the share targets. Wait for the user's choice.

Thus the user has final say. 

The extension in Level 2 is the ability to share files. Nothing in the API creates File objects, so web sites would only be able to share Files they created or already have access to.



Eric Willigers

unread,
Jan 28, 2019, 9:17:43 PM1/28/19
to Ashley Gullen, blink-dev
On Tue, Jan 29, 2019 at 1:22 AM Ashley Gullen <ash...@scirra.com> wrote:
The most important extension to Web Share for us is the ability to share images. It sounded like this was mentioned in passing, but to be clear, is this definitely supported? I suppose we would encode a compressed image as a blob (e.g. calling canvas.toBlob()), convert it to a file (e.g. new File([blob], "myfile.png")), and then add it to the files array of the share data?

Yes, this is a typical use case.
const image = new File([blob], "myfile.png", {type: "image/png"});
navigator.share({ files: [image] });

 

Tom Jones

unread,
Jan 28, 2019, 11:15:44 PM1/28/19
to Eric Willigers, blink-dev
Thanks for that, it might be helpful to modify the description, if any one else balks.
Peace ..tom

Eric Willigers

unread,
Jan 29, 2019, 12:49:03 AM1/29/19
to Jochen Eisinger, blink-dev
On Mon, Jan 28, 2019 at 7:39 PM Jochen Eisinger <joc...@chromium.org> wrote:
Are there plans to protect against malicious content being sent over this API? E.g. executables, or similar?

There are no current plans. We don't block executables from being uploaded in <input type="file">. Android's sharing system doesn't block the sharing of APKs, for example from Downloads to Google Drive.

If a widely used share target on a given platform did leave their users vulnerable to unsandboxed code execution, we might need to block the sharing of executables on that platform. We can add a paragraph to the spec.

There is already the paragraph
The data passed to navigator.share() might be used to exploit buffer overflow or other remote code execution vulnerabilities in native applications that receive shares. There is no general way to guard against this, but implementors will want to be aware that it is a possibility. 

Jochen Eisinger

unread,
Jan 29, 2019, 3:40:06 AM1/29/19
to Eric Willigers, blink-dev
On Tue, Jan 29, 2019 at 6:48 AM Eric Willigers <ericwi...@chromium.org> wrote:
On Mon, Jan 28, 2019 at 7:39 PM Jochen Eisinger <joc...@chromium.org> wrote:
Are there plans to protect against malicious content being sent over this API? E.g. executables, or similar?

There are no current plans. We don't block executables from being uploaded in <input type="file">. Android's sharing system doesn't block the sharing of APKs, for example from Downloads to Google Drive.

If we download stuff in Chrome, we do have some level of protection, both based on origin (safe browsing) and file type.

I'm wondering whether it would be prudent to first start with supporting only a set of known types that we can do basic checks on in a sandboxed renderer, e.g., decoding of an image, parsing of a URL, etc..

Daniel Bratell

unread,
Jan 29, 2019, 6:00:03 AM1/29/19
to Eric Willigers, Tom Jones, blink-dev
I find it a bit tricky to keep the sharing APIs apart but as far as I've understood this one will not directly expose anything on a user's device but instead let a web site direct one of its own resources (which may be something the user has earlier uploaded) to a generic "sharing" switchboard, which might then send that resource onwards via mail, social media, or something else. 

A malicious site could make that resource public without going through the user so I'm not that worried about that part, but there are some security concerns since this might trigger an OS sharing dialog without the user knowing why or how to cancel/abort the process. 

All in all it seems like a reasonable thing to explore.

/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK2Cwb4zhPYrsZJUbowJrV_0%2Be9E4moTFtdH0_z_VPVHDz_7CQ%40mail.gmail.com.



--
/* Opera Software, Linköping, Sweden: CET (UTC+1) */
Reply all
Reply to author
Forward
0 new messages