Application Secrets vs. Key Pairs

I was just reading about the new Google Storage API for US developers and I am wondering why we see application secrets so often?

Google is generating an application-id / "access key" and up to five application secrets for different projects a developer is working on. Fine. The developer has to sign each request to the storage API.
http://code.google.com/apis/storage/docs/getting-started.html#keys

I assume that Google might even generate code snippets for a given pair of access key and application secret to sign requests to make things really easy for the developer.

Does nobody fear that Google admins might misuse the developer credentials?
Does nobody fear that Google's database of developer credentials might be breached one day?

What is so hard in using key pairs for developers? I know that some people faint when you use the three letter word "RSA" or "DSA" or whatever smells like asymmetric crypto. But if I have to sign a request anyway then where is the difference between symmetric and asymmetric? Is performance really still an issue? gmail is now SSL which is good. So here security finally won.

Generating a keypair is really simple and using it to sign bytes is as simple as using a symmetric key. Yes you have to protect the private key but not more than you have to protect the symmetric key.

It is harder to autogenerate code snippets because the generator does not know the private key or how to access it. But is this the point?

With asymmetric crypto there is no database of keys that can be stolen because the private key is not on a central system. And the developer credentials can not abused by Google operators which is good for audits and Google's liability.

So why are symmetric keys so ubiquitous? They are nothing than passwords and share some of the problems passwords have.

oauth 2.0 scope is the new black

David's openid connect proposal uses oauth2.0 to get an access token to access the user's info API.
Openid connect does not define a new flow for oauth but uses a scope with value "openid" to signify that this kind of access token is requested.

What I am missing here is that there is no way for the client to specify which of the user's information it wants to access. The users might choose to release only a subset of their information at oauth-approval-time but they have no way to know what the client is requesting. I fear that the authorization server suggests to give away all user data and that the user will grant that access.

A quote from the openid connect proposal: "The (user info) server is free to add additional data to this response (such as Portable Contacts) so long as they do not change the reserved OpenID Connect keys."

This is the Facebook notion of privacy to give everything away by default.
I don't like that.

Even if the client does not want the data it now has access to it.

I am intentionally not suggesting a different proposal or new values for scope. But what I am thinking about here is probably obvious given the background I am coming from.

XAuth is Evil

Google and Meebo got it so wrong! Meebo with support by Google published a javascript xauth.js that tells a website which social networks the user is a member of. Information is stored on xauth.org and in local storage what my social networks are.

This is so wrong that it hurts. Sites should publish which social networks they support and the user should then choose which ONE they would like to use at THIS site at THIS time.
The xauth scheme just transports too much data to a central site too often.

