From Accessibility to Zope

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

Look, an actual website which uses Swatch Internet time! If you haven’t heard of Swatch Internet Time, it was Swatch’s bizarre marketing ploy from 1998 to unify time on the Internet by promoting a time system which was baffling to everyone the world over equally. With an @-sign so that everyone know’s it’s all Internet-y.  A sensible approach to i18n for time is included in the HTML5/Web Apps 1.0 draft. I’ll talk more about this spec soon.

In other news,  my desktop box has a dmesg entry stating that it inserted a leap second last night. Leap seconds are the extra seconds that get wedged in on the occasional 30th of June or 31st of December to correct UTC for the gravitational deceleration of the Earth. However, there was no leap second scheduled for last night. I have investigated a little bit but not deduced the cause. Apparently leap seconds are configured by ntpd using the kernel linux/timex.h API. NTP servers pass out announcements about leap seconds. Either my kernel or ntpd has its knickers in a twist or a low-stratum NTP server I’ve trusted has erroneously issued a leap second. Obviously this is pretty much immaterial but for some reason it really frustrates me.

I find Facebook very annoying. I can’t seem to make it do anything useful. It seems to get certain, key things stunningly wrong, assumptions which are disingenuous in my case and make it seem broken. I can’t find any friends on it and I’m getting bombarded by junk which isn’t applicable to me. I can’t find options to do many of the things which I’m sure are possible.

However, I’m impressed with what Facebook is supposed to do. It’s far and away the closest of the social networking sites to what Mauvespace aims to do. That in itself is interesting. I didn’t invent very many of the concepts regarding what Mauvespace can do: many of the suggestions about the combined expressibility of RDF vocabularies come from the web. However, it occurs to me that a fair number of those might have been inspired by Facebook or others, and Mauvespace merely inherits those suggestions (albeit mostly unimplemented as yet).

Specifically, things like annotating not only pictures as depicting a person, but regions of pictures, are things that I’ve read specifically about in comments describing RDF ontologies. I’m surprised Facebook isn’t semantic.

Still, several key factors differentiate Mauvespace as a social network even if it could do everything Facebook can (and the eventual plan is certainly to implement some of those things):

• It’s open source.
• It’s entirely themable.
• It’s semantic.
• It’s distributed and interoperable (as a result of being semantic).

Not all of these will matter to all people. Many people I’ve spoken to simply say “I’m interested, but only because I tried x and didn’t like it.” But regardless of what matters to other people, these things are exactly the most important things to me personally:

• I can make it work the way I want it to (as can anyone else).
• I can make it look as pretty as I like without resort to hackery (as can anyone else).
• I can use whatever data users make available in any way I see fit.
• No for-profit organisation controls my data, forces me to use their system to talk to my friends, forces my friends to use their system to talk to me, requires me to pay them money or requires me to view their ads.

I don’t think any proprietary social networking site could ever meet these requirements. That is why Mauvespace exists. Or very soon will.

The past couple of days have been spent tidying up my accounts in GnuCash. It’s great when it all comes together and your accounts reconcile perfectly with your statements.

I like GnuCash a lot actually. It’s slightly harder to get your head around than just listing your accounts in a spreadsheet, but much more powerful when it’s done. Because money always has to go from somewhere, to somewhere, you can view transactions from both ends immediately. So every time I pay for a domain name on card, I see the money transfer from my credit card, with the net cost going to the registrar, and the VAT value going to my VAT account and reducing my debt to the VAT man. And then I can turn it round and see the actual cost to me of the domains, or track my VAT debt.

The other neat thing is that accounts are nested, so for example, I can create an account for each client within Accounts Payable, and see how much each client owes, plus clients’ debts to me can be included within my assets. GnuCash’s own customer invoice tools don’t do use subaccounts though, which makes them actually harder to work with than doing it manually, I find.

At first I found GnuCash kind of quirky, and I did struggle with it. But the new 2.0 series is better on the UI front (now a GTK2 app) and now I know what I’m doing with it, it’s actually quite easy to get everything to work and incredibly useful when it does. It becomes quite frustrating that all the other accounting information I receive is in a simple flat transaction list, like a spreadsheet or a bank statement or some printed accounts. It’s not wrong; there may be no other way to do it; but it’s simply not so elegant and right.

All I need is some way to get the accounts data to my accountant.

I tried a few different ways:

• Linux VM with GnuCash and accounts, burned to a CD along with VMware player. Couldn’t get Ubuntu VM to fit on a CD; Debian and Damn Small Linux wouldn’t install properly.
• Converting to QIF with a Java tool. Tried importing this into Grisbi and it looked a mess.
• Importing GnuCash directly into Grisbi (with the intention of exporting to QIF or CSV or something). Seemed to make a mess of it, not as much as the Java exporter, but the account balances were all wrong.
• Transforming to Gnumeric sheet with an XSL stylesheet and sabcmd. No account balances, but these can be added quite easily within the spreadsheet app. Required me to install Gnumeric.

I sent the QIF and the spreadsheet (saved as XLS) to the accountant. Other ways that occurred to me:

• Hand them an Ubuntu CD and my GnuCash files. This would require them to reboot into Ubuntu and GnuCash isn’t even included on the CD anyway.
• Hand them an Ubuntu CD, an empty VMware VM and my accounts, and let them install everything. Probably too technical and overkill.
• Set up a VNC server that they can log into to access a copy of GnuCash. Security aside, I don’t know what kind of connection they have. It could either be too slow for them or it could DoS my outbound connection.

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.

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.