Safari 4 beta + Mail.app = strangeness?

Example strangeness
Example of the strangeness

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?

Privacy risks get real

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.)

Protecting us from people with cameras… who also walk their cats

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.

Will the “real” federated provisioning please stand up?

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. 

 

It turns out, to my surprise, that there are people doing this.  Parties in a federation agree to which attributes are needed and send those in their authentication assertions.  A process at relying party uses those attributes to provisioning new accounts.  This is a fairly lightweight and effective approach, but there are some catches to be aware of.

 

The first catch, as Nishant points out, is if the service provider needs attributes above and beyond what are in the assertion, there’s not an easy way for the service provider to ask for them.  To deal with this, the service provider has to present a registration screen of some sort to the user.  Compared to the first scenario in which the federate account is already waiting for the user, the second scenario is herky-jerky and will annoy/confuse the end user.

 

The second catch is deprovisioning.  The provisioning process hinges on an authentication event.  Deprovisioning cannot be activated on de-authentication.  This does leave the problem of how to remove accounts when people have left a federation partner.  In the approaches we have seen, when a new account gets built it has an expiration date associated with it that gets updated on every login.  After some period of time without an authentication, the account is suspended or deleted.  Not a bad way to go.

 

JIT Provision may in fact be “real” federated provisioning, but not provisioning, as a dogmatic, dyed-in-the-wool provisioning guy would immediately recognize.  While I take my dogma for a walk, this quarter Lori and Bob are going to looking into some of the intersection point of identity management and SaaS and I think they’ll have more to say on this type of conversation in the coming months.