Re: confirm and fingerprinting issues

I don’t know why we are changing design in these (subtle?) ways at this point. Can you remind me what we were trying to fix?

> On Aug 25, 2017, at 2:49 , Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote:
> 
> Hi Folks,
> 
> my goal would be to satisfy the requirements of the industry in this
> group ;-)
> 
> UNDERSTANDING THE PROBLEM
> 
> I would like to enhance our understanding before converging on a design.
> 
> I understand the fingerprinting risks of UGE for sub-domains
> (b1.site.com, bit2.site.com, ...). Mitigating the risks would be desirable.
> 
> I do not understand why this same risk is not there for the main site.
> 
> I also do not understand why site-wide exceptions should not be allowed
> (I do not see their fingerprinting risk) and I agree that allowing
> google to, e.g., ask for a "youtube.com" UGE in an iframe is a desirable
> use case.
> 
> ENUMERATING POTENTIAL SOLUTIONS
> 
> [1. Keep the old design] - allow UGE also for sub-contexts. This is the
> default unless we reach consensus to change something.
> 
> This would allow web-wide and site-specific.
> 
> One way to mitigate the fingerprinting risk of specific sub-domains in
> this scenario would be to limit the number of patterns that can be
> registered (e.g. 5 patterns should constitute at most 5 bits). This can
> be done as an implementation recommendation.
> 
> [2. Disallow UGE for sub-contexts] This would IMHO break the google
> usecase above, would mitigate the fingerprinting risk for sub-contexts,
> would still allow sites to use this bit-wise mechanism for fingerprinting.
> 
> [3. Only allow web-wide UGE for sub-contexts] This would mitigate
> fingerprinting for site-specific UGE. Since I did not understand why we
> wanted to disallow web-wide exceptions, I do not see a downside.
> 
> 
> DISCUSSION
> - I would appreciate if we continue populating the "understanding" and
> "potential solution" perspectives before picking a given solution.
> 
> By default (unless we reach a new consensus), we will stick to the old
> consensus and will not change the spec fundamentally. If we see a risk,
> I would add a note and see what feedback we receive.
> 
> 
> Any suggestions/input/feedback/solutions?
> 
> 
> Regards,
> matthias
> 
> 
> 
> 
> On 25.08.2017 10:03, Mike O'Neill wrote:
>> Hi Shane,
>> 
>> 
>> 
>> Only some industry.
>> 
>> 
>> 
>> The trend is for subresources to not be able to set a cookies, i.e.
>> Safari, especially the new ITB which effectively creates separate silos
>> for subresource cookies, i.e. they are not web-wide. If we allow
>> web-wide consent from iframes with no check I doubt most browsers will
>> implement it.
>> 
>> 
>> 
>> It also fails the “specific” test for lawful consent under EU DP/privacy
>> law.
>> 
>> 
>> 
>> 
>> 
>> Mike
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> *From:*Shane M Wiley [mailto:wileys@oath.com]
>> *Sent:* 25 August 2017 04:45
>> *To:* Mike O'Neill <michael.oneill@baycloud.com>
>> *Cc:* Matthias Schunter (Intel Corporation) <mts-std@schunter.org>;
>> public-tracking@w3.org; Roy T. Fielding <fielding@gbiv.com>
>> *Subject:* Re: confirm and fingerprinting issues
>> 
>> 
>> 
>> Working Group,
>> 
>> 
>> 
>> This will likely be a non-starter for industry then.  We specifically
>> reviewed this concept when the UGE API was first written and everyone
>> was supportive at that time ("NAI Opt-Out Model in reverse").  I'm
>> struggling to understand why a domain can set a cookie in an iFrame but
>> we're going to restrict setting an exception...?
>> 
>> 
>> 
>> - Shane
>> 
>> 
>> 
>> On Thu, Aug 24, 2017 at 2:18 PM, Mike O'Neill
>> <michael.oneill@baycloud.com <mailto:michael.oneill@baycloud.com>> wrote:
>> 
>>    Shane.
>> 
>> 
>> 
>>    Nope, web-wide was specifically ruled out see:
>>     https://w3c.github.io/dnt/drafts/tracking-dnt.html#exception-javascript-api-store
>>    6th para before end of section
>> 
>> 
>> 
>>    “This effectively limits the API for web-wide exceptions to the
>>    single target domain of the caller”
>> 
>> 
>> 
>>    What we said Monday was the site-specific in a an iframe was
>>    possible, but probably pointless.
>> 
>> 
>> 
>>    Mike
>> 
>> 
>> 
>> 
>> 
>>    *From:*Shane M Wiley [mailto:wileys@oath.com <mailto:wileys@oath.com>]
>>    *Sent:* 24 August 2017 20:49
>>    *To:* Mike O'Neill <michael.oneill@baycloud.com
>>    <mailto:michael.oneill@baycloud.com>>
>>    *Cc:* Matthias Schunter (Intel Corporation) <mts-std@schunter.org
>>    <mailto:mts-std@schunter.org>>; public-tracking@w3.org
>>    <mailto:public-tracking@w3.org>; Roy T. Fielding <fielding@gbiv.com
>>    <mailto:fielding@gbiv.com>>
>>    *Subject:* Re: confirm and fingerprinting issues
>> 
>> 
>> 
>>    Mike,
>> 
>> 
>>    Agreed on web-wide for those scenarios but I thought we confirmed on
>>    Monday that those would work in an iFramed approach?
>> 
>> 
>> 
>>    - Shane
>> 
>> 
>> 
>>    On Thu, Aug 24, 2017 at 12:39 PM, Mike O'Neill
>>    <michael.oneill@baycloud.com <mailto:michael.oneill@baycloud.com>>
>>    wrote:
>> 
>>        Shane,
>> 
>> 
>> 
>>        I think you need the web-wide exceptions for that and they are
>>        already disallowed for iframes (unless they are for cookie rule
>>        subdomains of the top-level domain). The site-specific exception
>>        is pointless for other-origin iframes, other than to specify
>>        same-party exceptions. It just lets you set a site-specific
>>        exception for the iframe domain when it is later visited as a
>>        first party.
>> 
>> 
>> 
>>        This way means you do not even have to use the iframes, it is
>>        much faster.
>> 
>> 
>> 
>>        Mike
>> 
>> 
>> 
>>        *From:*Shane M Wiley [mailto:wileys@oath.com
>>        <mailto:wileys@oath.com>]
>>        *Sent:* 24 August 2017 19:35
>>        *To:* Mike O'Neill <michael.oneill@baycloud.com
>>        <mailto:michael.oneill@baycloud.com>>
>>        *Cc:* Matthias Schunter (Intel Corporation)
>>        <mts-std@schunter.org <mailto:mts-std@schunter.org>>;
>>        public-tracking@w3.org <mailto:public-tracking@w3.org>; Roy T.
>>        Fielding <fielding@gbiv.com <mailto:fielding@gbiv.com>>
>>        *Subject:* Re: confirm and fingerprinting issues
>> 
>> 
>> 
>>        Mike,
>> 
>> 
>> 
>>        But wouldn't this break the industry "opt-in" page concept
>>        though (similar to the current "opt-out" iFrame model)?
>> 
>> 
>> 
>>        - Shane
>> 
>> 
>> 
>>        On Thu, Aug 24, 2017 at 11:05 AM, Mike O'Neill
>>        <michael.oneill@baycloud.com
>>        <mailto:michael.oneill@baycloud.com>> wrote:
>> 
>>            While restricting the API to top-level context stops it
>>            being used by bad
>>            actors (to invisibly fingerprint), it also stops the
>>            use-case Shane has
>>            identified of being able to assign consent to multiple
>>            domains. No longer
>>            will it be possible to call the API from an iframe, so top
>>            level script will
>>            not be able to dynamically create browsing contexts that do
>>            that.
>> 
>>            I think the only way to fix the security weakness is to stop
>>            sub-resources
>>            using the API, but it is very desirable to still allow the
>>            registering of
>>            exceptions for other-origin (though same-party) domains.
>>            This will be useful
>>            not just to larger sites.
>> 
>>            I think both can be done as long as a check is made that the
>>            script-origin
>>            controls the other domains. The security and privacy benefit
>>            of disallowing
>>            subresources using the API far outweighs any threat from
>>            first-parties
>>            getting it wrong.
>> 
>>            I spent today amending the API to show how this could be
>>            specified using the
>>            same-party array:
>> 
>>            https://w3c.github.io/dnt/drafts/samepartyawareapi.html#exceptions
>> 
>>            See Section 6. It is in a new file to be web readable. It
>>            would be easy to
>>            create a PR for it against the master branch.
>> 
>>            Another possible way to check that script origins control
>>            other origins is
>>            to use CORS (or fetch) , but this adds round-trips and
>>            therefore would be
>>            slow. The same-party way will be a lot more efficient.  We
>>            could add
>>            CORS/fetch as belt and braces if people thought it necessary.
>> 
>>            Please take the time to consider this before Monday's call.
>> 
>> 
>>            Mike
>> 
>> 
>>            -----Original Message-----
>>            From: Matthias Schunter (Intel Corporation)
>>            [mailto:mts-std@schunter.org <mailto:mts-std@schunter.org>]
>>            Sent: 22 August 2017 11:59
>>            To: public-tracking@w3.org <mailto:public-tracking@w3.org>
>>            Subject: Re: confirm and fingerprinting issues
>> 
>>            Hi Mike,
>> 
>> 
>>            thanks for the clarification.
>> 
>>            I believe your resolution should substantially reduce the
>>            fingerprinting
>>            isk.
>> 
>>            Any other concerns/objections?
>> 
>> 
>>            Regards,
>>            matthias
>> 
>> 
>> 
>>            On 22.08.2017 11 <tel:22.08.2017%2011>:31, Mike O'Neill wrote:
>>> Matthias, subresources are already denied making web-wide
>>            extensions (by
>>> Roy's last change). My suggestion is to generalise his
>>            sentence to cover
>>> site-specific also.
>>> 
>>> Mike
>>> 
>>> -----Original Message-----
>>> From: Matthias Schunter (Intel Corporation)
>>            [mailto:mts-std@schunter.org <mailto:mts-std@schunter.org>]
>>> Sent: 22 August 2017 09:39
>>> To: public-tracking@w3.org <mailto:public-tracking@w3.org>
>>> Subject: Re: confirm and fingerprinting issues
>>> 
>>> Hi Mike,
>>> 
>>> thanks for the clarification.
>>> 
>>> I now (hopefully) understand: Instead of pushing an
>>            identifier as a
>>> whole (9437489), you push individual bits (bit1-0, bit2-1,
>>            bit3-1, ...).
>>> Then querying them gets efficient; only say 32 queries
>>            (one per bit)
>>> needed ;-(
>>> 
>>> Thos the "you can only query what you store" approach does
>>            not mitigate
>>> this fingerprinting risk (it is efficient to query 32 bits).
>>> 
>>> Your suggested mitigation is to disallow subresources from
>>            requesting
>>> user-granted _site-specific_ exceptions (only the main
>>            site is allowed
>>> to do so). They would still be allowed to request web-wide
>>            exceptions
>>> (where this risk does not seem to exist).
>>> 
>>> This seems to be a workable and efficient solution.
>>> 
>>> Any thoughts?
>>> 
>>> 
>>> Regards,
>>> matthias
>>> 
>>> PS: Am I right that the main site could still use
>>            site-specific UGE
>>> approach for fingerprinting? Anything we can mitigate for
>>            them?
>>> 
>>> 
>>> 
>>> On 22.08.2017 10 <tel:22.08.2017%2010>:22, Mike O'Neill wrote:
>>>> Hi Matthias,
>>>> 
>>>> That is not quite what I meant. The fingerprinting I
>>            identified would
>>> allow
>>>> the subresource to assign a random number (up to 32 bits
>>            long in my
>>>> example), because there are 32 sub-subresources (lets
>>            call them
>>>> grandchildren of the first-party site):
>>>> 
>>>> b0.images.schunter.org <http://b0.images.schunter.org>
>>>> b1.images.schunter.org <http://b1.images.schunter.org>
>>>> b2.images.schunter.org <http://b2.images.schunter.org>
>>>>                  .
>>>>                  .
>>>>                  .
>>>> B31.images.schunter.org <http://B31.images.schunter.org>
>>>> 
>>>> Each grandchild represents one bit in the 32 bit string.
>>>> 
>>>> If an exception exists for a particular grandchild, that
>>            represents a 0
>>            at
>>>> that particular bit position
>>>> Otherwise the value of the bit is 1.
>>>> 
>>>> The value of each grandchild "bit" is communicated back to
>>>> images.schunter.org <http://images.schunter.org> by each
>>            grandchild detecting its DNT header (say by
>>>> reading navigator.doNotTrack), then sending the 1 bit
>>            value in a message
>>>> using the postMessage API.
>>>> 
>>>> Then images.schunter.org <http://images.schunter.org>
>>            receives all these messages and assembles the
>>>> original 32 bit string from them.
>>>> 
>>>> Note, this does not need the confirm call, though it
>>            could. Restricting
>>> the
>>>> confirm call does not fix the risk because the same
>>            information can be
>>>> obtained via postMessage.
>>>> 
>>>> This is complicated, but it is just javascript. Once it
>>            is done it will
>>            be
>>>> easy to reproduce. It gives subresources the ability to
>>            generate UIDs
>>            even
>>>> when they are blocked from using cookies e.g. on Safari.
>>            There are
>>            already
>>>> other more complicated methods for doing this in the
>>            wild, one of the
>>>> reasons for Apple's ITB in OS11.
>>>> 
>>>> 
>>>> 
>>>> Mike
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: Matthias Schunter (Intel Corporation)
>>            [mailto:mts-std@schunter.org <mailto:mts-std@schunter.org>]
>> 
>>>> Sent: 22 August 2017 07:44
>>>> To: Michael O'Neill <michael.oneill@btinternet.com
>>            <mailto:michael.oneill@btinternet.com>>;
>>> public-tracking@w3.org <mailto:public-tracking@w3.org>
>>>> Cc: 'Roy T. Fielding' <fielding@gbiv.com
>>            <mailto:fielding@gbiv.com>>
>>>> Subject: Re: confirm and fingerprinting issues
>>>> 
>>>> Hi Mike,
>>>> 
>>>> 
>>>> thanks a lot for the analysis of fingerprinting.
>>>> 
>>>> If I understand correctly, a sub-resource (say
>>            images.schunter.org <http://images.schunter.org>) can
>>>> obtain an exception for its
>>            "tracker7289437923.images.schunter.org
>>            <http://tracker7289437923.images.schunter.org>"
>>>> where tracker7289437923 is unique to a user for this
>>            subdomain. Since
>>>> tracker7289437923 is unique, your concern is that by
>>            learning that there
>>>> is a UGE for tracker7289437923, the site knows what user
>>            is visiting.
>>>> 
>>>> I believe that this is not a severe fingerprinting risk
>>            for the
>>>> following reason:
>>>> 
>>>> Assume that the web-site has registered a table of UGEs
>>>>  TRACKERID          NAME
>>>>  tracker7289437923  Joe
>>>>  tracker728laksdjh  Jim
>>>>  trackerk823982089  Helen
>>>>  ....
>>>> 
>>>> In theory, obtaining a line from this table allows
>>            fingerprinting.
>>>> However, our "confirm" API only allows to verify whether
>>            a single line
>>>> exists. I.e. I could indeed confirm whether I am talking
>>            to a given user:
>>>> - if confirm("tracker7289437923.images.schunter.org
>>            <http://tracker7289437923.images.schunter.org>") is true,
>>            then I am
>>>> talking to Joe.
>>>> 
>>>> However, using the scheme to fingerprint larger numbers
>>            of users seems
>>>> not really feasible: One needs to call the confirm() API
>>            once for each
>>>> subdomain that corresponds to each potential user:
>>>>  tracker7289437923
>>>>  tracker728laksdjh
>>>>  trackerk823982089
>>>>  ....
>>>> 
>>>> Ensuring this was the rationale (AFAIR) that David Signer
>>            insisted that
>>>> confirm must be called with the exact parameters of the
>>            store() call.
>>>> 
>>>> What do you think? If we agree that there is still a
>>            larger risk, we
>>>> should investigate your potential resolution (which I
>>            have not checked
>>>> in detail yet; since I am not 100% sure I see the risk).
>>>> 
>>>> Any feedback is welcome!
>>>> 
>>>> matthias
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 21.08.2017 21 <tel:21.08.2017%2021>:19, Michael
>>            O'Neill wrote:
>>>>> I think the web-wide issue is fine with Roy's sentence:
>>>>> 
>>>>> For each of the targets in a web-wide exception, a user
>>            agent must not
>>>> store
>>>>> the duplets and must reject the promise with a
>>            DOMException named
>>>>> "SecurityError" unless the target domain matches both the
>>>> document.domain of
>>>>> the script's responsible document and the
>>            document.domain of the
>>>> top-level
>>>>> browsing context's active document [HTML5]. This
>>            effectively limits the
>>>> API
>>>>> for web-wide exceptions to the single target domain of
>>            the caller.
>>>>> 
>>>>> This limits web-wide consent to the top-level browsing
>>            context which was
>>>> how
>>>>> it always was supposed to be.
>>>>> 
>>>>> But as the text is now, a subresource browsing context
>>            (aka an iframe)
>>>> can
>>>>> still specify a site-specific exception for itself and
>>            its own set of
>>>>> targets. This could be a danger because it allows a
>>            third-party
>>>> subresource
>>>>> to invisibly create arbitrary exceptions for itself,
>>            which it can then
>>>> use
>>>>> to fingerprint the user agent. It would do this by
>>            creating  a set of
>>>>> subresource iframes and establishing a UGEs for a random
>>            set of them.
>>>>> 
>>>>> For example, subresorce.com <http://subresorce.com>
>>            loads 32 child  iframes b0.subresource.com
>>            <http://b0.subresource.com>,
>>>>> b1.subresource.com <http://b1.subresource.com>, ...,
>>            b31.subresource.com <http://b31.subresource.com>.
>>>>> 
>>>>> When it exists as a subresource on top-level site
>>            example.com <http://example.com> for user
>>>> Alice
>>>>> it creates a UGE for targets bX.subresource.com
>>            <http://bX.subresource.com>, bY.subresource.com
>>            <http://bY.subresource.com>,
>>>> ...,
>>>>> bZ.subresource.com <http://bZ.subresource.com> . i.e. a
>>            random 32 bit pattern unique to Alice.
>>>>> 
>>>>> When Alice later revisits example.com
>>            <http://example.com> DNT:0 will be sent in requests for
>>>> the
>>>>> subset of targets specified in the UGE. These
>>            subresources can then
>>>>> communicate back to the parent subresource the value of
>>            DNT they have
>>>>> received, using the postMessage API. Thus
>>            subresource.com <http://subresource.com> can recognise
>>>>> Alice without having to place a third-party cookie. It
>>            cannot do this
>>>> for
>>>>> sites other than example.com <http://example.com>, but
>>            it is still a privacy risk.
>>>>> 
>>>>> We do not have a use case for a subresource initiated
>>            site-specific UGE,
>>>> so
>>>>> why do we need it? the easiest way to fix this is simply
>>            to adopt Roy's
>>>>> wording for all UGEs, not just web-wide ones.
>>>>> 
>>>>> For the other issue, making the confirm call (now called
>>>>> Navigator.trackingExceptionExists) capable of confirming
>>            exceptions for
>>>>> cookie rule subdomains as
>>            Navigator.storeTrackingException does, I
>>>> suggest
>>>>> the following derived from Roy's definition of "site" for
>>>>> storeTrackingException, with a lone "*" illegal:
>>>>> 
>>>>> site
>>>>> The referring domain scope where an exception should be
>>            confirmed:
>>>>> If site is undefined, null, or the empty string, the
>>            referring domain
>>>> scope
>>>>> defaults to the [site domain].
>>>>> Otherwise, the referring domain scope is defined by a
>>            domain found in
>>>> site
>>>>> that is treated in the same way as the domain parameter
>>            to cookies
>>>>> [RFC6265], allowing subdomains to be included with the
>>            prefix "*.". The
>>>>> value can be set to a fully-qualified right-hand segment
>>            of the document
>>>>> host name, up to one level below TLD. If such a domain
>>            scope cannot be
>>>>> parsed then the user agent must reject the promise with
>>            the DOMException
>>>>> named "SecurityError"
>>>>> 
>>>>> Comments?
>>>>> 
>>>>> Mike
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> 
>> 
>>        -- 
>> 
>>        - Shane
>> 
>> 
>> 
>>        Shane Wiley
>> 
>>        VP, Privacy
>> 
>>        Oath: A Verizon Company
>> 
>> 
>> 
>> 
>> 
>>    -- 
>> 
>>    - Shane
>> 
>> 
>> 
>>    Shane Wiley
>> 
>>    VP, Privacy
>> 
>>    Oath: A Verizon Company
>> 
>> 
>> 
>> 
>> 
>> -- 
>> 
>> - Shane
>> 
>> 
>> 
>> Shane Wiley
>> 
>> VP, Privacy
>> 
>> Oath: A Verizon Company

Dave Singer

singer@mac.com

Received on Monday, 28 August 2017 15:05:02 UTC