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

393 views
Skip to first unread message

Eric Willigers

unread,
Jul 17, 2020, 5:15:32 AM7/17/20
to blink-dev, Matt Giuca
ericwi...@chromium.org,mgi...@chromium.org Specification: https://w3c.github.io/web-share/#feature-policy Not needed, trivial change to existing spec A new permission policy, "web-share", controls access to navigator.share(). The default allowlist is 'self', avoiding possible abuse by third party iframes. 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.
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
No Web Share is currently only supported on Android. No WPT verifies that share() fails with NotAllowedError when feature policy headers specify Feature-Policy: web-share 'none' https://bugs.chromium.org/p/chromium/issues/detail?id=1079104 https://www.chromestatus.com/feature/6362499966304256
This intent message was generated by Chrome Platform Status.

Chris Harrelson

unread,
Jul 23, 2020, 3:31:43 PM7/23/20
to Eric Willigers, blink-dev, Matt Giuca
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

unread,
Jul 23, 2020, 3:43:31 PM7/23/20
to Chris Harrelson, Chris Wilson, Eric Willigers, blink-dev, Matt Giuca
+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


Eric Willigers

unread,
Jul 23, 2020, 7:59:39 PM7/23/20
to Mike West, Chris Harrelson, Chris Wilson, blink-dev, Matt Giuca
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

unread,
Jul 24, 2020, 2:41:50 AM7/24/20
to Eric Willigers, Chris Harrelson, Chris Wilson, blink-dev, Matt Giuca
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

unread,
Jul 30, 2020, 2:20:08 PM7/30/20
to blink-dev, Mike West, Chris Harrelson, cwi...@google.com, blink-dev, Matt Giuca, Eric Willigers
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

unread,
Jul 31, 2020, 12:22:30 AM7/31/20
to Mike West, blink-dev, Chris Harrelson, cwi...@google.com, Matt Giuca
> Would you mind filing a bug at https://github.com/web-platform-tests/wpt/issues/new, and marking it as `type:untestable`?



> 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

unread,
Aug 6, 2020, 7:42:33 PM8/6/20
to Eric Willigers, Mike West, blink-dev, cwi...@google.com, Matt Giuca
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.

Eric Lawrence

unread,
Aug 11, 2020, 4:27:54 PM8/11/20
to blink-dev, Chris Harrelson, mk...@chromium.org, blink-dev, cwi...@google.com, Matt Giuca, Eric Willigers
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

unread,
Aug 11, 2020, 8:08:32 PM8/11/20
to blink-dev, eri...@microsoft.com, Chris Harrelson, mk...@chromium.org, blink-dev, cwi...@google.com, Matt Giuca, Eric Willigers
The permission policy was temporarily enforced on Canary. 

Eric Willigers

unread,
Aug 11, 2020, 10:32:00 PM8/11/20
to blink-dev, eri...@microsoft.com, Chris Harrelson, mk...@chromium.org, cwi...@google.com, Matt Giuca
The permission policy was enforced on Canary from #789872 to #795383.

Eric Lawrence

unread,
Aug 12, 2020, 2:41:07 PM8/12/20
to blink-dev, Eric Willigers, Eric Lawrence, Chris Harrelson, mk...@chromium.org, cwi...@google.com, Matt Giuca
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

unread,
Aug 20, 2020, 3:15:18 PM8/20/20
to blink-dev, eri...@microsoft.com, Eric Willigers, Chris Harrelson, Mike West, cwi...@google.com, Matt Giuca
Hey folks,

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

-mike

Eric Willigers

unread,
Aug 24, 2020, 1:03:55 AM8/24/20
to blink-dev, eri...@microsoft.com, ericwi...@chromium.org, chri...@chromium.org, mk...@chromium.org, cwi...@google.com, mgi...@chromium.org

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

unread,
Sep 3, 2020, 3:06:46 PM9/3/20
to Eric Willigers, blink-dev, eri...@microsoft.com, Mike West, Chris Wilson, Matt Giuca
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.

Matt Giuca

unread,
Nov 2, 2020, 12:22:58 AM11/2/20
to Chris Harrelson, Eric Willigers, blink-dev, eri...@microsoft.com, Mike West, Chris Wilson
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

unread,
May 20, 2022, 4:36:22 AMMay 20
to blink-dev, Matt Giuca, Eric Willigers, blink-dev, eri...@microsoft.com, mk...@chromium.org, cwi...@google.com, Chris Harrelson
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

unread,
May 26, 2022, 11:07:48 AMMay 26
to blink-dev, Marcos Caceres, Matt Giuca, Eric Willigers, blink-dev, eri...@microsoft.com, mk...@chromium.org, cwi...@google.com, Chris Harrelson
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

unread,
May 26, 2022, 12:35:32 PMMay 26
to Marcos Caceres, blink-dev, Matt Giuca, Eric Willigers, eri...@microsoft.com, mk...@chromium.org, cwi...@google.com, Chris Harrelson
Thanks for the pings, Marcos. I'll try and have an update for you in the next week.

Matt Giuca

unread,
Jun 7, 2022, 10:05:48 PMJun 7
to Joshua Bell, Marcos Caceres, blink-dev, Eric Willigers, eri...@microsoft.com, mk...@chromium.org, cwi...@google.com, Chris Harrelson
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:

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

unread,
Jun 14, 2022, 1:55:04 AMJun 14
to blink-dev, Matt Giuca, Marcos Caceres, blink-dev, Eric Willigers, eri...@microsoft.com, mk...@chromium.org, cwi...@google.com, Chris Harrelson, Joshua Bell
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:

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.


Looking forward to a speedy resolution! 

Eric Willigers

unread,
Nov 8, 2022, 11:02:15 PMNov 8
to blink-dev, mar...@marcosc.com, Matt Giuca, blink-dev, Eric Willigers, eri...@microsoft.com, Mike West, cwi...@google.com, Chris Harrelson, Joshua Bell
The YouTube issue has been addressed. We can ship with default "self" in M110. crrev.com/c/3995946

Mike Taylor

unread,
Nov 9, 2022, 11:48:10 AMNov 9
to blink-dev, Eric Willigers, mar...@marcosc.com, Matt Giuca, blink-dev, eri...@microsoft.com, Mike West, cwi...@google.com, Chris Harrelson, Joshua Bell
That's great to hear \o/.

Eric, do you plan to send an I2S for this change?

Marcos Caceres

unread,
Nov 9, 2022, 12:58:27 PMNov 9
to Eric Willigers, blink-dev, Matt Giuca, eri...@microsoft.com, Mike West, cwi...@google.com, Chris Harrelson, Joshua Bell
Fantastic to hear! I’ve put up the the WebKit patch and hope to land it by the end of the week:
https://github.com/WebKit/WebKit/pull/6074

I also refactored the tests a little bit if anyone has a few cycles to review:
https://github.com/web-platform-tests/wpt/pull/36862/files

(I need to make some small changes to get them to run on WebKit Infra, plus found some missing conditions).
Reply all
Reply to author
Forward
0 new messages