Delivery-Date: Sun, 24 Apr 2016 19:13:43 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	RCVD_IN_DNSWL_MED,T_DKIM_INVALID,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 247E91E00AF;
	Sun, 24 Apr 2016 19:13:41 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 7FA073A443;
	Sun, 24 Apr 2016 23:13:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 513883A42C
 for <tor-talk@lists.torproject.org>; Sun, 24 Apr 2016 23:13:34 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id T4iVoi_-NJWy for <tor-talk@lists.torproject.org>;
 Sun, 24 Apr 2016 23:13:34 +0000 (UTC)
Received: from mail-io0-x236.google.com (mail-io0-x236.google.com
 [IPv6:2607:f8b0:4001:c06::236])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 228E03A42A
 for <tor-talk@lists.torproject.org>; Sun, 24 Apr 2016 23:13:33 +0000 (UTC)
Received: by mail-io0-x236.google.com with SMTP id f89so136108735ioi.0
 for <tor-talk@lists.torproject.org>; Sun, 24 Apr 2016 16:13:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=bentasker.co.uk; s=google;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to;
 bh=ztNLRdHV0RasTmVfUXKCiw3DWhXfvSKx9eDY2M+Lb/g=;
 b=OLmCfddTANimsB7Dk6pCoyWkcfUVkV8wHWM8RcNZYEayoH9COz/jYctCGF6qgT2fzT
 om/1qXO0cNxB4EzXxTHdhKjq5FpZ076AVSVsyBdz94DwPgsZaHORZhGyWYoiaYmQidWZ
 FWvSsBvL//kIu/PXk5DKZLaDw5jCjX/PAfyR8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:in-reply-to:references:date
 :message-id:subject:from:to;
 bh=ztNLRdHV0RasTmVfUXKCiw3DWhXfvSKx9eDY2M+Lb/g=;
 b=T8GMKj5bLcKgg7+R2+P1l8z/Fp6buPtAta4tlXP2wHVyIouIHbdc7eWYN80BD9G50o
 jITzUh0I8S+Nm2qBRueYVGeq5RBcIeCxokVtvdgKo+YxuKJbAcMrjKj9eg2U2HISHvAd
 N1m2YAqvga0vx04fclgRlNx/Tt8v3dLPp/7bSsQ9BP8atBLBBUhqpNxw4yhElJJx7vXP
 Or6qlmHb9i4VzR05nVCTJQwhgltPIgsN0/0ZQBYaKqt6xEPZZzFVP7flLqEeNU0UM+LF
 KRXvAa6HFXs0G4OzasQpKW6iZE5y/1HA0y50rTstR2VSfhknuwBc8FWPCcFQ8LNSa3e+
 j1eQ==
X-Gm-Message-State: AOPr4FXWaTyJXGBH1jjceTaM6OFUBbOJZ4Nhp9BZcgX0EkoamB1f3s/aBnM8+BjnNL1JK1VQS+wSjsbWmO4QGQ==
MIME-Version: 1.0
X-Received: by 10.107.192.129 with SMTP id q123mr34814970iof.197.1461539611568; 
 Sun, 24 Apr 2016 16:13:31 -0700 (PDT)
Received: by 10.64.246.134 with HTTP; Sun, 24 Apr 2016 16:13:31 -0700 (PDT)
X-Originating-IP: [81.134.152.4]
In-Reply-To: <571D49DA.2090904@gmx.com>
References: <1461417342.6149.17.camel@pentium.freedom.box>
 <571BC6FE.5080205@gmx.com>
 <1461441264.6149.45.camel@pentium.freedom.box>
 <571BF566.4010200@gmx.com>
 <CABMkiz6J4=4Day4EQ=X045EBa5O0YKxkxgZHA0wrMHKg430f3A@mail.gmail.com>
 <571D49DA.2090904@gmx.com>
Date: Mon, 25 Apr 2016 00:13:31 +0100
Message-ID: <CABMkiz6jKaxenm9gBGPmx+dNditn7T32JWNaAfUKU1zW12ObAQ@mail.gmail.com>
From: Ben Tasker <ben@bentasker.co.uk>
To: tor-talk@lists.torproject.org
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [tor-talk] 12.7 percent of the domains I visit are intercepted
	by CloudFlare
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

> I know little about Cloudflare's actual operation.  What's the
implication / danger of one entity setting  cookies on multiple or 1000's
of  sites?

