html5 中的音频标签安全性答案

【问题标题】：Audio tag security in html5html5 中的音频标签安全性
【发布时间】：2013-02-27 08:18:15
【问题描述】：

加长版：

我使用 html5 音频标签在我的网站上播放 mp3 文件。使用 Flash，我可以流式传输 mp3 并确保 95% 的安全性。

使用 html5 很容易找到 mp3 的位置并从那里下载。即使我使用唯一的哈希来保护它，在 chrome 中检查网络选项卡并查看带有哈希的 mp3 url 也不难。

我想知道是否有其他方法可以保护 mp3 不被翻录，以及是否值得花时间。例如bandcamp 确实会生成唯一的哈希值，但下载 mp3 仍然非常容易。对于 youtube，您可以下载可以处理 flv 流并翻录音频并将其保存为 mp3 格式的网站。

我能想到的第一层安全措施是将 mp3 文件的扩展名更改为 .txt 或其他常见格式。

95% 的用户没有发现该扩展程序，因为它在 Windows 和 Apple 上默认隐藏。这将阻止前 95% 的用户发现并播放 mp3 文件。

短版

任何防止用户在使用 html5 音频标签时窃取 mp3 文件的建议。

【问题讨论】：

是你的音乐吗？为什么不只是流式传输低质量的副本并使用唯一的哈希来半保护它。
或者时不时在mp3中间轻声细语你的域名。
两个不错的选择。不同的艺术家授予我在网站上播放音频的权利。
在这种情况下，我认为最好使用低质量的流和购买完整质量版本的链接。
事情有进展 - 在底部查看我的答案

标签： html security audio

【解决方案1】：

简答

没有。

将音频文件重命名为 .txt 不会对 mp3 音频文件的安全性有任何帮助。如果有的话，它会给您带来更多问题，因为现在，您的 mp3 音频文件将以不正确的 MIME 类型发送，这可能会导致浏览器的内置音频播放器出现问题。

我能给你的最好建议是：

确保检查 REFERER http 标头，确保它来自具有 mp3 播放器的页面。
使用唯一哈希保护 mp3 文件。
不允许两次下载相同的哈希*

*请注意，即使这样做也可能会导致问题，例如，如果用户从缓存中重新打开选项卡，再次播放文件，而 mp3 文件未缓存，会发生什么情况？

最后，即使您的 mp3 文件是 IIS 和 Apache 历史上受保护程度最高的 mp3 文件，是什么阻止我打开 Adobe Audition 并录制音频流？

虽然您对 Bandcamp 的 MP3 音频流的看法是正确的，但 mp3 的质量不如购买专辑后正常下载。

即使是 Google 也没有真正对其视频流提供任何体面的保护这一事实应该说明一些问题。一家从 YouTube 上的视频观看中获得数十亿美元收入的公司甚至无法制定（或者说更确切地说 - 没有费心实施）任何可行的方法来保护他们的视频。

【讨论】：

没错，重命名为 txt 是一种不好的做法，并且可能会遇到更多可以解决任何问题的问题。
不错的答案，但谢天谢地，事情进展了一点 - 请在下面查看我的答案

【解决方案2】：

有点。

Grooveshark 将 POST 请求发送到正在流式传输的 MP3 的服务器端脚本，这使得在不自己动态创建 POST 请求的情况下访问和欺骗非常困难 - 特别是看到您必须尝试存储收集的音频文件。但是您可以使用新的 AudioContext 来帮助大多数现代平台解决这个问题...

我使用了 HTML5Rocks.com 中的一个很好的示例来更改使用的标题，如下所示：

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");
}

如您所见，我还发送了一个密钥值，它也可能是公共/私有对的一部分。这应该可以阻止任何人尝试干预——当然，除了在播放 MP3 时简单地录制它，但是在计算机内部或外部的任何环境中，有什么可能阻止这种情况呢？

【讨论】：

不错的sn-p。这看起来很可靠，肯定会阻止 99% 的普通用户窃取 mp3
谢谢 - 我很快就会使用它，所以我很高兴我遇到了这个线程，因为它帮助我解决了这个问题。道具转到 Grooveshark 和 Alex Reidy 的指针。
抱歉，是什么阻止我在我的 chrome 控制台中看到资源并可以访问它？
@Snick 您可以每次发送一个唯一的流并定期将其附加到音频流中。此外，拥有公共加密密钥意味着您只能进行一次定期握手，而不能共享链接。更重要的是，你可以做一个每部分的加密密钥。你可以用它来做很多层次的想象，所以它更像是一种高级别的威慑。
啊，我明白了，这将在服务器端请求一个活动进程来处理每个部分的加密和流连接，对吧？我猜它不适用于cdn'ed内容。

【解决方案3】：

你可以让 MP3 本身没有吸引力。一些想法：

不要在文件中包含专辑封面、专辑信息等（id3 标签）。更好的是，用“此文件来自 myMusicSite.com”之类的内容填写所有 id3 标签字段。
将您的文件分成几个较小的部分，然后在浏览器中按顺序播放它们。必须下载所有单独的部分会使您的文件的吸引力大大降低。您可能会遇到无缝播放的问题，但不确定它的支持程度。
将它们编码并作为视频播放，可能使用您的徽标或其他内容作为视频流。生成的文件不会大很多，尤其是。如果您使用静态图像。这将意味着用户无法在 mp3 播放器、手机等上轻松播放您的文件。
如 cmets 所述，在录音中轻声说出您的域名或网站名称几次。

【讨论】：