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?