GDPR

[Anthony Lawrence]

Hello!

 

Given the seismic changes to data protection regulations across Europe, I'm (as I'm sure many others are) curious to find out about VATSIM's plan to adopt these changes and manage the impact it'll likely have, especially in terms of the varying ages of consent (for data storage), ability to request a data download of every piece of information held (CERT, I'm looking at you) and also the ability to request complete removal of personally identifiable information. All seems quiet, and I'd really hate for VATSIM to hurtle past May 25th and only then start to get their head around it.

[Daniel Gomes]

VATSIM is aware of GDRP implementation and is working on it.

 

There is a TEAM in place already working on the implementation of such regulations...

 

In due time we will keep members updated about this …

[Adam Arkley 1031024]

Hello Daniel et Al,

 

I must admit, that as an IT professional currently working on no less than three GDPR related projects for clients, the lack of information at this stage is worrying. Not only does VATSIM need to worry about data held centrally, within CERT, but VATSIM.net also needs to consider all of the data held by all of the subsidiary organisations across the globe. The deadline is the same for everyone and everyone is affected, if you're holding data about European nationals.

 

There needs to be a thorough plan, communicated to members well in advance of the 25th of May. Is Vatsim in a position to be making such communication?

 

Adam

[Gunnar Lindahl]

Hi Adam,

 

As Daniel has alluded to, there is a working group currently undertaking this work. As I'm sure you're all too aware of, it's a complex task for an organisation like ours but we will get there.

 

Once there is something to say it will be communicated.

[Anthony Lawrence]

All,

 

We're 22 days away from implementstion, I'm just curious to know what plans are afoot as there's very little publicity beyond GDPR suddenly appearing in meeting minutes (and quite late, at that).

 

It'd be good to have a concrete outline if what's planned, even if in a draft form, as I'm concerned at how wide spread the impact will be (region & division websites, online feeds, booking systems, and then the difficult topic of age restrictions varying by country).

 

Anthony

[Kieran Samuel Cross]

what's planned

 

Ha

[Pierre Ferran]

Watching this with concern as well considering the amount of identifiable information VATSIM holds on its European Users, as well as old, insecure logging/data storing systems.

[Mark Richards]

viewtopic.php?f=1&t=76286

[Anthony Lawrence]

Mark et al,

 

Any further updates on this?

 

Do people who use any of the data feeds need to prepare for any changes? What about changes to any of the APIs such as AutoTools and SSO? It'd be a shame if systems started breaking on the 25th, because changes have been rolled out without any communication.

[Mark Richards]

Communication went to Divisions Directors on this 10:55z

[Anthony Lawrence]

Communication went to Divisions Directors on this 10:55z

 

I'm not a division director, so my question still stands about how these changes might impact the data feed and SSO system (both of which are usable by non-staff).

 

I've since noticed the new policy is now live on the website ( https://www.vatsim.net/docomeents/data-protection-data-handling-policy ) and within it, it specifically states:

 

In addition, whilst connected to the network information specific to their simulated aviation operation at that time is collected. This data may be transferred to other organisations to facilitate greater situational awareness within the simulation. The only personal information that is transmitted in this manner is the member’s name, membership number and network rating. Members are able to enter a location into the various clients on connection, this can be either their real or a simulated location at the discretion of the individual member.

 

Which I can only [Mod - Happy Thoughts]ume relates to the (currently public) data feed. The above statement suggests that this feed might no longer be public, since there's no mention of it being publicly accessible in that docomeent. Can you confirm whether the feed will remain public, or whether it's going to require a registration to gain access?

 

Additionally:

 

Various subsidiary parts of VATSIM may collect and store additional data relating to the administration of their respective subsection of VATSIM. As a rule, this data is not to be retrieved from CERT. All such data shall be collected, stored, managed, and secured in line with the principles outlined in this docomeent.

 

Where does the SSO data come from them? Presently, it comes from CERT. Does that mean any SSO implementations are about to break, because data isn't going to be p[Mod - Happy Thoughts]ed/data isn't allowed to be stored?

 

Whilst we're discussing this new policy, the below is worrying:

 

VATSIM data is retained indefinitely unless removal is requested from a VATSIM member, as outlined in this policy.

 

That seems to be at odds with what GDPR seeks to achieve for a few reasons: (a) data should not be kept for longer than is necessary for the purpose of which the personal data is processed; (b) personal data that is inaccurate, should be erased. Instead, it seems that clause has been added purely to justify the desire to retain the information of all inactive members who haven't connected in a very long time.

[Gunnar Lindahl]

Hi Ant,

 

Addressing your points:

 

Which I can only [Mod - Happy Thoughts]ume relates to the (currently public) data feed. The above statement suggests that this feed might no longer be public, since there's no mention of it being publicly accessible in that docomeent. Can you confirm whether the feed will remain public, or whether it's going to require a registration to gain access?

 

The data feed is covered in the Privacy Policy under '1.3 - Personal Statistical Information' and I can confirm that it will remain publicly available:

 

"[...] This personal information can be seen by other members and/or VATSIM affiliates and partners. In addition, this information may also be available to the general public via the internet. For further information regarding the availability of a member's personal statistical information, please see the VATSIM User Agreement."

 

Where does the SSO data come from them? Presently, it comes from CERT. Does that mean any SSO implementations are about to break, because data isn't going to be p[Mod - Happy Thoughts]ed/data isn't allowed to be stored?

 

I believe the intention behind this clause is to make clear local facilities cannot simply access CERT and pull personally identifiable information from it for their own purposes. I accept it could be interpreted differently as you've described but to be clear SSO integrations will continue to function as before.

 

That seems to be at odds with what GDPR seeks to achieve for a few reasons: (a) data should not be kept for longer than is necessary for the purpose of which the personal data is processed; (b) personal data that is inaccurate, should be erased. Instead, it seems that clause has been added purely to justify the desire to retain the information of all inactive members who haven't connected in a very long time.

 

I don't agree with your interpretation of this at all.

 

Re (a) - retention of information:

 

Principle 5 of the GDPR covers this. According to the ICO guidance:

 

"It is good practice to regularly review the personal data you hold, and delete anything you no longer need. Information that does not need to be accessed regularly, but which still needs to be retained, should be safely archived or put offline."

 

If I sign up to eBay tomorrow and sell a few things, and then don't use my selling account for a year or two, I'd be pretty annoyed if I returned 2 years later to find my account had been deleted. Similarly, if I signed up to VATSIM and clocked 50 hours, then went away and got a new job or started a family, and came back a couple of years later, I'd be pretty disappointed if VATSIM had deleted my account. The key point in the 5th Principle is "longer than is necessary."

 

In other organisations/businesses there may be personal information collected that should feasibly be deleted after a period of time because they don't need it. In comparison to others, VATSIM collects very little personally identifiable data so this doesn't really apply.

 

In fact, VATSIM already has processes that follow the spirit of this area of GDPR pretty well. When an account isn't used for 6 months, a user must reactivate their account which involves them having to positively confirm that their registered email address is in date. Thus we are ensuring that the data we hold is accurate.

 

So to summarise: the clause is there for good reason and that is to make clear that VATSIM will keep data on file unless the user requests for it to be deleted. This is no different to countless other organisations and VATSIM considers it to be in line with the both the wording and intent of the legislation itself. Of course, anyone who isn't content with their data being held will be able to request for it to be erased.

 

Re (b) - inaccurate data erasure:

 

Can you provide an example of personally identifiable data that VATSIM collects that is at risk of becoming out of date and thence be a candidate for deletion? I can't...

 

Hope this makes sense. Apologies for dodgy formatting - writing this on a break at work.

[Jackson Harding]

 

In addition, whilst connected to the network information specific to their simulated aviation operation at that time is collected. This data may be transferred to other organisations to facilitate greater situational awareness within the simulation. The only personal information that is transmitted in this manner is the member’s name, membership number and network rating. Members are able to enter a location into the various clients on connection, this can be either their real or a simulated location at the discretion of the individual member.

 

Which I can only [Mod - Happy Thoughts]ume relates to the (currently public) data feed. The above statement suggests that this feed might no longer be public, since there's no mention of it being publicly accessible in that docomeent. Can you confirm whether the feed will remain public, or whether it's going to require a registration to gain access?

 

There is also no mention of it not being public. It is being treated as what it is. Within the network it is merely our own data, transmitted under our claim of legitimate interest. When it leaves the network it is a data transfer. And this docomeent states that it is being made available for the legitimate interest of enhancing people's situational awareness online. If someone objects to this legitimate interest there are procedures we can follow.

 

 

Various subsidiary parts of VATSIM may collect and store additional data relating to the administration of their respective subsection of VATSIM. As a rule, this data is not to be retrieved from CERT. All such data shall be collected, stored, managed, and secured in line with the principles outlined in this docomeent.

 

Where does the SSO data come from them? Presently, it comes from CERT. Does that mean any SSO implementations are about to break, because data isn't going to be p[Mod - Happy Thoughts]ed/data isn't allowed to be stored?

 

That probably should have read directly from CERT, well spotted. We are trying to encourage people to only do so via a system utilising SSO to access the data indirectly. The only reason to access CERT directly will be if you have a genuine network related reason. Specific guidance on this access is being developed, and no we don't have a timeframe, it would be nice if it's before Friday. Realistically I've run the So What Ruler over what happens if it's a few days beyond that and haven't come up with a compelling reason to wet myself.

 

Whilst we're discussing this new policy, the below is worrying:

 

[VATSIM data is retained indefinitely unless removal is requested from a VATSIM member, as outlined in this policy.

 

That seems to be at odds with what GDPR seeks to achieve for a few reasons: (a) data should not be kept for longer than is necessary for the purpose of which the personal data is processed; (b) personal data that is inaccurate, should be erased. Instead, it seems that clause has been added purely to justify the desire to retain the information of all inactive members who haven't connected in a very long time.

 

That section deals specifically with archiving. We don't archive our data, it's kept live so people can connect to the network at anytime, which is the whole reason for the network in the first place.

 

Long term retention is indeed something we are going to do. We have 20 years of accomeulated data that shows we have inactive members coming back to the network all the time on a regular basis. We contend it is in the legitimate interest of the network to ensure it's smooth functioning for all users, to facilitate the members return, to not have them have to start over (which would impact the legitimate interest of the network and it's users due to training delays) etc etc etc, with all their ratings, accomplishments and record intact that we do so. If our data showed it was not a frequent event we would have handled this differently. If a member objects to this claim of legitimate interest (as is their right), or asks for deletion we will of course do so, and have put in place the processes to make this happen.

 

Regards,

Jackson

[Brad Littlejohn]

Another question regarding this.

 

While VATSIM as a whole has put out an update regarding GDPR, and while they have said that this information has been pushed out to other divisions, does that require those divisions to put out their own separate disclosure and privacy notices to each of their members? For example, as VATSIM already laid it out at POLICY, does that mean that VATUSA, VATUK, VATUER, VATNZ, etc. etc. need to do the same thing?

 

I ask because also being in IT I have had to work on this for various sites, but as the are all under the same domain, most division sites within VATSIM aren't, and it may be A Good Idea[tm] to prepare the users for the monotony of accepting the new policy changes at each division's website, let alone each individual sector's/FIR's sites.

 

BL.

[Anthony Lawrence]

Hi Ant,

 

Thanks for taking the time to shed some light on this - I appreciate GDPR is like wading through treacle at times.

 

 

Which I can only [Mod - Happy Thoughts]ume relates to the (currently public) data feed. The above statement suggests that this feed might no longer be public, since there's no mention of it being publicly accessible in that docomeent. Can you confirm whether the feed will remain public, or whether it's going to require a registration to gain access?

 

The data feed is covered in the Privacy Policy under '1.3 - Personal Statistical Information' and I can confirm that it will remain publicly available:

 

"[...] This personal information can be seen by other members and/or VATSIM affiliates and partners. In addition, this information may also be available to the general public via the internet. For further information regarding the availability of a member's personal statistical information, please see the VATSIM User Agreement."

 

 

OK, can I clarify then that members will be asked for their explicit consent to this public release of their data, rather than it being buried within a docomeent that you hope they've read? Article 7 of GDPR is very clear, in that consent should be clearly distinguishable, intelligible, and easily accessible in a clear and plain language.

 

My concern with the data remaining public is that by being a data controller, when you then publish that data for others to use, how are you going to handle erasure notices to anyone that has consumed that data? It'd be far better to have at least _some_ knowledge of who is using your data, to issue such notices to them too.

 

 

Where does the SSO data come from them? Presently, it comes from CERT. Does that mean any SSO implementations are about to break, because data isn't going to be p[Mod - Happy Thoughts]ed/data isn't allowed to be stored?

 

I believe the intention behind this clause is to make clear local facilities cannot simply access CERT and pull personally identifiable information from it for their own purposes. I accept it could be interpreted differently as you've described but to be clear SSO integrations will continue to function as before.

 

 

Thanks - that makes sense.

 

That seems to be at odds with what GDPR seeks to achieve for a few reasons: (a) data should not be kept for longer than is necessary for the purpose of which the personal data is processed; (b) personal data that is inaccurate, should be erased. Instead, it seems that clause has been added purely to justify the desire to retain the information of all inactive members who haven't connected in a very long time.

 

I don't agree with your interpretation of this at all.

 

Re (a) - retention of information:

 

Principle 5 of the GDPR covers this. According to the ICO guidance:

 

"It is good practice to regularly review the personal data you hold, and delete anything you no longer need. Information that does not need to be accessed regularly, but which still needs to be retained, should be safely archived or put offline."

 

If I sign up to eBay tomorrow and sell a few things, and then don't use my selling account for a year or two, I'd be pretty annoyed if I returned 2 years later to find my account had been deleted. Similarly, if I signed up to VATSIM and clocked 50 hours, then went away and got a new job or started a family, and came back a couple of years later, I'd be pretty disappointed if VATSIM had deleted my account. The key point in the 5th Principle is "longer than is necessary."

 

 

I think you'd be somewhat surprised if you dived into some of the new GDPR publications of large organisations, such as eBay on the stance of "abandoned" accounts. Off the top of my head, Amazon's approach is 2 years of inactivity for their cloud services (Marketplace, Files, Music etc) before all data is deleted, with members being warned after 1.5 years.

 

 

In other organisations/businesses there may be personal information collected that should feasibly be deleted after a period of time because they don't need it. In comparison to others, VATSIM collects very little personally identifiable data so this doesn't really apply.

 

 

It depends on if we're using the same definition of personally identifiable, since GDPR adds IP addresses and 'identifiers' to the list of personally identifiable information, I'd actually put it back at you that you gather quite a lot with all of the connection data, server logs, statistics, etc.

 

 

In fact, VATSIM already has processes that follow the spirit of this area of GDPR pretty well. When an account isn't used for 6 months, a user must reactivate their account which involves them having to positively confirm that their registered email address is in date. Thus we are ensuring that the data we hold is accurate.

 

 

But you aren't though, as there's no expectation for members to provide up-to-date information if their account is inactive and they don't wish to use it. Additionally, these members still appear in public searches, on the statcheck page, the forum, the statistics website, and therefore are still being processed, with inaccurate data.

 

Re (b) - inaccurate data erasure:

 

Can you provide an example of personally identifiable data that VATSIM collects that is at risk of becoming out of date and thence be a candidate for deletion? I can't...

 

 

Age, location, email address. If we focus on age for a second, presently you only track age band which is out of date for the vast majority of individuals. I'm led to believe that under the new arrangement, you'll ask for a user's age (rather than date of birth) - this data might therefore go out of date as quickly as 1 second (if they registered 1 second to midnight on the eve of their birthday) or in 365 days - either way, the data about that individual is then incorrect and must be updated (presently, age brackets can't be updated). Location is no different, nor is email address (particularly of abandoned accounts).

 

