Live data from Hacker News

Guidance to developers affected by effort to block less secure browsers, apps

developers.googleblog.com

161–165 of 165 posts

Re: Guidance to developers affected by effort to block less secure browsers, apps

#161

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.

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.

Re: Guidance to developers affected by effort to block less secure browsers, apps

#162

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

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.

Re: Guidance to developers affected by effort to block less secure browsers, apps

#163

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

Also fair point.

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

#164
post #99

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

Sure:

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

#165
post #117

Earlier 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 agree that the post is not very well written, but if you are a bit generous you can read them saying "phishing sites are doing MITM attacks that we have a very hard time distinguishing from CEF logins, so we are axing CEF logins altogether".

I'm appalled of the general direction Google is pushing the web to (an AD haven), but some of their points make sense.

Post reply on HN