Personal Data

Last week, the UK government revealed that it had lost personal information on 25 million people - all 7.5 million families in the country. The information included names, dates of birth, addresses, national insurance numbers (like US social security numbers), and bank account details.

This catastrophe can hardly have been worse. It's potentially the worst loss to terrorists and criminals since the Jul 7th bombings, and even worse a loss to financial stability than Northern Rock. It abuses the trust of nearly 50% of the country.

What's more, the institutional failings revealed are breathtaking. Why on earth was an obviously untrained 23 year old even allowed access to the data? Why didn't anyone - neither HMRC, the NAO or the IT company that provided it - seem to care that it wasn't encrypted? How could it possibly have been sent via the unregistered post? And why weren't the lessons learned from many similar, if smaller scale, recent incidents in the same government department?

Once the dust has settled, and hopefully managers have been fired for rank incompetence, there are two basic lessons to learn - how to manage personal data, and how to secure identities.

Controlling personal data

I already blogged that citizens should own and manage their own data, not the government. Citizens should also be able to see which government departments are using their data, and how, and when. Any time the government wants more access to my data, they should have to personally ask me - because it's mine!

Proving your identity

In the age of MySpace and Google, whoever thinks that their date of birth is a secret? Or their home phone number and address? Because that's all you need to log into my phone banking service.

This security model is absurd, we can't trust our identities to supposed 'secrets' that can be discovered by anyone in the world in 30 seconds flat. We must find something more trustworthy - whether physical (e.g. fingerprints), or mental (e.g. a password) - or ideally, both.

It's outrageous that the government should abuse our trust by losing personal information about every family in the country. But it's also outrageous that this simple personal information is enough for serious identity fraud to take place.

Some good can still come from the HMRC catastrophe, provided we learn the lessons and build a new security model for the 21st century - a model that places data control where it belongs (i.e. with each individual), and that provides a safer way to prove identity.

Convergence

One of the universally accepted themes of IT in the last few years is "convergence". Markets are merging, technology is standardising, and gadgets are getting common components, all driven by the internet.

So what does "convergence" mean? Actually there are three different convergences taking place:

Device convergence

Firstly, devices. Phones, laptops, TVs, PCs, and even cameras and satellite navigation systems are increasingly sporting the same features (operating system, internet access, camera, touchscreen) and can access the same applications. Apple's use of Mac OS X across its complete product range - iPhone to 24" iMac - shows the way forward.

Device convergence means that the consumer electronics industry is becoming something more cohesive - call it the "internet device" industry. The industry-spanning strategies of Sony and Apple will win - expect mobile phone companies (e.g. Motorola) to merge with PC companies (e.g. Lenovo) to compete.

Despite this standardisation, hardware is actually getting more important, not less - note the success of innovative products like the Wii and iPhone!

Network convergence

The second type of convergence is for networks - the IP protocol has won. Broadband, phone line, cable, mobile have just become different ports into the internet. That explains the focus on the triple play (mobile, broadband, landline) - it's all becoming the same thing.

Networking is a utility industry, albeit one experiencing rapid technological evolution. The players - e.g. Vodafone, AT&T - are terrified of becoming utilities, but there's nothing they can do to stop it.

Application convergence

Silicon Valley has won this battle - applications are moving to the web. Simple old HTML and javascript have somehow beaten massive corporate creations like Java and dot net (not that many technologists outside Silicon Valley have realised it yet).

There are only two successful business models in Silicon Valley - adverts for consumers, and subscription (i.e. software as a service) for the enterprise.

Different industries

These three convergences are delivering three massive new industries - the internet device manufacturers, the networkers, and the application providers. They're very different industries, with different business models, regulations, capital investment patterns, and rates of change.

So there's one type of convergence that I really can't see working - convergence across industries. That includes Nokia (Ovi applications will never compete against Adwords), Google (what do they know about operating a network?), Vodafone (spare me the "Vodafone live!" closed garden). Even Apple, so great at hardware design and OS software, haven't yet built a hugely successful website application.

Next time you hear the "convergence" word, watch out for which industry is being mentioned. Though the internet might drive all three, they're very different!

CSS Color Gradients

1. Introduction

This document proposes a new feature in CSS for creating color gradients. These gradients define an additional <color> value type for the CSS3 Color specification; as such, they can be used in place of a traditional color anywhere in CSS, e.g. as a background color gradient, a text color gradient, or a border color gradient.

The proposals are based on the SVG specification. However, CSS color gradients could style any markup element, including HTML.

2. color-gradient-linear

Linear color gradients are created using the color-gradient-linear color value, which takes several parameters:
color-gradient-linear(angle, offset1 color1, offset2 color2, ... , spreadmethod)

