6 ms·

Not sure if this is covered under Widevine, but Google also blocks anything that is not a major browser from logging into any of its services. https://security

Not sure if this is covered under Widevine, but Google also blocks anything that is not a major browser from logging into any of its services. https://security.googleblog.com/2019/04/better-protection-against-man-in-middle.html https://security.googleblog.com/2019/04/better-protection-ag...

AndrewUnmuted 6y ago
Sorry to go off-topic slightly, but can any INFOSEC people confirm that this idea below makes any sense? The conventional thinking, as far as I am aware, has always been that JavaScript increases your attack vector and diminishes your security coverage. > Last year, we announced that we would require JavaScript to be enabled in your browser when you sign in so that we can run a risk assessment whenever credentials are entered on a sign-in page and block the sign-in if we suspect an attack. This is yet another layer of protection on top of existing safeguards like Safe Browsing warnings, Gmail spam filters, and account sign-in challenges.
- eivarv 6y ago
  There's probably more here, but one thing I can think of is fingerprinting the client as part of the automated risk assessment, deciding whether and when to block attempts, trigger MFA, and recognize specific devices (and potentially tie them to specific users for whatever reason).
- schoen 6y ago
  I think they're looking at two different notions of security: security of Google's services against bots (which is probably what Google is trying to check with Javascript), and security of users' browsers against malware (which is an attack surface that can be limited by turning off Javascript). It might be like thinking about whether a "TSA lock" increases security. One might say that it increases security because it allows TSA to check the contents of people's belongings more easily, or that it decreases security because it can allow anyone with brief physical access to a bag to steal its contents. Edit: the sibling comment also points out a likely use about recognizing your own devices. If you let Google spy on you more, it can more accurately determine what is usual or unusual for you, in order to distinguish you from an impersonator. You might also not want Google or others to have this information.
- closeparen 6y ago
  Phishing is accessible to anyone with basic web development skills, while JavaScript sandbox escapes for major browsers are the domain of pretty sophisticated actors.
- butt_hugger 6y ago
  You are correct. This is just for Google's benefit, as you can imagine. They are Google, after all.
- _jal 6y ago
  Dirty little secret: when software vendors speak, they will frequently blur the purpose of a given security measure and who, exactly, it protects. This measure helps protect Google. And much like a politician stretching the definition of the national interest to include themselves, Google might say that they're protecting you by protecting themselves.
  - kmeisthax 6y ago
    If Google can use this to rate limit sign-ins more effectively, then it does protect users, since the limiting factor on password security is time to crack.
    - Wowfunhappy 6y ago
      I want the ability to change these types of settings for my account. They can be buried in an advanced menu somewhere. I have a password manager. My Google password is a long, unique string of random characters that I don't use on any other service. If someone does break into my Google account, it will be because they broke into my password manager and/or successfully phished me (or hit me on the head with a $5 wrench). Number of retries will have nothing to do with it, unless they have a computer from the future. I am much more concerned about Google locking me out of my account some day in an attempt to stop someone from breaking in, then I am about someone else actually breaking in.
      - kcartlidge 6y ago
        Upvoted for the subtle xkcd reference :)
eivarv 6y ago
A more precise wording might be "... Google also blocks anything that's implemented in an embedded framework (e.g. CEF, webviews) and does not use browser-based OAuth authentication."
- LeoPanthera 6y ago
  That's not correct, as Konqueror and Falkon browsers are also blocked.
  - eivarv 6y ago
    I'm just summarizing what the linked article actually says. As for your examples, Konqueror and Falkon might be blocked because they use Qt WebEngine – which embeds Blink in the Qt framework [0]. [0]: https://en.wikipedia.org/wiki/Blink_(browser_engine)#Frameworks https://en.wikipedia.org/wiki/Blink_(browser_engine)#Framewo...
    - lights0123 6y ago
      Nice for Google to block the project that wrote the origins of their browser engine.
      - eivarv 6y ago
        The Qt project didn't write the origins of Google's browser engine. Blink forked from Webkit, which started as a fork of the KHTML and KJS libraries from KDE. Many KDE-projects are built upon Qt, but Qt is an independent project.
        Drdrdrq 6y ago
        I think they are talking about Konqueror, not QT. Konqueror is what KHTML was developed for, iirc.
        eivarv 6y ago
judge2020 6y ago
It's pretty warranted when this is the type of attack possible: https://news.ycombinator.com/item?id=25717156 https://news.ycombinator.com/item?id=25717156 See the comments for a summary and why the submission was flagged.
- kevin_thibedeau 6y ago
  It's also a glaring ADA violation.
  - judge2020 6y ago
    https://www.google.com/accessibility/products-features/#!#chrome-browser https://www.google.com/accessibility/products-features/#!#ch...
    - kevingadd 6y ago
      "We're perfectly accessible as long as you switch web browsers to the one we make" is probably not going to cut it by ADA standards if someone pushes hard enough. Chrome isn't a 1:1 drop-in replacement, and it may not be available on some devices.

