Re: PROV-AQ security (privacy) considerations

Hi Graham

Thanks for the explanation.

cheers
Paul


On Thu, Nov 8, 2012 at 7:10 AM, Graham Klyne <graham.klyne@zoo.ox.ac.uk>wrote:

> 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
>
>


-- 
--
Dr. Paul Groth (p.t.groth@vu.nl)
http://www.few.vu.nl/~pgroth/
Assistant Professor
- Knowledge Representation & Reasoning Group |
  Artificial Intelligence Section | Department of Computer Science
- The Network Institute
VU University Amsterdam