Subject: [ietf-privacy] ITU, DPI, and Deliberate Obscurity

From: Dean Willis <[email-masked]>
Date: Sun, 9 Dec 2012 10:55:30 -0600

If you aren't following tho, see:

http://www.theregister.co.uk/2012/12/06/dpi_standard_leaked/?utm_source=twitterfeed&utm_medium=twitter

A couple of years back we had some discussion about the need to design IETF protocols to be DPI resistant. One principle that I think should guide our efforts is that not only should each protocol be itself DPI resistant, but it should deliberately assist other protocols in being DPI resistant. I call this "intentional mutual obscurity".

Compare it to camouflage. In the city, one person wearing camo will stand out and be noticed. But in the woods during hunting season (or on the battlefield), everybody is camouflaged  and nobody stands out.  It also works for herds of zebras, it works for schools of fish, and it should work for flocks of packets.

You may remember thinking that this position was a little "extreme" when I proposed it.

With the ITU insisting on designing deep packet inspection into the network at the behest of dictators, tyrants, and thugs at various levels of political regimes, perhaps we're ready to reconsider?

--
Dean

---

From: SM <[email-masked]>
Date: Sun, 09 Dec 2012 09:46:43 -0800

Hi Dean,
At 08:55 09-12-2012, Dean Willis wrote:
>A couple of years back we had some discussion about the need to 
>design IETF protocols to be DPI resistant. One principle that I 
>think should guide our efforts is that not only should each protocol 
>be itself DPI resistant, but it should deliberately assist other 
>protocols in being DPI resistant. I call this "intentional mutual obscurity".

Is this about security or privacy?

>You may remember thinking that this position was a little "extreme" 

:-)

>With the ITU insisting on designing deep packet inspection into the 
>network at the behest of dictators, tyrants, and thugs at various 
>levels of political regimes, perhaps we're ready to reconsider?

I thought that deep packet inspection was also used by regimes which 
label themselves as democratic to remove illegal content from their 
national network.  Anyway, deliberately obscurity prompts people to 
build better mouse traps.  It is well known that mouse traps can 
always be improved. :-)

Regards,
-sm

---

From: Johan Pouwelse <[email-masked]>
Date: Mon, 10 Dec 2012 12:54:28 +0100

Hello again Dean,

On 9 December 2012 17:55, Dean Willis <[email-masked]> wrote:
> A couple of years back we had some discussion about the need to design IETF
> protocols to be DPI resistant. One principle that I think should guide our
> efforts is that not only should each protocol be itself DPI resistant, but
> it should deliberately assist other protocols in being DPI resistant.

Interesting topic. We worked closely with a company who also provides
DPI equipment once upon a time.
It proved difficult for me to think how to address the DPI threat,
especially long term.

> With the ITU insisting on designing deep packet inspection into the network
> at the behest of dictators, tyrants, and thugs at various levels of
> political regimes, perhaps we're ready to reconsider?

Is it even possible to beat DPI? (given the probable mousetrap
improvement cycle)

> it works for schools of fish, and it should work for flocks of packets.

Indeed, so beating DPI means altering the majority of packet flow to
use a camouflage technique?
I've thought years ago about a "state explosion" and "cover traffic" approach.
So the majority of traffic should be in encrypted form, providing
cover. How realistic is that unfortunately?
You could possibly overload hardware that operates at wirespeed by
increasing state. Thus two people communicating over the years should
preserve state and use that.
 -johan.

---

From: Dean Willis <[email-masked]>
Date: Mon, 10 Dec 2012 22:55:52 -0600

> Is this about security or privacy?

Privacy, absolutely. How can you have privacy when your packets are being probed to figure out not only what's in them, but who you're talking to, what applications you are running, and what you're talking about? It's like the inverse of "do not track" powered by a nuclear reactor. If you're not having kittens about this, you just don't understand the implications ;-).

Assume DPI is present, even required, at multiple layers in the network. Do you think we can assure the preservation of privacy by publishing some nambypamby guidelines on what the DPI operators can do with the information they've gleaned? Even when there's no business relationship between the user and the DPI operator and no informed consent? 

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 10 Dec 2012 23:04:27 -0600

> use a camouflage technique?

Perhaps to use multiple such techniques. If everything is encrypted, time-randomized, size-randomized, and TORed, DPI gets a lot harder. 

> cover. How realistic is that unfortunately?

A few years back we thought it unreasonable for a major web site to use https for anything other than the initial sign-on. Now it's the norm for reading email. 

