Sorry, but that sounds like a cheap excuse. There has to be a link in order for roon to work. What if I changed my log-in details on my roon core? Roon would stop working. Somehow personal info and library info have to be connected. Even if it is one way only, there could be a way to do it.
I am no IT guy, but there are other companies doing it. The German email provider posteo.de for example, where you can open an account without giving personal information. However, as the account is 1€ per moth, they have an architecture to link a payment made e.g. by credit card to your account, without compromising your anonimity. More info: https://posteo.de/en/site/payment).
This is to say that if Roon wanted to link personal data and library data for them to be able to delete all data if necessary, they could do it.
I assume that this whole topic is a nightmare for Roon, as building these infrastructures is probably expensive and difficult.
Most commercial companies, especially those creating IP/value from aggregated data do exactly what roon do. It’s not an excuse or a way around the rules, identifiable data is controlled and kept separate. Non identifiable data is retained as commercial capital. Be that Transport, Retail, Real Estate.
Public Sector companies that have passed intense GDPR scrutiny still retain the bulk data and publish it via open APIs for anyone to see.
As an example every journey by TFL bike hire is available at cycling.data.tfl.gov.uk including start docking station and destination with start time and duration. Fully GDPR compliant by removing personal identification. (Unless you analyse the data and notice the same journey done every day, at which point you could physically monitor and identify! But GDPR compliant).
Actually, going by the description of the way roon works this software is better architected than many I’ve seen where GDPR compliance is questionable and relies on a lot of manual intervention and a favourable wind.
personal data’ shall mean any information relating to an identified or identifiable natural person (‘data subject’); an identifiable person is one who can be identified, directly or indirectly, in particular by reference to an identification number or to one or more factors specific to his physical, physiological, mental, economic, cultural or social identity;
any information about an individual maintained by an agency, including (1) any information that
can be used to distinguish or trace an individual‘s identity, such as name, social security number, date and
place of birth, mother‘s maiden name, or biometric records; and (2) any other information that is linked or
linkable to an individual, such as medical, educational, financial, and employment information.
If you leave out the link between something and the identifiable natural person, it is no longer personal data. It can not be used to identify a person!
This is untrue.
I can provide some examples:
Example1: (no link):
Every time someone enters/plays a radio URL in Roon, we note that. We do not track who added it, just what was added and when. Once we got an understanding of how people used internet radio, we decided it was worth tackling the problem of making an internet radio directory. Thus:
Once this project is completed, a very nice directory for all the world’s internet radio stations will be available in Roon organized, searchable, and sortable/focusable.
The station URL in our database is not tied to you at all. It can not be personal data because there is no way to go from the station to a person. If there was to be an attack on our database that holds all the stations, it would be impossible to determine who added what station.
Example 2 (no link):
Every time you view lyrics, we know who you are where you were when you did it. We then collect which lyrics were viewed in what regions. Nowhere is it noted an individual viewed a certain lyric. We then share this collected data with the company we license lyrics from, for purposes of compensating the copyright holders. If that data was compromised, it would be impossible to determine who viewed what lyrics.
Example 3: (link in local db, copy without link):
We have a notion of your play history. This is stored on your Roon Core machine (try installing Roon on another machine, you will see it disappear). A second copy of this play history data, with richer data, is also saved in the cloud, but with no link back to personal data. This is critical to why the play history data can be both usable and at the same time, not link back to an “identifiable natural person”. [Note: I have edited this section for clarity]
If implemented properly, it is possible to build a large class of data-driven products without compromising privacy.
We segment data we collect into various databases, in different locations, with different cloud service providers. Often, these decisions fall nicely in with costs. For example, personal data is often small and highly critical to operations, so it requires a higher level of availability. Non-personal data does not. You can store it in more cost-efficient locations. Most importantly, the “Core” if Roon’s architecture means we can do things that seem impossible because we have a database sitting on your network.
The answer is we take data into the cloud, in the US, but some of it is not personal data or PII. Because we have your local database to work with as well (our favorite place due to speed and cost to us), we can store data there and keep it personal without being impacted by any privacy laws. We can do this because we have a Roon Core. I believe this is the part @Coltrane was missing when he stated the links must be there. We don’t hold your database in our cloud. Licensing is purely to get you access to our software and cloud services. Your database is local.
You may not feel comfortable giving us data you’ve generated, for free, and having us build a business on that, but this is where you can vote with dollars. I stated this earlier in my Michael Jackson example. @Pepe_A seems to think I was being condescending, but it was not my intention. I was merely explaining what we do and don’t do by example.
Additionally, many features in Roon were a result of collecting non-personal data. This stuff exists in Roon because we collect. We already discussed radio directory, but there are others.
We do collect data in our cloud services, in the US. Some of that data is personal and some is not. We’ve told you exactly what personal data we collect in the privacy policy. You seem to think there is more, like library data, but the data we collect is not personal, by either definition (Europe or US). The personal data we collect is listed in the privacy policy. The non-personal data is not disclosed there, but it also not required we disclose it. It’s not a requirement of GDPR or EU DPDs. This is what I meant when I was talking about everybody’s personal definition of privacy vs the one stated by law.
I’ve cleaned up the “go away” posts and the discussion on discussion about GDPR.
Let’s stick to the topic of what is collected by Roon.
Roon collects personal data and it is listed in the privacy policy. It also collects non-personal data that is mentioned broadly in the privacy policy but not explicitly annotated. We have gone to lengths to unpersonalize data and take advantage of our split database architecture (cloud and local).
Before you proceed to make claims about what is and isn’t true, make sure you understand our architecture and the rules of GDPR and the EU DPDs. Both state personal data must be explicitly annotated. Non-personal data is not covered by either. A datum that can not be tracked back to a specific person is not personal. Every example in the documents above agrees, as does the text of the laws/directives.
The debate seems to be whether the musical data of Roon members such as play history or library content is “personal data” for the purposes of the EU directive (linked by Danny above).
Although the words of the directive itself are the legal obligation, it is useful to see how the guidance published by EU members interprets those words. This guide published by the ICO in the UK is an example and it includes the following points:
Personal data is information that relates to an identified or identifiable individual.
What identifies an individual could be as simple as a name or a number or could include other identifiers such as an IP address or a cookie identifier, or other factors.
If it is possible to identify an individual directly from the information you are processing, then that information may be personal data.
If you cannot directly identify an individual from that information, then you need to consider whether the individual is still identifiable. You should take into account the information you are processing together with all the means reasonably likely to be used by either you or any other person to identify that individual.
Information which has had identifiers removed or replaced in order to pseudonymise the data is still personal data for the purposes of GDPR.
Information which is truly anonymous is not covered by the GDPR.
What are identifiers and related factors?
An individual is ‘identified’ or ‘identifiable’ if you can distinguish them from other individuals.
A name is perhaps the most common means of identifying someone. However whether any potential identifier actually identifies an individual depends on the context.
A combination of identifiers may be needed to identify an individual.
The GDPR provides a non-exhaustive list of identifiers, including:
name;
identification number;
location data; and
an online identifier.
‘Online identifiers’ includes IP addresses and cookie identifiers which may be personal data.
Other factors can identify an individual.
Can we identify an individual directly from the information we have?
If, by looking solely at the information you are processing you can distinguish an individual from other individuals, that individual will be identified (or identifiable).
You don’t have to know someone’s name for them to be directly identifiable, a combination of other identifiers may be sufficient to identify the individual.
If an individual is directly identifiable from the information, this may constitute personal data.
Can we identify an individual indirectly from the information we have (together with other available information)?
It is important to be aware that information you hold may indirectly identify an individual and therefore could constitute personal data.
Even if you may need additional information to be able to identify someone, they may still be identifiable.
That additional information may be information you already hold, or it may be information that you need to obtain from another source.
In some circumstances there may be a slight hypothetical possibility that someone might be able to reconstruct the data in such a way that identifies the individual. However, this is not necessarily sufficient to make the individual identifiable in terms of GDPR. You must consider all the factors at stake.
When considering whether individuals can be identified, you may have to assess the means that could be used by an interested and sufficiently determined person.
The test as to whether an individual is “identified” or “identifiable” is stated as being able to distinguish them from other individuals, which seems very broad. That would explain why pseudonymous data is still “personal data”.
I think it boils down to whether the shared data has been anonymised. Danny has noted that the play history stored in the cloud has no link back to personal data which is a good start. That feels anonymous enough for me as a user. But whether it satisfies the EU definition may depend on whether the data base knows that my play history for today is a continuation of the same user’s play history for yesterday. If so, then that might be sufficient to distinguish me from other individuals so as to constitute identification within the above definitions.
I’d suggest after updating the privacy policy - that is, if an update is required, which from the enlightening discussion here seems to be the case - an additional KB article explaining what the concise and legally required passages in the policy do mean in practice ( = for example) would be rather helpful. Most of the prospective contents could be reused from this discussion so @danny it may not be too much additional effort.
Also, a system architected with privacy aspects in mind and controls in place is something worth to talk about – so do it!
It only needs every play to know the previous play id. Has nothing to do with the user. You can track history this way but when you get back to the first play, you no longer can get back to personal data.
An example: a test or development system that is cloned from production may include user names or IDs changed (pseudonyms) but customer data such as email, address, telephone, DOB, bank account etc. may be intact and could still be used to identify a person. This is why it is still covered by the regulation.
If I’ve understood Danny correctly, my Roon account and Roon library are completely separate. The first is associated with personal information and the second is not. Indeed there is no need to associate the two.
All Roon needs to know is that my library is not yours, but it doesn’t need to know that it belongs to me. So in this instance it is not personal information.
However, if some unique identifier for my library was associated to my account that’d be a different scenario.
Regarding the privacy policy or notice, I think it may benefit from an update but not at the cost of overcomplicating. These documents should be easily understood using simple plain language.
Thanks for all your input, this is a discussion worthwhile having. Also, I particularly appreciate Danny’s input. Not every COO would spend so much time to answer these rather delicate questions.
I may be a bit of an extremist in this regard, but I’d like to restate my argument from above. Consider it more an ethical than a legal argument.
I paid for Roon to use, so why do they have to use my library data, playlist data etc and use it for free? Roon clearly profits from this data. The argument for gathering this data is always to improve the product. But we all know that it is also a Business decision to gather data. Data is the new oil. Why not improve the product without gathering data? Isn’t it possible? How much would I have to pay for it if the data wasn’t monetarized, and Roon would still be reasonably profitable? This is a serious question.
I bought a lifetime license and I simply dread the idea that Roon could be sold or changed their terms and conditions and some other company would make money with the data I created by using Roon.
We cannot use any product without producing data. We even cannot live today without producing data. Think about it for a while. Everything you do produces data. Those who have the tools to collect the data and use it are the powerful agents of tomorrow. Amen;)
I understand what you are driving at here but I think that in the case of Roon at least what you create (library track info and play counts/lists) have no intrinsic value on their own. It has no monetary value to you or any other individual.
The value is added by Roon’s ability to anonymously combine all that data from multiple users and infer links between tracks and artists etc based on how the ‘crowd’ behaves.
At least this is my simplistic understanding of how Roon Radio works. That is where the value is and on your own you cannot create it, it requires many data points and requires Roon’s proprietary technology to infer the rest.
I dare say Roon could implement a sliding scale of opt-in/opt-out settings for data collection but of course you would potentially lose functionality the more you opt-out. And there would come point when you may as well just stick with iTunes
your library sits local to your machine. we never deal with it in the cloud.
The only times your library enters the equation in our cloud services is when it needs to update metadata. In that case, it makes requests for updates, but we do not have your library in the cloud and nor do we save the requests.
As for play history, its different… it goes into the cloud to power analytics for features like Roon Radio. But because that information is never associated with you, its non-personal. Only your database contains the information to link it back together to you, and your machine is not our cloud.
Ok thanks for clarifying. This is news to me. I thought you had an image of my library on your servers. Of course not the real files, but file name etc.
When @Martin_Webster and others stated “maybe Roon is not for you”, I believe this is what they were talking about. This is absolutely what I meant when I speak about ‘voting with your dollars’.
We’ve always been open about collecting usage data (there are sections written in plain language about this in our privacy policy), and we’ve also built up the product using features possible only through data collection. In the early days, we made many incorrect guesses about where to take the product focus. When we started using data, we made fewer bad decisions.
Could we create some product without collecting anonymous data? Absolutely, but it isn’t interesting to us. We want to be, as you said, “agents of tomorrow”, not fade into obscurity.
What genuinely confuses me is that even though this data has no value to you (or at least I don’t see how it does), you seem to care about sharing it. Why?
Dread is a pretty terrible emotion. Maybe I can fix that for you by switching you back to an annual subscription?
I have read this with interest and I think on balance Roon are providing an excellent service and have taken both reasonable and extensive steps to preserve privacy while still providing a useful and high grade service. They should be applauded for doing so not made to feel that they are one of the bad guys when they are absolutely not.
I have been so impressed with the service and the thought shown herein that I have upgraded my trial to a full sub. As you say vote with your dollar.
