This has been a topic that was suggested ages ago by HumbleTim, and

parroted by me a few times already in various meetings over the years.

But keeps falling "down the cracks" over these years of community meetings, posts on forums,

So, Parroting again.

I have usually brought up this same exploit many times, and demonstrated it MANY TIMES.

Be it through foxbombs, targeted foxlasers, wallet opening panics, wanted posters, among other mischievous pranks to raise awareness.

But as High Fidelity has grown;

which has caused the exploits are getting serious, or damaging; which can be damning as more and more money is getting involved.

I am afraid of just nodding at the direction "The exploit you described" is just waiting for murphys law to kick in:

So, I'll open the can of worms.

I mean the can was already open, It actually starting to reek,

but I am turning it upside down and laying its contents on a plate with a solution how to address it.

There are already protections in place for most HiFi run domains (Except, Maker), which is why this is ok time to talk about it in more depth.

....

Most attack vectors for "Exploits" as discussed in the town meeting on 14 March 19 involve running an

entity script that targets a specific users (this is fairly simple to do).

It's not even an exploit, it is the main feature, which can, and has been exploited.

Lets describe the crux of it:

You can edit ANY UNLOCKED ENTITY. There is no such thing as "edit permission". You can do this with a client script or a modified create script.

The nature of Hifi requires interactable objects to be unlocked, so you cant really lock everything.

If things were locked, theyd be static. You cant do anything with a locked entity, except unlock it, if you have the permission to do so. So LOCKED Entities do have domain level protection which is a good thing.

However, for unlocked entities, this means you can apply any entity script to any unlocked object; unless the server denies you this through filters.

Entity scripts are scripts that run locally on your client and allows it impact you, or command you to impact the world. So if you fire a flare gun up in the sky? You create the entity, simulate it, and definite the particle and light effects for other clients. Hook guns? it applies an force to your avatar, pushing it forward along the hookline.

This is how many things in High Fidelity works. You have an input and have an output. Make sense right? Flow.js is a fantastic example of a client script that animates your avatar depending on the your avatar and other avatars.

Combined with Message Queue, you can do... many great things... and many unspeakable things with this.

Such as take over control of another user's actions.

And if targeted to a specific user you can be them, at least according to the server.

All things great power comes with great responsibility; and with everyone having such power, you shouldn't just trust everyone.

....

Scripts are the lifeblood of High Fidelity, without them we have the fun things, they sorta need to have the unferreted access;

Permissions systems like SL or Android would be nice to have, but have architectural challenges ahead and may take years to establish,

which does not address the short-term (even if alphas been discussing this longer than a few years).

Most of this can be protected against via Entity Filters, and fairly all High Fidelity domains are protected by them,

meaning places like Spot and Bank are fairly secure, (i will keep poking ;) ).

These tend to work by only allowing certain edits (like position, rotation) to be trasmitted to other users, with everything else being "locked".

But Filters are an arcane art and not well documented for others to make full use of.

They are also not provided by default in the sandboxes provided to users.

----

So.. If youd eliminate the client from running a malicious script,

then youd eliminate this attack vector:

It is a Matter of Trust.

Thus we need to be able to define that trust through Client Script Whitelists.

The white list should also be extendable by user, allowing one to add their own scripts to the list. But this should only affect that user.

By Default, what everyone should have theirs running at.

You should Only trust following scripts:

1. Released (Stressing REVIEWED) marketplace scripts. (Marketplace Authorized)

2. Scripts or url domains that the domain say are ok. (Domain Authorized, or Required)

3. Scripts from file system. (Local filesystem)

Users should be able to turn on / off which ever. If a domain requires scripts to run on the domain, they should be allowed to run on client. If client denies these from running then client should immediately disconnect and give a message to user that the domain requires the permission to connect. (This allows for gamelogic, and I think is already in place)

This can later be expanded upon with a permission system that analyses what commands the script will run; and if permissions are given, will allow it to be placed on the whitelist. Ofcourse there are some stuff that should never be allowed to go through such, such as presence of eval.

This does not eliminate bad actor domains, but it would put more control for the client.

IT would also put more people in ease of not bumping into entities that may do something naughty with their clients.