> preserve state and use that.

That's an interesting idea. Not entirely dissimilar from perfect forward secrecy techniques, as used in ZRTP for example; key-revision state is preserved, so that any MITM substitution that succeeds can be detected.

--
Dean

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 11 Dec 2012 07:35:45 +0000

If you want privacy, encrypt your traffic. Smoke screens mostly make people work a little harder - not only the folks you're trying to interdict, but the people you want to help.

---

From: SM <[email-masked]>
Date: Tue, 11 Dec 2012 00:24:45 -0800

Hi Dean,
At 20:55 10-12-2012, Dean Willis wrote:
>Privacy, absolutely. How can you have privacy when your packets are 
>being probed to figure out not only what's in them, but who you're 
>talking to, what applications you are running, and what you're 
>talking about? It's like the inverse of "do not track" powered by a 
>nuclear reactor. If you're not having kittens about this, you just 
>don't understand the implications ;-).

The ITU specification your message refers to does not have any 
discussion of privacy considerations.  At some level the 
specification is not that different from the IETF specifications the 
ITU specification references.  In my opinion it would be difficult to 
get anything done if the problem is framed solely in terms of privacy.

I wouldn't say that people do not understand the implications.  I 
would describe it a distant threat as there is no immediacy to it, 
i.e. for the average person, there isn't any noticeable impact.

>Assume DPI is present, even required, at multiple layers in the 
>network. Do you think we can assure the preservation of privacy by 
>publishing some nambypamby guidelines on what the DPI operators can 
>do with the information they've gleaned? Even when there's no 
>business relationship between the user and the DPI operator and no 
>informed consent?

I don't think so.  However, that does not change the fact that 
nothing will be done about the problem.  If one wants to ensure 
privacy in the protocols being developed in the IETF one would have 
to review current work on a regular basis.  That is not being 
done.  If one takes an extreme position the problem will be unsolvable.

Regards,
-sm

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Dec 2012 08:58:45 +0000

On 11 Dec 2012, at 08:24, SM <[email-masked]> wrote:

> If one wants to ensure privacy in the protocols being developed in the IETF one would have to review current work on a regular basis.  That is not being done

We did try but it didn't work. Happy to try again. If folks here are willing to do occasional draft reviews for privacy considerations please mail me offlist in the next week. I'll summarize back here after that

S

---

From: "Bryan McLaughlin (brmclaug)" <[email-masked]>
Date: Tue, 11 Dec 2012 09:56:10 +0000

I agree, obfuscation is perhaps not the formal approach we should take to
such offerings. Asking users to encrypt to protect privacy is also onerous
on users and may interfere with the management of networks where DPI
'could' be an appropriate and justifiable use.

I would also offer that privacy considerations 'should' be designed into
the operation of systems such as we are discussing.

But as privacy is a social construct and therefore subjective it's a tad
challenging for a technical community. That does not mean we should not
engage in this area though.

Bryan

On 11/12/2012 07:35, "Fred Baker (fred)" <[email-masked]> wrote:

>If you want privacy, encrypt your traffic. Smoke screens mostly make
>people work a little harder - not only the folks you're trying to
>interdict, but the people you want to help.
>_______________________________________________
>ietf-privacy mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf-privacy

---

From: SM <[email-masked]>
Date: Tue, 11 Dec 2012 02:01:33 -0800

At 00:58 11-12-2012, Stephen Farrell wrote:
>We did try but it didn't work. Happy to try again. If folks here are 
>willing to do occasional draft reviews for privacy considerations 
>please mail me offlist in the next week. I'll summarize back here after that

I am aware that there was an effort to review drafts for privacy 
considerations.  I am also aware that some Area Directors are still 
still trying.

It is extremely difficult to get a review team started.  Folks 
volunteer to do the occasional review and switch off after a while 
(there are actually valid reasons for that).  The "please do 
something" approach turns into somebody else doing the work.  That 
does not work for obvious reasons. :-)

Here are some points which people might wish to consider to have 
privacy reviewed:

  (a) It will not work unless there is a significant number of people
      committed to perform the reviews.

  (b) The occasional review will not have a significant impact.

  (c) There isn't any IETF common practices to rely on.

  (d) It will take over a year to get anywhere.

  (e) Some document authors will not be happy about the reviews.

Regards,
-sm

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Dec 2012 10:16:15 +0000

Hiya,

You're entirely correct. I'm still happy to try again:-)

S.

