I’m not sure if I fear or hope for where this seems to be going.
Forked Interface/Stack variants,
Where things like texture size caps, default UI choices and other nagging sources of irritation can be addressed. When so much of this seems not open to debate or input the freedom of open source seems to be the last remaining solution. Welcome to freedom, or maybe anarchy, where you have HiFi’s Interface/stack, and then possibly countless variants with incompatible protocol levels since that’s the only option when you hit a roadblock to your ideas or even just simple enjoyment of using the product. I already apply a plethora of patches for my personal use sandbox/interface… turning off 99.99999% of logging, no hot mic on each startup and numerous other bits that improve my experience. (Of course - that’s only for my own use - the Linux packages I provide are 100% un-modified from HF’s sources.)
yes we agree with that as well… but there is some subtlety here, and we’re trying to find the balance. Using your Chrome add-in analogy… we wouldn’t expect chrome to let web sites block add-ons…
I guess my general point is… we are aware that there are pros and cons of our “extensible” client approach… and we will do our best to optimize for the most pros and the least cons… and we are listening.
Perhaps there could be an option in server settings to disallow local scripts from interfacing with the domain.
I do like the fact that users can’t stop server-side scripts from running (they don’t show up as running scripts… unless that has changed in the last year or so) although I doubt I would rely on that for server security.
The client code can be modified… it’s open source after all, so in general, we assume “the client can’t be assumed to be “stock”/unmodified”
The scripts are just “callers” of protocol end points, e.g. editing of entities, playing of sounds, – from the “server” perspective, we can’t actually tell if the client is trying to play a sound because an domain level entity script told the client to do that, or some client script tried to do that, or someone modified the C++ to do that.
So basically, our security model is, as a domain operator, we provide control over what “actions” or “API end points” you allow to be used by what types of users or what narrow contexts… this is really the only secure way we can give you control over what’s happening.
What’s an example of a type of “script behavior” you want to prevent? We can discuss how to use the existing safe guards to prevent those behaviors in your domain, even if the end user is running custom scripts on their client.
Checking whether or not certain server-side scripts are running on their interface.
Controlling where their avatar can and can’t go, and even taking full control of their movement.
Controlling their avatar mesh and attachments.
Limiting info they can glean by sending commands (for security purposes).
Preventing unwanted inventory rezzing/wearing (i.e. banning certain content directly, by creator, or even all foreign content) without having to make checks every couple of seconds to see what attachments they are using.
Let’s say somebody used HiFi to make a World of Warcraft MMO clone. They would need to be able to override pretty much anything a user can do. For instance when their avatar died (or if they are crafting/fishing/etc) they shouldn’t be able to move. They should only be able to wear avatars and attachments native to the MMO (no foreign content). Their movement speed should be controlled (e.g. they might move faster if on a mount or slower if they are injured).
Or let’s say somebody wants a HiFi domain where the user doesn’t even have an avatar (a multi-user app for example). You wouldn’t want them to be able to rez anything, move or wear an avatar.
Or how about an experience where users cannot perceive each other except in certain circumstances? If it were a stealth game you wouldn’t want users to be able to use a script to tell them where their enemies are hiding.
Is going to be really important since we apparently won’t have even the minimal insulation of basic adult/not adult “verification” at the user account (HiFi’s system) level leaving all responsibility to fall upon a domain operator… So here we have our nice not adult space, signs saying no adult stuff and next thing we know we have some pile of “something” wearing “somethings” all piled in a corner doing “stuff and things”. In a structure like SL we have the fallback of SL giving an adult check (lax as it may be), sim ratings that prohibit entry of not adults or adults not wishing exposure to adult features.
Here our only alternative is tight control of what sources content entering our domain can come from or adding layers of “registration” such that our users have a 2nd tier validation process before entering the space and excluding those who are minors.
This is where idea that HiFi is “Apache” falls a bit short - as keepers of user identity there’s a bit greater entanglement with all these nasty bits than say, Apache, would have with such subjects.
This is another problem with how things happen around the HiFi sphere… which tweet, blog or voice conversation is some piece of useful, if not critical, information located in/from? The number of times I’ve seen something like; “I think I heard someone say they heard someone say something” from one of the Friday meetings is… too many times. This has been an issue since the earliest days, especially for those who can never or nearly never attend those in world sessions.
A ton of dry techincal stuff goes past in the github,thats never spoken about or explained . Im sure whislt not perminantly the majority of the hifi users are actually interested in that stuff cos were that kinda nerd
The devs have their meeting fridays , allways did its a shame theres not the opputninty for users to appear there as ghosts, ie not contribute or to start a fight about makiung it more like sl , but just to listen
the current demographic is serial killer/ tek nerd
Well I was half wrong… He doesn’t specifically mention age verification but age verification would be one of the first things I would think of when it comes to querying “different account information”.
Yeah - I recall OAuth being on the roadmap diagrams from 3 years (+) ago and the concept that we’d be able to leverage that as 3rd parties “somehow”… and, yes, about the only thing I would care about is query for adult status, but, the mixed signals from reading other posts leaves me unwilling to assume that’s going to be part of data stream.
Leading us back to - we’ll need tight controls at the domain/assignment-client levels of what content may/may not enter our spaces. It’s hard enough to visually “police” a handful of avatars in a 256sqM SL sim 24/7/365 let alone a 32/769KsqM space.
I do know that we have the following domain-side updates available:
Avatar (under Avatars > Avatars Allowed from: ), which will override avatars not matching the rule from Avatars > Replacement Avatar for disallowed avatars. this forces the avatar-mixer not to pass information of the avatar url, similar to how Display names are lightly sensored if using some curse words where the avatar mixer desides what to send and what not to send. I do have to note that, while Avatar has control, attachments don’t, so that is till circumventable for now.
Entity Script Url (under Entity Server Settings > Entity Scripts Allowed from:) to block any entity updates with scriptURLs not matching
You can also write a custom scripts to check entity edits, change / restore / remove the entities them selves (including checking what modelURL is used) under Entity Server Settings > Filter Entity Edits with various functional rules you can write for it.
All of the above are server-enforced.
There was a worklist item to also apply server side speed limits which I attempted to do, but there are alot of server-side architectural changes that needed to be done to allow for it. It would have also blocked teleporting, but as of the moment, the avatar-mixer has no override capability to teleport users about.
This one doesn’t make sense to me… as far as “server side scripts”… they would be running on the server… as far as client-side scripts, in general - you have to assume you can’t control that… because people can always run a modified client or open and run their own scripts.
You can sort of do this today, to a degree… and in general, sure, this makes sense… your domain can control this with things like entity-scripts to basically set an avatars position, or even over-ride their keyboard/controller inputs to not route to the standard movement controls. So - you can do this today… and we don’t plan to change that.
You can also do this today in a couple of different ways, and we will be adding more in the future. Today you can actually run an “entity script” that will replace someone’s avatar. We might change this behavior in the future, so that any changes you make would be temporary… right now, if you change the avatar, you should be a good citizen and change it back.
I’d need more detail to understand this… but basically, you generally have to assume the person is running a modified client, and so any enforcement you would need to do in your server side code.
We have more work to do in this regard. But in general we do expect to allow various controls to allow domain operators to control these sorts of things. But this won’t be enforced through controlling client scripts, instead, these things will be enforced at the server level. Much like our existing features for filtering entity edits, and white listing avatars and entity scripts.
Agreed - we totally believe you can build this sort of thing with our exiting features… if you run into something specific that you can’t control from the suggestions I’ve given above, please let us know. This is a perfect use case we expect to be possible with our existing platform.
You can actually do this today with our white listed avatar feature. Check your avatar mixer advanced settings in your domain server settings.
Like most of these issues, you have to assume that the client can be modified… so to really enforce this sort of thing, you might need to use our ignore feature, which actually causes the mixer to block sharing of info about other clients. This isn’t directly exposed in the SDK today, but you could modify your server code to provide these types of features. Maybe we could add those to the SDK but we’d need to think about how to do it in a manner the provides the feature in a secure (and un-exploitable) manner.
Well you can force their local scripts to stop and force them to run scripts from the server already (which don’t even show up as running scripts). Just hope this stays like it is ( or ‘like it was’ if this hasn’t changed already… haven’t tried it in a while but it used to work this way).
provides user some choice in the “you’re about to go to a domain that will reset your scripts”… kind of like how you need to provide permission for a website to access your twitter or facebook account…
We haven’t really spec’d out or designed 3… which is probably why we haven’t “fixed this yet”… but when we do fix it… we will try to retain the basic ability you have as a domain operator to control that experience on your domain.