Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"I am not convinced that removing any optimization which can be used in a timing-based side channel is sustainable." basically boils down over two decades of JavaScript (now WebAssembly) API and language design, where one subset of the committees fervently argues against any feature or primitive that could possibly be used to acquire timing information, no matter how useful. It's tough, because they are ALSO trying to make sure any advertiser on the planet can run code on your PC without your permission, so it is pretty important to stop that code from using timing side channels to capture your credit card number or something. Once it was proven that JavaScript could trigger rowhammer (I remember having debates about this during wasm spec meetings at the time when it was still speculative), that kind of guaranteed that the side-channel people would remain in control, I think. SharedArrayBuffer is the biggest example - we basically had safe multithreaded memory access available in browsers but it got disabled due to spectre/meltdown, and we only started getting it back relatively recently with lots of additional constraints to try and make it "safe". Want high-precision timestamps? Not anymore you don't, it's a side-channel!

Similarly, when a new browser update goes out it may or may not make all the web apps you rely on slower (or break them), so any web benchmarking also needs to be re-run from scratch on a regular basis. New Chrome and Firefox releases "ride the trains" every 6 weeks or so, and they quietly push changes to the browser more frequently than that which can occasionally impact perf or behavior too.



Now, if it were limited to browsers, or even to desktop computers...

"Security by default" affects, by default, also trusted workloads. Games, desktop editing software, word processors, spreadsheets running dumb totals in big tables, and virtualized computing workloads running in the cloud (where it has a serious financial impact for whoever pays the cloud bill). All of them pay the Javascript tax. Worse, there doesn't seem to be any solution in sight, we have become too reliant on the damn thing.


> virtualized computing workloads running in the cloud

as trusted workloads?


It's understood that multi-level security (MLS) is extremely hard to do, wanting MLS capabilities (which enables separation of co-located, hostile programs) while also entertaining high performance simply is not going to happen.

The problem is the obvious solution - get rid of the hostile programs! [i.e. removing the capability of any website to run code from anywhere on your machine] - has been ruled out from the start. Now we are only left with non-obvious solutions and bad trade-offs. Things like CPUs with fast/slow microarchitectures on the same die so you may run the JS engine on a slow core that has a harder time messing with things, for example. How many engineer-millenia are poured into trying to make this work?


> It's understood that multi-level security (MLS) is extremely hard to do

Has it even been tried? Given that we do need to protect against info disclosure vulns, even a rough attempt at proper MLS would be way more feasible than treating all programs as untrusted/hostile or all data as equally sensitive.


How do you get rid of the hostile programs?

If one could get rid of the hostile people, we wouldn't need passwords. Login is enough. Much easier to develop webapps. But we can't get rid of the hostile people and we can't get rid of the hostile programs.

The only semi-successful way to get rid of the hostile programs is Apple-style walled garden. But even there malware happened. And giving up all your freedom for that kind of safety is like going to the jail voluntarily to be safe from the outer world. I don't think that this approach would work for everyone.


The silent browser updates that break things are so much fun. Earlier this year Chrome pushed a change that throttled JS timers severely on inactive tabs, and everything that used SignalR over websockets broke.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: