Out of the way

If you read my blog obsessively, checking every 15 minutes to see if I wrote something new and reading it immediately, you should probably relax a bit. On the other hand, thank you (it would be nice to think that someone likes what I write enough to do this) - and as a reward you find out that we just made a public alpha version of Opera 9.5 - the new "Kestrel".

Read more...

Microsoft recently announced some stuff about how they would handle accesskey and keyboard shortcuts in IE7 (so being opinionated in this fieldI commented - apparently before my good mate John Foliot).

What they choose to do is sometimes important. The fact that they aren't considering site-specific preferences except for "some future version, perhaps" only matters to their users - it is a convenience or accessibility functionality.

But their implementation of accesskey, which was also followed by Mozilla, causes problems for everyone. Because IE has such a large market share, things that cause sites to break in IE are not acceptable for many site designers. Making a page that causes the browser to behave in unpredicted ways and breaks the predicted functionality isn't helpful. So people are going to avoid using accesskeys that conflict with normal IE behaviour.

This is good of them, unless you are one of the people whose life would be made a lot easier by good shortcut navigation around websites. (On average people are not, like me their life will be unaffected or made just a little bit easier, but nobody who reads this blog is average, right? ). Being an international product with various localisations means that a lot of the keyboard gets used up. For many years now, authors have been trying to find the keys that cause the least conflict with bad browser implementations, instead of suggesting something that is actually memorable.

(Of course authors making better use of the rel attribute to support very highly predictable navigation would be nice, too. The fact that not all browsers have good support for it isn't much of a reason not to use it, since unlike accesskey it doesn't do funny things even to browsers with poor or no implementation).

So I would love to believe that Microsoft are going to improve their implementation in IE7, and Mozilla their next version, to something that reduces the damage to the accessibility of the Web. (Yes, I do mean something like what Opera does for accesskey). It should not be difficult for them to move to the approach of having a pass-through key instead of just changing expected browser behaviour (without any warning, at the moment).

This implies changing the way part of the user interface works for people with disabilities. In general this isn't considered a brilliant idea. On the other hand the people who want to use accesskey are not getting any support, because authors avoid using it. At least some of those people would be heavy keyboard users in general, so having their browser functions vanish on them will be a frustration too. It will cause a few authors a little pain. Those who have been helpful enough to have implemented access keys and then realised that they needed to do more work to explain what is happening in IE and Mozilla/Firefox will have to change their text that says

press alt+key to go to this link

to take account of the fact that there are different implementations out there. It seems a relatively small price (if somewhat unfair) for a relatively big improvement.

(as in Opera 9 technical preview 2)

If you've ever used dashboard on a Mac, or if you remember when the first window interfaces came out or what a "TSR" program was, you probably understand what I think is cool about these things. In one sense they are quite simple - you write a web page using normal web page tools - HTML, CSS, SVG, JPG images, Javascript, etc. (Well, this is Opera, so you can use advanced coolness like canvas, webforms 2, SVG animation, or whatever your favourite authoring mode is as well as doing plain simple HTML). You write a little bit of information about what the widget can do. And then it runs in its own space, a little tool you keep on the desktop and can drag around.


This is a technical preview - so the widgets are not yet complete and perfect in all cases. For example some of them lack keyboard navigation or other common Opera features. But they do cool things, too.

I've been testing them for a short while, and found the nicest thing is that I can keep them enabled, use the "7" key to zoom out (make them tiny) and then stack them all in a corner of my screen to drag out when I want them. ("6" key takes them to 100% again).

I started playing with writing widgets. It is easy enough, although it's helpful to have a bit of sense for design, and there are a lot of things you can do more easily if you are a gun javascript programmer. It looks like being a neat tool, in the way taht sticky blog posts are neat. At some point I might convert some of my panels (which are overflowing, because I hooked up oodles of useful services) to a few widgets. But for now I am lokoing at making sure we figure out all the accessibility issues and get fixing and improving for the "release" version.

