W3C home > Mailing lists > Public > public-privacy@w3.org > April to June 2012

TAG on privacy by design for web applications

From: Thomas Roessler <tlr@w3.org>
Date: Mon, 23 Apr 2012 13:41:56 +0200
Cc: Thomas Roessler <tlr@w3.org>, Dominique HazaŽl-Massieux <dom@w3.org>, Robin Berjon <robin.berjon@gmail.com>, Dan Appelquist <dan@torgo.com>
Message-Id: <66EB0467-C3D3-4288-ABE1-CDF9BDBDC23C@w3.org>
To: "public-privacy (W3C mailing list)" <public-privacy@w3.org>
Included below, the draft minutes from the W3C Technical Architecture Group's recent discussion about privacy by design for web applications and relevant APIs.

Original message here:
	http://www.w3.org/mid/4F91C3A3.8010107@arcanedomain.com
--
Thomas Roessler, W3C  <tlr@w3.org>  (@roessler)







Begin forwarded message:

> Web Applications: Privacy by Design in APIs for Web Applications
> 
>   noah: Product page is no longer a draft:
>   [45]http://www.w3.org/2001/tag/products/apiminimization-2012-02
>   -02.html
>   ... review of
>   [46]http://www.w3.org/2001/tag/doc/privacy-by-design-in-apis-20
>   12-03-27
> 
>     [45] http://www.w3.org/2001/tag/products/apiminimization-2012-02-02.html
>     [46] http://www.w3.org/2001/tag/doc/privacy-by-design-in-apis-2012-03-27
> 
>   robin: the feedback I've got is that the scope should be
>   clarified
>   ... so I will clarify it here
>   ... the background is: we started working on Geo API
>   ... this had privacy impacts
>   ... in DAP we tried to take into account privacy from day one
>   ... DAP started to think about how to do privacy in APIs
>   ... one principle was API minimisation which led to DKA's draft
>   ... now, that is only used in one API
>   ... and not used in any other WG
>   ... because we've moved on to other techniques
>   ... so API minimisation needs to be set into a broader
>   framework
>   ... applicable to several groups who are defining APIs
> 
>   <Zakim> DKA, you wanted to ask robin to put the good parts back
>   in
> 
>   DKA: that all sounds great
>   ... *but* I think you've taken out bits that shouldn't have
>   been taken out
> 
>   <DKA> [47]http://www.cs.virginia.edu/~evans/cs551/saltzer/
> 
>     [47] http://www.cs.virginia.edu/~evans/cs551/saltzer/
> 
>   DKA: for instance, the original draft referenced Saltzer &
>   Schroeder
> 
>   jar: in academia, this is the seminal classic on the subject
> 
>   <DKA> [48]http://escholarship.org/uc/item/0rp834wf
> 
>     [48] http://escholarship.org/uc/item/0rp834wf
> 
>   DKA: I understand why you might not want to bring those things
>   up
>   ... but I think it's important to do so, to mend the fence
>   between the "privacy nuts" and the "script kiddies"
>   ... there is really good information in the Dierdre Mulligan
>   document
>   ... and in the Saltzer document
>   ... these are architectural principles that could be brought
>   into the modern age
> 
>   <jrees> Official but paywalled location of S&S's classic:
>   [49]http://dx.doi/org/10.1109/PROC.1975.9939
> 
>     [49] http://dx.doi/org/10.1109/PROC.1975.9939
> 
>   DKA: if the additional techniques that you think could be
>   recommended enhance these
>   ... then point that out
>   ... point out that it helps to minimise the data that flows
>   down the line
>   ... I would like that work, which I think is good, to be
>   brought through
> 
>   robin: I hear that the digestion process was too aggressive
> 
>   DKA: you know the latest stuff from DAP
>   ... have the principles been tossed out?
> 
>   robin: mostly the document from which they come has not been
>   updated in three years
>   ... no one has read it in two years
> 
>   DKA: did they need to be updated?
> 
>   robin: I don't have a problem with the meaning of the
>   principles, but the phrasing is probably off
>   ... because the discussions have happened in other WGs
>   ... and whenever the document has been cited, it's been ignored
> 
>   <DKA>
>   [50]http://dev.w3.org/2009/dap/privacy-reqs/#privacy-minimizati
>   on
> 
>     [50] http://dev.w3.org/2009/dap/privacy-reqs/#privacy-minimization
> 
>   robin: so clearly it's not expressing things in a way that
>   people are able to use it
>   ... I'm happy to try to revive those principles more actively,
>   but we need to rephrase them
>   ... and I'm happy to do that
>   ... I really tried to make this document a how-to manual for
>   people busy writing specs
>   ... so if I'm writing a spec, what do I need to read to get it
>   right
>   ... a short, checklist document
>   ... I could re-organise the document so it serves both ends
>   ... there's good architectural matter in the documents you
>   cited
>   ... so I will try to restructure to serve both documents, I
>   think that's doable
>   ... the fast reading for the spec writers, and then there's the
>   background that can inform further thinking
> 
>   DKA: yes, and give the reasons for why the techniques work
> 
>   ashok: when we started this work, we really wanted to do
>   something in the privacy area
>   ... DKA found this well-scoped, well-defined area, which he
>   wrote up
>   ... and we hoped we could close on it quickly
>   ... what I'm worried about is that the scope has been enlarged
> 
>   robin: slightly
> 
>   ashok: the parts that you've added are different
>   ... they seem to be addressing a different problem with
>   different solutions
>   ... it looks like two ideas in this space, and I'm not sure
>   whether we shouldn't break them up into two things
> 
>   jar: or there might be more, two is a funny number
> 
>   ashok: there's lots of issues in privacy, and we couldn't
>   possibly handle them all
> 
>   robin: I don't want to boil the privacy ocean
>   ... this document is scoped to what you can do about privacy
>   inside a User Agent API
>   ... it's not everything that could possibly do in this area
>   ... but I think it does scope the problem in a way that is
>   useful and applicable by people who are working in this space
>   ... and it would be difficult to explain them in isolation
> 
>   ashok: so these are two directions that a user agent could take
>   to help protect privacy
> 
>   <Zakim> noah, you wanted to talk about tradeoffs
> 
>   robin: not the user agent, but the design of the API to be run
>   within the user agent
> 
>   noah: this is good work
>   ... I think it's coherent in its scope
>   ... I'm worried about it taking a long time, so focusing on the
>   most important thing is a good idea
>   ... you were saying that you wanted to do a quick guide for
>   people building these things
>   ... I think the TAG is at its best when it tries to tell
>   stories that have longevity
>   ... there are tradeoffs in the designs of the APIs
>   ... I'd expect to see those tradeoffs set out, for example how
>   testable the API is
>   ... as it will have a bigger surface area
> 
>   <Larry> I don't think this is the right recommendation for
>   "privacy by design". I'm not certain privacy-by-design if only
>   because there isn't even a clear definition of the "privacy"
>   design goal. I think this is consistent, I was worried about
>   API minimization. Note GEOPRIV policy document
>   [51]http://tools.ietf.org/html/draft-ietf-geopriv-policy-25 in
>   25th revision
> 
>     [51] http://tools.ietf.org/html/draft-ietf-geopriv-policy-25
> 
>   noah: also talk about performance
>   ... numbers of calls on the API
>   ... draw out the core things
>   ... to teach people to think deeply
>   ... handy guides are great as well
>   ... but I'd skew it more towards longevity
> 
>   <Zakim> timbl, you wanted to feel that a document of this sort
>   should mention acceptable use tracking, and the concept of
>   accptabl euse for a user aget and fo a community of agents of
> 
>   timbl: basically, I think it's a very useful document
>   ... two separate things that occur to me
>   ... talking about acceptable use
>   ... that's what came out of a privacy workshop at MIT
>   ... about capturing policy
>   ... if you're a user agent, you don't want to do anything
>   unexpected or damaging
>   ... if I've decided to share something (eg a calendar entry)
>   ... I select the two people to share it with
>   ... my app might decide to send them emails
>   ... it would be more reasonable for it to pop up the email so I
>   can edit it
>   ... it's different to add the name & address to a mailing list
>   ... which leads to the idea that sometimes there's an implicit
>   use
>   ... you haven't captured what you said the data could be used
>   for
> 
>   robin: looking at data usage is a fundamental question in
>   privacy
>   ... but it's hard to put that into API design
>   ... but you'll get pushback from API designers
>   ... and you'll get a fight, and it won't give progress
> 
>   jar: can we learn from that conflict?
> 
>   timbl: the related thing is between a trusted and an untrusted
>   app
>   ... web apps have to have total power, so they become trusted
>   apps
>   ... with an untrusted app, it's difficult to stop them from
>   using the data for something different
>   ... but then there's a trusted app talking to an untrusted app
> 
>   <Larry> note long discussion about whether SPDY's use of SSL
>   offers a "promise of improved privacy"
> 
>   timbl: at that point it might be reasonable to have a
>   negotiation about acceptable use
>   ... because the trusted app gathers the data to do something
>   specific
> 
>   robin: it would make sense, but we don't want to reinvent P3P
>   ... DAP started looking at rulesets, a simplified version of
>   P3P
>   ... so a server could say what it wants to do with the data
>   ... there's only one person in the privacy community who cares
>   ... and no one in the browser space
>   ... no one sees how to make that work in the broader sense
>   ... the solution we've come up with at the moment is user
>   mediation
>   ... so web intents allow the initiation of communication
>   between a server you trust and another that you don't
>   ... or vice versa
>   ... with the user in the middle saying ok about the transfers
> 
>   <Zakim> DKA, you wanted to comment on scope
> 
>   <Larry> main problem is that the design requirements for
>   privacy, accessibility, performance, security from
>   eavesdroppers, etc. can't be evaluated in isololation, so "X by
>   design" in general is problematic
> 
>   DKA: I want to comment on scope and support Robin
>   ... the original idea we had for privacy on the TAG was data
>   minimisation as one targetted document as a series of things we
>   could say
>   ... I struggled to think about what that set should say
>   ... your revised title and scope for this document really made
>   sense to me
>   ... how do you apply the 'privacy by design' idea to API design
>   ... I have been thinking about this for a while, and this
>   brought that back to me
>   ... so I support that idea
> 
>   <Larry>
>   [52]http://www.ietf.org/mail-archive/web/privacydir/current/msg
>   00053.html
> 
>     [52] http://www.ietf.org/mail-archive/web/privacydir/current/msg00053.html
> 
>   DKA: and I think the scope you've chosen is not boil the
>   privacy ocean
>   ... it's focusing on the API design, rather than all the
>   potential issues that the TAG might hit on privacy
> 
>   robin: yes, and it stops where the IAB's work on privacy starts
>   ... the IAB works up to the protocol layer
>   ... and I hope their work will also address data usage
> 
>   larry: I'm really concerned about the TAG taking this on as a
>   work item
>   ... not because it's not important, but because we're
>   optimising about a moving set of requirements
>   ... we had a discussion about SPDY's use of SSL and found we
>   didn't really have a common understanding of what privacy meant
>   ... we're optimising against a goal that is not clearly
>   understood in the industry
>   ... the GeoPriv policy expression language has been repeatedly
>   revised
>   ... the subject is controversial enough and has a lot of
>   different perspectives
>   ... it seems unlikely that the TAG will converge on a finding
>   that will fit with those
>   ... especially as the IAB is moving about what it covers
>   ... we have the area of variability around the tradeoffs
>   ... and about the definition of privacy and the channels of
>   communication
>   ... and then there's the boundary between this and other TAG
>   work
>   ... the boundaries feel very fuzzy to me
> 
>   robin: you're worried about us broadening the scope?
> 
>   larry: we have a risk of overlapping and saying something
>   contradictory, or leaving a gap between this work and others'
>   work
>   ... to shallow to the point it's not actionable, or too deep
> 
>   yves: what about the risk of saying nothing?
> 
>   larry: what's the boundary between the TAG and the privacy
>   interest group etc
>   ... there are other groups who are strongly chartered to work
>   on this
> 
>   <Larry> wonders if we are really ready to negotiate a boundary
>   with IAB
> 
>   larry: maybe we could come up with something that's shorter and
>   more generic to encourage further work
> 
>   robin: we should talk about this in the session with Dom
>   tomorrow
>   ... I did meet up with Christine who is chairing the privacy
>   interest group
>   ... to discuss whether this is of interest to them, whether
>   they should be doing it, whether the TAG should be doing it
>   ... I've also been talking about it with the IAB as well
> 
>   <robin>
>   [53]http://tools.ietf.org/html/draft-iab-privacy-considerations
>   -02
> 
>     [53] http://tools.ietf.org/html/draft-iab-privacy-considerations-02
> 
>   robin: the reasonable consensus is that the IAB are working at
>   the protocol level
>   ... and I have the impression that they are happy with this
> 
>   noah: isn't there a lot of conceptual stuff that has to be
>   sorted out across these
> 
>   robin: yes, so we've spoken about terminology
>   ... which is still a moving target
> 
>   noah: do they include a threat matrix?
> 
>   robin: they start with an internet privacy threat model
> 
>   noah: that seems important to agree on, what the problem space
>   is
> 
>   robin: yes, so their terminology is too much of a moving target
>   to be reused, so that will need to be revisited at intervals
>   ... as far as the Privacy IG goes, Christine felt that some
>   joint work, either joint review or a joint TF
>   ... to look at policy and that we could contribute
>   technological view
> 
>   larry: I talked to people at the IETF meeting, to the IAB, to
>   Wendy, to Thomas, and they didn't mention any of this
>   ... for you to have a private discussion, that the others in
>   the IAB and Privacy IG aren't aware of makes me worried
> 
>   robin: these discussions happened Thursday and Friday
> 
>   larry: we need to arrange discussions with the IAB in order to
>   collaborate with them
> 
>   noah: getting colocated with the IAB has proven difficult
>   ... we couldn't have a TAG meeting at the same time as the IETF
>   meeting
> 
>   larry: my concern is about overlapping with other groups
> 
>   <Zakim> jar, you wanted to urge disclaimer about sampling of
>   techniques, it's not a comprehensive treatment
> 
>   jar: there's something that feels incomplete about the draft
>   ... about how the scope is set
>   ... if you just look at the title it looks like it's about all
>   privacy issues
>   ... what you've said today about the scope is really important,
>   and should go into the introduction
>   ... this is really just a sampling of things that have come up
>   through the WG process
> 
>   timbl: you could have a related work section
> 
>   jar: there's a lot of interesting stuff in this space
>   ... you should say that
> 
>   noah: say why we chose these bits now
>   ... and what you should watch out for because we haven't
>   covered it here
>   ... stuff that hasn't been touched: different threat models,
>   different capabilities
> 
>   jar: give space for the reader to realise that this is a
>   sampling of what we know about right now
>   ... it might end up being complete, but because it's an active
>   area it's unlikely to be
> 
>   robin: this is like a BCP more than anything else
> 
>   noah: it might just be early
>   ... a year ago people were talking about minimisation
> 
>   timbl: I like 'patterns in API design'
>   ... and you could mention an anti-pattern, things that you
>   didn't cover
>   ... you're not saying they're best, that they could work for
>   some people
> 
>   robin: the reason I didn't use 'pattern' was that several
>   groups said it would tie it to 'design patterns'
>   ... which is a little old-fashioned
>   ... personally 'pattern' would have been something that I would
>   have used, but some people are scared of using that word
> 
>   <Zakim> noah, you wanted to say we must be willing to say we
>   don't have good answers on, e.g. policy
> 
>   robin: I'm happy to try using it
> 
>   <timbl> Alexander et al A Pattern Language
> 
>   <timbl> 1865
> 
>   noah: talking about policy, and that we don't have good answers
>   ... there's a risk of telling the piece of the story we
>   understand in isolation
>   ... and perhaps without policy it doesn't matter
>   ... need to explain which part of the problem these designs
>   will solve
> 
>   <timbl>
>   [54]http://www.amazon.com/Pattern-Language-Buildings-Constructi
>   on-Environmental/dp/0195019199/ref=sr_1_1?s=books&ie=UTF8&qid=1
>   333378641&sr=1-1
> 
>     [54] http://www.amazon.com/Pattern-Language-Buildings-Construction-Environmental/dp/0195019199/ref=sr_1_1?s=books&ie=UTF8&qid=1333378641&sr=1-1
> 
>   noah: and what issues it doesn't solve
>   ... if it can do it without talking about policy, I'm happy
> 
>   robin: I think that's part of explaining the scoping better
> 
>   noah: let's see if we can tell enough of the story with this
>   ... we have another session on this tomorrow to review how this
>   went with Dom
>   ... and we can go over logistics at that point
>   ... so let's wrap this up for now and come back on it tomorrow
> 
>   Adjourned
Received on Monday, 23 April 2012 11:42:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 April 2012 11:42:07 GMT