How Verizon's Advertising Header Works • Hacker News Board

Re: How Verizon's Advertising Header Works

#41

Post by x0x0 » Sat, Oct 25, 2014, 1:20 AM UTC

x0x0 wrote: post #20

skywhopper wrote: post #14

Earlier quoted context omitted.

It doesn't work on SSL yet. Although I won't be surprised when in the near future certain carrier-enhanced phones start coming with a Verizon-signed root CA installed that enables them to crack into your SSL stream and do the same thing. As for its legality, it shouldn't be, but it likely is. After all, it's well established that ISPs may mess around with your TCP and IP packets to enable NAT. So why not with the HTT…

it's a good reason to buy iphones. Apple will let a poisoned ca cert on their phones about the same time hell freezes over. Android can probably only be trusted if it's a nexus phone.

apparently suckers believe that lg, the company that makes tvs that upload shows watched or files on your network, or samsung, the company that needs your phone number, address book, gps location, and accounts in order to download jayz mp3s, wouldn't install a cert for verizon

Re: How Verizon's Advertising Header Works

#42

Post by zrm » Sat, Oct 25, 2014, 1:32 AM UTC

scintill76 wrote: post #25

skywhopper wrote: post #14

Earlier quoted context omitted.

It doesn't work on SSL yet. Although I won't be surprised when in the near future certain carrier-enhanced phones start coming with a Verizon-signed root CA installed that enables them to crack into your SSL stream and do the same thing. As for its legality, it shouldn't be, but it likely is. After all, it's well established that ISPs may mess around with your TCP and IP packets to enable NAT. So why not with the HTT…

I suppose they can already sneak it into the SSL handshake packets, right? Put something in extended client hello[0] that whoever is interested can look at, and other TLS implementations should be ignoring for compatibility. It's maybe not as easy for ad networks to consume, but where there's money to be made, there's a way. I think this would work. Am I missing something? Has anyone checked if it's already being don…

They don't even have to inject anything, it's surprising they're doing this at all. They could just use the TCP/IP source and destination addresses and ports to identify the connection. TLS wouldn't help that. VPN would though.

Re: How Verizon's Advertising Header Works

#43

Post by ianlevesque » Sat, Oct 25, 2014, 1:37 AM UTC

userbinator wrote: post #38

It's one thing for your ISP to be collecting information about you; it's totally another thing for your ISP to be silently modifying your data by adding a tracking header and sending it to all other sites you visit . Modifying application-level data is something an ISP should never do. What if I happened to be using the exact same header name for some other purpose for a web app API? This should be considered illegal…

Nobody wants to defend against their ISP but it's clear at this point that you must. Comcast injects ads when you're using one of their wifi hotspots, Verizon has silently recompressed images and now adds these headers, AT&T uses DPI to detect tethering apps and add additional charges to your bill. The internet is a hostile environment.

Re: How Verizon's Advertising Header Works

#44

Post by sehugg » Sat, Oct 25, 2014, 1:50 AM UTC

This is actually really good, because if advertisers have an Verizon API to query the cookies for demographic information, in theory intelligence agencies could have an API to query a cookie to see if the device belongs to a U.S. person and stop incidental collection of that stream. Which is what they would do, right?

Oh wait, a bad guy could steal your phone. Guess we'd better collect it all. Hey, I guess we could use that cookie for something...

Re: How Verizon's Advertising Header Works

#45

Post by userbinator » Sat, Oct 25, 2014, 1:58 AM UTC

coldcode wrote: post #30

They need to be publicly attacked for doing this. Only massive embarrassment will change the behavior. Maybe get some politicians involved if there are any they haven't bought yet.

Here is a good analogy to use, one which the politicians will understand: it's like the postal service opening letters not only to read their contents, but to change them before forwarding them onto their intended recipients.

Re: How Verizon's Advertising Header Works

#46

Post by scintill76 » Sat, Oct 25, 2014, 2:24 AM UTC

zrm wrote: post #42

scintill76 wrote: post #25

Earlier quoted context omitted.

I suppose they can already sneak it into the SSL handshake packets, right? Put something in extended client hello[0] that whoever is interested can look at, and other TLS implementations should be ignoring for compatibility. It's maybe not as easy for ad networks to consume, but where there's money to be made, there's a way. I think this would work. Am I missing something? Has anyone checked if it's already being don…

They don't even have to inject anything, it's surprising they're doing this at all. They could just use the TCP/IP source and destination addresses and ports to identify the connection. TLS wouldn't help that. VPN would though.

Maybe, but it sounds more messy. Verizon would have to maintain a semi-public (to their "other" customers, that is, advertisers etc.), low-latency queryable database of {source, destination, customerID} tuples, and ads and/or pages might not finish loading until that query returns. If the ID is more static, the trackers can cache the identity information for awhile after the first time, and Verizon probably has less work to track and resolve IDs.

Re: How Verizon's Advertising Header Works

#47

Post by dazbradbury » Sat, Oct 25, 2014, 2:43 AM UTC

The largest network in the UK, O2 (and therefore Three and Tesco), were sending your mobile number as a HTTP header to every site you visited [1]. Didn't last long.

ISP's have also tried this in the past - I remember a few in the UK trying to set up an ad-injection model, but can't seem to find them now, other than NebuAd [2].

[1] - http://www.theregister.co.uk/2012/01/25/o2_hands_out_phone_n...

[2] http://en.wikipedia.org/wiki/NebuAd

Re: How Verizon's Advertising Header Works

#48

Post by jacques_chester » Sat, Oct 25, 2014, 3:16 AM UTC

I happen to be in the process of patenting an opt-in system for authenticating and recording requests from users. One of my design goals was to prevent anyone from piggybacking on the scheme to track the users across multiple requests.

It occurs to me that if I'd been suffering from a less overdeveloped sense of decency, I could've filed sooner with something like this and hit Verizon with a lawsuit.

Re: How Verizon's Advertising Header Works

#49

Post by justanothername » Sat, Oct 25, 2014, 3:19 AM UTC

Using the SOPA visibility strategy could be effective. If enough popular sites redirected requests that had a X-UIDH to a Informational page about the privacy intrusion, people might care (if only for the extra click its causing them).

Re: How Verizon's Advertising Header Works

#50

Post by jameshart » Sat, Oct 25, 2014, 4:02 AM UTC

gojomo wrote: post #31

Notably: the exact same device ID (X-UIDH) is injected into HTTP requests from different browsers/apps, or browser tabs in 'privacy' or 'incognito' mode. Also, if you're using 'personal hotspot', any HTTP traffic from a connected desktop/laptop sharing the mobile data service also gets the header. So VerizonWireless is allowing third-party sites to correlate all HTTP traffic from one device to a single identity, even…

There WILL be information leak vulnerabilities created by breaching the barrier between app HTTP client contexts and browser client contexts. Apps can now make HTTP requests to servers and correlate them with HTTP requests made from a web browser, which was previously not possible. You don't know which apps you use are using HTTP vs HTTPS to phone home, either. This is a complete compromise of the HTTP privacy model... which I guess proves what should be obvious: that HTTP HAS no privacy model, and that we should be using HTTPS everywhere.