Earlier quoted context omitted.
And, OAuth tokens can be revoked meaning scripts will just suddenly fail.
What's your point? Passwords can change and sessions can get invalidated, which all has the same effect.
Guidance to developers affected by effort to block less secure browsers, apps
161–165 of 165 posts
Re: Guidance to developers affected by effort to block less secure browsers, apps
#162Earlier quoted context omitted.
What's your point? Passwords can change and sessions can get invalidated, which all has the same effect.
Yes I would agree with that, except that if you change a password you know the scripts will fail, but if an OAuth token gets invalidated by the system and not you, then it will fail without warning.
What makes you say oauth tokens are any less robust? Aside from the fact they usually have an expiration attached to them, there's not much difference.
Re: Guidance to developers affected by effort to block less secure browsers, apps
#163Earlier quoted context omitted.
Yes I would agree with that, except that if you change a password you know the scripts will fail, but if an OAuth token gets invalidated by the system and not you, then it will fail without warning.
And if your password gets reset by the system and not you, same story. What makes you say oauth tokens are any less robust? Aside from the fact they usually have an expiration attached to them, there's not much difference.
What makes me say that? Experience.
However, I will say to counter my own point: it’s not all roses. Using password by necessity means that your password is now stored somewhere that is likely more easily compromised (In my case: secure passwords are stored in 1Password, but passwords for script usage are either stored in an ENV or in the script itself, neither of which are great from a security standpoint)
Re: Guidance to developers affected by effort to block less secure browsers, apps
#164Earlier quoted context omitted.
Such as: - I have a script that downloads my liked videos (in case they get deleted, which I’ve found out happens a fair bit) - I also have a script to download my watch later videos (for sync to devices without YouTube Premium/Red/whatever)
Would you share those scripts?
```bash
# !/bin/sh
cd /media/youtube-dl
docker-compose run --rm youtube-dl -v --cookies /etc/youtube-dl.cookies.txt https://www.youtube.com/playlist?list=INSERTYOUROWNWATCHLATE... -o "watchlater/%(title)s-%(id)s.%(ext)s" --ignore-errors
```
That’s a bash script that runs via cron. One thing to note: this uses the cookies from a logged-in browser session because at some point YouTube blocked password log in from youtube-dl. This was is a bit of a pain to set up, and I wish it was not the case, but it mostly works.
Re: Guidance to developers affected by effort to block less secure browsers, apps
#165Earlier quoted context omitted.
This is regarding man-in-the-middle attacks. There is not attack on Lynx. Many sites do not functionin without JavaScript. Sad, but that's the way it is.
Google is actually misrepresenting the danger in their blogpost, because they write "One form of phishing, known as man-in-the-middle,..." - this statement is clearly false because MITM is not phishing. Not in any stretch of the definition. So who knows what is the real justification.
I'm appalled of the general direction Google is pushing the web to (an AD haven), but some of their points make sense.