If we consider the fact that a member may well update their email address on .net, there's currently no provision to automatically cascade this update out to third parties who received this data via SSO, without the member either being a member of the division (and the division pulled a divdb download), or the member logging into the site via SSO. In which case, it's not "accurate across all systems". However, I also notice that the BoG want the final say on whether or not a member is allowed to update their personal data, when the policy states "The final authority to update such information shall be at the sole discretion of the VATSIM Board of Governors".

 

Continuing on the age front for a second, how are we handling existing members that are below 16? Are we ignoring that fact? I think, regardless of GDPR, there's a whole host of safeguarding reasons to actually want to know who our young, vulnerable members are to ensure that as an organisation, VATSIM ensures they're abreast of how to stay safe online.

 

Additionally, from a technical perspective, there's very few details about how data is stored securely - the policy outlines that access to the database is via a custom built web interface, but I know of a good number of people that have direct database access via both the command line and the DBMS UI. However it doesn't detail whether the data is encrypted at rest, or whether any backups are taken, transferred or encrypted. Does that need additional clarification?

 

Having now seen the email sent to regional directors last night advising them of how to proceed, which confirms data is held in Germany, can I ask how international data transfers are being handled? Whilst SSO is likely to be covered, as it asks for explicit consent when sharing data to a new third party, the same isn't true for the data feed where personal data is publically shared with individuals outside of the EU.

 

