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.
Yet, it is a very not-really-good idea to run stuff on a web browser. Web browsers are a notoriously insecure, slow platform with controls (āBackā, āReloadā, ā¦) which are not optimized to run applications.
edit: I did not expect that the āmodern webā crowd would now come here to berate (and downvote) me for the sacrilege of not unconditionally considering web browsers to be the very best piece of software for every purpose. My fault, sorry. Iām out of here, this is pointless.
Is this true for PWAs for mobile too? Iām a security noob, but Iāve noticed the (few) PWAs I use on iOS seem to be using and sending a lot less telemetry stuff compared to their app counterparts. They seem faster too.
Tell that to Google with Google Docs, Microsoft with Office365, etc. The web applications are starting to become a thing in a big way.
I agree. Every company Iāve worked for recently has been migrating to web based applications, which has DEFINITELY been fun.
Nowadays web browser are so much more then that, with tools like webasm, web usb, web bluetooth, gamepad API, web gpu and all that we are far away from the slow platforms with limited controls of the olā days.
The list of modern API is almost endless https://developer.mozilla.org/en-US/docs/Web/API
Exposing your hardware over JavaScript sounds dangerous to me, to be honest. But well, Iām sure that nothing bad could ever happen.
we are far away from the slow platforms with limited controls of the olā days.
Web browsers are still much slower than your kernel.
I never said that it would be save, I purposely left that out. I am not a fan of Webapps and Games running in Web browsers myself, at all.
But it can be a valid option, for everyone not as paranoid as me
Okay, I have to admit that thatās leaving me a bit nonplussed. Assume for a moment that I am concerned about the security implications of running an open-source Tomb Raider engine implementation. How exactly are you proposing running this in a more-secure fashion?
If I run an executable on my platform ā say, an ELF binary on Linux ā then normally that binary is going to have access to do whatever I can do. Thatās a superset of what code running inside a Web browser that Iām running can do.
Are you advocating for some form of isolation? If so, what?
EDIT: And Iāve got another question for you. Letās say that youāre worried about security of browser APIs. How do you avoid this? Because if your browser is vulnerable to some exploit in its WebGL implementation, not clicking on a link explicitly labeled as going to a website that uses 3D ā which is what you appear to be urging people to do ā isnāt going to avoid it. Any site you browse to ā including those not labeled as such ā could well expose you to that vulnerability.
EDIT2: In another comment, you say that you want to trust the ākernelā instead of the browser. Okay, fine. There are a whole class of isolation mechanisms there. What mechanism are you proposing using? Remember that you are needing to give access to your 3d hardware to whatever software package is involved here, and the Linux kernel, at least, doesnāt have a mechanism for creating virtual, restricted āchildā graphics devices. The closest I can think of on Linux you can get at a kernel level there would be pass-through from a VM to a dedicated graphics adapter, which probably isnāt going to be an option for most people and I have doubts about being a carefully-hardened pathway compared to browser APIs.
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.
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.
