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

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

developers.googleblog.com

Post reply on HN
Print view View original

81–90 of 165 posts

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

#81

Post by detaro »

pjc50 wrote: post #79
detaro wrote: post #74

Earlier quoted context omitted.

And you claim that doing more to stop people from giving their google account password to "random apps" (I personally trust youtube-dl a lot too, but "random apps" is what it comes down to) and forcing those apps to use OAuth to obtain scoped tokens has "nothing to do with security"?

Security for whom? Locking the user out of the software they want to use is not improving security for them .

That's only true if you assume the user is perfectly capable of evaluating the trustworthiness and quality of the software they want to use. It's understandable that that's not the assumption Google designs their security under. Yes, that sometimes somewhat sucks for us power users.

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

#83

Post by detaro »

bxk1 wrote: post #54
detaro wrote: post #51

Earlier quoted context omitted.

It's OAuth. The application can launch a normal browser for the OAuth flow and have the user complete it.

For plenty of applications the whole purpose is not to run "a normal browser" and possibly not even have it installed.

You can also use a browser on a different device if your thing can't run a browser itself. OAuth covers a large space of options.

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

#84

Post by wwwigham »

I feel like detecting these environments is directly at odds with user privacy and anti-tracking; but I guess google has never been anti-tracking, so that's not too surprising. Still, I'm incredibly disappointed that they'd essentially require clients be fingerprintable to auth. I feel like this is just codifying an arms race between strengthening requirements and JS environment checks, and hostile embedders ability to emulate a real runtime, and taking legitimate embedders with less incentive to participate in the race down as collateral damage.

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

#85

Post by dvfjsdhgfv »

samuelroth wrote: post #56
userbinator wrote: post #38

Earlier quoted context omitted.

It has everything to do with security: securing Google's control . Google wants to take over the Internet. We should not let it use these "less secure" excuses to sway the public opinion.

Google’s control...over the security of Google accounts? If you are worried enough about Google’s dominance over the Internet to be upset by this particular practice, it is unlikely you have (or should maintain) a Google account. I’m not a “Google stan” by any means, but to say that they want to take over the Internet is just not true.

> to say that they want to take over the Internet is just not true.

I don't know if they "want", but they already do have control over various aspects of the Internet, especially of the web, but also DNS and email.

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

#87

Post by tester756 »

dleslie wrote: post #62
duskwuff wrote: post #45

Earlier quoted context omitted.

Which would still be fine. The only thing that'd be blocked is obtaining those OAuth tokens by passing your Google username/password to a browser automation tool.

Which would break some common authentication options in ytdl: https://github.com/ytdl-org/youtube-dl#authentication-option...

Let's dont act as if the whole world was trying to fight against ytdl.

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

#88

Post by edoceo »

canofbars wrote: post #49
maest wrote: post #17

Earlier quoted context omitted.

They need non-Chrome browsers to exist, to avoid accusations of a monopoly. Chromium is arguably a strategy around this, where you can have a bunch of browsers using the same (Google controlled) infrastructure. Safari is an exception, since Apple won't accept giving that up in their products.

They don't need anything other than firefox or safari. All new browsers could be blocked as they are unknown/untrusted.

And if you want to build a new one - you cannot test against a very common use case.

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

#89

Post by worik »

dleslie wrote: post #62
duskwuff wrote: post #45

Earlier quoted context omitted.

Which would still be fine. The only thing that'd be blocked is obtaining those OAuth tokens by passing your Google username/password to a browser automation tool.

Which would break some common authentication options in ytdl: https://github.com/ytdl-org/youtube-dl#authentication-option...

It is not the whole world attacking ytdl - but Google, definitely.

Evil by default?

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

#90

Post by dleslie »

tester756 wrote: post #87
dleslie wrote: post #62

Earlier quoted context omitted.

Which would break some common authentication options in ytdl: https://github.com/ytdl-org/youtube-dl#authentication-option...

Let's dont act as if the whole world was trying to fight against ytdl.

It's not just about ytdl; this policy will ban all headless browsers, text-based browsers, and browsers with automation tools.
Post reply on HN