Related opinion piece:
> Data portability: An antitrust weapon for the digital economy? (Le Monde, 2018)
> In concrete terms, what would portability in the digital economy look like? Let us imagine we could easily transfer our playlists between online music platforms (Spotify, Deezer, Apple Music, etc.), our files between cloud service providers (Google Drive, DropBox, OneDrive, etc.), our purchase records between online retailers (Amazon, CDiscount, Zalando, etc.) or our social graph between social media platforms (Facebook, Twitter, Snapchat, etc). By limiting platform lock-in, such measures would significantly intensify competition within these market segments.
I consider their developer platform to be an app store of sorts, and they do not play fair when it comes to holding onto their market power in certain areas.
Anyone have a contact in the App Fairness Coalition to raise these points with?
No doubt that the same company that sends a cease and desist to a developer who provides an export feature would act the same way as Apple if they were in its shoes.
> ...the right to request a copy of your personal data in electronic format and the right to transmit that personal data for use in another party’s service...
Why can’t a transfer service just use that file?
Perhaps, it doesn’t include playlists or liked artists/albums/songs?
Tried the GDPR data export from Spotify. By default, you get like 6 JSON files with almost nothing. After many emails and complaining and a month of waiting, I got a 250MB archive with basically EVERY INTERACTION I ever did with any Spotify client, all my searches. Everything.
What the heck...
My current day-job is a multi-tenant SaaS system - every single entity in any of our heterogenous databases is tagged with a tenant identifier (it's also used in composite PKs/FKs in RDBMS databases to prevent incorrect inter-tenant references). Every database system we use (MSSQL, MySQL, Cassandra, etc) has some way to query itself (INFORMATION_SCHEMA, system_schema, etc) which allows for query-generation to generate queries that will reliably dump all data we have associated with any tenant (and by extension, any user) within seconds, even if there's been some ad-hoc or unplanned database design changes (this is the only time I use "SELECT *" in production code!) - this is from a weekend project where I wrote a simple web-application that generates and runs those queries and dumps data to CSV files for tables and JSON for document-stores, shoves them into a zip and uploads them to Azure Blob storage. I didn't build it for GDPR compliance but actually to allow me to undo any unintentional data-deletion without needing to do a full database restore.
My operation's scale is nothing compared to Spotify - but if a tool I built in a couple of days can reliably dump all data about a subject across multiple independent cloud databases within seconds - what's Spotify's excuse?
I'm not a lawyer specializing in EU law, but I think this wording was put there for the precise reason of being able to punish companies that behave like that.
They'll get to them eventually.
The reality is that "30 days" translates to "someone will run a script manually once a month" whereas something like "100 milliseconds" would force you to have automation. It's a reasonable tradeoff for rare events. There is a lot less engineering effort required, and that makes it cheaper.
There is. Any tiny issue puts you past 30 days and invites a slap from the regulator. There's a lot of space between 100ms and 30 days. If you can't run your monthly process twice a day instead for example, you're most likely delaying on purpose - that's the "undue delay" part.
There's a company I know which decided not to pay any invoices until the last possible moment - which one day resulted in the electricity being cut to an office building with hundreds of people. Do you think that was a good decision in the end?
Additionally, having a delay can be useful to make it harder for someone to take over your account, and grab all your data; especially if there's sensitive data that might not be otherwise accessible or enumeratable through the UI or API.
Why commit to a tighter SLA than you legally have to?
Any large company has a tens, hundreds, or even thousands of different teams who may own a system with some data that identifies you as a customer. Presumably, they're on the hook for serving you (the customer) all of this data when you ask for it. Honestly, I'd hate to be a legal counsel at a company having to sift through every attribute/data column trying to figure out what we "have" to return vs. what we can probably keep hidden as a trade secret, but I digress.
Anyway, there's no guarantee that even half of the systems storing this data were designed with GDPR (or whatever privacy-related) compliance in mind.
Consider a system that's storing nested JSON blobs with customer-identifying data several layers deep. You happen to be on a team that owns this mission critical system. Your legal department gets you to prioritize some dev work to build a system to quickly extract this data.
You'll (probably) do it in the most cost effective manner – it might mean rearchitecting your system if the cost of extracting that data is very high. It could be that you have the tools to extract this data very quickly and so you just need to plug and play. Or there's at least one more scenario where such an operation is so expensive (and impacting on your main business function) that you accumulate a bunch of requests (i.e. 30 day window) and run some ETL to get all the customer data and respond on the compliance requests. So with that approach it's definitely not a real-time or near real-time response.
And my example scenarios here are actually pretty simplistic for a large company. Imagine the scenarios where you have N customer records with some loose notion of an evolving schema over the years. You're not even sure how to query that data or transform it... or your automation works 98% of the time to pull the customer data but 2% of the time it fails, and so you have to time (legally) to manually have an engineer fix that edge case (depending on how expensive that work is) or the engineer manually goes and pulls your data, accounting for whatever edge case that was discovered.
The more data you store about a customer, the "harder" this would get.
I would probably use data retention policies to drop as much data as I can, although I'm sure at a large company, your business customers push back: "Oh we've never had to use that data set, but we want you to keep it because we might use it to build features for some new ML model in the future or to solve other problem <Y>".
I've been a Spotify user for over half a decade, but the oldest date I could find in the dump was a little over two years ago.
I then contacted their support asking for all data, but I've made a mistake of contacting them with a wrong email address (which lead to them being unable to find my account) and I haven't bothered since.
In the best case scenario, I'd say it takes a week to get the entire dump, which is not very convenient for switching to a competitor.
For example, the Spotify API track-level responses always contain the ISRC , but the JSON files contained in the GDPR request don't.
Spotify clearly does only the bare minimum required by the law and even actively frustrates GDPR requests by taking the maximum allowed time to respond to them.
I don't agree that Spotify has to let users transfer Spotify curated playlists as that is a business strength. Songshift seems to show Spotify curated playlists on their homepage like Discover Weekly so I can see why Spotify won't like this.
But if my understanding of GDPR is right they have to allow users to transfer playlists created by themselves.
Regarding GDPR and data portability:
In practise you can expect to receive a (link to a) zip file via email with a bunch of XML documents after going through a convoluted dance. Also, it often takes some time (days) to receive the data. Basically, nothing that can easily be automated by a third part service - you need user auth of the requesting user to access the data.)
"You must comply with a request for data portability without undue delay and at the latest within one month of receipt of the request"
I guess it's because data portability isn't trivial, and it was wasn't the key aspect of GDPR.
As a contrast: The EU mobile number portability legislation says: max 1 working day.
Without a legislative mandate and a third party integration partner that assures the port is successful, seems unlikely that a market leader like Spotify would ever allow them to exist.
Even when we implemented it for my last company, we did JSON exports on signed S3 paths. I thought structured data was the easiest way for any competitor or user to use their data.
I think it could have worked pretty well to keep it as vague as that. (The auth aspects would need more detail, obviously.)
I don't think data format fragmentation is a big issue (just implement adapters for the top five competitors in your market...), but rather the impossibility of doing it in a quick and seamless manner on behalf of someone wanting to migrate their data to your service from some other service.
Yeah, this would have been nice. I am not sure if legally you could enforce that as automation itself is vague and depends on the source and target both.
> I don't think data format fragmentation is a big issue (just implement adapters for the top five competitors in your market...), but rather the impossibility of doing it in a quick and seamless manner on behalf of someone wanting to migrate their data to your service from some other service.
I think if companies were being honest in their efforts for data portability, as a first step they would not try to reap the benefit of the 30 day window by as much as they can.
For most, it should take mins or hours to get the export yet the best turnaround I have seen from any service has been from Tinder, it was I think 3 days.
Is there anything to prevent the export file format from shifting regularly? You know, for ongoing product improvement reasons, naturally.
Anyway, let me know when the GDPR actually helps with something instead of just making the internet more of a usability train wreck.
The key part is the "the don't keep data around forever just because you can" part.
Sure, the GDPR got a bit bloated, but I honestly believe most europeans lives got a little bit better because of it.
Edit: I think you're thinking about that horrible cookie warning law. That one needs to burned to the ground.
It’s not about “allows user to quickly find the same songs elsewhere”, because if you’re not ready for that then you shouldn’t probably be in this business in the first place.
Apple's "New Music Mix" is absolute shit compared to Spotify's "Discover Weekly". Most of the stuff Spotify suggests to me are either complete bangers or listen-worthy at worst.
Apple's stuff though... It's like they don't have ANY intelligence in the system at all. I listen to 80's gangsta-rap once, then I get modern mumblerap shit for months and months.
BUT I do love how Apple Music integrates with my iOS devices and I think the sound quality is better. So I just use Songshift to sync the discovery playlists to AM (semi)automatically.
That's exactly the sort of unexpected "music discovery" I'd be looking for. ;-)
I've tried to understand how the algo somewhat works to suggest stuff but with no luck... I keep hitting the don't like this song or artist and yest somehow I still manage to get dreadful recommendations each week :(
- a builtin weekly personal archive of DW/RR
- a "get me more more interesting music in this style based on other peoples recommendations" button
It's an easy and interesting way to go back in time and see what I was listening to etc..
I have a "house rule" where I never remove any songs from them after the fact. If I added it, then it stays.
At the end of the year, I try to pick 2 songs from each month to make a curated "Best of <Year>" and then compare that to the algorithmic one that Spotify sends me.
Anyways, it's been a really fun thing and a reasonable substitute for DW/RR archives.
I still got my Starred playlist from back when you couldn't like. Been using dual like and Starred ever since they added like list. Since Starred playlist still contains dates, I could retroactively do what you did. However there would be some months with a lot and some with (almost) none and I have a tendency to hyperfocus on certain genres/artists for a while which might split but not on exact start of month.
I think this functionality belongs in the core experience.
Can I ask you how many songs are in your Liked playlist? It's a lucky week if I find 3 songs that I like in my Discover Weekly. The rest are forgettable at best, often terrible. I think I am not using Spotify the way I'm supposed to, because i find it really hard to discover new music I like.
It really improved after that and it's typically pretty great (with some weeks being exceptions). For reference, I've got 1,272 tracks in "Liked".
Now that they’ve threatened songshift they’re forcing you to make a choice (or manually sync).
Hopefully you won’t choose Spotify.
Spotify’s attack on podcasts with exclusivity and trying to destroy the open standard really bothers me: https://stratechery.com/2020/dithering-and-the-open-web/
Now with this I just don’t have much respect for them.
When paired with their complaining about Apple’s policies being unfair it makes me really dislike them, they don’t care about their users or what’s best for them. It wouldn’t surprise me if soon I have to call and beg them to cancel my subscription like Sirius XM.
FreeYourMusic also still works, so if you want to do this download it quickly before Spotify forces them to break the feature.
We are still operational and have Spotify export working. If they won't let you through doors, we get in via window. ️
We do not expect any platforms to be limited on FYM.FM in near future.
I really miss when they were laser focused on music. If they drop their bad business practices, I will switch back. For now I’m really feeling the need for competition.
Heads up, Apple Music doesn’t sound as good as Spotify, unfortunately. Tidal is better overall in my experience and as far as I can tell they’re not being anticompetitive in any way.
Otherwise it is completely inferior to Spotify in each and every way, starting with the core functionality that is a train wreck, at least on macOS. I regularly have issues with the scrobbler getting out of sync, recently playback stops after ~5 seconds when waking my mac from sleep and I have to restart it. The experience is just a mess.
On top of that it is 2x the price of Spotify. I am seriously thinking switching back to Spotify just because the SQ difference is not worth the disaster that comes with it.
I’m fully making the switch as protest of business practices, not because Tidal is already better. I hope Tidal gets there but if they don’t I’ll have to reevaluate eventually. I hope Spotify just apologizes for being shitty so I can go back to them.
That's funny, just a few comments up there's someone saying that Apple Music sounds better than Spotify
I ended up sticking with Apple Music after my Spotify Premium trial ran out, but I suspect that's largely because it's what I'm used to. I've seen lots of "Apple Music's recommendation engine is crap," but that's not actually been my experience -- their "New Music Mix" isn't great, but the whole of their "For You" page almost always has stuff I'm interested in and I really like digging through their curated playlists. It's been a much more rewarding service for just digging around exploring in than either Spotify or Tidal have been for me. (Although Tidal undoubtedly has the best sound quality if you're willing to pony up for the lossless/MQA tier.)
The days of 128 Kbps MP3s encoded with L3enc or Xing with horrific pre-ringing and squelched cymbals is long gone.
I’m not exactly an audiophile but Apple Music sounds noticeably bad with my headphones to the point I thought they were broken. Then I thought it was my PC but it sounded just as bad on a MacBook Pro.
Why would that be?
I listen with WH-1000XM3 and ATH-M50x and the Apple Music encoding sounded really, really bad to my ear. It’s not the bitrate, which should be fine, it’s the sound of the audio which is totally different from other services.
I suspect they have optimized for low quality devices like AirPods and earbuds; I expect the oversharpening might be rated as better on those devices.
FWIW Tidal and Spotify sound the same at their standard premium tier. I can’t hear the difference between Spotify and Tidal HiFi on my Bluetooth (AptX) Sony headphones, but I can hear the difference with my wired ATH-M50x.
I recommend listening to the services side by side, preferably with desktop client to compare. In Spotify you may want to adjust the streaming quality to high from auto, as I always do, to be sure it’s a fair comparison. Sadly Apple doesn’t seem to give a choice in quality, but based on reading my understanding is they always default to high - I could be wrong.
It doesn't help Spotify's image though.
And you literally cannot do what you described with Spotify if you are a podcaster. Spotify can decide to do it, but you can’t.
Apple has also been a good steward of podcasts and keeping the open standard.
Spotify Developer Platform Team, if you're listening: you're imbeciles for doing this and you're putting customers back in a buying position when they were happy to keep giving you money forever.
starts looking at alternatives
For example: their web playback SDK has a provision about "contact us to use for noncommercial purposes," and there's a long-standing GitHub issue specifically about how no one has ever gotten a reply back when they email about this.
Meanwhile, when I had a problem with MusicKit JS - the Apple Music equivalent - I actually got a reply back within a few weeks from an Apple engineer about it that helped me resolve it. Obviously not the shortest timescale, but at least there's clearly some effort being put into it. It helps that they actually are using MusicKit JS to power their own Apple Music web player, while Spotify's playback SDK is a separate codebase, which is why it's missing features like Safari playback that are present in the web player.
Spotify's new mobile SDKs are also unusably awful, and can't do basic functions like "playing a single song and stopping instead of autoplaying onwards." They also have deprecated and killed off several past mobile SDKs that were far more feature-filled. I saw a new Spotify-powered radio app that launched recently (Station Rotation) appears to be using the legacy undocumented SDK for playback because of this - can't imagine that app will have much of a future if Spotify ever decides to finally break that SDK.
Honestly, I expect Spotify to completely kill their public APIs and SDKs within the next two years. They clearly see no value in them, or they would have invested in maintaining them.
It's baffling. They could've had a distinct advantage being one of the only developer-friendly (and thus highly flexible/adaptable) streaming services on the market, but they instead decided to toss that in the garbage bin and push usage of the official client, which sees constant frustrating UI changes for no good reason.
As they mature and double-down on value extraction from their existing customers, they are cutting off more and more interesting third-party services that helped them grow but are now seen as competitors or detriments to their revenue.
We don't want the users to be able to easily shift from our platform to anyone else's, though. That's bad!
(Obviously the corporate interests only align with the consumer interest when it serves the bottom line of the corporation.)
At least Google Takeout allows me to export my GPM data very easily.
I'm a happy Spotify user but this is plain hypocrite. You cannot claim to be against the power of larger corps while you as a big corp are doing the same to smaller companies.
Boy, as one of the very few people who switched over from Spotify to Apple Music, I’m hoping that the Spotify vs. Apple lawsuit turns on Spotify’s head over this
They curate some really good playlists, so they can restrict them but they should allow user created playlists to be exported.
To count as copyright there have to be a substantial manual effort into production of the data. Also byproduct of your ordinary business is not copyright (called “sui generis”).
On page 15 there is also about the “horse race” case taken to the court, that state the same.
Have the user open the playlist and copy & paste, or use an extension, user script or bookmarklet, to extract the information.
And of course post a warning against maintaining your playlist in Spotify, prominently recommending competing services instead.
Is there something that will let me convert a Spotify playlist into a list of e.g. YouTube videos without having a Spotify account?
I would suggest anyone using Spotify to switch. On the plus side, Tidal also pays musicians a four times what Spotify does (last time I checked, I can't find the link), which I think is in itself a good reason to prefer it.
However, as a supporter of open, non-proprietary standards, promoting MQA would really put me off. I don’t have time for “audiophile” nonsense and hadn’t heard of MQA until now but it seems like another attempt at building a walled-garden for rent-seeking opportunities . MQA is not something I want to support and while I don’t know if it’s a complete deal-breaker with respect to Tidal, I won’t be switching today.
Thanks for the info.
I used a website to transfer my Spotify playlist to Tidal before this recent change.
I hope Tidal is prepared to take advantage of Spotify’s customer loyalty bonfire. Not having a strong developer offering isn’t a great look.
There are some reverse engineered API packages out there for Tidal. They might work but that's not what I'm looking for as a paying customer.
Even better, make a tool that accepts your login and password and does that for you.
It's quite funny that tools like Deemix let you download songs from Spotify, but there's no way to actually export them.
 I won't provide a link because of piracy.
 Deemix internally converts to Deezer, and then downloads from that.
Login/password and scraping is a more interesting alternative, but then Spotify would presumedly block any server-side scraping. Really, best option I can come up with is browser automation that is entirely client-side (whether a browser extension or maybe wrapping Puppeteer).
Do people go for a monthly pricing for this kind of service?
I mean transferring playlists from an old service to a new service sounds like a one-off thing. Does someone really need it continuously?
Overall I think that music streaming services were probably the best services for switching platforms, and this is a blow that is surely gonna damage that reputation for me. Compare that to other markets that offer something similar (like ebooks or video streaming) where there's absolutely no chance for you to retain even 10% of your library if you decide to switch, so services like Songshift make no sense in those fields.
Having just three major music publishing conglomerates is both a blessing and a curse.
How about libraries?
Really unfortunate that Spotify dictates what you do with your own playlist when you're not even ripping the songs off of their service.
And there was more projects like mine on Github at the time. Spotify2AM was good ...
Strangely, Spotify have also made their API a lot more powerful, even with embedable players on webpages. Kind of seems like a step in the opposite direction, although they might have tightened up that as well since last time I checked.
I've been really happy with it. They haven't implemented any restrictions around exporting from Spotify yet. Might be helpful if you'd like to jump ship
In principle, a tool for transferring of user's data could be operating on a GDPR/CCPA data export that has to be available for all Spotify users in California and EU. Those are just not exposes as easy-to-use APIs (yet).
Imagine things like Facebook messenger chats being indexed by a person name rather than an account ID or phone number so there is a high chance "Chat with Dave" is ambiguous... Not the kind of thing you could start a lawsuit over, but it is enough of a barrier that re-importing exported data is near impossible.
Now with Tesla adding spotify, I've got a 3rd user that is only used on the car, only problem is manually syncing playlists from one user to another, but you can 'follow' another user now at least.
But, this podcasts business is madness. Their podcast integration has always been awful (you can't auto-download new episodes for example), and now they're shoveling millions into content I have less than 0 interest in.
I imported my playlist to spotify, it's mine, why shouldn't I be able to export it?
I hope to see a response from spotify, because I would prefer not to leave.
Looks like this is what forces my move now :(
> h. Do not transfer Spotify Content to unauthorized third parties, including (i) directly or indirectly transferring any data (including aggregate, anonymous or derivative data) received from Spotify to, or use such data in connection with, any ad network, ad exchange, data broker, or other advertising or monetization-related toolset, even if a user consents to such transfer or use; or (ii) to another music service that competes with Spotify or the Spotify Service.
Interestingly enough it says these were last updated over 2 years ago, so they must have been not clamping down on this paragraph until now, or they added it recently and didn't bother to update the document version to hide it. Either way, this is very disappointing.
> Spotify Content” means any content, data, information or material made available through the Spotify Platform, Spotify Service or by Spotify. This may include, among other things, sound recordings, short-form videos, cover art, musical works, artist biographies, song lyrics, metadata, playlists, and user data
So it seems that the list of songs that the user "likes" is considered Spotify Content. Does any body know how far this goes? What if one tool accesses the API to extract the list of user's songs into a CSV file, and then a separate tool is used to automatically "like" a list of songs from a CSV file in a competing platform?
Does Spotify really own the (Artist, Song) tuples that make up a list of songs?
The Discord integration, cross device interoperability, UX are simply unmatched on all other music platforms.