Firefox 4 Beta 1's handling of Geolocation...

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.

Yesterday, I found this video lecture given by him at Google. Check it out! It covers a lot of things that are in the book.

I’ll just say, it’s a little bit sad to see such few people in the audience. Also, the questions from Google employees are very defensive. In my opinion, Daniel is right to say that people should have more control over Google results about themselves, specially if those results are slanderous.

A website viewed in Safari on iPhone 3.0 requesting to use the end-user's current location. But what will the data be used for? And where is the application getting the data from?

As can be seen in the screenshot on the right, when a web page attempts to access geolocation services on Mobile Safari, the browser presents the end-user with a dialog that states “[URL] Would Like To Use Your Currrent Location” with two options: “Don’t Allow” and “OK”.

This “click to confirm” model suffers from a number of  privacy issues: For one, the confirmation dialog does not give any indication to the end-user how their location is being derived: Is the location-provider the GPS? or is it the WIFI, or the cellular network, or a Web service? or a combination of those? and under what privacy policy does the location-provider provide that information? The iPhone provides no accessible means of viewing or changing the geolocation provider; hence an end-user has no control over the geolocation provider or even of knowing if their data is being encrypted on request.

Another privacy issue of Mobile Safari is that the confirmation prompts are modal: the user cannot fully view or interact with the underlying application to make an assessment of what the application might do with the positioning data, without first rejecting geolocation access to the website. Also, it is generally accepted that this kind of modal confirmation dialog lead to ‘click fatigue’: whereby users simply become accustomed to clicking “OK” to every prompt without grasping the consequences of their actions, and without having any real control over what personally identifiable data gets used, what it will be used for, or how long that data will be kept, or even if it will be made available (sold) to third parties. The privacy policies that govern geolocation services are buried three-levels deep in the “Settings” menu of the iPhone, under the “Legal” option, which contains about 50 a lot of pages of legalese and no searchable index!

The Iphone 3.0 "Legal" screen does not contain an index. Nor are hypelinks active.

Similar confirmation dialogs are found in the iPhone’s native applications (e.g., the Camera and Maps applications). If a user changes their mind about allowing location services, there is usually no way in the application  for them to revoke geolocation access without either quitting the application, uninstalling the application, or finding some other convoluted way to revoke access to geolocation services (e.g., having to globally disable location services on the device through the “Settings” menu). What is worst is that  once a user grants an application access to geolocation services three times, the system grants access to location services forever – or until the device is “reset”, meaning resetting back to factory default settings.

UPDATE: @andreasbovens pointed out to me on Twitter that the iPhone does, in fact, contain a way to reset location warnings. Go to “Settings > Reset > Reset Location Warnings”. My bad.

Iphone reset location warnings, which I didn't find the first time around

Applications that get granted access then do not generally provide an end-user with a means to revoke that access on an individual basis. This is also true on Mobile Safari: even after clearing the cache, history, and cookies Mobile Safari still grants websites access to geolocation without prompting the user.

In summary, Apple’s Mobile Safari browser (and iPhone 3.0 in general) provides end-users with limited access to privacy controls. It also provides no means of seeing which Websites have access to geolocation, nor once granted can that access be easily revoked by an end-user. The OS, however, provides means of achieving confidentiality by allowing the end-user to globally disable location services, WIFI, and cell-tower communication (via “Airplane Mode”). INSERT: The iPhone OS also provides a “Reset Location Warnings” option for all applications.

iPhone Airplane mode: anonymity?

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.

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

Java treats an application as unsigned, and reduces its privileges: meaning some APIs will not be available.

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.

Feature Requests

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.

Chrome's browser extensions show the capabilities of a packaged application, but lacks information about consequences.

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

Papers are  due on the 7th of June. I’m currently trying to put a position paper together which I will post here once I’m done.

Attack

The video below shows the reaction of the protesters.

Reaction

My initial reaction to seeing the YouTube video was a sense of outrage and anger. But I wanted to understand exactly why I was angry. That is, to go beyond the simple “fucking Muslims! here they go again.” that is most people’s reaction and really does not help anyone, to a more reflective analysis of my own moral position that causes me outrage (well, enough outrage to sit down and “blog-it-out” here). I knew on the face of it that what angered me was that people would react violently towards homosexual imagery and towards Lars Vilks – doubly outraged in an academic institutional setting, which establishes itself as a place of tolerance, debate, dissemination of knowledge, diversity of ideas, and scientific inquiry (things that are a direct affront to religious dictates, which are generally inward looking and discourage questioning and self analysis – I don’t need to give examples of religious persecution of science, women, other religions, etc., as they are so common in history). Upon reflection, to me, the purpose of art is to challenge the viewer and to seek an aesthetic reaction – that reaction may differ from one individual to the next. However, to suggest that attacks were simply motivated by an aesthetic reaction to what was on screen is of course naive. It is clear that the crowd had already gathered there with the intent on disrupting the talk that Lars Vilks was about to give and had no intention in engaging in a well-mannered debate about, well, anything.

