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

Hi all,

I agree that privacy/security shouldn't be limited to the privacy /
security section, but we probably want to have one central location which
contains references to all security/privacy issues mentioned.

On an unrelated note, I had been thinking that given the TAG's recent
finding on unsanctioned tracking, we might want to add a question:

*"Does this standard enhance an attacker's ability to perform unsanctioned
tracking?"*
While it isn't perfect, I feel like it would capture a large set of
behaviors (fingerprinting, supercookies etc) that are used to collect
information. As we've all seen, defining things like what is personal
information can be difficult, so focusing on problematic collection
behaviors is one way to solve that issue.

On Thu, Jul 23, 2015 at 1:41 PM, Frederick Hirsch <w3c@fjhirsch.com> wrote:

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


-- 
/***********************************/

*Greg Norcie (norcie@cdt.org <norcie@cdt.org>)*

*Staff Technologist*
*Center for Democracy & Technology*
1634 Eye St NW Suite 1100
Washington DC 20006
(p) 202-637-9800
PGP: http://norcie.com/pgp.txt

Fingerprint:
73DF-6710-520F-83FE-03B5
8407-2D0E-ABC3-E1AE-21F1

/***********************************/