Web Share Target API

[matteocargnelutti]

Request for position on an emerging web specification

• WebKittens who can provide input: @hortont424, @marcoscaceres

Information about the spec

• Spec Title: Web Share Target API
• Spec URL: https://w3c.github.io/web-share-target/
• GitHub repository: https://github.com/w3c/web-share-target

Design reviews and vendor positions

• Mozilla standards-positions issue: Web Share Target mozilla/standards-positions#176

Bugs tracking this feature

• WebKit Bugzilla: https://bugs.webkit.org/show_bug.cgi?id=194593

Anything else we need to know

Summary: While the Web Share API allows browsers to make use of the operating system's native "share" mechanism in web-to-native contexts, the Web Share Target API intent is to enable web-to-web and native-to-web sharing scenarios.
What is WebKit's position on this spec?

[othermaciej]

Is this an Unofficial Draft of the Web Apps WG? Is it a community group thing? Can't tell the venue from the document itself.

[matteocargnelutti]

@othermaciej My understanding is that this draft comes from the WICG, as the Specification - Level 2 doc suggests:

[...] Web Share Target API - Level 2 Specification, published by the Web Incubator Community Group under the W3C Community Contributor License Agreement (CLA). [...]

https://github.com/WICG/web-share-target/ redirects to https://github.com/w3c/web-share-target.

[marcoscaceres]

It's an unofficial draft, but it's in scope for WebApps WG should another implementer become interested:
https://www.w3.org/2019/05/webapps-charter.html#wicgspecs

[othermaciej]

OK, so for now WICG, but has fast track to go to Web Apps WG depending on interest?

[marcoscaceres]

That's correct, yes.

[hober]

@hortont424, thoughts?

[othermaciej]

Potential security concerns if this allows a website to appear in the Share Sheet with a site-chosen icon and name, as it can then intentionally duplicate a popular or preinstalled app and thus mislead users.

[tomayac]

The user would need to add the app to their home screen pro-actively, so when they are on Banana Game with a [🍌] icon and they try to add it and it suddenly says Facebook Messenger with a [💬] icon, they would notice there.

[othermaciej]

So this API is only usable by installed/homescreen web apps? Not in the browser?

[matteocargnelutti]

@othermaciej: So this API is only usable by installed/homescreen web apps? Not in the browser?

In its current state, the spec leaves the user agent determine how, if, and when targets should be registered.

The spec suggests different strategies that can be used to determine if the share target(s) should be registered: whether or not the web app is installed is one of them.

Chrome's current implementation of the Web Share Target API requires the web app to be installed.

---

@othermaciej: Potential security concerns if this allows a website to appear in the Share Sheet with a site-chosen icon and name, as it can then intentionally duplicate a popular or preinstalled app and thus mislead users.

The spec also lists spoofing as a risk of "particular concern", and suggests that this risk is heightened when the user agent doesn't require the web app to be installed.

[tomayac]

@othermaciej I have opened w3c/web-share-target#109 asking if some sort of installation ceremony should be made obligatory by the spec. In practice, the API in its current implementation in Chromium already requires apps to be installed for it to have an effect.

[othermaciej]

@othermaciej: Potential security concerns if this allows a website to appear in the Share Sheet with a site-chosen icon and name, as it can then intentionally duplicate a popular or preinstalled app and thus mislead users.

The spec also lists spoofing as a risk of "particular concern", and suggests that this risk is heightened when the user agent doesn't require the web app to be installed.

Ideally there should be not just an identification of the risk but also something in the spec (even if just a suggestion) to mitigate it. The risk is also heightened if it's possible for a web app's name or icon to change post-install (without user confirmation).

[tomayac]

Regarding changing icons and/or name: both are considered security-sensitive and the spec mandates UAs make users aware of such changes.

[marcoscaceres]

This is a DRAFT POSITION and does not represent the consensus of the WebKit community.

However, unless anyone objects by Friday 16th of November 2022, we will make the below the "official position". Please feel free to object or requests more time if needed. Please expressed support through the thumbs up reaction or additional comments (no +1 comments please!).

WebKit’s position is "neutral" but with concerns.

The main pro of the API is that it allows applications applications that have been added to the home screen to participate as share targets, putting them on a more equal footing with other applications participating as share targets. We continue to evaluate ways to determine user trust for arbitrary websites (those not “installed”) to serve as a share targets. Stronger spec wording may be required to make sure that a regular web application can’t change its visual identity after the user has registered a site as a share target (e.g., perhaps it might be prudent to just say that an application MUST be “installed” per Web Manifest).

The WebKit community probably needs to evaluate if the mechanism proposed is compatible across various platforms (particularly macOS, which use “Share Extensions”, and iOS, which relies on “Actions“). Further investigation is needed to evaluate how this would integrate in other platforms, like Linux.

Other positive is how it integrates with existing web content by leveraging HTTP GET and POST in the form of a Request. However, the WebKit community would need to further evaluate how well it integrates with both navigating and the use of the Fetch API: presumedly, the origin of the request is set when it is created to be in the correct context, etc. plus probably need to verify the behavior with respect to HTML’s navigation algorithm.

As a side, it would be good to see the spec migrate away from using Web IDL for the extensions to Web Manifest.

[tomayac]

Thanks for your position, @marcoscaceres!

If the spec were to hard-require installation (i.e., Add to Home Screen on iOS/iPadOS) of an app before it can appear as a Web Share Target, would that possibly move your position more toward positive?

[marcoscaceres]

Personally, I still think we need to think about this more in the Web Community at large. I'm personally worried about creating an "installed web" and a regular web: where some things only work if an app is installed. We should avoid that as much as possible, though it may be unavoidable in this case.

Having said that, "neutral" shouldn't be seen as negative. Maybe with a bit of work, Web Apps WG can turn it into something worth "support"ing?

[hober]

Closing as we've identified our position.