Whenever things are this quiet, you can be sure that there is a lot of work going on beneath the surface. Just in case you don’t believe me, check out the latest version of the Bandit DigitalMe Selector: I *love* the yellow band that displays the hostname of the Relying Party you are trying to interact with, it’s a great addition. Nice work Andy!
Congratulations to the London Heathrow Airport Security Team on busting the dangerous character who had the AUDACITY to wear a tshirt depicting a picture of a fictional superhero holding a fictional gun. Who knows — perhaps that character could have jumped right out of fiction-land into reality and hijacked a plane.
I had no idea about this very serious threat to national security! I will heretofore make the sacrifice of leaving my Jessica Rabbit t-shirt at home from now on. I sure do wish my own country’s airport security crew was as observant and as quick to act upon credible security dangers; I admit I feel like I’m at risk in Canadian airports, where the security personnel would laugh heartily at the idea of a cartoon posing a risk to air flight. In fact, I won’t feel safe until we develop technology that can scan passengers to make sure they aren’t wearing Boba Fett Underoos…
I must have missed the memo on unencrypted tokens… will check with the OSIS crowd and report back - this will most likely temporarily break some Relying Parties (including mine). Oh, the wicked pace of progress 
On my way to go watch bad American Infomercials last week, I spent a lot of time in the airport, in this case the Vancouver airport. The usual time-honored geek-at-an-airport rituals were observed: the scurrying around with lowered head, looking for the elusive power outlet behind a seat, the plugging in of as many gadgets as the outlets allow, and then the groan that comes forth as you open your browser to see how much you get to pay for internet access for today’s airport tenure.
Many of you have probably had the airport wifi experience. You get online just enough to be given options for payment — 1 hour, 1 day, 1 month, or ongoing support. If you already have an account with the wifi provider, you are off to the races. If not, you have to (1) Register. (2) Pay. (3) Get a username and password that you will never remember. (4) Use it once. My favorite at SFO was always the fact that the usernames stuck around but that you (or at least I) couldn’t recover the password, so you had to end up appending numbers to the end of your usual username choice to get a new account for every visit. If you were optimistic enough to pay for multiple visits at once, well good luck getting in on the second visit. The experience is uniformly time-consuming and frustrating.
And so, as I started my browser and saw that Wifi was managed by Telus (not Bell, my own provider), I braced myself. Suddenly — at the bottom of the page, I saw the following:
Canadian wireless providers have created a provider centric wireless service offering, where instead of having to give your information to whatever provider happens to run the hotspot, you can alternatively authenticate to a wireless provider you already have a relationship with, and and do the deal there. Once negotiated, your provider deals with payment on your behalf, your internet access charge shows up on your monthly bill, and you gain access to Vancouver airport wireless service, never having had to pull out your credit card or fill in a registration form.
Yes!!! This is exactly the experience that I want to see! Instead of having to hand over my data & credit info to someone I had no reason to trust, I instead chose an entity with whom I already had a relationship to act on my behalf. The transaction was easier for me, and I assume profitable both for Bell and for Telus. Wins, all around.
This is what needs to happen in general on the internet. By whatever means. I of course have my technology preferences, but it is the end result that matters the most.
As a result of a bit too much time spent watching American TV in hotel rooms this month, I decided to check out the URL of an interesting product. The BenderBall is a little tiny thing that I’m convinced would be perfect for trying to keep in shape at the cabin.
At this point — I have generally decided I want the product. I’ve remembered the URL. I’ve visited the site on the web. I’ve clicked the “Update Cart” button. I’m not a big “shopper” so to get me to this point is a rare occurrence. Suddenly I’m presented with the payment page, and I see the one thing that GUARANTEES I will not buy the product:
To force me to subscribe to the “special offer” list in order to get a Shipping Confirmation is unacceptable, and I will not pay $$ to a company who attempts to coerce me into doing so.
Yes, this company has a product I want, but the barrier to pulling out that credit card is already high, and now they have blown my trust of their business practices. I’m already suspicious of infomercial sites to begin with.
I would however, buy this product through either a bricks & mortar establishment, or through a trusted provider such as Amazon. Why? Because I can do so without putting as much of my data into the sleazy vendor’s hands.
I guess my abs will just have to stay flabby.
I’m sitting in the Data Sharing Summit after a conversation about what can go wrong with data portability, all full of wonderment and questions — I figure I’ll blog my heart out while I can still embrace my current simplistic view of this area
I feel a huge sense of dissatisfaction when I listen to application developers talking about privacy. They talk about how a given person can create a view of themselves that can be consumed by an application - but the vocabulary they use reminds me of assembly programming. Of course, the folks who write the specs and the folks who implement those specs must understand this level of granularity - but can’t there be something more palatable put in front of the users?
Every person who interacts with another makes a personal risk assessment about the action they are about to take. At the very beginning, all you can really do is look at the very superficial things that people advertise about themselves, and interpret those things within the context of the current community. In real life, this means that initiating a conversation on heavy metal with a person wearing a Metallica t-shirt is probably not risky within most contexts. In the same way, you might choose to confidently drop a literary reference in a conversation with a person who has a copy of ‘The Master & Margarita’ in his hand.
This is theoretically analogous with online entities like interest groups within social networks, it gives fellow users a chance to make initial guesses on the type of person they are dealing with. But I have to ask — why is it that we have nice warm fuzzy interfaces for users to express their preferences, affiliations, personal views and all sorts of context such that other people can synthesize a gestalt of a person and make a risk assessment, but the application can do no such thing?
What about allowing a user to choose a set of simple, private parameters that represent a very coarse-grained view of how that user might wish to be treated by the application? If I tell Linkedin that I want to be treated like a quiet, conservative, privacy-concerned person who keeps to themselves, I think that LinkedIn can guess how I would feel about my data being exported. If I wanted LinkedIn to treat me slightly less stereotypically in some circumstances, I should be able to dive into the assembly language and tweak things - but I’ll bet most people would be fine with broad strokes as a starting point.
Alternatively, perhaps I tell Facebook that I’m an extrovert with a great sense of humor who loves to connect but who is concerned about how photos with me as the subject are published to the world. Again, I think there are interpretations that can be made with respect to the boundaries that this user wishes to set.
Would this perfectly work every time? Certainly not. But neither does the real world model. At least maybe this could be a way to mitigate the fact that the social graph with respect to data portability/privacy is in fact an interconnected set of multi-dimensional matrices that represents the mother of all provisioning problems - every person dealing with every attribute of every relationship within every community they are a part of, and now also between many of the communities they are part of.
Here is what I envision. Imagine a very small number of possible attributes to describe a person’s privacy tolerance, that are displayed as part of your account settings. My guess is, if you see a descriptive word in your account that is the default, but doesn’t describe you, you will go and change it (rather than just ignoring a wall of possible privacy settings that doesn’t give you any interpretation of the implications). Perhaps to be more visual, you could set up an equalizer at the bottom of the page representing different ranges of tolerance for various uses of data, that users can set with one button click by using a preset and then fine tune if needed.
Hm, I wonder what the privacy version of the “stadium” preset would be?
Last weekend while I was out at my cabin, Ryan Janssen was trying to install PamelaWare for WordPress. Generally I wouldn’t be too concerned, as my project members and I have worked hard to make the install relatively easy.
I try to make myself available as tech support if I know anyone is trying to get the plugin to work, because I want to make sure everyone has a good experience — but in doing so, it turns out that I was masking a critical flaw in both the documentation and the administrative user interface.
For more details, you should read Ryan’s entry, I recommend it - the entry very clearly describes his frustration around not knowing what format of private key, passphrase, and domain name the plugin was expecting, and his eventual success by brute-forcing all of the possible combinations.
Obviously, this isn’t exactly the review I was expecting But luckily, I have just finished Henry Petroski’s book “To Engineer is Human; The Role of Failure in Successful Design” (recommended during Brian Cheess & Gunnar Peterson’s AWESOME RSA talk). As such, I have to note that I did not design to obviate failure in this case — but that the failure Ryan experienced can now be learned from and used as a cautionary tale for the future.
As a result of Ryan’s sacrifice of time and his willingness to describe his pain, I’ve updated my documentation to include an SSL Primer and an SSL Certificate FileType Guide, as well as screenshots of what a typical filled-in interface might include. I’ve also added a page explaining how to tell if your environment is set up for PHP version 5 and mcrypt (prerequisites for PamelaWare). I have not yet improved the user interface, but I will. I also think there is more to do, to explain what happens next once you’ve installed and configured the plugin. The great thing is, I’m now focused. And I can always go back to Ryan’s blog if I need to capture that feeling of “WTF do I do now?” Many thanks to Ryan for not just walking away, and for writing it all down.
I so love to see a point well made:
 | Mark Dixon on Catalyst Epiphany #1 |
 | Matt Flynn on Catalyst Epiphany #1 |
 | Nathan Harris on Real Life Personal Privacy… |
 | Pamela on Firefox 3 Rocks the Certificat… |
|
