Below are the slides for the presentation I gave at the W3C Workshop for Advanced Web APIs. See my other blog post for more information about the workshop and the paper.
Had a brief look to see if anything had changed re: geolocation in Firefox in its first beta release of 4.0. Seems they have started to integrate an indicator into the address bar.
The indicator still does not show up when geolocation is active, but it’s a start and it’s good to see that they are working to fix that.
UPDATE: the presentation slides are now available.
It’s a little bit drafty, so any feedback or comments welcomed. I will republish as a HTML file soon.
Investigating privacy in depth has been one of the most interesting things I’ve done in a long time… though it has left me a little bit creeped out. Hopefully I’ll get around to writing a bit more about what I read, what I’ve learned, and what practical changes I’ve made.
The following part of my forthcoming position paper for the W3C Workshop on Privacy and advanced APIs. Because my paper focused on implementation of geo-location, this sections had to be cut out. However, I think the following is relevant to the discussion about privacy and packaged Web applications, which is why I am publishing it here.
When it comes to privacy, it is obviously insufficient to simply define an API in terms of an Interface Definition Language (IDL), such as WebIDL and OMGIDL, within specifications. IDLs are limited in that they only allow one to express simple inputs, outputs, and data type constraints. Nevertheless, implementations exist based on specifications that only provide IDL definitions, which are agnostic to privacy. To overcome these limitations, some implementers leverage digital signatures as the means of enabling privacy-sensitive APIs in an application. For example, if application “X” is signed by company “Y” then allow application “X” to access API “Z”.
Such an approach to privacy is limited in that it hands control of privacy matters over to a third-party (the signer) and implicitly assumes that the end-users unquestionably, or via a End User License Agreement (EULA), trusts the signer as the authority to enable an API without necessarily informing an end-user as to what is going on “under the hood” – such a model is commonly seen in the Java application space.
Others have extended the digital signature to enable API model by having software developers explicitly declare what functionality an application will use (lets call them “feature requests“). Upon installation, the end-user is presented with a dialog informing them of the capabilities the application will use, and if they wish to proceed. An example is Chrome’s browser extensions, seen on the right.
From a privacy perspective, this model is significantly better then simply enabling APIs based on digital signatures. However, this model is also problematic in that it often does not provide any meaningful information about, for instance, what “can access your browsing history” coupled with “access your data on all websites” means. It can be argued that this model unfairly puts the consequences of consent on the end-user, by entering them into an agreement with an application without recourse (i.e., “Yes website/application X, you can access my history data even though I don’t know what you will do with it.”).
I recently submitted a paper to the W3C’s Workshop on Security for Access to Device APIs from the Web. The workshop is being held in London on the 10th of December, 2008. The website for the workshop informs us that:
With the emergence of the Web as a compelling alternative to locally installed applications, security issues are an increasing obstacle for realizing the full potential of the Web, in particular when Web applications developers need to get access to features not traditionally available in the browsing environment: cameras, GPS systems, connectivity and battery levels, external applications launch, access to personal data (e.g. calendar or addressbook), etc.
The goal of this workshop is to bring together people from a wide variety of backgrounds (API designers, security experts, usability experts, …) to discuss the security challenges involved in allowing Web applications and widgets to access the APIs that allow to control these features, and to advise the W3C on appropriate next steps for any gap that needs to be addressed with new technical work.
As all the papers of the workshop are now available on-line, I thought I would republish my position paper here. Being a child of the social networking era, my paper focuses on securing widgets using a community-driven approach to control rogue software. I propose that control security policies be handed over to trusted communities. Anyway, I won’t spoil the fun by rewriting the paper here. I also include the comments I got back from the panel reviewers at the bottom of the post.
And the panel said:
The notion of declaring in advance what feature access is needed is a good one. It’s similar to Necula’s notion of proof-carrying code (http://raw.cs.berkeley.edu/pcc.html). This is a good idea, regardless of how the authorization is done.
W00T! +1 to me!
I’m less enthusiastic about the multiple authorities notion. The paper suggests that developers pick the authorities, a notion that is ripe with potential for abuse. Even if all of the authorities are honest — itself quite an assumption — users may have different values. Some, for example, may trust the EFF’s notion of privacy and legitimate monitoring; others might prefer the RIAA. Why should the developer decide?
No no no! Users or operators can pick the authority! As if I would let the developer pick the authority, that is stupid. The developer is the hacker so of course they don’t pick the authority!
I’m also leery of community-based control of automated decisions. Wikipedia works (when it does work; the abuses are, of course, well known) because people read it and update it. What is to stop a botnet from flooding an authority with bogus “yes” votes for a malicious widget? At the least, this question should be addressed.
“When in works?!” WTF? it works just great as far as I can tell. What’s to stop the bogus bot, the same mechanisms and interests that stop the bots from destroying Wikipedia. It’s also the same mechanism that stop P2P networks from falling apart: the community. The community filters the content. And yeah, some bad stuff gets through, but it’s quickly filtered out before it does any damage. Ask the movie and media industry, they’ve made no progress in stopping piracy of movies and TV shows through bit torrents. Now apply the same to widgets.
It’s pretty notional, and the author doesn’t really seem to understand how the analogy between wikipedia and web trust breaks down in a number of ways. But the discussion could be fun and good for brainstorming.
I wish the reviewer would have elaborated and what I don’t get.
Get off the soap box and dive on how this would really work in the face of attempts to subvert it. That’s the hard problem. Right now, the paper has a bit too much hand waving.
Maybe this reviewer missed the “how it works in practice” section.
Remember how little time it takes for a spammer to get what they want. How will you deal with time lag exposures? (for example)
I proposed polling white/black lists. It’s better than the crap security models we have at the moment. It’s how current anti-virus software currently does it. I’m proposing a simple solution. I don’t think there is some magic notification system that could be implemented.
This is an interesting paper but I think it introduces more problems than it solves. Nevertheless, I think this would be a good topic of discussion for the workshop.
It be nice also if reviewer three listed what those problems where. Guess I’ll hear about them at the workshop.
Anyway, lots of great papers have been submitted to the workshop. I’ve not read all of them, but from what I’ve read so far, I recommend the following papers:
- WebVM – Security policy for device API access by Paddy Byers and Kai Hendry of Aplix Corporation
- A Web based security model fit for purpose, by Nick Allott, David Rogers, and Geoff Preston, of OMTP
- Secure access for widgets to resources and privileged APIs by Arve Bersvendsen of Opera Software ASA
- APIs, Safety, and User Notifications on The Web, by Arun Ranganathan of Mozilla
- Security model for browsing and widgets by Olli Immonen of Nokia
UPDATE: This conspiracy theory has been debunked. Microsoft said they would implement various aspects of the access-control spec in IE8. For what it’s worth, those Microsoft guys are ok with me
I love conspiracy theories… particularly when I get to make one up! Here is my conspiracy theory for how Microsoft will try to force both the W3C and other browser makers to adopt IE8‘s XDomainRequest mechanism/API.
A bit of background first: the Web Applications Working Group (WAF) has been working on a spec that allows browsers to do cross-domain requests (basically for creating mashups securely). The spec is called Access-Control, and has been in development for three years. The spec was being edited by Anne van Kesteren of Opera Software, but under heavy influence from Hixie of Google, Jonas Sicking from Mozilla, and Maciej Stachowiak from Apple, to name a few people/companies. Marc Silbey, the representative from Microsoft to the working group, was also participating for a while, but he dropped off the radar as Microsoft shifted into high gear during development of IE8 (actually, Microsoft assigned 3 people to participate in WAF, but only Marc did). A few months ago, to coincide with the release of the IE8 beta, Microsoft announced XDomainRequest… aspects of which look, in a lot of ways, very similar to Access-Control, but with some key differences.Then, to the shock of the working group, they brought XDomainRequest to the W3C for standardization knowing full well that WAF had been working on Access-Control for over three years!
Naturally, Microsoft’s actions pissed a lot of people off because, as I stated in an email, they are just ignoring over three years of work into the Access-Control spec, they created their own proposal and implementation in secret and now are attempting to fast track it through standardization ignoring due process.
You know, there is an idea that perhaps we’re not IGNORING the work on Access Control, and perhaps we simply disagree with some of it.
Which prompted me to respond:
…If Microsoft would have found the time to collaborate [in the WAF WG], all this stuff could have been resolved progressively and the [Access-Control] spec would probably be done by now (as has been shown, the MS proposal has just as many issues, if not more, than the Access-control spec; so trying to do it in-house did not yield a more adequate solution).
Which beckons the question, why did Microsoft stop participating in WAF to go off and create their own version of access-control? And here is the conspiracy theory:
- Microsoft joins the WAF working group in 2007
- Microsoft “borrows” Access-Control idea
- Microsoft implements its own XDomainRequest mechanism in IE8beta
- Mozilla implements Access-Contol in FireFox 3, but then pulls the feature at the last minute (consequently leaving a gap in the cross-domain request space for Microsoft to jump in)
- Microsoft delays Access-Control work by sending in comments a year late (just before it was about to go to Last Call) and putting in their XDomainRequest proposal for standardization. Meanwhile…
- Microsoft rolls out IE8, quickly gains market share (no help from Vista, of course )
- Other browsers must now implement Microsoft’s solution/spec because business and developers start using it
- Microsoft’s spec become a W3C Recommendation, Access-Control spec dies in the ass.
We are currently at point 5, with Microsoft using delay tactics to slow down standardization of Access-Control.
Why do I care? I’ve only contributed to Access-Control from the sidelines by attending face-to-face meetings and asking Anne dumb questions. However, a lot of C02 has been wasted flying everyone to meetings to talk about this spec; that’s thousands of dollars and thousands of kilos of C02 going to waste. Another thing that annoys me is, as I already stated, that Microsoft has every chance to provide feedback to the working group to fix/discuss any issues they’ve had with the Access-Control spec.