Hacker News Reader

Comment by ggchappell | Hacker News Reader

I get annoyed when people are warned not to open some attachment. The real problem here is that in 2013 we're still using the flawed language of "opening attachments" -- as if running a native executable with full permissions is an action that belongs in the same category as viewing an image, reading a text file, or listening to music.

Well, it doesn't. This is a problem that should have been solved at the level of OS permissions/UI long ago. Why does a modern OS include UI functionality allowing a standard user to run an uninstalled executable in a non-sandboxed environment? There's no good reason for it.

In some cases the problem been solved (e.g., restrictions that allow only signed apps to be executed). But I guess none of those cases include Windows, its standard UI, and popular e-mail programs. :-(

View on HN

We only use that language because it's an order of magnitude easier to explain to novice computer users, and because as you stated, the problem still hasn't been fixed at the OS permissions / UI level.

A modern OS lets us do that because lots of users are the sole user of their PC and do not understand the idea of permissions.

People understand that webapps are safe, because they have less permissions.

That really isn't telling the whole story at all. Webapps have their own problems -- like no ownership or control over your data.

The best solution would be the one used by Linux: Separate Data and Software.

On Linux there is a specific flag that has to be set and is not set per default to make a file executable.

So if you run something, you know that you are running it as a program and not opening it as data.

Windows on the other hand marks everything as executable which begins with MZ and whichs filename ends in .exe or .com

Except in this case (original article) it was an executable inside a zip file.

In the normal case, unzipping a file on linux will result in the executable bit being restored if it was included on the original file.

This is normally what you want - imagine an app that was distributed (over https) as a zip file where you then had to go and manually add the executable bit to each relevant file.

But a zip file that was opened as an email attachment is largely indistinguishable from one that was opened from an HTTPS download (it need not be that way, but it is), so the OS has no reliable way to allow you to run executables you download in a zip, but not ones you received as an email in a zip file.

There are certainly ways around it, but the executable bit isn't really the solution here.

While that is useful, in Windows-land the result would only be another message box to click-through, asking if you wanted to make the file executable, which no average user would understand, and therefore just click OK. If they even took the time to read it before clicking through.

Better to sandbox any executables received from external sources.

The absence of that executable flag does nothing to protect you from using an existing executable and some data such as an interpreter and source code.

> On Linux there is a specific flag that has to be set and is not set per default to make a file executable.

Windows does too. It's called FILE_EXECUTE permission.

It just happens to grant them to everything by default, but the problem isn't the lack of the feature.

I believe this is what Bromium is doing with their "micro-VMs" - http://www.bromium.com/use-cases/overview.html

Reply on news.ycombinator.com