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

121–130 of 165 posts

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

#121

Post by u801e »

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

> his has nothing to do with security and everything to do with banning tools like youtube-dl, wget and others

Exactly. What's insecure about an application that can establish a secure connection using an accepted version of TLS and cipher?

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

#122

Post by kiwidrew »

gitweb wrote: post #117
Aldipower wrote: post #78

This is a campaign against Lynx! > The browser must have JavaScript enabled. > You must confirm that your browser does not contain any of the following: > * Text-based browsers Once upon a time the internet was TCP with things like FTP, Email, Newsgroups, IRC and yes also HTTP (aka WWW). Now, the internet seems to be Google, Apple, Facebook aaand SEO. Hey, wait! There is a small shiny place!! Hackernews! :)

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.

How can a prohibition on "text-based browsers" have anything to do with MitM attacks? The browser's chosen rendering method (text or GUI) is irrelevant.

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

#123

Post by ogurechny »

Welcome to Google's private World Wide Web. Please ensure that you use the one and only official Google WWW client (others exist, but they are just for show). Unauthorized alteration of its configured operation will result in user termination.

One might wonder how that can accompany all the talk about open standards, and multitude of devices implementing different subsets, and responsive/adaptive/semantic design, etc. Then you realize that you don't really need, say, user-agent sniffing if you are already in position to dictate what browsers will and will not do, so into the trash it goes. You don't need interoperability hacks if you've stopped having interoperability problems.

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

#124

Post by 9HZZRfNlpR »

delroth wrote: post #22
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.…

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

Definetly not on the right side of the history. With all the social changes and uprises we see one would expect you to do better.

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

#126

Post by Dylan16807 »

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.

They can spit out a url for you to copy into a normal browser, then.

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

#127

Post by marcan_42 »

tinus_hn wrote: post #69
pitaj wrote: post #50

Earlier quoted context omitted.

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

Sure, Chrome on iOS is ‘only’ a 118 mb application! And much of that is also in Google Maps, the Google Docs apps etc.

Chrome on iOS isn't even a real thing, it's just an app embedding Safari like every other app with a webview (because Apple's draconian policies forbid alternate browser engines). All the other Google apps also have to use Safari for any web stuff.

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

#128

Post by MereInterest »

jakelazaroff wrote: post #31
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.

Are embedded browsers not usually just the system webview?

They might hide the URL, so I can't see where the link led me. Or they might disable the usual browser menu, preventing me from bookmarking a page. Or they might have the "close tab" interaction be in a completely different location, breaking any muscle memory.

If I'm following an HTTP(S) link, it means that I want to view it in a browser. I don't want to have some in-app view that can only return me to gmail, or to discord, or to google handouts, just because that happened to be where I clicked the link from. I don't care in the slightest whether the rendering engine is the same as the default browser. I care whether the user interactions are the same.

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

#129

Post by MereInterest »

npsimons wrote: post #37
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 identify itself clearly in the User-Agent. I wonder what they'd think of my proxy which I have setup to (among other privacy respecting features) rewrite the User-Agent to "By allowing me access, you waive all rights and policies regarding my access." This is basically my form of EULA. > The browser must not provide automation features. LOL. This was obviously written by some tech illiterate law ty…

Yeah, the browser itself is an automation feature. It automates the downloading of a file over HTTP, downloading of any dependent resources, managing of caches, and rendering of the result. That these are so frequently done that this automated pipeline is referred to as "a browser" doesn't mean that this isn't an extremely automated system.

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

#130

Post by phendrenad2 »

Google is becoming increasingly user-hostile, which is the wrong business phase to be in while your competition is on the rise. Other email providers are (finally!) getting almost as good as Gmail. Bing is an okay substitute for Google Search. YouTube has been strangled by subservience to advertisers and people are moving to Twitch and other places.
Post reply on HN