Intent stage "Evaluate readiness to ship": web-share permission policy

[Eric Willigers]

Contact emails ericwi...@chromium.org,mgi...@chromium.org Explainer Design docs/spec Specification: https://w3c.github.io/web-share/#feature-policy TAG review Not needed, trivial change to existing spec Summary A new permission policy, "web-share", controls access to navigator.share(). The default allowlist is 'self', avoiding possible abuse by third party iframes. Motivation Third party iframes could previously use navigator.share() without explicit permission from the site. The new permission policy's default allowlist is 'self', preventing such abuse. Organizations that want to prevent sharing will be able to define an enterprise policy. Risks

Interoperability and Compatibility Minimal. navigator.share() is used by web apps, not common third party iframes. Gecko: Positive (https://github.com/w3c/web-share/issues/151) Collaborated with Marcos on spec text. WebKit: No signal Web developers: No signals

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? No Web Share is currently only supported on Android. Is this feature fully tested by web-platform-tests? No WPT verifies that share() fails with NotAllowedError when feature policy headers specify Feature-Policy: web-share 'none' Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1079104 Link to entry on the Chrome Platform Status https://www.chromestatus.com/feature/6362499966304256

This intent message was generated by Chrome Platform Status.

[Chris Harrelson]

Hi Eric,

Is this actually an intent-to-ship? Also, please use the methodology for browser signals linked from the most recent intent-to-ship template.

--
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAyiQQNZgE7JcATa7nAc0jpmj%3DfMJ%3DSnzAOvcspxTBZDe6QKcQ%40mail.gmail.com.

[Mike West]

+Chris Wilson to follow up on the subject line for emails generated by chromestatus.com. :)

Assuming this is an intent to ship, it seems pretty reasonable to me conceptually. That said, it is a deprecation and removal in disguise, as it going to prevent frames that are currently triggering share actions from doing so until their embedders update. That seems like the right long-term outcome, but it would be helpful to quantify the short-term implications. Do we have UseCounters that would help us understand the potential breakage? I'm thinking of embedded services like sharethis (which might or might not actually use the webshare API?), and would be left with broken buttons. Is there data you could provide, perhaps from HTTP Archive, that could set an upper bound on the short-term impact?

You also note that WPT doesn't cover this functionality yet. It would be helpful to add tests to verify the nested behavior.

-mike

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

[Eric Willigers]

On Fri, Jul 24, 2020 at 5:43 AM Mike West <mk...@chromium.org> wrote:

You also note that WPT doesn't cover this functionality yet. It would be helpful to add tests to verify the nested behavior.

