W3C home > Mailing lists > Public > public-privacy@w3.org > July to September 2015

Re: questionnaire feedback (was Re: Save the date - PING at IETF - Thursday 23 July)

From: Frederick Hirsch <w3c@fjhirsch.com>
Date: Thu, 23 Jul 2015 13:41:50 -0400
Cc: Nick Doty <npdoty@w3.org>, "public-privacy (W3C mailing list)" <public-privacy@w3.org>
Message-Id: <C59BAE14-23E7-44D7-B16C-E22AD8AFCE37@fjhirsch.com>
To: rob@blaeu.com
if the security and privacy statements were appropriately tagged within the document (e.g. with appropriate markup) then I could see a tool automatically processing the document (e.g. ReSpec) to generate/augment a summary section in the document. 

We did something similar with best practices, to mark each practice within a document, then auto-generate a summary appendix of best practices [1].

regards, Frederick

Frederick Hirsch

www.fjhirsch.com
@fjhirsch


[1] 

ReSpec -  https://www.w3.org/respec/guide.html#best-practice-documents 

Example document - http://www.w3.org/TR/2013/NOTE-xmldsig-bestpractices-20130411/


> On Jul 23, 2015, at 3:44 AM, rob@blaeu.com wrote:
> 
> 
>> Regarding security and privacy considerations section, I think it's
>> great to ask about them and to note why they might be useful. We can
>> say, though, that security/privacy-related text doesn't need to be
>> limited to that section. In fact, I think it's a good practice (as we
>> saw with Media Capture recently, and in some other documents) for
>> documents to include privacy and security text/requirements
>> throughout. In that case, a section might not be an absolute
>> requirement, or it might serve more as a summary than as introducing
>> normative language for the first time.
> 
> Agree, but having a seperate section at the end containing a summary, i.e., all the recommendations (incl. normative privacy requirements) makes them easy to spot. Hyperlinks to the sections which relate to the details of the recommendations make the summary section even more useful IMHO.
> 
> Rob
> 
> 
> Nick Doty schreef op 2015-07-23 07:44:
>> Regrets, friends, but 2:30am is just a little bit too late for me to
>> be coherent on the phone, so I won't be able to join you from
>> California. I've been enjoying the email discussion on the
>> privacy/security questionnaire and it seemed like the group was making
>> good progress without my involvement.
>> A couple of thoughts on reading over the wiki page:
>> The security section mentions identifiers, but I suspect we could be
>> quite more detailed about the questions/limits we put on identifiers.
>> In particular, the Media Capture document highlighted that it wasn't
>> entirely clear the *scope* of an identifier. Across what contexts is
>> it unique? How is it persisted? If it's persisted, is it marked to be
>> cleared with other storage? And I think a key consideration here that
>> we haven't described in as much detail is the privacy risk if an
>> identifier or local storage mechanism is shared across origins. One of
>> the dangers of tracking identifiers introduced through header
>> enrichment is that the introduced identifier might be the same for
>> different origins, which allows for cross-origin tracking that would
>> be entirely opaque to the user. (See, for example, the TAG finding on
>> Unsanctioned tracking.)
>> While I prefer it to "PII", I think "personally-derived information"
>> might still be a little misleading. I think we would want to highlight
>> any information from the device, for example, like files on the file
>> system, microphone/camera, location, contacts/calendar, even
>> accelerometer and the like. Maybe a broader phrase such as
>> "information about the user or device" would be appropriate?
>> Regarding security and privacy considerations section, I think it's
>> great to ask about them and to note why they might be useful. We can
>> say, though, that security/privacy-related text doesn't need to be
>> limited to that section. In fact, I think it's a good practice (as we
>> saw with Media Capture recently, and in some other documents) for
>> documents to include privacy and security text/requirements
>> throughout. In that case, a section might not be an absolute
>> requirement, or it might serve more as a summary than as introducing
>> normative language for the first time.
>> Hope this helps,
>> Nick
>>> On Jul 15, 2015, at 12:57 AM, Christine Runnegar <runnegar@isoc.org> wrote:
>>> PING and friends,
>>> We will be meeting in the Rokoska room between 11:30 and 13:00 on Thursday 23 July 2015.
>>> Anyone with an interest in privacy is welcome. Bring your friends!
>>> Please let us know (off list) if you plan to attend.
>>> The main topic will be the draft TAG privacy and security questionnaire:
>>> https://w3ctag.github.io/security-questionnaire/
>>> Link to the PING working document:
>>> https://www.w3.org/wiki/Privacy_and_security_questionnaire
>>> Useful background reading:
>>> DRAFT - Fingerprinting guidance - https://w3c.github.io/fingerprinting-guidance/
>>> DRAFT - Privacy considerations - https://w3c.github.io/privacy-considerations/
>>> DRAFT - Specification Privacy Assessment - http://yrlesru.github.io/SPA/
>>> Please note that this will be a “bring your own lunch” meeting
> 
> 
Received on Thursday, 23 July 2015 17:42:19 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 23 July 2015 17:42:19 UTC