At first glance, what’s not to like – a thought through JSON api which uses HTTP PATCH – see that proves they’ve been thinking.

Unfortunately it repeats what I believe is the big mistake in OpenID – assuming that HTTP URLs (and in the end DNS) is the right place to root the decentralisation.

OpenID proved that most people won’t register a domain and set up a service on it just to have an identity on-line (and arguably that they just don’t think of themselves as URLs). And if you don’t do that, you’re still tied to whichever host you initially choose. You might have data portability, but you don’t have identity/graph portability. Even with e-mail (one of the 2 obviously successful internet-scale decentralised systems), most people only have data portability and not identity portability because they don’t own the domain they’re sitting on. That massively increases the costs of moving, and I’d argue moving e-mail providers is easier that moving social graphs because of the variety of relationships and associated data you have with people in your social graph.

So can/how do we do a social network/graph/identity system where everything isn’t tied to URLs/DNS?

Having given it a full couple of hours though, I think it’s possible with judicious use of crypto, really good UX, and probably some help from the smart devices everyone carries around.

When you learn to program in C, you’re exposed to data structures which map easily to underlying hardware. Basic data types are of a fixed size, and locating information within them is based on indexing a number of bytes into them. If you want a variable size data structure, or to find information within a structure based on something other than a count then you need to either build something complex or find a library to use.

Of course keeping mappings between data, and dealing with unpredictable and variable sized collections of data are incredibly common.

When Java came along in the mid 90′s, it dealt with this by modelling the language in the same way on the workings of the machine, but provided a bunch of high quality variable and associative data structures as part of the standard library. These have evolved over the years, and we now have some incredibly capable and flexible data structure available.

However, in 2012, the way they’re available feels increasingly archaic.

Other languages which eschew the direct mapping to the underlying hardware for developer productivity make these structures available as ‘part of the language’. Sometimes these implementations aren’t as fully-functional, but they make simple things simple, and allow leave options open for the more complex cases.

Javascript objects are all dictionaries (maps from string to something). Ruby arrays are variable length. In Scala lists and maps feel like they’re part of the language.

While I have sympathy with the idea of designing a language which maps cleanly to the underlying system, I don’t think it’s a decision which makes sense any more. Good developers will learn/understand how these feature work, and when it’s (in)appropriate to use them. And they won’t adopt/stick with your language when it makes simple things difficult.

Yes, Java 9, I’m pointing at you.

This is convenient for users as they have fewer logins to remember, and don’t have to repeatedly enter the same information every time they want to use a new web site.

It’s good for third party sites because it’s fast and easy for the users, and also because they often gain easy access to extended data about the user in the form of their social network.

It’s good for the social network because they get more information about what their users do when they’re not active on the network directly. This is valuable both to improve the network, but more significantly is valuable for ad targeting which allows them to make money.

There are some downsides though. For the user, a loss of privacy, and for the third party site, having to share the usage data with the identifying party.

There are a number of alternatives, but none have yet taken off.

Mozilla BrowserID/Persona is a recent attempt I’ve been experimenting with over the last couple of months.

The two core design decisions which differentiate it from other attempts are:
1. Use of am email address to identify users rather than a URI as users are used to thinking of themselves in terms of email addresses.
2. Designed to be natively implemented by browsers. This is good for preventing phishing and protecting privacy.

Like OpenID, it’s decentralised, allowing domain owners to vouch for users at that domain. One of the challenges that brings is in bootstrap. Most people don’t run their own domains, so for people to opt-in, they’d have to wait until their e-mail provider adds support. In order to work round this, Mozilla has set up a fallback system which verifies ownership of e-mail in the traditional way, with the intention that over time, fewer and fewer people will use this.

As a Java developer, this probably should be difficult to say, but it’s not. Now is the time to disable the Java browser plugin by default. In the past year I’ve only consciously used it on one site, and in that time there have been a whole bunch of security vulnerabilities in it.

