Comment by lyxsus1 | Hacker News Reader

Comment by lyxsus1 | Hacker News Reader

Parent Full thread

In that case use should understand, that you need to find a way to disable all browser media, css and html rendering. Because they all process data from untrusted source.

The thing is, executing javascript is not that much different from rendering all those things, and anytime you allow your computer to do some computations using any program on data from untrusted source, it's a risk. There might be even bugs in decompression library, so let's not download anything.

There were plenty exploits that used html/css parser bugs with no JS at all. I think I even heard about case where guys hacked into car using radio and a bug in mp3 decoder.

And it won't get any better unless we maybe start writing on something more safe, like Rust instead of c/cpp.

The way JS engines are implemented and used makes it an easier and more obvious target, but not really enough to just turn it off by default. Doing so is just a superstition, we could make just a little step further and rip off all our computers IO to be safe.

Running browser in VM might be a better idea, but again, in theory one could escape VM.

Sadly, it feels like we're at least a couple decades away from owning secure systems, if that's even possible. Ha, I just thought, that we might get strong AI before that :)

> In that case use should understand, that you need to find a way to disable all browser media, css and html rendering. Because they all process data from untrusted source

There's a big difference between processing data from an untrusted source and allowing active code from an untrusted source to execute.

> There were plenty exploits that used html/css parser bugs with no JS at all.

True, but I'm not talking about exploits. I'm talking about code running as intended by the authors. Tracking and telemetry scripts are prime examples of what I'm talking about.

> Running browser in VM might be a better idea

That's a larger pain than simply disallowing scripting, and does nothing about things like tracking.

> There's a big difference between processing data from an untrusted source and allowing active code from an untrusted source to execute. With all respect, there's very little difference between code and data.

> That's a larger pain than simply disallowing scripting, and does nothing about things like tracking. Unless you live don't live in EU, your data is guaranteed to be tracked, stored and if any value is found, it's being sold.

> With all respect, there's very little difference between code and data.

I disagree entirely with this. The difference is clear -- data is not operational on its own, it requires something to operate on it. So in terms of trust, I only have to trust the software operating on the data -- and I have many choices of software to use to do that.

Code is operational, and I have to trust the code itself rather than a tool.

> Unless you live don't live in EU, your data is guaranteed to be tracked, stored and if any value is found, it's being sold.

I don't live in the EU, and this is the exact sort of attack that I'm doing my best to protect myself against.

> I disagree entirely with this. The difference is clear -- data is not operational on its own, it requires something to operate on it. So in terms of trust, I only have to trust the software operating on the data -- and I have many choices of software to use to do that.

Well, that's what I strongly disagree with. You either oversimplify it for practical purpose (which exactly what I wanted to point out making this statement) or are simply wrong on a fundamental level. Distinction between data and code is artificial. It really helps us when we programs, but hurts when we think about security issues and that mindset in a way is an exploit itself.

If you look into security-related updates in any mature interpreted language, you'll see that 99% of them are related to data processing, not some restriction being forgotten. Think about good-old stack overflows errors, where your data suddenly becomes a code, or numerous exploits in simple text formats, xml parsers or PDF nightmare.

Real security problems have very little to do with the fact that malicious data was carried by some executable code, they do just find without it. In fact, having so heavily-tested VM that there are, makes daily usage of average computer user much safer that it would be without it.

> I don't live in the EU, and this is the exact sort of attack that I'm doing my best to protect myself against. I didn't mean that new hysteria about being tracked by ads and browsers. It's a toothless issue, that poses no significant threat and we as community could entirely fix it in less than a year, I just don't think anybody's capable really cares. After all, if we can have some GDRP joke and that makes people feel better, why even bother?

I was really pointing that your traffic is compromised at ISP level and if you were a person of any interest, analysis could be bought at black market, just as your SMS could be intercepted without you knowing. It's business.

Oh, and don't let me start about hardware level, which we trust, but as it turns out, should not.

Reply on news.ycombinator.com