Data is compressed using the deflate algorithm, then base64 encoded to ensure it can be stored safely in a URL. It is then set as the window.location.hash of the current page. Testing with various URL shorteners has shown that they don't care about long URLs generated by this. I still need to add checks to ensure that the URL isn't too long (I'm looking at you IE), but as a quick proof-of-concept I'm happy with what I've come up with. I'm wondering whether the same idea could be used to share data in other formats...
Brilliant idea, by the way.
HN submission: http://news.ycombinator.com/item?id=2464213
Now you combine that with this in a bookmarklet / plugin. Add some obfuscation so bitly or whatever url shortener you use has a hard time detecting you and so the wrong anchor or no anchor shows an innocuous page.
Now the host isn't aware of the existence of the data nor is the encryption being done using server side code.
I am of course probably missing a huge flaw, so someone tell me why this won't work and how to fix it.
A truly server-less pastebin would use the `data:` URL scheme to encode the html & js script boilerplate in addition to its content.
You're right, data: would be more pure, but AFAIR it has some limitations.
 - https://github.com/lucaspiller/shortly
One problem I noticed with it though:
It does not work correctly with Japanese text. I can input & "save" Japanese, but upon opening that link the text will not be displayed correctly.
I think you should implement the hash-based encryption key support from Zerobin, though. That way you could send around the message or the message and the key, as you choose.
If you want to password-protect your paste, you are free to pass it through GPG before posting it. Much better security than trusting a third party's JS library which may have been modified in transit or even contain a back door.
It links here:
i would like something like this for binary data, with the option to specify a filename, as that is something the data url scheme does not provide.