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

61–70 of 165 posts

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

#61

Post by izacus »

worldmerge wrote: post #52
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.…

Well I guess my unofficial YouTube chat bot won't work anymore. The YouTube API is awful compared to the Twitch one for bot creation so it is easier to get the functionality you want using Selenium.

Why not? This restriction was added on Android years ago and it basically means that you retrieve the OAuth2 token with a normal browser and then send it to your automaton script/app.

It blocks auth to prevent phishing, not actual access.

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

#62

Post by dleslie »

duskwuff wrote: post #45
dleslie wrote: post #25

Earlier quoted context omitted.

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.

Which would break some common authentication options in ytdl:

https://github.com/ytdl-org/youtube-dl#authentication-option...

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

#64

Post by throwaway09223 »

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

It would be interesting to see this examined in the context of accessibility requirements created by the ADA.

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

#65

Post by ForHackernews »

nojito wrote: post #60
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.…

It's to stop scraping of Google Data. There is currently millions -> hundreds of millions being made by scraping Google content.

Kind of hypocritical given that Google's entire business is founded on scraping the rest of the internet.

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

#66

Post by dleslie »

dmoy wrote: post #46
dleslie wrote: post #30

Earlier quoted context omitted.

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?

It blocks misrepresentation of agent, in general; automation is also blocked in general, but _especially_ for authentication.

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

#69

Post by tinus_hn »

pitaj wrote: post #50
tinus_hn wrote: post #21

Earlier quoted context omitted.

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.

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

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

#70

Post by izacus »

jlokier wrote: post #36

Make sense for security. However, if just to login in some application, it would be awful UX if going to the login step in an application triggers an unwanted load of 3 desktops full of 20 browser windows and a few hundred tabs, and some minutes delay while they all start up. So if I'm not already running the "full browser" required for auth, ideally for authentication I'm going to want it to launch an "alternate pro…

On Android, there's a feature called Chrome Custom Tabs (despite the name, it works with other browsers as well) which basically opens the default browser window in a restricted UI without most of the chrome and tabs. It shares the state and extensions though and it's meant as a replacement for these exact banned flows (on Android, webview logins are banned for years now).

I wonder if such interface could be exposed for desktop browsers.

Post reply on HN