thefoundation

Diaspora — Can the Social Graph be Our Web of Trust?

2010-08-23T01:30:22Z

On Friday we had Max, Ilya and Raphael from Diaspora over at Mozilla. They talked about their effort in creating a distributed social network. Where I think they are on the right track, and where they should think even bigger.

Why we need Diaspora

Personally, I see three major challenges that everyone passionate about the open internet needs to make up their mind about:

The erosion of Net Neutrality
Participants switching to closed environments of apps and appliances, becoming mere consumers (*)
People entrusting their personal data and social activity to Facebook, forced to choose between control and connectedness

In the context of the Diaspora talk, I’ll focus on the third issue.

We need Diaspora because people need to be in control over with whom they share personal information. Every time Facebook sneaks in a new default that breaks privacy, we grudgingly change the settings again — and stay, not wanting to lose our friends. Or we just don’t know about it and leave it as it is. Combined with the social monopoly that Facebook has established, this makes privacy and security optional features, subject to change like any other.

How Diaspora can help already

The main distinguishing factor of Diaspora compared to Facebook et al. is in that it decouples your social graph from the network provider, bringing back real competition to the social space. Like with E-Mail, there can be lots of network providers, loosely connected over push-interfaces. Whenever a pod (the equivalent to an e-mail-provider in Diaspora) should violate your trust, you can just switch to another one, or set up your own pod.

What could be done better

On the downside, this means that you have to trust your pod as well as all your friend’s pods. No big deal? Well, where the same server software is used on a distributed network, it is very prone to exploit of vulnerabilities due to patch delay and misconfiguration (correctly setting up TLS is still a big challenge, not only for regular people).

Secure HTTP is great when a large, anonymous group of people needs to trust a central service. It allows us to do online banking and purchases, free from eavesdropping and man-in-the-middle attacks. However, it is not peer-to-peer: When you fetch your mail over a secure IMAP connection, you might be sure that your password is protected, but you do not know who actually sent you that e-mail (think about it: that is the reason why phishing works). When you get it from Google Mail, you might be using TLS, but Google is still able to read your every conversation.

How PGP can solve this

I propose that Diaspora pods should be dumb post boxes that are not able to actually look into status updates, private messages, friend lists and so on. How? The technology for that has been available for quite some time and is called PGP.

Basically, PGP allows you to send and receive messages that cannot be decrypted by the servers that route them. So, if you were to encrypt your message inside your browser, you would establish secure end-to-end communication. No need to trust the shady pods that some of your friends decided to use, not knowing any better. But encryption in a web client? That sounds awfully slow! Well, Firefox Sync does it already with your entire browsing history (the pass phrase to your key is never sent to the server), and I would imagine that JavaScript interpreters have become fast enough to emulate the cryptographic capabilities of a PC from 1991.

I do have ideas on how to approach search and incremental profile updates with this, and on the new security considerations that apply here (Can you always trust your browser? Could a pod not make you use an insecure web client that transmits your passphrase?). However, that is rather technical, possibly material for a follow up post.

The social network is a key signing party

The problem with PGP has always been that people have been unable to exchange public keys in a manner that is both trustworthy and extensive. Because a web of trust can often not be established, people refrain from using encrypted e-mail. Turns out that social networks come with a mechanism that is just made for this: Friending. In the secure social network, accepting a friend request would be equivalent to exchanging keys. Usually you are referred to friends from people you already know, so there already is a basic level of trust.

This means that online social networks can be transformed from a jeopardy to our security to a vehicle of the same. This idea is of course also not entirely new. What might be new is the idea of building the social web entirely on top of PGP rather than just integrating that as an optional feature.

Any Comments?

I have not gotten around to add Commenting or Pingback to this blog, but I would love to incorporate any (links to) comments in a follow up post, please write to michael at this domain.

Update:

If I understand correctly, the diaspora guys are already planning to use GPG for cryptography somewhere. This is a pretty good start. If they really already plan on generating keys for everyone, then they would only need to pull the actual encryption into the web client.

(*) Like any intern at Mozilla I had the opportunity to to talk to John Lilly, and I got the impression that Mozilla takes this development very seriously.

It appears I was wrong

2009-04-08T23:18:11Z

Yesterday, Google announced the availability of Java as the new programming language for the App Engine, refuting my guess from last year that it might be JavaScript — though of course, not entirely.

If you take the demand of the users into account, Java is of course the right choice as the next language. It might just alienate lots of Java-Developers if a niche language of the server zoo such as JavaScript was to emerge first. Additionally, Java is one Step short of full (albeit sandboxed) JVM support.

