Subject: [hiaps] some discussion in the press...

From: joel jaeggli <[email-masked]>
Date: Tue, 28 Oct 2014 21:06:14 -0700

this is pretty much exactly what I would have expected from injection on
the wire of an identity token...

http://webpolicy.org/2014/10/24/how-verizons-advertising-header-works/

http://www.wired.com/2014/10/verizons-perma-cookie/

http://www.forbes.com/sites/kashmirhill/2014/10/28/att-says-its-testing-unkillable-tracker-on-customers-smartphones/

---

From: <[email-masked]>
Date: Wed, 29 Oct 2014 13:19:56 +0000

Hi Joel,

Thank you for sharing this information. 

The host_id effort does not aim to inject globally unique/stable identifier but to provide the same information that would be conveyed in the source IP address.

There are already some applications that inject the MSISDN using some non-standard HTTP headers (e.g., HTTP_X_UP_CALLING_LINE_ID) to reveal the phone number. User can use services (e.g., http://www.mulliner.org/pc.cgi) to check whether their phone number is revealed or not.

I fully agree that leaking globally unique information in application message payloads must be controlled; otherwise this can be used for user tracking: An IP address may change when reconnecting while the MSISDN is a stable identifier. 

Documenting mis-uses of injecting unique and stable identifiers is still needed to socialize such practices and also to be aware of their side effects.

Cheers,
Med

-----Message d'origine-----
De : hiaps [mailto:[email-masked]] De la part de joel jaeggli
Envoyé : mercredi 29 octobre 2014 05:06
À : [email-masked]
Objet : [hiaps] some discussion in the press...

---

From: Brandon Williams <[email-masked]>
Date: Wed, 29 Oct 2014 09:54:58 -0400

Agreed. Inserting a publicly visible user identifier is a bad idea. 
That's why all the proposals that have come from people on the hiaps 
list (to the best of my knowledge) have focused on relaying _host_ 
identifiers that are already publicly visible (generally the public IP 
address) through to the other side of middleboxes that are hiding such 
publicly visible identifiers. If there are proposals out there that 
violate this principle, I agree entirely that they should be abandoned.

--Brandon

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: <[email-masked]>
Date: Wed, 29 Oct 2014 14:10:41 +0000

Hi Brian,

I echo your comment. 

None of the proposals inventoried in the HOST_ID effort is trying to do the same thing as X-UIDH header. Moreover, none of these proposals is endorsing the following headers (but not limited to) nor aims at revealing a customer ID, account ID, profile ID, etc.: 

HTTP_MSISDN, HTTP_X_MSISDN, HTTP_X_UP_CALLING_LINE_ID,
HTTP_X_NOKIA_MSISDN, HTTP_X_HTS_CLID, HTTP_X_MSP_CLID,
HTTP_X_NX_CLID, HTTP__RAPMIN, HTTP_X_WAP_MSISDN,
HTTP_COOKIE, HTTP_X_UP_LSID, HTTP_X_H3G_MSISDN,
HTTP_X_JINNY_CID, HTTP_X_NETWORK_INFO, ...

Cheers,
Med

-----Message d'origine-----
De : hiaps [mailto:[email-masked]] De la part de Brandon Williams
Envoyé : mercredi 29 octobre 2014 14:55
À : joel jaeggli; [email-masked]
Objet : Re: [hiaps] some discussion in the press...

--Brandon

_______________________________________________
hiaps mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/hiaps

---

From: joel jaeggli <[email-masked]>
Date: Wed, 29 Oct 2014 07:59:10 -0700

> violate this principle, I agree entirely that they should be abandoned.

imho one of the assumptions I see in the work is that the host
identifier being relayed was previosuly not publicly visible, hence the
need for hostid injection.  That applies to nat translation for example
it also  applies to differentating between prefix sharing UE's in IPV6
by something other than source address.

http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-07
http://tools.ietf.org/html/rfc6269

that's part of the reason for hiaps bof proposal to consider the problem
of securing such an identifier from differentiation by surveillance.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 29 Oct 2014 11:51:18 -0500

Hi Joel,

> of securing such an identifier from differentiation by surveillance.

Absolutely.

Should we revive the bof effort?
I think that doing the standardization related to hosted in hiaps
rather than intarea is the right way to go for IETF.

Behcet

---

From: joel jaeggli <[email-masked]>
Date: Wed, 29 Oct 2014 14:36:26 -0700

> Should we revive the bof effort?

you didn't hear me say that. I think you know where we left it.

From my vantage point a bof proposal that addresses the scope and
privacy/pervasive monitoring concerns and which has a critical mass of
effort behind it might certainly be worthy of consideration as bof.

> rather than intarea is the right way to go for IETF.

We created this mailing list to have a place to discuss host
identification, we can use it for that or we can get rid of it.

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 30 Oct 2014 14:04:13 -0500

Hi Med, Brandon,

Last time Med was on paternity leave and he could help. Brandon found
out about hiaps late.

Now, it is time for you two to say something regarding

> a bof proposal that addresses the scope and

Regards,

Behcet

---

From: <[email-masked]>
Date: Fri, 31 Oct 2014 16:03:34 +0000

Hi Behcet,

I'm still supportive of this work and actually I'd like to see some concrete progress. Saying that, I'm not sure Joel is asking for another BoF but perhaps I'm wrong here.

Just like the "panic" with pervasive monitoring, there are several mailing lists that are alarmed with injection of the identifiers. These practices are not new but these are "panic" cycles... The side effect of it is that these alarming news can pollute the HOST_ID work despite the fact that we are not asking for unique/stable identifiers nor asking to leak/reveal any customer ID, profile ID, etc.  

BTW, there IETF documents that already documents some practices of injecting identifiers, see for instance: http://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-01#section-3.3 that is more close to what Joel shared in this list.

Cheers,
Med

-----Message d'origine-----
De : Behcet Sarikaya [mailto:[email-masked]] 
Envoyé : jeudi 30 octobre 2014 20:04
À : joel jaeggli
Cc : [email-masked]; BOUCADAIR Mohamed IMT/OLN; Brandon Williams
Objet : Re: [hiaps] some discussion in the press...

Hi Med, Brandon,

Regards,

Behcet
>>>>> http://www.forbes.com/sites/kashmirhill/2014/10/28/att-says-its-testing-unkillable-tracker-on-customers-smartphones/

Subject: Re: [gaia] Vodacom exposing your number to every website you visit
From: Phil Regnauld <[email-masked]>
To: Melissa Densmore <[email-masked]>
Cc: gaia <[email-masked]>
Date: Thu, 30 Oct 2014 08:30:14 +0000
List-Id: Global Access to the Internet for All <gaia.irtf.org>

Melissa Densmore (melissa.r.densmore) writes:
> Vodacom South Africa is injecting HTTP headers into requests we send to web
> servers. Includes IMEI and phone number.
>
> http://mybroadband.co.za/news/security/113037-vodacom-
> exposing-your-number-to-every-website-you-visit.html

        This is happening other places - here's an article in Danish:

        http://www.version2.dk/artikel/mobilsurf-danske-teleselskaber-sender-dit-telefonnummer-til-hjemmesider-70145

        Google translate can probably do a good job of summarising it :)

        The problem was already brought up back in 2012.

--
Phil Regnauld     Network Startup Resource Center (NSRC) - www.nsrc.org
[email-masked] fb.com/nsrc.org | google.com/+NSRCorg | twitter.com/nsrcworld
PGP Fingerprint:  60FD D10F DA87 7706 A426  3177 C0FD ACDB E408 E96D

_______________________________________________
gaia mailing list
[email-masked]
https://irtf.org/mailman/listinfo/gaia