Hacker News Reader

Comment by tedunangst | Hacker News Reader

I only have so many CPUs, and I visit more websites than that.

Consider disabling javascript on websites by default and only allowing it on those that you trust. e.g. uBlock origin has that built in. You'd be surprised how much still works perfectly fine and of cause, which sites break for no good reason.

I want an extension that disables JavaScript by default and then allows me to enable and disable JavaScript for the current site that I’m visiting (and all of its dependencies; I don’t want to deal with enabling it also for its cdns etc) with only one click and then remembers my setting. Does that exist?

Umatrix from the author of ublock origin can do this. Not with a single click (it'll take two, one to enable and one to tell it to remember) but it's very close.

https://addons.mozilla.org/en-US/firefox/addon/umatrix/

Clarifying, for those unfamiliar with it:

uMatrix permits enabling or disabling JS (and other website features: images, CSS, media, frames, XSS, ...) by domain or subdomain, including default allow/deny permissions should you choose.

You can also temporarily enable or disable specific permissions, and save those changes permanently should you choose.

It's fiddly, but good fiddly.

NoScript used to do it in 1 click. Now that it's a Web Extension, it takes two.

You can do that in uBlock Origin, just enable advanced mode then you can block 1st + 3rd party scripts across all domains in two clicks..

https://github.com/gorhill/uBlock/wiki/Per-site-switches#no-...

This actually doesn't make sense. Any trusted code can absolutely run on a trusted processor, and the usual timesharing methods will handle your stackoverflow tabs.

So you use the same password for SO and HN?

I have no idea what that means relative to this conversation. Either I'm out of my depth or we're talking past each other. Either way, no big deal.

If you use different passwords, you must believe they are in different trust zones, and the usual time sharing methods won't work, in light of this and many other attacks. You will need separate CPUs as suggested by rayiner.

You can run trusted code on one processor and untrusted on another. The untrusted processor must not perform speculative execution. It'd be slow but should solve the presented conundrum.

Their point is untrusted code can still have private info (I don't want a random website to be able to steal my private key or my info like credit cards or password in other tabs), so you need a new core for each website, which is obviously impractical.

My point is that if you disable speculation on the insecure core then the websites can share without this class of exploit being a risk factor. There my be other vectors for accessing the data of colocated processes.

Unfortunately, being slow is just not acceptable in a decent portion of scenarios. Web developers won't start writing 5x faster sites, and cloud providers won't like needing 5x more hardware to serve the same amount of virtual CPU performance. (5x being my random guess of the performance decrease from losing speculative execution & co; it'd likely be even worse, especially combined with the fact that manufacturers would have to design a completely new chip)

They aren’t in different trust zones, because there’s nothing to trust in either of those. The reason for using different passwords is to minimize the losses when they leak.

They need to be in different trust zones unless your willingness to enter a credit card into any website means you’re willing to allow every other website you may be visiting to observe that input. Ditto viewing bank information etc.

That’s the point: you can’t just pile every website into the same zone, and if you did pile them into the same zone, then using a different password for x.com and y.com is to some extent pointless because x can observe y’s password input and vice-versa.

(disregarding the fact that in current computing architectures “just put all the untrusted stuff on one core” is probably an insufficient solution due to shared caches anyways, no indeed nothing in this attack requires “sharing a core”)

I’m not entering credit card info though. And even if I did, it’s not very security-sensitive - in the worst case the bank will give me back my money stolen from the card.

If you truly never enter credit card info on the web, or truly have zero expectation that other tabs shouldn't be able to spy on that credit card info when you do, then frankly you're so outside the range of normal people's expectations and behaviours that I don't think basing security architecture around what you do or don't do makes any sense whatsoever.

Reply on news.ycombinator.com