Note: My security work has mostly been in dealing with service architectures and intrusion detection (and partly in bars, which is surprisingly similar in most of the basic concepts and approaches). I haven't got a monopoly on making mistakes, so I intend to revisit and edit this any time I learn something should be changed... (Also, it's not really necessary to be a heavy security and web geek to understand the ideas in here, I hope. Whether that makes them intreresting or not is another question).

Security on the Web is pretty important. At Opera we work hard on in, and according to Secunia (who watch over this area pretty carefully we are normally better than either Internet Explorer or Mozilla/Firefox at not exposing ourselves to new attacks, and at fixing problems fast and effectively.

The early Web didn't really address security - it left it to a seperate layer (primarily SSL - the https URIs that you often see are the most obvious example) that was developed as the need arose, and could be put in place because of the clean seperation of layers. For many years the US government stopped this being available to the whole world, but as newer and better systems became available they could be dropped into place. This seperation of layers is an important theoretical principle, with some practical benefits - you can be surer of your security when it is not bound up with every other function that you are developing, and testing is more straightforward.

As the Web has become more complex and dynamic, to offer more useful services, new types of security requirement have appeared. When pages were static, or had a simple form that could talk to the server that gave it to you, SSL was fine. "XSS" (cross site scripting) actually appeared with forms that would pretend to be one site but were really talking to another, giving, say, your address and phone number to badguys.com instead of to niceFolks.org. Technologies like Frames and Javascript, as well as offering new possibilities, made it easier for a site to pretend to be something else, and even to use a real site as a kind of "trojan horse" to fool the user into trusting it.

At the same time users have learned more about how the Web works, and browsers have developed ways of helping them check that they are not being tricked. The little yellow bit in the Opera address bar tells you who owns the site you are connected to, and how good the security is (on a scale of 0 to 3). Browsers also block the most obviously dangerous cross-site access. In general, a script from dodgyDevelop.com cannot access your information on myBank.com unless the site itself has a copy of the script that it delivers because it trusts it. When these blocks are not in place you can get the kind of problems Jim Ley has noted recently in development projects.

(Development is like this - the trick is to release a service in a way that doesn't expose other risks by getting the layers right. One of the common processes is to use expert crackers to find bugs before releasing software - this is standard QA. In the Open Source world, the theory is that so many people look at the work that problems are picked up and solved. In some cases this works well, in others not, according to the actual results).

Although this security approach is helping to keep us from being caught out by a malicious attack, it comes at a price. The idea of the Web is that you can use a service you find. Of course you need to know, when anyone in the world can offer a service, whether you can trust it. This is not new to the Web. Most people are already wary about b eing offered millions of dollars by someone they don't know who says they were stolen in a far-off country, and many are wary of giving money to people who claim to be collecting for some good cause, but can't show who they are. Trust networks are things people have in the real world, but interfaces and systems for building them on the Web are not yet mainstream, and are not necessarily simple to create at the moment. So we live with the cross-site restrictions as a simple answer, winning something and losing something.

In accessibility, I have had a long-running discussion with my good friend John Foliot about how to deal with making keyboard access better for people who need it. A key disagreement we have is on whether it is better to get rid of existing content along with broken implementations, or whether we should take an architecture that is clearly flawed, and adapt it in ways that let us keep using the existing web, at the price of taking longer to work towards the system we would like. In that case I believe that the value of the existing Web is high, and we should keep it, since we can minimise the practical cost.

In this case, the security model is not yet built into the specifications that describe how the services themselves can be built. It seems to me that we are better keeping it out - making sure that we can change the model we have now for a better one (both in actual security and in minising the downsides of the implementation) as soon as it is readily available. The idea of writing the security model we should be using into the specifications for the formats we use strikes me as wrong on two levels.

1. Using a new format specification will mean copying the security information into that specification. This seems like a bad approach
   
2. More seriously, it makes it harder to replace the model with a better one, since it needs to be teased out of the specification, and in the worst case replaced with a new set of specifications, something that takes a very long time to put in place.
   

In other words, I am worried that we are giving ourselves the relatively comforting protection of a security blanket instead of growing up and thinking about real security as adults who decide for themselves what to trust.

Comments are actively sought here. This is complex stuff, and more brains working on it is a good thing IMHO.