I just wanted to write a quick follow-up to my post yes­ter­day on Diaspora’s fail­ure to prac­tice what they preach and imple­ment real pri­vacy con­trols on basic user information.

Yes­ter­day I said that to date, the Dias­pora devel­op­ers had “failed to inte­grate their most basic premise into the soft­ware design. They’ve missed the point from first prin­ci­ples.” Well, a cou­ple of friends on Twit­ter called me out on this and asked whether I’d actu­ally checked out the back-end code to be sure about my accu­sa­tions. Maybe Dias­pora was just lack­ing a UI to make the rel­e­vant changes? This is alpha soft­ware, after all.

Well, they had a point. And thanks to the beauty of open source source, I was able to down­load the source code directly and take a look for myself. I only got as far as look­ing at the data­base schemas, but it looks to me like the data­base layer would require sig­nif­i­cant work to bring pro­file infor­ma­tion into their aspect-based pri­vacy model.

The aspect model is clearly built around con­trol­ling vis­i­bil­ity of posts, which starts out by encom­pass­ing “wall posts” and will cas­cade to include com­ments, pho­tos, men­tions, videos and every­thing else that flows from there. At first glance, the team have done well. They seem to have laid the foun­da­tion of their pri­vacy approach on bedrock, build­ing their phi­los­o­phy into the soft­ware from the ground-up. Their ini­tial design will nat­u­rally affect every­thing based on their cen­tral idea of a “post” as the net­work grows and fea­tures are added.

The only prob­lem? Pro­file infor­ma­tion does not sen­si­bly fall into this model in any way. It’s cur­rently stored in fields in the Pro­file model in a non-extensible way which is entirely dis­con­nected from posts. To allow pro­file infor­ma­tion to fall into line with the rest of their aspect-centric approach, they’d need to refac­tor the user pro­file mod­els pretty heav­ily (which admit­tedly they will likely want to do any­way even­tu­ally, given the lim­ited nature of their cur­rent design) and they will also have to rework with the basis of the aspect model or the way in which users and user pro­files are connected.

In other words, their foun­da­tions aren’t built on bedrock at all. They’ve laid them two storeys up, estab­lish­ing their ground­work on top of the hastily-constructed user model they already had in place.

Fix­ing this omis­sion cer­tainly doesn’t look like a triv­ial job. And in addi­tion, let’s not for­get that any rework­ing of their basic mod­els at the data­base layer would nat­u­rally have to fall through the rest of the MVC lay­ers to the UI too. This is not an insub­stan­tial over­haul. Given that the Dias­pora project doesn’t even have a note about this on their roadmap, my ini­tial assump­tion that they’ll have to hack this sup­port in and bolt it on later when it’s too late to refac­tor prop­erly seems accurate.

All of the above shouldn’t be taken to mean that noth­ing can be done and the prob­lem is unre­solv­able, but there is a rea­son­able amount of work involved and it would mean pretty fun­da­men­tal changes to their core mod­els. It’s not some­thing that could get imple­mented as a quick patch; this change would require full sup­port of the core devel­op­ment team. Open source is indeed beau­ti­ful thing that enables us to trust our soft­ware and gain under­stand­ing of how it works, but some­times you just have to hold your hands up and admit defeat.

Dias­pora is fun­da­men­tally miss­ing the point of their own phi­los­o­phy, and there’s noth­ing we can do but wait and see how they end up fix­ing it later down the line. Will it be a Facebook-style mess of pri­vacy con­trols? I hope not, but at present the odds aren’t look­ing good.

I was recently able to sign-up to Dias­pora thanks to the kind­ness of some friends on Twit­ter. I’d been quite excited at the idea of an open-source net­work, dis­trib­uted across many machines and admin­is­tered by any­one who cares to run their own instance (or “pod”, as Dias­pora calls them). The pods inter­con­nect, the net­work grows, and every­one can feel lov­ingly involved in a real social net­work that was built from the ground up on open technology.

It’s a bit dead at the moment, and very lack­ing in fea­tures com­pared to any other ser­vice you might care to join, but that’s fine. It’s in alpha, and miss­ing fea­tures are to be expected (along with a good help­ing of bugs). My real issue with the ser­vice, and the one that lead me to com­pose this blog post under such a dis­mayed title, is that Dias­pora is already fail­ing to meet the expec­ta­tions they set about con­trol over pri­vacy and sharing.

One of the core thrusts of Dias­pora is the big bold mes­sage on their home­page: “Share what you want, with whom you want.” In accor­dance with this, they have imple­mented aspects: con­tacts must be cat­e­go­rized into dif­fer­ent sets of users (which may over­lap as required) so that you can choose what you share and only dis­close it to the cho­sen con­tacts. This, they sug­gest, allows you to share the 3 nice pic­tures from your night out with col­leagues while your friends can see the full dam­age (i.e. the other 47 images). It’s a nice idea, and one that appeals to me. It’s sim­pler than Facebook’s messy pri­vacy model and seems to be built-in from the ground up. Or does it?

One of the first things I tried to do was to hide my birth­day from any­one other than close friends and fam­ily. It’s a silly thing, but I thought it would be nice to share my real date of birth only with my friends; the rest of the world should see noth­ing, or per­haps just the year in which I was born. Not a big deal, but a rea­son­able thing to want to pro­tect given how often date of birth is used in var­i­ous secu­rity mechanisms.