On 12/11/2012 10:01 AM, SM wrote:
> It is extremely difficult to get a review team started.  Folks volunteer
> to do the occasional review and switch off after a while (there are
> actually valid reasons for that).  The "please do something" approach
> turns into somebody else doing the work.  That does not work for obvious
> reasons. :-)
> 
> Here are some points which people might wish to consider to have privacy
> reviewed:
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 11 Dec 2012 11:14:06 +0000

> engage in this area though.

Not sure I said otherwise.

I think there are in fact ways to have encryption that are not onerous to users. Secure HTTP encrypts, although having a standard certificate given everybody is not the most "private" way to do things. Diffie-Helman encrypts without user involvement. If we put our thinking caps on, I suspect we could find a way to encrypt that isn't onerous.

>> interdict, but the people you want to help.

----------------------------------------------------
The ignorance of how to use new knowledge stockpiles exponentially. 
   - Marshall McLuhan

---

From: Allison Mankin <[email-masked]>
Date: Tue, 11 Dec 2012 11:38:22 -0500

Another non-onerous encryption approach I'm finding quite compelling:
tcpcrypt (tcpcrypt.org).

On Tue, Dec 11, 2012 at 6:14 AM, Fred Baker (fred) <[email-masked]> wrote:

> I think there are in fact ways to have encryption that are not onerous to
> users. Secure HTTP encrypts, although having a standard certificate given
> everybody is not the most "private" way to do things. Diffie-Helman
> encrypts without user involvement. If we put our thinking caps on, I
> suspect we could find a way to encrypt that isn't onerous.

---

From: Dean Willis <[email-masked]>
Date: Tue, 11 Dec 2012 10:55:46 -0600

> If you want privacy, encrypt your traffic. Smoke screens mostly make people work a little harder - not only the folks you're trying to interdict, but the people you want to help.

Fred, I want EVERYBODY to encrypt their traffic, so that my encrypted traffic doesn't stand out.

I also want everybody using dynamic port numbers, randomized packet sizing, randomized inter-packet timing, etc.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 11 Dec 2012 11:00:52 -0600

On Dec 11, 2012, at 10:38 AM, Allison Mankin <[email-masked]> wrote:

> 
> Another non-onerous encryption approach I'm finding quite compelling:  tcpcrypt (tcpcrypt.org).
> 

Yes, I really like tcpcrypt in concept. The "security" people I've talked to about tcpcrypt dismissed it rather glibly, but it seems to me that widespread use of tcpcrypt is both feasible and rewarding in its impact on casual inspection and consequent change of expectations. 

--
Dean

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 11 Dec 2012 20:13:18 +0000

> Fred, I want EVERYBODY to encrypt their traffic, so that my encrypted traffic doesn't stand out.

There is one problem with that, and it's legal. In some countries, encryption is illegal.

---

From: Allison Mankin <[email-masked]>
Date: Tue, 11 Dec 2012 15:30:10 -0500

Dean,

At the last IETF, I chatted with a number of people about tcpcrypt (having
talked with Mark Handley about it in the past).  believe we could spend
some energy on it at IETF and make progress on broader usage for it.

Allison

On Tue, Dec 11, 2012 at 12:00 PM, Dean Willis <[email-masked]>wrote:

> Yes, I really like tcpcrypt in concept. The "security" people I've talked
> to about tcpcrypt dismissed it rather glibly, but it seems to me that
> widespread use of tcpcrypt is both feasible and rewarding in its impact on
> casual inspection and consequent change of expectations.
>

---

From: Scott Brim <[email-masked]>
Date: Tue, 11 Dec 2012 21:47:12 -0500

Encrypting content only provides privacy of the content. It doesn't protect your traffic behavior,  who you communicate with,  from where etc. DPI can sniff out a lot of this kind of information. 

Sent from my Nexus 10.

---

From: Scott Brim <[email-masked]>
Date: Tue, 11 Dec 2012 21:48:35 -0500

Does tcpcrypt need the IETF for anything? 

Sent from my Nexus 10. 

-----Original Message-----
From: Allison Mankin <[email-masked]>
To: Dean Willis <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Tue, 11 Dec 2012 3:32 PM
Subject: Re: [ietf-privacy] ITU, DPI, and Deliberate Obscurity

Dean,

Allison

---

From: Robin Wilton <[email-masked]>
Date: Wed, 12 Dec 2012 10:31:11 +0000

There are clearly lots of issues here at several levels, from the procedural to the technical… I'm not going to fan the flames, though - I just want to make one observation about the threat model/risk assessment, in response to the snippet I have retained below.

