General Data Protection Regulation (GDPR) and High Fidelity Sandbox


#1

Lets re-open a new can of worms, before it blows up from pressure, as this will become in force in

May 25th 2018:


This little thing will be coming up soon here in Europe:

Note that while the video words “Companies”, but the article it self is worded for “Hosts” and “Users” using the terms “Controllers” and “Processors”, and not just companies: where Controllers decide what to do with the data, and Processors doing something with the data.

So technically, anyone running a High Fidelity Sandbox, is a “Controller,” as they have data on who connects to their service. Basically if you are online and have EU users, or if you are located in EU this applies to you; and since this is the Internet it pretty much applies to anyone.

Specifically Take-aways which will impact High Fidelity Platform, and Anyone hosting a Sandbox:

  • Identifiers, from dynamic and static IP Address, UDIDs/MACs are now to be considered Personal Data. If bundled with personal info
  • Encourages Pseudoanonymization of Data
  • Data Breaches must be notified within 72h(?).
  • Individual Rights are improved: Users must have the right to be forgotten; consent must be unambiguous, access / objection rights.
  • Right of Portability: Data must be available to be portable between similar services.
  • Applies to goods and services available to EU residents ( including free ) and for services from EU for any other resident in the world.

This unfortunately means that any domain host who doesn’t block EU residents of High Fidelity must adhere to the GDPR and held Accountable for their server security and the above and may not always know if they been compromised or not.

Edit:
Note however @Ron.Khondji pointed out:

This Directive applies to data processed by automated means (e.g. a computer database of customers) and data contained in or intended to be part of non automated filing systems (traditional paper files).
It does not apply to the processing of data:

- by a natural person in the course of purely personal or household activities;

So anyone doign commercial stuff through a high fidelity sandbox needs to pay attention. So should there be a method to mitigate any issues by having everyone as a service provider by making sure that by default servers don’t store ip addresses and usernames in logs, and only relies on the information in memory and make sure even if breached no information regarding to service users is available.

Specifically the following information will need to be pseudonymized:

  • IP Addresses via domain-server logs
  • Usernames via domain-server logs
  • Access Rights (IP, Usernames, MAC, fingerprints)

Additionally

  • Avatar urls via avatar mixer logs

Any of the above combined could technically be used to “identify” users in other services / cross domains (identifiable with the service is fine from what I’ve read).

I think we could go around this by having a generated unique secret key of the domain (or the sessionuuid) and hashing any identifiable information to create pseudo-anonymous identifiers that are only unique for that server, and logging these instead. Something like to how the fingerprints work currently.

This doesn’t stop users from building their own servers where they log all the info they want, but they would then be responsible for that info, but it will at-least make it less of a hassle for average user that plops up a sandbox server from their PC, to not have to worry about any GDPR issues.

This way, even in the case of a breach, there is no way to identify users as there is no “personal data” available at all.

This however does not solve the issue of pseudo-identifying users to:

  • belong to a group
  • to be an adult
  • Wallet ID
  • Commerce

And then there is the massive question for High Fidelity Inc:

High Fidelity ICE for Sandbox Address resolution, which escentially requires store and know ip addresses of all sandboxes that are configured to connect to it. Infact, I think running a sandbox that connects to this needs to ask explicit consent from the users running that it will connect to it to map ones IP address to a pseudo-name used for the address system.

What are the thoughts on these from High Fidelity @Jess / @Caitlyn… or even @philip ?


#3

Just my 2 cents on the situation…

Personal data is defined as “any information relating to an identified or identifiable natural person”.

As far as Bitcoin goes (and probably most blockchain tech in general), I don’t think it is covered by these regulations. It is by nature pseudo-anonymous since it is all public and does not identify or use any personally identifiable information. It does not store IP addresses. Nodes could potentially store IP addresses in their logs but when transactions are relayed there is no way to tell if the transaction came from another relay or the originator of the transaction itself.

