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
Requesting approval to ship?
No
--
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.
--
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.
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.
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.
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?
const image = new File([blob], "myfile.png", {type: "image/png"});navigator.share({ files: [image] });
Are there plans to protect against malicious content being sent over this API? E.g. executables, or similar?
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.
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.
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.