Re: PROV-AQ security (privacy) considerations

Replying to two comments at once here.

Paul,

I personally think that it is very appropriate for the spec to include this kind 
of language.  Of course, others may (and do) disagree.  Security (of which 
privacy is a facet) is (a) of critical importance, and (b) very hard to get 
right, requiring care to be applied at every stage of design and implementation 
(cf. Ross Anderson's comments about "Programming Satan's computer" 
[http://www.cl.cam.ac.uk/~rja14/Papers/satan.pdf], etc).

The IETF has a long history of requiring all specifications to give 
consideration to possible security issues they may introduce.  It's not a 
panacea, but it helps to remind specification designers, reviewers and 
developers to be aware of security issues, and to try and make explicit those 
considerations that have been recognized, and maybe to prompt others to think 
about other considerations that have not yet been recognized.

The W3C does not (yet) have such a culture.  I think it's no accident that the 
web represents one of the largest and most pervasive attack surfaces today for 
subversion of digital information.  So yes, I think it's more than appropriate, 
I think it's irresponsible to NOT give some consideration to security 
considerations in the design, documentation and implementation of standards 
particularly those that are intended to widely used.

On 07/11/2012 01:12, Yolanda Gil wrote:
> Provenance management systems can provide mechanisms for enforcement and
> auditing of privacy policies.

Yolanda,

Thank you for reminding me about audit.  I've added this slightly modified to 
constrain it's scope to what I think is appropriate to this spec.  The paragraph 
previously circulated now reads:

[[
Provenance information may provide a route for leakage of privacy-related 
information, combining as it does a diversity of information types with possible 
personally-identifying information; e.g. editing timestamps may provide clues to 
the working patterns of document editors, or derivation traces might indicate 
access to sensitive materials.  In particular, note that the fact that a 
resource is openly accessible does not mean that its provenance information 
should also be.  When publishing provenance, its sensitivity SHOULD be 
considered and appropriate access controls applied where necessary.  When a 
provenance-aware publishing service accepts some resource for publication, the 
contributors SHOULD have some opportunity to review and correct or conceal any 
provenance information that they don't wish to be exposed.  Provenance 
management systems SHOULD embody mechanisms for enforcement and auditing of 
privacy policies as they apply to provenance information.
]]

#g

Received on Thursday, 8 November 2012 12:51:49 UTC