Effective at 10 Dec 2018 there will be a new required field for cloud apps, stating if personal data is stored outside of Atlassian systems by an app. We have an app that stores user data in user properties (/rest/api/2/user/properties). We think that this means that we still can select “No” in the new field.
Is this correct?
@m.schmidt, that sounds a bit odd to me. Can you be more specific as to what personal data you are storing in user properties, and for what purpose?
@m.schmidt - Jira will not clear user properties after data deletion is processed for account close. This means that if you are storing personal data in user properties you should help clear personal data after account close which means you will have to select “Yes” and implement the Personal Data Reporting API.
@epehrson @akassab We currently store the userids of users (covering for a user that is not in office), but change to accountIds there also.
Other data that is stored there is project ids and a personal message, that is send, when someone assigns an issue to this user.
This information is automatically deleted as soon as the date of the absence is over.
Does this still mean we must implement the api?
@m.schmidt, if you replace any user identifiers in those user properties by account IDs, then you will not be storing any personal data. The project ID is an Atlassian entity identifier, and the personal message is user-generated content. Neither is considered personal data.
As long as you store user keys or usernames or other personal data in user properties, you will be required to select “Yes” in the Marketplace selector and report on these user accounts. Once you complete the migration to account ID, you can select “No”.
Hi,
Is this also need for Server Apps? My Add-on named Timesheet for Confluence stores usernames in MySQL database installed to customers server? So do I need to select “Yes” on this?
Hi @matti.kiviharju -
The field applies to all apps (Server / Cloud / Data Center). The requirement to implement the personal data reporting API is only applicable for Cloud.
Hello @akassab ,
We are only storing account Id and Display Name of the user in our connect app ( replaced userkey /userId with account Id). Will Display Name be considered as personal data?
Thanks!!
Hi @sfg - Yes. Display Name is personal data. We recommend only storing accountID.
Wait what? Is it the official stance of Atlassian that user generated content is not considered PII? You people have a weird interpretation of GDPR…
@remie, can you elaborate on what you disagree when comes to PII? I’m still learning.
The disagreement follows from the choices Atlassian is making in regards to PII, which are very inconsistent.
In general, there are three distinct roles defined in the GDPR: the Data Subject (the natural person to which the PII applies), the Data Controller (the entity that requests and handles the PII from the data subject) and the Data Processor (the entity that does a specific task with that PII on behalf of the Data Controller).
Atlassian is in a bit of a tricky spot: it does business with both individual users (making Atlassian the Data Controller) and companies (for which Atlassian is Data Processor, and the company itself is Data Controller on behalf of the employee). To complicate things: Atlassian has decided to enforce an Atlassian ID for all users, meaning that regardless if you are accessing the Jira Cloud instance of your company, you, as a data subject als go into an agreement with Atlassian with Atlassian being the Data Controller.
This mixup makes it really hard: normally, if I were a employee of a company I would be able to ask for removal of my PII upon resignation. The company is than obliged to remove my records from all systems, including Jira. However, because Atlassian is using Atlassian ID, it means my relationship with Atlassian could in theory live beyond my commitment to the Jira Cloud instance of my employer. I could have used that same ID to sign up for a different service within the Atlassian sphere, say BitBucket Cloud.
To fix this problem, Atlassian has embarked on a mission to A) irradiate their systems from PII as much as possible, B) create very complex privacy settings (incl. UI option for each different state) that will make APIs behave differently based on the privacy settings of either the company or the individual user, C) create PII records API for interfacing with 3rd parties (vendors) to allow them to trickle down requests for data removal via Webhooks and D) update all legal documents to make sure everyone in the Atlassian sphere plays by the same rules.
From that perspective, it is really strange to see that Atlassian has taken their hands of user generated content. Because that does not stroke with the fact that they are doing their best to control every aspect of PII within their systems and the systems of 3rd parties (vendors).
There is probably a good technical reason for this, because detecting PII in user generated content is really difficult. And in some extend, Atlassian is right for not touching this. However, they cannot have it both ways: either you want to fully control PII within your systems, or you create a legal structure in which you do not take any responsibility for PII leaving it solely with the Data Controller or Data Subject.
The strange legal mixup Atlassian has created for itself in combination with the practical implementation simply doesn’t make any sense from a GDPR perspective.
Thanks @akassab!!
In order to report the user personal data for connect apps using following API
POST /rest/atlassian-connect/latest/report-accounts
Scenario : One database for multiple tenants ,
For the purpose of personal data reporting
Thanks!!
Hi @epehrson, could you, or anybody else from the Atlassian staff, please re-confirm, that an account id is still not considered personal data?
As to my understanding the account id identifies a single person across Atlassian products. And reading the GDPR that pretty much sounds like personal data:
“Personal data are any information which are related to an identified or identifiable natural person.
The data subjects are identifiable if they can be directly or indirectly identified, especially by reference to an identifier such as a name, an identification number, location data, an online identifier or one of several special characteristics, which expresses the physical, physiological, genetic, mental, commercial, cultural or social identity of these natural persons. In practice, these also include all data which are or can be assigned to a person in any kind of way. For example, the telephone, credit card or personnel number of a person, account data, number plate, appearance, customer number or address are all personal data.”
Thanks!
Ok, let me start by saying I’m not a lawyer. Also, I’m not an Atlassian staff member. However, I do have some insights into GDPR as a result of running a privacy consultancy firm together with a lawyer at the height of GDPR implementation madness.
The key to the paragraph that you have posted is:
The data subjects are identifiable if they can be directly or indirectly identified
Let’s say a random number 1858230 is the database identifier for my account in any e-commerce system. The number itself is not personal data, because, well, it’s just a number.
It does however become personal data when compounded with additional information. For instance, if you would know that this is an Amazon ID and you would somehow have a means to retrieve my personal information from Amazon using that ID, the number 1858230 can be used to identify me.
Within the context of Atlassian, that means that storing a random string like the Atlassian ID in a database in and of itself does not make that information personal data. An attacker would not be able to actively use the data from your database to identify a data subject, any more than it would if you would have stored a field containing 1858230.
Only compounded with the knowledge that this is an Atlassian ID, and with the means to extract additional information from Atlassian based on that ID would the random string turn into personally identifiable data.
Having said that, please do keep in mind that when you store the base URL of the client instance (A), the shared secret for your app (B) and the account ID of users (C) into the same database or database table, you create a compounded set of information that together does constitute personal identifiable data, following this logic:
A is semi-public information and does not in itself represent PII
B will grant API access to all data to which the app has access (based on scopes) for those instances for which the app is installed
C will allow you to directly query information for that user based on their ID
If you have A+B, you can connect to the API and potentially retrieve PII for all users of that instance. Now if you have A+B+C you can directly retrieve PII for that user, only limited by app scope and global user privacy settings.
I hope this clarifies how random data becomes PII within the context of GDPR.
Thanks @remie for the detailed clarification!