Comment by okamiueru | Hacker News Reader

Comment by okamiueru | Hacker News Reader

Parent Full thread

It's great that it made Spotify activate a useful API they had little good reason to terminate. However, that "victory" always left me thinking a lot of people missed the point, including the person who challenged Spotify, as well as Spotify employee who responded to those emails, who confirmed they had little good reason to disable/remove the API.

To summarize, Spotify can of course terminate any API they so wish, and there is absolutely nothing in GDPR that compels them to keep it up. As long as they of course still follow the requirements by GDPR. As annoying as a workaround would be for Confiks, emailing the data within those 30 days to SongShift is acceptable and in compliance. There is nothing in GDPR that says "data transfer options once enabled cannot be removed and/or changed".

Quoting the clause "the data subject shall have the right to have the personal data transmitted directly from one controller to another, where technically feasible.", always seemed off with what is being demanded, because, they would be complying with that requirement by compiling and archive of the data, a big dump, and send it to SongShift. "I demand that you re-enable the API", on the other hand has no basis whatsoever in GDPR. The quote follows with "... or allow for some other method to allow me to exercise my rights under the GDPR", which is exactly right.

Spotify re-enabled the API because they chose to, not because they had to.

To clarify: I think it was great that Confiks convinced Spotify to re-enable the API. But, the arguments presented were not particularly convincing, and I took this as a case of Spotify doing the right thing, rather than a "David vs Goliath".

> Spotify re-enabled the API because they chose to, not because they had to.

Spotify re-enabled the API because:

• they already had the API, so they couldn't claim it was an undue development burden to re-enable it;

• it was cheaper than setting up another system based on manually emailing large chunks of the database; and

• it was good press.

Indeed. But those are probably the reasons for why they chose to. My point is that Spotify chose to. A lot of people made that correspondence out to be that they had to, per GDPR. And, as this thread discusses, and your list correctly omits: GDPR was not one of them.

Bullet points 1 and 2 in that reply only exist because of the GDPR...

Regarding bullet point 1, this is where Spotify went wrong (if their intention was to not provide this API), because in the correspondence, they did make it apparent that enabling the API was trivial. However, they could have said that due to business reasons, they decided to no longer maintain that API, and there is nothing compelling them to do so.

Regarding the second bullet point, you would have to explain to me what that has to do with GDPR.

To get back to the original point, activating this API is suggested as the clear winning example of GDPR. And, the counter argument I provided is that Spotify could have chosen to not activated the API, and still be in full compliance of GDPR. However, they evaluated the situation, and decided to activate the API.

I'm not making a point beyond this, so the responses so far have been a bit confusing. Yes, GDPR was part of the factors that pushed in the direction of enabling the API, and this is a good thing. However, the argument is only that GPDR did not compel them to do so.

> Regarding the second bullet point, you would have to explain to me what that has to do with GDPR.

Without the gdpr the cheapest alternative is to dev null the email, with the gdpr the cheapest alternative is to re-enable the api.

> I'm not making a point beyond this, so the responses so far have been a bit confusing.

Welcome to the internet :P

I do think your point is a bit weak here to be honest, and that people are reacting to this. It relies on interpreting the original demand as strictly "re-enable the api" and not "comply with the GDPR, and btw we both know the easiest way for you to do that is to re-enable the api".

In the example being used it was really the latter, consider that all the followup emails included the phrase "or allow for some other method to allow me to exercise my rights under the GDPR". It's also not like the overall goal of exporting data to another provider would have not been achieved if they implemented some new method instead, you can be sure that songshift would still do the work to make it easy to switch from spotify to them.

It’s could easily be argued that it’s an burden to maintain them.

Not that this impacts your broader point, but

> the data within those 30 days

This is a common misconception. The requirement is

> GDPR information must be provided without undue delay but at latest within one month. Only in reasoned cases may this one-month deadline be exceptionally exceeded.

The operative requirement is without undue delay, one month is a maximum on the definition of undue delay, not a minimum. Intentionally delaying compliance for the better part of a month after you have demonstrated the ability to send the data within seconds would undoubtedly constitute undue delay... (Some exceptions apply)

I agree. Though, in the context where I do mention this, I was pointing out the worst case that is easy to demonstrate a breach of. Spotify employee in correspondence made the mistake (and I mean this in the more business sense, as I personally find it refreshing that a correspondence is honest, rather than filled with protective legalese) of suggesting that the API would be trivial to reactivate, and thus making a case for it to be a case of causing an undue delay if not doing so. Without that, proving "undue delay" is not an easy thing to do.

Breach of this is not easy to prove, and I think that if this was to reach the court, it would be easily be dismissed if the user had their data transferred (in any form that can be processed, and not necessarily whatever was part of the original API spec) within 30 days.

Proving that undue delay was caused, is a much higher bar to meet. Again, less high due to the correspondence in question.

Reply on news.ycombinator.com