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.

I make a lot of inter­na­tional calls at work to US clients and prospects. Unfor­tu­nately, many of the calls are to dif­fer­ent peo­ple in dif­fer­ent cities. I’m not yet at a point where I asso­ciate par­tic­u­lar US area codes with their time­zones (nor coun­try codes with time­zones for that mat­ter), and to be hon­est I’m not sure if I ever want to be that famil­iar with them.

My process used to be labo­ri­ous: visit Ben­net Yee’s Area Code List­ing, by Num­ber and look up the state to which the area code cor­re­sponds, visit Wikipedia and look up the cap­i­tal city of the state, then visit the World Clock Meet­ing Plan­ner and see how our time­zones over­lap. This got old pretty fast.

I’ve solved this prob­lem with Sun­dial, a US tele­phone num­ber to time­zone con­verter. It’s a sim­ple web­ser­vice which takes any old tele­phone num­ber and, if it’s a US num­ber, pro­duces a time­zone com­par­i­sion chart to show how it cor­re­sponds to GMT. Sun­dial is freely avail­able for pub­lic use, so please give it a try!

You can use Sun­dial in a few dif­fer­ent ways. The sim­plest is to visit the Sun­dial con­verter and enter a US tele­phone num­ber that you would like to lookup. For­mat is not important—stick it in with brack­ets, peri­ods, warts and all. Alter­na­tively, to con­vert Mobile: (651) 342.2323 you can just nav­i­gate directly to http://benjaminasmith.com/tools/sundial/Mobile: (651) 342.2323 and get the answer you’re look­ing for.

My favourite way to use Sun­dial is via Fire­fox Smart Key­words. Using smart key­words, I can just type:

sun Mobile: 651.342.2323

To set this up, just cre­ate a new book­mark to http://benjaminasmith.com/tools/sundial/%s and give it the key­word sun.

Sun­dial is still under devel­op­ment, so I’d love to hear any sug­ges­tions you might have or fix any bugs you might come across. Let me know how you get on in the com­ments, or drop me an email.

Snow­fall is a fairly reg­u­lar occur­rence. In the UK we are graced by snow for around 10 days per year. Fewer days of snow may affect those near the coast, or many more may affect those in the Pen­nines, but it is a safe bet that you will enjoy a nice coat­ing of snow for at least a few days per year.

The reac­tions to snow are mixed. For some, they fear the has­sle it brings: dis­rup­tion to travel, to deliv­er­ies, and to daily rou­tine. It brings wet car­pets and cold ears; school clo­sures and icy pave­ments; slip­pery sur­faces and soggy train­ers. For oth­ers, snow is a bless­ing. It brings snow­balls and sledg­ing; qual­ity time with the kids; days free from the com­mute and free from the office. And for many, it means a day off. But just because it dis­rupts rou­tine, why should it destroy productivity?

Snow seems to be the only form of weather which can reli­ably bring British busi­ness to its knees. After the recent snow, absence man­age­ment orga­ni­za­tion First­Care esti­mated that nearly 11 per cent of the UK work­force stayed at home—the high­est fig­ure ever recorded for Decem­ber. Mean­while, The Cen­tre for Eco­nom­ics and Busi­ness Research esti­mated that this spell of absen­teeism costs us over £1 bil­lion per day. That’s over 26% of Britain’s daily GDP.

The key ques­tion for me is not why 11% of the UK work­force stays at home, but why stay­ing at home car­ries such a high cost to busi­nesses. Why does a lit­tle snow (or even a lot of snow) cost us 13% of our daily GDP?

In 2009, it was esti­mated that 73% of the UK GDP came from the ser­vices sec­tor. In today’s world, ser­vices means far more than tourism and trans­port: it also means finance and busi­ness ser­vices, many of which are essen­tially vir­tual. What do I mean by “vir­tual” ser­vices? I’m refer­ring to ser­vices which at their core do not directly relate to phys­i­cal prod­ucts or the move­ment of mate­ri­als. They relate to con­cepts, to ideas and to impor­tant infor­ma­tion, yet they do not require a phys­i­cal back­drop. These are ser­vices like account­ing, adver­tis­ing, design, pro­gram­ming and sup­port. To an extent, even tele­sales, recruit­ment and many real estate ser­vices fall into this category.

