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

131–140 of 165 posts

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

#131

Post by jlokier »

pjc50 wrote: post #80
izacus wrote: post #77

Earlier quoted context omitted.

You'll need to find another provider which doesn't care that much about preventing phishing attacks. Google accounts are a big target so it makes sense you move away from the masses.

In practice it just means faking the user-agent and other fingerprinting more enthusiastically. I'm not sure how google can win that without resorting to the same anti-cheat measures as games companies.

You'll try, but the first time you won't know what fingerprinting tests they are going to do. After a few iterations you'll succeed, but it will be obvious to Google that the account you've just been testing it on belongs to someone trying to break their auth restrictions...

Good luck keeping your account!

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

#132

Post by d99kris »

jhasse wrote: post #5

What does this mean for IMAP?

It was recently (Oct 8) announced that that Google would provide a 12-month heads-up for stopping less secure app access, so it's my understanding that IMAP is not affected at this point.

https://workspaceupdates.googleblog.com/2020/03/less-secure-...

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

#133

Post by scrollaway »

joshspankit wrote: post #43
dleslie wrote: post #33

Earlier quoted context omitted.

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.

What's your point? Passwords can change and sessions can get invalidated, which all has the same effect.

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

#134

Post by olliej »

The only reason chrome isn’t mandatory is that there are still a few hold out browsers they can’t force out of the market.

Also, the requirement that the browser not lie about its identity in the UA means that the existing UA tests that google properties deploy everywhere means that those “acceptable” browsers may still be “accidentally” blocked.

It would be nice if people would start to acknowledge that chrome is the new IE and Google is the new MS.

Actually arguably worse: in addition to using free services subsidized by their primary advertising business. Once that business is gone they start charging.

All the while they grossly destroy user privacy, and come up with new specs that just happen to accidentally make tracking users easier. Generally poorly thought out ones to help single teams at google without any thought of what the general problem is.

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

#135

Post by austincheney »

dleslie wrote: post #10

This has nothing to do with security and everything to do with banning tools like youtube-dl, wget and others; from the post: > The browser must identify itself clearly in the User-Agent. The browser must not try to impersonate another browser like Chrome or Firefox. > The browser must not provide automation features. This includes scripts that automate keystrokes or clicks, especially to perform automatic sign-ins.…

> The browser must not provide automation features. This includes scripts that automate keystrokes or clicks, especially to perform automatic sign-ins.

If a web developer knows what they are doing they are using the standard web APIs supplied by the browser in an efficient way, designed to be invisible to accessibility for accessibility test automation, and thus this control from Google is largely unenforceable. As such I believe this is just a block against incompetent forms of automation that probably shouldn't be there in the first place.

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

#136

Post by austincheney »

heavyset_go wrote: post #2

Anti-trust action can't come fast enough.

Most of these controls are a blessing. They are blocking gross incompetence from front-end developers who don't know ow to do their jobs. I say this as a front-end developer.

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

#137

Post by devit »

I fail to see how they can possibly do this in a way that isn't trivially worked around by just embedding the same code as the full browser.

I guess their best bets are detecting non-fullscreen screen sizes on mobile, requiring Widevine or requiring Chrome and adding some proprietary authentication code, but all these are problematic and can be worked around.

Also of course both Firefox and Chrome support automation via WebDriver and WebExtensions so not quite sure what they plan to do with "The browser must not provide automation features".

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

#138

Post by athenot »

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.

Even worse when the embedded web view is not properly detecting the user-agent and puts up a banner... prompting you to download the app (looking at you, NHL).

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

#139

Post by smlckz »

If browsers which does "server-side rendering" are blocked from accessing my Google Account, I lose my access to all Google services requiring sign-in like Gmail etc.

I don't have the privilege to own a desktop, laptop, or even smartphone. I am using a J2ME enabled feature phone with Opera Mini to access the internet. Most websites requiring "modern browsers" are out of reach from me. Thanks to all the people who maintain the websites that are functional without JS or upto ES5.1 (last JS version supported by Opera's server rendering powered by Presto) or less. Only Google Search and Gmail works in Opera Mini, other Google services don't.

So I am out of luck! Anyone out of luck like me?

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

#140

Post by ashneo76 »

smlckz wrote: post #139

If browsers which does "server-side rendering" are blocked from accessing my Google Account, I lose my access to all Google services requiring sign-in like Gmail etc. I don't have the privilege to own a desktop, laptop, or even smartphone. I am using a J2ME enabled feature phone with Opera Mini to access the internet. Most websites requiring "modern browsers" are out of reach from me. Thanks to all the people who mai…

Is it possible to de Google?? Google provides no value other than a few email address
Post reply on HN