Most of the MP3 player I’ve seen doesn’t protect the owner of the MP3 to be stolen. It’s sometimes a choice, but everyone (should) know that by using one of those simple MP3 players in Flash:
You are offering your MP3 files the same way that if you putted a link on it, called “download it”.
A little bit keen user will find the file and download it, it’s very very easy with the Net tab of Firebug (for Firefox) or the Activity Window of Safari.
Using Firebug on Samples.fr homepage
(a very cool blog about who sucks the song of who, only 30 sec. preview).
For a personnal website, a blog or whatever, it’s not a problem from my point of view, because it belongs to you and you are responsible of you do with it. The problem comes with public services.
MySpace has had troubles with their MP3 player back in september 2006 and are now using a more secure player and file delivery system (token based).
At the beginning Mx3 had the same issue, they fixed that a first time by using a token based authentication. But it wasn’t enough, because you could grab the source code of the SWF movie by decompiling it with Flare for example.
v1.GETTOKENURL = '/single/get_token?s='; v1.GETMP3URL = '/single/get_MP3?h='; v1.SHAREDKEY = \ '812664f85904d7458291529ae9c503b3'; [...] var v2 = com.meychi.ascrypt.MD5.calculate( \ PlayerCtrl.SHAREDKEY + \ '--' + \ this.__getTokenLoadVars.t); this.__playback.setMedia( \ PlayerCtrl.GETMP3URL + \ v2 + ’'&t=' + \ this.__getTokenLoadVars.t,\ 'MP3');
This issue was solved using a encrypting solution (and changing the shared key of course).
I’ve spent some times to investigate on famous, eye-candy, übercool web radio, music selling, or sound web site. Most of them have no protections at all! Nothing. I built scripts that download all the songs from a query on a band for two of them :
Theses scripts deal only with RSS and Flash Remoting and aren’t more than 100 lines (with comments and bla-bla). But it was easy, no cookies, no sessions, no internal counter, no HTTP header to simulate, ... I have the feeling that I didn’t hack anything, just used the offered RSS based REST or Flash Remoting API. I even didn’t decompile a single SWF file.
To protect your files, don’t rely on technologies like Flash, XML or Flash Remoting but put some kind of authenticaton in the discussion protocol your are using, that cannot be simulated easily outside the MP3 player your are providing. If the URL that gives the file to the player can be runned only one time and cannot be generated without decompiling the swf file, you’ve got it. Next step is to encrypt your swf file and it’s not mandatory for Flash 8 at least. I’ve tested with swf files generated by Flex and cannot find anything, it’s a matter of time I think.
I’m managing to build a MP3 player (based on Flex) and a server that could protect the MP3 it plays from being stolen. More to come.
One kind of protection is to deliver crap: poor quality, not the entire song (like Amazon does), no ID3 tags, random file name, etc.
But music tastes better if you buy it or respect its licence:
J’aime beaucoup le petit dicton « Loin des yeux, loin du coeur », en terme de développement web c’est tout aussi vrai que dans la vie de tous les jours. Tout ceci pour vous dire que la grande, l’écrasant majorité des lecteurs MP3 en Flash qu’on trouve sur la toile ne protège pas contre le téléchargement de la chanson elle-même. Sachez que parmi les suivants :
Tous permettent le téléchargement des fichiers directement. Un enfant pourrait le faire en allant dans l’onglet Net de Firebug pour Firefox ou via l’Activity window de Safari.
On peut dire qu’ils sont destinés à un usage personnel donc que la personne les publiant le fait sur son site perso et en est donc pleinement responsable. Oui, je suis d’accord avec ça. Cette réflexion vient poser problème pour des sites de service offrant la mise à disposition de musique ou la libre écoute.
MySpace par exemple a eu un petit problème en septembre 2006 quand une personne a publié un logiciel pour télécharger les chansons d’une page donnée et ils ont rapidement dû revoir leur copie.
Un autre service, Suisse celui-ci, Mx3, avait le même problème au départ qu’ils ont rapidement corrigé en utilisant un système basé sur un jeton unique qui permet d’obtenir le fichier. Mais ce jeton était facilement falsifiable, le code étant pour ainsi dire disponible. Des outils permettent de décompiler un fichier SWF pour en extraire le code, les images, ... d’autres permettent de le crypter pour se protèger de ce type de problème, chose qui a été faite.
J’ai passé du temps à jouer avec des services offrant de la musique, qu’ils soient jolis, web 2.0, populaires ou pas, très peu se protègent du téléchargement de leurs fichiers musicaux. Sans même avoir à décompiler leur lecteur SWF, j’ai pu construire des scripts permettant de télécharger toutes les chansons en fonction d’une recherche. Certains se basent sur Flash Remoting, d’autres des fichiers XML (comme RSS par exemple) qui fournissent l’adresse du fichier à télécharger directement. Rien d’autre à contourner comme un cookie, une entête HTTP, un jeton, ... rien!
Une technologie ne protège pas, XML et Flash Remoting ne protègent pas. Tant qu’il n’y a pas une forme d’authentification dans les messages échangés entre le client (le lecteur en Flash) et le serveur qui fournit les fichiers audios, il n’y a pas de protection.
J’essaie actuellement de mettre en place un lecteur MP3 (en Flex, je bosse sous GNU Linux donc pas trop le choix) et un serveur de fichiers devant offrir une forme de protection suffisante. À suivre.
Une forme de protection assez efficace est de fournir de la mauvaise qualité : des fichiers tronqués (comme Amazon), de mauvaise qualité, sans les tags ID3, avec un nom aléatoire, ...
Au passage, il y a plétore de sites internets qui mettent à disposition de la musique de qualité en libre téléchargement. Et en plus, ça fait plaisir d’avoir autre chose à se mettre sous l’oreille que les tubes passant à la radio, non ?