If you'd like a good read, written from a technical perspective by someone who's had a lot of input on GDPR implementations, check out https://techblog.bozho.net/gdpr-practical-guide-developers/

 

-A.

[Mark Richards]

Another question regarding this.

 

While VATSIM as a whole has put out an update regarding GDPR, and while they have said that this information has been pushed out to other divisions, does that require those divisions to put out their own separate disclosure and privacy notices to each of their members? For example, as VATSIM already laid it out at POLICY, does that mean that VATUSA, VATUK, VATUER, VATNZ, etc. etc. need to do the same thing?

 

I ask because also being in IT I have had to work on this for various sites, but as the are all under the same domain, most division sites within VATSIM aren't, and it may be A Good Idea[tm] to prepare the users for the monotony of accepting the new policy changes at each division's website, let alone each individual sector's/FIR's sites.

 

BL.

Brad

 

The suggestion is that Divisions can either refer to the VATSIM Privacy Policy (which is the preferred option) or create their own local policy that cannot contradict the VATSIM policy (as is the case with all local policies).

 

What we have determined is that all requests for deletion, correction or release of data will be handled by the Membership Department who will in turn filter this down to, and coordinate with, local facilities that the member is, or has been, a member of, as transfer information is kept on the members CERT record.

 

I hope this helps.

 

