As with other virtual worlds, there are scripts for all to see and there may be scripts whose contents a creator wishes to remain private. Sometimes the value of a product is more in the scripted behaviors than the 3D model. What are the plans to protect scripts in entities and also scripts running in the interface app?
We will have to see what the official word on this is though.
However, interfacing to remote APIs with stuff like XMLHttpRequest ( for JSON Data requests), we can hide critical logic behind backend servers just like how it works on the web.
That is true.
I believe the devs consider the protection of scripts as strongly as they would models, it is all content and needs protecting.
Once the ownership and permission system develops it will undoubtedly include security for scripts.
For example entity scripts are an entry in the entity properties just like its origin URL, if users cant see inside the entity the script is safe. But currently the scripts and URLs are exposed in the debug console.
Scripts developed for distribution will need a whole other level of security, I have no idea whats in mind for this but I have faith it will come. Keep your valuable stuff on a private domain and test all you want without fear of giving it away until you are ready.
This kind of post it well worth while, the more we yell for security the more likely we can push it to the top of the priority list.
Security is really needed. Better today then tomorrow. That need to be implemented now, before more people come in. Secureing content need to be one of the top priority things I know it’s a make or break…
For me it’s something i dont know how to handle it. Did have the same problem in other world. but high fidelity is more weak in my eyes at this point. So, i dont know how to build things and keep it secure without locking everybody out. Offcorse
Hints, welcome or idea’s
I asked the question because the scripting/programming model in HF is quite a bit different than the SL-style worlds (or game platforms too). When scripts run in company servers, there is a chain of trust and protection. Permissions prohibit access to them. But this new model has scripts coming from distributed sources. Entities grab the scripts from various places, so the chain of trust is much larger. Scripts running in the interface also poses a problem too in that they can be extracted easily. It is easy to suggest firewalling the execution in some other server but that begins to push latency issues in a direction opposite to the design goals of HF (low latency). So, I bring this up just to place a marker on some architecture issues that need to be resolves.
Obviously for now during this alpha period, everything is promiscuous, scripts and 3D models. I can deal with that because presently this is all a learning experience. Much of what I and perhaps others will write or build at this time are either throwaway items, or they are things we’d likely share anyway. But at some point soon, as in beta, the barn doors need to be closed.
You cannot firewall high fidelity assets if it’s a public region acessable from the internet. Most scripts are running client side. only the Assignment clients run scripts server side. but that can mean on other server too. I think @chris have better explenation.
I keep coming back to using tech as used in node.js - in specific EncloseJS. I don’t think EncloseJS is a good fit for our needs, but, it illuminates possibilities. The key seems to be using V8 JS Engine ( https://github.com/v8/v8-git-mirror ) which, if support for HF specific functions were added to, opens a path to a form of compiled JS code that could have potential use in this context.
It could be, with work and some careful consideration, a potential solution. Since we could design a standard script hosting environment - we could tailor it to execute protected code in a consistent way offering script producers some confidence their work is not open source code. One could even envision producing code that can only execute on “trusted” code execution engines, possibly operated by the script writer.
But Balpien’s essential question of “What are the plans to protect scripts in entities and also scripts running in the interface app?” is important.
There’s no real logic in expending a lot of time and effort inventing a wheel that will ultimately be of no use. If there’s a plan or even an idea of one then, fine, we’ll wait, but, bluntly put, there’s nothing worse than assuming a part of this system will remain something similar to as it is today, spending a lot of time coding something to use, then waking up to the announcement - feature X is gone as of tomorrow. Case in point, a few dozen hours of coding a JS library to allow object to object communications via XMPP and other communications tasks that were missing when XMPP was still here.
Well, there IS something to be said for serving up only compiled routines to the end user for some of these, while keeping the uncompiled script at the maker’s home base, so that the end user can’t open it to look at the code… tho that wouldn’t necessarily stop the end user from dumping it into a reverse-compiler
Its also possible we could devise a series of trusted servers, sprinkled all over the HyFy Metaverse, that flagged-as-nomod scripts could be run on and where the place the scripts are running in is firewalled off from the end user, but such that at least one of these are always physically located only one or two hops away from any given end-user’s machine, i.e. close enough to that end user as to prevent noticeable lag. And by trusted servers, I mean these would be machines that some central and secure group high up at the HyFy chain of command has provided some sort of secure certificate to that you only get if you’ve been carefully vetted, and that can be revoked at any time if you go rogue.