Hard Permission System

[Frooxius]

Currently Neos features a soft permission system, designed to keep the user experience more in control, but not to fully deal with malicious actors and people looking to actively break the experience.

This will be addressed by a "hard permission system" comprised of several parts, which is going to enable following:

• Low level write/modify validations of the data model, locking down parts of it from being modified by users (even in case of malicious client which bypasses the restrictions on user's end)
• Throttling system - limiting how many objects, components and assets can be spawned/modified per unit of time, preventing people from spamming
• Type filtering - will limit which datatypes can be introduced into the model for loaded/spawned objects. This will allow filtering out certain components/nodes from avatars, objects, so they can still be brought in, but with restricted functionality. It'll also allow users to spawn certain items, but not others.

These elements in combination should provide a stricter way of controlling the experience and harden the system against malicious users as the community grows.

[ProbablePrime]

Just jotting down an idea based on Last night's stuff:

Idea: "ParentBlock" component, similar to the other "*Block" components. Prevents anything from being parented within the hierarchy that the component is added to.

[Frooxius]

That could potentially be added, but wouldn't be part of the hard permission system. Those components are more of "hints" to the system, but they do not guarantee that they will be respected (e.g. consider DestroyBlock, which you can still delete with inspector).

However I don't think it would be too practical. At which level would it work? If you put it at the root, then you can no longer grab items for example, or equip hats and other stuff since that involves parenting.

The hard permission system would allow for more finegrained locking and filtering of the hierarchy at lower level, so it's guaranteed that it will be respected by all the code.

[ProbablePrime]

Systems now exist which allow bypassing the part of the permissions system which disallows jumping between users in the session menu.

These systems don't use the session menu so aren't subject to the permission block that is there. They use "Set Position" logix nodes instead.

The existence of these systems in a couple of maps i'm working on will break puzzles and experiences within those maps.

I'm just noting this down in this issue as it should be covered in the hard permission system that a stronger protection against teleportation should be implemented.

[Frooxius]

This one is a bit tricky, as there's not a clear way to handle this. There's not much of a difference to the system between the user moving through their inputs and to the position being changed, so it's hard to cover this with a permission.

One option is to use LogiX/component stripping system (once it's added). Remove any "Set Position" nodes and such. But that's hard to make it cover every single case, so it would likely have to be very aggressive stripping, which could break a lot of things on the avatar.

Alternatively only provide the user with your own avatars for the game/puzzle, which you know are safe.

There are also reactive approaches. You could check if the user moves too fast and then move them back or clamp the moved distance to some max allowed velocity. It's not perfect solution, but it will help somewhat.

Yet another solution would be to run all movement on the host and use that as authority, correcting any deviation on the client. But this gets a lot more complicated to setup and would require more subsystems systems to be built.

One more option will be restricting write access to the fields to LogiX based on "owner" or context in which it happens, but that can still be prone to workarounds.

It depends a bit on what level of protection against cheating you want, but this particular problem isn't too suitable for the hard permission system, because that one is binary. You can either do something or you can't. But in this case you want the user to do something (move around), but only in certain way (not teleporting). I'd suggest a separate topic for that perhaps.

[ProbablePrime]

Hmm, I understand what you're saying and can manually make these changes on a map by map basis, but I'm a little confused by the statement of the binary nature of the "hard" permission system.

Being able to jump to users via the "Jump" permission is binary in the current permission system. My hope was for a binary setting for that that was "Hard" and more likely to block other forms of teleport.

As I think about the permission system more, More examples that are similar to this come to mind where the permission isn't binary. Even reading your initial description doesn't suggest the binary nature. For example the throttling part.

Perhaps I'm misunderstanding the nature of this feature?

[Frooxius]

The binary nature here is in context of the data model and what you're actually changing. E.g. the "Jump" button is a binary state for whether the button is active or not. But there are other means of jumping, that can be done through LogiX.

What could be done there is to block them, e.g. by blocking the "Set Position" node. But that node can be used with other things as well, e.g. some visual features of the avatar. If blocking those isn't an issue, then it would be a good solution. This is pretty much the LogiX stripping.

But now let's say you want to allow "Set Position" node, but you don't want to allow it to be used to make the whole user jump.

This is where it gets tricky. You'll need to block it at the level of the position property of the player. A binary permission here would be whether the user can mutate this field or not (change their position). But if they couldn't, they won't be able to move by any means (e.g. locomotion module based on their inputs).

This could potentially be solution too - have the movement done by trusted LogiX/components on the host and streamed, but it gets more complicated. Even more if you add prediction system to compensate for latency.

But if you want to keep it simpler, so the user can still move via locomotion module, but not teleport to someone, it's a bit tricky. You want them to be able to mutate their position, but only in very particular ways (not change too much). It's not a binary choice anymore and it needs more of a "high level" handling of that makes sense.

One of the possible high level handlings would be to clamp the maximum delta position. If they move too much too fast, put them back. That could be done of course! I'm just laying out the different options for dealing with this kind of scenario.

And yeah the throttling isn't binary either in the same way. Although in some sense it is, since it determines whether you're allowed to make certain change or not, which is context based (how much stuff you've already made).

I hope this helps! Let me know if you have any more questions.

[ProbablePrime]

Thank you!, that makes more sense. Let's keep an eye on this particular issue as it appears. For now I can take care of it on a map by map basis.

Thank you for the explanation.

[flarn2006]

What worries me is that this will also prevent some stuff from working that would be acceptable. Just because some people might abuse unlimited access to the data model doesn't mean those who wouldn't abuse it should need to suffer for it. I can think of many things I might want to create which require a level of access that can be seriously abused (nothing more than what we currently have) and in many cases even that particular use case could be seriously abused. But so long as I don't abuse it, that isn't an issue.

I suggest implementing a sort of reputation system, kind of like what VRChat uses. The age of one's account is a good way to determine this, because then being banned will actually mean something. But of course other things could play into it as well. The idea would be that the more reputation you have, the fewer restrictions apply to you, and if you don't cause any trouble, you'll eventually become exempt from the limits entirely, and you'll have the same access that we currently all have. (And of course, if you do cause trouble, you'll lose reputation, and the privileges with it.)

[Frooxius]

That'll be up to you. If you want to host a session with open permissions, then you can. The idea of this system is to only provide more tools to control your own sessions, not to impose global restrictions on everyone.

As such, we won't be adding reputation system like that, since we think those are inherently flawed and could be quite subjective. We don't want to impose our decisions on behalf of everyone like that, but instead we want everyone in Neos to enjoy its creativity to the fullest - you can always start your own session or join people you know and trust to have full permissions and mess around.

If you want to have more restricted session, perhaps more public one where strangers can join, you'll be able to configure it as such and grant them higher permissions on case by case basis.

[flarn2006]

I see; that does make more sense. Would it be possible to add a system where it remembers which users have been given those higher permissions, and then (optionally) automatically grants them when one of those users joins another session with the same host?

Or maybe there could be a reputation system that sets the permissions you'd start with by default, if the host doesn't change the settings?

On Fri, Oct 22, 2021 at 10:42 PM Tomas Mariancik @.***> wrote:

That'll be up to you. If you want to host a session with open permissions, then you can. The idea of this system is to only provide more tools to control your own sessions, not to impose global restrictions on everyone.

As such, we won't be adding reputation system like that, since we think those are inherently flawed and could be quite subjective. We don't want to impose our decisions on behalf of everyone like that, but instead we want everyone in Neos to enjoy its creativity to the fullest - you can always start your own session or join people you know and trust to have full permissions and mess around.

If you want to have more restricted session, perhaps more public one where strangers can join, you'll be able to configure it as such and grant them higher permissions on case by case basis.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Neos-Metaverse/NeosPublic/issues/289#issuecomment-950044462, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFHZUMSYTYJCHNEDTJTMQDUIIOJBANCNFSM4IMLQCYQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.