To allow for sandboxing, Google wraps some of its own API's into Java SE or JSR–standardized services such as javax.mail and java.net.URL. Also, there is a white-list currently containing 1323 of the 3700+ Java SE 6 classes. Most of the classes that are not available are from the Swing and AWT suites which a web developer will not need anyway. Instead, Google provides the homebrewn GWT.

Thanks to the free and open source Rhino JavaScript Interpreter written in Java, server side JavaScript on the App Engine is rather easy to achieve now. I guess I might have to check it out and report back about it later, so I just signed up for the Java technology preview on my App Engine account.

There are some videos from the Google Campfire event over at Youtube. Most of the time they are rather interesting, plus Kevin Gibbs does a pretty decent imitation of Steve Jobs during the presentation (voluntary or not).

Is JavaScript The Next App Engine Language?

2008-09-21T04:00:28Z

As the language of the browser, JavaScript has become a kind of common denominator among web programmers. On the server it is rare compared to Java, PHP, Ruby or Python. Could this change, since Google has built an implementation of JS and an affordable yet scalable web application infrastructure?

Scripting Language of The Open Web

JavaScript was created as a scripting language for the Netscape 2.0 browser. Other than its namesake Java, it has remained in the browser since then. Web Developers know this language because they have to use it, no matter if they like it. Throughout the late 90s and well into this decade, JavaScript was mostly regarded as a toy language for silly effects and simple form checks. Due to the more recent experience with Ajax applications and the resulting thorough coverage in technical literature, the users of JavaScript have become more professional.

The Server Domain

The development on the server side has — with some notable exceptions — ignored the language JavaScript for many years. Perl was a dominant language in the early days. Then, PHP gained momentum in the fast growing developer community during the internet bubble due to its gentle learning curve, the simple integration with MySQL and the overwhelming availability of inexpensive shared hosting. You could say that in its ubiquity, PHP has mimicked JavaScript, only on the server.
Other languages and tool chains have gained momentum since then, most notably Ruby, Java and Python. They are not as affordable as PHP (except Python on the App Engine), and seem to be used mostly because of their modern MVC frameworks.

Why JavaScript Is Not Popular on The Server

JavaScript has some fundamental weaknesses that have inhibited its inception as a server side programming language:

JavaScript, — or rather ECMAScript — has no real standard library, it is just a language. There are no tools for file or process manipulation. There are no database bindings and there is no shared memory. There is no way to open a socket.
In the past, JavaScript Interpreters have not been known for their performance. Anyone who has seen the message A script on this page may cause Firefox to run slow. would think twice before writing an application in JavaScript.

The Helma framework tries to address the first issue by using the Rhino Interpreter, making the Java SDK available to the JavaScript programmer. The second issue is at least partially resolved as some performance intensive tasks are moved to Java. In Java 6, Rhino is even bundled with Java. Nevertheless Helma and similar integration efforts are not very popular, compared to Rails or Struts. A reason for this might be that Java for the web (the enterprise edition) is a very serious business, while the perception of JavaScript has long been ...well, the opposite of serious. The two cultures do not seem to mix well yet, as good as the technologies might blend.

Why The App Engine Loves JavaScript

When Guido van Rossum adopted Python for the Google App Engine, he had to remove lots of features because they would not work with the sandboxed, replicating environment which is the App Engine. It turns out that the limitations of JavaScript really make it an ideal candidate for the App Engine.

JavaScript is just a language: It cannot create sockets, files or processes. App Engine does not allow for that anyway, so this is a plus!
The language is easily sandboxed. Web Browsers have to do this all the time. This is ideal for a shared hosting environment.
It has a no database bindings included, but a natural serialization format, JSON. This is great for the Google Data Store, because it stores objects, not table rows.
Recently, JavaScript Interpreters (or, lets say JavaScript Machines) have become fast. There is V8 and it is fast.

It is known (at least since Guido van Rossums talk at DjangoCon 2008) that Google plans to adopt more languages for the app engine. Also, there are four primary languages that Google uses for development: Python, Java, C++ and JavaScript. Python is already available. Java is a good candidate for the App Engine, but it is not exactly lightweight certainly not shared nothing. C++ is probably the opposite of any sandboxable language.

In combination with a template engine, a free offer on the App Engine might give the already ubiquitous JavaScript language a final boost. The prospect of one language from model definition to client side computation is certainly compelling!

To encourage further speculations: With Google's V8 machine comes an embedding, process.cc, that contains code necessary to extend a hypothetical HTTP request processing application - which could be part of a web server, for example (...) (V8 Documentation).