>In which the author explains DOMCrypt in a non-technical manner

>DOMCrypt is a Firefox privacy extension I have been working on for some time. In this post I will attempt to explain what it is and why I am working on it in a somewhat non-technical manner.

What is DOMCrypt?

The core functionality is being able to take a bunch of text (or any data) and turn it into an unreadable blob via a password, right in any web page.

For instance, you can take the sentence: “Meet me in Lincoln Park by the beach at 2:00” and scramble it into something that looks like: iim08xKWVut3eqGubpq2jdCTanU7jV41q4UQKTJOoLD8y6sadUEm/8K9kpv+Wvq

The scrambled “version” of the sentence cannot be turned back into plain text unless you know the password required to convert it back.This sentence can be sent to your contact, who alone can unscramble it and read the plain text.

The cool thing is that this kind of data scrambling – encryption – is pretty standard these days, in fact, you use this technology every time you visit a page that begins with https://.

The problem I am trying to solve is that the encryption tools in your browser are either not exposed to web pages for developers to use or the implementation (of, perhaps, an extension) is so complex, few users will ever use it.

Why DOMCrypt?

If you think about it, you realize that it is nearly impossible to communicate online without the content of the conversation recorded by a third party. Whether the purpose is ‘advertising’ or truly nefarious, you are stuck revealing your conversation to your internet provider, free email host, or social networking site. Perhaps that is not a problem to you, but to many it really is a bad situation.

The web has evolved into a network where users are tracked as web sites are traversed, their email and personal information is archived, collated, sliced, diced and indexed. Your data is not yours. This is about privacy and it is about ownership. Is privacy a relic? Is the ownership of your data important to you?

Privacy really needs to become the default configuration, a primary feature.

There is a lot of upheaval in the world right now. People all over the world need to be able to communicate privately, anonymously (or pseudo-anonymously) and quickly. With DOMCrypt, developers can build privacy-enhanced pages and applications which fully obscure at least the contents of these messages. The server that accepts these messages can be written so that there is virtually no identifiable data stored about the user.

Related

2 responses to >In which the author explains DOMCrypt in a non-technical manner

>avoiding data mining and advertisements is only one side of the problem. For someone like me, I don't really care that I'm being tracked. What I DO care a lot about are two main things: 1) protecting sensitive data and 2) evading censorship.Sensitive data gets sent to a 3rd party server where usually it is encrypted immediately. However, there are leaks and breaches all the time so the 3rd party should not be responsible for that burden of protection. The case where a rogue Google employee started stalking someone after sniffing their IM conversations is a perfect example of why we can't rely on 3rd party encryption. In this case, Google did not *intend* to expose sensitive information, it leaked out.Luckily, censorship is not so common on the web but it could become worse. Twitter does not censor any of its data or reveal private data (just like most responsible companies) but recently the US government subpoenaed all the data they had on Julian Assange. They had to comply with the law to hand it over. If the data were truly encrypted then there would be nothing they could hand over. This is another perfect example of why we need true encryption.The biggest problem with protecting data is one to many communication. A lot of social networks happen this way: you send data to a channel rather than a single person. The public key exchange in something like DOMCrypt does not scale very well for this situation so I think one-to-many is still an unsolved problem.

>@Kumar:Yeah – the censorship issue is central here, as well as the simple act of having a truly private conversation.The key exchange issue in a 1 to many conversation is not too difficult actually. You can create a new symmetric key for each new message, encrypt the message with it and encrypt the one-time-key with the recipient's public key. This will make sending the message take a moment or two at worst – at least you are not encrypting the message for each recipient. Core i7s can make this a reality. The next demo I will build will be a status-feed-style communication app.