Re: ISSUE-24 (fraud detection and defense)

On Oct 9, 2014, at 13:41 , Shane M Wiley <wileys@yahoo-inc.com> wrote:

> Justin,
>  
> I’d rather we drop the 2nd paragraph.  I’ve spoken to many security experts – including the security expert “live” at the October Sunnyvale F2F - and everyone agrees that the most effective security approach is to start with a larger net and then minimize from there as you’re able to determine traffic is not suspicious.  Attempting to go the reverse direction is not effective and would allow many “bad guys” through.  As companies are all alone in this fight, we need every tool in our arsenal for this very specific permitted use.  Companies instead should look to data minimization and data segregation principles to ensure the proportional use of this information.

I think we can achieve that if we change the word/concept “graduated”, which I understand you take to mean that you can only ramp up.  Instead, if we explain that you can’t use this as a reason to collect all the data all the time, but instead, for example (this is not spec. text):

a) start with careful monitoring, and reduce from there as confidence grows and you learn what monitoring is effective to detect problems
b) use light monitoring until a problem is detected, and then use focused heavier monitoring to determine its nature, details, origins etc.
c) use statistical techniques or other quality control techniques for checking (e.g. random sampling)

We somehow have to leave it possible to do reasonable fraud detection and analysis while not leaving the barn door open to indifferent permanent collection. The first paragraph alone doesn’t do this, unfortunately. 

In addition, now we’re back critiquing, the first paragraph implies that the only ‘other use’ restriction on this data is "not used for operational behavior (profiling or personalization) beyond what is reasonably necessary”, but this is wrong.  Data collected for a permitted must not be used for ANY other purpose; this is a general statement about all permitted uses.

Finally, I think that we may need to re-state the other general requirement on data collected for a permitted use: it has to be applicable to that use. Certain types of data are not going to help you either detect or analyze fraud, so don’t collect it.  If you collect it, you should imagine that at some time you’ll have to justify why it could be useful (or ideally was, in fact, used).

So, three problems:

* graduated response is only one way of achieving ‘not everything all the time’, we need to be more general here to allow security people to operate reasonably
* this permitted use requires, like all permitted uses:
  * that data collected for security and fraud detection and analysis needs to be usable for that purpose
  * that it not be used for any other purpose

>  
> - Shane
>  
> From: Justin Brookman [mailto:jbrookman@cdt.org] 
> Sent: Thursday, October 09, 2014 1:19 PM
> To: public-tracking@w3.org (public-tracking@w3.org)
> Subject: ISSUE-24 (fraud detection and defense)
>  
> Hello all, last October we came very close to final agreement on language on the fraud/security permitted use:
>  
> Regardless of the tracking preference expressed, data MAY be collected, retained, and used to the extent reasonably necessary to detect security incidents, protect the service against malicious, deceptive, fraudulent, or illegal activity, and prosecute those responsible for such activity, provided that such data is not used for operational behavior (profiling or personalization) beyond what is reasonably necessary to protect the service or institute a graduated response.
> When feasible, a graduated response 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 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.
>  
> However, Shane strongly objected to the language and the issue has remain unresolved.  So I am inclined to go for a Call for Objections on the issue.  Shane, would your proposal just end in the first paragraph after “to protect the service”?  Or do you wish to propose something different?
> 
> Justin Brookman
> Director, Consumer Privacy
> Center for Democracy & Technology
> 202.407.8812
> @JustinBrookman

David Singer
Manager, Software Standards, Apple Inc.

Received on Thursday, 9 October 2014 22:34:14 UTC