angle indicates the angle of the gradient from horizontal, moving clockwise so that an angle of 0 deg creates a gradient from left to right, and 90 deg creates a gradient from top to bottom.

At least one offset & color pair must then follow. offset indicates where to start the gradient, and can take any length unit. Draw a line through the containing element, following the gradient angle; offset takes the values 0% and 100% where the line hits the element's inside border.

For example, if angle=0deg, then an offset of 0% indicates the gradient starts at the left hand border. If angle=90deg, then an offset of 100% indicates the bottom border.

color can be any valid CSS3 color value, including rgba and hsla values that enable opacity.

The spreadmethod parameter, which is not required, can take three values - "pad | reflect | repeat". This indicates what happens if the gradient starts or ends inside the bounds of the target element. Possible values are: pad, which says to use the terminal colors of the gradient to fill the remainder of the target region, reflect, which says to reflect the gradient pattern start-to-end, end-to-start, start-to-end, etc. continuously until the target element is filled, and repeat, which says to repeat the gradient pattern start-to-end, start-to-end, start-to-end, etc. continuously until the target region is filled. The default value is "pad".

Examples:

    /*linear gradient from green to blue, moving left to right*/
em { color: color-gradient-linear(0deg, 5% green, 95% blue) } 
    /*linear gradient from a transparent red to solid purple, top to bottom*/
em { color: color-gradient-linear(90deg, 5px rgba(100,100,100, 0.5), 200px purple) }
    /*linear gradient from green to blue to yellow, right to left*/
em { color: color-gradient-linear(180deg, 3px green, 50% blue, 100% yellow) }
    /*linear gradient from green to blue to green to blue ..., left to right*/
em { color: color-gradient-linear(0deg, 0px green, 10px blue, reflect) }

3. color-gradient-radial

Radial color gradients are created using the color-gradient-radial color value, which takes several parameters:
color-gradient-radial(center-x center-y, radius1 color1, radius2 color2, ... , spreadmethod)

center-x and center-y indicate the center of the radial gradient, offset from the top left corner of the element.

At least one radius & color pair must then follow. radius indicates where to start the gradient; it must be a positive length value, starting from the center of the circle. A value of 100% for radius indicates that the gradient is equal in length with the element's width.

The spreadmethod parameter works exactly as for color-gradient-linear.

Examples:

    /*radial gradient from green to blue, center outwards, starting at the element's center*/
em { background-color: color-gradient-radial(50% 50%, 0px green, 50px blue) } 
    /*radial gradient from a transparent red to solid purple, center outwards, starting top left*/
em { background-color: color-gradient-radial(0px 0px, 5px rgba(100,100,100, 0.5), 200px purple) }
    /*radial gradient from green to blue five times, center outwards, starting at the element's center*/