Mark

[Brad Littlejohn]

Another question regarding this.

 

While VATSIM as a whole has put out an update regarding GDPR, and while they have said that this information has been pushed out to other divisions, does that require those divisions to put out their own separate disclosure and privacy notices to each of their members? For example, as VATSIM already laid it out at POLICY, does that mean that VATUSA, VATUK, VATUER, VATNZ, etc. etc. need to do the same thing?

 

I ask because also being in IT I have had to work on this for various sites, but as the are all under the same domain, most division sites within VATSIM aren't, and it may be A Good Idea[tm] to prepare the users for the monotony of accepting the new policy changes at each division's website, let alone each individual sector's/FIR's sites.

 

BL.

Brad

 

The suggestion is that Divisions can either refer to the VATSIM Privacy Policy (which is the preferred option) or create their own local policy that cannot contradict the VATSIM policy (as is the case with all local policies).

 

What we have determined is that all requests for deletion, correction or release of data will be handled by the Membership Department who will in turn filter this down to, and coordinate with, local facilities that the member is, or has been, a member of, as transfer information is kept on the members CERT record.

 

I hope this helps.

 

Mark

 

Hey there, Mark.

 

This makes absolute sense, and I understand that. However what I wonder that may need clarification is the following scenario.

1. A user joins VATSIM. That's fine, VATSIM handles the data usage via CERT, and as such, VATSIM's policy holds sway.
   
