RE: updating Compliance doc with graduated response

David,

I'm okay with "more discussion needed" - please open an issue if needed.  I'd like to remove this concept as it creates a false option for implementers.

- Shane

-----Original Message-----
From: David Singer [mailto:singer@apple.com] 
Sent: Monday, September 23, 2013 7:01 PM
To: Shane M Wiley
Cc: Nicholas Doty; public-tracking@w3.org List
Subject: Re: updating Compliance doc with graduated response


On Sep 23, 2013, at 18:39 , Shane M Wiley <wileys@yahoo-inc.com> wrote:

> I object to this being added.  New Issue?  
> 
> 'Graduated Response' is not a viable approach to Security.  While I appreciate how this approach sounds perfectly acceptable from a logical perspective, in practice this doesn't work.  This was highlighted during the Sunnyvale face-to-face where the "security expert" agreed that attempting to collect more data from a user over time would likely tip off the suspected bad actor that they were being tracked in a differentiated manner - something you would not want to as they would quickly change tactics - creating another security risk/channel.
> 
> I've attempted to convey our security experts views in this area and thought the Sunnyvale session clearly demonstrated there is little value to this approach and creates a false expectation by placing this in the Compliance and Scope document.  More than happy to continue documenting though and have true security experts provide this feedback to the group.

We probably need to debate this more (sadly) but the "when feasible" introduction does seem to allow your experts some...latitude.

I think the point of graduated response is a basic "you are not recording everything all the time".  Whether/how you achieve that, it's preferred.

> 
> - Shane
> 
> -----Original Message-----
> From: Nicholas Doty [mailto:npdoty@w3.org] 
> Sent: Friday, September 20, 2013 9:59 PM
> To: public-tracking@w3.org List
> Subject: updating Compliance doc with graduated response
> 
> Attached is a diff proposed to add a definition of graduated response and then a non-normative section in the security permitted use. I believe this implements the group's decision on a call in July. (Text included below if you want to read the changes.)
> 
> Thanks,
> Nick
> 
> 214a215,220
>> 			<section id="graduated-response">
>> 				<h3>Graduated Response</h3>
>> 				<p>
>> 					A <dfn>graduated response</dfn> a methodology where the action taken is proportional to the size of the problem or risk that is trying to be mitigated. In the context of this document, the term is used to describe an increase in the collection of data about a user or transaction in response to a specific problem that a party has become aware of, such as an increase in fraudulent activity originating from a particular network or IP address range resulting in increased logging of data relating to transactions from that specific range of IP addresses as opposed to increased logging for all users in general.
>> 				</p>
>> 			</section>
> 442a449,452
>>  			<section id="security-graduated" class="informative">
>>  				<h4>Graduated Responses for Security</h4>
>>  				When feasible, a <a>graduated response</a> to a detected security incident is preferred over widespread data collection. An example would be recording all use from a given IP address range, regardless of DNT signal, if the party believes it is seeing a coordinated attack on its service (such as click fraud) from that IP address range. Similarly, if an attack shared some other identifiable fingerprint, such as a combination of user agent string and other protocol information, the party could retain logs on all transactions matching that fingerprint until it can be determined that they are not associated with such an attack or such retention is no longer necessary to support prosecution.
>>  			</section>
> 
> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Tuesday, 24 September 2013 03:07:03 UTC