> This is the login page - users are typing in a long term stable identifier already!
There are so many other considerations at work here though, and I can't imagine that they're not obvious to you as well? For starters, we're creatures of convenience, and this makes it significantly inconvenient to block google scripts on other websites even when not signed in. It also guarantees that you have the chance to produce a (likely unique) JS-based fingerprint of every google user that can then be used for correlation and de-anonymization of other data.
But really the most basic point that probably makes folks here suspicious: if this were really only about preventing malicious login attempts by bots, then why not give users a clear, explicitly stated choice: either JS or 2FA.
I take offense at your tone, and the implied judgement. Malbolge was the right tool for us, and let us tap into a talent pool that was otherwise going unused.
I'd be curious if the tools are only effective because of the fringe requirement of them. That is to say, right now, many malicious users are easy to spot using these, precisely because they don't have to be hard to spot.
That is to say, in the long run, it will be interesting if this actually reduces malicious use. Seems like it would be just as easy to avoid.
Thank you Google for making me investigate alternatives.
I am serious, I've been using gmail since 2004.
I realize some day my main account is going to be permanently inaccessible just because I will be in the "wrong" country or will be using the wrong browser in the wrong cafe.
There should be no need for Javascript with proper 2FA.
Your algorithms already make me solve ridiculous captchas "some" of the time.
I'd disagree entirely. I'd argue that I'm aware of how much effort has gone into making the web much, Much, MUCH more convenient and less risky for the average, day to day user.
It's frankly stunning how much the ecosystem has changed just over the last 5-10 years. And I mean that as a developer who works in the security industry with a focus on browsers/extensions. It's ludicrous how much more secure the web of today is over the web of the past.
That said, it's not yet secure. There's always a risk/reward decision for using the web, especially around HOW you - the user - uses the web.
So to make an analogy: The infrastructure in place between root authorities, the IETF, browser vendors, ISRG (Let's Encrypt is just one), and website developers has done a DAMN good job in making the web less vulnerable than it was.
It's a nicely paved two lane road that goes nearly everywhere.
That said, you are interacting with the entity hosting the site you visit, NOT THOSE GROUPS, when you visit a site.
It's your responsibility to make sure you trust that entity, and do your due diligence.
Just like I wouldn't try to drive my crappy 1998 Mazda Protege offroad - It's dangerous and I would be unprepared.
Its your responsibility to make decisions for yourself (or at least I fucking hope it is... that's a fundamental aspect of a democratic society that I STRONGLY believe in). That means living with the consequences.
It can also mean choosing different service providers that are less convenient if you deem the easy ones too risky. If you're not willing to do that (aka: switch away from gmail if you want js disabled everywhere) and you still want to complain... I find it hard to treat you seriously.
> It's your responsibility to make sure you trust that entity, and do your due diligence.
What does this entail? I mean, ask the average person if they trust the New York Times, the London Stock Exchange, or Spotify. Those are well-known names - sure we trust them. We trust that, as an organization, they are not plotting to steal our identities.
But trusting them means trusting their business people, their IT people, and their advertising partners, not only to be moral but also to be competent. And whoops, all of them have served malvertising in the past.
Nobody has the time and expertise to evaluate every site's JavaScript every time they visit. The "due diligence" you describe would be a very specialized full-time job.
Whereas turning off JavaScript in the browser takes about 10 seconds.
> It's your responsibility to make sure you trust that entity, and do your due diligence.
> What does this entail?
My whole point is that that's up to you to decide. No one else can make that choice for you.
The VAST majority of people have decided that the risks they face today are worth it, and continue to use the web with js enabled.
If you're not one of them, I absolutely respect that decision, but it means you'll have to accept that companies are making financial and security based decisions based on the behaviors of normal people.
That means that when spotify (and lets be honest, every other streaming service) doesn't work without js, you go somewhere else, and use something different.
That's the whole point I'm making. You can make any decision you'd like with regards to your own security, you can make any decision you'd like with regards to the sites you visit. But that site is free to act in it's own interests, including adding features and services that target the majority of their uses.
Why does this matter in the context of this discussion?
If you choose to visit that news site, you're trusting their web developers. You can always manually go and setup tools and systems to block those 3rd party requests (like I mentioned earlier, an ad blocker is a great first step, because it's easy and automatic). If you're not willing to take those steps...
> Pushing JavaScript everywhere increases the attack surface for every single user on the web.
I understand where you're coming from, but most users browse the web with Javascript = on. Even as a NoScript user I have Google whitelisted because most of their services are unusable without Javascript. Even automated tools have good Javascript engines now thanks to headless mode in popular browsers.
I suspect the next steps in browser security will not be to blanket-deny scripting, but instead focus on containers and sandboxing to make script-based attacks less worthwhile.
Does anyone know of a good way in NoScript to block say, facebook.com or google.com, except when I am on those domains specifically? When I am using FB I do want it to work.
I am not talking about merely enabling JavaScript. I am talking about normalizing more and more APIs accessible to every website I visit. Sound. Canvas. 3D. Local storage.
Then just get your wallet out to use the ATM in the dodgy neighbourhood and put it away again. You just need your wallet for the ATM in the dodgy neighbourhood.
> You're shifting the responsibility from yourself to a different entity for the choices you're making. The single safest thing you can do while using the web is to simply be aware of what you're clicking on, and what sites you visit.
This seems like a fundamental misrepresentation of how malware is distributed, and how privacy is compromised. People are responsible for the sites they choose to visit. They're not responsible for what those sites serve them, because they can't evaluate it until it's already been served. I don't know what a page will serve me until I visit that page. I can't.
Holding people responsible for whatever content they're served on a page is the same sort of "suck it and see" logic we rightly rejected with "by opening this package, you have consented to the terms of this license". It's a concept that's fundamentally incompatible with informed agreement.
If you want to hold people responsible for clicking "crack DRM now!" ads on the Pirate Bay, fine. But malware doesn't necessarily require outbound clicks, and doesn't necessarily come from dubious sites. Forbes locked out adblockers and served malware through their ad network. Xfinity, the NYT, ebay, Youtube, the Atlantic, and a dozen others major sites have served malware. Newegg, British Airways, and probably Ticketmaster were hit by Magecart, which infected even users with adblockers running.
Why do I disable Javascript? It's not because I don't think I'm responsible for my safety online. Precisely the opposite - it's because I'm not relying on other parties! Magecart was running on major sites two months ago. Adblock, an up-to-date browser, and responsible surfing didn't keep people safe, but uBlock did. A framing where users are accepting any code that ever appears on any site they visit is a framing where we all ought to abandon the internet outright.
>"When your username and password are entered on Google’s sign-in page, we’ll run a risk assessment and only allow the sign-in if nothing looks suspicious. We’re always working to improve this analysis, and we’ll now require that JavaScript is enabled on the Google sign-in page, without which we can’t run this assessment."
Is the idea that an actual browser will be able to have a fingerprint whereas a bot would not? Is the check for a javascript a way to short-circuit responding to a non-browser based request? It wasn't clear to me.
This is actually surprising enough that I'm glad to hear it even as an anecdote.
My experience with changing devices or cities (or god forbid both at once) is that it always requires further authentication, and often fails outright. I have an account which is simply disabled because I didn't set a recovery phone # or email and then changed machines. Everyone I've ever discussed the topic with has described similarly pervasive problems.
Which makes me wonder: what's so different between usage patterns? Obvious Google's auth approach is working for lots of people, so what's distinctive about this block of users who it's constantly failing for?
No, the password is whatever you send over the wire. If a website processes your attempt to type "password" into "5f4dcc3b5aa765d61d8327deb882cf99" before sending that to the server, then your password for that website is 5f4dcc3b5aa765d61d8327deb882cf99. That's what the server sees and how it recognizes you. The only effect of this is to make it less likely that the user knows his own password.
If user password is "passsword" he may be reusing it across 50 other websites. If you leak information that "password" is linked to "email@gmail.com" I can hack the 50 other websites. If you never knew that the user password is "password" you can not leak it and I can not use it to log in into 50 other websites. Leaking "5f4dcc3b5aa765d61d8327deb882cf99" is useless to hackers, because he cant go and use it to login into another website.
So, there are properties that differentiate "password" and "5f4dcc3b5aa765d61d8327deb882cf99", even if for the server it's all the same.
The distinction you're trying to draw vanishes as soon as this becomes a standard practice. Passwords are already stored hashed and salted. They get compromised anyway, because the data is valuable. Under the circumstances you describe, cracking 5f4dcc3b5aa765d61d8327deb882cf99 (which takes less than a second) is just as valuable as cracking a password database entry is now, because the underlying issue -- reuse of credentials -- hasn't gone away. (In fact, you're encouraging it, so it's probably somewhat worse.) As long as people are reusing credentials across multiple websites, those credentials will have value greater than that associated with their use on any particular site, and other people will put in the effort to crack them. Even when you're generating and submitting a cryptographically secure salted hash, you haven't improved on the situation now, where databases store a secure salted hash of the password.
> Damn right you don't let random people drive your car! just like I expect you not to click every link you see!
The difference is that I can interact with any number of people, yet only trust a few to drive my car.
You seem to suggest that I should trust everyone I interact with to drive my car, and since that's risky, I should limit my interactions to a few people.
> You're shifting the responsibility from yourself to a different entity for the choices you're making.
Not trusting a site's code is taking responsibility for what it might do to me. Trusting their code is giving them the responsibility to do what's right.
> The single safest thing you can do while using the web is to simply be aware of what you're clicking on, and what sites you visit.
This is good, practical advice for non-tech people. But fundamentally there is no reason the web needs to be unsafe. Viewing a series of hypertext documents is safe, no matter who wrote them. The web is totally safe if you browse it using curl. It's only when we assume that "of course you're going to run that stranger's code" that things become dangerous.
It's great that we can have web applications. It's not great if every page is an application. There should be an explicit step from "I'm casually looking at your page" to "now I want to trust you and run your code".
> That said, modern browsers do a really, really good job at isolating the code running in that page from anything you care about.
That code can't wipe my hard drive, but it can track me everywhere if I let it.
The reason we need content security policies and cross-site request forgery tokens and cross-site scripting protection etc, etc is that our browsers are constantly eval'ing whatever code they're given.
76 comments
[ 2.8 ms ] story [ 156 ms ] thread> This is the login page - users are typing in a long term stable identifier already!
There are so many other considerations at work here though, and I can't imagine that they're not obvious to you as well? For starters, we're creatures of convenience, and this makes it significantly inconvenient to block google scripts on other websites even when not signed in. It also guarantees that you have the chance to produce a (likely unique) JS-based fingerprint of every google user that can then be used for correlation and de-anonymization of other data.
But really the most basic point that probably makes folks here suspicious: if this were really only about preventing malicious login attempts by bots, then why not give users a clear, explicitly stated choice: either JS or 2FA.
They already pop up messages trying to trick you into logging in to "adjust your settings" or "improve your privacy" or some such.
That is to say, in the long run, it will be interesting if this actually reduces malicious use. Seems like it would be just as easy to avoid.
Quick poll: how many of you rely on Javascript for your income?
I am serious, I've been using gmail since 2004.
I realize some day my main account is going to be permanently inaccessible just because I will be in the "wrong" country or will be using the wrong browser in the wrong cafe.
There should be no need for Javascript with proper 2FA.
Your algorithms already make me solve ridiculous captchas "some" of the time.
https://support.google.com/accounts/answer/6010255
But just as you said, they are giving it away for free, so it is technically theirs, we are not paying customers. (Except for G-Suite users)
This would be accurate, if watering hole attacks[1] weren't a thing.
[1]: https://en.wikipedia.org/wiki/Watering_hole_attack
To reframe - my statement is akin to saying: the single safest thing you can do while driving is to pay attention to the road.
And you responding with: "This would be accurate, if trees falling on you weren't a thing."
Sure it's a risk, it's not the primary risk.
It's frankly stunning how much the ecosystem has changed just over the last 5-10 years. And I mean that as a developer who works in the security industry with a focus on browsers/extensions. It's ludicrous how much more secure the web of today is over the web of the past.
That said, it's not yet secure. There's always a risk/reward decision for using the web, especially around HOW you - the user - uses the web.
So to make an analogy: The infrastructure in place between root authorities, the IETF, browser vendors, ISRG (Let's Encrypt is just one), and website developers has done a DAMN good job in making the web less vulnerable than it was.
It's a nicely paved two lane road that goes nearly everywhere.
That said, you are interacting with the entity hosting the site you visit, NOT THOSE GROUPS, when you visit a site.
It's your responsibility to make sure you trust that entity, and do your due diligence.
Just like I wouldn't try to drive my crappy 1998 Mazda Protege offroad - It's dangerous and I would be unprepared.
Its your responsibility to make decisions for yourself (or at least I fucking hope it is... that's a fundamental aspect of a democratic society that I STRONGLY believe in). That means living with the consequences.
It can also mean choosing different service providers that are less convenient if you deem the easy ones too risky. If you're not willing to do that (aka: switch away from gmail if you want js disabled everywhere) and you still want to complain... I find it hard to treat you seriously.
What does this entail? I mean, ask the average person if they trust the New York Times, the London Stock Exchange, or Spotify. Those are well-known names - sure we trust them. We trust that, as an organization, they are not plotting to steal our identities.
But trusting them means trusting their business people, their IT people, and their advertising partners, not only to be moral but also to be competent. And whoops, all of them have served malvertising in the past.
Nobody has the time and expertise to evaluate every site's JavaScript every time they visit. The "due diligence" you describe would be a very specialized full-time job.
Whereas turning off JavaScript in the browser takes about 10 seconds.
> What does this entail?
My whole point is that that's up to you to decide. No one else can make that choice for you.
The VAST majority of people have decided that the risks they face today are worth it, and continue to use the web with js enabled.
If you're not one of them, I absolutely respect that decision, but it means you'll have to accept that companies are making financial and security based decisions based on the behaviors of normal people.
That means that when spotify (and lets be honest, every other streaming service) doesn't work without js, you go somewhere else, and use something different.
That's the whole point I'm making. You can make any decision you'd like with regards to your own security, you can make any decision you'd like with regards to the sites you visit. But that site is free to act in it's own interests, including adding features and services that target the majority of their uses.
You have not lost that control.
Why does this matter in the context of this discussion?
If you choose to visit that news site, you're trusting their web developers. You can always manually go and setup tools and systems to block those 3rd party requests (like I mentioned earlier, an ad blocker is a great first step, because it's easy and automatic). If you're not willing to take those steps...
Don't use the site.
I understand where you're coming from, but most users browse the web with Javascript = on. Even as a NoScript user I have Google whitelisted because most of their services are unusable without Javascript. Even automated tools have good Javascript engines now thanks to headless mode in popular browsers.
I suspect the next steps in browser security will not be to blanket-deny scripting, but instead focus on containers and sandboxing to make script-based attacks less worthwhile.
This seems like a fundamental misrepresentation of how malware is distributed, and how privacy is compromised. People are responsible for the sites they choose to visit. They're not responsible for what those sites serve them, because they can't evaluate it until it's already been served. I don't know what a page will serve me until I visit that page. I can't.
Holding people responsible for whatever content they're served on a page is the same sort of "suck it and see" logic we rightly rejected with "by opening this package, you have consented to the terms of this license". It's a concept that's fundamentally incompatible with informed agreement.
If you want to hold people responsible for clicking "crack DRM now!" ads on the Pirate Bay, fine. But malware doesn't necessarily require outbound clicks, and doesn't necessarily come from dubious sites. Forbes locked out adblockers and served malware through their ad network. Xfinity, the NYT, ebay, Youtube, the Atlantic, and a dozen others major sites have served malware. Newegg, British Airways, and probably Ticketmaster were hit by Magecart, which infected even users with adblockers running.
Why do I disable Javascript? It's not because I don't think I'm responsible for my safety online. Precisely the opposite - it's because I'm not relying on other parties! Magecart was running on major sites two months ago. Adblock, an up-to-date browser, and responsible surfing didn't keep people safe, but uBlock did. A framing where users are accepting any code that ever appears on any site they visit is a framing where we all ought to abandon the internet outright.
>"When your username and password are entered on Google’s sign-in page, we’ll run a risk assessment and only allow the sign-in if nothing looks suspicious. We’re always working to improve this analysis, and we’ll now require that JavaScript is enabled on the Google sign-in page, without which we can’t run this assessment."
Is the idea that an actual browser will be able to have a fingerprint whereas a bot would not? Is the check for a javascript a way to short-circuit responding to a non-browser based request? It wasn't clear to me.
My experience with changing devices or cities (or god forbid both at once) is that it always requires further authentication, and often fails outright. I have an account which is simply disabled because I didn't set a recovery phone # or email and then changed machines. Everyone I've ever discussed the topic with has described similarly pervasive problems.
Which makes me wonder: what's so different between usage patterns? Obvious Google's auth approach is working for lots of people, so what's distinctive about this block of users who it's constantly failing for?
So, there are properties that differentiate "password" and "5f4dcc3b5aa765d61d8327deb882cf99", even if for the server it's all the same.
The difference is that I can interact with any number of people, yet only trust a few to drive my car.
You seem to suggest that I should trust everyone I interact with to drive my car, and since that's risky, I should limit my interactions to a few people.
> You're shifting the responsibility from yourself to a different entity for the choices you're making.
Not trusting a site's code is taking responsibility for what it might do to me. Trusting their code is giving them the responsibility to do what's right.
> The single safest thing you can do while using the web is to simply be aware of what you're clicking on, and what sites you visit.
This is good, practical advice for non-tech people. But fundamentally there is no reason the web needs to be unsafe. Viewing a series of hypertext documents is safe, no matter who wrote them. The web is totally safe if you browse it using curl. It's only when we assume that "of course you're going to run that stranger's code" that things become dangerous.
It's great that we can have web applications. It's not great if every page is an application. There should be an explicit step from "I'm casually looking at your page" to "now I want to trust you and run your code".
> That said, modern browsers do a really, really good job at isolating the code running in that page from anything you care about.
That code can't wipe my hard drive, but it can track me everywhere if I let it.
The reason we need content security policies and cross-site request forgery tokens and cross-site scripting protection etc, etc is that our browsers are constantly eval'ing whatever code they're given.