How to make invisible avatars visible?


#1

Last sunday meeting someone used ATP avatar. Now we all know that atp cannot be used outside domain. (lucky) But because that it can be abused to, just like a complete invisible or tiny avatar.

The problem with that is whst high fidelity seems to have high on the list. Privacy High Fidelity is not showing in anyway if there’s some invisible or not loading avatar around you. secondlife showing them as cloud Nd if you have nametafs on in secondlife you see them too. (not use ugly nametags btw)

So how it now works, people can spy or do other things close around you without you know someone is there. This is problematic you not want to see where everyone is, but you not want someone sitting on your back without knowing it.

How can this be solved ?


#2

Probably best way would be to load a default avatar if the current avatar is unreachable. Although this still wouldnt solve the problem, as one could just make an sneaky avatar by having an avatar that has no mesh, or a body consisting of a single triangle, or just make an avatar very very very tiny…

But if you are paranoid, one could just make a script that creates a overlay circle around the position of an avatar which follows the avatar’s hips/centerpoint that normally would just be hidden if an avatar would be there: The clients after all know where the avatars are.

However: if it is privacy you are concerned with, remember that we have infinite range for cameras too, unlike in second life everything is rendered depending on the camera position, not avatar.

The most secure way is to have best privacy, is just host it on your own sandbox that only you and the ones you trust have access to. No one else can teleport to a sandbox you own when configured properly.


#3

Just pointing at a problem that users not going to like.
and lock things, yes it’s idea. except, that so far i never got any response on the request for privacy zones. to place inside a domain.

Locking a whole domain keeps nuts. But the privacy zones that would do what you describe. Only let people in you like and not let anything like chat or other info go out of the zone. Sofar not know there idea about it.

Not want to lock a whole domain, just small parts would be good. To create safe zones users need on there domains !.

https://alphas.highfidelity.io/t/really-missing-private-zone/10418


#4

It may sound nuts, but its completely doable, you can always use the local sandbox thats bundled with the client, rather than use the one that is dedicated for it for the private area.


#5

That is not what i would want, and i think many others to.
One good server, with zones that can have different permissions. Or block access. Not something you need to run at home. and then need to redo all your work again because it’s on the wrong ATP server etc.

Privacy zones, also work as parcels so someone can split a domain up in small sections and let others have a small part on it. It’s something that is needed.

Then you get something like shared experiences.


#6

Could you please suggest how this script would work as an assignment script please?
I have a project that requires any avatars on the domain to be located and their positions sent back to a script for processing, I have a need to track avatars on a domain even when I am not there.
I have tried a few assignment scripts but it seems unable to detect avatars.
Thoys suggested it might need to be run “As Avatar” but I need a bit more info about that.

Any suggestions would be appreciated.


#7

The Server could technically just have an assignment client as well as you suggested that rezes an entity that follows the user positions. Unfortunately I havent done enough experimentation with Assignment clients yet.

Actually now that I able to get other avatar positions so assignment clients would be best, but it could also be done locally using a script through the overlay per client.

How I think it works is using

AvatarList.getAvatarIdentifiers(); that returns an array of string uuids which is UNDOCUMENTED but can be found in the airshipscript.

with combination of a for loop that iterates AvatarList.getAvatar(uuid), which get the Avatar Object, and maintain a separate array that maintains entities and entity count.

#Note- Pseudo code for assignment client: needs filling with actual programming


//GLOBALS:
var avatars = [];
var followerList = [];
// -------

And on frame Update events

avatars = AvatarList.getAvatarIdentifiers();

if(followerList.length != avatars.length){
  // Update the list of entity object ids. Make sure it is the same length as avatars
  var entityId ;
  if(followerList.length < avatar.length){
     // Modify this to your likig
     entityId  = Entities.addEntity({type: "Box", collisionless: true})
     followerList.push( entityId );
  } else {
     entityId = followerList.pop();
     Entities.deleteEntity(entityId);
  } 
}

