February 18th, 2008
The PCI DSS is clear on how to handle CV2 (also known many other acronyms: CVV, CVV2, CVN, CCV, CVC). You may not store this number “subsequent to authorization”, not even encrypted. This means the number is highly sensitive. It is treated as the one true anti-fraud measure for Cardholder Not Present transactions. Of course, this is slightly odd - it’s written right there on the card for any old waitress to see - but the Payment Card Industry makes the rules and this is the rule they’ve set.
The user friendly model for e-Commerce payment is this:
Confirm these purchases -> Enter credit card details -> Please confirm that all of the above is correct -> Thanks, here’s your order confirmation.
The final confirmation is vital for making sure customers are informed about exactly what they’re agreeing to. Customers, en masse, are stupid, and they often get to this stage before realising they’ve messed up something. The difficulty then is that the request where the web application received the credit card details is different to the one where the customer authorises it to go ahead. This means that the credit card details must persist for at least one request. In the unhappy world of statelessness that is HTTP, that translates as ‘indefinitely’.
To investigate how other software tackles this I’ve come across a startling lack of awareness in open-source shops.
First I looked at Satchmo. Satchmo stores CV2 unencrypted in the database. I couldn’t see any code that deletes it after authorisation. It also stores the card number (PAN) encrypted symmetrically with a key from the settings file. This is incredibly naïve! A compromised server would compromise the card information for the entire order history.
Then I looked at osCommerce. Unbelieveably, osCommerce appears to return the CV2 to the customer… in the address bar! Where it will be stored in the browser’s unencrypted history for maybe 90 days.
These are the technical options as I’ve thought of so far:
- Send a PreAuth request to the gateway when you have the details and a PostAuth when they confirm. I had thought this was the unequivocally correct way - now I’m not sure. A PreAuth request isn’t an uncommitted payment authorization: funds are reserved on the card when the PreAuth is requested. Moreover, if there is an error on the confirm page that affects the amount to be billed, you need to re-request the card details. In essence, a PreAuth is a more binding transaction than the customer feels they have entered into at this stage.
- Encrypt the card details with symmetric encryption and send them back to the browser in a hidden field. This is quite elegant, in that it remove the specific problem the PCI DSS is trying to tackle: that a compromised server potentially compromises all credit card details held. It’s still encrypted storage, though in this form it may well fall under encrypted transfer. It’s permissable to transfer CV2s as necessary, provided there’s strong encryption.
- Encrypt the card details with symmetric encryption as above but keep the encrypted blob and give the user the key. The cryptographic strength of this protocol is only as good as the previous if the keys are cryptographically random, but it is what the PCI DSS mandates you don’t do, assuming the strictest intepretation of the standard.
- Only request the CV2 on the confirm page. This could seem quite natural, if expressed as “Please enter your CV2 number for this card to confirm the transaction”. It doesn’t really help secure the other card details.
- Don’t show a confirm page, or at least combine the confirm page with the form to submit credit card details, and add a big red button saying “Place this order”.
Given these the only option that I am personally happy with is 2 so that is what I intend to implement. I don’t like the PCI DSS, incidentally. I don’t like global financial companies mandating what the little people must do to protect their profits. I don’t like the way it’s written - describing what you mustn’t do without offering it’s view of approved methodologies. I think it’s paranoid about network security, it overstates the benefit of firewalls, and it’s not comprehensive enough about application security. But I like security and I’m tolerant of this PCI DSS for that reason.
I’d very much like to hear if anyone has a better solution or a different opinion.
Posted in Open-source, e-Commerce | 2 Comments »
February 17th, 2008
When in 1981 Steve Jobs said that “Rectangles with rounded corners are everywhere” he began a trend which today sees dozens of rounded rectangles on millions of PC screens almost all the time.
On the web the situation is even more desperate. Bound by the available technology, and aiming towards intuitive and usable HCI, designers often draw on rounded rectangles to make functional layouts appear more friendly and personal. More than that, using rounded rectangles is perhaps the simplest way to design a site that isn’t just boxy and dull.
In CSS, there are two well-known approaches. The fluid-width approach is to stick small graphics of rounded corners into each corner of a box - these cover up the box’s corners and make it appear round. The fixed-width approach is to have top and bottom images that comprise the corners, and a tiling background to blend between the two. CSS3 offers an improved background model that will render these hacks unnecessary.

Of course, it’s not necessary to stick to plain rectangles: using the above approaches, it’s possible to decorate them with drop shadows, highlights, stripes, cutouts or whatever else you’d like to. These aren’t just techniques for cutting corners - they generalise to techniques for decorating web-based boxes.
There are some caveats with nested rounded rectangles that you should watch out for. This is how nested boxes with rounded corners should appear.

The arcs for all the nested rounded boxes that share a corner should be arcs of concentric circles. In practice, this just means tweak the radii until they look right - so that they appear to focus on a point. Any square boxes should fall inside that focus.
Notice in the diagram below how square corners don’t work unless they are inside the focus. Nesting rounded boxes inside square boxes is an absolute don’t. A more common mistake is to use the same corner radius for an outer rounded rectangle as for a nested one. Most tools preserve the setting for corner radius, and that’s not what you want. Notice how the outer box appears proud in the diagram below, right (cf. above, left)

