ian glazer's tuesdaynight

Being the new-ish addition to the IdPS team is, well, an interesting place to be. Besides the requisite induction activities (ask me at Catalyst how you pick up the dry cleaning for a team who lives all across the country), I’ve been working with my peers on vastly different pieces of research. And being curious by nature, I’m loving the chance to not only dig into different topics, but also observe how different people go about the actual process of analyzing a topic or a market. One technique that Burton Group uses is Contextual Research (CR). Essentially, the CR process is meant to challenge an analyst’s knowledge of a subject and their associated preconceived notions as to what problems enterprises face and how they are facing them. It turns seasoned veterans, experts in the field, into beginners again. This is what practitioners of Zen Buddhism call “beginner’s mind.” Here’s how it works in a nutshell. Kevin (seasoned vet) and Ian (newbie) identify a bunch of organizations to talk to. So far nothing out of the ordinary as compared to our other approaches to research. That being said, the conversations we have with these organizations is very different from typical research techniques. Instead of coming to the conversation with a fixed hypothesis that we want to prove out, we come to the conversation with nothing. No leading questions. No surveys. No preconceptions. In these conversations, we, the analysts, are newbs. We let the people that we are talking to teach us what is important to them about a subject, how they have approached a problem, what wisdom they’d like to share with others. The analysts furiously take notes, listen, and try not to talk. Having listened to as many people as we can, we bring the whole team together to find affinities among the statements, identify trends and common techniques, and evaluate the state of a market through the eyes of a customer. Right now, Kevin and I are in the midst of a role management CR. Although, we are far too early in the process to comment on what we’ve found, some of the anecdotes we have learned along the way are really fascinating. Discussions about the needs of the business, efficiencies gained, and methodologies for conducting role analysis – all of these conversations have been grounded firmly in the realities of today’s economy as well as current state of identity management in the enterprise. You’ll see some of the results of this beginner’s mind approach to analysis at Catalyst this summer. In fact, the Catalyst workshop on Advanced Role Management is going to be a master-class of a sort, shaped by what Kevin and I learn during this CR process. Stay tuned for more on our roles CR. Towards the end of April, I’ll be updating you on how the process has faired. (Cross-posted from Burton Group’s Identity Blog)

Like a good little fanboy, I installed the Safari 4 beta on my aging iMac. So far, I am really liking the new version. Nothing earth shattering, but the performance gains are quite nice. Even on this old G5, Safari seems a lot zippier. I have noticed something really odd since installing the beta. Mail.app stops rendering HTML emails correctly. I’ll get the first few lines of an HTML email and then a bunch of whitespace. If I resize the window, the email appears normally. Anyone else seeing this?

When you think of “the usual” privacy risks you think of things like brand and reputation damage, fines, and increased regulations. You don’t think of jail time for executives. But jail time is exactly what some Google executives face if an Italian prosecutor has his way. The arrest of Peter Fleischer, Google’s Paris-based Global Privacy Counsel, in Milan on January 23 stems from video that was briefly available on Google’s site in Italy. The video showed high school students bullying a classmate with Down Syndrome. Google took down the video in less than 24 hours after receiving complaints about it. The view of Milan’s public prosecutor is that permitting posting of the video for any period of time was a criminal offense. Fleischer and three other Google employees have been charged with defamation and failure to control personal information. In our forthcoming report, Bob and I explore the contextual nature of privacy. Google clearly operates in multiple geographic and legal contexts. In the US, Google enjoys protections similar to those afforded “common carriers”. However, in Italy, Google is being treated as a content provider and not a content distributor, and thus is not receiving any such protection. The contextuality of privacy requires that you evaluate your business from all relevant contexts. In this case, Google may find that it should have looked at its video services from the perspective of an Italian user as well as an Italian regulator. This examination from all relevant contexts would highlight not only conflicts between contexts (someone’s desire to publish a video versus a state’s definition of what constitutes offensive or inappropriate content) but also conflicts between contexts and the organization’s business model. Google’s business of allowing anyone to post a video is in this case colliding with an Italian regulator’s desire to treat Google as a content provider, holding Google to an unanticipated set of requirements. There’s no way that a small privacy team will be able to know everything about every context the company does business in. To that end, a side effect of doing business in multiple contexts can be a budgetary one. Organizations may need to budget for external legal counsel, counsel that specializes privacy for the contexts they are working in to aid privacy teams in their evaluation of relevant contexts. We don’t expect criminal penalties for privacy violations to become common, and it’s not at all clear that the action against Google’s executives will be sustained by the Italian courts. But that being said, we do expect privacy regulations to become stricter and subsequent penalties to become more severe. Privacy risks are getting real. Join us at Catalyst this summer and learn how to adapt, and thrive, in the face of this new reality. (Cross-posted from Burton Group’s Identity Blog.)

