Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript is now required to sign in to Google

security.googleblog.com

Post reply on HN
Print view View original

151–160 of 529 posts

Re: JavaScript is now required to sign in to Google

#151

Post by tzs »

kibwen wrote: post #71
mrep wrote: post #57

Earlier quoted context omitted.

Do you have a better solution for differentiating yourself as an actual user from a robot spammer?

Being allowed to pay for services with money, rather than being required to pay for services with your personal data. I browse the web via a proxy when I'm on public wifi, and Google is nigh unusable with how many captchas it forces you to solve to do a single Google search. Fortunately Bing and DDG still work, for now.

> Being allowed to pay for services with money, rather than being required to pay for services with your personal data

One possible big disadvantage for a site owner in letting people pay with money instead of data is dealing with taxes.

I'm not actually sure how most jurisdictions tend to classify it when someone comes to your site and you charge them to access your content. My guess would be it would be taxed the same way they tax digital goods such as downloadable software that does not include any physical components.

For such goods most jurisdictions that tax them seem to base the tax on the buyer's location rather than the seller's location, so the seller has to deal with charging the appropriate tax and filing returns for potentially a large number of jurisdictions.

If the seller is providing the content for "free" and making their money selling visitor data to advertisers then their income will probably only be subject to taxation in their own jurisdiction. It will simply be ordinary business income.

Re: JavaScript is now required to sign in to Google

#152

Post by diminoten »

hueving wrote: post #147
diminoten wrote: post #98

Earlier quoted context omitted.

Yeah, because permissions, sandboxing, and access controls don't exist. Oh wait, they do, and they work, so you're wrong.

No, they don't always work. We have bullet proof vests but it's still not safe to put one on and have someone start shooting you.

Do you wear a bulletproof vest every time you go outside? No? Interesting.

Re: JavaScript is now required to sign in to Google

#153

Post by userbinator »

dane-pgp wrote: post #144
throwawaymath wrote: post #110

Earlier quoted context omitted.

