There is no HTTP Referer header for iframe in an extension page

[hanguokai]

Today we have a discussion about YouTube player in an extension page.

<iframe id="ytplayer" type="text/html" width="640" height="360"
  src="https://www.youtube.com/embed/M7lc1UVf-VE?autoplay=1"
  frameborder="0"></iframe>

Above is the code that users embed a youtube video in a web page or extension page. Recently, it doesn't work in extension pages, but still works in web pages. After investigation, I found YouTube asks all clients (including embed youtube player) to send HTTP Referer header. If there is no referer, youtube doesn't allow you to use it (show a 153 error code – The request does not include the HTTP Referer header or equivalent API Client identification).

The key difference between web page and extension page is the browser doesn't send HTTP Referer for an iframe in an extension page, it sends this header if the iframe is embedded in web pages.

I'm not quite sure why the browser does this by default in extension pages. We have two workarounds in the prior discussion link, but it requires more work for developers. Could browsers offer a better solution?

[carlosjeurissen]

@hanguokai thanks for opening this issue!

@oliverdunk this may be relevant on how a potential solution for #730 is designed.

[oliverdunk]

Thanks for flagging this, Carlos! It seems like a good one to discuss during TPAC and we can decide on the best overall behavior.

[Rob--W]

This topic was discussed in today's meeting. The meeting notes are pending review before publication in #900.

Two main questions:

• What is the URL/origin we want to expose? In Chrome the URL is static and the same for all users, but in Firefox and Safari it is different. In WebExtensions should use asset links model for WebAuthn RP ID #238 we also had the issue of needing a stable URL (Origin) for identification purposes, so if we converge towards a common way of having a fixed URL, that might be helpful here.
• How do we want to expose it? Exposing by default may be problematic, but if an extension were to specify a referrer policy (e.g. in a meta tag or referrerPolicy attribute), there may be something to say for exposing it.

[derekantrican]

I'm also seeing this issue, but not in a webextension (so feel free to redirect me elsewhere if there's a better place).

I have a small app that is basically a webbrowser (using WebView2) that allows you to watch videos like a "picture-in-picture" view: https://github.com/derekantrican/WatchNow_public . The app has always used the "embed" url for YouTube videos to avoid all the clutter.

A couple months ago I started seeing the 153 error with the error embedder.identity.missing.referrer in the YouTube embed player. Even trying to use the full iframe player with referrerpolicy="strict-origin-when-cross-origin" doesn't seem to get around it.

Is someone here able to provide a little more light about what changed with the YouTube player that caused embed players to stop working and what the recommended fix would be?

[carlosjeurissen]

@derekantrican for WebView2 specifically you can open an issue here:
https://github.com/MicrosoftEdge/WebView2Feedback

[derekantrican]

@carlosjeurissen Thanks, but this isn't an issue with WebView2, this is something that changed with the YouTube embed video player in the last 2ish months. I can reproduce this issue in any browser with the following steps:

1. Open any YouTube video
2. Go to Share > Embed and copy the given iframe snippet
3. Create a local .html file with the iframe snippet
4. Open that .html file in any browser

For me, this always shows a "153" error. This used to work just fine until a couple months ago.

[carlosjeurissen]

@derekantrican this is also not an issue in the YouTube embed video player. From YouTube's perspective, it does it's job perfectly fine.

Seems the issue is the YouTube iframe not getting a referrer even if referrerpolicy="strict-origin-when-cross-origin" is explicitly set. In which case it is a WebView2 issue. In any case continuing this conversation in a WebView2Feedback issue makes a lot more sense as your issue is unrelated to webExtensions.