The era of native plugins is nearly over, Java included. There are still a few sites out there which need it, but those are so few and far between that I’d recommend keeping it installed and disabling the plugin and re-enabling only when absolutely required.

This is trivial to do in Firefox, and I’m sure must be in other browsers as well.

Was interesting to dig out basic trig knowledge, and I’m sure my solution isn’t optimal, but it was a fun way to spend an afternoon.

I got there in the end, but unfortunately a little late to actually spend the time to make a decent planet… maybe something for the train tomorrow.
Anyway, I’ve uploaded the .qtz file to downloads.illsley.org. Feel free to grab it and drop it in ~/Library/Compositions/ if you want to play with planets on the Mac.

It’s this flexibility which introduces what I think is a difficult to solve problem. If you’re running a non-SSL site, and an attacker can gain access to your DNS (as recently happened to theregister.co.uk and others), they can ‘pin’ your users to a public key which you don’t have the private key to, and which isn’t revocable. At that point, you either rely on the browser vendors to somehow decide that you really do own your site, and push some kind of special unpin message to all browsers, or you pay up to the attacker to buy the private key, from which you can have a cert issued, and which you can then use to serve your site, and probably downgrade from pinning and HSTS.

In this case, we’ve essentially shifted trust from CAs to DNS registrars, who inevitably have less security expertise. Without HSTS+pinning, theregister.co.uk just had to wait for the registrar to correct the whois records, and for the DNS to propagate. With pinning, a similar registrar failure could have a much longer lasting impact. There are variants to this attack which simply require acting as a MITM, but in those cases, gaining a CA cert for a target domin is considered much harder.

This attack essentially targets the bootstrap phase which we already knew wasn’t secure. After a few days pondering solutions to the problem, the solutions I can come up with essentially further weaken the bootstrap phase, but enable pinning over the long-term without these problems for non-secured sites.

My proposal is to soften the effect of the ‘pin’ for 72 hours from when a domain is first pinned. If, in that period, a certificate which doesn’t correspond to the pin is encountered, the browser must apply heuristics to determine what to do. This may include user input or communication with white/blacklist services. It must not blindly obey the pin.

Why is it important to put this into the spec? If I think about the costs of setting up a truly secure and trustworthy blacklist/unpin service, the task is as complex as running a CA. I think it’s unreasonable to expect that browser vendors will want to get into that business. And even if they did, the time it might take for them to correctly identify the domain owner and correct pinning status would likely be lengthy. Any site owner setting a pin would be rightly upset if their site was incorrectly unpinned. Providing a short window (at the already weak boostrap phase) where a lower set of expectations is codified would provide cover to implement sensible heuristics and low-bureaucracy services to mitigate the worst of the problem, without implying that those same services would be appropriate for a general pin revocation scenario.

How so? Well, Eclipse supports ‘Access Rules’ on dependency libraries which essentially mimic the Export-Package property in OSGi. A tool which allows you to easily set up this configuration based on the manifest would allow you to respect the (normally carefully crafted) Export-Package restrictions without going all the way to OSGi. Hopefully this means that you’re less likely to use APIs which are considered internal, and so when you’re upgrading the version of your dependency, there’s less likelihood of accidental incompatibilities.

The source to this (very simple) plugin is on github, and along with a built jar which you can drop in the dropins folder.

Then, to use it, simply right-click on a Java project and select “Refresh OSGi export restrictions”. This will then scan the dependent jars and their manifests, and for OSGi bundles, update the Access Rules to explicitly allow use of exported packages, and forbid use of all other packages (this is visible in the Java Build Path/Libraries tab).

If it’s useful and you have feedback, please use the tracker on github.

So what does the future hold? Well, a move away from a software product vendor to a company which uses technology and software in support of (and to drive) its business. Also a move from the leafy Hampshire countryside to Canary Wharf. On a date TBC in the not too distant future, I’ll start work as a software engineer at Morgan Stanley.

I’m really excited and looking forward to working with a new team on new challenges and learning a lot more about the finance industry.