Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Audio tag security in html5

Long version:

I use html5 audio tag to play mp3 files on my website. With Flash I can stream mp3's and secure it for 95%.

With html5 it is easy to find out the mp3 location and just download it from there. Even if I secure it with unique hashes it is not hard to inspect the network tab in chrome and see the mp3 url with hashes.

I was wondering if there are other ways to secure the mp3 from being ripped and if it is worth the time. For example bandcamp does generate unique hashes but it is still very easy to download the mp3. For youtube you got download websites that can proces the flv stream and rip the audio and save it for the user as mp3 format.

The first layer of security I can think of is change the extension of mp3 files to .txt or another common format.

95% of the users don't spot the extension because it is hidden by default on windows and apple. This will prevent the first 95% of the users to spot and play the mp3 file.

Short Version

Any suggestions to prevent users from stealing mp3 files while using html5 audio tag.

like image 657
automaticoo Avatar asked Mar 11 '13 23:03

automaticoo


People also ask

Is audio tag supported in HTML5?

HTML5 supports <audio> tag which is used to embed sound content in an HTML or XHTML document as follows. The current HTML5 draft specification does not specify which audio formats browsers should support in the audio tag. But most commonly used audio formats are ogg, mp3 and wav.

What is audio src in HTML?

The src attribute specifies the location (URL) of the audio file. The example above uses an Ogg file, and will work in Firefox, Opera, Chrome, and Edge. However, to play the audio file in IE or Safari, we must use an MP3 file. To make it work in all browsers - use <source> elements inside the <audio> element.


2 Answers

Short Answer

No.

Renaming the audio file to .txt is not going to do anything to help the security of your mp3 audio file. If anything, it is going to cause you even more issues, because now, your mp3 audio file is going to be sent with the incorrect MIME type, which may cause issues with the browser's built in audio player.

The best suggestions that I can provide you is:

  1. Make sure that your checking the REFERER http header, make sure that it is coming from the page that has the mp3 player on it.
  2. Protect the mp3 file with a unique hash.
  3. Don't allow the same hash to be downloaded twice*

*Note that even doing this could cause issues, for example, what happens if the user reopens a tab from cache, plays the file again, and the mp3 file is not cached?

And finally, at the end even after your mp3 file is the most protected mp3 file in the history of IIS and Apache -- what is stopping me from just opening up Adobe Audition, and recordinging the audio stream?

Although you are correct about Bandcamp's MP3 audio stream, the mp3 is not as high quality then just a normal download after purchasing an album.

The fact that even Google does not really have any decent protections on it's video streams should say something. A company that generates billions of dollars from video views on YouTube can't even make (or better put -- has not bothered to put in place) any viable methods for protecting their videos.

like image 125
Tim Groeneveld Avatar answered Oct 31 '22 03:10

Tim Groeneveld


Kind of.

Grooveshark send a POST request to a server-side script for the MP3 that is being streamed which makes it very difficult to just access and spoof without dynamically creating a POST request yourself - especially seeing as you would have to then attempt to store the audio file that is collected. But you can use the new AudioContext to help solve this for most modern platforms...

I used a great example from HTML5Rocks.com to alter the headers used as follows:

var dogBarkingBuffer = null;
// Fix up prefixing
window.AudioContext = window.AudioContext || window.webkitAudioContext;
var context = new AudioContext();

function loadDogSound(url) {
  var request = new XMLHttpRequest();
  request.open('POST', url, true);
  request.setRequestHeader("Content-type","application/x-www-form-urlencoded");
  request.responseType = 'arraybuffer';

  // Decode asynchronously
  request.onload = function() {
    context.decodeAudioData(request.response, function(buffer) {
      dogBarkingBuffer = buffer;
    }, onError);
  }
  //this is the encryption key
  request.send("key=98753897358975387943");
}

Related

As you can see I am also sending a key value which could possibly be part of a public/private pair too. This should put anyone off attempting to intervene - other than simply recording the MP3 as it's playing, of course, but what could possibly stop that in any environment inside or out of a computer?

like image 30
marksyzm Avatar answered Oct 31 '22 02:10

marksyzm