I flipped to my Pro­file Set­tings, but couldn’t see how one might restrict cer­tain parts of one’s pro­file to par­tic­u­lar aspects. Nei­ther biog­ra­phy, loca­tion, photo, or birth­day could be hid­den away. It’s not just that I was in the wrong part of the web­site, which was my first thought: there is no way to con­trol which of your con­tacts see which parts of your user profile.

This is a very basic start­ing point. Even Face­book gets this right. Yet Diaspora—the social net­work that allows you to “share what you want, with whom you want.”—has missed the point entirely.

I know this is almost silly. After all, there’s not much in your pro­file you’d real­is­ti­cally want to restrict at present. But there are use cases for doing so now, even para­noid secu­rity rea­sons. And what’s more, when you can even­tu­ally add infor­ma­tion like employ­ment details, reli­gion or sex­u­al­ity, one might very well want to restrict cer­tain infor­ma­tion to close friends or family.

I did post a con­tracted ver­sion of this rant on Dias­pora itself, and a friend com­mented that per­haps I should try to get involved with devel­op­ment. It’s not a par­tic­u­larly sat­is­fac­tory response. Indeed, the only bad thing about open source tech­nol­ogy is that one can­not make dis­ap­pointed noises with­out some­body else sug­gest­ing they get involved and fix the issue them­selves. It’s a poor response when peo­ple say it on the Gen­too forums, and it’s a poor response when it gets trot­ted out on a social net­work too.

To date, the devel­op­ers have failed to inte­grate their most basic premise into the soft­ware design. They’ve missed the point from first prin­ci­ples. And, like secu­rity mod­els, try­ing to bolt the right behav­iour on to the appli­ca­tion later down the line will be a los­ing bat­tle: you’ll never plug all the holes. I’m not sure any indi­vid­ual hack­ing on the exist­ing code­base can make a real difference.

Despite all of the above, I will indeed keep a close eye on Dias­pora and I’m not going to give up on it. But at present, the dis­par­ity between their mar­ket­ing blurb and their soft­ware is almost unpalatable.

Last week marked a momen­tous change for the UK account­ing indus­try. On April Fools Day 2011, it became manda­tory for UK com­pa­nies to report their statu­tory accounts and tax com­pu­ta­tions in a new for­mat called Inline XBRL. This change trans­formed the way in which orga­ni­za­tions report to HMRC in one fell swoop, simul­ta­ne­ously end­ing the centuries-old prac­tice of fil­ing on paper and unsanc­ti­mo­niously boot­ing PDF fil­ings out of the door (except in very par­tic­u­lar cir­cum­stances). As of now, every com­pany in the UK must file elec­tron­i­cally using a struc­tured data format.

Inline XBRL, oth­er­wise known as iXBRL, is an incred­i­bly ele­gant solu­tion to finan­cial report­ing. A deriv­a­tive of XHTML, iXBRL allows users to pro­duce human-readable doc­u­ments that can be ren­dered in web browser while also allow­ing them to embed addi­tional struc­tured data. When processed by a com­pli­ant proces­sor, an iXBRL doc­u­ment is trans­formed into an XBRL instance document—a for­mat used by gov­ern­ments, reg­u­la­tors and ana­lysts world­wide. For those of you that don’t work in the world of finan­cial report­ing, iXBRL really is a very neat option: the very same data that is read by human eyes can be trans­formed into an XML–based machine-readable for­mat by any iXBRL com­pli­ant proces­sor, allow­ing a sin­gle source doc­u­ment to be used by ana­lysts and BI tools alike.

For the aver­age user, iXBRL means that the doc­u­ments seen on-screen are com­pa­ra­ble to the Word doc­u­ments, Excel doc­u­ments or even PDF doc­u­ments which they are replac­ing (and in many cases, the doc­u­ments from which they were gen­er­ated). Pro­vided it doesn’t hin­der machine-readability or require dupli­ca­tion of data, this famil­iar­ity can only be a good thing. The fact that iXBRL also hides away the hideous angle-bracket-and-slash-infected nature of XBRL doesn’t hurt either. XBRL may well be a great for­mat which is ideal for con­sis­tent, com­pa­ra­ble, and process­able finan­cial report­ing, but it’s miles away from any­thing an accoun­tant would actu­ally want to use or understand.

On a global scale, iXBRL is going to be a big deal pri­mar­ily because it solves the kind of prob­lems that the US have been endur­ing for years. The largest cor­po­ra­tions in Amer­ica have to file their 10-K and 10-Q reports to the SEC, but they have to file two copies of their returns: one in XBRL for­mat, and one in HTML for­mat. One pro­vides struc­tured data, and the other merely allows the ana­lysts who have been rely­ing on read­able returns for decades to con­tinue doing their jobs. This leaves us in a hor­ri­ble half-way house, with dupli­ca­tion of effort (and data!) plus a bor­ing, tire­some job com­par­ing the two doc­u­ments to ensure that they are con­sis­tent. Worse, it means that every­one can ignore the XBRL fil­ings for a few more years and work with the same HTML EDGAR fil­ings they’re already com­fort­able with—reducing the impe­tus for com­pa­nies to pro­duce high-quality XBRL returns.

In the UK, the sharp charge to iXBRL has deliv­ered all of the ben­e­fits of HTML and XBRL for­mats while cut­ting out the draw­backs of being forced to pre­pare both. I’d be will­ing to bet that even though the UK is the first coun­try to make the leap to iXBRL, it won’t be the last.

Wel­come to the world stage, iXBRL. You’re a wel­come addi­tion to the sta­ble of finan­cial report­ing for­mats, and I bet you’ll also be one of the most durable.