ONS sta­tis­tics show that even in 2000, over 10 mil­lion peo­ple were employed in vir­tual sec­tor jobs against a back­drop of over 25 mil­lion work­ers employed within the wider ser­vices sec­tor. The vir­tual sec­tor makes up approx­i­mately a third of the UK work­force, yet accounts for closer to half of UK GDP. In today’s cli­mate (both mete­o­ro­logic and eco­nomic), surely the over­whelm­ing major­ity of vir­tual sec­tor should be able to work from home and reduce the cost of snowfall?

There are plenty of exam­ples of how com­pa­nies can func­tion even while staff work from home, and plenty more exam­ples of com­pa­nies fail­ing to think ahead. I’m going to pick out two.

I’ll start with a soft­ware house in Oxford at which many of my friends are employed. When their offices are snow­bound or employ­ees are faced with a rather slip­pery uphill strug­gle to get to work, they are all pro­vided with myr­iad sen­si­ble ways to work from home. For some, this is as sim­ple as using the same lap­top at home as at work. For oth­ers, it is cen­tred on good, thor­ough doc­u­men­ta­tion and a reliance on free, open source soft­ware. Sen­si­ble email access poli­cies allow users to get set-up from home, and employ­ees are pro­vided with secure access to the com­pany intranet through use of free, multi-platform, open source soft­ware like PuTTY. Because the com­pany base so much of their oper­a­tion on open source soft­ware, employ­ees can freely install almost any of the other tools they need to do almost all of their work from home. It’s not ideal, but it’s prag­matic and allows for solid pro­duc­tiv­ity even in the worst con­di­tions. All they need is inter­net access.

Let’s take a rather less impres­sive case: Ebuyer, the online elec­tron­ics super­store. Snow hits, and their deliv­er­ies take a hit—something which is per­fectly under­stand­able given the loca­tion of their offices in East York­shire. How­ever, not only do their deliv­er­ies strug­gle, but so do their tele­phone lines. When the snow came down in early Decem­ber, their tele­phone lines were closed for days and email enquiries received very lim­ited responses. This was appar­ently because their staff could not make it to the sup­port cen­tre. But why did staff need to be in the cen­tre to work?

There are many free or cheap solu­tions to route tele­phone calls that do not require a phys­i­cal ded­i­cated line hooked up to each hand­set, and indeed vir­tu­ally every call cen­tre already uses these. There are also plenty of good and cheap solu­tions for rout­ing calls over IP. As for remote email access: this is just a given in the mod­ern world, and all it takes is for a plan to be in place. Could staff not have been pro­vided in advance with a spare head­set and any required doc­u­men­ta­tion to allow them to sign-on and work from home? Per­haps this is impos­si­ble with the sys­tems that Ebuyer have in place, but with a lit­tle prior plan­ning and good choice of tech­nol­ogy it seems very unlikely that the prob­lem could not have been avoided.

The key point is that with a lit­tle prepa­ra­tion and a lit­tle tech­nol­ogy there is almost always a way to allow vir­tual sec­tor employ­ees to be work from home. There are so many solu­tions which are already in use for this very purpose—an increas­ing num­ber of which are already in your IT infra­struc­ture, are freely avail­able, or can be cheaply deployed from the cloud. This is a solved prob­lem from the tech­no­log­i­cal stand­point. Con­nec­tiv­ity is not an issue even over great dis­tances, and band­width is largely free for con­sumers, so why not make use of it? Why are we still left to floun­der when the snow settles?

This is a call to arms. Man­age­ment: get pre­pared, talk to your sys­tem admin­is­tra­tors in the New Year, and make this hap­pen. It might require a lit­tle effort and a lit­tle will, but it can be done and will deliver huge sav­ings to your busi­ness even in the medium term.

Every­one else: go out­side and make the most of the snow while you can. This time next year you might find your­self not skiv­ing and sledg­ing, but work­ing from home. At least you’ll get to skip the commute…