The below is quoted from the above linked page... ... I realised that you can do something with Firefox 2.0.x that you could not do with Firefox 1.5.x: track an unsuspecting user using TLS client certificates. Here is how it works: - The user visits a websites and leaves behind some personal data (for example on a registration form). - The website uses SPKAC using the <keygen> tag to create a private key for the user. This will pop up a dialog that says: "Key generation in progress ... This may take a few minutes ... Please wait ..." With a 1024 bit key on a modern machines, this only takes a few seconds, so it is barely noticable to the user. - Using the SPKAC data, the website creates a TLS client certificate for the user (which may contain just a unique identifier for the user and/or the personal data entered) and sends it to the user using the "application/x-x509-user-cert" MIME-type. Firefox will automatically install the certificate and pop up a dialog that says: "Your personal certificate has been installed. You should keep a backup copy of this certificate." This dialog may need some social engineering from the website to keep the user unsuspecting. But who has actually heard of a "personal certificate" except for the more technical users? One could even explain to the user what it really is without the user knowing that it will mean trouble for him. - Because Firefox's standard configuration is to automatically choose a TLS client certificate to be sent out, the certificate including the personal data will now be sent out to any website that requests it. Contrary to a typical cookie, this includes websites that are on a completely different domain. The user will not notice this at all. Caveats: - The user has to have saved a password in his password safe before. Otherwise, Firefox will ask the user to choose a password for the "software security device" during the SPKAC key generation. What other browsers do: - Firefox 1.5: Does not allow you to install a client certificate that is from a CA which you don't trust. I still believe this was a decent default setting. - Opera: During the key generation, it asks for "a master password to protect your client certificates in Opera". Note the wording, which is IMHO much more clear than the password for a "software security device". During installation, it asks whether you want to install the certificate and pops up another dialog "Are you sure you want to trust this issuer?". Before connecting via HTTPS, it pops up a dialog that says "The server requested a certificate. Please select one of these certificates or press [Cancel] to send none" and then requests the master password. - IE: Does not use SPKAC, but has a similar mechanism using the XEnroll control. With the default security settings, both requesting a certificate and installing one pop up confirmation dialogs explaining the situation and having a default of 'No'. Not that it does not have problems with certificates, though. Has anyone else ever noticed that if you have have more than a certain number of DNS subject alternative names, the certificate chain validation just breaks? This is actually a productive problem at $CUSTOMER, where they have a large webserver which has somewhere around 50 virtual hosts ... - Safari: Does not say a peep during the SPKAC request generation. Allows for 512 bit keys, btw - whoever would want a 512 bit key these days? I could not find the correct MIME type to send the certificate for installation (I'd be interested to know though if anyone has an idea), but I'd assume the installation uses keychain (at least under Mac OS X, no idea what they do on Windows), which hopefully does some prompting. - Konqueror: Pops up a 'KDE Certificate Request' wizard during SPKAC key generation which will ask for a password for the private key. I could not test this any further though, because my Konqueror installation did not create the request. Apparently, it sends 'deadbeef' though if it can now create correct SPKAC data ... :-) Allows for 512 bit keys, too.