Adding a lazy, or going the extra mile of only loading a pure HTML div that is swapped by the iframe on click would be better to limit tracking. Do not load the iframe for people who don't want to play it.
There's more to it. Youtube's own embed is by itself harmful just due to the sheer size of it
- 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
funny, right? imagine how hard it is to get on that team that spits out that garbage embed - you probably need to answer how many golf balls fit in a bus and such and sweat leetcode level hard and then dump 1,3mb on user where 1kb would suffice
The main takeaway here should be to avoid YouTube embeds whenever possible. YouTube is way overused just to embed a video on a website. I'm baffled it's even commonplace on marketing homepages, why would you want YouTube's branding on your own brand's website?
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.
MP4 works fine, but different ways of creating/editing/preparing video all have different ideas about how to produce a video file, and the people operating them don't always have the technical background to even know there's a difference. YouTube offers a simple solution: drag any video file in any weird format to the upload modal, and you never have to think about it.
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.
Fair, but in my view if you have engineers implementing your marketing homepage they should be able to do this for you just like they write the HTML and CSS for you and figure out the deployment.
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.
Yeah, I've very recently had issues with mp4's only working on desktops/firefox/etc due to the wrong encoding or container or whatever not being supported. hvec vs mpeg-4 maybe? Had to mess with ffmpeg arguments multiple times to get it right. Meanwhile if you put it on youtube it will work 100% of the time.
>and yes, they have to be all set one by one, because there is no deny-all in the spec. No doubt this spec was designed with end-users' privacy and security in mind.
I can understand that, actually. deny all would be a forward compatibility nightmare
the problem comes when you decide to make a rule for something that was already possible before. let's say you have your deny-all set up becuase you want none of those. and then they add a rule for right clicking (just a silly example) and suddenly stuff breaks
Why would it be a compatibility issue? Every time one gets added it will presumably be added to this list. In fact once you get your embed working with some set of directives you want to say "I will never need more than this, deny anything new."
Is it not possible that they decide to add something as configurable that is currently allowed everywhere? As an analogy, when Apple decided to make the ID of a user opt-in.
There is a WordPress plugin that does some of these things and what lite-youtube-embed to all video embeds, no just YouTube. I own it I will communicate this to the author, and I am sure more of what is shown here will be added, I guess it's just to allow parameter and this insane list if it's really needed, still perplexed about this…
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.
" src set to www.youtube-nocookie.com instead of youtube.com. Both are official Google urls, but the former doesn't do tracking via cookies, and disables API and interaction and interaction logging. Amusingly, it's the player used on whitehouse.gov. "
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.
Is Google still able to find these for rich results? We tried one of the other things mentioned in this thread (youtube-lite) recently and Google delisted all of our detected videos as it recrawled us.
This is more work than it's worth, especially as the "no-cookie" domain could be deprecated or changed, leaving a bunch of broken embeds.
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.
It's nice that they have a free tier, but their pricing seems unattractive. Why use them when I could go with something like Bunny or Cloudflare that offer much better prices? Unless I'm misunderstanding something, Vimeo charges $20/month for what you could get on Bunny for $1/month.
Is the allow thing like this really true? I was under the impression that everything is disallowed by default, and you specifically have to allow it to work, hence the default embeds from YouTube and others having it on there.
> and yes, they have to be all set one by one, because there is no deny-all in the spec. No doubt this spec was designed with end-users' privacy and security in mind.
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.
> `credentialless` to load youtube in a blank disposable context, without access to the origin's network, cookies, and storage data.
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.
Fair point! I had thought I had seen ads in embedded players, but it might just have been spammy looking video thumbnails or something.
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.
> YouTube obviously isn't using the camera, what is that achieving?
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.
> But not allowing access to the camera? YouTube obviously isn't using the camera, what is that achieving?
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)
> Because my browser is not asking permission to access the camera?
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.
> 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).
Something in the options block the “view in youtube” links in the interface too, I thought it would but just checked to confirm, so you can't note it for future viewing that way either.
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.
> 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".
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.
> As the article says, you need to disallow every single permission individually because the spec has no "deny all" option
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.
"Provide videos with a supercharged focus on visual performance. This custom element renders just like the real thing but approximately 224× faster."
https://github.com/paulirish/lite-youtube-embed