CODEWITHSUNDEEP
amazon-web-servicesamazon-s3download
user1503606
user1503606

Reputation: 4290

Stop services from downloading secure urls

I use amazon s3 to streaming media with amazon s3 they provide a secure url with a time limit and the this expires like below.

http://wp.video.s3.amazonaws.com/daisy_2x.jpg?AWSAccessKeyId=AKIAIDVCDVR32H7DCSNA&Expires=1382004775&Signature=gtYCQy2SAC44sEV6zDDTD0MZS%2Bs%3D

I found that, using Torch browser, it is possible to download the audio/video.

Is there anyway to stop this?

Thanks

Upvotes: 0

Views: 997

Answers (1)

Michael - sqlbot
Michael - sqlbot

Reputation: 178956

I was initially confused by your question, because, I thought "well, of course people can download files if you give them a signed URL to an object in an S3 bucket."

When you said "download," I thought you meant "fetch an object using HTTP," but you were using it to mean "download and save to a file" -- which is the part you wanted to prevent.

You mentioned Torch, which seems to make it extra easy for people to capture links to media content, but any browser in possession of a signed URL for one of your objects could download it.

The short answer, then, is "probably not," although it depends on the setup you are using now. Fundamentally, as my original reaction to your question illustrates, a signed URL to your files means your files are downloadable and can be saved to a file.

If you are using some kind of custom player that sends or can send a specific user-agent string, and that player speaks https, you could configure your player to set that value on the request, and then add a bucket policy with a condition that prohibits requests unless the user-agent string (that identifies the browser to the web server) matches a specific value. The reason for the need to use https is that it is trivially simple for a browser to change its user-agent string to match whatever it is you're expecting, and the only way to prevent that string from being discovered is if the request for the resource is never sent over the wire unencrypted, which would require https.

That's really a pretty weak mechanism, because if the magic value is discovered, you're back where you started, though it would limit the accessibility of your resources somewhat.

If you're not using a custom player, then I'm not sure why you wouldn't expect the files to be downloadable.

The only other mechanism that comes to mind would be to apply DRM to your files before uploading them to S3, which would require a player that understands the DRM format you're using. This is how the music subscription site rhapsody.com works. You're in possession of the downloaded files, but they're encrypted and your player won't play them if it can't verify that you're still a Rhapsody subscriber. I have no idea what the cost, complexity, or compatibility of such a solution would be.

Perhaps the bigger problem that makes this problem seem insignificant by comparison, is that if somebody wants a copy of your content, it doesn't take much ingenuity at all to pull your content through a hole that is impossible to plug.

Upvotes: 2

Related Questions