In theory it shouldn't be an issue, so long as they can't somehow tie the
multiple cookies together.

The problem being there are a wide range of fingerprinting techniques they
could use to do just that. On the flipside though, if they're willing to go
to those lengths then the cookie doesn't add a huge amount of value to
their operation. The potential risks, really, are more a product of one
party being the endpoint for so many sites.

CF claim that cookie is used only to indicate you got past security -
https://support.cloudflare.com/hc/en-us/articles/200170156-What-does-the-CloudFlare-cfduid-cookie-do-
- which is _probably_ true.

If they were setting a third party cookie (e.g. with a domain of
nottrackingyou.cloudflare.com) it'd be a slightly different story, as
they'd then be able to track you across domains, based on that cookie.


> I've also read (true or not) that lots of sites sell customer / member
data on cookies & IPa's to tracking companies or advertisers.

They sure do. Some go even further -  a little while back Verizon decided
to add a unique (to the subscriber) HTTP header to any outgoing (mobile
IIRC) requests so that their advertising buddies could easily track their
users and generate some revenue. Completely transparent to the user, unless
you happen to take a PCAP at the other end, or visit somewhere that
displays the request headers it received from you.

It had the particularly "pleasant" side-effect, that if you deleted
cookies, when the advertising platform next saw you, it'd set a new one,
pull the UID out of the injected header and link your new ID to the old one.

Selling individual (first-party) cookie details isn't particularly worth
while, even for a large site, as advertisers generally see more profit in
profiling your behaviour as far across the net as possible. IP's are in a
similar position, though I suspect they have some value if you're able to
show one user always visits your site from IP 1.1.1.1 - indicating they
either use a single proxy as a matter of course, or they've got a static IP
on their home connection (ker-ching, easy tracking)



> Years ago, lots of sites didn't require cookies just to browse.  Now many
do - just to take a peek, or it won't work right.  Maybe that's because the
cookies can be turned into cash?

That's definitely a driver for some. But, back in the day, most sites were
static and users interaction was largely limited to reading. A lot of sites
today run on content management systems, so will set (at least) a session
cookie in case you try to do something that would require a statefulness
(even if there's nothing like that enabled on the site....). There's also
(IMO) an aspect of laziness/stupidity - you can find sites where the
developer has decided that controlling the theme and page layout is best
done by setting a shedload of cookies and then reading them back with
javascript.




On Sun, Apr 24, 2016 at 11:34 PM, Joe Btfsplk <joebtfsplk@gmx.com> wrote:

> On 4/23/2016 5:44 PM, Ben Tasker wrote:
>
>> My guess is it is set by abc.com, but the " name" of the cookie involves
>>>
>> "cloudflare?"
>>
>> Keep in mind that Cloudflare is essentially a glorified bunch of reverse
>> proxies. Because Cloudflare terminates your TCP connection to abc.com,
>> they're in a position to set cookies _as_ abc.com. So I'd fully expect
>> the
>> site name to be abc.com, though it's naughty of them. The browser won't
>> consider it thirdparty, because it isn't - it was set by abc.com. This
>> does
>> seem to be the case (picking a site that uses cloudflare randomly from a
>> list):
>>
>> $ GET -Ssed  http://absolutewealth.com | grep Set-Co
>> Set-Cookie: __cfduid=dfcadd8517f9edb7f6fd202c7152da9861461451390;
>> expires=Sun, 23-Apr-17 22:43:10 GMT; path=/; domain=.absolutewealth.com;
>> HttpOnly
>>
>>
>> What it does mean, though, is when you visit xyz.com, the browser won't
>> present the cookie set earlier by abc.com. So it's use in tracking across
>> domains is incredibly limited. Pretty useful for tracking return visits to
>> abc.com (and it's subdomains) though
>>
>> Ben
>>
>> I know little about Cloudflare's actual operation.  What's the
> implication / danger of one entity setting  cookies on multiple or 1000's
> of  sites?
> I've also read (true or not) that lots of sites sell customer / member
> data on cookies & IPa's to tracking companies or advertisers.  Maybe not
> names or credit cards, but...
>
> Years ago, lots of sites didn't require cookies just to browse.  Now many
> do - just to take a peek, or it won't work right.  Maybe that's because the
> cookies can be turned into cash?
> I'm startin me some websites.  Yee-haw!
>
>
>
> --
> tor-talk mailing list - tor-talk@lists.torproject.org
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>



-- 
Ben Tasker
https://www.bentasker.co.uk
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