Web Share is only available in the context of transient activation (previously known as user activation). I don't know how to achieve that in a WPT. testdriver.js bless calls click, which has

        click: function(element) {
            if (window.top !== window) {
                return Promise.reject(new Error("can only click in top-level window"));
            }

[Mike West]

Got it. Would you mind filing a bug at https://github.com/web-platform-tests/wpt/issues/new, and marking it as `type:untestable`?

-mike

[Mike West]

Pinging the questions around short-term impact. Have y'all been able to gather any data that could help us make a decision?

-mike

[Eric Willigers]

> Would you mind filing a bug at https://github.com/web-platform-tests/wpt/issues/new, and marking it as `type:untestable`?

Raised https://github.com/web-platform-tests/wpt/issues/24755

> Pinging the questions around short-term impact. Have y'all been able to gather any data that could help us make a decision?

I think we can get the most reliable data by adding use counters, checking how often a feature policy would deny permission if it was enforced.

This would delay an enforcement decision by a couple of releases, but that shouldn't be a problem.

[Chris Harrelson]

Hi Eric,

Just to give a quick update: the plan of gathering data via use counters and then coming back to this thread sounds good to the API owners, as the timeline is acceptable to you.

Chris

--
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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAyiQQOJzv30-5PdLcMFwf5g-K7XHneOQ80KQzj%2BbcAcuGnVcw%40mail.gmail.com.

[Eric Lawrence]

Is this change expected to have broken YouTube video sharing?

1. Using Edge Dev (which enables the sharing API by default) visit https://www.tcl.com/in/en.html
2. Scroll down and play a video under Discover TCL
3. Click on Share option 
   
   Nothing visibly happens, but console shows:

base.js:6945 Uncaught (in promise) DOMException: Failed to execute 'share' on 'Navigator': Permission denied
    at g.mQ.onClick (https://www.youtube.com/s/player/0a90460f/player_ias.vflset/en_US/base.js:6945:285)  

When I perform the bisect, it points at our merged payload including https://chromium.googlesource.com/chromium/src/+/e41da738c01c870e5c30ccb24bb4c9f9b1cb5ae9

Interestingly I was unable to reproduce an error when trying this repro in Chrome on Android.

[Eric Willigers]

The permission policy was temporarily enforced on Canary. 

[Eric Willigers]

The permission policy was enforced on Canary from #789872 to #795383.

[Eric Lawrence]

Thanks, Eric!

I'm still curious about the long-term plan for YouTube's "Share" feature (at a minimum, it seems like they should tolerate fallback more gracefully) but it's good to hear that the immediate functional regression will be cleared up for us shortly.

[Mike West]

Hey folks,

Have you followed up with YouTube internally? As Eric notes, it seems bad that this broke sharing in Canary.

-mike

[Eric Willigers]

On Friday, August 21, 2020 at 5:15:18 AM UTC+10, Mike West wrote:

Have you followed up with YouTube internally? As Eric notes, it seems bad that this broke sharing in Canary.

I have raised a YouTube issue internally, showing how to detect if Feature Policy forbids sharing.

[Chris Harrelson]

Hi Eric,

Did the analysis relating to Youtube complete? Do you think this will be safe to turn on, because the Youtube case was sufficiently special?

Chris

--
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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e554e75c-f1cc-4a68-bac9-a7e8477c916bo%40chromium.org.

[Matt Giuca]

Pinging on this. It's been awhile and I don't think we've seen any update on it. (Nobody from YouTube responded on the internal bug.)

Eric, did measurements land and if so, what milestone will we start seeing results in?

[Marcos Caceres]

Hi All, 

Coming back to this as it's now starting to cause Web compatibly issues across both Firefox and SafariTP (both of which implement `'self'`). 

I'm still worried that the ability to share files and other content (and even URLs, as we've seen in the past) is quite a powerful feature with security implications.

However, we (other implementers) are facing a losing battle with Web compatibly here :( 

If it's too far gone, could we compromise with a "*" policy. But I'd like to get again get a sense if we can go with 'self'.   

[Marcos Caceres]

Just checking in again 👋 I'm wondering if by chance folks here might be to ping the YouTube folks one last time? It's been a while, so maybe they will respond this time? 

Also, if we can try to get some cross-browser resolution around permission policy for Web Share, it would be really great.   

[Joshua Bell]

Thanks for the pings, Marcos. I'll try and have an update for you in the next week.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/124d0a06-05d6-4248-8771-0ac15105e787n%40chromium.org.

[Matt Giuca]

Hi folks,

I've followed up on this internally at Google (talking to Chrome and YouTube people) and also had a private thread with Marcos.

Marcos has proposed just changing the spec (and by extension, Gecko) to make the permission policy be "*" by default, essentially codifying Chrome and Safari's current behaviour of allowing embeds to use Web Share without permission, but giving embedders the option to explicitly block it:

https://github.com/w3c/web-share/pull/234

My preference is actually to try and enforce the current spec (default of "self") which would mean YT and other embeds are blocked from using Web Share by default, unless granted permission by the embedder.

As I see it, the only major issue with YouTube being a huge user of Web Share in iframes, is that the share button is apparently broken (as in, if clicked, it throws a JS exception) if the permission is blocked. That's simply a bug which we can get YouTube to fix (I am following up internally with YouTube). If that bug is fixed, then I don't see a problem with the share button falling back to use the internal in-page share UI (rather than using the Web Share API) on the majority of embedded YT videos, with the option for embedders to grant the permission if they want that UI to work.

Either way, we should come to a consensus on this and align the spec and three implementations in relatively short order (O(days-weeks)).

Apologies that this issue has been left dangling for years.

Matt

[Marcos Caceres]

Hi All, 

On Wednesday, June 8, 2022 at 12:05:48 PM UTC+10 Matt Giuca wrote:

Hi folks,

I've followed up on this internally at Google (talking to Chrome and YouTube people) and also had a private thread with Marcos.

Marcos has proposed just changing the spec (and by extension, Gecko) to make the permission policy be "*" by default, essentially codifying Chrome and Safari's current behaviour of allowing embeds to use Web Share without permission, but giving embedders the option to explicitly block it:

https://github.com/w3c/web-share/pull/234 

My preference is actually to try and enforce the current spec (default of "self") which would mean YT and other embeds are blocked from using Web Share by default, unless granted permission by the embedder.

'self' is my preference also and I'd be more than happy to close the PR for the proposal above (#234). Short of removing the permissions policy entirely, #234 was basically the only means we had to deal with the web compat issues that have arisen. 

But it's super encouraging to hear "self" could be back on the table. 🙏 

As I see it, the only major issue with YouTube being a huge user of Web Share in iframes, is that the share button is apparently broken (as in, if clicked, it throws a JS exception) if the permission is blocked. That's simply a bug which we can get YouTube to fix (I am following up internally with YouTube). If that bug is fixed, then I don't see a problem with the share button falling back to use the internal in-page share UI (rather than using the Web Share API) on the majority of embedded YT videos, with the option for embedders to grant the permission if they want that UI to work.

Either way, we should come to a consensus on this and align the spec and three implementations in relatively short order (O(days-weeks)).

That would be amazing. In the meantime, we've updated WebKit to use "*" as I was left with little option because of the breakage.

However, if we get agreement on "self" and some kind of timeframe form Chrome, I can revert that form WebKit and we can work towards an interoperable solution ('self'). 

FWIW, Firefox is also shipping with 'self' as the policy [1], which means it's also affecting their Windows and Android implementations.

[1] https://github.com/mozilla/gecko-dev/blob/1e13dfc1bd87c3747d6712807401c590d0211a46/dom/security/featurepolicy/FeaturePolicyUtils.cpp#L37  

Looking forward to a speedy resolution!