Adventures of an Eternal Optimist

Can anyone tell me if the link to a site’s privacy statement from the ‘First time at a site’ CardSpace screen (picture below) can be set by relying parties who don’t have an EV certificate? Finding documentation on this feature is ugly, since most Microsoft -based pages have a link at the bottom of the page entitled ‘privacy statement’ (referring to the site policy) — which horribly dilutes the search pool.

Update:  see the comments for the answer to my question (thanks Mark)

Here’s what I know. The ‘first time’ screen can be shown to a user for (at least) four reasons:

• It really is the first time that CardSpace has seen the site.
• If the user selects the “learn more about this site link” during regular use.
• Any of the certificate details for that site change.
• If “The site states that it has changed its privacy statement” (reference here).

How does that last bullet work? Does CardSpace detect a change in the privacy statement because the privacy statement is encoded in the EV certificate? If so, it sounds like a maintenance nightmare; do you have to re-install your certificate every time your privacy policy changes? If not, how exactly does a site “state” that it has changed its privacy statement? For that matter, how does a site state that it has one in the first place?

It is worth finding out, because if you as a site owner don’t have anything behind that privacy statement link, a user who clicks on the link will be told:

The site has declined to provide a privacy statement.

I hope there is a way for us peasant-cert types to populate the link – I can’t say that I’m excited about having my (potential) users thinking that I have declined to provide a privacy statement if the case happens to be that I am in reality unable to provide a privacy statement.

Thanks in advance to anyone who can help with this :)

I have an SSL certificate for my domain. And it took mere minutes and not a single extra email conversation to be validated.

The winning SSL Vendor took the approach that if I’m in control of my domain, I should also be in control of a few standard domain email addresses. A verification was sent to one of those email addresses. I responded to it. Done. And I didn’t even go through the parent company – I went through a reseller, and the process was still flawless (and cheaper).

What a night-and-day difference in customer experience. Talk about creating brand loyalty…

Rule #1 in this girl’s Guide to the Internet is: Never post your home address. Whether you are a 14-year-old in a chat room or a 30-something girl geek registering a domain, it makes sense to keep that information private.

In keeping with that rule, I use my work address when registering my own domains. Other people I know use post office boxes. I do not consider such a thing as bizarre or unexpected behaviour. As long as I can receive postal mail at the specified address, I do believe that I have satisfied the original registration requirement.

Unfortunately, at least one SSL vendor does not agree. I attempted to get a certificate for my domain yesterday, and ran into a wee little roadblock. Sadly, there is no trust relationship between the company that I registered my domain with, and the company I attempted to get a certificate from. The only method that the SSL vendor has instituted to ensure that I own my domain is to demand an exact match of address information between a submitted copy of a real-world credential and the WHOIS database entry for my domain:

Dear Pamela Dingle,

Thanks for writing to us.

We like to inform you that, according to validation we
follow the below process:
1. Inorder to activate your account, we need any of
the supporting documents exactly to match with the
account details.

2. And for issuing certificate, we need the account
details to match with whois.

Alternatively, you can change your account details for
which you can provide the documents.

We look forward to your response.

As it is highly unlikely that I will be able to produce a copy of an “official” document containing my work address, the only alternative that the SSL company is willing to entertain is for me to update my WHOIS information with my home address, so that it matches my drivers license. I consider that unacceptable, and I think it is a perfect example of users being railroaded into placing more information than they want into the public domain. Yes, I could temporarily change my information to my home address to get the cert and change it back. Yes, I could probably get my company to request the certificate, because we’re a small company and because I have a nice boss. That isn’t the point.

The point is that most people will do what the vendor asks, because they are being held hostage. They want SSL. They are told they have no other options. It is easier to accomodate under duress, than to stand up and say no.

