[HN Gopher] Google to block less secure browsers and applications
___________________________________________________________________
Google to block less secure browsers and applications
Author : mattmein
Score : 94 points
Date : 2020-11-21 21:04 UTC (1 hours ago)
(HTM) web link (developers.googleblog.com)
(TXT) w3m dump (developers.googleblog.com)
| ivanche wrote:
| Next step: The browser must not be anything but Chrome.
| bxk1 wrote:
| This is pretty much the current step already, not the next
| step, with broad ban on anything that isn't a lot like Chrome
| and anything that they simply don't want to allow. In the last
| thread the narrative was hijacked with bullshit "security"
| justification, while in the blog post they ban much more
| broadly, any automation, text-based browsers, etc.
| bpodgursky wrote:
| No way. (Theoretically on Android, but let's be real, they
| won't).
|
| No way they are giving up marketshare on Safari or on corporate
| boxes with IE. They've paid so much to get onto iPhones,
| there's not a chance they'd risk any marketshare erosion.
| gtirloni wrote:
| Please stop spreading FUD on HN.
| maest wrote:
| 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.
| canofbars wrote:
| They don't need anything other than firefox or safari. All
| new browsers could be blocked as they are unknown/untrusted.
| xoa wrote:
| > _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 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, and of course lobbyists will use the opportunity
| if they can.
|
| Without that though or another big disruptive shift Apple
| misses, can even Google afford to give up on the entire iOS
| market? Even the Mac market perhaps, if Apple really wanted to
| push back against Google there they've certainly got the
| potential capability.
|
| Restricting to just Chrome/Safari(Apple webkit) would still be
| really bad though. Even if they still allow Firefox, that would
| further formalize just 3 browsers with minimal further
| experimentation still possible. That'd be a real shame.
| AnthonyMouse wrote:
| > 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.
| hedora wrote:
| I briefly hoped this would apply to search and ad serving as
| well.
|
| Sadly, no.
|
| I'd happily set my user agent string to Mozilla 1.0 if it stopped
| all that stuff from working.
| jhasse wrote:
| What does this mean for IMAP?
| duskwuff wrote:
| Nothing. IMAP doesn't use the web signin form that these
| changes apply to.
| gtirloni wrote:
| Not much. If you're not using app passwords and your client
| wants to authenticate using Google auth (e.g. Thunderbird), it
| has to open the user's browser and setup the oauth flows
| instead of embedding the browser directly in the app.
| unixsheikh wrote:
| I'm glad I neither use Google nor YouTube! Security.. riiight!
| etaioinshrdlu wrote:
| How does this mesh with their plans to deprecate User-Agent?
| https://9to5google.com/2020/01/14/google-deprecate-chrome-us...
| indymike wrote:
| This reads like Google is trying to eliminate browsers that don't
| have a user attached to them. Good luck with that.
| kwijibob wrote:
| 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.
| tinus_hn wrote:
| Never mind carrying around 6 copies of Chrome on your phone
| pitaj wrote:
| What are you talking about? Embedded browsers use the system
| webview, provided by Chrome, Firefox, or whatever is
| configured.
| tinus_hn wrote:
| Sure, Chrome on iOS is 'only' a 118 mb application! And
| much of that is also in Google Maps, the Google Docs apps
| etc.
| whereistimbo wrote:
| Recent version of Android reverts the default webview to
| Android System WebView again.
| jakelazaroff wrote:
| Are embedded browsers not usually just the system webview?
| canofbars wrote:
| Yes but how would you even know as a user. Or how would you
| know that you are on the real google page.
| LockAndLol wrote:
| If you don't like that google does this: stop using their
| products. Make the effort to choose, use and promote a service
| you think is doing a better job. If you so deem it necessary,
| tell Google why you're switching.
|
| If people actually did something instead of just complain,
| companies like this would think pretty hard about their actions
| since it would harm their bottom line.
| Aldipower wrote:
| 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! :)
| dleslie wrote:
| 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.
| worldmerge wrote:
| 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.
| izacus wrote:
| 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.
| DevKoala wrote:
| Pretty much. It also helps their ad business to combat fraud.
| nojito wrote:
| It's to stop scraping of Google Data.
|
| There is currently millions -> hundreds of millions being made
| by scraping Google content.
| ForHackernews wrote:
| Kind of hypocritical given that Google's entire business is
| founded on scraping the rest of the internet.
| throwaway09223 wrote:
| "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.
| scrollaway wrote:
| If you'd bothered to read a little more before knee-jerking a
| reaction comment, you'd know this is only for the
| authentication flow.
| pjc50 wrote:
| And? What if I want to automate my login flow?
| izacus wrote:
| 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.
| pjc50 wrote:
| 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.
| dleslie wrote:
| I did read that; did you know that passing oauth tokens into
| such automation tools is commonplace?
| ath0 wrote:
| 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.
| dleslie wrote:
| 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.
| detaro wrote:
| It's OAuth. The application can launch a normal browser
| for the OAuth flow and have the user complete it.
| bxk1 wrote:
| For plenty of applications the whole purpose is not to
| run "a normal browser" and possibly not even have it
| installed.
| detaro wrote:
| You can also use a browser on a different device.
| joshspankit wrote:
| And, OAuth tokens can be revoked meaning scripts will
| just suddenly fail.
| delroth wrote:
| > 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 browser / ... app.
|
| (Disclaimer: I work at Google, not on anything related to this
| blog post or to your hypothetical scenario.)
| dleslie wrote:
| Passing oauth tokens into automation tools is a common use
| case in order to automate the retrieval of account-restricted
| content.
| dmoy wrote:
| 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)
| dleslie wrote:
| It allows one to download private videos that your
| account can access.
| joshspankit wrote:
| 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)
| dmoy wrote:
| So the theory is this has nothing to do with security,
| but is only used to break private video downloading of
| youtube-dl?
| dleslie wrote:
| It blocks misrepresentation of agent, in general;
| automation is also blocked in general, but _especially_
| for authentication.
| mulmen wrote:
| There's an ocean between required and useful.
| duskwuff wrote:
| 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.
| dleslie wrote:
| Which would break some common authentication options in
| ytdl:
|
| https://github.com/ytdl-org/youtube-dl#authentication-
| option...
| tester756 wrote:
| Let's dont act as if the whole world was trying to fight
| against ytdl.
| detaro wrote:
| How does youtube-dl obtain the token today?
| dleslie wrote:
| https://github.com/ytdl-org/youtube-dl#authentication-
| option...
|
| Username, Password, 2FA, etc.
| detaro wrote:
| And you claim that doing more to stop people from giving
| their google account password to "random apps" (I
| personally trust youtube-dl a lot too, but "random apps"
| is what it comes down to) and forcing those apps to use
| OAuth to obtain scoped tokens has "nothing to do with
| security"?
| dleslie wrote:
| If that were all that they were doing I might agree; but
| they are blocking browser identity misrepresentation and
| automation, as well; it also requires that all "browsers"
| have a complete implementation of web standards.
|
| It explicitly blocks "headless" browsers.
|
| > You must confirm that your browser does not contain any
| of the following:
|
| > Headless browsers
|
| > Node.js
|
| > Text-based browsers
| pjc50 wrote:
| Security for whom? Locking the user out of the software
| they want to use is not improving security for _them_.
| detaro wrote:
| That's only true if you assume the user is perfectly
| capable of evaluating the trustworthiness and quality of
| the software they want to use. It's understandable that
| that's not the assumption Google designs their security
| under. Yes, that sometimes somewhat sucks for us power
| users.
| [deleted]
| mrjin wrote:
| Google has went rouge for quite a while. AMP was another
| example of the same nature.
| npsimons wrote:
| > 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
| type, perhaps a first year law student? I fear to think what
| incompetent engineer working at google of all places would have
| come up with that verbiage . . .
| userbinator wrote:
| It has everything to do with security: securing _Google 's
| control_.
|
| Google wants to take over the Internet. We should not let it
| use these "less secure" excuses to sway the public opinion.
| samuelroth wrote:
| Google's control...over the security of Google accounts?
|
| If you are worried enough about Google's dominance over the
| Internet to be upset by this particular practice, it is
| unlikely you have (or should maintain) a Google account.
|
| I'm not a "Google stan" by any means, but to say that they
| want to take over the Internet is just not true.
| dvfjsdhgfv wrote:
| > to say that they want to take over the Internet is just
| not true.
|
| I don't know if they "want", but they already do have
| control over various aspects of the Internet, especially of
| the web, but also DNS and email.
| haunter wrote:
| Hope that doesn't kill ungoogled-chromium
| skee0083 wrote:
| Will iOS mail app still work?
| IshKebab wrote:
| This presumably means they are banning Chrome Lite?
| vaccinator wrote:
| Google already blocks me from my account all the time because
| they don't recognize my device because of privacy settings...
| wwwigham wrote:
| I feel like detecting these environments is directly at odds with
| user privacy and anti-tracking; but I guess google has never been
| anti-tracking, so that's not too surprising. Still, I'm
| incredibly disappointed that they'd essentially require clients
| be fingerprintable to auth. I feel like this is just codifying an
| arms race between strengthening requirements and JS environment
| checks, and hostile embedders ability to emulate a real runtime,
| and taking legitimate embedders with less incentive to
| participate in the race down as collateral damage.
| Sniffnoy wrote:
| So, uh, does this mean I won't be able to use IMAP with Gmail
| anymore...? It already complains at me about this for being less
| secure than webmail, but that doesn't seem to be covered in this
| announcement.
| swiley wrote:
| Dear god I'm glad I got my crap off of google.
| uniqueid wrote:
| Same here. It's like I made a sharp, long-term investment. As
| the months pass, I enjoy the payoff: watching Google get worse
| and worse without it touching my life.
| throwawayay02 wrote:
| 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 someone hack my account,
| what do I care. And if the user doesn't care why does the website
| owner? Why should hackernews care more about my user account than
| myself for example? It could be argued this position of security
| maximalism is due to cutting costs on customer support, for
| account recovery, but as I understand it Google doesn't have
| customer support already.
| Latty wrote:
| 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.
| bobbyi_settv wrote:
| 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.
| brokencode wrote:
| 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.
| swiley wrote:
| The problem is that you _have_ to have an account on google
| to participate in a number of communities. Because of this
| they have social scaling problems that might be fundamentally
| unsolvable and in their attempt to find a solution they 've
| done things like this.
| jlokier wrote:
| 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 profile" instance of my full browser which doesn't
| include all the other tabs or normal user info.
|
| I.e. the browser should somehow be able to load just one special
| window for this application, and remember that it hasn't actually
| loaded my regular profile and saved state yet.
|
| Clicking on any links for info that is logically "outside the
| application", that's what should probably lead to a regular full
| browser being started.
|
| In the end, this ideal browser behaviour in response to an
| application requesting Google auth is much the same as using an
| embedded web view - except running separately from the
| application for security purposes so that it's UI isn't subject
| to application interference.
|
| Given that's just a web view with security properties, why not
| instead allow auth to launch a "security instance" version of an
| embedded web view, one that is subject to guarantees from the
| OS/GUI security systems that it is running independently from the
| application which triggered its launch?
| izacus wrote:
| 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.
| heavyset_go wrote:
| Anti-trust action can't come fast enough.
| dageshi wrote:
| 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.
| gostsamo wrote:
| Once upon a time Google had "don't be evil" in their
| corporate mission and people trusted them to act in good
| faith. Good old times.
| Ygg2 wrote:
| Now it's "Do the right thing (for corporate)"(tm).
|
| How times have changed.
| cm2187 wrote:
| They just got some friends elected. Wouldn't count too much on
| the DOJ being impolite with big tech the next 4 years.
| Denvercoder9 wrote:
| Previously on HN: https://news.ycombinator.com/item?id=25155451
___________________________________________________________________
(page generated 2020-11-21 23:00 UTC)