I'm increasingly amazed by the number of banks and other secure services that seem to spread their online services over dozens of differerent domains. Simple put, a domain is one unit of trust, for a variety of reasons, and this is even assumed for security reasons in many applications (cookies and XSS sandboxing spring to mind). It's cheaper, easier, more secure, and visibly more secure to use subdomains than purchase a separate domain to redirect users to for secure services.

Some of the culprits I've come across:

• NatWest (at natwest.com) use nwolb.com for online banking.
• RBS (which owns Natwest) also owns Streamline Direct, a payment gateway. RBS' merchants' customers get redirected onto Streamline Direct (at streamline-esolutions.com) to enter credit card details. Most won't have ever heard of them. But if you did Google for them you'd find them at streamline-direct.co.uk and/or streamline.com.
• Paying for domains online yesterday (at streamline), I was redirected to securesuite.com, ostensibly some Mastercard security thing, and asked to enter my credit card details a second time.
• Barclays' (at barclays.co.uk) runs their payment gateway out of epdq.co.uk
• Play.com hands over to playsecureserver1.com to take card details.

And just to contrast the way it's supposed to work, let's think of a few examples of big sites with secure services:

• Amazon (www.amazon.co.uk) uses https://www.amazon.co.uk.
• If you pay Google for advertising (adwords.google.co.uk), you'll pay at https://adwords.google.co.uk.
• What domain does Paypal (www.paypal.com) use for secure services? https://www.paypal.com/.

It is relatively trivial for a hacker to obtain an SSL cert for an arbitrary domain, but extremely hard to obtain an SSL cert for someone else's domain and then insert his machine into their DNS. Either way, he still has to compromise a web server somewhere to get his machine inserted into the chain, but web servers do get compromised, and he would have to find it beneficial to redirect to a third-party machine rather than set up some credit-card interception on the compromised host, but that's not that hard to imagine either - maybe he can't obtain the requisite privileges, or perhaps it's less traceable to redirect to a different (perhaps also compromised) server.

Maybe I'm just paranoid, but more important than technical security measures are social measures: How can the public be expected to avoid phishing attacks when legitimate services are being given untrusted domains?

There is no good way I know of refactoring selector-driven stylesheets. Procedural styling, such as that used by smarty or even vanilla PHP, is easy. Styling starts in one place and flows in a controlled way through to the end. Selectors make life difficult because you don't know what is going to match where or what is overridden by a different selector elsewhere. It's very difficult to work out how it works, even with comments, because you don't know which comments are immediately relevant and besides, they refer to a document structure which is dynamically generated.

I've never managed to cleanly refactor CSS and I've not really tried with XSL, because it looks difficult for all the same reasons. With XSL there's an intermediate XML structure that can be refactored, but this is generated procedurally. But for the presentation layer - CSS, XSL and to some extent Javascript - if anyone knows a better way of refactoring than throwing it all out and starting again, please let me know.

My web shop codebase really needs tidying up. It includes lots of things that I wouldn't do the way they are done now that I've had some experience of maintaining the codebase.

I have a ton of integration to do. There are two branches to the codebase:

• One (let's call it 'stable') has seen bugfixes and customer-driven improvements, but has been branched a dozen times and is a huge mess.
• One has had some refactoring and more developer-driven improvements, but currently crashes due to character set issues.

After that is done, the administration interface needs to have some serious work done. Most importantly, the ImageChooser service needs to be pretty much redone. It all needs a bit of AJAX on top to make administration a more smooth experience, and I need to hook up TinyMCE to bolt in a minimal CMS.

The difficulty, if I do this work, is that I may still have to work with the aforementioned 'stable' version even though I will have a much improved next-generation version available. Perhaps I can cut a deal on that.

I'm also considering supporting osCommerce, because it would be cheaper in terms of codebase maintenance, but I wouldn't be able to make the same guarantees I can about implementation of bespoke features and use of future-proof technologies. This would be available as an alternative to my shop software.

What I most want to do is rewrite everything in Python. Python is much faster to develop with than PHP, and leads to much tidier and more legible code.

Sometimes - increasingly perhaps - I find myself using Inkscape for constructing program assets.

Program assets are a different beast to standalone artworks because you start to have to recombine artistic elements in new ways programmatically.

Most of the time, when web programming, you don't really need to generate completely original artwork on the fly, but you often need to composite some selection of pre-drawn assets. There are a variety of ways to do this, but Inkscape doesn't seem to make any of them very easy for me.

Composition of minimal PNGs

Export PNGs from Inkscape and composite them elsewhere, using external data or hard-coding to get them all to composite in the right place. This involves working out offsets, either by trial and error or trying to read them off the rulers in Inkscape. But, madly, the rulers and coordinates in Inkscape have the y-axis inverted.

You also have to build the document in Inkscape so that the various elements can be exported with the alpha channel - independently of shapes above and below the one you're trying to export. This means everything has to either be cloned off the page, or drawn on a seperate layer so that it can be independently hidden.

If you're actually attempting to composite PNGs client-side in IE, you need to use the PNG alpha hack, which isn't universally applicable.

Composition of padded PNGs

Export PNGs that are padded such that they can all be composited using one origin. This can be done in Inkscape, but it still isn't easy, because Inkscape only has the option to export the selection. The trick is to create completely transparent bounding rectangles and use these to store Inkscape's export settings. The resulting graphics are larger in filesize than they might otherwise be, and composition could also be slower.

This DHTML clock I wrote a while back mainly uses this method.

Export SVG

Export SVG and write a program to import, modify/compose and potentially rasterise. Rasterisation is still tricky. It will be really useful when browsers get more widespread support for SVG.

Still, this method requires painstaking care making sure that all the symbols are easy to recombine. It often means using a lot of svg:use elements (clones in Inkscape lingo), or, more easily, rewriting the xlink:href attribute to repoint the link to a different symbol. Doing it this way preserves the affine transform, but creating your own transforms (for a newly created clone, say) is still tricky.

The SVG Cities interface I mentioned recently uses this method.

Draw out all the permutations

Generate lots and lots of permutations using Inkscape, perhaps using a script to accelerate exporting them. This only works if the number of permutations is small, if it's possible to use only a subset of them, or if they can be generated en masse using Inkscape's excellent Tile Clones tool.

This is the approach I'm about to take with this DHTML dice widget I'm working on. First I've drawn out my base dice, then I've cloned one face onto the sides of one die.

Now I can align the 5 currently unused faces over the 5-side, then modify the links using Inkscape's XML editor:

Some of the problems I've come across in Inkscape when used for this kind of work include:

1. As mentioned, the y coordinates are all wrong so any coordinates you read off the UI have to be mapped y -> (document height - y)
2. Inkscape doesn't offer any way to make symbols more invariant. Ungrouping and regrouping works, but is time-consuming.
3. There isn't an easy way to manage which clones link where, or re-link clones on mass. In fact the only way to re-link clones is with the rather dire XML editor.
4. Inkscape doesn't let you group 1 primitive, even though this is both valid and useful.
5. Inkscape doesn't let you create offscreen symbols for use with clones.
6. Inkscape doesn't make it easy to set IDs for things.
7. All IDs generated by Inkscape are meaningless alphanumeric strings. Clones, for example, don't inherit any part of their parent symbol's ID.
8. Inkscape has a "label" as well as IDs. Label overrides ID in all of Inkscape's UI, even though they are also meaningless alphanumeric strings, useless in the programming, and they must be set independently of the ID.

Well what do you know... what with all my recent work with client-side scripting and then today's look at Mauvesoft Gallery and scanning for photos, I was just thinking about an AJAX-powered web-based Picasa clone when I stumbled across Google's Picasa Web Albums, which I hadn't seen before.

I've uploaded a few photos to it, and it's OK I suppose, but it's not as developed as some of the other Google webapps: it's just a basic web gallery. It's better than Gallery (Capital G) because Gallery is a mess these days. Gallery 2.0 is hugely bloated, and for all that bloat it isn't very much more powerful and certainly not as easy to use as Picasa Web albums.

Still, I think Mauvesoft Gallery is a fairly good web gallery core, and it's simple and hackable enough that I could probably rig up some AJAX over the top quite easily. It would certainly make for an easy-to-use administration interface, but I was thinking more of the on-the-fly searching, and Picasa's wonderful 'Timeline' feature. I wonder whether the publishing to the world of photos is the main aim when people use web galleries, or is it that they just want access to all their photos wherever they are? (Or a third option: my brother, on holiday, uploads photos from Internet Cafes so that he can delete them from his camera to free up space.)

A fork of Mauvesoft Gallery is used to power the ImageChooser component in my e-Commerce software, and that is desperate for some attention. The UI is appalling at the moment. Perhaps I'll download Dojo and see if that can speed up the development.

One of my old online friends, Twisted, messaged me this morning to say that he was having problems with his installation of Mauvesoft Gallery. He had reinstalled in on a new Ubuntu box but it was not thumbnailing properly: first it was not generating thumbnails; then, having fixed that, he found that it was not caching them.

Anyway, I tarballed up my unstable development version, 1.5, which adds a few features and fixes a few bugs.

Changelog

• Feature: PHP-based templates
• Feature: Watermarking of thumbnails
• Feature: Images now support EXIF captions and titles
• Theme: New theme 'corporate'
• Theme: 'slides' rewritten in XHTML and CSS
• Bug: Thumbnail transparent PNGs with GD
• Bug: .JPG extensions not considered images
• Bug: Directory names containing '+' character
• Bug: Imagemagick engine doesn't work with CMYK JPEGs

He installed that and after a few permissions bugs, it's up and running.

I suppose this makes it almost ready for an RC. The first alpha is already running on a site I did a couple of months ago for a client, Photography2you.

When I actually package this for release I'm going to use shar, which I am fairly confident I can use to configure the installation after it has unpacked. All webapps suffer from this installation problem, and there doesn't seem to be a generic solution for installing them, even though there is a very limited range of things that need to be configured to get them off the ground on a single-vhost basis. I can't imagine that it would be hard to write a package manager for them. Mauvesoft Gallery works on Windows and even IIS too I believe (although I've not tested it recently), but Windows is much more lax on the permissions (although I've not tried Server 2003), so a normal ZIP file may suffice.

It also occurs to me that as part of this shell-based installer I could offer the user the option to scan their $HOME and symlink any directory it find containing photos (for some definition of photo... perhaps JPEG image over 1 Megapixel?) into the Albums root. Zero-configuration installs here we come. The goal is to make Mauvesoft Gallery simpler to install and use than any other gallery software.

I've been working on this website recently which has really challenged my technical abilities.

I've put together a Javascript system, which I'm quite proud of, for implementing quite a lot of Flash-like effects with pure DHTML, with the aim of remaining accessible.

The complete system works like this:

1. You describe and lay out the pages however you want them with XHTML and CSS.
2. You describe transition timelines in an XML-based language. You can animate scalar CSS properties and colour values with cosine interpolation; you can assign attributes and CSS properties; and you can import and replace content in the document with AJAX. For accessibility, the idea must be to transition one page completely into another, although there can be some purely graphical effects in between.
3. The Javascript loads the transitions with AJAX and sets up event handlers to run the transition.

Easy! It's like developing web pages in CSS, except that you get to animate your CSS properties. There's also a bit of hackery to smooth over some IE issues.

I'll post more about this when it's a bit more polished.

That's not the bit that has challenged my technical abilities. The technical challenge is working with the clients' ideas. This job is actually under subcontract so there's a chain of clients all wanting to get their way, but it seems to me that every time I implement something technically impressive, the clients see what I have achieved and assume that any small modification is an inherently small task. This is not universally true.

I think the site currently looks pretty naff. I've not had artisitic control on this one, and it's a mess. The animations are distracting, and the clients keep asking for something ridiculous, like "make this image fill the screen". That's not something that can be achieved in an attractive way with a fluid layout. This was actually in the brief, which was why I originally started with a fixed layout, but one of their first demands was to move from a fixed to a fluid layout, and I can't seem to get them to understand that's the trade off.

This is the damage Flash has done to the world of web design. Clients want pointless effects and WYSIWYG modifications, because they've seen it on other sites, without knowing the actual situation with respect to accessibility or maintainability.

I've been experimenting with using Greasemonkey to rewrite the interface to a game I've been playing recently called Cities. I was trying this because I wanted to test how well a native SVG interface to a web application might work, and it was much easier to work with an existing web application - one that I use - than developing one as I go.

Here's a screenshot of the standard Cities viewport (with CSS styles by Bebe):

And this the current status of my viewport implementation:

Cities is a browser-based MMO. It's a slightly off-beat fantasy game with some humourous elements and not very many quests. Many of the rules are based on alignment, which is one of the four classical elements: earth, air, fire and water. It's alright, and quite fun when you get a couple of the alignment quests under your belt and the game starts to open up a bit, but the design isn't very polished and much of the world is fairly large, boring and featureless.

Anyway, it's quite well developed as a web application, and I play a little bit daily, so it's a good candidate for my experiments.I decided to use Greasemonkey after trying some of the Greasemonkey scripts other people have written to add the features they wanted to Cities. The approach I wanted to use was to replace the viewport with an SVG OBJECT on my server, and configure the OBJECT with Javascript by parsing the data out of the standard viewport's DOM tree. However, Firefox's Javascript sandbox prevented me from accessing the OBJECT's .contentDocument property because the SVG was loaded from a different domain. This is to prevent cross-site scripting vulnerabilities.

The first thing that occurred to me as a workaround would be to host the SVG on the Cities Wikimedia Wiki. Then by assigning a value to document.domain (this is allowed iff you're generalising from a subdomain, which the wiki is) you can permit the XSS.

But in fact I didn't try this because this would require me to update the version on the Wiki every time I wanted to test a page load. So in fact the approach I took was to load the entire SVG with a Greasemonkey AJAX request (has to be a GM AJAX - the vanilla kind also has XSS security) and import the SVG DOM into the HTML DOM. Firefox in fact renders this combination better than it renders an SVG OBJECT, because it can use the native dimensions of the SVG from the SVG documentElement rather than you having to respecify them as attributes of the OBJECT element.

For the parsing of the DOM tree, I would have liked to have used E4X, but it doesn't appear to work. This could just be a Greasemonkey limitation, because Greasemonkey uses XPCNativeWrapper for security reasons, or it might be that E4X doesn't interoperate well with DOM yet. It didn't occur to me at the time that I could have used XSLT, but there was quite a bit of processing involved in configuring the SVG DOM tree, so although this might help it would only be of real use in reading the state of the view from the source source DOM. This would be easier than writing DOM javascript to do it, but not as easy as E4X.

Reconfiguring the DOM was mainly rewriting and adding elements to link to symbols defined within the SVG file. No SVG paths were constructed in the Javascript, only a few elements.

I've got relatively far but the thing that has halted my progress is the problem of perspective on the viewport. I could make the view isometric, but I could have done that with a collection of absolutely-positioned transparent PNGs.

I could encode some 3D information in XML and use that to lay out the artwork in the tiles with perspective correction, but that is a lot of work for what is basically an experiment.

One of the first things I wanted to do with Oli's blog was start making minor alterations to the default Kubrick theme (which I really like, incidentally) in my favourite vector graphics editor, Inkscape. However, after searching the web for the source, I eventually found that the original source was a Photoshop file - one that the GIMP couldn't open.

Frankly, I don't think this is a very good show for an application which purports to be open-source. Anyway, as a result I pulled Wordpress's assets into Inkscape and reconstructed the graphics, as closely as I could, tracing the originals.

The result is an SVG file and a shell script to extract the assets. The assets should all be replaced together because the match isn't quite pixel perfect, but if you do replace them you shouldn't notice the difference.

Ok, so I've been lured into the world of blogging, which I have been loathe to do ever since blogging took off.

This was partly - perhaps mainly - a result of working for a while on my brother's blog, which was set up to allow him to keep his friends updated about his progress on his trip round the world. While working on it I became enamoured of Wordpress, because it is relatively elegant to use.

However the codebase for Wordpress is a mess. I found an outstandingly stupid bug/feature the other day on my brother's blog: no thumbnails are generated when uploading photos over 3 Megapixels in size. There's literally a test there that just checks the dimensions, compares to an arbitrary 3 Megapixel value, and if not, you're silently handed back the full-size image. It also defaults to simply embedding a thumbnail, without a link or anything. And there's no option to change that. You have to hack the code. And the particular hack needed to change the default (which is a tri-state toggle option) isn't just reordering an array or assigning a different initial value - it requires hacks to the PHP code, the HTML code and the Javascript!

Anyway, this will not be a stream of consciousness blog about life but a blog focused on software development, primarily web-based because that's what I do for a living. We will probably discuss the problems I've encountered and/or solved, interesting ideas, and shameless plugs.