There is a general problem with user perceptions of privacy risk, because of the lack of noticeable impact arising out of behaviour that erodes privacy. The human brain is not well adapted to this kind of threat (it's well evolved to deal with immediate threats like a tiger running at you…). When it comes to privacy, the deleterious effects of 'bad' behaviour are so remote from the behaviour that caused them, that we tend not to draw the connection between the two in any way that causes us to change our behaviour.

Similar issues are evident in our attitudes towards the risk of smoking, lack of exercise, poor posture, fatty foods etc.: the risk (and the damage) is incremental and often not apparent until the habit is too well ingrained to change. 

The threat to privacy from intrusive surveillance technologies may be remote, and the impact may not be noticeable to the average person, but that doesn't mean it should be ignored… nor does it mean that user perception of the problem is a reliable guide to what should be done about it.

Best wishes,

Robin 

Robin Wilton
Technical Outreach Director - Identity and Privacy
Internet Society

email: [email-masked]
Phone: +44 705 005 2931
Twitter: @futureidentity

On 11 Dec 2012, at 08:24, SM wrote:

> 
>   I would describe it a distant threat as there is no immediacy to it, i.e. for the average person, there isn't any noticeable impact.

---

From: Robin Wilton <[email-masked]>
Date: Wed, 12 Dec 2012 10:52:13 +0000

Thanks Allison - 

tcpcrypt looks interesting, but the following couple of sentences make me a little uneasy:

By default Tcpcrypt is vulnerable to active attacks—an attacker can, for example, modify a server's response to say that Tcpcrypt is not supported (when in fact it is) so that all subsequent traffic will be clear text and can thus be eavesdropped on.

Tcpcrypt, however, is powerful enough to stop active attacks, too, if the application using it performs authentication. For example, if you log in to online banking using a password and the connection is over Tcpcrypt, it is possible to use that shared secret between you and the bank (i.e., the password) to authenticate that you are actually speaking to the bank and not some active (man-in-the-middle) attacker. 

I don't think they can have it both ways. Either they have a secure, non PKI-based (see their earlier dismissal of PKI on the same web page) authentication mechanism, or they are vulnerable to man-in-the-middle attacks of both kinds: simple ones which say the server doesn't support tcpcrypt, and advanced ones which interpose a tcpcrypt-capable server between you and the bank…

Needs a bit more investigation before I'd trust it...

Yrs.,
Robin

Robin Wilton

email: [email-masked]
Phone: +44 705 005 2931
Twitter: @futureidentity

---

From: Robin Wilton <[email-masked]>
Date: Wed, 12 Dec 2012 10:53:24 +0000

Oops. Sorry, Dean, I've just seen your response and realised that I have added myself, by default, to the "glib dismissal" fraternity :^(

R

Robin Wilton

email: [email-masked]
Phone: +44 705 005 2931
Twitter: @futureidentity

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 12 Dec 2012 18:42:27 +0000

> Encrypting content only provides privacy of the content. It doesn't protect your traffic behavior,  who you communicate with,  from where etc. DPI can sniff out a lot of this kind of information.

It doesn't take DPI to do that. All it takes is IPFIX for the first hop, and web/mail/etc logs for more detailed information.

https://tools.ietf.org/html/rfc3924
3924 Cisco Architecture for Lawful Intercept in IP Networks. F. Baker,
     B. Foster, C. Sharp. October 2004. (Format: TXT=40826 bytes) (Status:
     INFORMATIONAL)

AFAIK this or something like it is used by every police force on the planet. It is more-or-less mandated in the EU, by the Data Retention Initiative, and periodically comes up in one form or another in the US. Count the signatories to the Council of Europe Convention on CyberCrime, which covers data retention, content intercept, and direct investigation of stored computer data (read "cloud"). http://conventions.coe.int/Treaty/en/Treaties/Html/185.htm

Yes, someone will mention RFC 2804. That document says two things: the IETF doesn't want to get involved, and it encourages anyone who does get involved to publicly post their specifications for review. Hence RFC 3924. Head in the sand doesn't prevent things from happening. Getting involved gives you a voice in getting it right. The original ETSI spec for LAES, per the guy that was the editor at the time, called for ISPs to split their fiber and push one end under their friendly LEA's door. The argument: "it's secure; they take what they want, and they don't need to tell anyone." Well, take a look at the failures of LI at the LAPD in the late 1990's (there were two, one an overzealous cop and the other a mafia plant in LAPD) and the fact that circa 2003 the Greek PM discovered that 100 of his minister's phones were tapped and Vodaphone couldn't tell him who was getting the information. I got involved and called for auditability in the spec we published. Tell me that was the wrong thing to do.

---

From: SM <[email-masked]>
Date: Wed, 12 Dec 2012 10:26:12 -0800

Hi Robin,
At 02:31 12-12-2012, Robin Wilton wrote:
>There is a general problem with user perceptions 
>of privacy risk, because of the lack of 
>noticeable impact arising out of behaviour that 
>erodes privacy. The human brain is not well 
>adapted to this kind of threat (it's well 
>evolved to deal with immediate threats like a 
>tiger running at you…). When it comes to 
>privacy, the deleterious effects of 'bad' 
>behaviour are so remote from the behaviour that 
>caused them, that we tend not to draw the 
>connection between the two in any way that causes us to change our behaviour.

Agreed.

>Similar issues are evident in our attitudes 
>towards the risk of smoking, lack of exercise, 
>poor posture, fatty foods etc.: the risk (and 
>the damage) is incremental and often not 
>apparent until the habit is too well ingrained to change.

Yes.

>The threat to privacy from intrusive 
>surveillance technologies may be remote, and the 
>impact may not be noticeable to the average 
>person, but that doesn't mean it should be 
>ignored… nor does it mean that user perception 
>of the problem is a reliable guide to what should be done about it.

I recently did a presentation related to privacy 
to an audience in a foreign country.  I did not 
mention intrusive surveillance technology as it 
might be perceived as inflammatory by the audience.

"What should be done about it" is only doable, in 
my humble opinion, if the user perceives that 
there is a problem worth solving.  If I used the 
arguments quoted above I doubt that the users 
would be convinced.  It's not that they are not 
good arguments; it's more of a matter of 
audience.  Alissa Cooper once wrote a proposal 
about an IETF privacy policy.  The was a 
discussion about it (see 
http://www.ietf.org/mail-archive/web/ietf/current/msg62274.html 
).  At the time this message was written the IETF 
did not have a privacy policy.

Coming back to surveillance technologies, if I 
click on 
https://www.crowd4privacy.org/page/impressum the 
HTTPS request might be rerouted if the site is on 
"the" list.  It's not a good idea to complain 
about that as I might end up on some list. :-)