I think that there are other options. The goal shouldn’t be to prove where I live, but to prove that I have control over the domain. I could, for example, change my WHOIS data to say “SSL VENDOR X SUX”. Besides making me feel better, I think it would prove some measure of control over my domain, but just in case, I could set it to a mutually agreed upon string. That would be a lot tougher to spoof than oh, say a photoshopped drivers license, yes? Ideally, wouldn’t it be great if the SSL company could receive an assertion from the company I registered my domain with, attesting to the fact that I own the domain? I’d like to see that happen.

Until then, SSL Vendor X can stuff it, and I will try and find a vendor who will take my money and treat information I wish not to disclose with a little more respect. Wish me luck.

For those of you who haven’t seen the comments to my last blog entry, it turns out that the lack of persistence in the optional claims checkbox was not by design. Bill Barnes from Microsoft responded to my entry to say:

The fact that the checkbox isn’t defaulting to checked in this case is just plain a bug.

As to the placement of the checkbox, one could argue it belongs on the front page, on the details page, and on the edit page. That’s a lot. But it makes sense.

I’m really happy to hear Bill’s response, since I figure this means the problem is more likely to be fixed sooner as a bug than as a request for enhancement. Hopefully this bug has a nice high priority on the list of fixes to stuff into the next update.

Thanks for setting the record straight Bill.

For all of the time I’ve been playing with CardSpace, I’ve only begun truly using the thing in a manner that I would consider representative of real world usage in the last month or so. For the first time, I am authenticating to the same site with the same card again and again, making changes to data in the card with expectations of those changes being picked up by RPs, attempting to provision accounts with cards, and generally acting like an actual user instead of just pushing buttons.

It is an easy tool to use – with one small exception.

I had understood previously that a user must explicitly choose to send optional claims for CardSpace transactions. I just didn’t realize that you had to do that every single time you wished to send optional data to the site. My testing has shown that the “Include optional data” checkbox lasts for one use and one use only. The next time you use that card at that site, if you just click the “Send” button — only the required claims get sent.

So for every transaction where you wish optional claims to be sent, you will need to:

1. Click the “Preview” button (even though “send” is right there).
2. Click the “Include optional data” checkbox.
3. Click the “Send” button.

It doesn’t sound so bad — until you do it all the time.

It means that as a user, you can’t decide once to include your webpage in the data you send to a site. You have to decide every time. That’s if you remember… if you don’t, the data just doesn’t get sent. That initial “send” button on the beguiling green background is hard to resist if you aren’t paying attention.

As a relying party, it makes for difficulties too. It makes just-in-time (ie not locally stored) receipt of optional data just that little bit less consistent. For sites who are storing optional card elements in a local profile, coders can’t blindly assume that every change to an optional claim should result in a profile update, or profile data will come and go on a daily basis, depending on whether or not the user remembers to hit the magic checkbox that day. If you decide to keep the original data in cases where the optional claims are empty, you have to make sure that your integration code can tell the difference between an empty piece of optional data that is included, and a not-included claim, so that you can blank out the field in the former case, and ignore the latter case. That’s a tough one to educate users on, too.

So this longtime CardSpace fan and user would like to respectfully suggest that it might be worth changing either the position, or the persistence of the “Include optional data” checkbox. My preference would be that the “Include optional data” checkbox be placed on the initial send page, and if I could have it all, I would want the state of the checkbox to default to whatever setting I set it to the last time I sent this card to this site. I would be fine with having the checkbox reset to “off” whenever I made changes to the card. I would even be ok with the box being unselected every time – as long as it was in a place where I would remember to turn it on when I wanted it. I don’t think that this would lead to anyone sending more data than necessary to a site, it would simply make it easier to send the right data to the site.

What do you think Bill? Would you consider it for V2?

I went to an NHL hockey game last night. Halfway through the game, two of the players dropped their gloves, circled, and closed for a fight. The crowd loved it; the home team scored a goal immediately after, high on the moment.

As I cheered the fighters on, I reflected with surprise that I was enjoying what I think many would consider a barbaric practice – what I used to consider a barbaric practice.

