Intent To Implement: Web Share API (Windows & Chrome OS)

Hoch Hochkeppel

unread,

Jul 29, 2020, 5:35:13 PM7/29/20

to blink-dev

Contact emails

mho...@microsoft.com, ericwi...@chromium.org

(mhochk will be addressing the Windows portion, ericwilligers the Chrome OS portion)

Explainer

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

Spec

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

Level 1 support already received a TAG review (https://github.com/w3ctag/design-reviews/issues/170, https://github.com/w3ctag/design-reviews/issues/179) and Level 2 was discussed in the TAG review for Share Target (https://github.com/w3ctag/design-reviews/issues/221).

See also the pre-existing Intent To Implement for Level 1 (https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/1BOhy5av8MQ/OPPt76oZCQAJ) and Level 2 (https://groups.google.com/a/chromium.org/forum/#%21msg/blink-dev/AiKgWvv3cq0/xAsjfSfMDQAJ).

Summary

Web Share is an API set for sharing data (text, URLs, files) from a web app (to which the data is already available) to an app of the user's choosing. This has already been implemented/shipped in Chromium for Android and has been implemented/shipped in Edge for Windows. This phase covers extending the support for these APIs to the Windows and Chrome OS implementation in Chromium.

Motivation

The ability to invoke a platform "share" event is already exposed to websites today as a platform-neutral API and its usage is growing, but is only supported on some platforms. To better allow websites to take advantage of this functionality this will extend the support to include more platforms.

The underlying Web Share API's motivations focuses around existing scenarios where websites offer the ability to "share", but are forced to do so using individual links to developer-selected targets. This not only requires the site author to individually add support for targets, it also limits those targets to other websites (not native apps) and limits the user's selection options to those chosen by the site author.

Risks

Interoperability and Compatibility

Interest in this feature has been consistently expressed, but even with its growing support we expect most sites to offer this functionality as an opportunistic addition to their pre-existing share functionality. As such, the impact on sites of adding (or removing) support on an additional platform should be minimal.

Edge: Shipped Level 1 and 2 on Windows.

Firefox: Partially implemented and continuing development (bug, bug)

Safari: Shipped Level 1 support (bug) and continuing development of Level 2 support (bug)

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

See also the Intent to Implement: Web Share API (Android) discussion: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/1BOhy5av8MQ/OPPt76oZCQAJ

See also the Intent to Implement: Web Share Level 2 (Android) discussion: https://groups.google.com/a/chromium.org/forum/#%21msg/blink-dev/AiKgWvv3cq0/xAsjfSfMDQAJ

Ergonomics

The Web Share Target API complements this API. Web applications can register to receive share requests. It is shipped in Chrome for Android (https://web.dev/web-share-target/) and implemented (not shipped) in Edge for Windows.

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)?

No. This feature is already implemented on Android and this will extend the feature support to include Windows and Chrome OS. Web Share has to be specifically implemented for each platform because it is an OS interop mechanism.

Link to entry on the feature dashboard

Level 1: https://www.chromestatus.com/feature/5668769141620736

Level 2: https://www.chromestatus.com/feature/4777349178458112

(New) Windows Tracking Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1035527

(New) Chrome Tracking Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1110119

Requesting approval to ship?

No

Theodore Olsauskas-Warren

unread,

Aug 6, 2020, 1:36:27 PM8/6/20

to blink-dev, mho...@microsoft.com

Are there any concrete proposals to help ensure that the user is sharing only what they actually intend to share? If it's not possible to provide strong guarantees that shared information doesn't contain tracking information or malicious payloads, has any consideration been given to solutions for contextually informing the user that they had really better trust both source and destination endpoints? Is there anything that could be done to prevent an identifier being tacked onto outbound shares and used to join first-party identifiers across every website or application they are shared to?

Eric Willigers

unread,

Aug 6, 2020, 9:56:41 PM8/6/20

to blink-dev, Theodore Olsauskas-Warren, mho...@microsoft.com

With regards to tracking information, I don't think the browser can (or should) try to detect or ban steganography or watermarking in shared images. Similarly, I don't think the browser can determine if URLs like https://paint-recipes.example.com/464338884664003686652232235096 or https://paint-recipes.example.com/?red=46433888&green=4664003686&blue=652232235096 containing tracking identifiers or if they simply identify user-oblivious public web resources. It’s also unlikely that the user would be able to determine that based on a visual inspection of the URL, so showing the URL to the user in advance is unlikely to represent a useful mitigation.

The sharing UI (also called a share sheet) is typically provided by the operating system. If we provided a warning page as a precursor step, web apps would provide an inferior user experience to native apps.

With regards to malicious payloads, we prevent sharing of executables.

We also restrict sharing to HTTPS, require user interaction with the page (transient activation), and are preparing to restrict usage inside iframes via permissions policy.

Hoch Hochkeppel

unread,

Aug 7, 2020, 5:19:40 PM8/7/20

to blink-dev, mho...@microsoft.com, sau...@google.com

The possibility that the payload may contain malicious payloads is a known concern called out in the Security and privacy considerations of the spec.

https://w3c.github.io/web-share/level-2/#security-and-privacy-considerations

As for exposing the to-be-shared content to the user, that is left up to the OS's existing implementation of "sharing". Currently neither Android nor Windows attempts to fully surface all of the data being shared, leaving it up to the source and destination to expose data to the user in such a way that the user feels comfortable using those apps for this operation. The data shared from a source is limited to data already available to that source.

Though there are measures in place to ensure that the source is not given any information on the user-chosen destination, there is nothing to stop the source from including identifiers in the information it chooses to share. In order for those identifiers to be useful to the source, however, the user-chosen destination would have to either react to them based upon an agreement with the source, or inadvertently expose the identifiers in such a way that the source site can later find them (e.g. a unique ID was embedded in a shared image that was then posted publicly to Instagram).

In the case where both the source and destination have an external agreement to share data there is no practical way to prevent them from being able to detect a data share having occurred between them. Even if identifiers were not included in the shared package directly, both could upload hashes of the shared content + timestamps + any identifiers of the account/machine/etc. they have access to and could pair them up based on that.

In the case where the source has hidden identifiers within the content it shares and the destination is unaware of them it would be possible for the source site to also crawl expected destinations where the content may be publicly shared in an attempt to pair the share operation with a destination.

In both cases the threat to user privacy is minimal, as they are only threatening to expose one user interaction - not any pre-existing user data (since that was already exposed to the source before the Share operation started).

Reply all

Reply to author

Forward