←back to thread

439 points Leftium | 3 comments | | HN request time: 0.02s | source
Show context
molticrystal ◴[] No.45306399[source]
The claim that Google secretly wants YouTube downloaders to work doesn't hold up. Their focus is on delivering videos across a vast range of devices without breaking playback(and even that is blurring[0]), not enabling downloads.

If you dive into the yt-dlp source code, you see the insane complexity of calculations needed to download a video. There is code to handle nsig checks, internal YouTube API quirks, and constant obfuscation that makes it a nightmare(and the maintainers heroes) to keep up. Google frequently rejects download attempts, blocks certain devices or access methods, and breaks techniques that yt-dlp relies on.

Half the battle is working around attempts by Google to make ads unblockable, and the other half is working around their attempts to shut down downloaders. The idea of a "gray market ecosystem" they tacitly approve ignores how aggressively they tweak their systems to make downloading as unreliable as possible. If Google wanted downloaders to thrive, they wouldn't make developers jump through these hoops. Just look at the yt-dlp issue tracker overflowing with reports of broken functionality. There are no secret nods, handshakes, or other winks, as Google begins to care less and less about compatibility, the doors will close. For example, there is already a secret header used for authenticating that you are using the Google version of Chrome browser [1] [2] that will probably be expanded.

[0] Ask HN: Does anyone else notice YouTube causing 100% CPU usage and stattering? https://news.ycombinator.com/item?id=45301499

[1] Chrome's hidden X-Browser-Validation header reverse engineered https://news.ycombinator.com/item?id=44527739

[2] https://github.com/dsekz/chrome-x-browser-validation-header

replies(14): >>45306431 #>>45307288 #>>45308312 #>>45308891 #>>45309570 #>>45309738 #>>45310615 #>>45310619 #>>45310847 #>>45311126 #>>45311155 #>>45311160 #>>45311645 #>>45313122 #
1. guerrilla ◴[] No.45309570[source]
> If you dive into the yt-dlp source code, you see the insane complexity of calculations needed to download a video. There is code to handle nsig checks, internal YouTube API quirks, and constant obfuscation that makes it a nightmare(and the maintainers heroes) to keep up. Google frequently rejects download attempts, blocks certain devices or access methods, and breaks techniques that yt-dlp relies on.

This just made me incredibly grateful for the people who do this kind of work. I have no idea who writes all the uBlock Origin filters either, but blessed be the angels, long may their stay in heaven be.

I'm pretty confident I could figure it out eventually but let's be honest, the chance that I'd ever actually invest that much time and energy is approximates zero close enough that we can just say it's flat nil.

Maybe Santa Claus needs to make some donations tonight. ho ho ho

replies(2): >>45309786 #>>45310667 #
2. imiric ◴[] No.45310667[source]
As the web devolves further, the only viable long-term solution will be allow lists instead of block lists. There is too much hostility online—from websites that want to track you and monetize your data and attention, SEO scams and generated content, and an ever-increasing army of bots—that it's becoming infeasible to maintain rules to filter all of it out. It's much easier to write rules for traffic you approve of, although they will have to be more personal than block lists.
replies(1): >>45311246 #
3. drnick1 ◴[] No.45311246[source]
This is more or less what I already do with uBlock/uMatrix. By default, I filter out ALL third party content on every website, and manually allow CDNs and other legitimate third party domains. I still use DNS blacklists however so that mobile devices where this can't be easily done benefit from some protection against the most common offenders (Google Analytics, Facebook Pixel, etc.)