YouTube video embedding harm reduction
dustri.org
dustri.org
"Provide videos with a supercharged focus on visual performance. This custom element renders just like the real thing but approximately 224× faster."
- Google's own Lighthouse will mark youtube embeds as bad practices for many reasons. And will provide you with an article on how to replace the official Youtube embed with third-party libraries: https://developer.chrome.com/docs/lighthouse/performance/thi...
- Google's own "Performance leader at Chrome" penned an article for web.dev where he mentions that you should use this other third-party library https://web.dev/articles/iframe-lazy-loading
Just upload the video to GCS, S3 or Cloudflare and use the <video> tag. It's really simple. You can even add different resolutions/bitrates or formats or subtitles in different languages. Cloudflare can even do it automatically for you. But even a single dead simple MP4 works well for most use cases and still loads faster than the YouTube <iframe> player.
https://blog.youtube/inside-youtube/new-era-video-infrastruc...
You're right that all the major video hosts offer it too, and I think GCS/AWS/Cloudflare all have APIs for it, but YouTube does it for free without requiring you to have any clue about all this stuff.
And if the marketing team uses Webflow or Framer or something like that, maybe those tools should add native support for dropping in videos without needing YouTube to make it equally simple, just like they make the rest of the development of the website simple.
I can understand that, actually. deny all would be a forward compatibility nightmare
Here's the full (current) list just to show the sheer insanity of it:
allow="accelerometer 'none';
ambient-light-sensor 'none';
autoplay 'none'; battery 'none';
browsing-topics 'none';
camera 'none';
display-capture 'none';
domain-agent 'none';
document-domain 'none';
encrypted-media 'none';
execution-while-not-rendered 'none';
execution-while-out-of-viewport '';
gamepad 'none'; geolocation 'none';
gyroscope 'none';
hid 'none';
identity-credentials-get 'none';
idle-detection 'none';
local-fonts 'none';
magnetometer 'none';
microphone 'none';
midi 'none';
otp-credentials 'none';
payment 'none';
picture-in-picture 'none';
publickey-credentials-create 'none';
publickey-credentials-get 'none';
screen-wake-lock 'none';
serial 'none';
speaker-selection 'none';
usb 'none';
window-management 'none';
xr-spatial-tracking 'none'",The most importantly thing is just loading the thumbnail instead of the actual iframe on pageload. Loading=lazy is not really cutting it as the bloated iframe(s) just get loaded in on scroll. If you have multiple videos on a page or your visitors may not actually want to watch videos because they have already seen them ... loading=lazy is great for images but for iframe you need more than that.
sandbox can be used to completely disable any left clicks inside embeds, so clicking on stuff will not open new browser tabs. That is incredibly useful to not let video hosts lure your site visitors away. Right click will still work but its good enough.
Is (was) actually UNTRUE. The no-cookies URL last time I checked it should be doing it now, but I am too lazy right now. This STILL set cookies when people engaged with the embed, it just prevented automatically setting cookies and tracking with that just by loading the iframe.
Also, what about local-storage why in 2024 the talk is still about cookies? Local storage is the more modern API, and it seems many people fail to realize the all the stuff cookies do can be done with local storage and more.
Sucks but you have to play their game.
The embed doesn't achieve anything from a UX standpoint other than showing a preview thumbnail. I'd rather copy the thumbnail image, add that to the post and use a good old anchor link to the actual video.
/s
(Yes, I hate myself for making this comment, but it had to be said).
--
In fairness that spec was designed in a much more naive time, when open SMTP servers were commonplace, along with other things that would be a security red flag these days.
Also, “designed” may be too generous a word. Back then (~96/97?) web related things were being thrown together on a whim.
So it won't use my profile to load this ad-free with my subscription? Say what you want about premium subscriptions, but bypassing user preferences that mean they will see ads is not exactly a strong pushback against "enshittification".
In fact, most of the details here are only harm reduction if you strongly believe that YouTube will do anything the browser can do to harm users. I see little evidence of this. Yes there are ads, I know people hate ads, I get that. But not allowing access to the camera? YouTube obviously isn't using the camera, what is that achieving?
Pitching this as a generalised "hardened iframe" for untrusted content, sure! These are good things, and the allow spec should have a deny-all. But there's a lot of FUD in this with little to back it up for the case of YouTube, at least in my experience as a heavy user of the platform.
I'd suggest the best way to manage this is to provide your own “view directly in youtube” link with the embedded video, perhaps underneath, so your users get the embedded video minimal cruft by default but get the option of the fuller features if they have a youtube account and want to use things like adding to playlists.
Without auditing YT's code, it's not very obvious to me. But let's assume it doesn't; if/when it gets hacked, the injected malicious code might still want to use the camera.
Embedded players do not (currently) show adds, so no one would be losing that nicety using this method.
Another commenter points out it also means no watch-later, which is perhaps a more concrete example of the same problem – being logged out is a worse experience here for many.
Why aren't you using an adblocker? Even if you pay for youtube premium, the rest of the internet will still be inundated with ads. As an independent publisher of a site, I would care more about protecting my users' privacy than protecting youtube's business model.
> But not allowing access to the camera? YouTube obviously isn't using the camera, what is that achieving?
As the article says, you need to disallow every single permission individually because the spec has no "deny all" option. That's why there's also accelerometer, gamepad, payment, etc permissions in there.
Yes, and I agree that a deny-all option makes sense in general, but my point is that denying YouTube access to the camera seems nonsensical.
It betrays a bad-faith viewpoint that is in my opinion, one not based in evidence or experience. What is the threat model? I can't see one that makes sense in the context of YouTube being a large consumer product oriented company.
In the same way my apartment door is locked because it's the safe default, and not because my neighbors are known to be criminals.
[1]: https://en.wikipedia.org/wiki/Principle_of_least_privilege
Isn't it? How do you know for sure? It definitely isn't if you don't explicitly let it.
One possible use is browser fingerprinting and other such profiling. At a minimum the existence of a camera or not provides one bit of information for a fingerprinting data pool. I don't know if the relevant interface provides further information (camera capabilities like resolution, for instance), if it does then that would be useful for this purpose too.
Because my browser is not asking permission to access the camera? Sure enough the browser is made by the same company, but if you don't trust that how do you trust these permission flags? (Since they are also carried out, or not by the browser)
IIRC (I've not verified, so I may not RC!) you can see the presence of a camera (or permission to see one) without doing anything that will prompt the permission prompt.
> the browser is made by the same company
Chrome does not have 100% marketshare. Your browser might be made by the same company, the next person's may not be.
But you feel that that makes the argument for the flags even weaker? I choose to talk about Chrome because that is where the supposed argument can be the strongest (and they are still weak).