Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Youtube.js – full-featured wrapper around YouTube's private API

github.com

Post reply on HN
Print view View original

81–90 of 113 posts

Re: Youtube.js – full-featured wrapper around YouTube's private API

#81

Post by vosper »

zinekeller wrote: post #76
vosper wrote: post #66

Earlier 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.

Thanks for pointing that out

Re: Youtube.js – full-featured wrapper around YouTube's private API

#82

Post by tedunangst »

tptacek wrote: post #72
endisneigh wrote: post #10

If 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.

Youtube in particular sort of famously had content protection code, which took in part the form of a VM implemented in Javascript that probed its runtime to detect non-browser or otherwise headless clients. I think Mike Hearn worked on it. Found it: https://moderncrypto.org/mail-archive/messaging/2014/000780....

There doesn't seem to be a whole lot in there on YouTube js obfuscation techniques?

Re: Youtube.js – full-featured wrapper around YouTube's private API

#83

Post by binarynate »

This 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 YouTube’s robots.txt file; or (b) with YouTube’s prior written permission;
It would be great if YouTube updated their ToS to permit this because that could unlock some really interesting innovation. Until then, devs should at least be aware that building a product with these APIs is risky.

[0]: https://www.youtube.com/static?template=terms

Re: Youtube.js – full-featured wrapper around YouTube's private API

#84

Post by trinovantes »

cmeacham98 wrote: post #80
trinovantes wrote: post #39

Earlier quoted context omitted.

Technically nothing can be trusted e.g. can anyone trust their silicon, wires, device drivers, compilers, OS, routers, SSL CAs, etc.? Trust has to happen at some point. 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…

> 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 So does all the malware: your browser's cookie store

Not every application runs in the browser i.e. not SPA and 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

Re: Youtube.js – full-featured wrapper around YouTube's private API

#85

Post by cmeacham98 »

trinovantes wrote: post #84
cmeacham98 wrote: post #80

Earlier quoted context omitted.

> 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 So does all the malware: your browser's cookie store

Not every application runs in the browser i.e. not SPA and 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

> 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.

Your point was "malware in random unrelated software won't know where to look for my YouTube session key", my response was "it will".

Re: Youtube.js – full-featured wrapper around YouTube's private API

#86

Post by trinovantes »

cmeacham98 wrote: post #85
trinovantes wrote: post #84

Earlier quoted context omitted.

Not every application runs in the browser i.e. not SPA and 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

> 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 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.

Re: Youtube.js – full-featured wrapper around YouTube's private API

#87

Post by kadoban »

______-_-______ wrote: post #60
wvenable wrote: post #45

Earlier quoted context omitted.

They should immediately rename it so as not to be caught the way YouTube Vanced was. A disclaimer is not a sufficient response to trademark issues.

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.

Re: Youtube.js – full-featured wrapper around YouTube's private API

#88

Post by judge2020 »

binarynate wrote: post #83

This 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 downloading music videos from YT[0]. If they wanted to introduce any more functionality to the API, they'll simply add it to the official API and extend the docs[1].

0: https://news.ycombinator.com/item?id=24872911

1: https://developers.google.com/youtube/v3/docs

Re: Youtube.js – full-featured wrapper around YouTube's private API

#89

Post by oefrha »

comprev wrote: post #24
samisupset wrote: post #13

Earlier quoted context omitted.

Keep changing the implementation, keep changing names, keep changing the API formats. I'm definitely curious if there's a way to do a rotation that resists easy automatic code analysis.

Facebook does something similar to combat adblockers. They mangle the names of div elements to make sponsored posts indistinguishable from friends/group posts. I'm not aware of any browser plugins which are effective at blocking FB ads. Anyone know if other websites put as much effort into anti-adblock engineering?

A vision (ML)-based blocker should easily blow rigid rule-based cosmetic blockers out of the water and render div soup obfuscation completely useless. Not sure anyone’s investing in that space though.

Once you’ve defeated obfuscation you’ll be dealing with DOM integrity-based defenses.

Post reply on HN