perhaps this is the worst possible abstraction to be protected by a security framework.

How is that? Per-process namespaces in Plan 9 seem like a good idea for isolation. "Everything is a file," but what is and isn't accessible can be managed on a per-process level.

In POSIX we only generally get a user/group level of granularity which seems to practically mean that only daemons are completely isolated.

Per process won’t be good enough in a different app that does legitimately need `/net`, just not when displaying file:/// links inside HTML pages.

I disagree. Use a second process that has a limited namespace where you've mounted only the local files you want an HTML document to be able to refer to and an IPC socket marked for exclusive use. The first process resolves file links and reads file contents via IPC to the second process.

I can see a way this would be useful to use the same abstraction to limit app/user web access to a single domain.

For instance the dropbox binary can only access "/home/dropbox" and "/net/dropbox.com" if this was more well-known/used.

This can be done with a proper capability system.

IMO not so much. Just assume all files are malicious unless accompanied by metadata saying otherwise. That is pretty much the status quo already.

Except we have some grandfathered file types that are implicitly trusted.

In the article, the remote file's contents were not malicious, but merely trying to access it was. That would require a very different security posture to "assume all files are malicious".

> the remote file's contents were not malicious

until ... one day ... they are!

And what about malicious metadata?

I don't think "everything is a file" is necessarily bad. What's worse is "every application I run has access to every resource that the OS gives my user access to".

Would be nice if the operating system could set up a fresh, temporary "user" for each application installed, and instead run the application as that user, who starts out with no access to computing resources. Maybe some existing systems already sandbox apps into their own unprivileged users, I don't know, but it would probably be very secure.

Modern operating systems can; there is quite granular control.

But often when such sandboxes are attempted, it turns out that it often became more complex than originally thought, and applications need many resources which were not originally considered, so they are given those resources, and very often those resources can be used again to construct more resources or otherwise to some measure escape the sandbox.

I believe this is how Qubes OS is supposed to operate.

On the contrary, it's very good design.

> perhaps this is the worst possible abstraction to be protected by a security framework.

I honestly don't understand how anyone with at least a basic understanding of how OSes are designed and operated could ever arrive at that conclusion. The layers of wrong assumptions required to support that assertion are in the level of "not even wrong" confusions.

Do you think it's true that bitcoin is the solution to a couple of problems that don't exist?

Again, I'm not a BTC fanboy, I don't even own any. But obviously it solves SOME problems - like how to transfer some sort of store of value across borders without using a bank. That's one of them.

It's not tulips and 100% useless. A digital currency is interesting to explore. It's interesting enough that institutions are stuffing their cash into it because they are fearing inflation, and the old school explanations of why we won't get inflation are now being questioned.

Don't ask me to forcefully argue for or against, there are many other people on this thread to argue both positions. But you can't say it has NO utility.

Hi, thanks for the reply, makes sense what you said. I am not looking for strong stances or arguing; I just want to expand my understanding. I get from you that institutions pour real money into it and they rely on bitcoin's scarcity to overcome inflation. Makes sense. However, I want to understand why using banks or FinTech companies for money transfer is so bad? Nowadays there are low fees, way lower than what Bitcoin offers today. And that is just one aspect. It's just an opinion but I feel that money transfer problems caused by banks are exaggerated, especially in developed countries. Can you explain why I might be wrong about it? I also do not own Bitcoin, my employer is not a bank and I do not have any involvement or desire to promote the banking or payments industry.

> However, I want to understand why using banks or FinTech companies for money transfer is so bad?

I've never done it, but when I lived abroad and I had to transfer money, I got fleeced by banks and then (a few years ago) there weren't really any alternatives. I don't have any skin in the game with Bitcoin, but I guess that left a foul taste in my mouth.

There've been other comments about Bitcoin that are a bit more nuanced and interesting, in one case there was a gentleman from Argentina making an impassioned case for the use over and against the polices of his government.

I think there's an element of institutional mistrust that Bitcoin claims - maybe wrongly, given how centralized it is - to solve.

Certainly the most important value proposition from the companies behind the established cryptocurrencies is the decentralized network for value transfers. No more "brokerage" firms. Getting rid of these feels like an emotional fulfillment; and today this beats pragmatism. Thanks for writing.

Exactly correct. You can recognize its not useless even if you don't like the thing.

Fully agree. Also, if you need to debug your code that runs in kubernetes pods, VS Code also smokes other IDEs. In my case, not only the API calls are forwarded from the cluster to my debugging session but I can also consume during debugging some Kubernetes services by using their DNS names. Just awesome.