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

41–50 of 165 posts

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

#41

Post by Latty »

throwawayay02 wrote: post #34

I really dislike this notion of many internet companies of their own self-importance. To me the obvious example is a website that requires you to set up a very strong password and link a phone number. A user account is a two way street, the website should give you the tools for good protection, and you should use them if it matters. If it doesn't matter to me let me use a weak password. If it doesn't matter to me let…

Frankly, this is just wrong. Maybe for some circumstances, but in Google's case, they provide email.

When it comes to things like email, your account being compromised doesn't just affect you. Google let people send out emails from those accounts, so if a compromised account is used for spam, it hurts them reputationally as they are actively facilitating harm.

You might not care if that account is compromised, but they should.

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

#42

Post by bobbyi_settv »

throwawayay02 wrote: post #34

I really dislike this notion of many internet companies of their own self-importance. To me the obvious example is a website that requires you to set up a very strong password and link a phone number. A user account is a two way street, the website should give you the tools for good protection, and you should use them if it matters. If it doesn't matter to me let me use a weak password. If it doesn't matter to me let…

Even if you don't care if someone hacks your Google account, the rest of care when we start getting deluged with spam from that Gmail address.

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

#43

Post by joshspankit »

dleslie wrote: post #33
ath0 wrote: post #26

Earlier quoted context omitted.

OAuth tokens used in automation tools will continue to work. Entering in username & password through auth, to automate an OAuth flow (or any other traditionally manual flow) will stop working. Breaks some puppeteer scripts too - but those have been getting flaky for a while now.

Thus making it even more cumbersome for users; now they simply login, in the future they'll have to know how to get the oauth token.

And, OAuth tokens can be revoked meaning scripts will just suddenly fail.

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

#44

Post by AnthonyMouse »

xoa wrote: post #20
ivanche wrote: post #4

Next step: The browser must not be anything but Chrome.

> Next step: The browser must not be anything but Chrome. It seems like that'd be difficult without somehow dealing with Apple first, maybe by getting the government to force them to allow Chrome. Which could happen. Some of the "antitrust" stuff getting tossed around is already starting to get exploited by entities like advertisers, and not just big ones like Facebook, there were those EU ones recently. Like all pow…

> It seems like that'd be difficult without somehow dealing with Apple first, maybe by getting the government to force them to allow Chrome. Which could happen.

But that would also imply they'd have to allow Firefox, and Brave, and Tor Browser. Which would certainly be worth the "cost" of allowing Chrome.

> Some of the "antitrust" stuff getting tossed around is already starting to get exploited by entities like advertisers, and not just big ones like Facebook, there were those EU ones recently.

All political coalitions work like this. If you're against DMCA 1201 then commercial pirates will be on your side. That doesn't mean they're your friends. They're not, and in fact are costing your side goodwill, even if your side is right in the end.

> Like all power, Apple's focusing of its user's collective power can be used not just for bad stuff but for very good stuff as well. But that nuance doesn't seem to be present in a lot of the last year's discussions

Because it's true of anything. Dictatorships are a wonderful thing if you're the dictator's friends, but that's hardly making a strong case for dictatorship.

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

#45

Post by duskwuff »

dleslie wrote: post #25
delroth wrote: post #22

Earlier quoted context omitted.

> To protect our users from these types of attacks Google Account sign-ins from all embedded frameworks will be blocked starting on January 4, 2021. (emphasis mine) So I don't follow how this would have anything to do with banning youtube-dl, which doesn't require login? And as the blog post mentions, you can still bootstrap auth through a normal web browser, and pass the auth token to your command line / less secure…

Passing oauth tokens into automation tools is a common use case in order to automate the retrieval of account-restricted content.

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.

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

#46

Post by dmoy »

dleslie wrote: post #30
dmoy wrote: post #27

Earlier quoted context omitted.

What does that have to do with youtube-dl? (Sorry it's been like 5 years since I used it, I don't remember that being required)

It allows one to download private videos that your account can access.

So the theory is this has nothing to do with security, but is only used to break private video downloading of youtube-dl?

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

#47

Post by brokencode »

throwawayay02 wrote: post #34

I really dislike this notion of many internet companies of their own self-importance. To me the obvious example is a website that requires you to set up a very strong password and link a phone number. A user account is a two way street, the website should give you the tools for good protection, and you should use them if it matters. If it doesn't matter to me let me use a weak password. If it doesn't matter to me let…

1. Many uses are not computer experts and don’t realize they’re at risk. They won’t adopt extra security measures unless they need to.

2. No company wants to announce that a bunch of accounts were hacked. The excuse that “our users don’t care” would be widely criticized.

3. Well yes, of course companies want to reduce customer support costs, but guess who else benefits from not needing customer support? The customers. It’s better to avoid a problem in the first place than to have great mechanisms for resolving it.

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

#48

Post by detaro »

dleslie wrote: post #25
delroth wrote: post #22

Earlier quoted context omitted.

> To protect our users from these types of attacks Google Account sign-ins from all embedded frameworks will be blocked starting on January 4, 2021. (emphasis mine) So I don't follow how this would have anything to do with banning youtube-dl, which doesn't require login? And as the blog post mentions, you can still bootstrap auth through a normal web browser, and pass the auth token to your command line / less secure…

Passing oauth tokens into automation tools is a common use case in order to automate the retrieval of account-restricted content.

How does youtube-dl obtain the token today?

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

#49

Post by canofbars »

maest wrote: post #17
ivanche wrote: post #4

Next step: The browser must not be anything but Chrome.

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.

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

#50

Post by pitaj »

tinus_hn wrote: post #21
kwijibob wrote: post #8

I hate the smartphone app trend of having embedded browsers. Just launch me to my preferred real browser. Stop trying to trap us in your ecosystem.

Never mind carrying around 6 copies of Chrome on your phone

What are you talking about? Embedded browsers use the system webview, provided by Chrome, Firefox, or whatever is configured.
Post reply on HN