Looks like Amtrak police got a little ahead of themselves; they arrest a photographer in NYC which he attempted to take pictures for an Amtrak photography contest. I know - it is a bit confusing. Don’t worry - Colbert explains it all to us in nice small words. .cc_box a:hover .cc_home{background:url(‘http://www.comedycentral.com/comedycentral/video/assets/syndicated-logo-over.png') !important;}.cc_links a{color:#b9b9b9;text-decoration:none;}.cc_show a{color:#707070;text-decoration:none;}.cc_title a{color:#868686;text-decoration:none;}.cc_links a:hover{color:#67bee2;text-decoration:underline;}

[

](http://www.comedycentral.com)

The Colbert ReportMon - Thurs 11:30pm / 10:30c

Nailed ‘Em - Amtrak Photographer

Nishant has commented on my post about federated provisioning. He has provided two different examples of federated provisioning. One of these, the advanced provisioning example, involves a company who manages its employees’ access to a service provider service via provisioning. In this case, Nishant agrees with me that provisioning of this sort is no different than provisioning the UNIX box down the hall.

But it is Nishant’s second example, the just-in-time provisioning example, which is a bit tougher. In this case, the enterprise and its service provider have a federation in place. Using SAML-based authentication, a new user attempts to access the service provider’s service. The idea (hope?) is that the service provider recognizes the new user request, provisions the user, and authenticates the user in the same conversation. Nishant does add a degree of difficult in this scenario as he ties the federation service to a provisioning service. Grabbing attributes from the SAML token, creating a SPML message, and handing that to a provisioning service is possible, but as a commentator points out this sort of interop isn’t spec’ed out so the heavy lifting is left to the service provider. And even if the service provider doesn’t want to directly link its federation and provisioning services, it still needs to grab that assertion attributes and create the account in the backend system.

Here is a short piece on how a researcher, Chris Paget, bought a $250 RFID reader on eBay and used it to clone ePassports while driving 30 miles an hour near Fisherman’s Wharf in San Francisco. I fully recognize that this demonstration doesn’t represent a method for fabricating complete paper-in-hand cloned passports. Cloning is just the first step, but it is a big step. More importantly, it is a step that the State department has is somewhere between impossible and unlikely. The following is a passage from the privacy impact assessment (PIA) of TDIS - the Travel Document Issuance System: The Department of State has taken extensive measures to prevent a third-party from reading or accessing the information on the chip without the passport holder’s knowledge. This includes safeguards against such nefarious acts as “skimming” data from the chip, “eavesdropping” on communications between the chip and reader, “tracking” passport holders, and “cloning” the passport chip in order to facilitate identity theft crimes. These safeguards are described in detail on the Department of State website. Apparently those safeguards aren’t very strong. I invite you to read the State Department’s FAQ on e-Passports. Notice the incredibly defensive tone in the opening of the answer to the question, “Will someone be able to read or access the information on the chip without my knowledge (also known as skimming or eavesdropping)?” Also notice the tacit acknowledgment that passport RFID chips can be cloned. Mr. Paget intends on driving around DC this weekend to see what he can clone, and with a macbre sense of humor, I look forward to reading his results. Until then, I’ll keep my paper passport.

I mentioned yesterday that Bob and I have just finished up some research on privacy. In this upcoming report, we stress the importance of establishing privacy principles and then using those principles to guide privacy practices. I happen to see this NY Times article (via Nishant’s Twitter stream) and had a bit of a Baader-Meinhof moment. The article talks about how social networking sites are giving their end-users more and more control over how information is disclosed. Giving users choice as to how their information is disclosed and used is important. Giving users meaningful choice as to how their information is used is much better.

Today is International Privacy Day (and also National Data Privacy Day here in the USA and maybe where you are too). The day is set aside to celebrate the anniversary of the Council of Europe Convention on Data Protection. Put on your reading list for today both the Convention for the Protection of Individuals with regard to Automatic Processing of Personal Data as well as the Organisation for Economic Co-operation and Development’s Guidelines on the Protection of Privacy and Transborder Flows of Personal Data.

There’s been a bit of recent blogging activity about federated provisioning and SPML. Having worked on both federated provisioning and SPML in a past life, it warms my heart to see this discussion. Jackson, quoting the CIO of Education Testing Services, Daniel Wakeman, restates the observation that SaaS providers are providing when it comes to federated identity management. This “major shortcoming” leaves service subscribers to fend for themselves in managing user lifecycle events like on-boarding and off-boarding. Not acceptable. That got me thinking - there really ought not to be a concept of federated provisioning. Provisioning an application in the data center must be the same as provisioning an application in the cloud. However, in the course of the conversation between James, Jackson, and Mark, it seemed SaaS applications and in-house applications were different from a provisioning perspective. SaaS applications may be harder to provision and de-provision than non-SaaS application, but that doesn’t make them fundamentally different animals. The point was made that SaaS apps lack a standards-based provisioning interface, an SPML interface. The fact is the vast majority of applications, SaaS or not, lack a standards-based provisioning interface and this makes dealing with them very much the same. Now there are two reasons that we don’t hear the same short of clamor about provisioning non-SaaS applications as we do with SaaS applications:

In response to regulatory pressure and to apply some pressure on their competition, Yahoo has announced that after 90 days it will anonymize search queries and remove personally identifiable information (PII) from them as well. Specifically, Yahoo will delete the last eight bits from the IP address associate with a search. Further, Yahoo will remove some PII data, like names, phone numbers and Social Security numbers from the searches. The goal is to (eventually) destroy the ties between a person and what that person searches for which could include embarrassing, compromising, or sensitive items such as information about medical conditions, political opposition materials, adult entertainment, etc. There are two points I want to draw you attention to. The first point is related to the amount of time search providers, like Yahoo, hold identifiable search queries. Regulators have recommended to search vendors to reduce how long they hold identifiable searches. The EU has recommended 6 months, for example. Yahoo, reducing their retention time from 13 months, has taken a laudable step to reduce that time to 90 days. In the future, the time it takes a search provider to extract whatever goodness it wants to out of a search query (to feed its varied businesses) and anonymize that query will reach zero. External pressures aside, the Googles and Yahoos of the world will achieve near-instantaneous goodness-extraction/anonymization of search queries simply because it reduces what they have to store, maintain, and worry about. That being said, even though search providers will be able to achieve near-instantaneous extraction and anonymization, they will never be able to put it into practice. Why? Because there will always be a desire on the part of law enforcement to gain access to those identifiable searches. The second point relates to the methods and outputs of the anonymization process. The industry needs to provide greater transparency in their anonymization methods to ensure that the scrubbed queries are truly anonymous. Consider AOL Stalker. AOL thought they had scrubbed their searched, but in reality those searches were fairly trivial to de-anonymize. Removing the last 8 bits of the IP address, as Yahoo and Google are doing, certainly helps to anonymize a search, but it does not do so completely. In fact, all removing the last 8 bits does is render my IP address indistinguishable from 255 other IP addresses in those last 8 bits - hardly anonymized. Once a search provider extracts what it needs to from a search, I question why it has to retain any IP information at all. I applaud Yahoo’s announcement; decreasing retention time is a good thing. But, I’d like to ask two more of the search providers. First, work together, in a transparent manner, to ensure the methods anonymization produce truly anonymous search query data. Make sure that when you strip a search of PII of all sorts including IP address, it cannot be transformed back into an identifiable search. Second, work with browser makers to have an anonymous search mode. Akin to the private browsing mode of better browsers everywhere, an anonymous search mode would indicate to the search provider that the search being submitted from the browser must be anonymized immediately. With announcements like Yahoo’s, 2009 may shape up to be a great year for privacy. (Cross-posted from Burton Group’s Identity Blog.)