The name is OpenLara (https://github.com/XProger/OpenLara ) and you can try out the WebGL build directly on your web browser on: http://xproger.info/projects/OpenLara/ . The web version works amazingly well on my Pixel 7a with touch controls (you have to click on the “go fullscreen” button) using Firefox as a browser.
Let me get this straight, you think running something in a browser with its sandboxed design, is somehow less secure than downloading executables off of GitHub?
Yes, because browser sandboxes will NEVER be as secure as kernel sandboxes.
(Run the browser in the kernel sandbox)
Touché.
I can check and validate the code I download from GitHub before I compile and run it. And I can be sure that the binary I compiled will always be the same. All that is not true with web apps, I can’t check the code before running (maybe I could with JavaScript but not with WebASM) and as the code gets delivered on the fly it always could be changed either on the server or by a third person in transit (TLS is not a impenetrable barrier, not with a default trusted authentication provider list that huge in all browsers).
That alone puts browser based application in a much higher risk category.
And when it comes to binaries: I can analyse those before running if I wanted to, again something I can’t with dynamic delivered code in the browser.
What’s the biggest code base you have ever reviewed? What’s the most recent TLS vulnerability you have encountered, as opposed to the last vulnerability in other parts of your OS? Code being swapped by the server, maybe, but are you saying you do a code review every time you update a package or dependency of some other project? This is only less secure in some inconceivably convoluted chain of events that no practical person could enact. No sane person does what you’re saying. Everyone has to trust someone else with code blindly at some point.
Yeah, Man in the middle attacks are completely uncommon and have never happened. You don’t need vulnerabilities in TLS itself but there are plenty of those, check the CVE list for 2023 alone: https://www.openssl.org/news/vulnerabilities.html#y2023
You only need a access to a valid certificate authority, no issue for any state actor for example, to interrupt the chain. Yes, there are mechanisms against that but those are so far not really common yet unfortunately.
And I never said that I do code audits, only that I have the possibility to do it.