Re: PING - areas where contributions are needed

Hi Lukasz -

Very interesting problem statement.

At a high conceptual level, if you want a relationship (in this case, a consent relationship) to be transitive, then you need some form of assertion to be exchanged or recorded, confirming that consent.

The most “fashionable” way to achieve that is probably to go on social media and yell “blockchain is the answer, you idiots”…

However, I am an unfashionable oldie, so instead my thoughts turn to a concept that Ian Glazer expressed a few years ago, called “Relationship Context Metadata” (RCM). RCM is basically a signed wrapper that you put around an assertion to provide evidence of its origin and tamper-resistance. That would do for “hop one” of your consent relationship. For “hop two”, you wrap the whole thing again, so that the resulting package contains any constraints indicated by the first discloser, plus whatever the second discloser needs to exchange with the next recipient.

The wrappers could, of course, contain the URI of more detailed expressions of policy, privacy preferences etc..

Does that suggest any useful techniques for your use-case?

Yrs.,
Robin

Robin Wilton
Technical Outreach Director - Identity and Privacy
Internet Society

email: wilton@isoc.org
Phone: +44 705 005 2931
Twitter: @futureidentity

On 6 Oct 2015, at 15:30, Joseph Lorenzo Hall <joe@cdt.org> wrote:

> I think Nick would be the best positioned to engage in detail with the
> example you raise... I don't see a way to do transitive consent or
> transferrable consent that protects against what you are calling
> "consent laundering" unless there is some constraint imposed at time
> of consent giving (e.g., "it's ok/not ok to transfer my consent here
> to downstream parties").
> 
> There is a pretty big divide between US and EU models for consent and
> legal theories... Frederik Z-B and Aleecia MacDonald just presented a
> net paper at TPRC entitled "Do Not Track for Europe" that nicely
> outlines the pretty stark differences that the DNT standard would need
> to support to be usable in the EU:
> http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2588086
> 
> best, Joe
> 
> On Mon, Sep 28, 2015 at 3:19 PM, Lukasz Olejnik <lkasz.olejnik@gmail.com> wrote:
>> Dear all,
>> 
>> First of all, this is my first post here so greetings fellow PINGers! I hope
>> to contribute to PING's works here and there.
>> 
>> I would like to address the recent contribution request
>> (https://lists.w3.org/Archives/Public/public-privacy/2015JulSep/0138.html).
>> 
>> I wanted to highlight some, perhaps minuscule (perhaps not) things in
>> relation to the Tracking Compliance [3]
>> (http://www.w3.org/TR/2015/WD-tracking-compliance-20150714/#transitive-exceptions)
>> that might deserve a bit of scrutiny.
>> 
>> First of all, this is a good job. Let's hope deployment & actual enforcement
>> will follow later on.
>> 
>> Now my comments are directed solely at point 4 of this draft, the consent.
>> Specifically, 4.1 - about transitive consent for data sharing.
>> It is naturally a usability feature that has practical means and needs, i.e.
>> to transfer the consent to the service providers. I will follow the draft
>> text and
>> use here the example of ads providers as well.
>> 
>> First issue is whether it won't allow the, well, let's poetically call it
>> "consent laundering"?
>> 
>> Scenario:
>> 
>> 1. User has no previous knowledge of the existence of parties, say, A1, ...,
>> A100..
>> 2. User grants consent (for sharing data) to B.
>> 3. A1, ..., A100 do not wish to ask for consent, for whatever reason. So
>> they use
>> the service of B to transitively acquire it.
>> 
>> So perhaps an example party, say A37, could even inject scripts of B, who
>> then would inject scripts of A37...?
>> Since B can transfer consent, consent is granted to A37. In a manner similar
>> to cookie matching (e.g. using HTTP redirects, as in
>> https://developers.google.com/ad-exchange/rtb/cookie-guide).
>> I acknowledge the latter MUST clause, where I do not see any suggestions of
>> enforcement.
>> 
>> So this is a privacy case with possibly non-obvious implications where
>> consent is being transferred to other party, as a matter of service.
>> 
>> 
>> Another comment may touch the "inhibiting adoption" issue. Whether enough
>> flexibility in terms of consent is provided - provided there is a justified
>> need, that is.
>> In this case let's discuss a situation when, say, the user visits
>> site A, a consent (for sharing data) is given to other party B (level 1),
>> and then B (later on) transitively
>> provides this to other parties (level 2; C, D, ...), of which the user may
>> not be aware of.
>> So the thing here is: to how many parties the consent is being granted in
>> this mode? Also, how many levels of consent should be allowed? Should there
>> be any concept of levels at all?
>> 
>> But further, let's assume a site A is including scripts of B (with consent
>> for sharing data), who is an Ad Exchange, running a Real-Time Bidding
>> platform (https://developers.google.com/ad-exchange/rtb/). Then let's assume
>> this platform has 100 bidders - all of them receive data about the user
>> during the RTB protocol. Furthermore, let's say a bidder C wins and is able
>> to deliver an ad. Does C, who may possibly maintain its own tracking
>> infrastructure posses the consent due to the transitivity?
>> 
>> Even more specifically, what happens if C is also an Ad Exchange and runs
>> another round, and has also a number of bidders and in the end some other
>> party D wins and delivers the end-content. So the original consent might
>> possibly be granted to B, going through C and reaching D?
>> 
>> In this case, I think 4.1 is written quite well in terms of generality, but
>> are we sure about the levels of transitivity?
>> 
>> Now to sum it up, consent is obviously required. This is a core principle of
>> privacy. But should there be any limits to transitivity? Or perhaps the
>> points I highlighted might be addressed somehow?
>> 
>> Best regards
>> Lukasz Olejnik
> 
> 
> 
> --
> Joseph Lorenzo Hall
> Chief Technologist
> Center for Democracy & Technology
> 1634 I ST NW STE 1100
> Washington DC 20006-4011
> (p) 202-407-8825
> (f) 202-637-0968
> joe@cdt.org
> PGP: https://josephhall.org/gpg-key
> fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871
>