Hacker News Reader

Comment by youzer | Hacker News Reader

Let's say I want to send some TCP. That TCP happens to kind of look like HTTP, but it's not. It's just some protocol I made up which looks HTTPish enough to trigger this injection.

Doesn't that mean that Verizon isn't actually offering TCP/IP (Internet) access, since they corrupt my protocol stream in transit? Shoudln't that mean they should be charged with fraud if they continue to advertise the fact that they provide internet access when what they really provide is a broken version of TCP they made up?

It's a serious question.

View on HN

"Doesn't that mean that Verizon isn't actually offering TCP/IP (Internet) access, since they corrupt my protocol stream in transit?"

This is a serious answer: Go back and look at what they actually promise to deliver. Bet it doesn't have the word "TCP" in it anywhere. You can't hit them with contract violation when they aren't in violation of their contract. (Well, you can lodge any lawsuit you like. But it won't go well for you.)

If they used the proper noun "Internet" then TCP/IP is implied.

No, it really isn't. Even in our world thinking Internet == TCP/IP is a faux pas, roughly equivalent to thinking Internet == WWW. Legally speaking I suspect the term borders on meaningless. Obviously a company offering "internet access" must do something to discharge their contract but I seriously doubt you could ever nail them on this.

And if you could and did today, in a month the contracts would be rewritten anyhow, making this a completely moot point.

There is no public, global network of networks besides the one known as the Internet, and it exclusively uses the Internet Protocol suite.

Thinking TCP/IP = IP is also a bit of a faux pas. No fair changing the terms I used out from underneath me and then complaining.

Further... again, go check your contract for your home provider. I'm quite confident it doesn't promise to "serve IP packets", let alone making any promise whatsoever to serve them without modification. Don't lose sight of the context here... pedanting about what protocol is in use isn't going to change the fact that none of them are probably mentioned in your contract.

I didn't say Internet Protocol, I said the Internet Protocol Suite.

Yup in theory. In practice you would call up your legal counsel, and they'd ask you how hard would it be to re-engineer your protocol to not break by Verizon. If the answer is anything less than 1 year and tens to hundreds of thousands of dollars then they'd advise you to just fix your protocol.

On the other hand if your spouse is a lawyer and wants to make a name for themself then you'd consider moving forward on failure to deliver service / false advertising / etc.

When most mobile providers get you on the internet, it's through NAT. They're already terminating and re-creating your connections for you, and not providing your "real" tcp/ip packets to the internet, and thus neither the world's "real" internet packets to you. All you get is a translation.

You've never gotten "the real internet" on a mobile device. The idea that they may change one more part of your fake connection seems pretty irrelevant.

The same happens on "real" routers, firewalls, etc when they massage the traffic going through them. Sometimes they barely change anything at all. Sometimes they make minor adjustments. Sometimes major ones. You don't have an agreement with any of them specifically to modify your packets; they just do. So do you have a claim of harassment against your packets? Have they trespassed on your property? Are you trespassing on their routers?

The answer to all these questions is: nobody has ever guaranteed to you what you get from the internet, other than "availability" if you're a business user, and even that's not set in stone.

NAT doesn't terminate and recreate connections. It modifies packet headers and forwards them.

Modifying headers in order to facilitate transit over a network is one thing, modifying the L7 payload is another.

Well you're right in a sense. But it modifies packets to a point where they are indistinguishable from the original connection, and tracks the incoming and outgoing interface sides as if they were discrete connections (there are at least four flows for every NAT connection).

Often carrier-grade routers will replace every aspect of a tcp/ip packet, like sequence numbers, windows, flags, source and dest ports, etc. Routers like these see everything going through them as a form of NAT; it's just some connections are modified more than others. The exception to this would be interfaces in bridge or monitor mode.

To your second point that modifying some layers is OK but modifying other layers is not: what rationale explains this double standard? What about the application layer do you find to be unique in that there's some expectation of purity? Does a proxy not modify layer 7 to cache and pass traffic? Does DNS not do the same?

Verizon LTE devices have a unique, publicly accessible IPv6 address.

No.

Your question may have been serious, but it's also ridiculous, unless you have a much more technically detailed contract with Verizon than I've ever seen.

I wonder if it would be possible to have them sign a contract when you sign up since customer is king.

customer is king? With verizon? not in the US.

I once had extremely odd errors being reported by my clients (phonehomes via window.onerror in the browser), things like syntax errors in my otherwise perfectly fine javascript and randomly corrupted data transfered with ajax. So i started investigating and came to the conclusion that someones ISP was trying to inject iframes with ads into any random text transfered over http, including javascript! Pure craziness, if i myself was affected i would change ISP on the spot.

This case was extreme but imagine as you say, a proprietary client and server that think they have implemented HTTP properly but they haven't. Maybe they assume all headers come in a specific order, the request size may not exceed X bytes, a hash of the request has been transfered over another channel, etc etc. Normally this is fine because they always only communicate with each other and they both always do exactly the same "mistake", but now the data essentially becomes corrupted. Can you really blame these applications for "not following spec", they were only designed to communicate with each other.

Reply on news.ycombinator.com