> Browser exploits are almost all JS-based, and even the few that aren't, are in practice deployed using obfuscation involving JS, to make analysis and detection harder. Go take a look through Pwn2Own. Most browser exploits do not involve JavaScript. JavaScript can be a delivery mechanism for a certain class of payloads, but it's not the substantial weakness in browser vulnerabilities (as opposed to web application v…

The security bugs found during Pwn2Own are usually kept under embargo, and only published later by the browser developers. Here's an article about a Chrome bug found in 2017's Pwn2Own: https://www.computerworld.com/article/3186686/web-browsers/g... and it does involve JavaScript. Could you provide some recent examples of the sort of browser exploits you mean, that don't require JavaScript? (I assume you're not includ…

The Firefox Pwn2Own... https://www.computerworld.com/article/3183264/security/mozil...

...is also JavaScript-related: https://bugzilla.mozilla.org/show_bug.cgi?id=1348168

Re: JavaScript is now required to sign in to Google

#154

Post by throwawaymath »

userbinator wrote: post #116
throwawaymath wrote: post #110

Earlier quoted context omitted.

> Browser exploits are almost all JS-based, and even the few that aren't, are in practice deployed using obfuscation involving JS, to make analysis and detection harder. Go take a look through Pwn2Own. Most browser exploits do not involve JavaScript. JavaScript can be a delivery mechanism for a certain class of payloads, but it's not the substantial weakness in browser vulnerabilities (as opposed to web application v…

JavaScript can be a delivery mechanism for a certain class of payloads That's exactly what I'm saying --- in the real world, exploits tend to be wrapped in JS even if they don't technically need it. but it's not the substantial weakness in browser vulnerabilities Then what is? My real-world experience also correlates.

> Then what is? My real-world experience also correlates.

HTML (non-JS) parsing, memory corruption, image processing, filetype validation and process isolation/sandboxing.

Re: JavaScript is now required to sign in to Google

#156

Post by bonsai80 »

"But, because it may save bandwidth or help pages load more quickly, a tiny minority of our users choose to keep it off"

Yeeaaah Google. Thaaaat's why we don't load JavaScript from you ;)

I get it they can't make this opt-in and expect many to use it, but it'd be nice to see an opt-out be made available.

Re: JavaScript is now required to sign in to Google

#157

Post by throwawaymath »

dane-pgp wrote: post #144
throwawaymath wrote: post #110

Earlier quoted context omitted.

> Browser exploits are almost all JS-based, and even the few that aren't, are in practice deployed using obfuscation involving JS, to make analysis and detection harder. Go take a look through Pwn2Own. Most browser exploits do not involve JavaScript. JavaScript can be a delivery mechanism for a certain class of payloads, but it's not the substantial weakness in browser vulnerabilities (as opposed to web application v…

The security bugs found during Pwn2Own are usually kept under embargo, and only published later by the browser developers. Here's an article about a Chrome bug found in 2017's Pwn2Own: https://www.computerworld.com/article/3186686/web-browsers/g... and it does involve JavaScript. Could you provide some recent examples of the sort of browser exploits you mean, that don't require JavaScript? (I assume you're not includ…

Sure: https://www.cvedetails.com/vulnerability-list/vendor_id-1224.... Also look at Google Project Zero writeups, and similar CVE details for Firefox and Safari.

Some are related to JavaScript (notably, it's hard to exploit V8 if the browser isn't processing any JavaScript!). But the vast majority are memory corruption and sandbox escape issues.

Disabling JavaScript insulates you from a nontrivial - but nontheless minority - subset of browser vulnerabilities.

Re: JavaScript is now required to sign in to Google

#158

Post by lovich »

magicalist wrote: post #143
cesarb wrote: post #137

Earlier quoted context omitted.

Hacker News works perfectly fine without Javascript. In fact, I don't think I've ever enabled Javascript here on Hacker News.

> Hacker News works perfectly fine without Javascript. keyword being " too ". > In fact, I don't think I've ever enabled Javascript here on Hacker News. I mean, that's super, but it's just one more point in the column of how HN's population is out of touch with any regular person. It's really annoying to wait for the page reload on even a fast network, and good luck finding your place again if a thread is even modera…

Ctrl f. But yes hacker news doesn't have the greatest UI.

Back to your main point. I don't think it's out of touch. It's different information or values. Do you think it's not annoying for me to not have JavaScript and have slow or broken pages? I know and feel the same thing, and I imagine anyone using no script does as well. It's just not worth it to me to let privacy be degraded for some speed.

I think this is due more heavily to being more informed about the situation than the average person, rather than different values. When Facebook starting getting in the news about all their privacy violations, Facebook MAU went down and the number of accounts deleted went up. That indicates that once people are aware of what is going on, they make similar choices about interacting with the companies.

The difference between many people on hacker news and the average populace is that we can both install something like noscript, and have a rough idea of how to interpret the options on it.

Re: JavaScript is now required to sign in to Google

#159

Post by pwg »

the_clarence wrote: post #130
vivekseth wrote: post #53

Earlier quoted context omitted.

Hashing passwords client side has no benefit if a site uses HTTPS. If a site uses HTTP, then hashing the password client-side and sending it up to the server is equivalent to sending a clear text password. If an attacker can already read your traffic, what is stopping them from using your password's hash to log-in to your account?

You are wrong. Client-side hashing CAN be a silly thing, but it can also prevent a (compromised) server from seeing your password which you probably use on other websites (which is what most people do unfortunately).

>but it can also prevent a (compromised) server from seeing your password

If the server is compromised, then there is no protection of your cleartext password at all. This is because the entity that compromised the server can replace the original JS with anything, including new JS that sends your cleartext password off to their own host as you type each character.

The only activity on your part that can save you against comprimised servers is having a unique password per server (i.e., not reusing any passwords).

Re: JavaScript is now required to sign in to Google

#160

Post by greycol »

bluetidepro wrote: post #10

I'm genuinely curious who actually browses the web in 2018 with JS disabled, though. Wouldn't 99.9999% of the web basically break? Like, if you do, do you only stick to a few basic sites, or?

I'm not sure if it quite qualifies as browsing with JS disabled but I run UMatrix with the default settings set to disable all scripts on a site. Then I've set some common domains I trust that greatly improve usability (things like ytimg, paypal, some common 3rd party scripts).

I'd say I browse the web normally. Plenty of sites load normally with scripts disabled (and may even be more pleasant to browse). Maybe a 25 to 40% of sites I hit I'll happily enable 1st party scripts and a couple of known CDNs that'll will be enough to have the site working. For I'd say 5% or less of sites I'll have to actually engage and think if the calls to a 3rd party api are required or if the cloudflare/amazon are actually part of the domain and there for a good purpose or may be being used to serve up nefarious code.

One of the things to consider about the above numbers is that they only really apply for the first time I visit a site. With exceptions for when a site changes how it's implemented (or a3rd party script calls a new domain) which is nice to know anyway. (Or when the tool I'm using to block scripts changes (3-4 times over the last 15 years + another couple for not transferring whitelist data to new machines)).

I wouldn't really recommend my approach as something to get into for 2 main reasons. Firstly because the web does work much nicer when you just turn scripts on and say 'to hell with the privacy and security concerns'. Secondly there is a fair bit of otherwise useless knowledge built up over the years of doing this that mean this set up is significantly less onerous than it would be for someone who only just starts doing it and needs to look up every 3rd party domain.

Having said that I would highly recommend that you should install some script management with the default more permissible settings (rather than my more draconian ones) as it breaks very little, takes little effort to fix most of the things it does break and will stop well known tracking and malicious sites.

Post reply on HN