In order to understand my outrage, I need to frame what to me constitutes “the good life”: that is, that highest moral authority and rights to which I must afford all human beings in the way I interact with them, and what I expect back from all human beings – something that is clearly at odds with Muslim protesters, for why else do I feel outrage? For this I turn to the Universal Declaration of Human Rights (UDoHR). Faith-wise, this means that I believe that globally applying the UDoHR would yield a better world in which I want to live and in which I want others to live (for an atheist who is influenced by Immanuel Kant, this is a matter of faith). What this also gives us a simple set of criteria by which we can judge our own actions and the action of others upon us in terms of justice, rights, and morality. The assumption being that the UDoHR are, in fact, universally applicable and do not seek to impose a higher (read religious or “god-given”) moral authority, and that the declaration is timeless. It also does away with intermediaries (God, churches, religions) and puts the responsibility of just action and behaviors on individuals: to be clear, you do things because it is the “right” thing to do at the individual level, and not because it suits the norms of a particular time or pleases some community (e.g,. “everyone in my church says abortion is wrong”), commercial entity (e.g., “I signed an NDA”), nature (e.g., “I’m hungry, so I must eat you”), or some constructed moral authority (e.g., “God said being gay is wrong”) – I give the examples because they demonstrate subtle forms of coercion – in each case, the individual is not free because something is influencing what they do. From my understanding of  Kant, turning to innate sense of human rights provides a sound basis on which to makes  particularly if you apply a “maximizing principle”:  simply take a situation, like suppressing someone speech, and maximize it globally. The act can only be moral if it does not violate someone else’s right – that is, justify an action on socio-economic terms, or in the interests of “the good of the people” is immoral (see the deeply flawed Utilitarianism, which seems to dictate much of American foreign policy). It is also fundamentally  different from “do to others what you would like to be done to you” (the Golden Rule), for, as stated nicely by George Bernard Shaw and quoted in the criticism section in the  Wikipedia article, “The golden rule is that there are no golden rules … Do not do unto others as you would that they should do unto you. Their tastes may not be the same.” Lastly, what is nice about the UDoHR is that it provides us some clear text to point at and quote from, as one would quote from a religious text.

What is clear from the video is that the protesters seem to be angry about some lack of respect for their particular moral norms (by Lars Viks specifically, and by Western Society in general). To show these images or videos seems to affect them as, for instance, an atheists being shown the video of Lars Viks being attacked by a group of Muslims (!) – that is, my reaction of moral outrage is because I see them attacking something that is normal, just, and right to me: the discussion and presentation of art and politico-religious satire within an academic context. This is where a point is drawn about what is just (in the sense of justice) and where religion though and institutions begin the threaten the liberties of individuals. In other words, when one group of people start to attack another group of people on the basis of religious morality (rather then human rights), religion breaches its boundaries and threatens, basically, everything (in the sense that “religion poisons everything”, as Christopher Hitchens puts it ).

The angry protester’s reaction then is framed as one that challenges another norm that is held as a pinnacle: that of freedom of expression. Article 19 of the Universal Declaration for Human Rights declares that, “Everyone has the right to freedom of opinion and expression; this right includes freedom to hold opinions without interference and to seek, receive and impart information and ideas through any media and regardless of frontiers.” The protester’s violent attack and violation of norms within a university setting certainly violate that right. The protester go on to violate  their right, and other’s participants right to peaceful assembly – Article 20 “(1) Everyone has the right to freedom of peaceful assembly and association.” They take the right away of Lars Vilks to speak, and for others to listen, and even from themselves.

This outrages me: someone (Muslim protesters) has violated someone’s rights. Violation of rights are not just- they are immoral and not in line with my view of “the good life”.  If someone’s rights can be violated by this group (Muslim protesters), then one day they might come and violate my rights. And I need my rights to do the right thing by people.

Response: A Picture of Muhammad

Article 18 states that, “Everyone has the right to freedom of thought, conscience and religion; this right includes freedom to change his religion or belief, and freedom, either alone or in community with others and in public or private, to manifest his religion or belief in teaching, practice, worship and observance.” But religion cannot be used to violate people’s rights.

Exercising my right to freedom of expression I give you a picture of the Prophet Muhammad. I drew this picture to portrait Muhammad just standing there. I don’t seek to mock the “prophet” by drawing him as an animal or something offensive.

Zip the good

Zip has a lot going for it. It is ubiquitous and dependable… so long as you don’t want to share files across cultures.