2. That user, for example, selects VATUSA as their division. Again, that's fine, as because of SSO, that data is held by CERT, so VATSIM's policy holds sway.
   
3. That user joins a sector/FIR that may not be using SSO via CERT. Does this mean that if they are not using SSO (which CERT would hold the record), that the sector/FIR needs to address GDPR with its own disclosure policy regarding how data is used (username, p[Mod - Happy Thoughts]word, etc.)?

 

If the answer is yes, then a lot of sector/FIR sites are going to have some work to do in short order to release their policy (which will be similar to VATSIM's (via VATUSA in this example above) so they are ready once GDPR goes into effect.

 

Or would this be a better time to try to get as many sites we have under the umbrella of VATSIM (read: authentication via SSO) so that one policy notice covers all?

 

I hope I explained that properly.

 

BL.

[Mark Richards]

If the answer is yes, then a lot of sector/FIR sites are going to have some work to do in short order to release their policy (which will be similar to VATSIM's (via VATUSA in this example above) so they are ready once GDPR goes into effect.

 

Or would this be a better time to try to get as many sites we have under the umbrella of VATSIM (read: authentication via SSO) so that one policy notice covers all?

 

I hope I explained that properly.

 

BL.

Brad, we are working towards sector/FIR sites setting themselves up in SSO to ensure that the VATSIM policy will hold. This is one of the next stages of the plan moving forward.

[Brad Littlejohn]

If the answer is yes, then a lot of sector/FIR sites are going to have some work to do in short order to release their policy (which will be similar to VATSIM's (via VATUSA in this example above) so they are ready once GDPR goes into effect.

 

Or would this be a better time to try to get as many sites we have under the umbrella of VATSIM (read: authentication via SSO) so that one policy notice covers all?

 

I hope I explained that properly.

 

BL.

Brad, we are working towards sector/FIR sites setting themselves up in SSO to ensure that the VATSIM policy will hold. This is one of the next stages of the plan moving forward.

 

Perfect! Completely answers my question!! Thanks!!

 

BL.

[Anthony Lawrence]

Any chance of any further responses to my questions..?

 

I only bump, as I've now had chance to sit down and read the privacy policy in full (side-by-side with the Data Protection & Handling Policy), which has prompted some additional questions on the two policies you've provided.

 

In the privacy policy you state:

 

All member information, not just the sensitive information mentioned above, is restricted. This information is p[Mod - Happy Thoughts]word protected and only those people who need the information to perform a specific job (for example Administrators, Conflict Resolution Staff, Membership Staff, Supervisors, and Divisional Directors) are granted access to personally identifiable information.

 

However, within the DP&H Policy, you've outlined that some PII is released publicly. This seems at odds with the other policy.

 

Within the DP&H you also state:

 

P[Mod - Happy Thoughts]words are stored as hashed encrypted data wherever possible. As a general principle p[Mod - Happy Thoughts]words are not to be stored as plain text.

 

I'm not entirely sure the policy can make this claim, although I'm happy to be proven wrong on my following point as the network doesn't use the same public copy of FSD as I have on my machine. The only p[Mod - Happy Thoughts]word we've got for VATSIM, is our network p[Mod - Happy Thoughts]word (or "CERT" p[Mod - Happy Thoughts]word). Based on the fact that FSD requires p[Mod - Happy Thoughts]words in plaintext, a user's p[Mod - Happy Thoughts]word is stored in plaintext within the CERT database and on the FSD servers within the cert.txt file. So, "wherever possible" suggests that there are instances where this isn't the case.

[Andrew Chan 1312598]

I'm interested in this as well, especially given how GDPR implementation is (at the time of writing) less than a day away.

However, within the DP&H Policy, you've outlined that some PII is released publicly.

Whatever way you slice it, real full names are considered personally identifying information, period. This is even more so when you combine it with the user's country of residence. The following tools allow data access without any kind of authentication:

• The data feeds (i.e. vatsim-data.txt), which contain the full name of all online users
  
• The automated CID verification tool (https://cert.vatsim.net/cert/vatsimnet/idstatus.php?cid=CID), which contains first/last name, country, registration date etc. I presume this is what is meant by "direct CERT access"?

EDIT #2:

This thread was bumped recently, and looks like "direct CERT access" refers to accessing one's entire CERT record (including staff comments), and not one that only provides a subset of the data, as is the case with this CID verification tool. If I'm understanding this correctly, this means anyone on the official VATSIM staff list (ADMs, SUPs) can view and modify this record? Does this also include division staff?

 

Of course, there's also SSO, but that requires user authentication, and the data that is transferred is clearly displayed on the SSO login page. I suppose you could modify/kill the above 2 non-authenticated tools to make them GDPR-compliant, but I don't see any official statement regarding their fate beyond May 25 (correct me if I'm wrong).

 

Within the DP&H you also state:

 

P[Mod - Happy Thoughts]words are stored as hashed encrypted data wherever possible. As a general principle p[Mod - Happy Thoughts]words are not to be stored as plain text.

 

I'm not entirely sure the policy can make this claim, although I'm happy to be proven wrong on my following point as the network doesn't use the same public copy of FSD as I have on my machine. The only p[Mod - Happy Thoughts]word we've got for VATSIM, is our network p[Mod - Happy Thoughts]word (or "CERT" p[Mod - Happy Thoughts]word). Based on the fact that FSD requires p[Mod - Happy Thoughts]words in plaintext, a user's p[Mod - Happy Thoughts]word is stored in plaintext within the CERT database and on the FSD servers within the cert.txt file. So, "wherever possible" suggests that there are instances where this isn't the case.

VATSIM's implementation of FSD does indeed store p[Mod - Happy Thoughts]words in plaintext. This is proven by the fact that the p[Mod - Happy Thoughts]word recovery feature in the membership dashboard sends an email with the p[Mod - Happy Thoughts]word (in plaintext).

 

For regular members, isn't this the only p[Mod - Happy Thoughts]word that's stored? Then what's the point of saying that p[Mod - Happy Thoughts]word hashing/encrypting (which, by the way, sounds ridiculous, based on the terminology alone) is a "general principle" when the only p[Mod - Happy Thoughts]word stored is in plaintext?

 

I've also gone through the DP&HP, and there are some more clauses that seem to raise even more questions than it answers. Here's the ones I've noticed:

1.2 - Types of data

VATSIM collects a range of personal data on members, both at the time of joining and while a member is connected to the VATSIM network for the purpose of ensuring the efficient functioning of the network. This data includes:

• ...
  
• Their history of connections to the network, including their IP address and additional security information to protect the integrity of the network
  
• ...

What does "additional security information to protect the integrity of the network" mean exactly? This is vague.

Similarly, the Privacy Policy mentions the following:

1.3 - Personal Statistical Information

In the normal course of connecting to the VATSIM network, certain personal statistical information will be collected. This information includes, but is not limited to, full name, the time and duration of a member's connection, the callsign(s) used, flightplan(s) filed and other information necessary and useful for the maintenance of the network and your account.

To me, this seems to be a way to justify collecting even more personal information, without revealing what exactly is being collected.

 

4.2 - Updating

A VATSIM Member may request an update of his/her retained information by making a request in writing to the Vice President of Membership.

The final authority to update such information shall be at the sole discretion of the VATSIM Board of Governors.

This seems to imply that the BoG can refuse to update inaccurate data, which would be contrary to the GDPR where "every reasonable step must be taken to ensure that personal data that are inaccurate are either erased or rectified without delay." (Article 5, (1)(d)).

 

6.3 - Provision for verifying identity

Where the person managing the access procedure does not know the individual personally there should be provision for checking their identity before handing over any information.

What is this provision?

 

9.5 - Procedure for granting erasure

VATSIM shall evaluate all requests for erasure. VATSIM reserves the right to retain any data that it believes is in it’s legitimate interest to do so, or that is required to establish, exercise, or defend any legal claims.

So data can still be retained, despite the right to erasure? Yes, there are exemptions in the GDPR, but as far as I can tell from here, the only one that might apply would be the "legal obligation" clause. VATSIM's "legitimate interest" (aside from "legal claims", as mentioned) would not - and should not - be considered a "legal obligation". But when would that apply? An ex-member suing VATSIM for, I don't know, defamation?

 

(edit: "The automated CID verification tool" / "direct CERT access")

Edited May 26, 2018 at 12:50 AM by Guest

[Mark Richards]

Ant

 

For consistency, Gunnar will be replying to your questions.

 

Mark

[Mark Richards]

I'm interested in this as well, especially given how GDPR implementation is (at the time of writing) less than a day away.

I'm currently working and your questions require me to set aside sufficient time in which to properly address them. I will respond over the weekend as time permits.

 

Mark

[Anthony Lawrence]

Ant

 

For consistency, Gunnar will be replying to your questions.

 

Mark

 

Thanks Mark

[Andrew Chan 1312598]

I'm interested in this as well, especially given how GDPR implementation is (at the time of writing) less than a day away.

I'm currently working and your questions require me to set aside sufficient time in which to properly address them. I will respond over the weekend as time permits.

 

Mark

 

Any updates? It's been 2 weeks since.

 

Thanks!