AndrewUnmuted 6y ago

Sorry to go off-topic slightly, but can any INFOSEC people confirm that this idea below makes any sense? The conventional thinking, as far as I am aware, has always been that JavaScript increases your attack vector and diminishes your security coverage. > Last year, we announced that we would require JavaScript to be enabled in your browser when you sign in so that we can run a risk assessment whenever credentials are entered on a sign-in page and block the sign-in if we suspect an attack. This is yet another layer of protection on top of existing safeguards like Safe Browsing warnings, Gmail spam filters, and account sign-in challenges.

eivarv 6y ago
There's probably more here, but one thing I can think of is fingerprinting the client as part of the automated risk assessment, deciding whether and when to block attempts, trigger MFA, and recognize specific devices (and potentially tie them to specific users for whatever reason).
schoen 6y ago
I think they're looking at two different notions of security: security of Google's services against bots (which is probably what Google is trying to check with Javascript), and security of users' browsers against malware (which is an attack surface that can be limited by turning off Javascript). It might be like thinking about whether a "TSA lock" increases security. One might say that it increases security because it allows TSA to check the contents of people's belongings more easily, or that it decreases security because it can allow anyone with brief physical access to a bag to steal its contents. Edit: the sibling comment also points out a likely use about recognizing your own devices. If you let Google spy on you more, it can more accurately determine what is usual or unusual for you, in order to distinguish you from an impersonator. You might also not want Google or others to have this information.
closeparen 6y ago
Phishing is accessible to anyone with basic web development skills, while JavaScript sandbox escapes for major browsers are the domain of pretty sophisticated actors.
butt_hugger 6y ago
You are correct. This is just for Google's benefit, as you can imagine. They are Google, after all.
_jal 6y ago
Dirty little secret: when software vendors speak, they will frequently blur the purpose of a given security measure and who, exactly, it protects. This measure helps protect Google. And much like a politician stretching the definition of the national interest to include themselves, Google might say that they're protecting you by protecting themselves.
- kmeisthax 6y ago
  If Google can use this to rate limit sign-ins more effectively, then it does protect users, since the limiting factor on password security is time to crack.
  - Wowfunhappy 6y ago
    I want the ability to change these types of settings for my account. They can be buried in an advanced menu somewhere. I have a password manager. My Google password is a long, unique string of random characters that I don't use on any other service. If someone does break into my Google account, it will be because they broke into my password manager and/or successfully phished me (or hit me on the head with a $5 wrench). Number of retries will have nothing to do with it, unless they have a computer from the future. I am much more concerned about Google locking me out of my account some day in an attempt to stop someone from breaking in, then I am about someone else actually breaking in.
    - kcartlidge 6y ago
      Upvoted for the subtle xkcd reference :)

eivarv 6y ago

A more precise wording might be "... Google also blocks anything that's implemented in an embedded framework (e.g. CEF, webviews) and does not use browser-based OAuth authentication."

LeoPanthera 6y ago
That's not correct, as Konqueror and Falkon browsers are also blocked.
- eivarv 6y ago
  I'm just summarizing what the linked article actually says. As for your examples, Konqueror and Falkon might be blocked because they use Qt WebEngine – which embeds Blink in the Qt framework [0]. [0]: https://en.wikipedia.org/wiki/Blink_(browser_engine)#Frameworks https://en.wikipedia.org/wiki/Blink_(browser_engine)#Framewo...
  - lights0123 6y ago
    Nice for Google to block the project that wrote the origins of their browser engine.
    - eivarv 6y ago
      The Qt project didn't write the origins of Google's browser engine. Blink forked from Webkit, which started as a fork of the KHTML and KJS libraries from KDE. Many KDE-projects are built upon Qt, but Qt is an independent project.
      - Drdrdrq 6y ago
        I think they are talking about Konqueror, not QT. Konqueror is what KHTML was developed for, iirc.
        eivarv 6y ago

judge2020 6y ago

It's pretty warranted when this is the type of attack possible: https://news.ycombinator.com/item?id=25717156 https://news.ycombinator.com/item?id=25717156 See the comments for a summary and why the submission was flagged.

kevin_thibedeau 6y ago
It's also a glaring ADA violation.
- judge2020 6y ago
  https://www.google.com/accessibility/products-features/#!#chrome-browser https://www.google.com/accessibility/products-features/#!#ch...
  - kevingadd 6y ago
    "We're perfectly accessible as long as you switch web browsers to the one we make" is probably not going to cut it by ADA standards if someone pushes hard enough. Chrome isn't a 1:1 drop-in replacement, and it may not be available on some devices.