You could theoretically make an educated guess and find an IP address if you were actively monitoring an entire network but you would probably end up with a huge list of IPs that look like the originator, and still not know which IP was the original.

I am sort of wondering if these regulations are intended to push blockchain tech onto everybody. It’s a pretty good solution to it anyway, if not a perfect solution.


#4

This GDPR. or directive 95/46/EC, does not aply for a personal ‘sandbox’ without commercial content or function.

SUMMARY

This Directive applies to data processed by automated means (e.g. a computer database of customers) and data contained in or intended to be part of non automated filing systems (traditional paper files).

It does not apply to the processing of data:

  • by a natural person in the course of purely personal or household activities;

Anybody with a sandbox running on their personal computer which is used to meet friends and/or strangers has nothing to worry about.


#5

Basically looking at my connection logs I can see my User

To limit personal data of users of ones domains through pseudonymization.

Anyone sufficient with know-how will be able to go around this and log it, but then they most likely will also know the rules related to this.

Also, even when it goes to effect, only law cases after will actually define the law better and see what is enforceable and what is not.


While this is a good thing to know, wouldnt this still affect people creating content to sell. This does however eliminate just the average user:.

I do doubt that they would go fine 20 mil from small tiny businesses and small non-profit NGOs as theyd never get those fines, it is would still be good to make sure that there isnt the possibility of issues.


#6

@menithal: I did some checking, and the current status is that we’re aware of the pending GDPR requirements and we will be working to address the issues raised well in front of the timeframe for compliance. In addition, I can say that that we are taking care not to include PII in our certification blockchain. More details will come as we proceed.


#7

When I hear talk about adding anonymity layers to things here it makes me cringe. I can’t see how it would be workable without a performance hit and having a centralised architecture, which goes against all that HiFi is.

Another issue is assets here. Because they can be hosted anywhere, Amazon S3, Digital Ocean, your own website or on your own machine via a web server or ATP, it may be very hard to comply with rules like that.

Systems like Google Analytics and others, don’t work without being able to log and save unique user use data. Even saving IP addresses , MAC addresses and machine fingerprints for white or blacklists could be a problem.

Because of this, I hope nothing is done unless it is forced on us. Every little nerf that is added starts us on the slippery slope of bloatware.


#8

If they are using blockchain for ownership and permissions this shouldn’t be a problem. All you have to do is prove you own the key to the asset. This is not covered by these laws as far as I can tell. It doesn’t look like they are forcing anybody to be anonymous, either.

You make a very good point there. Security might be a nightmare.


#9

As I mentioned earlier, perhaps on entry, such could be keyed hash and salted with a server side unique salt for entries to make it into a pseudoanonymous, and on connection always checked against that table. (So you enter a ipaddress, mac address or etc, and it get stored as a hash and salted version, which the server would refer to). Sorta like how one would do passwords in a database. Ideally a new salt could be generated per each list entry as well.

That way you are not storing the address or identifying info, but instead an identifier generated from that info that is harder to reverse, but quick to make. Ofcourse one could brute force a IPv4 in a few hours / minutes, if there was no salt.

The only down side would be to identify users via the whitelist/blacklist interface and figuring who is added to what list, but that could be eased with some interface changes.

Generally I think: if there were only IP addresses, without usernames, that doesnt need to be obfuscated, as by it self, IP address does not confer to individuals identity, but with other information, such as username or mac addresses it may actually be considered.


#10

IP addresses are automatically obfuscated by some analytics software like Piwik, and at first it can be surprising (sometimes you even temporarily disable these functions), but in the end you get used to it.


#11

GDPR is around the corner. Does anyone know how to setup our domains to get conform with the GDPR? Is there something (step-by-step) to do? This week I go a huge WordPress update, that helps to get conform with the blog and GDPR - is there something similar on the way with HF?

Any news for the folk?

And Question for everyone - what you have done to get conform with GDPR? I feel a little swamped with this topic. Thank you!