for(var x =0; x < avatars.length; x++){
  var avatar = avatars[x];
  // assignment client avatars have no avatar identity id,  
  // atleast last I checked. could be truncated from avatars list.
  if(avatar !== ""){ 
    Entities.editEntity(followerList[x], {position: avatar.position});
  }
} 

Hopefully that gives you an idea how to do it.


#8

The idea that someone could waltz in and you’d not be able to see them at all or know they’re there is actually rather unsettling. I fully anticipate some people are going to be doing some very, VERY personal activities in HiFi at one point. The absolutely NSFW sorts of… really intimate RP. Or, for that matter, business people will be discussing very proprietary, even trade secret, kind of details. And if they only think they’re alone, but really aren’t, you have a big problem. oO


#9

Thats when you pull up your own sandbox environment (aka your own home with your own whitelists and all) and do your business there.

In anycase, domain owners can adapt the script I posted above as an assignment-client. but this cannot do anything in stopping people in the domain from just moving a camera to another place and listening in using that (because again, view distance is camera location based, not avatar based, and we have full control over the camera via scripts) as we have no information about the camera position with the avatar info (I think it should be provided too, that way we can debug / see where people are looking as well, sorta like the LookAt position in SL, but transmission cannot be turned off!).

I posted above to spawn stuff at the location of the avatar to make sure they are visible. Ill try making it into an actual assignment client script later on. Mostly tested using the js console in Hifi. CC: @Adrian incase he missed the above post of the script.


#10

You would whitelist only those people you want in your domain. Yes, that is a rather broad brush approach but it works. I think that sectional access control of zones within a domain needs a lot more work. Not that full infrastructure should be done, but that low level methods are needed to let world builders write their systems. I wrote about this before. We really need methods to get data on who is in a domain, what their non-spoofable ID is. Frankly, I don’t care much about needing their system ID because a sha256 hash would be fine. Then I don’t have to know who they are, just that if I don’t want them there because they visited once before and caused problems I can identify their reappearance and deal with it.

Ideally there should be a way to create a whitelist or blacklist based on these ID hashes so that when someone tries to enter the domain they are stopped before they enter. A script sensing them has a latency associated with their discovery and that is enough time for them to launch an attack.

[edit]
And yes, along with the list of ID hashes, a domain operator and their agent script(s) needs to know the avatar’s position in the domain and the position of their camera. How else can a estate security system make disposition decisions about avatars.


#11

Id only wish those lists could be updated without having to goto the server interface and rebooting the server every single time :frowning:


#12

Much agreement! - –


#13

You know that this i a little bit siprissing. And not whst you expect in high fidelity. For me that’s close to a bug and big implementation error. High Fidelity need to link sound on the avatar, just what you would expect when walk around with the avatar or get closer to someone. It also solves a big secondlife problem with camming around.

But, link to avatar is big problem too. leaning works not so good with sound linked to the avatar.

There need to be some distance cutoff implemented in high fidelity. so you cannot hear someone 32000 meters away. Does the cam trick works too if the camera is going from one zone to other while the avatar is in the first zone ?

This unlimited distance for voice really need to be fixt too.

Other note: locking a whole domain is not hat you want if everybody need to have the option to visit. We need the zones that keep everybody out, including voice camming etc. except people on whitelist.


#14

There need to be some distance cutoff implemented in high fidelity. so you cannot hear someone 32000 meters away.

there is! :slight_smile:

A domain’s default attenuation can be changed in audio settings, so that no matter how far away a sound source is, it still plays at full volume (attenuation = 0). Likewise, the default attenuation for a domain can be set very high (to a max value of 1), making only things very near to you audible.

https://readme.highfidelity.com/docs/server-settings-reference#audio-environment

you can actually do some pretty complex audio setups using zones and attenuation

i.e. on cellscience there is an AC script that creates 4 audio injectors off in the corner of the domain, each of which is in its own little zone that pipes its sound through to a larger cube of space so that there is different background music at a consistent volume through the larger volume (without falloff or “spillover” – getting two sounds mixed together because you’re between them). it also means that there are 4 audio injectors creating background music for everyone and adding it to the mixer stream, instead of each person individually having to load sounds.