Re: Action 368 - Definition of Service Provider/Data Processor

On Wednesday 27 March 2013 00:22:52 Roy T. Fielding wrote:
> The addition of business associate here doesn't help

+1 (and deviates considerably from the initial wording)
> 
> The last normative paragraph ("may merge and use data") is backwards.

agree

> A service provider almost always collects data on behalf of all of
> its customers via a single stream. Once received, the incoming
> data stream is processed per HTTP request: first to conform
> to applicable regional requirements and then to the specific
> requirements of the request target (which identifies the party).
> Finally, any results or retained data from that processing is
> siloed per party (customer of the SP).

clear description
> 
> Prior to that separation process, 
> there might be raw logfiles,
=> permitted uses allow for that
> short-term debugging traces, 
=> debugging is allowed and agnostic here
> and aggregate statistical counters
for the controller or by the processor for the processor?

> based on the combined incoming stream, as is true of any Internet
> service run at this scale, 
which is perfectly acceptable IMHO and if this is unclear, we should add 
the acceptance into the text. 

> for the sole purpose of keeping the
> service alive and estimating capacity. 
I don't see a hindrance in DNT to do that. 

> Aside from active debugging
> or keeping a confidential record of actual security/systemic failure
> incidents, 
they are a permitted use AFAIK

> I would expect SPs to delete or de-identify such data
> before it could be retained long-term (more than a few days) or
> shared with anyone outside the operations team, and only when
> that is permitted by the respective data controllers.

which obeys to the general principles that apply to all permitted uses.
> 
> I don't see DNT:1 changing the above, since it is not subject
> to the user's preferences.  
Me neither as you never go beyond permitted uses. Only for "own 
uses/processing" the data processor needs permitted uses, because, as 
you rightly point out: 
> Moreover, I think it should be
> assumed that an SP can do anything permitted of the party for
> which it is contracting so long as the resulting data is
> controlled by that party.

> 
> Naturally, the incoming data stream is never seen by the SP's
> customers -- each party only has restricted access to its own data
> after the separation process, and usually has some sort of
> dashboard-level visibility into the aggregate statistical counts.

The statistical counts over the entire stream may be subject to 
discussion. They do not constitute a risk as long as those are not fine 
grained. But if they are super fine grained, they go clearly beyond what 
you could do under DNT:1 as a data processor. 
> 
> With regards to text changes, I think the existing text in the
> compliance section 3.4:
> 
>   Outsourced service providers are considered to be the same party
>   as their clients if the outsourced service providers only act as
>   data processors on behalf of that party in relation to that party,
>   silo the data so that it cannot be accessed by other parties,
>   and have no control over the use or sharing of that data except
>   as directed by that party.
> 
> is better than the proposed changes but still needs some tweaks
> once we agree on what terms to use for both the SP and the customer
> of SP.  The current use of "clients" here to mean customers is
> ambiguous with HTTP's clients, I am not sure what
> "on behalf of that party in relation to that party" means (perhaps
> a paste-o?), and "silo the data so that it cannot be accessed by
> other parties" is overly restrictive.  For example, the data is
> siloed per customer (data controller), but access is controlled
> by the data controller; thus, a customer might provide that access
> to some other parties, such as other contractors that have been
> paid to analyze the collected data.

I agree on the ambiguity of the currently used terms. Unfortunately, 
some people think it is a dangerous cultural setback if we use the 
(clear) terms "controller" and "processor". 
> 
> Unfortunately, I will have to take an action on that (due next
> week) if I need to propose exact text for the draft.

My suggestion would be to keep the text in 3.4 as is and add some text 
about the statistical aggregation of the entire stream (limit the 
granularity)

 --Rigo

Received on Wednesday, 27 March 2013 11:08:24 UTC