[madez]

If you stay with a system that is as open as possible from the lowest levels of the hardware to the highest level of the software, and if you airgap, and audiogap, and RF-gap the system permanently until it ceases to exist, you are pretty fine.

Also, more practically, two computers with different ISA and underlying hardware that compute the exact same high level semantics, that don't know each other but transparently share the necessary hardware (for example hardware random number generator), talking to the world through a simple electronic checker, that stops the system if both computers don't communicate exactly the same information bit by bit, is also pretty safe, even if you use backdoored computers. Just make sure both computers don't contain identical backdoors (which is not that difficult).

High and sufficient security in computer systems is practically possible. We just don't work at it. Instead we work on JavaScript and WebAssembly and proprietary hardware and software.

[orbital-decay]

The Spectre attack (for example) is an innovation in breaking complex systems. It's not just a hardware bug that can be easily spotted with a more cleverly designed process, or prevented with good security practices. It's a new way to look at the very general and basic concept (not implementation!) that was introduced years ago and was considered pretty safe for all these years.

It's the complexity of everything that we do with computers that needs to be addressed, not just the quality of software and hardware testing and exploit mitigation. Mitigation techniques can't stop every unknown exploit, just some of them; in a sufficiently complex system there always will be a way to break the system in an unexpected and conceptually new way. Besides, they are additional layers of complexity on their own, and you can't fight complexity with complexity.

[pas]

Not really novel in concept, but in implementation.

See also the responses: https://news.ycombinator.com/item?id=16083256

Especially "613.pdf" linked by NickPSecurity.

[conradev]

> JavaScript and WebAssembly

Isn't WebAssembly a huge step forward in the ability to distribute portable, high-performance, sandboxed code?

[madez]

Code, that is unreviewed, unaccounted and executed automatically. Now it shall be high-performance, too? Does the sandbox work? Does it really work? Are there no side channels? Are you sure? How do you make sure you don't take part in a DDoS attack or mine cryptocurrencies for somebody else? These are just points I can come up with spontaneously.

Besides that, the appification of the web is bad because it leads ultimately to dependency on software that is outside of the users control.

[the_duke]

This is all already true for Javascript, wasm doesn't change that much here.

[madez]

It makes the use-case for this type of code deployment wider and it's more effective at what it's already used for.

These are two reasons why developing and supporting WebAssembly is finally against the interest of the users.

[CyberDildonics]

How does it do that exactly? Anything you can do in wasm you can do in JavaScript, only was can do it faster. This freak out that some people have over wasm is bizarre to me on a technical level. I think it comes down to lots of JavaScript devs being threatened by more difficult languages being useful for web pages.

[madez]

I don't program in JavaScript.

> Anything you can do in wasm you can do in JavaScript, only was can do it faster.

It's faster and more flexible because it can easily be targeted by compilers. That is the problem. This might sound surprising. Allow me use an analogy to explain it.

Let's assume some new technology was invented to more easily breed cattle for meat production. I completely understand why some people would want that, and develop it. I think breeding and killing cows and bulls just to eat a steak is unethical. So, I would absolutely refuse to work on the technology, and I'd expect the same of everybody that cares about being ethical.

Now, coming back to JavaScript and wasm, it is used to deploy code in a way that takes the control of the software from the users to the developers. The deployed code is unreviewed, unaccounted, unsigned and executed automatically. I consider unsafe in the computing sense. So, I consider code execution on the web unacceptable. Since, wasm makes that easier and more efficient, I'm opposed to it.

On top of that I consider JavaScript a bad language. I'm worried by how much it's pushed as a teaching language.

[jhiska]

Or just use pen and paper. It's an easier tech for Joe Dilbert and easier for them to understand how to keep it secure.

[craftyguy]

Honestly, not really. You'd be surprised how much valuable information people leave laying on their desks. Or loose-leaf in a backpack that is half zipped. Or in their pockets. Or on their car seat. The list goes on.

[jhiska]

I am more aware than you might think, but not as worried about what can be stolen in a few hundred pages as what can be stolen in hundreds of thousands of documents.

I'm also not enthusiastic about how it's more secure from governmental snooping to mail a hard drive than it is to send its content over the Internet.

[iforgotpassword]

Hah so basically not at all more involved than when we still assumed modern platforms are just safe and trustworthy. Phew.

[madez]

At least the second part, the system of the two computers and the checker, is compared to even the very simplest parts of a modern computer laughibly simple.