But that was before. It used to seem so horrible and pointless for two guys to go out back and beat each other to a pulp. Why not talk it out? Except these days, it seems that nobody takes it out back unless they have a knife in their hands. Or a gun. As a result, trifling arguments which used to result in black eyes or bruises, now end up with obituaries. Barroom brawls are scary things, these days.

Last night it occured to me that I now view fistfights with nostalgia – the gentleman’s way to settle a dispute. I can’t say that nobody gets hurt – but at least nobody dies. Temporary boo boos for nowhere-near-life-or-death squabbles. Compared to the daily news, two guys fighting without weapons seems like a crazy thing to be upset about. Too bad it isn’t more common. Twisted logic, I know. But then, it’s a twisted world.

I remember being incredibly incensed by a Catalyst conference panel some years ago, where one of the panelists haughtily declared something to the effect of “if engineers built bridges the way coders wrote programs”… you can guess the rest of the analogy. The expectation seemed to be that if we somehow only allowed “licensed” programmers to work and kept the rest out, life would be ever so peachy.

I’m afraid this sentiment hasn’t grown on me with time. It is absurd to imagine turning every programmer out there into a security expert – and just because they aren’t a security expert, it doesn’t mean they shouldn’t be programming. As user-centric identity technologies ‘tip’ into mass adoption, people of all experience levels will be coding with the goal of accepting information cards, some of whom will be at or beyond the limit of their understanding as they follow someone else’s instructions, or incorporate someone else’s sample code. The challenge is to make it easy for all of those people to do it right.

This is my hope for 2007. It is inspired by an article, written by Jeremiah Grossman and published at gnucitizen.org. Here is a quick excerpt:

The only way I see software security improving significantly is if “security” is baked into the modern development frameworks and be virtually transparent. Remember, the primary developers mission is to pump out code to drive business and that’s what they’ll do not matter what. When developers find that its WAY easier and WAY better to do RIGHT by security, then we’ll get somewhere. Not before… being a web application vulnerability assessment vendor positions you to see this happen first hand. Our data makes it quite clear, which websites are more secure than others.

At WhiteHat we assess vulnerabilities in hundreds of websites each month coded in all sorts of programming languages. Its clear to us systems designed with modern development environments like .NET and J2EE are WAY more secure than their predecessor. Session handling issues go away. So does large amount of XSS and SQL Injection. Are they all rock solid and infallible? No, of course not, but the differences are hard to ignore. To improve the security of software, the development framework seems to be making the most difference.

I consider this an excellent description of what the Windows Communication Framework gives us. Of what Higgins will give us. Of what Rob Richards’ xmlsec PHP libraries give us. A layer of abstraction written by those who know how to be secure, so that not everyone has to be an expert.

So – my compliments and best wishes for 2007, to the people who are working hard to bake security into user-centric identity components, instead of bolting it on later. You know who you are. Thank you for thinking of it, so that I don’t have to.

Lastly, I’d like to offer up an alternate analogy. I think what Jeremiah Grossman is talking about, and the ways in which all of the identity frameworks are already building their systems could be compared to how pyro-technicians create fireworks.

All sorts of hard work, scientific knowledge, research, and testing combines to make a dangerous combination of materials into something that can be safely used simply by planting it, pointing it the right direction and lighting a fuse, because you can be pretty damn sure that some of the people who are going to be playing with the finished product are not going to have pyrotechnical training. In fact they will probably take what you’ve done and manage to turn it into something that you never thought anyone would do -

– but if the pyro-technicians have done their jobs well enough, the world will still be able to enjoy the end result and reason for having started this all in the first place, in reasonable safety. Note that nobody can make a firework 100% safe — because nobody can guarantee that it will be used properly. What they can do is to make sure that when it is used correctly, it is very safe indeed.

My goal for 2007 is to help with the using correctly part. More on this soon…