SasTech KioskNet

Object and Information Distribution System

Avatars vs. Natural Persons

First, some discussion about how the GDPR applies to avatars in SL.

- see

“Personal data” means any information relating to an identified or identifiable natural person. A natural person in general means a human being. Think of a natural person as someone with rights, such as those granted by the US constitution. Avatars obviously don’t have constitutional rights. Unfortunately the GDPR rules do not address the issue of avatars vs. natural persons, so it's left up to various people to give their opinions on the matter, which to me are simply not definitive.

Your avatar ID (legacy name, account name, UUID) could maybe be considered personal data, but can it be linked to any specific natural person? In general, with rare exceptions, no. The general consensus today seems to be that avatar data is not personal data. It just can’t be linked to you in any reasonable way.

SL is designed to make identifiable information about avatars easily and readily available. Any script (and most viewers if not all) can easily get your name and UUID. Those items are by design very public. You don’t need to opt-in to give that data out. It’s public data. Unsolicited spamming of such visitor lists, however, has always been against the TOS, but that’s a different subject.

All that being said, it's just not clear to me that the GDPR rules apply to avatars at all or whether any kind of data that can identify an avatar can be used to then identify a natural person. So if you are the owner of a KioskNet system, I would not worry about the data you or your kiosks are collecting about avatars.


The KioskNet system collects only the information it needs to operate in second life and nothing else. Every avatar that interacts with the system will have some core data stored in the database about them: their legacy name (i.e. “Joe Resident”) and their UUID. Other data is attached to an avatar UUID depending on the context:

Click and visitor data is not stored longer than 6 months. After that it is permanently purged. Payment data is stored for 1 year then purged, because some fundraising organizations need those records. Subscriber lists are purged 30 days (give or take) after the inworld server they are connected to is deleted.

Server owners and designated admins also get information stored about them, primarily which servers they are admins for and which ones they own. This info is purged when the server is deleted.

To access the Owner section of the website, you must create an account and log in. Logins (your user name) has an email name attached to it as well as one avatar UUID to connect you to your avatar. Those login names and email names are not shared with anyone, ever. It is only used to send you a password reset link if you forget your password, that’s it. Logins are purged 6 months after the last login date, if there are no inworld servers associated with that login account.

Owners and admins of a KioskNet server can see additional data about avatars related to kiosks attached to the servers they own or administer:

The system doesn’t collect any data for my own marketing use, period. I never use any data from the system for advertising my own stuff.

Right to Be Forgotten

Since the only personal data I store about anyone is their email address associated with their login, if you would like your login deleted, please let me know and I can do that very quickly. Email me at with your login name, avatar name, or email address so I can find you.

Subscriber Lists

To see a list of all Sastech subscriber lists you are subscribed to, and either add or remove yourself from any list, go to the Sastech store in my picks, and right inside the entrance of the store is a kiosk that will send you to a webpage where you can remove yourself from any and all subscriber lists. This must be done in-world since only the actual avatar can maintain their own subscriptions to avoid any griefing.

All sastech scripts that subscribe people to a list are OPT-IN only. This means that the only way that any inworld objects will add you to a list is via a click on a subscriber kiosk, a subscribe menu, or subscriber HUD. When you are subscribed, an automatic menu pops up with an Unsubscribe button. The date and location that you subscribed is stored in the database.

There is one exception to this rule, and that is that a list owner can import any list of avatar names into the system via the website. This is necessary to allow people to migrate from one subscriber system to another. However there is no possible way for me or the system to somehow confirm opt-in for all subscribers being imported from a file of names.

If I get any complaints from someone about being subscribed to a list without opting in, I’ll be happy to investigate. I really hate SL spam just like everyone else. If they were imported to a list without their knowledge, I follow up with the list owner and tell them there is a problem and that they are in real danger of being abuse reported for spam, which has always been against the TOS. I’ll then discuss options with the list owner on how to avoid abuse reports by offering a new opt-in to everyone on the list.

Notification is being sent out to all KioskNet owners that if they are worried about whether the GDPR rules apply to avatars, which does not seem to be the case, then they can contact me to work with them to get opt-in from everyone on their list without too much hassle.

I always highly recommend that list owners periodically send out their Subscriber HUD to everyone on their list so that they can easily unsubscribe if they want off the list. Don’t make it hard for someone to unsubscribe. Put your subscriber kiosk in a prominent place and make sure it’s really obvious what to click to get on or off the list. And as mentioned, anyone can go to my store and manage all their Sastech subscriptions with a HUD they can keep and use in the future, so I’ve made it as easy as possible.

Data Storage

All data is stored in a secure, encrypted SQL Server database hosted on Microsoft Azure. I would hazard a guess that Microsoft keeps their cloud servers secure :) All data from the database is encrypted “over the wire” when going to/from the website. The website itself is also hosted on Microsoft Azure so it is secure, though that never guarantees it won’t be hacked by some malicious hacker taking advantage of some vulnerability no one knows about.

SSL (HTTPS) is now supported but not yet required. That will change in the near future so that SSL is required to connect. All non-HTTPS requests will be redirected to HTTPS automatically.