Google should use its money and power to put this ability into the browser!
Start with Chrome and Mozilla (https://mozillalabs.com/conceptseries/identity/social-agent/). Yes, Google already supports Mozilla in this project but xauth is evil.

XAuth is not even acceptable as an intermediate "solution" before Identity in the browser is ready. Wrong, wrong, wrong.

I admit that website operators prefer it this way round and the collected data at the central server is definitely interesting and valuable. I think Google with good reason does not store that data on a Google server or do they? Who has access to that data? XAuth is not as bad as Microsoft Passport but not much better.
I fear that the user and privacy advocates are not strong enough to create "Identity in the browser"...

Don't do evil.

SHA256 et al in openinfocard

I just added support for RSA-SHA256 etc to openinfocard's signature validation.
This came up during the RSA conference' OASIS IMI interop. The cards issued by ADFS2 are signed using RSA-SHA256. The team from the Government of British Columbia suggested to configure ADFS2 to use SHA1 for card signing but this way is better. Openinfocard is now more flexible in regard to signing algorithms. I added all DSA and RSA algorithms from http://www.w3.org/TR/2010/WD-xmlsec-algorithms-20100316/

Enjoy.

Comments-Policy

I will delete comments to blog posts on this blog written in a language that I can not read or understand.
I disabled comments on the last blog post because it seems to draw unwanted attraction.

Identitymanagement and Sex

I learned something this morning. There is an ISO norm (ISO-5218:2004) that defines the representation of human sexes in IT systems "Codes for the
representation of human sexes". Probably there is an ISO norm for everything?

The actual representation looks similar to what is defined in the OASIS Identity Metasystem Interoperability standard.

0 - Not known
1 - Male
2 - Female
9 - Not applicable

IMI does not reference ISO-5218:2004 and "0 - Not known" is something different than "0 - unspecific". I guess the authors of the IMI spec do not know the ISO norm. Or is this due to the English differentiation of "sex" and "gender"? The ISO norm defines "sexes" and the IMI standard defines "Gender".
Interesting is the sheer number of "standards" to represent gender/sex.
http://de.wikipedia.org/wiki/Datenstandards_zur_Beschreibung_des_Geschlechts
(I have not found this in the English version of Wikipedia; Sorry.)
I find it interesting too that "transgender male" and "transgender female" do not exist in many standards. Although it may be inappropriate or even illegal to store the transgender information in a database but this is not the issue. Somebody might want to prove that he was formerly a she. It is better to have a representation in a norm/standard for all cases. The legal issues are outside the standard. ("legal" is always a path to headache for me e.g. http://de.wikipedia.org/wiki/Transsexuellengesetz)
OASIS should always check that new OASIS standards might be aligned to older existing standards.
I think the "gender" section of the IMI standard should be revised.

Firefox Personas and openinfocard

If you have personalized your Firefox with Personas then your openinfocard selector window now shows the same background image.


Which is nice and a security feature too. A malicious website could try to create a window that looks like your favorite openinfocard selector but the website does not know how you personalized your browser. So if your card selector window does not show the same background image as your browser then something is phishy!

Get the current (xmldap-0.9.9.201002251149.xpi) version of openinfocard now!

Did I say that openinfocard runs on MacOS Snowleopard too?

Openinfocard openid login @ plaxo

When I referred to Mike's post about the Microsoft OpenID selector I was reminded to try this at the same site (Plaxo) as Mike. Here we go...

First I identified a small issue with openinfocard: The code matches the issuers now case-insensitive. Plaxo asks for "Yahoo.com" while my card says "me.yahoo.com".
So you need the latest version of openinfocard to try this "at home".
http://openinfocard.googlecode.com/files/xmldap-0.9.9.201002231732.xpi

Please install this into Firefox3 and browse to https://www.plaxo.com/signin?test.selector=1

Now click the "Sign in with OpenID" link to start the selector.

After selecting a card click "Send" to start openid discovery.

Yahoo! login and confirmation

Now I am logged in at Plaxo!

Nice!

openinfocard OpenID Selector

Last autumn Microsoft demoed an OpenID selector at the OpenID summit hosted by Yahoo.
Now - finally - I found some time to add this to openinfocard.

If you have Firefox3 and Java6u12 installed then you have everything you need for this. On a Mac you need Snow Leopard to have java6. Thanks to JohnB and Pam for trying openinfocard on a Mac.

Now install the openinfocard addon into Firefox by e.g. clicking on http://openinfocard.googlecode.com/files/xmldap-0.9.9.201002121109.xpi.

Browse to https://test-id.org/XP/Selector.aspx

Clicking the button starts the Selector.

My Yahoo openid card is shown on a green background because I have visited the openid consumer (test-id.org) before and I have used this card there before.
Clicking the card image selects the card.

and you can now press "Send" to start the openid dance.
Discovery and Check Immediate are performed:


A "setup needed" is received and the Selector closes and we continue in the main browser window.


The final window: "You passed the test".

interop.ca.com for RSA 2010

A quick visit of the openinfocard card selector to CA's interop site for RSA 2010.

Hm, clicking the purple-i does ... nothing; but clicking the link next to it does the job.

Now clicking the purple-i - either on the page or on the URL-bar or on the status-bar - starts the selector.

Please note the card with the name "sechs" has a green background because I used it at this site before. Noteworthy too: The selector shows Verisign's issuer logo of CA's SSL certificate.

Please update your openinfocard selector to the latest version before trying this interop.

Microsoft Update Certificate Woes

When I choose "Start -> Microsoft Update" on my Windows system IE starts and shows http://update.microsoft.com/microsoftupdate/v6/default.aspx?ln=de .
Security paranoid as I am I have HTTPS://update.microsoft.com/microsoftupdate/v6/default.aspx?ln=de in my list of "trusted" sites but not the HTTP-site. I am willing to pay the price to have to add the "s" after "http" every time. No problem.

What annoys me is that since some time ago the certificate is issued to "www.update.microsoft.com" but not for "update.microsoft.com".
I admit that maybe I am not supposed to visit this site because I edited the URL by hand but come on Microsoft: Please buy another certificate or configure the server to redirect me to the one and only with the correct certificate. (This prepending "www" to every webserver is stupid anyway. Leave that to the companies that are 90% marketing and 10% feature)

All OS-updates should be over HTTPS anyway. CPUs are cheap! Buy some more if the encryption is a performance issue. I want that extra SSL security.

Cardspace Support for Firefox

During the last week I released new versions of the Mozilla Firefox addon that adds Cardspace support to the browser.

One feature that was reenabled was the ability to get the "value" of the object element using javascript. The value is the security token and thus requesting the value starts the selector. This "feature" was lost in the past and was quite easy to reactivate.

Another change that envolved code changes in many places was the elemination of global variables. Which is a good thing. All global variables were moved into a new namespace org.openinfocard.cs4ff. I hope that this change gets this addon out of the sandbox and it will become an addon that can be installed without the "let me install this" checkbox.

To bad that the Information Card addons are not compatible with each other. You have to make your choice whether you install DigitalMe, Openinfocard, Azigo's selector or Cardspace4Firefox. Or other addons based on the same code base.
Which on the other hand is no problem in the real world. Users will pick their selector and install just one.

Avoco RealPay etc

In case you have not done so please have a look at Avoco's Information Card work.

One of their demo sites is a site called RealPay. Here you see the current openinfocard selector at work:





But the above is only the "normal" Information Card scenario.
Much more interesting are their "cloud selector" and their Cardspace based document signing product. The latter can sign Microsoft Office documents and PDFs and if you try to open that document you have to present a valid security token based on an Information Card which might be restricting your access even to your current location. Nice.
Read more here.

selector progress

I am making good progress with the selector that supports Information Cards and OpenID (Cards). Maybe it will support username/password too.

Please notice the purple-i in the urlbar left of the site identity icon. Clicking it starts the selector which lets you login using your e.g. OpenID (Card). It "works" with the xmldap.org test page and it nearly works with Andrew Anortt's http://test-id.org/XP/Selector.aspx page. Markus Sabadello's testpage https://openidpad.com/ needs a little more work. The next step is to remember the cards used and display that/them in the urlbar.

I would like to mention that "login" or "connect" (to a site) is not enough. I think that attributes or claims are more important than login.

Sometime not too far in the future we should agree on a standard for this. I prefer the XRDS way to conway the RP's requirements to the selector and we can inline it into the HTML code if a download of the XRDS is not desirable...

New Version of "Cardspace for Firefox" addon

Well, this took quite some time.

Several people reported that there were issues with the IdentitySelector from the Codeplex repository (sometimes called Cardspace for Firefox) on Windows Vista while Windows XP worked. But now, finally, I was able to build a new version on Windows 7 using the Mozilla build system as described here. I tested it with Firefox 3.5.5 and it seems to do what is expected. Although I did not test it on Vista. Please report issues by using the Codeplex issue tracker.

Following are some screen shots from my tests:





The Cardspace version used was 3.0.0.0 as it come with Windows 7.

There is still much work to do like bringing this addon's code to the same maturity of the openinfocard selector.
And keeping it there e.g. by improving the XRDS support.

Later support the OpenID Selector...
And integrate with the work at Mozilla Labs like the "AccountManager"...
Not to forget the design work in the Kantara Universal Login Experience working group...

Dancing Elfs

Send your own ElfYourself eCards

Trust in Crypto

Some people fear that an encrypted token send through an untrusted operating system is not safe. Well, decrypt this:

<enc:EncryptedData xmlns:enc="http://www.w3.org/2001/04/xmlenc#" Type="http://www.w3.org/2001/04/xmlenc#Element"><enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" /><ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><enc:EncryptedKey><enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" /></enc:EncryptionMethod><ds:KeyInfo><wsse:SecurityTokenReference xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><wsse:KeyIdentifier ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">cInCP+uDfNbevxLZEMnZG3ozidc=</wsse:KeyIdentifier></wsse:SecurityTokenReference></ds:KeyInfo><enc:CipherData><enc:CipherValue>wu7z3ml5LPdisc1F/o2gWP/I/8lgQNnj5PYoRw/CNe6f1kFtvE7Q4zZiNCrqsAJiY115ztR063siJLFiSsyGi9jRTrRuTD3ZZGrlQHedWFbG519UXk14cT6fqqQ3O8b6jXqhVDWpeRn08vKv+K6FS4wI2wKZNH3BUw169VSjz0otC8HSUz5FG8POGhVL0/kkzYmgfhq75jt84iKt2dLVNQEDHvSYraAUOc4GCuMzd0l2TgSqVQ1dJYC9NC9iTyUv0l6GPV8XApdbK/7oKW4e4aNvhhkoyLDP/U6RxLiH/QPD7EEP0vM58LETTWD+R3tViD/A5UMVlVVzF6MMsdRI0Q==</enc:CipherValue></enc:CipherData></enc:EncryptedKey></ds:KeyInfo><enc:CipherData><enc:CipherValue>n4vumLMhKFzn29uSCktg1jEnzBf9yJcgt+OvYa7r3Vi7eLLyL9uGHy3NDIsaAr0qYF/+AyjwIE8aCk0/qMjFiY+O3j/oQLulbU+RHooQm95cesySRs2PlZ6G5nI1lnMDb9SsSFMhSjl2ZTBV6YWJ69kphS8IbQFjuNcnZBW4ARI0A5WGhj36F2zGXAGnJ7BNvVLJLv8zMT3hsmcJ0ZHA2ggN5RJnPEKT56OJkcgNN0mjhhldt35As2qK7NDumv25WB+3BX1DSCFBGkHCiK5pGjKAXu3tudXFt0+ryvDojdVpmbOwypRXjzgqCBZ8gOLMGoyYFVgXINUY59+mqbhv/mIBaOqbmuVV26tCWPWFkvbzMz1jD3fEcws7nKoc69Ceavl1BKWb5Zq+YYr3voHr7g2ZRvBd6me2YTRx6BNIgj8dbplzlD3Bp4HO13tK0rZXpJH1Z2OXfpUd3ZE0T879WJjDA1qcgUswH8F0ER+UG09P2Z2PgK2McFz4ntwTJOSohhipMU0WFRHQr3s+bLr3c78NFZl8FGGZ9rRm/AMhsHPqKuK/WAqmvtMoYdXPTWw5cP5CysgVIdWO+VymKZ4W7LbtZrZRk9hCya6ANmpkckEBSo03p/psqE5X97A43V6XExjP4cQNdwPZw1b8c4UDJzvFFFL69P3HispobxvdlLqI2nxu2tp9M9eyYQDHtqjSdutYjkyolXkrEKoRGAPOoUsUlxnctHd6RmbA825YNywNMG9sXqxIM8ua1BQoEWfRQauFUYxyGQYywqT0MsbVu1N2HSQsc8Dern6kOl0OLd/Z4n1XZI3bMWMCtNe4DrK2OOeG1RY8DPOn8dW+AL/+T2iqVv2d3dNkRXTvkaEl9UXecBe/G6oqtkjjTdSdZ/20ifi9LFejagAtdIQ+crfH12JKyGs5tPVgDtZfJPoAryHAeyqI+0kUsTTVgsJtE1OU/FAXI2naEVCDH26vZOt9QzaXkTgmRAL8X65BaXczJ365QWi/oURNq/q4zSpo/fkRrspIfh9mefhbyssNsGYWHtQO0GOeNzrCfpdRll5f2w8DdEkH3+u0V4c4otf0pMYkhyw007ig1Y7xgY+e1xFP7/fJ0QMa04XDe+NWdgDhT0NJe23ehPgOPFC0Qa4gC5an9V//u1/svnzjrNyKhjfUVQ7ai+xAi7Pla7Irmpr35vX+FjkPzmFyNnfNqRt3+o9rzLHRS4QYTMK00FccP7cirekRK45ni2yLa1wgHBn674owJTje/ugOYsXCdkZEOUbs6LgOMPjUlxUwQpeLj4uw1ycMRNZGNo7zBDHSMZ18ZRxAuP0J2V1s9KiQBLBsodtZ7fyqVYjKQVSeYj7mDlPM6r/4tC+R8k8pEQpnjvQFqhm/MHfZzoaYfO9523J5s5FXMOhO94XK/VdRayvOHNxaK1NV6k2tEpaPXPa4cSorRXBn81yKItis+u1NbE4SBb5CkuTTQnPNJec2/BQQspwWKfbMAs/sptJel4OaZ6x5svyHgijnYTV373V1EcIPDDNzDH/iJGJv/3hhZs0QNP4hO1zU+8RFphDMclM1YtYzruoROL8JW0jMwDC/UyfhKlWLIUSOS8PFE22UCuXpsnbY5ty/Q8CSaIvhNrOodAC8gRKoLGdyEqFt+tk4Fjbty7biuOBgONF8Uh8XeT9jKlRI3FUc4kpC3Pafeg7Os3LuXcxu8CggrRH73Lh4MJQ1Y7IIRsxDPNuJTBzEvsQJdNzPy/t+LA8cNV9OPat5+LXFhd1TH6zwqYC7i3hSCq9NT9spp15cZ0KZJt7FFd8uYwE9AHmy6Jb8NdbAXruwnGIETiiOYvlehGkMcND0aiwx7KIycYwz9quyOh9vYdc0IGvKaBLfbv7TYC89xSuOBqLiiuW4BOLMXxvrdutRPVy5HqLHlfOzaiq+TbljC+dqjJUw3NpViS5pmiP2culW4ZphNROb1Rp+oJLu1E2F6eGUNGBTSlohK6RD7ZaKVvLxU/PH0WNwXqmUY6215MRjH0+yEeKPNR/iq/KOmI9xwN0GB7Qpao1yS71tLnM/Rg6hjOI9X6ynDsTPRiUK+doeDznOfcysObf8Zpjjlp1eRHYCnp9WJNM3IGg/hd53APMUP+qy3wAmsKmLJ88W0qxUefslynIEKZeriARXpjQj46yDGIXYpe9XNBJAVc88+WCA4mIKlolsbtHZwbMccsfVQKiqLqV21Um50IITpLpPY5v1yRwNMf9A9/n72qrolDm8h38xDWPwyrojWs06bz4XMIQF7/lSR2aRE9L78Lp1i5UafNYe3EgnAReZsYWvCAr8Xm7IXyQmgEXh9en28b1t1ZsKNCyvQRRD5IqzSqBswtITRmbjoBfw2EnYcIp0E8vKGAG5zyxphhXCwfjEoRxKuZ7hDPcfGQb++KbPgIl3Ub6sJTX0QoVjBCAYnXvpKaKOQ9zOYN4MVp+lKMcFw0w4j/8IDC8D8O9ZAQhn2Bj6CPjAtEN6mwv4DqQwndNxx3glkOFVvkLBHkRfTvcQRmBcNjeP4RpQyCqMMgIcIRuQFYfQUXy0QxVVbegZHzeYYhe6A5yp3Oz3M87Nn3j5V5puu3kMUtLKIYl0KjKbrBLX8sqtx/BDhd+BuWiFsedmL0kAmRxuh96SoR1E6EzIrIm8s9xLvGRH45oBs5QA9KoSvm/gE2mcYVoe7baZocsrlkWs+xoZDwDAbmPZi16jbnwXxEWfwTBvKQ8vQisIN24O+gJXi7r0dzoRTqIY104yPJmPdIGh0rdGU4AUxtJNhpLujSpteU82M7kAlVhP4IK0UHIfciJ13C4OX0IH8y8shcu4QvZK4Nw98uIBjY3ybjMB9bqZAO2pZM1lk9sdn590L7iA/vjjJ24wAl2Yz2MhgtUKzTfTRzhnje+E10JHKYph/Z+DWO8Ku4vWEgak6m9flfXwrFPkSENTTNHXVKTnvFrdvJtfYAcympLg/tJXmQlrT+kQl2o/jbIcePi6HbtR+YtYWpckkfvU/cvcqWMuiJNHi3ST8vvVoGrypq7aY6MnJPqNTVD1yc3q2ZQxfreevKRktHm8gwGIjyuL7mUOkF4r0dQgWmcpQhS2Ozil5NkVtLdxJmcWeFxv3GZ4Tta2NXIEQexdgjUnAGRQH/CAF/Xi/9fjoM4puZTdlxdx4QRps1Y4DBQ6oCnI67sUdQGtcx7LwCVrLFJc0gKtnVtmEVvYDKPv1E4eIvyPz/6+fjHcYePYmKxPa6dV50g9E6K0832osbdV9klbDsx9AE0B2qkI0akEBuP978Wl5tIUDqC0kMNMp1wt2WTLx7KOrwLQVVUyFx167BGaduxIm/QAj5Jht6tVaAuCrhU3u6qzxZ7GQHtPe9pJCAtEOGNx68TGgaQynIdA0dS2G85XtYAHXI+Yt1D6eoQbQ04sMGiKfdm2E5QRy7lS/lNSQaf3+kNCiTEHmHeaTy4zCpMWvDDaAqtQbM5JNMxa4mkr0mmxOoykIS8CuSkat8+QIzROFEsIc+66qQC4yAJ0bKssZ0tyQ3BQC3D3hAGZoUsg8pUTNcR/i/hT0x5AMCgaU9EMkFFOhFQoVdcUti3tpUSLtpjVheuG5pAHIlGasfnh4iYexWQeF4DDoJRCFUVprFY7VJy4AAvT8qM+3XnraTKbLDncKEx14TDELnXdNgRDYkqt/XKgZ/Y2hNM0zonZHsp/lz8+ISfKJR5LRTjX2Xg+2loHKBIm6ysJ2ukEodwafMhJxPD7KSjJi/qW06WzCG3K1o4D/Q4B6ABjbGY7HXvn+yhz9EdWWECHfN+i2x/Jdh15wRsuS0hRGD0RL7O//mjHtGzJN0w1KqLYJvglUlEVVUtXqKwk/L0NLMW3T8n84kA/LEXL9a1NgQDlpBoP3ZOXqpzFa1rzfZfBkniIgQJT+JaciDpgo0oeo1F4uGRlQ5h5kIL6dXiOchkHEBv7uo0+N4OhRcK6mjHUgzorSwmkocYktW2Szu8gdr8ts6QbtkCM++uNz+v8AP5vO+gUh5b+9I7NWbkWdrqoWAOCw+miT7dPG5jMJ76HYCBFbWJt2iV96cpwiIR4VXH3kMHQBl0E66s75GFmaGUnx51JNXUGavmQASR3vsvrrC8kATb+P/mmTprvikGM7IPgWG1zHTcqLuoHDylVmfGHg0ys9LpqwuUBu7FvFuuftVwl/24RGJrxup3bGjOb3hJ12HSVMJ3NMZxVBIG4FVz7Voi9B8cCi9wPfaacZvc0Vk2itFOJS77nNrKs5XizH80JfWxu1Y/BYYNsMMys42rPpf0Mba/DHUfROLzlH5dg2lKQuuR1aJHLKWZHoQQPKEPu9D/pZKY7Y4T5ImdElXLG</enc:CipherValue></enc:CipherData></enc:EncryptedData>

If you succeed I'll fetch you a beer at IIW2009b.

Information Card Handouts from DIDW 2009

These two are the front and back side of the handout the Information Card Foundation provided at DIDW2009.



Visit Open Identity Solutions for Open Government to learn more how Information Cards are used in Open Identity and join the discussion at the Internet Identity Workshop. Register here!

New Version Openinfocard

I just uploaded a new version of the openinfocard selector to Google code here.

I changed code that limited self-issued cards to the "well-known" claims. Now I only need to add UI-code to enable the user to specify arbitrary URLs as claim-uris.
This change forced me to change the internal cardstore format for self-issued cards. The related XML now is more similar to the RoamingStore-format for Information Cards. This is good, but existing cards stop to work. Users of the new version have to delete and recreate their self-issued cards. Sorry, although I promise that this will be not the last time ;-) for this kind of changes. I want the internal cardstore format to be exactly like the RoamingStore format (plus legal openinfocard enhancements).

Other changes: - A small change that improves statusbar Information Card icon clicks when an object tag is in the page but no XRDS. This need more work.
- The sidebar code is leaner. This needs more work too, so that only matching cards are displayed and the sidebar window gets updated when the main window changes.
- The preferences javascript code is now in a separate file. I moved it from the XUL page. This seems to make the XBL that implements the preferences page happier.

I am glad that I found some hours to work on my hobby.

Happy Birthday Kim! Elusive Privacy Reloaded

That elusive privacy