Notice below how when the boxes don’t share a corner, you can use the same corner radius, but the effect is slightly different. Using the above rule-of-thumb throughout will keep the design a little more down-to-earth.

Posted in Tips, Web Design | No Comments »
February 12th, 2008
I’ve just been reading the latest goss on Acid3 and I’ve come across the most wonderfully perverse announcement from Microsoft (this is a few weeks old, but it’s not like I regularly read Microsoft blags).
Since announcing that IE8’s renderer can pass Acid2, it transpires that they have a Catch-22:
To have IE8 conform to standards, you have to use a non-standard workaround.
Wow. I’d assumed Microsoft knew what standards were but couldn’t seem to achieve compliance. Not so! Turns out they can achieve compliance but they don’t know what web standards are!
Posted in Browsers, Web Standards | No Comments »
February 11th, 2008
On a couple of websites I’ve noticed an unusual style of side tab which oddly doesn’t seem to conform to the “tab” metaphor and which I find oddly baffling to use:

Jakob Nielsen offers 13 design guidelines for tabs but this is not covered. Not only does the the shape fail to convey these are tabs, the rounded corners appear to emphasise the deselected tabs over the selected one. It’s as if the selected tab is cut out from the set. Only a very slight change to the shape or shading would make these apparently negative tabs pop out, and usability would return.
Posted in Bad Web Design | No Comments »
February 6th, 2008
I have been increasingly drawn into the world of blogging over the past few years. It is sometimes claimed that the blogosphere represents an information publishing revolution, and I wouldn’t disagree. Blogs are, in their simplest terms, a simplified content management system that has very simple and clear semantics and a very low barrier to entry. I sell customised blogs to my clients on exactly that basis. They are the cheapest websites we can offer.
Blogs are a trade off. Blogs make publishing easy, but the value of the collected content doesn’t increase as fast the quantity of posts increases, not in a single blog nor in the blogosphere as a whole. The archives of the blogosphere are hard to navigate. Where information can be found it may be wrapped up in reams of prose or buried way down in the comments. Most of the value of a blog lies in the most recent posts - the ones advertised at the top of the first page and the RSS feed. This, of course, is perfectly suited to news.
One comparison I could draw is with wikis. Wikis offer collaborative editing and this tends to increase the quality of the content as a whole (if the rate of improvement outpaces the rate of vandalism). Wikis are as a whole more up-to-date than blogs too, because old articles linger indefinitely in the archives of blogs, whereas wiki pages are replaced in situ. Personally I find a single wiki - Wikipedia - more useful than the entire blogosphere. It’s a very complex comparison to draw and an endlessly debatable one, but wikis offer a model which allows discussion or documentation of topics which are deeply interwoven - which is almost everything. Blogs mediate the actual mechanics of a single discussion better.
For professional publishing, we should try to identify and capitalise on the benefits of both of these models. It’s very tempting for me just to tack a blog onto a finished website so there is a channel for the owners to communicate with users, but lots of professional sites end up fronted by a rather dull blog, filled with unedifying news and other tidbits the authors think might engender some interest or at least turn up in search results. Instead, the heavily hyperlinked nature of a wiki could allow visitors to click from this sequential news to in-depth information, and collaborative editing (internally not publically, of course) could increase the quality of the content they find better than a shallow hierarchy of authors and editors.
I’d be interested to know if there’s an advantage to releasing content in “issues” like a magazine. I wonder in particular if visitors can get more engaged in a site when it complete refreshes once a week than when there’s a slow but steady drip of articles. Not a great proportion of sites do this although I can think of a few (The Onion, Linux Gazette). By publishing in issues your RSS feed becomes an invitation, not a medium in itself, an approach which would partly quench my long-standing gripes about RSS. But spending a fortnight writing and editing articles could be much more valuable than a constant drip of articles. But above all it could allow time to create unique and engaging graphic design for dynamic content, a holy grail for the web industry, and something I’ll talk about another time.
Posted in Blogging, Content Management | No Comments »
January 25th, 2008
One of the most common things to store in a database are details of people, be they users, contacts, or third parties you record details for. People are also far and away the most common source of mistakes in the design of relational database schemas and applications. Here are some pitfalls with handling names.
- First name, last name - Japanese people, amongst many others, disagree with the West on this ordering.
- Christian name - I’m not a Christian.
- Title as an enumeration - do you limit the choices of prefix titles people use? Have you included Dr., Sir, Prof., Prof. Sir, Rt. Hon., Cllr., Mayor, Cpt., Cmdr., M., Mme., Mlle., Sheik, Pope, HRH, President etc? Do you think you can compile an exhaustive list?
- Are two names required? Sting, Lulu, Bono, Pocahontas, Countess of Wessex.
- Guessing initialisms - If you’ve asked for my full name, don’t assume you can address me as Daniel J. Pope or D. Pope. I very rarely use these forms. Joanne Kathleen Rowling is usually announced as J. K. Rowling. Similarly, I’d always initial myself DJP and never DP.
- Many US Americans (sadly lacking maps) require their generation after their surname for disambiguation. But you can’t turn John Davis III into Davis III, John. You would write Davis, John or possible Davis, John III.
- Don’t force Title Case - Mohammed al Fayed, Manfred von Karma, John Davis III and so on shouldn’t be put into title case.
- “Abdhul” is not an informal way to address an Arab whose name begins with Abdhul ie. the first word of a given name is not necessarily an informal name.
- Have you stored aliases? Should your database be able to record the fact that Thomas C. Mapother IV is also Tom “Only scientologists can save the world” Cruise?
- I happen to have a peculiarity with my names. I am not called “Dan Pope”. Dan is slightly diminuitive but “Pope” is slightly formal, and the combination shouldn’t be used. People have often assumed they may refer to me this way and they are wrong. To confuse issues, in recent years I sometimes sign e-mails this way because I’ve found it’s a good fit for the formality of the medium. But different criteria apply in the second or third person.
Names are a very individual thing and people feel strongly about how they should be addressed. How you index or sort names is your business and doesn’t influence how people wish to be addressed. If you’re indexing by surname, be aware that not everybody will identify themselves to you by the same surname you have indexed. If you’re sorting, you should perhaps be aware that individuals’ native collations may differ.
The tip, then, is this: store the forms of address you wish to use. Do not assume you can correctly derive other forms.
These are the variants I use:
Full Title: Daniel James Pope MA (Cantab.)
Full Name: Daniel James Pope
Name: Daniel Pope
Formal Name: Mr. Pope
Postal Name: Mr. Daniel Pope
Initials: DJP
Vocative: Daniel
Familiar Vocative: Dan
Nickname: Mauve
Preferred Username: mauve
Posted in Tips | 1 Comment »
January 20th, 2008
The application/javascript MIME type has stopped working in my copies of Internet Explorer (6 and 7). Both now silently ignore scripts linked with type="application/javascript", which is as far as I have since determined the behaviour most people experience. Indeed I’ve only found very sketchy reports of it working at all.
Because I had no idea I was unique in being able to experience scripts linked in the RFC-compliant and IANA-approved way, I have used this MIME type on quite a few sites. So it’s good news, because I would never have spotted this otherwise. Happily, most of these sites are not yet deployed, and the rest only use Javascript for very trivial polish. There now begins a hunt to replace application/javascript with text/javascript on all my sites.
Obviously, I’m at a loss to explain why Microsoft has failed to offer a consistent platform for development and I feel quite aggrieved about it. If I hadn’t already boycotted Internet Explorer this would be a pretty good reason to start.
On the assumption that some other piece of software has by accident or design disabled - or had previously enabled - application/javascript, this is my list of candidates:
- Microsoft Outlook 2007, installed for the first time on this computer this week.
- Word 2007, also installed this week for the first time.
- Some random Windows update I installed last weekend.
- Access 2007, installed two weeks ago (but I think I would have noticed sooner if that had caused this change).
- Removing something malicious with Spybot. I think it removed one or two dubious registry entries left over from an infection of Vundo/VirtuMonde last year, so it’s unlikely but there’s an outside chance of an effect.
Posted in Browsers | No Comments »
January 18th, 2008
Bullet lists are a wonderful way of formatting both because they convey structure and because they serve to visually break up otherwise impenetrable paragraphs of prose.
It’s possible to use a custom image for these bullets, by way of the CSS list-style-image property. This is a great way to carry your site’s theme through into the content.
If you can’t be bothered to draw custom images, you can at least make your bullets agree with the font using the list-style-type. With sans-serif fonts, square bullets usually look more professional. If you are using serif fonts - and this is a bad idea incidentally, because they aren’t as legible on a screen - use circle or disc (ie. unfilled circular) bullets.
Posted in CSS, Tips | No Comments »
January 13th, 2008
Inkscape 0.46 is drawing close. There’s a whole wealth of new features, some of which are incredibly exciting. I’ve not been using the SVN version since I replaced my desktop machine 5 months ago, so I’m only now discovering what these new features will let me achieve. It’s a process of discovering not so much how each tool works, but identifing useful little ways of combining features.
To whet your appetite, here’s a two-minute doodle demonstrating a turbulent displacement filter.

Update: here’s a more realistic style using a specular lighting filter.

Posted in Artwork | No Comments »
January 11th, 2008
In contemporary web browsers, favicons are prominently displayed in the browser’s UI. As such they have become an integral aspect of creating a site that looks professional. More importantly, they allow users to identify a website from a host of tabs or bookmarks. Alas only a third of web pages (based only on my bookmarks list, admittedly) offer a favicon.
What your favicon looks like is less relevant than having something distinctive. Favicons should trigger recognition, and need not stand up to examination.
Posted in Tips | No Comments »