61–70 of 113 posts
Earlier quoted context omitted.
They should rename it to Innertube.js (which is the official name of the private API, and as far as I know not trademarked not used in any user-facing resources).
Valve.js would also work, since it allows access to the innertube.
Earlier quoted context omitted.
They should rename it to Innertube.js (which is the official name of the private API, and as far as I know not trademarked not used in any user-facing resources).
Valve.js would also work, since it allows access to the innertube.
Earlier quoted context omitted.
Valve.js would also work, since it allows access to the innertube.
I would advise against this on pure UX grounds due to the existence of Valve the game software company.
Cool project but I wonder if the name will catch flak from the lawyers. Trademarks and all that. At they very least a big "This is not affiliated with Google/Youtube" seems like a wise precaution.
Cool project but I wonder if the name will catch flak from the lawyers. Trademarks and all that. At they very least a big "This is not affiliated with Google/Youtube" seems like a wise precaution.
are you people seriously under the impression that trademarks and such make any difference if a big US corporation wants to fuck you? they can sue you out of existence for violating laws you aren't subject to and/or EULA you've never agreed to
Earlier quoted context omitted.
Valve.js would also work, since it allows access to the innertube.
And that would totally not infringe on anything else, right.
Cool project but I wonder if the name will catch flak from the lawyers. Trademarks and all that. At they very least a big "This is not affiliated with Google/Youtube" seems like a wise precaution.
are you people seriously under the impression that trademarks and such make any difference if a big US corporation wants to fuck you? they can sue you out of existence for violating laws you aren't subject to and/or EULA you've never agreed to
I've been wanting to use the Youtube Music API to automate some personal chores (like building/cleaning playlists, etc) and was very discouraged. I actually switched to Spotify (trial) partially over it but there were a couple of other (off-topic) reasons I didn't want to stay with Spotify. This looks like a wonderful tool! And it's not in Python :-D (sorry python people). Like others I'm a little concerned about bre…
Ths drove me nuts because Google Music had an actual public API. The service was deprecated in favor of YT Music, which has less features and no equivalent API. That deprecation was a catalyst to move my music collection elsewhere, so it's not threatened by the whims of Google anymore.
I'm always nervous about 3rd party API wrappers. It's basically saying "Here's the keys to my (users) Google account, please don't do anything bad". Even if it's open source, there's no guarantee there's no malicious change in version x.x.N+1
You could just pin to a version like a good dev and rid yourself of the problem. 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.
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.