Re: Using XACML profile to describe two current browser policies

Hi,

In an effort to better grasp the current proposal for the so-called
> XACML profile, I've tried to describe current browsers policies for:
> * the same origin policies as defined in HTML5,
> http://dev.w3.org/html5/spec/origin-0.html#origin-0
> * what I know of the current implementations of the geolocation API
> behaviors
> ...

The high-level summary seems to be that the declarative approach that
> the XACML profile is defining will have a very hard time matching the
> intricacies of actual deployed policies in browsers.
>

So I don't think the intention of the policy is to be fully prescriptive as
to how a browser controls access and the associated user experience. When
this was originally specified in BONDI the idea was that the policy tells
the browser the bottom line as to what it can and cannot allow, but still
the browser can (and should) be free to provide the best possible user
experience, balancing convenience to the user, respect for the user's own
choices, and offering reasonable yet usable safeguards for foreseeable use
cases.

Take, for example, the model that is used in IE where there are a number of
pre-configured "zones" ("Trusted sites", "Restricted Sites", "Local
intranet" and "Internet"). Each of "Trusted sites" and "Restricted sites" is
a configured list of domains. "Local intranet" is a set of sites based on
some fairly arbitrary heuristics, and "Internet" is everything else. For
each zone there is an associated set of permissions. You might imagine
having a policy in which trusted sites have access to geolocation with no
prompt, restricted sites have no access, and sites in "the internet" have a
requirement to prompt.

By having a "prompt" rule, the policy doesn't say what prompt is shown to
the user, or the options he is presented. It just says that some explicit
interactive confirmation is required by the user before granting access.
(I'm not expecting that this will be modal.) You can imagine that the user
could, in response to the prompt, indicate that the site is trusted, and
therefore should be added to the trusted sites zone, instead of granting
access solely to geolocation. So this is an option that the browser vendor
could elect to provide, which is not required by the policy but equally
doesn't conflict with the policy, but it is provided because it is believed
to offer a better experience to the user.

Personally I think the time-based idea falls into the same category - it is
felt by some browser vendors that this provides the best balance of
convenience and protection - but I'm not sure I expected that all details
like that would be specifiable by a policy author.

A similar issue relates to the user withholding rights - the user should be
able to (a) be aware when a site is using the geolocation API and (b) have
the ability to prevent it from using the API (say via something like
incognito mode) even if the policy permits access without a prompt. These
are general privacy considerations that implementations need to take into
account independent of simply implementing the rules configured in the
policy.

Over time, a consensus should emerge as to what best practice is in these
areas, and a policy-based approach should not stop this from happening.

Thanks - Paddy