The following restrictions apply to your use of the Service. You are not allowed to:
(...)
3. access the Service using any automated means (such as robots, botnets or scrapers) except (a) in the case of public search engines, in accordance with YouTube’s robots.txt file; or (b) with YouTube’s prior written permission;
I'd go as far to say routinely. A massive pain point for third party youtube apps like newpipe which break every few months due to it.
To be fair, building products with Google APIs is also risky. Google used to offer a YouTube API for free. People like me used it for personal use. Then one day Google unilaterally decided to discontinue it.^1 There are other examples of APIs that Google has changed or deprecated then discontinued.
1. To me, this is the great disadvantage of "web APIs". A "web API" is like a non-public version of a public website that the operator can easily limit access to or shut down at any time, without affecting the public website. Arguably the public-facing website is more difficult and less likely to suddenly change or shut down than a "web API". Given a choice between retrieving public data/information from a "web API" versus from the pages of a public website (or wherever the pages source their contents), I prefer the later.
Building any sort of web-based business dependent on some irreplaceable third party, such as Google, is risky.^2 When the third party makes a decision that affects someone else's dependent business, there is usually nothing the business owner can do. We see stories about this on HN from time to time. This is a control issue, folks. It is what happens when people voluntarily cede control to a third party intermediary.
2. Is it worth the risk? That is another question.
One difference between something like this free JS library on Github and an "official" Google API is that we can edit and adapt the JS library if the structure or content of YouTube's video page template changes, whereas if a YouTube API is changed or discontinued, we can do nothing. (Except complain, which rarely ever results in an API being restored.)
There used to be a free YouTube API. I had scripts that used it. Today I use the video page's HTML and JSON, not an API. (I more or less make an API for myself.) Unlike the script I once used with YouTube's API that is now useless, the script I use today keep working for the long-term. I have only had to change it twice in the last decade. These were very small changes that only took a short time to fix. (It seems like folks wait much longer for fixes to youtube-dl.)
This is more likely to break (be broken by google) than an official API, and those are bad enough. (hard pass on even trying this out, especially if it's good/nice I'll want to use it and kick myself later for being an idiot.)
Other than that, I fully agree that you should try to minimize your dependence on them, it’s not good a good position to be in; what’s in the best interest for YouTube today may not be the case in one year.
I find this task to be an interesting engineering problem.
A related question is if there’s an unspoofable way to detect a client.
That said, I wouldn't be surprised if Google issues a C&D, or just inevitably breaks it, especially if it uses undocumented APIs.
1. Install NodeJS and NPM (if you don't already have it)
2. Create a new folder
3. Run "npm install youtubei.js@latest" in that folder
4. Create a new file in this folder called ytdl.js (or whatever you like)
5. See section "Downloading videos:" on the github page. Make the contents of the file exactly like that. i.e. just cut/paste that example.
6. Replace line 'Looking for life on Mars - documentary' with the name of the youtube video you want to download (ideally this should come from args)
7. Run "node ytdl.js" and it should download Do I need an API key to use this?
No, YouTube.js does not use any official API so no API keys are required.Unrelated: My treadmill has the absolute worst YT client I've ever used.
This library also doesn't give you the dislikes anymore (just tested it).
[0] https://support.google.com/youtube/thread/134791097/update-t...
[1] https://github.com/Anarios/return-youtube-dislike#what-it-do...
This looks like a wonderful tool! And it's not in Python :-D (sorry python people). Like others I'm a little concerned about breakage as youtube APIs churn. Does anyone know what Youtube's approach to backwards compatibility is for internal APIs? Some companies just wait until 98% of user's are on the new clients and then rip stuff out, but others I've worked with basically don't allow breaking the API except in important circumstances and they stick around deprecated for a while.
That deprecation was a catalyst to move my music collection elsewhere, so it's not threatened by the whims of Google anymore.
/s
And they ban any accounts with matching recovery or verification phone numbers and email addresses too, or part of the same gsuite domain.
For example, some 6min show that goes on live french TV everyday got flagged and requires login to be viewed, for age reason.
Maybe there was curse words, or some butt-shaped thing in it?
Personally I'm using Firebase's private API because the public API is missing a couple of features. Currently I just regularly extract my Google cookies from Firefox and use those. But an easy login that grants access to the private API would be cleaner of course.
Just do a quick diff check when you upgrade. If you're too lazy to do that then you never really cared about security all that much in the first place.
Good devs don't keep up with dependencies' security updates or was this meant ironically?
Also, you'd have to pin to a hash, I imagine. Changing the version tag and pushing with -f doesn't sound like rocket science for someone with malice in mind. Next time you deploy it, you'll still get that code.
It might be this API wrapper or it might be any other dependency. It might even be the scientific calculator you installed that had nothing to do with that project.
What makes this especially scary?
The difference is that it's trivial for this developer to insert a backdoor to steal Google credentials since they know exactly how and where the oauth tokens are located. It's significantly harder for e.g. a webpack developer to insert a backdoor to steal Google credentials since they would have to first determine the code it's processing is handling oauth tokens and then figure out where they are stored.
The barrier to entry is the key in assessing your threat model. 3 letter agencies may not care about the cost if the target is valuable but a bored kid on the other side of the world will give up pretty quickly.
1. Release it as youtube.js for the name recognition
2. Wait for the certified letter
3. Announce you're renaming your project and get another 24 hours of exposure in the news
This guy is playing the game.
https://github.com/LuanRT/YouTube.js#disclaimer
edit: why am i getting downvoted?
My advice to avoid any negative attention from YT/Google (but again IANAL) would be to do two things:
1. Move the "this is an unofficial" disclaimer at the top and bold and/or italic it so it's totally unmissable. I would use the same approach as MarshallOfSound: https://github.com/MarshallOfSound/Google-Play-Music-Desktop...
2. Praise Youtube/Google for having such a great API that empowers and enables their users to get the most out of their subscription. Make sure to point out the (true) benefits that YT gets from having a library like this that is available but they don't have to maintain and promise nothing to.
Overall though, I would seriously ask why? Anti-cheat for a game maybe? It will cost you time/money to prevent, and it will hurt people that like your product enough to hack on it. As a user who rejoices in having APIs I can use to automate products I like, I'd be far more likely to pay you if you have an API I can use.
Found it:
https://moderncrypto.org/mail-archive/messaging/2014/000780....
If it's running in a browser, Google can simply disallow those domains to make API calls.
Also, at least Apple will block apps that make unauthorized API calls to third parties.
There are CORS rules, but those are enforced by the browser, a backend cannot prevent you from calling it, except by requiring an access token or something similar.
I suppose you can have a system which works like TOTP except for machine-to-machine. Although it would probably be broken since anything on the client side can be disassembled. The UX would likely suffer as a result as well.
I once saw a certificate-based implementation once where the server issued a temporary x509 cert to the client and then used mTLS[1]. It did reduce "unauthorized" clients by raising the bar, but it ended up making life way harder for their devs and the people they really wanted to stop just implemented the cert strategy and moved on.
[1]: https://freedomben.medium.com/what-is-mtls-and-how-does-it-w...
At that point anyone writing a library like this would need to actually pull in the rendered page on which the user is supposed to be navigated, scrape the field names off of that (which won't be easy), and only _then_ could they perform the form action.
But if you're a big enough site, someone will likely still take the time to do it.
Or only serve videos if they detect some kind of physical input(mouse/keyboard)
But they don't seem to care that much for non-mainstream tools, or this would be blocked already
For small scale sites it's definitely not easy to block
They may be some paid libraries that promises to do it, but I've never seen one that seemed really unbreakable
Even if you go all the way and block EVERY possible way of doing this, you can make a puppeteer script that could watch and record sound/video directly on the screen in like 15 lines of code, even if it would be really slow to get long videos
If you serve content, put it behind a paywall and rate-limit based on the maximum amount a human can reasonably consume and stop caring whether the user uses your own client or something like this - after all you’re getting paid either way.
The only businesses that are threatened by unofficial API clients are cancerous “growth and engagement” crap where the “value” is the wasting of the user’s time. Don’t be such a business and you’ll be fine.
I'm definitely curious if there's a way to do a rotation that resists easy automatic code analysis.
Anyone know if other websites put as much effort into anti-adblock engineering?
you'd basically have to make your own stealthy video format, otherwise you can just catch network requests
Once you’ve defeated obfuscation you’ll be dealing with DOM integrity-based defenses.
Coincidentally today is maybe the third time I've went to watch something and it's been broken. It's annoying yes, but soooo much less annoying that constant ads. It's a minor pain point that is easily solved by temporarily switching back to regular youtube.. by the time I've seen a few ads I'm more annoyed at the regular experience and NewPipe probably has a fix out by then anyway.
After all, youtube runs on millions of client devices which can't or won't update the client application. Eg. Android devices with google play broken or logged out. Forcing those users to update in many cases will lose a user. A 5+ year old phone's copy of youtube still runs and plays videos.
Now the API's that the website uses... those can be updated with nearly zero notice...
I have been playing around with NewPipe SponsorBlock. It has its flaws but generally seems to work. I have not seen it mentioned but NewPipe SB also supports Soundcloud, Bandcamp and PeerTube instances. I think it includes FramaSoft's and CCC's PeerTube instances as presets. It is interesting how smoothly PeerTube seems to work.
I would not rely on NewPipe for downloading or playing YouTube videos, even when it is "fixed", but the app does much more than just those two things.
So does all the malware: your browser's cookie store
We're talking about YouTube in this thread.
> any injected frontend js would have to bypass browser's sandboxing to steal another domain's cookies i.e. a zero day which is beyond your threat model
Where did this random unrelated attack vector come from? We're going talking about running untrusted software on your computer, remember? That's the attack vector we're discussing.
Your point was "malware in random unrelated software won't know where to look for my YouTube session key", my response was "it will".
You are talking about running untrusted software on your computer. This thread is about the "youtubei.js" npm package that is acting as a wrapper around YouTube's API.
My point is it's trivial for this developer to add additional code to `youtube.signIn(creds)` that I'm calling vs. any developer of one of my dependency to inject code to steal the same creds. If it's frontend code, their injected code cannot execute beyond mydomain.com. If it's backend code, their injected code would have to guess how my application works. I guess they can trivially dump my env variables but that's about it.
Ultimately, it's still (somewhat) harder for you to steal credentials from injecting code into my app vs I explicitly calling your code with the credentials.
Since you cannot use youtube.js in a browser (because it's not supported & because of CORS checks would fail), we can only be talking about 'backend' code here.
Thus the comparison has to be with other backend dependencies and software running on your computer/servers.
PS: Nice here refers to the French town (compare to Berne Convention, Geneva Convention, Treaty of Paris), not the common meaning in English.