Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editorial: mark permissions policy at risk #234

Merged
merged 6 commits into from
Jul 12, 2022
Merged

Editorial: mark permissions policy at risk #234

merged 6 commits into from
Jul 12, 2022

Conversation

marcoscaceres
Copy link
Member

@marcoscaceres marcoscaceres commented May 25, 2022

Closes #233


Preview | Diff

@marcoscaceres
Copy link
Member Author

As we haven't managed to hear back from YouTube in a reasonable amount of time, I'd like to move on this and patch WebKit this week.

@saschanaz, what's you plan for Gecko?

@saschanaz
Copy link
Member

saschanaz commented Jun 6, 2022

TBH I'd like to keep it and instead inject the following as the workaround, if we want to keep the policy itself:

if (window.parent != window.top) {
  navigator.share = undefined;
}

This at least activates the traditional fallback. (Sigh, we should have done this a year ago, idk why I didn't)

Edit: https://bugzilla.mozilla.org/show_bug.cgi?id=1772949

@marcoscaceres marcoscaceres changed the title Switch Permission Policy to * Switch Permissions Policy to * Jun 7, 2022
@mgiuca
Copy link
Collaborator

mgiuca commented Jun 8, 2022

TBH I'd like to keep it and instead inject the following as the workaround, if we want to keep the policy itself:

Do you mean inject that specifically into YouTube frames?

My slight preference is also to keep it strict rather than allowing it to be open by default. I am following up with YouTube to see if we can properly fix the exception rather than having to inject a fallback like that.

@saschanaz
Copy link
Member

Do you mean inject that specifically into YouTube frames?

Exactly.

My slight preference is also to keep it strict rather than allowing it to be open by default. I am following up with YouTube to see if we can properly fix the exception rather than having to inject a fallback like that.

👍

@mgiuca
Copy link
Collaborator

mgiuca commented Jun 8, 2022

I have been trying to reproduce this issue specifically on YouTube, but I can't actually see a share button in the embedded player. It's possible that YouTube removed the share button for embedded players in the last 2 years.

Example: https://www.w3schools.com/html/tryit.asp?filename=tryhtml_youtubeiframe_autoplay
I don't see a share button, nor is there one on the right-click menu, three-dot menu or settings menu. Tried in Chrome and Firefox. If there's no share button, then there's nothing to fix on the YT side, and our main concern about enabling this by default is removed.

@saschanaz have you been able to reproduce the broken share button on YouTube recently?

@marcoscaceres
Copy link
Member Author

marcoscaceres commented Jun 8, 2022

I have been trying to reproduce this issue specifically on YouTube, but I can't actually see a share button in the embedded player. It's possible that YouTube removed the share button for embedded players in the last 2 years.

No, it's done via third-party embedder like:
http://youtubeembedcode.com/en/

And:
https://youtubevideoembed.com

Which generate code like:

<iframe 
src="https://www.youtube.com/embed/jNQXAC9IVRw?loop=1&modestbranding=1" 
width="560" height="315" 
frameborder="0" 
allowfullscreen="">....</iframe>

The above shows the share button:

Screen Shot 2022-06-08 at 2 28 11 pm

Note that the above src is YouTube - so maybe it's a setting in YouTube itself saying "this video is sharable" or something.

@marcoscaceres
Copy link
Member Author

Here is a more significant example (view source):
https://diablo4.blizzard.com/en-us/

<iframe 
 class="absolute inset-0 w-full h-full" 
width="560" height="315" 
src="https://www.youtube.com/embed/LvrLZ4yETHI?autoplay=0&modestbranding=1" 
frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

@marcoscaceres
Copy link
Member Author

I should be more clear here that the various sites themselves would need to update their iframe with allow="web-share" to work.

Further, YouTube needs to update their own generated embed code. For example, it currently generates this (which is missing "web-share"):

Screen Shot 2022-06-08 at 2 59 38 pm

For which, given a random video, does include the share button.
https://jsbin.com/naxarebuwo/edit?html,output

@mgiuca
Copy link
Collaborator

mgiuca commented Jun 8, 2022

Very strange. I was playing around with the various differences in the iframe embed code between the Muppets example on w3schools and the Diablo IV example you posted above. It turns out literally the thing that makes the difference is the video: Muppets does not have a share button, Diablo does.

I don't know why that is, but thanks, I have a minimal repro now so I can take it to the YouTube team.

@marcoscaceres
Copy link
Member Author

Just Fyi, I've updated WebKit to use "*" in the interim to mitigate the current web compat issues.

@mgiuca, please let us know how you go with YouTube and happy to coordinate on a switch to self.

@marcoscaceres
Copy link
Member Author

Just touching base again as it's been over a month... how should we proceed? Give it more time or...?

@marcoscaceres
Copy link
Member Author

marcoscaceres commented Jul 8, 2022

Ok, this is the last outstanding issue in the spec. We've tried multiple times/ways of getting in touch with the YouTube folks for a while now but we've sadly not succeeded.

So, in the interest of moving forward, any objections with going down the "*" route? If I don't hear any objections, I'll merge this next week (on the 15th of July).

If there are objections, I'd like to hear about a tangible course of action.

@saschanaz
Copy link
Member

Still not a big fan of this as there's not been too many reports of this from users. (No reports for Gecko AFAICT, except mine https://bugzilla.mozilla.org/buglist.cgi?quicksearch=youtube%20share&list_id=16140758)

One point is that it's weird to expose navigator.share at all in a context that the browser knows it will always fail. Mozilla is seeing similar issue for IndexedDB (which currently always fails on private browsing mode on Gecko and the feature detection is not straightforward).

Might be worth to fix that as a general solution?

@marcoscaceres
Copy link
Member Author

Still not a big fan of this as there's not been too many reports of this from users.

We've had the opposite experience on the Safari side.

One point is that it's weird to expose navigator.share at all in a context that the browser knows it will always fail.
...
Might be worth to fix that as a general solution?

Might be tricky, but yeah... something like telling Permissions Policy to not expose the API at all (same way as secure-context works, but somehow configurable).

@marcoscaceres
Copy link
Member Author

Gave this more thought... to allow us to proceed to CR, with my WG Chair hat on, we can mark this feature "at risk". That allows us to publish, and then we can try to sort out the Permissions Policy situation by the end of the year.

If we don't sort it out, we can remove it from the spec and then add it back at such time as we actually get interoperability.

@marcoscaceres marcoscaceres changed the title Switch Permissions Policy to * Editorial: mark permissions policy at risk Jul 12, 2022
@marcoscaceres
Copy link
Member Author

Alright, I've updated the example and marked the feature at risk.

@marcoscaceres marcoscaceres merged commit 3d65c4e into main Jul 12, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add example of permission policy use with iframe
3 participants