Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Verizon's Advertising Header Works

webpolicy.org

Post reply on HN
Print view View original

21–30 of 68 posts

Re: How Verizon's Advertising Header Works

#21

Post by milkshakes »

notatoad wrote: post #15
duaneb wrote: post #10

Earlier quoted context omitted.

I wouldn't call it particularly deep packet inspection—they're just rewriting the http requests.

wouldn't re-writing the HTTP request require inspecting the packets as deeply as it is possible to?

yes

Re: How Verizon's Advertising Header Works

#25

Post by scintill76 »

skywhopper wrote: post #14
alimoeeny wrote: post #4

Is this even legal? I mean are ISPs, or telecom in general allowed to identify the requester without their permission? But I imagine it will not work on encrypted connections. SSL FTW?!

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 done?

[0] https://tools.ietf.org/html/rfc4366#section-2.1

Re: How Verizon's Advertising Header Works

#27

Post by andrewstuart2 »

I haven't seen it mentioned anywhere, but this can't work over HTTPS. The message is fully encrypted end-to-end and Verizon Wireless can't do anything to alter the content without destroying the whole message.

Seems like a few people know this, lots of talk about SSL & TLS, but I don't think anybody has mentioned it explicitly.

Re: How Verizon's Advertising Header Works

#28

Post by jtokoph »

andrewstuart2 wrote: post #27

I haven't seen it mentioned anywhere, but this can't work over HTTPS. The message is fully encrypted end-to-end and Verizon Wireless can't do anything to alter the content without destroying the whole message. Seems like a few people know this, lots of talk about SSL & TLS, but I don't think anybody has mentioned it explicitly.

Does Safari on iOS completely block mixed content (http resources embedded on https pages)?

If not, any page that embeds an insecure resource can still track you with this cookie.

Re: How Verizon's Advertising Header Works

#29

Post by nkozyra »

acdha wrote: post #5
crazy_geek wrote: post #2

I haven't had the opportunity to tinker with this, but what if the client sends a X-UIDH: header of it's own? Will VZW overwrite the header, or will it pass it through? If it doesn't clobber it, there's a browser plugin waiting to be written.

It reportedly overwrites a header sent by the client: https://twitter.com/kennwhite/status/525338284029775872

Given the ordering of the process, that makes sense. I'm not a Verizon customer but I would be gone yesterday if I were after reading about this.

As I understand it, they offer an "opt out" that doesn't actually opt you out of this.

Truly gross behavior, though.

Post reply on HN