I agree. Unfortunately OAuth is impractical for this project, as it requires registering your application with Google.

Instead I've done my best to make clear how it works[0][1] and what is stored[2].

As mentioned in a sibling comment Google does not have a good track record with similar projects. AFAIK the only project that provides similar functionality is youtube-dl[3], which works the same way.

Important to note is that this functionality is optional; you do not need to log in with Google to store subscriptions or preferences. The main benefit currently is that it will automatically sync subscriptions with YouTube, otherwise I would recommend creating a new account on Invidious and then importing subscriptions from YouTube.

0. https://www.reddit.com/r/SideProject/comments/8wvazc/invidou...

1. https://github.com/omarroth/invidious/blob/8af87f1/src/invid...

2. https://invidio.us/privacy

3. https://github.com/ytdl-org/youtube-dl/blob/76e510b/youtube_...

There's no way for me to verify that what you're running is the same as what you have in GitHub. And for anyone else running it. You should disable this feature.

Why should he? It‘s your choice to use it or not. If you feel uncomfortable, go and selfhost it. Or don‘t use it at all. But there is no reasoning to prohibit it for everyone.

Altruistically, it trains users that it is ok, which it isn't.

Selfishly, the author really does not want to be storing or even handling these kinds of credentials. It makes them a very juicy target for all kinds of bad actors. Imagine finding yourself in the middle of some kind of account hijacking nightmare that you have unwittingly enabled, having to deal with people who trusted you and have lost access to their account or have lost money because people accessed data in their account that allows for id theft.

Basically people should treat passwords (even other people's passwords) as radioactive material and not attempt to handle them unless they really know what they're doing.

You didn't read https://invidio.us/privacy

The privacy policy of not storing passwords is nice but what about when they get hacked and the site starts uploading passwords to some attacker's website?

I am guessing that this service falls squarely into "prohibited by Google's AUP" and thus they don't have much of a choice. Either that or, to prevent clones like this one, Google has deliberately not exposed an API to do whatever this app needs to do.

Yep. Hooktube's been through this already.

https://hooktube.com/changelog

Giving a fake username and password results in

> Expected Array for #[]?(index : Int), not Int64

> Traceback:

> Getting lookup...done, returned 200.

> Getting challenge...done, returned 400.

So, yeah, nope. Why not use Google's SSO to connect accounts?

Google has a history of disabling oath for services like these. There is also an invidious account system you can use to avoid using your Google account.