Regards,
-sm

---

From: Dean Willis <[email-masked]>
Date: Wed, 12 Dec 2012 14:41:26 -0600

> There is one problem with that, and it's legal. In some countries, encryption is illegal.

Then they don't have to be RFC-compliant, do they?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 12 Dec 2012 14:45:02 -0600

> Encrypting content only provides privacy of the content. It doesn't protect your traffic behavior,  who you communicate with,  from where etc. DPI can sniff out a lot of this kind of information.

Absolutely true. Correspondent IP addresses and ports, packet sizes, and packet timing say a lot too.

Things like Tor help with correspondent addresses and ports. And protocols can be designed to provide some randomization of packet size and timing. For example, RTP could have variation in the number of samples per packet, and use some filler bits for additional randomization. 

These are all well within the capacity of the IETF to influence.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 12 Dec 2012 14:47:15 -0600

> Oops. Sorry, Dean, I've just seen your response and realised that I have added myself, by default, to the "glib dismissal" fraternity :^(

Thanks for noticing. There may be hope for the fraternity yet!

--
Dean

---

From: Eric Burger <[email-masked]>
Date: Wed, 12 Dec 2012 19:06:57 -0500

Check out RFC 6562. It turns out ABR codecs leak out a lot of information, to the point that if one does really strong encryption on the packets... one can figure out what is being said based on packet size and timing alone.

The demo from UNC is pretty impressive.

---

From: David Singer <[email-masked]>
Date: Wed, 12 Dec 2012 16:18:13 -0800

> The threat to privacy from intrusive surveillance technologies may be remote, and the impact may not be noticeable to the average person, but that doesn't mean it should be ignored… nor does it mea…

