Sequential page numbering in LaTeX

Did you ever notice that the page number that your PDF reader gave you was not the same as the page number printed at the bottom of the page? By default, some LaTeX commands, such as \tableofcontents, reset the page number to 1.

I don't like this behaviour. I just want my cover page to be numbered 1, the next to be numbered 2, etcetera. This way, the ‘physical’ and ‘virtual’ page numbers line up nicely. It also prevents some problems with hyperref, which will otherwise create duplicate page labels.

You can get sequential page numbering by putting the following snippet in your document preamble:

\let\oldsetcounter=\setcounter
\renewcommand\setcounter[2]{%
    \def\arg{#1}\def\pg{page}%
    \ifx\arg\pg\else\oldsetcounter{#1}{#2}\fi}

This simply overrides \setcounter, such that it ignores any attempt to set the page counter, which holds the current page number. Ugly, but it works.

Verified by Visa – verily?

Today I ran into an excellent example of false security – with horrible usability to boot. I was helping my landlady to purchase a laptop online using a Visa card. At the checkout step, a screen appeared that we did not understand. It came from Visa itself and asked for the password associated with the credit card.

The password form was in an IFRAME, so the address bar did not light up green. I did not bother to check the security certificate by hand, or else I might not have dared to continue at all.

But we did read the FAQ that was linked to. As it turned out, this “optional” ‘Verified by Visa’ system makes online purchases more secure. It did not seem at all optional. Well, only more secure then. Right?

Wrong. How exactly does one get a Verified by Visa password? Let's click the “forgot your password” button and find out. To reset the password, you need to specify:

• the 3-digit card validation code
• your name, as written on the card
• the card expiry date
• the year and month of your birth

The first three of these four pieces of information are written on your credit card, and also submitted in any web form that involves a credit card purchase. By assumption, an attacker already has this information, or else the extra password protection wouldn't serve any purpose. So the only extra piece of information that is asked for is your birth year and month. Not exactly information that is hard to find, or even to brute-force if you put your mind to it. They might as well have skipped the password and asked for your birth date instead.

But well, it doesn't make you any less secure, so we continued to set up a password. First attempt failed: “use letters and numbers only”. Because, you know, secure passwords do not involve special characters at all. Second attempt: “please use both letters and numbers”. If you're going to use stupid limitations, at least tell me beforehand. Third attempt: “please use between 8 and 12 characters”. By now it seemed more like a CAPTCHA to me.

Then, finally, the password was accepted and we could proceed… to the next error message. Turns out that NoScript blocked the transaction, even with Javascript turned on. If NoScript does that to you, it probably means that you're doing something very, very wrong. But finally, after convincing NoScript that it was okay, the payment got through.

Stupidity can, in rare cases, be forgiven. But not if you're the largest credit card issuer in the world.