[VieElm]

Well it's lack of security makes it probably not an OS you'd want run untrusted code on. Like if you made a browser for it I'm not sure it would be easy to sandbox it to protect your computer from serious harm. Any program can read from and write to any part of memory if I recall correctly.

[x5n1]

on the other hand the chances of coming across a virus made for TempleOS is rather unlikely.

[S4M]

As long as it has very little users who are all super tech savvy.

[MichaelGG]

Please explain how that's different from today on other OSes. A JavaScript exploit or other browser corruption is still an issue on current browsers, right? (I only see one Firefox process on my machine, so I'm gonna guess if you break the browser, you have code exec with my user access level.)

[masklinn]

A Javascript browser exploit is still an issue, however it won't usually be able to read and write to kernel memory. TempleOS runs entirely in ring0. That means any exploit whatsoever and the exploiter can not just access some of your data, they own your machine entirely from the kernel up.

http://www.templeos.org/TempleOS.html is a good explanation of the point and purpose of the project, one which is reasonable and makes perfect sense. It explains why a TempleOS machine should not ever run unchecked third-party programs (let alone be on any kind of network), but could be an excellent OS to use on a remote abandoned island.

[lucozade]

> you have code exec with my user access level

That's the difference. TempleOS has no access restrictions. It's not intended for either multiple users or networking so it really hasn't got even basic security e.g. processes having separate address spaces.

For all that, it's still pretty impressive but it wouldn't be suitable for a general purpose OS for most people.

[kpcyrd]

I'm not sure why this is getting downvoted, the point is very valid. In most cases it's trivial to get root if you can tamper with the environment of a user that gets root at some point.

https://xkcd.com/1200/

[mikeash]

Chrome runs the rendering engine and JavaScript stuff in a sandboxed process that has almost no privileges. Escaping from that is possible if there's a vulnerability in the sandbox, but now you need to combine at least two vulnerabilities which makes it substantially harder.