em { background-color: color-gradient-radial(50% 50%, 0px green, 20% blue, reflect) 

Social Graphs and Unsocial Graphs

Tim Berners-Lee just wrote a wonderful note on the social graph. He points out that just as the "III" (net) connected computers, and the "WWW" (web) connected documents, the "GGG" (giant global graph) will connect real objects - including people.

So let's return to OpenSocial, Google's new social networking API. I already commented that it might (just) be an open API, but it certainly doesn't open the data - connections between people - which is the important thing. It shouldn't be only Myspace widgets that can securely access this information, but any website.

Tim's blog reveals a further issue - it's not just about connecting people, but connecting anything! OpenSocial doesn't seem to handle my CV, my possessions, my train tickets or what I ate for breakfast this morning. OpenSocial might be a small step forward, but it's not nearly the full answer - it only handles basic information about people.

Tim has clearly found a huge and important issue to resolve, and more people in the industry should be paying attention. Unfortunately, I just don't think they are.

Part of the issue is that he's way before his time - everyone is still focused on the document (HTML). Another issue is that his proposed solution, rdf, doesn't carry enough incentives for people to use it - I can't put adverts in rdf, I can't directly create compelling content with rdf, and anyway no applications take advantage of it yet. A third issue is that it's not clear how HTML (e.g. a Wikipedia entry on breakfasts) would sit alongside rdf (some XML technical markup that describes the same thing).

There is a way out. Create a new open data format standard that describes a person (Google have made a start on this already with GData), and add it to OpenSocial. Make this data format compatible with RDF, e.g. FOAF. And finally, hand the data over to the user - it's theirs to manage.

That way, at least one usage of RDF will take off - information about people and their connections. OpenSocial will gain new momentum, since the data will be free, not just the API. And finally we'll have a springboard for the graph - not just social ones, but any graph - to take off.

The new iPhone SDK will be Safari

Apple's recent announcement of a native iPhone SDK seemed a massive U-turn; first Steve Jobs promised pure web development, then he relented. But I suspect their native SDK will in fact be an upgraded version of Safari - web development on steroids!

There are several reasons why web applications failed the iPhone:

• Connectivity - endless waits for page load over slow and uncertain EDGE networks
• Presentation - browsers can't handle coverflow, smooth animation or rotations
• Awkward audio and video - no flash plugins lead to messy javascript solutions
• Memory access - you can't access the phone memory using javascript
• Sensor access - you can't control the camera, microphone, touch sensor or proximity sensor using javascript
• Cultural - people still expect the mobile web to be crap

Within the last month, a series of announcements have led me to believe that Apple will chip away at all of these issues.

Safari have already announced local SQL database support, which is part of the draft HTML 5 spec. Combined with other HTML 5 sections like caching, this would solve the connectivity and memory issues above, allowing offline access via local memory.

David Hyatt, the lead Safari developer, has also hinted (see comments) that perspective transformations (enabling coverflow) will shortly become available in Safari. CSS animations and affine transformations, including rotations, have also been added to the beta version of Safari.

Now, Safari have announced support for HTML 5 media, bringing first-class audio and video to the iPhone's browser.

Putting two and two together

I just can't see why people aren't putting two and two together! The only remaining technical issue with using Safari as a client development platform is access to the iPhone's sensors - so I fully expect Steve Jobs to announce a javascript API in January's Macworld.

It also provides another reason why Apple released Safari for Windows; they're building a browser competitor to Windows, and they need maximum distribution to persuade developers to use the new web SDK.

For Apple it makes good sense to convert the browser into an OS; they sell hardware, and they get to ride the internet wave. Safari as the client development platform is the classic disruptive innovation!

OpenSocial isn't open enough

Google's OpenSocial has attracted enormous publicity over the last week - it's seen as the entry of the big beast into social networking, fighting Facebook and Microsoft by transforming the rules of the game.

But I honestly don't think it has changed the rules of the game. The API is only 'open' in the sense that lots of companies have signed up to using it - it does pretty much the same as Facebook's API, albeit using HTML rather than Facebook's weird proprietary markup.

It's the basic premise that I disagree with - that social networks are 'container' applications, within which every other application is hosted, as a 'widget'.

The problem with apps hosted INSIDE social networks is that you get data silos - not everyone I know is in Myspace, and they never will be.

Instead, we need apps that work ACROSS social networks, gathering the relevant friends and details from each to provide the complete picture - e.g. a complete address book.

Writing one of these apps is not about data storage, it's about data aggregation from all across the web. For example, a photo editing website should allow you to import your friends and colleagues from ANY social network, to allow you to collaborate on a picture. That's not possible with OpenSocial.

Of course, I'm sure OpenSocial will be extended in future. Since Brad Fitzpatrick is reportedly behind both OpenID and OpenSocial, I wouldn't be surprised if we see some immediate progress on this front from his employers Google. If my URI for OpenID is the same as my URI for OpenSocial, then whenever I log in someplace, it gets automatic controlled access to my details.

So OpenSocial gets us some of the way there, but the vision is still not complete - it may be a relatively open API, but it currently enforces a closed data model.

Web Communication

Technology is there to enable people to do things. So, if you want to write a successful application, it's worth asking what things people like to do! And there's one answer that has proved itself time and time again - people like to communicate.

The killer apps of the internet have always been communication tools - starting with email, moving to webmail, instant messaging, blogging, Twitter streaming, and most recently social networking.

So how far has the web come in enabling communications? I put chart together to work this out.

Communication types

Timing	View	Add	Method
Asynchronous	Private	Private	Notebook
Asynchronous	Private	Public	Email / Voicemail
Asynchronous	Public	Private	Blog
Asynchronous	Public	Public	Wiki
Realtime	Private	Private	Dictaphone, CCTV
Realtime	Private	Public	Instant Message
Realtime	Public	Private	Twitter / TV / Radio / Webcam
Realtime	Public	Public	Phone / video conference

The most obvious thing to note is that every cell in the table has something in it, so there are no obvious gaps - but many are filled with very recent technology, and it's still changing very quickly.

Secondly, the table drives home just how important and useful the Atom Publishing Protocol is - starting from blogging, it is spreading to all the asynchronous types of communication. That shows some foresight from Google, who have based their architecture around the standard.

Thirdly, realtime communications technology seems less mature. That's not a surprise - HTTP was designed for the asynchronous request / response pattern. So it will be interesting to see how this piece develops.