4 ms·

I don't understand GDPR too well -- does this mean every company must build APIs that would be sufficient to allow competitors to import user data from them?

mjburgess 6y ago
It does seem onerous. I wonder if, "so, we will email SongShift directly" etc., would do. I guess the law doesn't say "for free" ? So perhaps they could charge a fee for each API use... It otherwise seems unreasonable to require data-holders (/"controllers") to pay the costs of this "direct transfer", esp. re building and maintaining an API. They have in their possession an object which the user owns -- their data -- would we, in analogous cases, require stores to do anything other than "hand it back" ? This seems quite an odd law. EDIT: given downvotes, let me clarify: I like the law. It is useful. I just want to understand the moral/legal/economic logic. This law imposes costs somewhere, and prevents some services being offered.
- Nullabillity 6y ago
  > It otherwise seems unreasonable to require data-holders (/"controllers") to pay the costs of this "direct transfer", esp. re building and maintaining an API. Consider it a cost of collecting the data in the first place.
  - mjburgess 6y ago
    You're assuming that they are deriving additional value from it. That isn't universal, but the law is. Eg., consider me uploading some image files for processing and then downloading them. The website keeps those images only insofar as I wish, and never analyses them or derives value from them beyond what I permit -- and suppose the default is to permit nothing. Then it seems odd. Since this is more like taking my shoes to be repaired. It would be onerous to require repair shops to send them elsehwere.
    - asdfasgasdgasdg 6y ago
      I think the theory is if the data controller does not derive value from storing the data they should not do so. In spotify's case they plainly do. Without user created playlists they would be up a creek.
    - corobo 6y ago
      If they get no value from it they're free to delete it
- aenario 6y ago
  An alternative is to think of data as dangerous chemicals. You can acquire it and store it, but you have to follow some procedures : - do not expose your employees to it - do not leak it in the environment It then falls to the company to make the cost/benefit analysis : is this chemical important enough to our process to justify these hasles. The data export also does not need to be a perfect API, dump a huge json and let third party handle changes.
TonyTrapp 6y ago
I guess the relevant section also quoted in the original post by Confiks ("the data subject shall have the right to have the personal data transmitted directly from one controller to another, where technically feasible") may be up for interpretation, and as a result not everyone might have provide such an API. But this specific case, we can be sure that it most definitely was technically feasible, as the feature used to work before their ToS change and it merely stopped working because they wanted to block SongShift.
- tpxl 6y ago
  You don't have to provide an API to transfer between accounts on the same platform, but you do need to provide a way to get all your data off the service, which another service can use to import.
  - disiplus 6y ago
    read the emails this person sent to spotify.
    - tpxl 6y ago
      The API was already implemented and shut off. He did not as them to implement the API, he asked them to turn it back on and there is a large difference.
      - okamiueru 6y ago
        Am I alone in thinking he isn't entirely correct? To my understanding with GDPR (I'm no expert, just on the developer end trying to adhere to it), he has all the right to get a copy of the data, as well as have that data be transferred to another controller. He does, however have no say in the exact data transfer protocol used for the transfer. If Spotify wants to disable an api and shut down production resources, I don't see how a GDPR request can compel them otherwise. As long as they prepare all the data, and allow for the transfer, then they are complying with GDPR. Even if the API at some point existed, it doesn't mean they are required to maintain it. The other side of this is that Spotify's answers were perhaps too earnest in detailing why. When arguing it is against their ToS, it doesn't really fly with GDPR anymore, because that implies they have everything in place, but they don't want to. They could have just said "we'll compile all the data and facilitate a transfer on your behalf", and the user really wouldn't have the slightest case. So to sum up, my take is that both are wrong. Spotify in arguing its against their ToS (it doesn't fly). And the emailer arguing that they are entitled to Spotify enabling their api (they aren't).
parliament32 6y ago
No: the root of the matter is that it has to be "technically feasible", which with proprietary software you can't ever prove. This was a special case because they already showed it was possible (it was working), then they took it away.
- emn13 6y ago
  Even here, if they reaaaaalllly cared (and had good reasons to, other than "we want to lock in customers"), they probably could take the feature away - they'd just need to play the CYA game much better, and be willing to risk a hefty fine based on whether a court believes your reasons for technical infeasibility. After all, not everything that was technically feasible stays so in a changing environment. Another think they can do is just try occasionally, and see if people give up.