Zip the bad

The Zip spec does not seem to know that there are normalization models for UTF-8, when there are actually 4 (or more, because there is some non-standard ones too!). The Zip file gives no guidance as to how file names inside zip files are to be normalized.

Consider, when a zip file is created on Linux, it just writes the bytes for the file name in the encoding of the underlying file system. So, if the file system is in ISO-8859-1, the bytes are written in ISO-8859-1. This may seem ok, but when you decompress the zip file on Windows, which runs on encoding Windows-1252, the file names get all mangled. If the underlying encoding of the file system on Linux is something else, you won’t be able to share files with other systems at all. So in this case, it is not Window’s fault.

The Zip spec says that the only supported encodings are CP437 and UTF-8, but everyone has ignored that. Implementers just encode file names however they want (usually byte for byte as they are in the OS… see table below).

It gets worst! because MacOS runs on some weird non-standard decomposed Unicode mode, you can only share zip files with other MacOs users. According to this email, the LimeWire guys also ran into a similar problem with regards to encodings in MacOS:

“for example a French, German or Spanish Windows user cannot exchange files that contain [file names with] French, German or Spanish accents with a French, German or Spanish Macintosh users”

The following table illustrates the problem:

Yes! holly crap! three different byte sequences corresponding to different character encodings.

The only way around this would be a *special* custom-built widget zipping tool that normalizes file name strings to NFC. If the widget engine needs to decompress the widget to disk, then it would take the NFC and convert them to the operating system’s native encoding (or store the files in memory, and reference them that way). This affects the URI scheme and DOM normalization of Widgets, so Web Apps will have to deal with it eventually… but not sure exactly how.

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.

Towards a community-controlled security policy for Widgets
Marcos Caceres, W3C Invited Expert

Traditional software security models have had limited success in
halting the spread of malware. Some studies suggest that roughly 1/10
of all computers connected to the Internet are running some sort of
malware. Software security firms have effectively given up trying to
keep track of the number of infected computers.

The Web Apps working group is currently working towards standardizing
a class of client-side Web application colloquially referred to as a
"Widget".At the time of writing, widgets currently lack a standardized
security model that would make user's less susceptible to widgets as
malware. A new standardized approach is needed to protect users and
limiting widgets from further exacerbating the software security
problem. This is  particularly important on mobile devices (one of the
target platforms for Widgets), which already outnumber PC; A number
that is only set to increase as prices on mobile devices continue to
decrease and the social value of  convergence between internet and
device capabilities increasingly add value to the social dimensions of
the Web.

The mobile industry has largely avoided the software security problems
that plague PCs through (a) strict control over what software can go
on devices, or (b) by requiring that developers have their software
digitally signed by a vendor or some other trusted third party to
access device features. However, the stringent controls have resulted
in:

 o Lack of innovation within the mobile software application space,
where only those who can afford to pay for a digital certificate are
allowed to access APIs on devices.
 o High barrier of entry for developers, because of the cost of buying
a code signing certificate.
 o Developers circumventing security policies and distribution models
(eg. jail-breaking the iPhone).
 o The creation of an extremely closed and anti-competitive
environment, where a single vendor can "kill" applications for any
arbitrary reason (as Apple has done a number of times on the iPhone).

At the same time as malware has grown exponentially, a different
phenomenon has shown itself resilient to vandalism and attacks on the
Web. Namely, Wikipedia has sustained a high level of quality of
content by leveraging a community's interest to keep the quality of
content high.

In this paper, I take the position that a different approach to
software security is needed for widgets: one that builds on
traditional ways of keeping software secure, but also attempts to
leverage the community of users that use widgets. In other words, a
community-driven security model for widgets whereby the social layer
of the Web form "trusted authorities" that have the ability, through
existing Web protocols, determine and dynamically adapt the security
privileges of Widgets running on end-user's devices (or even recommend
the removal of Widgets from an end-user's device, if the trusted
authority deems that a widget has become malicious).

Standardization of Widgets through Web Apps Working Group
Widgets are client-side applications that make use of Web
technologies, such as HTML, CSS, and JavaScript instead of compiled
programming languages such as Java or C#.  Although not formally
specified at the time of writing, the security model that underpins
widgets is one of almost total lockdown: by default, a widget is only
allowed to access resources within it's own package (widgets are
always packaged in a Zip file). To get access to the network, a widget
must explicitly request it through a configuration document . Widgets,
however, rely on the limited functionality provided by browser's APIs
in order to do anything remotely useful. For example, widgets from
various vendors rely on the XmlHttpRequest object to make asynchronous
requests to fetch data from the Web. The Web Applications Working
Group seeks to change this by allowing widget authors to have access
to APIs beyond those provided by today's Web browsers. To this effect,
the Working Group formulated the following requirement in the Widgets
1.0 Requirements document [1].

