Web Security is still primitive

The current focus in web security is on fixing existing issues with viruses, phishing etc. This is the main barrier to trust on the internet today - and without trust, internet communities, like any other, will die.

But even if we stopped nearly all of these attacks, security on the web would still be primitive. That's because most web architects interpret 'security' too narrowly.

For example, why do I have have different usernames and passwords on different websites and on my PC? This makes it tricky for me to remember which one to type in, causing security issues like account locking and writing passwords down. And can this be done in a secure enough way that my bank will accept this single password, but that I can choose to remain anonymous on other sites?

And shouldn't I maintain a basic profile that all websites can look up (given my permission), so they all know my latest credit card number or address? And shouldn't there be a central repository where I can find out who knows my details, for example what my phone number is, and where I can accept / deny requests for access to this information?

And how do we solve the 'forgetting problem', where I tell someone a secret and have confidence that immediately after, they forget it? For example, when I use a website to purchase a gift, I don't want them to keep my bank account details, they should be permanently deleted after use. How can I be sure they've actually deleted it?

And how can I use hosted applications, like Salesforce or Google Spreadsheets, while maintaining privacy of my data? Could I store the data locally, but use the application remotely? Or is there a way for me to manage exactly who has access to this data, even though it's hosted remotely?

And should I be able to demand access to all data stored about me by any organization?

Some answers to these questions have already been attempted. Microsoft Passport was supposed to be a security model that all websites could sign up to, but it dissolved. We've recently made some progress in understanding federated security - see the Liberty Alliance, although there is distinct lack of real implementations.

These questions will become increasingly important as the web matures; data privacy and federated accounts will become a huge part of online security. But we're years from being able to address them. Web Security is primitive at best.

XHTML and Internet Explorer need each other

What is the future of XHTML, now that Tim Berners Lee has recognized lack of take-up and kicked off further development in HTML? It's clear that even XML enthusiasts are now having to re-assess XHTML and accept that it could be years, if it all, before XHTML gains wide use.

The first reason why XHTML hasn't caught on is the classic chicken and egg scenario. Internet Explorer doesn't support XHTML (except as a broken version of HTML) because there are so few developers using it, and developers don't use XHTML because Internet Exporer (IE) doesn't support it.

And the second reason is that up 'til now the main benefits of XHTML are in computer parsing and XML data integration. But while browsers handle parsing errors, and most structured data is still in non-XML relational databases, these benefits haven't been enough to outweigh the extra effort of using a stricter language.

With the recent rise of XML standards like Atom or SVG, the benefits of XHTML are much more obvious. Trying to embed HTML content inside Atom, or use XML data sources to populate HTML pages, is currently unsatisfactory due to namespace and mime type problems. And Ajax lends itself to the kind of scripted data transformations that XHTML thrives on.

But without support from IE, this kind of use is unlikely to catch on. So what are the chances that IE will be upgraded to handle XHTML? Up till now, precisely zero - in fact there wasn't any new functionality at all in IE for five years.

Now IE development has re-started, XHTML could be just what Microsoft needs to regain momentum on the internet. Firstly, as Kurt Cagle points out, XHTML enables them to move ahead with a new platform free of legacy issues, while maintaining support for masses of HTML code. Secondly, XHTML supports their new Live strategy of merging desktop and internet apps - I suspect MS Office developers are now lobbying for IE improvement that previously they stifled.

The current rumours from Microsoft are not encouraging. The IE team have plenty of work to do, even to fix bugs in their support for existing standards such as CSS. And their history of supporting standards they haven't developed themselves is not great.

But the fact remains: without XHTML, Internet Explorer will not reach its potential. And without Internet Explorer, XHTML will not reach its potential.

New uses for RSS / Atom

RSS, like its web standard sister Atom, was designed to support syndication across blogs. By opening up the data behind a set of blog entries, information could easily be shared across the internet without manual copy-paste or messy screen scraping.

Due to the massive growth and enthusiasm for blogs, all manner of technology to support RSS / Atom is now commonly available - downloadable client news readers, website based news readers, blogging sites, browser toolbars, even integration with the Vista operating system.

But like all great technology, RSS / Atom is useful for a lot more than initially realised. In fact, it's becoming one of the foundations of the web. Here are some examples:

• Business Process alerting engines: use a feed reader to monitor queues and automatically escalate exceptions via email, IM, SMS or VOIP.
• Document Management: replacing user-generated content in Windows Explorer and other document management systems with a set of RSS / Atom feeds. This allow for syndication, tagging, search, subscription, separation of presentation from content, and integration with internet technologies like CSS, HTML, the URI, and javascript.
• Synchronization: Using RSS / Atom to manage automated synchronization, for example between Blackberry / iPod and a PC, or between a PC and internet sites
• Email / Calendar / Contact storage: using simple extensions to RSS / Atom, it's possible to store emails, calendar entries and contact information as a native XML feed. This can replace the dreaded .pst file, bringing the same advantages as Office XML formats did over the old binary files.

The common theme is that RSS / Atom is an internet-based approach to managing sets - whether sets of files, of emails, or of blog entries, it handles them all.

Several extensions to RSS / Atom are in active development (as extensions, these work best with Atom which is namespace aware): Atom Publishing Protocol, to handle updates / deletes as well as simple views of data; SSE, to handle synchronization between feeds; and Gdata, to allow for native email / calendar / contact storage.

But even without these extensions, it's clear that over the next few years, RSS / Atom will become one of the most important foundations of the web.