mjburgess 6y ago

It does seem onerous. I wonder if, "so, we will email SongShift directly" etc., would do. I guess the law doesn't say "for free" ? So perhaps they could charge a fee for each API use... It otherwise seems unreasonable to require data-holders (/"controllers") to pay the costs of this "direct transfer", esp. re building and maintaining an API. They have in their possession an object which the user owns -- their data -- would we, in analogous cases, require stores to do anything other than "hand it back" ? This seems quite an odd law. EDIT: given downvotes, let me clarify: I like the law. It is useful. I just want to understand the moral/legal/economic logic. This law imposes costs somewhere, and prevents some services being offered.

Nullabillity 6y ago
> It otherwise seems unreasonable to require data-holders (/"controllers") to pay the costs of this "direct transfer", esp. re building and maintaining an API. Consider it a cost of collecting the data in the first place.
- mjburgess 6y ago
  You're assuming that they are deriving additional value from it. That isn't universal, but the law is. Eg., consider me uploading some image files for processing and then downloading them. The website keeps those images only insofar as I wish, and never analyses them or derives value from them beyond what I permit -- and suppose the default is to permit nothing. Then it seems odd. Since this is more like taking my shoes to be repaired. It would be onerous to require repair shops to send them elsehwere.
  - asdfasgasdgasdg 6y ago
    I think the theory is if the data controller does not derive value from storing the data they should not do so. In spotify's case they plainly do. Without user created playlists they would be up a creek.
  - corobo 6y ago
    If they get no value from it they're free to delete it
aenario 6y ago
An alternative is to think of data as dangerous chemicals. You can acquire it and store it, but you have to follow some procedures : - do not expose your employees to it - do not leak it in the environment It then falls to the company to make the cost/benefit analysis : is this chemical important enough to our process to justify these hasles. The data export also does not need to be a perfect API, dump a huge json and let third party handle changes.

TonyTrapp 6y ago

I guess the relevant section also quoted in the original post by Confiks ("the data subject shall have the right to have the personal data transmitted directly from one controller to another, where technically feasible") may be up for interpretation, and as a result not everyone might have provide such an API. But this specific case, we can be sure that it most definitely was technically feasible, as the feature used to work before their ToS change and it merely stopped working because they wanted to block SongShift.

tpxl 6y ago
You don't have to provide an API to transfer between accounts on the same platform, but you do need to provide a way to get all your data off the service, which another service can use to import.
- disiplus 6y ago
  read the emails this person sent to spotify.
  - tpxl 6y ago
    The API was already implemented and shut off. He did not as them to implement the API, he asked them to turn it back on and there is a large difference.
    - okamiueru 6y ago
      Am I alone in thinking he isn't entirely correct? To my understanding with GDPR (I'm no expert, just on the developer end trying to adhere to it), he has all the right to get a copy of the data, as well as have that data be transferred to another controller. He does, however have no say in the exact data transfer protocol used for the transfer. If Spotify wants to disable an api and shut down production resources, I don't see how a GDPR request can compel them otherwise. As long as they prepare all the data, and allow for the transfer, then they are complying with GDPR. Even if the API at some point existed, it doesn't mean they are required to maintain it. The other side of this is that Spotify's answers were perhaps too earnest in detailing why. When arguing it is against their ToS, it doesn't really fly with GDPR anymore, because that implies they have everything in place, but they don't want to. They could have just said "we'll compile all the data and facilitate a transfer on your behalf", and the user really wouldn't have the slightest case. So to sum up, my take is that both are wrong. Spotify in arguing its against their ToS (it doesn't fly). And the emailer arguing that they are entitled to Spotify enabling their api (they aren't).

parliament32 6y ago

No: the root of the matter is that it has to be "technically feasible", which with proprietary software you can't ever prove. This was a special case because they already showed it was possible (it was working), then they took it away.

emn13 6y ago
Even here, if they reaaaaalllly cared (and had good reasons to, other than "we want to lock in customers"), they probably could take the feature away - they'd just need to play the CYA game much better, and be willing to risk a hefty fine based on whether a court believes your reasons for technical infeasibility. After all, not everything that was technically feasible stays so in a changing environment. Another think they can do is just try occasionally, and see if people give up.