Re: wording for the privacy section

Hi John,

Thanks for the comments.

On Wed, Oct 29, 2008 at 12:52 AM, John Morris <jmorris@cdt.org> wrote:
> To not mince words, I believe that the proposed language and the broader
> suggestion to leave it to the UA to figure out privacy are a whitewash of
> the privacy concerns, and are pointing this WG effort down a very, very
> problematic path.
>
> [...] I believe that the current trajectory of this WG is heading
> toward a train wreck
>

I think these are extremely strong statements and I am not sure I see
any concrete justification for them. It is one thing to say that we
need to better address the issue of privacy, and another to claim that
the entire WG "is heading toward a train wreck". What exactly is this
ultimate catastrophe that you refer to?

> My main points are:
>
> Point 1:  The current direction of this WG is NOT what is specifically set
> out in the charter or what at least some (and I predict most) W3C members
> expect.
>
> According to the charter, the objective of this WG is "to define a SECURE
> AND PRIVACY-SENSITIVE INTERFACE for using client-side location information
> in location-aware Web applications."  To simply assert in a spec that any
> implementation MUST take privacy into account while being silent on HOW to
> do so accomplishes nothing, and will do absolutely nothing to change the
> norm - which is to wholly ignore privacy.

Again, I don't see where you explain this claim. Most of us seem to
agree that this specification is primarily intended for the Web, so
its most prominent implementers will be the Web browsers. Can you
think of any such Web browser today that would "wholly ignore privacy"
when implementing this (or any other) specification?


> Point 2:  This WG could well do serious harm to the uptake of more-privacy
> protecting efforts such as the IETF's Geopriv, and I seriously doubt that
> the W3C will want as part of its legacy serious harm to the goal of location
> privacy on the Internet.
>
> As I detailed a few days ago [1], the IETF's Geopriv WG has spent 7 years
> grappling with and largely solving most (but not all) of the questions this
> group is setting out to work on.  And the output of that group is a standard
> that seeks to FORCE developers to deal directly with privacy (or to
> consciously choose to ignore privacy by ignoring an essential element of the
> IETF standard).  If developers implement Geopriv to facilitate location info
> conveyance, they cannot claim to be compliant with the IETF standard if they
> do not address privacy.
>
> Now comes the W3C with a WG that substantially overlaps with Geopriv, and

This isn't actually accurate. Our primary goal is to define an
Application Programming Interface. Looking at your charter, your goal
is different:

"The primary task of this working group will be to assess the the
authorization, integrity and privacy requirements that must be met in
order to transfer such information, or authorize the release or
representation of such information through an agent."

You also have the following secondary goal which is, again, different to ours:

"An example API for application-level access to/management of
link-based location information.  That is, for instance, the WG may
describe an API for secure, privacy-enabling user/ application
handling of location information specific to a 3G wireless link
technology."

So I am not sure how our WGs overlap substantially. On the contrary:
if Geopriv offered a practical solution that would allow an
implementation of the W3C Geolocation API to address privacy, then by
all means, we should refer to your spec from ours (as Jon also
suggests).

>
> Point 3:  This WG effort appears to be reinventing the wheel, and does not
> even appear to be trying to do as robust a job as the existing wheel.
> Although I agree with the list traffic saying that this WG has a somewhat
> different purpose than Geopriv, I also think that the Geopriv effort has
> worked through (successfully to my mind) many of the questions that this WG
> appears to want to address.
> One can see this, for example, in the list traffic discussing terminology -
> what is of course a starting point for "standardization."  Geopriv developed
> a detailed terminology years ago - it may not be perfect or complete, but it
> is a good starting point.  As another example, on the list we are now just
> beginning to discuss the idea of "fuzzing" of location info (which is
> important for privacy).  [2]  But Geopriv grappled with - and came up with
> workable approaches to - fuzzing location years ago.
>
> It strikes me that a key threshold question this WG needs to answer (after
> defining requirements, as discussed below) is whether Geopriv offers a
> workable foundation on which this WG can build.  Rather than just starting
> out with new terminology and new standards for expressing and conveying
> location, we should try if possible to build on what already exists.  This
> is especially true because the entire structure of Geopriv is to facilitate
> OTHER protocols and other SDO efforts to build on top of Geopriv.  In other
> words, if there are indeed things that the W3C wants to accomplish that
> Geopriv does not (and I assume that there are such things), then Geopriv
> provides a clear framework to build extensions into the core location AND
> privacy conveyance that Geopriv already provides.  So I believe an important
> discussion (after we define requirements) is to see what is already done in
> Geopriv - so that we can then figure out what this WG needs to do in
> addition.
>

First of all, I think it's great if you can make contributions to this
W3C specification. Nobody is claiming that the specification is
perfect, so we naturally welcome constructive comments from anyone. On
the other hand, you seem to imply that we absolutely must base our
work on Geopriv. I'm sorry but I am not sure why this would be the
case. So far we have made decisions based on their technical merit. If
you have concrete proposals to make, then I'm sure we're all happy to
discuss them. Second, I think we are well beyond the point where we
would discuss whether this WG should exist or not or whether there is
any value in its work. We have spent many months on this
specification, we have contributions from all major browser vendors, 2
of which have already implemented it, we also have another
plugin-based implementation, plus quite a few applications that
already use the API.

>
> Point 4:  This WG appears to be putting the cart before the horse, by teeing
> up a proposed "solution" before we have defined the problems we are trying
> to solve.
>
> This WG does not seem to be approaching its mission in the best order.  In
> my experience, a "requirements" document is a good starting point, not a
> draft spec.  Unless the whole point of this effort is to put a W3C rubber
> stamp on an existing draft spec, then I think we should set aside the
> current documents and start at square one.  That pesky charter suggests (at
> least to me) that a core mission is to achieve a "secure and
> privacy-sensitive" result.  I don't think we can achieve that mission
> without first defining what exactly we are trying to accomplish here, and
> then identifying the security and privacy considerations raised by those
> goals.  We seem to be putting the cart before the horse.
>

As you noticed yourself, we do have a requirements section in the
current spec. We also started the entire effort by spelling out that
set of requirements. We then proposed a solution (the current API).
Please refer to the mailing list to see how things evolved.

Thanks,
Andrei

Received on Thursday, 30 October 2008 02:44:42 UTC