Live data from Hacker News

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

developers.googleblog.com

91–100 of 165 posts

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

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

Pretty much. It also helps their ad business to combat fraud.

This is probably the only case that actually affects them. There's really no argument for security here.

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

#93
post #5

What does this mean for IMAP?

If you have "less secure apps" you can still use password. Going forward G is pushing use of XOAUTH2 for IMAP auth.

There was some noise from the PHP group because the imap_* functions don't do XOAUTH2 (but Net_IMAP and Zend IMAP libs do the trick)

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

#94
post #7

Anti-trust action can't come fast enough.

Once upon a time Google would've been applauded for forcing people to improve their security. Like when they made https a ranking factor for sites and overnight forced all the laggards to move off http. Now, people just scream "monopoly" at everything google does, good or bad and boy is it getting tedious.

It's almost like people have rose tinted glasses and opinions can change when a company has repeatedly abused it's position more than a handful of times.

Wow, it's really a shocker people could be upset. There comes a point where using a blanket term "security" to define uncompetitive behavior is called covering. They want to ensure ads cannot be blocked with manifest v3, they want to ensure DNS cannot be blocked by ad blockers, they cannot let you use any browser that isn't pre-approved so they can force you to be unable to block their ads. They'll define new web standards to help themselves and break the web.

Google isn't doing this for security, they're doing it to keep their ad market dominance and force customers to be required to use only approved browsers. Also when did JS being enabled become a hard requirement for the web as a standard?

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

#96
> The browser must have a reasonably complete implementation of web standards and browser features. You must confirm that your browser does not contain any of the following:

  - Headless browsers
  - Node.js
  - Text-based browsers
Yeah... This has nothing to do with "standards or security".

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

#97
post #7

Anti-trust action can't come fast enough.

Once upon a time Google would've been applauded for forcing people to improve their security. Like when they made https a ranking factor for sites and overnight forced all the laggards to move off http. Now, people just scream "monopoly" at everything google does, good or bad and boy is it getting tedious.

They are not improving security, just making it more difficult to scrape google, who ironically is 100% based around scraping and living off other peoples content and creations in general.

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

#99
post #30

Earlier quoted context omitted.

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

Such as: - I have a script that downloads my liked videos (in case they get deleted, which I’ve found out happens a fair bit) - I also have a script to download my watch later videos (for sync to devices without YouTube Premium/Red/whatever)

Would you share those scripts?

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

#100
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.

So they're breaking mountains of automated test and scripting tools? Nice to know.

>Headless browsers locked out (thanks for nreaking test automation) >Node.js (riiight) >Text-based browsers (Going aft Lynx? Of all things?) >JavaScript MUST be enabled

Totally not a power grab here folks. Totally not a company known to value reaping user data in any form possible up to any kind of user hostile behavior, or exercising undue influence over the character of the Net.

Nope, no siree, Bob. Moving riiiight along.

Post reply on HN