On the other hand, I think that people can also be over-concerned about privacy risks.  We tend to be able to evaluate risks that are (a) voluntary (we chose them) and (b) perceptible and 'quantifiable' (we can see and maybe assess the potential problem), much more effectively than their counterparts.  Nuclear radiation is the most-often cited; you generally don't choose to expose yourself, and you can't see it or its consequences (until it's too late). People freak out about it, as a result.  Driving is the opposite; we choose to drive, and we see the very real possibility of accidents.

The fear that people have that 'some people' are 'building a database about me', 'without my permission or knowledge' may be much larger than warranted if they only knew what was in the database, or it was accumulated after consent/knowledge.  Basically, reducing the "it's creepy" feeling may be of assistance here.

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Ashok Malhotra <[email-masked]>
Date: Wed, 12 Dec 2012 16:41:36 -0800

> The fear that people have that 'some people' are 'building a database about me', 'without my permission or knowledge' may be much larger than warranted if they only knew what was in the database, o…
If we could look at and, perhaps, even edit the info collected about us, that would allay our fears.
Much of the info may be innocuous.  For example, my database may say that I buy swimming pool
supplies.  That's just fine by me.  In fact, it may be a good thing as I will discount offers for pool
supplies.

Ashok

---

From: "Bryan McLaughlin (brmclaug)" <[email-masked]>
Date: Thu, 13 Dec 2012 02:00:06 +0000

On 13/12/2012 00:41, "Ashok Malhotra" <[email-masked]> wrote:

>> The fear that people have that 'some people' are 'building a database
>>about me', 'without my permission or knowledge' may be much larger than
>>warranted if they only knew what was in the database, or it was
>>accumulated after consent/knowledge.  Basically, reducing the "it's
>>creepy" feeling may be of assistance here.

Or it may say I buy hi-fat milk and so am defined as a health risk for
insurance companies? Or it could infer any number of things from items
that alone would 'appear' to pose us no personal risk at all.

Being able to 'edit' what is collected presupposes we allow the
collection. It also presupposes that you will have access to all the
databases. I think that is a dangerous thing for a society to presuppose
lightly.

Big Data is a tremendous opportunity for society, but I firmly believe  we
should  exercise caution until we have a better understanding of the
potential impact and the practical impact.

Why not let the mail man look at all your mail and record every parcel and
correspondence you send or receive?  Why not allow them to open and  read
them?  Why not Listen to every call to hear what products I am  interested
in and which adverts are working in getting increased interest and if I go
on to buy them? 

I think the point is clear we do not allow that  as we 'feel' that that is
personal. Until society catches up with the technical capabilities our
perception - as a society- will be way behind the potential risk.

Did you know  there is research that takes your fingerprints and recreates
facial characteristics?

My point being just because 'we' think something seems innocuous in a
certain does not mean it is now and will forever remain innocuous in that
fashion.

---

From: Dean Willis <[email-masked]>
Date: Sun, 16 Dec 2012 13:31:05 -0600

> supplies.  That's just fine by me.  In fact, it may be a good thing as I will discount offers for pool

You buy swimming pool supplies? Chlorine and muriatic acid are components of improvised explosives devices.   They're also used in the production of illegal recreational pharmaceuticals. You don't want to be on either list. In fact, people whom the authorities suspect of something but that they can't get any other way are not uncommonly busted on "possession of bomb-making supplies" or "possession of drug-manufactuing equipment" for something as innocent as bleaching their pool or fertilizing their gardens.

--
Dean

---

From: JC Cannon <[email-masked]>
Date: Sun, 16 Dec 2012 23:14:03 +0000

I'm sure the authorities would get that information from the suppliers and not rely on ad networks for security intelligence.

JC
________________________________
From: Dean Willis<mailto:[email-masked]>
Sent: ‎12/‎16/‎2012 11:31 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [ietf-privacy] ITU, DPI, and Deliberate Obscurity

---

From: David Singer <[email-masked]>
Date: Mon, 17 Dec 2012 10:02:34 -0800

> I'm sure the authorities would get that information from the suppliers and not rely on ad networks for security intelligence.

I am not so sure.  The ad networks have a much broader view of you than any one supplier (as do search engines).  If you're looking to profile people, you want more information.  Oh, he buys this…and reads that…and visits that site…and goes to these places…guilty!

> From: Dean Willis
> To: [email-masked]
> Cc: [email-masked]

David Singer

---

From: Dean Willis <[email-masked]>
Date: Mon, 17 Dec 2012 20:43:51 -0600

> I am not so sure.  The ad networks have a much broader view of you than any one supplier (as do search engines).  If you're looking to profile people, you want more information.  Oh, he buys this…a…

Total Information Awareness.

From Wikipedia: The TIA program was researching, developing, and integrating technologies to virtually aggregate data, to follow subject-oriented link analysis, to develop descriptive and predictive models through data mining or human hypothesis, and to apply such models to additional datasets to identify terrorists and terrorist groups.

The "ad network" is consumer-grade TIA in a box.

--
Dean