Re: Proposed feedback for TAG on their security questionnaire + PING questionnaire feedback

Thank you Greg for championing this work.

Some comments in line.


> On 19 Nov 2015, at 6:19 pm, Greg Norcie <> wrote:
> Hi all,
> One of my main goals for the New Year will be moving the PING questionnaire [1] forward. in order to achieve this goal, my thinking was that our questionnaire will supplement (not replace) the existing TAG questionnaire [2].

> My vision was that the TAG version would include a subset of the PING questions, hitting on a subset of high impact questions, whereas the PING questionnaire would eventually become a larger resource for spec developers looking to do a deep dive, as well as a resource to those new to PING who want to help out.

Any input we can provide to the TAG regarding [2] would be helpful. In my view, the PING questionnaire should:
- focus primarily on privacy
- have a cover note with a relatively short list of questions/issues and some recommended best practices for particular situations
- provide more detail regarding the issues raised by the questions (this is your idea for more of a deep dive/more comprehensive resource)
> Giri's email on 10/19 was extremely valuable and gave some great insight into where the TAG's questionnaire, as well as prompting me to think a lot about how our own questions could be improved.

Agree. Thank you Giri.
> I am going to list out some proposed changes to both below, and I'd love to hear thoughts from the rest of PING. My goal was that we would send feedback the Tuesday after American Thanksgiving (12/1).

Everyone, please provide your feedback on the list or come ready to discuss these points on 3 December 2015.
> Annyways moving on:
> proposed TAG questionnaire changes:
>  • For questions 3.1--3.13 and , we should change the wording to "How does" This forces spec authors to show their work rather than answer simply "yes" or "no".  
>   • If they're unsure about what the question wants (which will happen often until the Qs move out of alpha) they can say why they think they are meeting expectations
>  • Questions 3.8, 3.9, 3.11, and 3.12 lack an explanation. Each of these should have an explanation. 
>   • (I'd be happy to take first stabs)
>  • Question 3.4 could be reworded as ""Does this specification increase users’ fingerprintability?" so that the threat model is clearer to someone without a security/privacy background
>  • Question 3.13 should be reworded so that someone without a security background can answer it without reading 
>  • Q3.15 could be made clearer - text could be added explaining WHY persisting data is problematic. (tracking + simple shenanigans like filling someone's HD with junk data)

> proposed PING questionnaire changes:
> (Note: this is a little more high level, apologies for the lack of specific action items):
>  • The "PII" vs "personally derived data" debate (basically, US govt vs EU govt view) is going to make question 3 (“Does this specification generate personally derived data, and if so how will that data be handled?”) on the PING questionnaire particularly troublesome. I don’t have a good answer on how to reword it, but simply being mindful it will be a hot debate is a good first step. I'd love to have a discussion on how we can craft something that satisfies both sides of the pond.
>  • Expanding on the above point: Should our questionnaire discuss how the data is handled, or should PING limit ourselves to merely the collection, transmission, and processing of the data? 
>   • Do we want to get into issues such as "Is the data encrypted once it is received by the website" or "What does the website do with the data once it is received?"
>   • Would that be out of scope for PING? If so maybe we should state so explicitly to help avoid needless debates.)
> [1]

> [2]

> -- 
> /***********************************/
> Greg Norcie (
> Staff Technologist
> Center for Democracy & Technology
> 1634 Eye St NW Suite 1100
> Washington DC 20006
> (p) 202-637-9800
> PGP:

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

Received on Thursday, 26 November 2015 09:22:31 UTC