TAG on privacy by design for web applications

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 UTC