Earlier quoted context omitted.
Or do this: 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.
Something like this lives or dies based on how much you annoy the people with lawyers to spare. Doesn't seem like the best plan.
Youtube.js – full-featured wrapper around YouTube's private API
91–100 of 113 posts
Re: Youtube.js – full-featured wrapper around YouTube's private API
#92This is really cool, but maybe the README's disclaimer should also warn that using YouTube's private APIs is against their Terms of Service[0], specifically this section: 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 YouT…
I don't see why YouTube would want to allow any of this; the APIs probably changes regularly, have documentation only available internally, and they can't attribute the use of these APIs to specific Client IDs for abuse (ie. bypassing rate limits by using these); this is not mentioning how there's $0 to gain from doing this, and it could actively cause them to lose money since the RIAA has DMCA'd even the mention of…
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.
Re: Youtube.js – full-featured wrapper around YouTube's private API
#93This is really cool, but maybe the README's disclaimer should also warn that using YouTube's private APIs is against their Terms of Service[0], specifically this section: 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 YouT…
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.)
Re: Youtube.js – full-featured wrapper around YouTube's private API
#94Earlier quoted context omitted.
I don't see why YouTube would want to allow any of this; the APIs probably changes regularly, have documentation only available internally, and they can't attribute the use of these APIs to specific Client IDs for abuse (ie. bypassing rate limits by using these); this is not mentioning how there's $0 to gain from doing this, and it could actively cause them to lose money since the RIAA has DMCA'd even the mention of…
> the APIs probably changes regularly 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.
Re: Youtube.js – full-featured wrapper around YouTube's private API
#95Earlier quoted context omitted.
> Not every application runs in the browser 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…
> We're going talking about running untrusted software on your computer, remember? 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 t…
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.
Re: Youtube.js – full-featured wrapper around YouTube's private API
#96If you’re YouTube or any site, and want to stop these sort of wrappers - what’s the easiest way to do so without breaking your own site? I find this task to be an interesting engineering problem. A related question is if there’s an unspoofable way to detect a client.
Seems like a use case for remote attestation.
Re: Youtube.js – full-featured wrapper around YouTube's private API
#97Earlier quoted context omitted.
> the APIs probably changes regularly 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.
as it happens, newpipe is currently broken
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.
Re: Youtube.js – full-featured wrapper around YouTube's private API
#98Earlier quoted context omitted.
I don't see why YouTube would want to allow any of this; the APIs probably changes regularly, have documentation only available internally, and they can't attribute the use of these APIs to specific Client IDs for abuse (ie. bypassing rate limits by using these); this is not mentioning how there's $0 to gain from doing this, and it could actively cause them to lose money since the RIAA has DMCA'd even the mention of…
> the APIs probably changes regularly 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.
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...
Re: Youtube.js – full-featured wrapper around YouTube's private API
#99Personally 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.
Re: Youtube.js – full-featured wrapper around YouTube's private API
#100Earlier quoted context omitted.
It probably wouldn't, because it would be clear that it's got nothing to do with Valve the gaming software company. Trademarks aren't blanket coverage of any possible uses of a name.
Not really, there are rigid categorisation of trademarks (Nice Classification). All software is in Class 42 ( https://www.wipo.int/classifications/nice/nclpub/en/fr/?basi... ) so Valve would actually have standing here. PS: Nice here refers to the French town (compare to Berne Convention, Geneva Convention, Treaty of Paris), not the common meaning in English.