Starting January 4 Google will block sign-ins from embedded browser frameworks(lists.webkit.org)
lists.webkit.org
Starting January 4 Google will block sign-ins from embedded browser frameworks
https://lists.webkit.org/pipermail/webkit-dev/2020-November/031604.html
196 comments
The intention here is that users don’t enter their password into an embedded web view where the host application can inject JS or otherwise sniff the password/session cookie. (or just phish them). That’s a good thing. A new standalone browser should be a separate case. Hopefully.
In an ideal world the Android/iOS framework would enforce that an insecure embedded webview has a distinguishing User-Agent or some other tell that Google can check. A standalone browser wouldn’t have that and in theory wouldn’t be caught up by Google’s enforcement of this. That’s how it should work, but it unclear to me if that’ll actually happen.
In an ideal world the Android/iOS framework would enforce that an insecure embedded webview has a distinguishing User-Agent or some other tell that Google can check. A standalone browser wouldn’t have that and in theory wouldn’t be caught up by Google’s enforcement of this. That’s how it should work, but it unclear to me if that’ll actually happen.
> A new standalone browser should be a separate case.
Right, but what are the chances google will allow people to sign up with their own user agent with their new browser engine? Or even if that was a feasible thing for them to do, why should _they_ be able to gatekeep that? The security argument is valid, but there should be some web standard or something to address that, not google deciding who gets to read their email depending on the browser they use.
Right, but what are the chances google will allow people to sign up with their own user agent with their new browser engine? Or even if that was a feasible thing for them to do, why should _they_ be able to gatekeep that? The security argument is valid, but there should be some web standard or something to address that, not google deciding who gets to read their email depending on the browser they use.
It's tricky. Although this is being justified with references to phishing (which may well be the case) it's also an issue for spambots that need to sign in to a Google account in order to e.g. post spam links to YouTube comments.
If you think about it, you'll quickly end up in a briar patch of confusion over what exactly the definition of a "browser" is. Google have attempted to provide a definition here which is better than most, but it's basically a subtractive definition. A browser is a thing that supports "modern web standards" whilst not supporting automation features. OK. What about extensions?
The intent is to ensure that only people can sign in when they understand which site they're on. If anyone can define any program as a browser you can't enforce that and would have to allow unlimited automation of web sites. That is too hard to do, purely server side content analysis algorithms don't get you far enough, hence CAPTCHAs and now this JavaScript based enforcement.
If you think about it, you'll quickly end up in a briar patch of confusion over what exactly the definition of a "browser" is. Google have attempted to provide a definition here which is better than most, but it's basically a subtractive definition. A browser is a thing that supports "modern web standards" whilst not supporting automation features. OK. What about extensions?
The intent is to ensure that only people can sign in when they understand which site they're on. If anyone can define any program as a browser you can't enforce that and would have to allow unlimited automation of web sites. That is too hard to do, purely server side content analysis algorithms don't get you far enough, hence CAPTCHAs and now this JavaScript based enforcement.
>spambots that need to sign in to a Google account in order to e.g. post spam links to YouTube comments.
Wouldn't sign up be a better enforcement point than sign in?
Wouldn't sign up be a better enforcement point than sign in?
The same system is enforced on sign up too, but the spam market is split between account creators/sellers and account users. So you need it everywhere.
Do you need it everywhere? Why can't you just cut off the sellers?
Because of the asymmetry of use. Signing up takes a small amount of human labor, and there's already several sellers of fake accounts who use cheap human labor to create them. If actually sending spam would require human labor too, spamming would not be as desirable.
(For the record: I vehemently disagree with the idea of dictating what browsers are allowed to use an online service.)
(For the record: I vehemently disagree with the idea of dictating what browsers are allowed to use an online service.)
The issue also affects Electron-based browsers, something I wouldn't consider "embedded". These are a few browsers affected off the top of my head:
- Beaker https://github.com/beakerbrowser/beaker/issues/1749
- Min https://github.com/minbrowser/min/issues/868
- Agregore https://github.com/AgregoreWeb/agregore-browser/issues/65
From what I can tell, it's really any browser not well known by Google.
- Beaker https://github.com/beakerbrowser/beaker/issues/1749
- Min https://github.com/minbrowser/min/issues/868
- Agregore https://github.com/AgregoreWeb/agregore-browser/issues/65
From what I can tell, it's really any browser not well known by Google.
The actual problem seems to be the UA string requirement (from the OP, at least).
If he removes the UA spoofing, all Google sites break because Google use this to determine if they run their services (which is incredibly weird to me).
If he doesn't, then his browser is banned. Somewhat of a double bind.
The most charitable explanation here is that Google is a megacorp now, and the right hand and left hand are on different continents and aren't aware of each others existence.
If he removes the UA spoofing, all Google sites break because Google use this to determine if they run their services (which is incredibly weird to me).
If he doesn't, then his browser is banned. Somewhat of a double bind.
The most charitable explanation here is that Google is a megacorp now, and the right hand and left hand are on different continents and aren't aware of each others existence.
You're right that the issue described in the OP is more specific. However, I believe its a symptom of the larger, underlying problem.
Google shouldn't wield the power to decide which browsers are worthy enough to access the larger internet they have control over. It's antithetical to the open web.
Google shouldn't wield the power to decide which browsers are worthy enough to access the larger internet they have control over. It's antithetical to the open web.
Google isn't restricting other/embedded browsers from the rest of the internet, Google is restricting them from its own sign-in page.
Google literally has the keys to a kingdom. Should Google's box ever be opened, countries will burn. Let's face it, the definition of a monopoly is insufficient on a global scale.
Merely restricting their own sign-in service impacts over 1.5 billion people. Of course, most are unaffected.
Merely restricting their own sign-in service impacts over 1.5 billion people. Of course, most are unaffected.
Even Firefox has experimented with UA spoofing on Android because Google offers a severely downgraded experience even though the browser would technically support the same site that Chrome gets. So in the limited set of a dozen or so extensions for Firefox mobile, there is one that adopts the Google UA... The list was manually selected by Mozilla so you know their opinion on this.
Worth noting that Google's browser, Chrome, spoofs Firefox and Safari.
Are they likely to whitelist Electron (and React Native and other major webapp-as-native-app frameworks)? Or will those apps be forced to boot you out to the browser, and then back to the app?
I think I've already seen one app that did that to me. It was clunky and broke the illusion that the app was native -- though I guess that's a pretty thin illusion anyway.
I think I've already seen one app that did that to me. It was clunky and broke the illusion that the app was native -- though I guess that's a pretty thin illusion anyway.
Does Google provide any non-Web APIs ?
ChromeOS also lets you sign-in into Google via an embedded browser view when you login to the device.
Though I guess Google will probably exempt themselves from this policy...
Though I guess Google will probably exempt themselves from this policy...
In an ideal world we would have settled on an authentication protocol which everyone could support. Something like "oidc://idp-url" which the OS could have a built-in handler for.
Hmm, how it is different from OpenID that Google currently uses?
At least on my Android device, OIDC sign ins are handled by the default browser, not a purpose-built application.
This is not a security feature. This is smoke and mirrors. If it was really about securing the web, Google would made IETF and W3C recommendations, instead of trying to kill competition. This is strictly market grabbing and anti competitive
[deleted]
"The intention"
Stated intention. Unless you can read minds.
Stated intention. Unless you can read minds.
From Google:
“The browser must identify itself clearly in the User-Agent. The browser must not try to impersonate another browser like Chrome or Firefox.”
Which is a bit funny considering that Chrome impersonates Mozilla, Safari, and Gecko! (As do all browsers)
Chrome’s User-Agent for reference:
“Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36”
Spoofing other browsers is a long standing tradition. Funny to see Google trying to forbid it. Here’s a great history on User-Agents: https://webaim.org/blog/user-agent-string-history/
“The browser must identify itself clearly in the User-Agent. The browser must not try to impersonate another browser like Chrome or Firefox.”
Which is a bit funny considering that Chrome impersonates Mozilla, Safari, and Gecko! (As do all browsers)
Chrome’s User-Agent for reference:
“Mozilla/5.0 (Macintosh; Intel Mac OS X 11_0_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36”
Spoofing other browsers is a long standing tradition. Funny to see Google trying to forbid it. Here’s a great history on User-Agents: https://webaim.org/blog/user-agent-string-history/
Furthermore, wasn't Google talking about phasing out and replacing user-agent strings? User-agent leaks data and is somewhat fingerprintable, so the idea was to further genericise Chrome UA strings and adopt a new standard for sharing data about the client.
Found an article: https://www.zdnet.com/article/google-to-phase-out-user-agent...
Found an article: https://www.zdnet.com/article/google-to-phase-out-user-agent...
Using privacy.resistFingerprinting in Firefox on a Mac makes it appear like an other browser version of Firefox, on another OS (Windows).
And you forgot Konqueror with the KHTML engine.
This doesn't really surprise me?
I've found apps launching login screens in their own embedded browser windows difficult to verify aren't phishing, since they usually don't even show a URL bar, and obviously, could fake it.
I can't say I disagree with the expectation you launch a real browser for OAuth purposes, though it's key they support all real general purpose web browsers.
I've found apps launching login screens in their own embedded browser windows difficult to verify aren't phishing, since they usually don't even show a URL bar, and obviously, could fake it.
I can't say I disagree with the expectation you launch a real browser for OAuth purposes, though it's key they support all real general purpose web browsers.
They don't even need to fake the URL bar. A malicious app can steal your password from the real login page if it's in its embedded browser.
There's another scenario that matters here: an ordinary phishing website. Yes, about 15-20% of users never look at the URL bar and will type their password into any site that looks like the login screen regardless of how obviously bogus the URL is.
However, the server-side code for the phish now has a problem. The user may be protected by two-factor authentication. To handle that case, the PHP script or whatever needs to step through the login process in the same way a browser would. Google have tech that can make it very, very hard for this PHP script to do that (it's called BotGuard). So the next move is that the phishing site needs to use an embedded browser to try and evade BotGuard's detections. Then it can obtain the necessary codes to trigger the 2-step verification challenge and intercept the number sent to the user's phone, and finally complete the login to obtain session cookies before storing them and redirecting the user to the real google website (so they don't suspect anything).
There are ways BotGuard can detect embedded browsers apparently, as they specifically say they will ban CEF and embedded internet explorer. But if you do that then people who use the embedding features to make their own browsers are out of luck. It's really tricky because it's hard to see how you can get critical mass for a new browser if you're limited to OAuth (which is meant for APIs). You'd have to get in touch with Google somehow and ask them to whitelist your browser. If they're sharp and fast about that even for new or hobby browsers then maybe this won't be so bad. If they get jammed up in product management bureaucracy and don't whitelist browsers fast enough, it could turn into an anti-trust issue for them.
However, the server-side code for the phish now has a problem. The user may be protected by two-factor authentication. To handle that case, the PHP script or whatever needs to step through the login process in the same way a browser would. Google have tech that can make it very, very hard for this PHP script to do that (it's called BotGuard). So the next move is that the phishing site needs to use an embedded browser to try and evade BotGuard's detections. Then it can obtain the necessary codes to trigger the 2-step verification challenge and intercept the number sent to the user's phone, and finally complete the login to obtain session cookies before storing them and redirecting the user to the real google website (so they don't suspect anything).
There are ways BotGuard can detect embedded browsers apparently, as they specifically say they will ban CEF and embedded internet explorer. But if you do that then people who use the embedding features to make their own browsers are out of luck. It's really tricky because it's hard to see how you can get critical mass for a new browser if you're limited to OAuth (which is meant for APIs). You'd have to get in touch with Google somehow and ask them to whitelist your browser. If they're sharp and fast about that even for new or hobby browsers then maybe this won't be so bad. If they get jammed up in product management bureaucracy and don't whitelist browsers fast enough, it could turn into an anti-trust issue for them.
Yeah, this is ironically why I can't use in-app payments on Android; it prompts a Google Play login overlay and there's no way to verify that I'm looking at a legitimate request from the Play store and not a counterfeit from the app itself.
I thought the entire phone would already logged in, such that no overlay is required. You describe it as being different. Do I misunderstand how Android account handling works?
Payments on Google Play require password or biometric authentication for completion. It's a very weird design inconsistency, since the login prompt looks nothing like a typical Google login prompt.
FWIW, Google announced they'd be doing this April of last year. Their reasons for it are security based, and make sense to me: https://security.googleblog.com/2019/04/better-protection-ag...
It seemed like they were planning to enforce it a long time ago. Perhaps they let the deadline slip to give developers more chance to adapt.
It seemed like they were planning to enforce it a long time ago. Perhaps they let the deadline slip to give developers more chance to adapt.
> Their reasons for it are security based, and make sense to me
Preventing legitimate users that use different browsers is not good behaviour. One company shouldn't be able to control the web this way.
If they wanted to add a warning about a particular security issue in a browser, OK, but this blocks them outright.
You'll also know that you have fight captchas in Firefox, but rarely in Chrome. It's not right!
Preventing legitimate users that use different browsers is not good behaviour. One company shouldn't be able to control the web this way.
If they wanted to add a warning about a particular security issue in a browser, OK, but this blocks them outright.
You'll also know that you have fight captchas in Firefox, but rarely in Chrome. It's not right!
If you read the article, you'd know they're blocking all embedded browser frameworks, including CEF. Embedded chrome has the same security risks. This isn't a partisan policy, nor is punting responsibility to the end user to make decisions always better. Even as an educated engineer, you have no way of evaluating whether that embedded browser is doing something nefarious with your login data or not unless it's open source, which few mobile apps are. Non-actionable warnings are meaningless.
> Non-actionable warnings are meaningless.
Agreed. Yet that’s exactly what they’re trying to make use of here.
“The browser must not try to impersonate another browser like Chrome or Firefox.”
Agreed. Yet that’s exactly what they’re trying to make use of here.
“The browser must not try to impersonate another browser like Chrome or Firefox.”
But again, there's a double-bind here.
Option 1: Remove UA spoofing, presumably Google will allow sign-in. However, Youtube and Gmail won't work.
Option 2: Keep the UA spoofing, lose ability to sign in to Google.
There's literally no way to comply.
This is super, super anti-competitive, and I guess I'll have to figure out which MEP/Commission person I need to complain to (as they appear to be the only regulator likely to care).
Option 1: Remove UA spoofing, presumably Google will allow sign-in. However, Youtube and Gmail won't work.
Option 2: Keep the UA spoofing, lose ability to sign in to Google.
There's literally no way to comply.
This is super, super anti-competitive, and I guess I'll have to figure out which MEP/Commission person I need to complain to (as they appear to be the only regulator likely to care).
> Preventing legitimate users that use different browsers is not good behaviour. One company shouldn't be able to control the web this way.
They're talking about their own services that they require accounts for here, not "the web", or even general search, AFAICT. You can still use google, you just can't log in using an app they aren't sure is trusted, for user security. Google goes a great many problematic things these days, but I'm not sure this is one of them.
You could keep a trusted browser around and use it just for authenticating and getting a token. That's all they care about here, that they have a certain base level of assurance that you aren't being directed through an application that can steal credentials.
They're talking about their own services that they require accounts for here, not "the web", or even general search, AFAICT. You can still use google, you just can't log in using an app they aren't sure is trusted, for user security. Google goes a great many problematic things these days, but I'm not sure this is one of them.
You could keep a trusted browser around and use it just for authenticating and getting a token. That's all they care about here, that they have a certain base level of assurance that you aren't being directed through an application that can steal credentials.
> you just can't log in using an app they aren't sure is trusted, for user security
s/app/browser, though.
Effectively and strongly kneecapping any new browser competition.
s/app/browser, though.
Effectively and strongly kneecapping any new browser competition.
I mean app in the traditional sense, application. It's apps (almost) all the way down. ;)
And any new browser competition has been kneecapped in that way by recaptcha for a long time already. You either deal with the web being less convenient because you've opted somewhat out of the easy path presented you (like I do, with Firefox and many container tabs), or you don't use Google services, or accept the easy path of Chrome and Google services together.
We're talking about convenience here. Google makes it convenient and more secure (from others) to use their applications and services together. I'm not going to begrudge them making something harder to do it a way they think is worse for them as a company as long as they still leave it possible. That's better than you'll get from Apple.
And any new browser competition has been kneecapped in that way by recaptcha for a long time already. You either deal with the web being less convenient because you've opted somewhat out of the easy path presented you (like I do, with Firefox and many container tabs), or you don't use Google services, or accept the easy path of Chrome and Google services together.
We're talking about convenience here. Google makes it convenient and more secure (from others) to use their applications and services together. I'm not going to begrudge them making something harder to do it a way they think is worse for them as a company as long as they still leave it possible. That's better than you'll get from Apple.
> Even if WebKit is not blocked, we can be confident January 4 will be a sad day for browser diversity
This is true, I hate that this is true, and I hate that there's very little to be done about it.
I use Firefox for ideological reasons, and last week got off my ass and ensured all my documents (from Dropbox), music (from Google Music / now the inferior YT Music) and photos (from Google Photos) were stored in a way I could control. My plan going forward is to use an old laptop running Syncthing as my primary source of truth for files. Email is next (but more complicated since I don't want to self-host it).
It helps me personally to take Stallmanesque approaches to managing my digital life. And if Google continues to get more and more restrictive I have the technical acumen to find or make alternatives—or figure out how to do without. But I'm worried about the growing number of non-technical users who are increasingly dependent on technology and—startlingly—increasingly less technical. People who only use Google Docs on their phone and a laptop have no reason to understand that documents correspond to files on disk that can be edited by programs running locally.
It more and more seems like the future is tech oligopoly with more and more subscription fees. What else could happen once a generation has been trained to only use Approved Tools running on Approved Servers?
This is true, I hate that this is true, and I hate that there's very little to be done about it.
I use Firefox for ideological reasons, and last week got off my ass and ensured all my documents (from Dropbox), music (from Google Music / now the inferior YT Music) and photos (from Google Photos) were stored in a way I could control. My plan going forward is to use an old laptop running Syncthing as my primary source of truth for files. Email is next (but more complicated since I don't want to self-host it).
It helps me personally to take Stallmanesque approaches to managing my digital life. And if Google continues to get more and more restrictive I have the technical acumen to find or make alternatives—or figure out how to do without. But I'm worried about the growing number of non-technical users who are increasingly dependent on technology and—startlingly—increasingly less technical. People who only use Google Docs on their phone and a laptop have no reason to understand that documents correspond to files on disk that can be edited by programs running locally.
It more and more seems like the future is tech oligopoly with more and more subscription fees. What else could happen once a generation has been trained to only use Approved Tools running on Approved Servers?
This literaly demands that Android apps use your Firefox browser for login instead of a builtin WebView. This prevents the apps from stealing your login credentials with phished data.
Seriously, what are you ranting about here? What does what you write have anything to do with a fundamental security requirement?
Seriously, what are you ranting about here? What does what you write have anything to do with a fundamental security requirement?
I think I'm a little fired up about the Play Music -> YT Music migration, recent Google Photo storage restrictions, etc. What I see in TFA is another case of Google limiting choice in a user-hostile way. I happen to use Firefox and will be unaffected by the above, but Firefox is the only non-Webkit-based browser of any consequence. I'm incensed on behalf of people who use Epiphany or Brave or Konqueror or anything like that.
So you're mad about something entirely unrelated and equating this to user hostility. If you wanna use Brave or Konqueror, go for it. As long as it's your default browser you can log in. This just prevents an app from using an embedded webview.
I'm a big Firefox fan and I don't love google, but this is your standard hn 'circlejerk' of bashing google because google bad. Just like every single Amazon thread, regardless of topic, devolves into "yeah but comingling"
Google can be bad and still do the right thing for user privacy. In my opinion, they did just that.
I'm a big Firefox fan and I don't love google, but this is your standard hn 'circlejerk' of bashing google because google bad. Just like every single Amazon thread, regardless of topic, devolves into "yeah but comingling"
Google can be bad and still do the right thing for user privacy. In my opinion, they did just that.
many apps use webview for login as they have single sign-on. they dont want to re-implement logic so it works native or some other hacky things
I don't consider resistance to a single firm having near-complete visibility into my life 'ideological'.
I call it prudent.
But I agree, this will make me correct my last bits of Google-use.
I call it prudent.
But I agree, this will make me correct my last bits of Google-use.
So the story is that Google built up their Chrome browser on top of work done by KHTML/WebKit projects, and now, they'll potentially try to block users that are still using Konqueror from using Google services that require login?
Yes, they'll require this for authentication, not use. There are already ways to log into Google accounts using a trusted platform like a browser when the environment can't be confirmed. Google Cloud Shell has a mechanism like this, where it will generate a URL that you paste into a browser, and it will prompt for login if you aren't, then provide a token you can paste back into the shell utility, and then it's authenticated to perform actions on Google Compute Engine as you through shell commands.
This is essentially what the embedded browser context is doing in an automated way. My guess is there's a way to manually do this already, or there will be soon.
The main thing they are trying to do here is make sure the login process is secure as they can make it. I think there's a non-negligible increase in security by requiring somewhat trusted applications to make the request.
This is essentially what the embedded browser context is doing in an automated way. My guess is there's a way to manually do this already, or there will be soon.
The main thing they are trying to do here is make sure the login process is secure as they can make it. I think there's a non-negligible increase in security by requiring somewhat trusted applications to make the request.
So in order to log in to Google Services in a browser that isn't Google Chrome, I have to install Google Chrome?
Or Firefox, or Safari, or Edge, I believe.
Sorry, I meant for that to be implied, but should have been explicit.
This requirement locks you in to using one of the major players until the end of time.
This requirement locks you in to using one of the major players until the end of time.
Or unless there's a petition process to get another browser added. I think the criteria is "not a webview, not embedded", so if your browser isn't usable for that, or at least not without it being obvious, then maybe that browser can ask to be added?
There are reasons why Google doesn't just want to allow any curl request to authenticate a user, and those are valid reasons I agree with. Do those apply to a browser like Epiphany? Probably not, but there's a spectrum along which things will fall, and people will not always agree on where those things belong on that spectrum, and some things may be initially excluded purely on popularity, but that might be an easy problem to fix. Asking is pretty low effort.
There are reasons why Google doesn't just want to allow any curl request to authenticate a user, and those are valid reasons I agree with. Do those apply to a browser like Epiphany? Probably not, but there's a spectrum along which things will fall, and people will not always agree on where those things belong on that spectrum, and some things may be initially excluded purely on popularity, but that might be an easy problem to fix. Asking is pretty low effort.
I do wonder if Michael Catanzaro has tried reaching out to Google. Epiphany's user base is microscopic compared to Chrome's, I'm sure, but they're also very far from a fly-by-night project.
Then again, I'm not sure how he would reach out. Google is infamously hard to contact, particularly in these sorts of situations where you're a victim of the AI.
Then again, I'm not sure how he would reach out. Google is infamously hard to contact, particularly in these sorts of situations where you're a victim of the AI.
Probably to a dev on the team that implemented this, which might be harder to find, but is also likely to be a more fruitful conversation than some front-line support rep, as technical cases and reasons can be explained dev-to-dev.
>then maybe that browser can ask to be added?
So as soon as one such webview-based browser gets added via this hypothetical petition process, what's to stop the Evil Nasty Malware (tm) from using the same webview library? The email's author worries about needing their webview-based browser to maintain JS engine and TLS ciphersuite equivalence with an approved browser, but that becomes trivial if the exact same webview library can be used by an approved browser and the Evil Nasty Malware.
It seems to me that allowing even a single webview-based browser would go against what Google is trying to do.
So as soon as one such webview-based browser gets added via this hypothetical petition process, what's to stop the Evil Nasty Malware (tm) from using the same webview library? The email's author worries about needing their webview-based browser to maintain JS engine and TLS ciphersuite equivalence with an approved browser, but that becomes trivial if the exact same webview library can be used by an approved browser and the Evil Nasty Malware.
It seems to me that allowing even a single webview-based browser would go against what Google is trying to do.
If it's a webview based browser, I think it shouldn't be added. Sorry, that's just the price they pay for using a webview as a shortcut to providing a full browser.
> It seems to me that allowing even a single webview-based browser would go against what Google is trying to do.
I agree. Other than it being weird to ask/need the system to use a different browser than you are using, and possibly a different browser than what you've set as default if you've set it to one Google doesn't trust for auth, nothing prevents any webview browser from acting like any other webview, and outsourcing to Chrome or Firefox for the authentication to get a good token, as long as you can use a token for full Google account login (which I don't know if you can).
> It seems to me that allowing even a single webview-based browser would go against what Google is trying to do.
I agree. Other than it being weird to ask/need the system to use a different browser than you are using, and possibly a different browser than what you've set as default if you've set it to one Google doesn't trust for auth, nothing prevents any webview browser from acting like any other webview, and outsourcing to Chrome or Firefox for the authentication to get a good token, as long as you can use a token for full Google account login (which I don't know if you can).
>If it's a webview based browser, I think it shouldn't be added. Sorry, that's just the price they pay for using a webview as a shortcut to providing a full browser.
Okay. So using a browser library for building a browser is a shortcut, and that disqualifies it from being a "full" browser. Of course one of the fundamental tenets of software is to not reuse other people's work. Silly me.
brb writing my own browser called Chremium and petitioning Google to allow it. Apart from that I'll also publish a library that uses the guts of Chremium, called the Chremium Ombodded Framework, which can be embedded in other applications.
Of course any application that uses the COF is indistinguishable from Chremium itself, but Google won't then distrust Chremium because it can't distinguish it from COF any more, right?
Okay. So using a browser library for building a browser is a shortcut, and that disqualifies it from being a "full" browser. Of course one of the fundamental tenets of software is to not reuse other people's work. Silly me.
brb writing my own browser called Chremium and petitioning Google to allow it. Apart from that I'll also publish a library that uses the guts of Chremium, called the Chremium Ombodded Framework, which can be embedded in other applications.
Of course any application that uses the COF is indistinguishable from Chremium itself, but Google won't then distrust Chremium because it can't distinguish it from COF any more, right?
> Of course one of the fundamental tenets of software is to not reuse other people's work. Silly me.
Many properties of programs are composable. Security isn't one of them. Embedded browsers sniffing credentials is an observed threat to real users.
Many properties of programs are composable. Security isn't one of them. Embedded browsers sniffing credentials is an observed threat to real users.
> Okay. So using a browser library for building a browser is a shortcut, and that disqualifies it from being a "full" browser.
Using an off-the-shelf library to provide core browser functionality disqualifies it from being on a list of browsers that do not use and off-the-shelf library to provide that functionality, yes.
I didn't say it wasn't a full, browser, so please to imply that I did, I said it was a shortcut to providing a full browser (which implies it is a full browser), and it is a shortcut compared to writing one from scratch.
Bottom line, if you write software utilizing libraries in a way that is extremely close or identical to a way that other software does and that method is being blacklisted for security, expect problems. It's the same for interpreted code and app stores. For security they don't want programs that can change how they function after review, so they often disallow interpreted code and downloading code to run, and in Apple's case, require their own webview library to view remote sites because of this. They don't even allow a set of other valid webview libraries, they just draw a line in the sand and say "ours only".
> Of course any application that uses the COF is indistinguishable from Chremium itself, but Google won't then distrust Chremium because it can't distinguish it from COF any more, right?
Probably. Seems like a bad business plan to follow in your snarky alternate reality. A better one might be to figure out how Google disambiguates Safari from the iOS webview, Chrome from the chromium webview, etc, and follow the same path. You might have had to trade some of the snarkiness in your example for reality, in that case.
Using an off-the-shelf library to provide core browser functionality disqualifies it from being on a list of browsers that do not use and off-the-shelf library to provide that functionality, yes.
I didn't say it wasn't a full, browser, so please to imply that I did, I said it was a shortcut to providing a full browser (which implies it is a full browser), and it is a shortcut compared to writing one from scratch.
Bottom line, if you write software utilizing libraries in a way that is extremely close or identical to a way that other software does and that method is being blacklisted for security, expect problems. It's the same for interpreted code and app stores. For security they don't want programs that can change how they function after review, so they often disallow interpreted code and downloading code to run, and in Apple's case, require their own webview library to view remote sites because of this. They don't even allow a set of other valid webview libraries, they just draw a line in the sand and say "ours only".
> Of course any application that uses the COF is indistinguishable from Chremium itself, but Google won't then distrust Chremium because it can't distinguish it from COF any more, right?
Probably. Seems like a bad business plan to follow in your snarky alternate reality. A better one might be to figure out how Google disambiguates Safari from the iOS webview, Chrome from the chromium webview, etc, and follow the same path. You might have had to trade some of the snarkiness in your example for reality, in that case.
> Using an off-the-shelf library to provide core browser functionality disqualifies it from being on a list of browsers that do not use and off-the-shelf library to provide that functionality, yes.
Epiphany uses Webkit-GTK. In a certain sense of the word, this is indeed an off-the-shelf library, but only in the same sense that Google Chrome uses off-the-shelf Blink. Epiphany a major contributor to Webkit-GTK, and one of its largest users.
Should Epiphany ban everyone else from using Webkit-GTK? I don't actually think they can, it's all open source after all.
> A better one might be to figure out how Google disambiguates Safari from the iOS webview, Chrome from the chromium webview, etc, and follow the same path.
Google is probably doing some kind of ridiculous obfuscated fingerprinting. I don't know that it's viable to work around something like that without cooperation from Google. It would be a constant cat-and-mouse game, with Google having the upper hand.
Epiphany uses Webkit-GTK. In a certain sense of the word, this is indeed an off-the-shelf library, but only in the same sense that Google Chrome uses off-the-shelf Blink. Epiphany a major contributor to Webkit-GTK, and one of its largest users.
Should Epiphany ban everyone else from using Webkit-GTK? I don't actually think they can, it's all open source after all.
> A better one might be to figure out how Google disambiguates Safari from the iOS webview, Chrome from the chromium webview, etc, and follow the same path.
Google is probably doing some kind of ridiculous obfuscated fingerprinting. I don't know that it's viable to work around something like that without cooperation from Google. It would be a constant cat-and-mouse game, with Google having the upper hand.
> Epiphany uses Webkit-GTK. In a certain sense of the word, this is indeed an off-the-shelf library, but only in the same sense that Google Chrome uses off-the-shelf Blink.
And yet nobody would accuse Google of this. The reason why is actually the same reason why that comparison doesn't make sense. Chrome and Blink are separate projects in name only, to allow for an easier separation of concerns so people can use Blink, but really they are part of the same thing.
> I don't know that it's viable to work around something like that without cooperation from Google. It would be a constant cat-and-mouse game, with Google having the upper hand.
I wasn't suggesting figuring out what they were doing so you could fool them, I was suggesting figuring out what they were doing so the same separations could be attempted and they could be petitioned for inclusion. Of course they're going to try to block a browser that tries to circumvent their detection of browsers to increase security, all anyone does by attempting to circumvent that is confirm they are the group Google are attempting to block, or at least aligned.
What this announcement really is is Google saying you need to use an authentication app to log in to their services, and that app happens to be Chrome, Safari, Edge or Firefox. People might already be using those and not notice, and other people might need to install those to authenticate. This doesn't even affect search. I'm having a hard time getting worked up about people not being able to use whatever random software they want to work as an authentication tool for Google's services. Don't use Google's services or just use one of those browsers to authenticate, problem solved.
And yet nobody would accuse Google of this. The reason why is actually the same reason why that comparison doesn't make sense. Chrome and Blink are separate projects in name only, to allow for an easier separation of concerns so people can use Blink, but really they are part of the same thing.
> I don't know that it's viable to work around something like that without cooperation from Google. It would be a constant cat-and-mouse game, with Google having the upper hand.
I wasn't suggesting figuring out what they were doing so you could fool them, I was suggesting figuring out what they were doing so the same separations could be attempted and they could be petitioned for inclusion. Of course they're going to try to block a browser that tries to circumvent their detection of browsers to increase security, all anyone does by attempting to circumvent that is confirm they are the group Google are attempting to block, or at least aligned.
What this announcement really is is Google saying you need to use an authentication app to log in to their services, and that app happens to be Chrome, Safari, Edge or Firefox. People might already be using those and not notice, and other people might need to install those to authenticate. This doesn't even affect search. I'm having a hard time getting worked up about people not being able to use whatever random software they want to work as an authentication tool for Google's services. Don't use Google's services or just use one of those browsers to authenticate, problem solved.
Am I missing something fundamental here? What is the difference between a "webview-based" browser and a browser?
If you're on macOS, sure, it's pretty obvious what's a WebView, because Apple explicitly uses the term, and it's their OS. The distinction is one of language rather than technology, but it's a valid distinction nonetheless.
On Linux, I don't think the distinction exists. Webkit-GTK is the Linux port of Webkit, and it can be used for anything.
If you're on macOS, sure, it's pretty obvious what's a WebView, because Apple explicitly uses the term, and it's their OS. The distinction is one of language rather than technology, but it's a valid distinction nonetheless.
On Linux, I don't think the distinction exists. Webkit-GTK is the Linux port of Webkit, and it can be used for anything.
There isn't a distinction. That's my point.
So what did you mean by "it seems to me that allowing even a single webview-based browser would go against what Google is trying to do."
kbenson suggested that Google could be petitioned to allow more browsers than the handful they already have.
I'm saying that if they allow even a single new webview-based browser, that would implicitly also allow any program using said webview library. This is the opposite of what Google wants.
Therefore the only logical conclusion is that Google will not allow any webview-based browsers.
In https://news.ycombinator.com/item?id=25156594 kbenson clarified that they think Google should not allow any webview-based browsers regardless of whether this hypothetical petition process exists or not. I responded by pointing out how this distinction does not help in any way, because even a new browser written from scratch that gets allowed by Google can then turn around and implement a webview library based on itself anyway.
My point is that this entire thing that Google is apparently trying is nonsensical. Maybe it works for phones, where "malware" (ie alternative browsers) can't easily change whatever Google is looking for in the HTTP requests (user-agent header, etc) to identify webview-based browsers vs the few they chose to allow. But it doesn't make sense for regular PCs. Anything an allowed browser can do, "malware" can mimic.
Actually, there is one way that it'll work on PCs too - if every google.com website starts using DRM. I almost look forward to that just because of the carnage that will occur in response.
I'm saying that if they allow even a single new webview-based browser, that would implicitly also allow any program using said webview library. This is the opposite of what Google wants.
Therefore the only logical conclusion is that Google will not allow any webview-based browsers.
In https://news.ycombinator.com/item?id=25156594 kbenson clarified that they think Google should not allow any webview-based browsers regardless of whether this hypothetical petition process exists or not. I responded by pointing out how this distinction does not help in any way, because even a new browser written from scratch that gets allowed by Google can then turn around and implement a webview library based on itself anyway.
My point is that this entire thing that Google is apparently trying is nonsensical. Maybe it works for phones, where "malware" (ie alternative browsers) can't easily change whatever Google is looking for in the HTTP requests (user-agent header, etc) to identify webview-based browsers vs the few they chose to allow. But it doesn't make sense for regular PCs. Anything an allowed browser can do, "malware" can mimic.
Actually, there is one way that it'll work on PCs too - if every google.com website starts using DRM. I almost look forward to that just because of the carnage that will occur in response.
[deleted]
> unless there's a petition process to get another browser added
Ah yes, once there were standards and committees, now you have to beg the power that be to let you in. Brilliant.
Ah yes, once there were standards and committees, now you have to beg the power that be to let you in. Brilliant.
Yes, now you ask the company you are trying to use the services of to allow your application to be a valid authentication agent of. Since when doesn't it make sense to ask to tie in your app when it's to be used with a different service when you care about that?
This is for login to a Google account, just plain searching on google.com or viewing a video on Youtube. We can complain about web standards all we want, but this isn't access to the open web we're talking about here, it's access to Google's service ecosystem that requires a Google account, and them gating that however they want is their prerogative.
This is for login to a Google account, just plain searching on google.com or viewing a video on Youtube. We can complain about web standards all we want, but this isn't access to the open web we're talking about here, it's access to Google's service ecosystem that requires a Google account, and them gating that however they want is their prerogative.
> they'll require this for authentication, not use.
Except for workarounds, I can't watch age restricted youtube videos without an account. And even for normal content, youtube wants me to log in very often. I have to decline all the time. I fear that youtube will be authwalled eventually like instagram and similar services.
Except for workarounds, I can't watch age restricted youtube videos without an account. And even for normal content, youtube wants me to log in very often. I have to decline all the time. I fear that youtube will be authwalled eventually like instagram and similar services.
Embrace, extend, extinguish.
It's just like Microsoft in the 1990s.
Any developer who values open computing (open source software or hardware, general purpose computers, running whatever programs you want, working around DRM, owning your own data) should be avoiding systems, tools, services and devices designed by companies like Google, and recommending the same to friends and family. Google does not have our interests at heart.
It's just like Microsoft in the 1990s.
Any developer who values open computing (open source software or hardware, general purpose computers, running whatever programs you want, working around DRM, owning your own data) should be avoiding systems, tools, services and devices designed by companies like Google, and recommending the same to friends and family. Google does not have our interests at heart.
> The browser must not provide automation features. This includes scripts that automate keystrokes or clicks, especially to perform automatic sign-ins.
Don't all major browsers have such automation features? Sounds like everything is illegal, including password managers and accessibility tools.
Don't all major browsers have such automation features? Sounds like everything is illegal, including password managers and accessibility tools.
Password managers aren't needed if you login to everything using Google, as you are supposed to.
This automation is an important part of password manager hygiene. Password managers only autofill credentials on the correct domain to prevent phishing.
If they are really blocking password manager extensions, then they can expect far less google logins from me.
If they are really blocking password manager extensions, then they can expect far less google logins from me.
They have already done this with Chromium Embedded Framework (CEF) which I use in my everyday browser. Since it can't do logins, even things like Google Groups fails auth and I'm forced to use Chrome instead of Chromium.
It is very annoying, Google announced it well ahead of time, but in general just doesn't care. They suggest the browser integrate with external auth options as if I want to customize my browser for Google auth.
They're actively fighting certain user agents with secret heuristics after having people create/need Google accounts for lots of things. Bastards.
It is very annoying, Google announced it well ahead of time, but in general just doesn't care. They suggest the browser integrate with external auth options as if I want to customize my browser for Google auth.
They're actively fighting certain user agents with secret heuristics after having people create/need Google accounts for lots of things. Bastards.
Just use a normal browser then. You aren’t blocked from the web.
But Chromium is a normal browser!
Chromium is, but the GP said they were using CEF embedded in another browser, which is specifically what this tries to prevent.
I imagine using normal raw Chromium will continue to work just fine.
I imagine using normal raw Chromium will continue to work just fine.
Oh, oops, good point! I saw the line "I'm forced to use Chrome instead of Chromium" and made some assumptions! If Google wants to explicitly block a framework that is designed to be a WebView, that seems a bit more reasonable (even if it sucks for the OP).
How would Google differentiate between Chromium and CEF in a way that isn't trivially spoofable by the latter?
By doing weird fingerprinting stuff, I assume.
I dunno. I think the situation where a company made a framework explicitly for embedded WebViews is a little different than what's happening with Epiphany.
I dunno. I think the situation where a company made a framework explicitly for embedded WebViews is a little different than what's happening with Epiphany.
Should the title be changed from "embedded browser frameworks" to "unsupported browsers"? The latter seems far more consequential than the former.
Edit: I wonder if this is intended to be an attack on browsers like Ungoogled Chromium that Google doesn't like? (https://github.com/Eloston/ungoogled-chromium)
Edit: I wonder if this is intended to be an attack on browsers like Ungoogled Chromium that Google doesn't like? (https://github.com/Eloston/ungoogled-chromium)
Does this mean Google is explicitly repudiating web standards and refusing to interoperate with any browsers except the ones they approve? Or is there more to it than that?
Quite the opposite actually. OAuth is designed to broker token exchange between two services in a standards-compliant web browser. Apps have increasingly been getting around it by embedding browser shells in their own interface, making the process less transparent for the end user. This opens users to all kinds of phishing attacks (e.g. an app might show you a Google sign-in page which is actually hosted on their own server, or steal your credentials even if you are actually on google.com, or automatically click "approve" without any user feedback etc.)
Enforcing that OAuth is handled in a browser controlled directly by the OS is the right thing to do.
Enforcing that OAuth is handled in a browser controlled directly by the OS is the right thing to do.
> an app might show you a Google sign-in page which is actually hosted on their own server, or steal your credentials even if you are actually on google.com
I'm confused, how does "this browser is not supported" translate into "this request is coming from a third party server"? Can't a third party just use whatever browser is supported to send the request?
I'm confused, how does "this browser is not supported" translate into "this request is coming from a third party server"? Can't a third party just use whatever browser is supported to send the request?
The idea is that users should not be expected to or used to entering their Google credentials outside of a browser they don't fully trust.
> entering their Google credentials outside a browser Google doesn’t fully trust
FIFY
As the user, I fully trust my Epiphany browser.
FIFY
As the user, I fully trust my Epiphany browser.
No, this means that Google demands that apps use the default browser you've set for login instead of the builtin WebKit of the device.
And what if your default web browser is Epiphany?
[deleted]
The user you asked has apparently decided to pretend that particular reality doesn't exist.
> The browser must not provide automation features. This includes scripts that automate keystrokes or clicks, especially to perform automatic sign-ins.
Can't Chrome do this via Chrome extensions?
Can't Chrome do this via Chrome extensions?
Yes, but only on PC. If Chrome was built from scratch in 2020 it wouldn't have extensions, just like on Android
You can also do full automation with Chrome's remote debugging API without installing anything (it's just websockets)
You can also do full automation with Chrome's remote debugging API without installing anything (it's just websockets)
I don't know why this is here, because this requirement has been in place for years - e.g. I've hit it at least two years ago where Google OAuth didn't allow builtin old WebKit login anymore.
Instead, you need to call users' default browser (Firefox, Chrome, whatever they have) and it'll return back with the token. Just like OAuth on desktop.
It's much, much safer, because the app can't see or hijack the login process - it doesn't get access to the login form and can't phish you with it.
The utter ignorance in comments here is really depressing, what happened with HN?
Instead, you need to call users' default browser (Firefox, Chrome, whatever they have) and it'll return back with the token. Just like OAuth on desktop.
It's much, much safer, because the app can't see or hijack the login process - it doesn't get access to the login form and can't phish you with it.
The utter ignorance in comments here is really depressing, what happened with HN?
For context, the author of this mailing list posting is concerned because Epiphany (the default browser in GNOME) uses GtkWebkit, an embedded Webkit browser engine. Presumably, it would be treated like any other unsupported browser.
(Edit: Additional context: in follow-up replies, they seem to have tested it by sending a header to try the changes early, and as of now it doesn’t appear to break things. I have not read the entire thread; folks should check the replies though.)
(Edit: Additional context: in follow-up replies, they seem to have tested it by sending a header to try the changes early, and as of now it doesn’t appear to break things. I have not read the entire thread; folks should check the replies though.)
I guess the easiest solution is to use Firefox User Agent. It's obsolete header after all, isn't it?
...until they introduce browser fingerprinting to prevent such shenanigans. I'm sure they already have the infrastructure/code in place, given that they also run recaptcha.
Funny thing about that. From the article:
> Google says: "The browser must identify itself clearly in the User-Agent. The browser must not try to impersonate another browser like Chrome or Firefox." We cannot comply with this because user agent spoofing is required for compatibility with various Google websites.
The author is concerned that Google will become increasingly aggressive about detecting alternate browsers, since it's clearly against the rules and they certainly have the capability.
> Google says: "The browser must identify itself clearly in the User-Agent. The browser must not try to impersonate another browser like Chrome or Firefox." We cannot comply with this because user agent spoofing is required for compatibility with various Google websites.
The author is concerned that Google will become increasingly aggressive about detecting alternate browsers, since it's clearly against the rules and they certainly have the capability.
I think a lot of people are forgetting that Google saying "the browser must not try to impersonate another browser" is a fairly funny part in itself.
Everyone remembers the User-Agent for Chrome starts with "Mozilla/5.0" right? It has always impersonated another browser for compatibility reasons. For so long that we take this for granted now.
Everyone remembers the User-Agent for Chrome starts with "Mozilla/5.0" right? It has always impersonated another browser for compatibility reasons. For so long that we take this for granted now.
Yes, this!
Here's my favorite send-up of the history of the User-Agent header (hard to believe it was already 12 years ago(!) when it first made me laugh)
https://webaim.org/blog/user-agent-string-history/comment-pa...
https://webaim.org/blog/user-agent-string-history/comment-pa...
Make sure every alternate browser has accessibility specific features. Then smack them down with the ADA.
Actually, when I was reading Google's blog post, this rule jumped out to me:
> The browser must not provide automation features. This includes scripts that automate keystrokes or clicks, especially to perform automatic sign-ins.
Automating keystrokes and/or clicks could absolutely be necessary for accessibility.
> The browser must not provide automation features. This includes scripts that automate keystrokes or clicks, especially to perform automatic sign-ins.
Automating keystrokes and/or clicks could absolutely be necessary for accessibility.
Sounds like they're worried about fake ad clicks.
What does logging into google have to do with fake adclicks?
The ad clickspam system uses the logged in user (or lack of) as a strong signal.
Thanks.
My default browser is one I built, and it hasn't worked with Google auth since they disallowed auth from CEF. Not warned, put captchas in front of, etc but disallowed. Yes the ignorance in HN comments can seem depressing, but I decided to respond to this one anyways.
Yours is very edge case though, and the grandparent is rightly pointing out that the headline is a little misleading and comments are generally negative for a positive aspect.
[deleted]
It's a very important edge case. Every new browser, by definition, starts out as a self-compiled project.
If this happened in the 90s, would we ever have had Mozilla? Would tabbed web browsers exist?
If this happened in the 90s, would we ever have had Mozilla? Would tabbed web browsers exist?
This.
If something can't be accessed by any standards-conforming client, then it isn't the web.
If something can't be accessed by any standards-conforming client, then it isn't the web.
>Yours is very edge case though
Not using google chrome is itself an edge case. That's kinda part-and-parcel with monopolistic predatory behaviors.
Not using google chrome is itself an edge case. That's kinda part-and-parcel with monopolistic predatory behaviors.
One man's edge case is another man's line in the sand.
If you think impersonating another browser's user-agent string for compatabililty reasons as a full fledged "real" browser is an edge case ...
You should remind yourself what the Chrome user-agent string actually is.
You should remind yourself what the Chrome user-agent string actually is.
Have you checked YOUR user agent? This is rediculous.
I'm interested in this browser code you speak of...as a fledgling browser builder.
https://cretz.github.io/doogie/ - I don't publish prebuilt releases anymore because I don't really work on it anymore, but I build it for myself with the latest CEF every update. There's a bug here and there, but it is by far more productive for me than other browsers.
But user beware, you can't login to any Google account using it since they disallowed it.
But user beware, you can't login to any Google account using it since they disallowed it.
The writer of this post is the developer of a Webkit-based browser for Linux. Not an email or chat client with an embedded log-in screen—a real, true browser that just so happens to not be named Chrome, Safari, or Firefox. It is the default browser in many Linux distributions.
Yes. And we are all well past the point now where antitrust legislation should be invoked to break Google up. This is another attempt to use one piece of Google to promote another piece of Google.
>It's much, much safer, because the app can't see or hijack the login process - it doesn't get access to the login form and can't phish you with it.
Not really. On non-sandboxed platforms (eg. windows or mac) it does nothing because the program already has full access to the operating system. It could very keylog the password as it's being entered into the "real" browser. Regardless of whether it's sandboxed, it could also launch a phoney "real" browser (ie. custom build of firefox/chrome that has keylogging logic built into the browser itself), and keylog using that. I'm not sure how that can be detected.
Not really. On non-sandboxed platforms (eg. windows or mac) it does nothing because the program already has full access to the operating system. It could very keylog the password as it's being entered into the "real" browser. Regardless of whether it's sandboxed, it could also launch a phoney "real" browser (ie. custom build of firefox/chrome that has keylogging logic built into the browser itself), and keylog using that. I'm not sure how that can be detected.
dapids(1)
jeppesen-io(1)
This entire post is about legitimate browsers being banned from Google logins. It's really depressing to see quite a few people sidestepping this point entirely and even accusing people of ignorance.
"It's much, much safer, because the app can't see orhjack the process - it doesn't get access to the login form and can't phish you with it."
What if you are the author of the "app" and its sole user?
What if you are the author of the "app" and its sole user?
> whatever they have
That's what is being threatened, other browsers. Google is throwing its weight around to try and enforce browser standards that are bad for a lot of people. Just like with amp.
> It's much, much safer, because the app can't see or hijack the login process - it doesn't get access to the login form and can't phish you with it.
Apps that try this shouldn't be running on your computer. This is not much safer, it's negligibly safer with a significant cost.
> The utter ignorance in comments here is really depressing, what happened with HN?
The irony.
That's what is being threatened, other browsers. Google is throwing its weight around to try and enforce browser standards that are bad for a lot of people. Just like with amp.
> It's much, much safer, because the app can't see or hijack the login process - it doesn't get access to the login form and can't phish you with it.
Apps that try this shouldn't be running on your computer. This is not much safer, it's negligibly safer with a significant cost.
> The utter ignorance in comments here is really depressing, what happened with HN?
The irony.
> That's what is being threatened, other browsers.
Is it? Oauth regularly opens Safari on mobile and Firefox on OS X for me; it's not clear that this move itself is forcing users to chrome per se.
If they're blocking non-popular browsers, that's obviously a problem. But if they'll let users open Firefox or Safari, then it seems fairly obvious to me that this is a mistake more than a sinister plan to drive Chrome adoption forward. After all, if they were trying to drive Chrome forward why would they push me more towards Safari?
Is it? Oauth regularly opens Safari on mobile and Firefox on OS X for me; it's not clear that this move itself is forcing users to chrome per se.
If they're blocking non-popular browsers, that's obviously a problem. But if they'll let users open Firefox or Safari, then it seems fairly obvious to me that this is a mistake more than a sinister plan to drive Chrome adoption forward. After all, if they were trying to drive Chrome forward why would they push me more towards Safari?
I was using the googlevoice python plugin a couple years ago. At some point they decided they definitely didn't want anyone using googlevoice from an automated system and its been broken for a year+ now. I spent a couple hours with various headless browsers/etc and developer tools trying to see if I could get anything to login. I didn't try super hard, but i'm still not 100% sure what they were doing to detect actual user interaction.
It was easier to just pay a couple dollars a year to a different service that prioritizes having a working API.
It was easier to just pay a couple dollars a year to a different service that prioritizes having a working API.
What Voice alternative do you use now?
Google are playing with anti-trust fire here.
This just seems like fixing a security bug? They're saying that they'll no longer allow apps to embed the oAuth login inside their own embedded WebView, right? Seems like this is in the interest of protecting users from malicious apps that pretend to show Google's oAuth screen but actually show a phishing site.
The issue is that one person's WebView is another person's web browser. You can't really block WebViews unless you decide anything other than a whitelisted browser must be a WebView.
As a security measure, the cows are out of the barn already.
Workflows already exist where an app shows an embedded login page. Users have already become accustomed to it. A malicious developer trying to phish in that flow will just substitute a self-hosted or local simulation of the Google login form. Worst case, you pretend there was an error and punt the user to "backup login" in a real browser to now blow your cover. This won't prevent such scams.
If they had made the decision several years ago, they might have been able to say "We've never and never will supported this type of login flow; if you see it, it's a scam" and managed expectations on a going forward basis. But now you're stripping functionality without a clear user-facing notification that embedded logins are suspicious. Is there even a reasonable way to convey that info to most potentially impacted users today?
Of course, that doesn't solve the problem of dividing the world between "real" and "embedded" browsers, but that's another story. Again, if this wasn't a regression, it would be more forgivable. I can accept that the full Google experience won't work on other unsupported environments (say, the web browser packed in with OS/2), but it's not like those worked yesterday but not today as a policy choice.
Workflows already exist where an app shows an embedded login page. Users have already become accustomed to it. A malicious developer trying to phish in that flow will just substitute a self-hosted or local simulation of the Google login form. Worst case, you pretend there was an error and punt the user to "backup login" in a real browser to now blow your cover. This won't prevent such scams.
If they had made the decision several years ago, they might have been able to say "We've never and never will supported this type of login flow; if you see it, it's a scam" and managed expectations on a going forward basis. But now you're stripping functionality without a clear user-facing notification that embedded logins are suspicious. Is there even a reasonable way to convey that info to most potentially impacted users today?
Of course, that doesn't solve the problem of dividing the world between "real" and "embedded" browsers, but that's another story. Again, if this wasn't a regression, it would be more forgivable. I can accept that the full Google experience won't work on other unsupported environments (say, the web browser packed in with OS/2), but it's not like those worked yesterday but not today as a policy choice.
A malicious developer trying to phish in that flow will just substitute a self-hosted or local simulation of the Google login form.
That doesn't work because Google login is multi-step. Just stealing a password isn't enough, then you need to log in with it. They have anti-hacking systems and two factor auth to stop that.
That doesn't work because Google login is multi-step. Just stealing a password isn't enough, then you need to log in with it. They have anti-hacking systems and two factor auth to stop that.
"Users can use browsers of their choice" and "Logging in does not throw you out of the app and open a browser" are not security bugs.
This in NOT just a bug. This is killing off the web masquerading as that. Google is evil. I can't say this more
Ya, leverage monopoly to push their own "supported" browser.
No, they are just tightening controls of their own OAuth to avoid peoples' Gmail accounts being phished by scummy apps.
If the app uses a webview to connect to its own brand of oauth, that isn't affected.
If the app uses a webview to connect to its own brand of oauth, that isn't affected.
If only they'd actually get burned, this time.
Knowing Google, security is just smoke and mirrors for excluding any competition in the browser and app space.
Will this block sign-in on Tesla's browser and Youtube app?
Sounds like it, but I'm sure their corp dev/partnership teams will make a special exception for S&P 500's newest member!
They could just redirect the authorization to the users phone.
That's been broken for a long time anyways. Workaround is to just go to any site that uses google login, then magically you're logged into youtube.
No.
Does this block stuff like qutebrowser?
FWIW Google already did this back in 2019, without any announcement - at that point, I added a workaround, which I hope will continue to work: https://github.com/qutebrowser/qutebrowser/issues/5182
Yes.
I live qutebrowser and this is frustrating.
FWIW Google already did this back in 2019, without any announcement - at that point, I added a workaround, which I hope will continue to work: https://github.com/qutebrowser/qutebrowser/issues/5182
[deleted]
I think this will cause chrome headless to stop being able to login to Google accounts.
But since Firefox is also now supporting chrome remote debugging protocol, it might be possible to swap chrome headless for Firefox, if your use case involves that. For example, automation, testing or remote browsers.
But since Firefox is also now supporting chrome remote debugging protocol, it might be possible to swap chrome headless for Firefox, if your use case involves that. For example, automation, testing or remote browsers.
I think this is good. My big concern with OpenID was that, beyond it's technical security, it was training users to enter very valuable credentials (like their Google account that they probably use for bank emails, etc.) all over the place for other services (like some random app that lets you use your Google account), where they don't really know how to confirm that the credentials are going straight to Google. Doing this in their legit browser makes this a bit better.
No. This is terrible for the web. This closes of the the web to just their "legit" browser, like an app mandated by them. The very thing that made Google, Google is killing that.
Ok - so in an embedded browser how do I know with high confidence my credentials are being sent encrypted to the right authenticator? If that functionality isn't part of the web, then I don't subscribe to it.
Can't users pick another OpenID provider?
The only correct response by other web browsers is to spoof other browsers as hard as necessary to work around this bad behavior.
[deleted]
Weirdly, we got the same notice a few days ago, but it said it meant we'd no longer be able to authenticate people using our external auth provider (auth0.com).
Which sounds like it really leaves our Google users up shit creek without a paddle. :(
Which sounds like it really leaves our Google users up shit creek without a paddle. :(
So how will thunderbird (and other software) sign into gmail accounts?
Thunderbird can use "app passwords" and/or oauth2, I believe. It's not trying to maintain a browser session login cookie.
So app passwords are something Google are slowly boiling the frog on to get rid of. As of the last year or two, Thunderbird is using OAuth2.
_The way it does OAuth_, is by opening a google sign in in an embedded browser, and then catching the API key in the redirect by intercepting the navigation in the embedded browser.
It's not a browser session cookie, but it does require the user to log in. To replace this and use the desktop browser, thunderbird would have to spin up a web server, and I'm not sure what restrictions Google have about TLS on redirect targets, which may be problematic to spin up a trusted TLS server on arbitrary end user devices.
They could of course set up a centralised service to echo the token back to end users, but this seems likely to be even higher risk of the service stealing your oauth tokens and less trusted by those types of users still using a desktop email client.
_The way it does OAuth_, is by opening a google sign in in an embedded browser, and then catching the API key in the redirect by intercepting the navigation in the embedded browser.
It's not a browser session cookie, but it does require the user to log in. To replace this and use the desktop browser, thunderbird would have to spin up a web server, and I'm not sure what restrictions Google have about TLS on redirect targets, which may be problematic to spin up a trusted TLS server on arbitrary end user devices.
They could of course set up a centralised service to echo the token back to end users, but this seems likely to be even higher risk of the service stealing your oauth tokens and less trusted by those types of users still using a desktop email client.
They can just set a thunderbird:// redirect uri and register a custom OS protocol handler
Same way it does right now (and many apps did it for years): it'll open your default browser (Chrome, Firefox, whatever) and wait for it to return the oauth token to it.
How does this work? Like, in practice I understand how you open the default web browser and log in, and get an oauth token. But how does the default browser hand it back to thunderbird or whatever application made the request? Is there a standard way for a browser to return a value to an application that called it?
The trick is setting the right redirect_uri [0].
Generally it's implemented with a custom URI scheme (that the target application is registered for) or a loopback ip address.
[0] https://developers.google.com/identity/protocols/oauth2/nati...
Generally it's implemented with a custom URI scheme (that the target application is registered for) or a loopback ip address.
[0] https://developers.google.com/identity/protocols/oauth2/nati...
Thanks! Was about to implement OAuth (against Azure AD) at work and we didn't want to embed a browser, so this was really helpful.
This is part of the normal OAuth flow. Normally, there's an API call from the app to the site in addition to the app opening the user's browser.
I don't know, but there are lots of apps that do stuff this way. Not to mention every tv app that has you sign in on your desktop. Clearly there are ways.
Standard POP3/IMAP logins should still work, I believe?
You are not supposed to use Thunderbird. You are supposed to use the web interface so Google can control your experience and show you ads.
They have been doing this for a long time already. It's a good thing that random apps cannot hijack your Google account sign-in flow.
That’s why I turn off background running process off in various web browsers.
Also put tab to sleep once it’s out of focus.
Also put tab to sleep once it’s out of focus.
This already is blocked via "Safety" for lots of older printers and SMTP relays.
As easy as impersonating Chrome—if they can detect you, you’re not doing it well enough.
Wow, now is the time to switch to something else?
Why would it be time to switch to another browser because Google is disallowing apps from embedding Google oAuth pages in their own WebView? This seems like a security win for users - you'll no longer have to trust that the app isn't phishing your credentials.
Time to switch away from Google services... Of course dont go back to Google Chrome...
This is about apps using an embedded webview to present a password page instead of using the system browser. It was basically training people to enter their credentials into 3rd party apps which is a terrible idea.
I get that but I use apps that I like to give access to my Google account to... Looks like its going to be an issue now.
Want to sign in to Google? Use one of the selected browsers with a significant, existing market share.
But first though, are you actually human? Let's see if your browser is compatible with our reCAPTCHA service. [0]
Oh, you wanted to watch something on Netflix? I hope your browser is approved by Google for DRM playback. [1]
[0] https://twitter.com/bcrypt/status/1320410639244746753
[1] https://blog.samuelmaddock.com/posts/the-end-of-indie-web-br...