[kcima]

The genius of this is the realization that browsers do not send the named anchor (technically "fragment identifier"[1]) to the server. Using the named anchor as the cryptographic key enables users to pass around simple URLs to encrypted data. Data is stored on the server, but the server never has access to the complete URL with the key, so it cannot decrypt it.

As others have pointed out, this doesn't protect the data from a compromised server, but I think it has a different motivation.

It appears the purpose of this is to reduce the liability of whoever is running the server. Perfect for magnet links and such.

This is another step in the right direction of protecting the web and its maintainers from legislation.

[1] http://www.w3.org/TR/html401/intro/intro.html#fragment-uri

[Natsu]

> It appears the purpose of this is to reduce the liability of whoever is running the server. Perfect for magnet links and such.

PasteBin itself is a DMCA notice magnet already for some very litigious people, as I know from having read through more public DMCA notices than most people would bother reading through. So if you're worried about legal liability, consult a lawyer to make sure that your technical solution would actually help you in court.

There's something called "willful blindness" that you might want to understand if you plan to run a PasteBin clone where people could be expected to post magnet links to pirate content. You could also do worse than to have a lawyer explain your DMCA obligations to you, too. If people start posting pirated stuff to your site, you're going to want to be very clear about them, lest you find out that you technically don't have DMCA safe harbor because you flubbed one of the requirements.

[emily37]

Sort of off-topic, but on the subject of using fragment identifiers to pass around secrets, Ben Adida used them to secure session cookies from eavesdroppers:

https://github.com/benadida/sessionlock

http://www2008.org/papers/pdf/p517-adida.pdf

He uses a token in the fragment identifier to authenticate every request; since the fragment identifier never gets sent to the server, a passive attacker never sees it -- it's a nice trick.

[chubot]

Interesting... but bafflingly, doesn't the URL shortener service they provide totally defeat this?

http://snipurl.com/230jiso

They allow you to shorten the URL by using another service. But now snipurl.com has your URL fragment and can read your stuff!

[kcima]

True, but this isn't where you are going to store your credit card information. My guess is that this is a defense against those who want to control the Internet through legislation.

Imagine a world where SOPA had passed, and everyone who ran a website was legally responsible for everything that their users did.

In that scenario, one way for website operators to protect themselves is to make it impossible to know what their users are doing.

The 3rd party URL shorting service is not storing or associated with the encrypted data and is also not responsible for it.

So this may not be about private data so much as it is about protecting the freedom of information.

[strictfp]

You can't hack the law. All the legislators have to do is to make it mandatory for the site owners to be able to search through site contents.

[ygjb]

It would be pretty easy to build a tool to route around that type of law. I create a service that encrypts blobs of data (encryptmyblo.bs), and uses a (publicly defined somewhere) postMessage API to communicate that blob to and from a key value store provided by a third party. I have my friend set up a key value store service provider that stores and retrieves blobs (storemyblo.bs), including the facility to search for stored blobs of data based on binary strings.

Because the services exchange those KVPs via a postMessage API, neither service is actually communicating with one another directly or have a formal association. The user is effectively (via the browser) moving the data from one service to another. Since EncryptMyBlo.bs doesn't store any data, and StoreMyBlo.bs doesn't have visibility into the data, neither service would be in violation of those requirements.

[strictfp]

It would also be pretty easy to make encryption illegal.

[ComputerGuru]

No, because the goal isn't to protect the user's data from being "leaked", it's to protect the user from the hosting site (zerobin) being forced to take down their posts.

[billpg]

Quoth the project page; "Admins can still remove a document upon injunction or infringement notice… but have no way to tell if the same document has been posted again."

[marshray]

So what happens when Zerobin or SnipURL is ordered to take down "all posts from the same client IP address as the post with the shortened URL of ..."?

[kcima]

Don't log IPs? End user IP's are mostly dynamic anyway.

[toomuchtodo]

And run the entire server out of memory. 64GB of ram is cheap on servers now; you boot from a write-protected flash drive, and everything is done in memory. If you power the box down, anything stored in ram is lost.

[dexen]

> If you power the box down, anything stored in ram is lost.

That's the theory of ideal RAM, but in practice RAM is not ideally volatile. Cf.: http://en.wikipedia.org/wiki/Cold_boot_attack

[marshray]

SnipURL doesn't seem to make that claim. They even load https://www.paypal.com/en_US/i/scr/pixel.gif which has a tracking cookie.