"R21. Feature Access Declarations
A conforming specification MUST specify or recommend a means to allow
authors to declare that an instantiated widget will require access to
device specific standardized features or proprietary features (e.g. a
proprietary API to access the camera on a device). A conforming
specification MUST be specified in such a way that fallback
relationships can be declared so that if one feature is unavailable,
another can be declared as a possible substitute. In addition, a
conforming specification MUST provide authors with a means of stating
which features are optional and which features are mandatory for a
widget to run."

Feature access, in this context, generally refers to accessing APIs to
device capabilities. The current proposal for standardization of
feature access is to declare, within a widget's configuration
document, a <feature> element. The feature element, as specified at
the time of writing, has two attributes: name and required. Name is a
URI that identifies the feature, and required means that the feature
is required for the widget to run. Feature elements can be nested,
forming a fallback relationship. So, if the outer most feature is
unavailable, then the widget user agent will attempt to use the next
inner feature like so:

<widget xmlns="http://www.w3.org/ns/widget"
   wid="http://widgets.com/superWidget">
   <feature name="uri:tryMeFirst">
       <feature name="uri:tryMeSecond"/>
   &lt;/feature&gt;
</widget>

It also needs to be stated at this point that widgets can be digitally
signed. Creating a digital signature for widgets involves hashing all
the resources inside a widget package to produce a digital signature
resource. This resource is stored inside the widget as
"signature.xml". Multiple signatures by different vendors may be
included in a widget package.

Securing feature access
Consider the following hypothetical example. A developer has created a
widget that requires the use of the W3C's Geolocation API. In the
example below, the Geolocation API is identified by URI, which the
widget engine is able to recognize.

<widget xmlns="http://www.w3.org/ns/widget"
   wid="http://widgets.com/superWidget">
   <feature name="http://www.w3.org/api/geo" required="yes" />
</widget>

Then, at runtime, there are essentially four ways that a feature
widget can be allowed to access the feature:

1. The end user is prompted for permission to use the feature.
2. If the widget was digitally signed by a trusted source, a vendor
may grant the widget access to the feature.
3. The widget was packaged and digitally signed with a resource that
grants it permissions.
4. The widget engine acquires a list of features that a widget is
allowed to access from one or more trusted sources on the Web.

In the case of 1, prompting the user, it is generally known that
end-users will click "yes" without fully understanding the
consequences of what they are doing. Hence, leaving security decisions
solely to end-users does not generally help with security. In the case
of 2, relying of digital certificates, is costly for both
vendors/publishers and developers because it requires that every
widget be checked and signed by a single source authority. It also
requires that the root certificate of the authorizing signer be on
every device, which is economically infeasible and likely technically
impossible. Case 3, including signed permissions, suffers from the
same problems as 2. It also suffers in that once the widget has been
released into the wild, the permissions are effectively baked into the
widget package. In the case of 4, dynamically acquiring permissions to
access features from a trusted source, overcomes many of the problems
with 2 and 3, but requires an infrastructure that would offload the
quality assurance and privacy management and device capability access
to some trusted authority on the Web. However, I would argue that
model 4 is a natural evolution of community run Widget
galleries/Software review sites on the Web, which already provide
ratings for widgets by communities of users.  What is currently
lacking is the mechanisms that would allow such a model to emerge.

Of course, there are problems with the community driven security
approach. For instance, the permissions server may be unavailable or
the policy delivered for a widget may be incorrect. The system could
be circumvented by members of the community to grant a widget access
to more features. However, as with Wikipedia, community protocols can
be established to limit such things from happening. Another problem
with this approach is that it requires the developer to have their
widget verified by as many trusted authorities as possible, to make
sure that their widget runs on as many devices as possible. Despite
it's limitations, I would still argue that, together with traditional
software security models,  this proposed  model may further assist in
reducing widgets becoming malware.

How it would work in practice
A developer creates a widget and submits it to one or more trusted
authorities for review. As part of the widget, they declare the
features they require at runtime.
The trusted authority may grant the widget access to the features it
requested by providing some sort of downloadable permissions file.
If the widget starts misbehaving, members of the community of the
trusted authority may reduce the feature privileges of a widget, or
even send a warning to end-users that the widget has been deemed
unsafe.
The widget engine periodically verifies each widget with one ore more
trusted authorities, dynamically adjusting the security policies as
widgets.
If a malicious developer submits a widget, and it is granted feature
rights, the widget can only do limited damage before it is discovered
and disabled by the community.

And the panel said:

Reviewer 1:
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.

Reviewer 2
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.

Reviewer 3
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