May 18, 2009

Re: Technology Bill of Rights

*** Disclaimer as to the tone of this response ***

Sometimes people misread the tone of a blog post, response, or comment. Since I don't have an expertly-developed tone, I'll make it clear: I'm nice. I respect other peoples' thoughts and the opinions of those that I disagree with. If you feel I am being nasty, just pause and re-read the sentence. Imagine someone smiling. There you go.

I recently read an interesting blog post by Paul Venezia about a Technology Bill of Rights. While the post makes some great points and is great for initiating dialogue, I think that some of Venezia's ideas are woefully mislead.

To begin with, I disagree with the notion that a Technology Bill of Rights is necessary, and in fact that it would be a good idea. When a nation needs to address the issues of a changing society, there are generally three options.

1) We predict the future and write laws based on that. If that were possible, the founding fathers would have already made laws about blog posts :)

2) We make new laws every time something changes. This is the general approach that our government takes, and it is the approach that is implied by a Technology Bill of Rights.

3) We take the laws that were created centuries ago in the Bill of Rights and decide their interpretations through the courts, like we were meant to.

This third approach is the one I recommend. As I will note later, I think most of the issues that Venezia addresses in his post can be handled by interpreting and/or enforcing current law.

Venezia lists six articles as possible starting points for a Technology Bill of Rights. In my opinion, he's on the right track with most of them. But, here are my qualms:

Article 1. Any individual shall be able to choose anonymity when posting to Internet sites. This is the one I most strongly disagree with. If people were forced to embarrass themselves in angry, misguided comments (as Venezia comically points out :) ) I would agree. But people are not forced to participate in online community activities, they make a choice. If they make the choice to go ranting in comments, they should make the choice to read the privacy policy of the site they are posting on. Should sites perhaps be required to accurately enforce their own privacy policies? I could see how that could be reasonable. But by no means should web sites be forced to provide anonymity to any user who wants it. Web sites should be able to do what they want!

Anticipated counter-argument: nobody reads privacy policies. Well, nobody asks for the nutrition facts at McDonalds, either. That doesn't mean we make McDonalds illegal just because most people don't know how to protect themselves from it. People make choices!

Article 2. No network provider may constrain or restrict access to the Internet in any way, shape, or form other than agreed-upon access speeds. I have a kind-of complicated view on Net Neutrality, but I'll just say I agree here since I mostly do.

Article 3. No individual shall be held liable for effects of malware or malicious code unknowingly run on a personal computer. Agreed, but this issue doesn't need its own law--it needs a court decision. In the American court system, the prosecution must be able to establish intent. The case of Julie Amero that Venezia mentions is something that never should have happened. It was an example of a mishandled trial on both sides (the prosecution and the defense), and luckily it was overturned. But still, we don't need to pass a law making citizens "not liable" for malware running on their computers. If all citizens were totally not liable, this would mean that, in order for a prosecutor to prove the intent of a hacker who installed malware intentionally on his own computer, he would literally have to prove that the hacker "knew" that the malware was installed, which would be impossible. Sounds like a can of worms to me.

Article 4. A company that produces and sells closed source software for use on computers shall be responsible for the security of that product, and a user has a right to seek damages in the event of a failure to secure their product. Companies are already liable for whatever they sign a contract to be liable for. If a consumer wants total liability protection from a software producer, they simply need to find one that will offer it. As with Article 1, this is a blanket law that isn't needed. Consumers need to take responsibility for who they sign up with and what those people are liable for.

Article 5. Any software or hardware used to conduct or support laws and public policy shall be open-source. Actually, I love this one. The point about the breathalyser is dead-on. Good call.

Article 6. Any media content legally purchased by an individual shall be available for private use on any device, at any time. This one falls into the same category as Articles 1 and 4. If consumers don't want DRM on their music, they don't have to buy from iTunes! CDs still exist. And so do other online music stores that let you download actual MP3s. If DRM continues to get out of hand, the free market will handle it because consumers will cut out of places that abuse their customers' loyalty.

I hope everybody will read Venezia's article. It's really well-done. Though I disagree with lots of it, I appreciate Venezia's open-minded tone and general desire for more openness. I just hope that people can see openness through a broader lens, as I feel I have presented it here.

Peace!

May 15, 2009

Secure AJAX calls without SSL

I recently spoke with an individual who was very upset that his password had been sniffed because he was using a web application that didn't offer a secure connection via HTTPS. I began to think about how the developer of that web app must have felt: either waste money on an SSL certificate for this dumb site (which doesn't even store any personal data) or incur the wrath of angry customers whose passwords get sniffed by pranksters.

During the conversation with this angry individual, I zoned out and decided to think about how I would approach this problem as a developer. Certainly, not all sites need secure access via HTTPS, but wouldn't it be nice for small sites to have encrypted form submissions and AJAX calls?

After some thought and some Googling, I did bit of work on this issue for fun. I have affectionately named the fruits of my efforts RSAJAX.

I'm a big fan of getting to the fun part. Here's a demo.

I am using several open-source libraries here. Proper attribution will appear in a more-descriptive write-up I will be doing tonight. I literally just finished it up five minutes ago, so I'll probably be cleaning and tweaking it too.

Update: A web page is now available that gives more information on RSAJAX. Check it: http://www.andrewpeace.com/rsajax/

The process here is actually very basic, even for somebody like me who isn't into crypto. All you need to understand are the basics of public-key encryption (specifically, RSA) and private-key encryption (specifically, RC4). Just Google it...

The server generates a private and public RSA key, the latter of which is shared with the client-side via a regular AJAX call. The JavaScript then generates an RC4 encryption key, which is a simple matter of generating a random 256-character-long string. JavaScript then encrypts its RC4 key with the server's public RSA key, and sends it to the server, where it is decrypted with the private RSA key and stored.

From that point on, making a secure AJAX call is simple. First, JavaScript encrypts any values being sent to the server using the public RSA key. Once the server receives an encrypted value, it decrypts it with its private key. This is exactly the same thing that happened when the client's RC4 key was shared with the server.

When the server is ready to respond, it encrypts its response via RC4 using the client's key, which it has stored. Upon receiving the AJAX response, the JavaScript can then decrypt that value using its RC4 key.

Shazam! Encrypted on the way up, encrypted on the way down.

If you are wondering why this process involves both RSA and RC4 encryption, there are good reasons for it. I'll get in to those when I do my next write-up. Anyways, I may swap out RC4 for something a bit stronger.