5 ms·

Most interesting part was the reply from the Comcast employee.

by vages 9y ago

throwaway613834 9y ago
Specifically the last sentence!
- tylerruby 9y ago
  For those that haven't seen it: Customer: "Comcast has my phone office number, my cell for texts, my email, and my home address, yet they choose to molest my requested web pages by injecting hundreds of lines of code." Comcast Response: "The notice is typically sent after a customer ignores several emails. Perhaps some of those ended up in your spam folder?" To me this sounds like a crazy ex-lover. "You didn't respond to my texts so I came to your house." No, Comcast, don't do that. They ignore your emails because you're trying to sell them something they don't want. Here is the Twitter of the Comcast rep for anybody interested: https://twitter.com/jlivingood https://twitter.com/jlivingood
  - sleavey 9y ago
    And I bet that by "ignore" they mean "didn't allow remote tracking images in emails to be loaded therefore stopping us from knowing if, when and where the email was viewed".
exikyut 9y ago
Yes, indeed it was. It's a fairly standard, unsurprising response for this situation; doesn't try to be defensive, doesn't try to provoke. [Edit: I'm horribly under-perceptive, after reading other comments I see I'm a bit off.] But... this bit. > ... [JL] This is our web notification system, documented in RFC 6108 https://tools.ietf.org/html/rfc6108 https://tools.ietf.org/html/rfc6108, which has been in place for many years now. ... Oh, interesting, what Internet technology are they using? > "RFC 6108: Comcast's Web Notification System Design" > February 2011 Cue jawdrop. My instinctive response was to WAT and think "this is not what RFCs were for..." But then I read this part, > Status of This Memo > This document is not an Internet Standards Track specification; it is published for informational purposes. > This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; ... Hmm. Reading through, this outlines a way to avoid using deep packet inspection by using Squid and Tomcat instead. Initially when I read this my brain was sort of going in the direction of "this kind of thing is where the net neutrality repeal thing started..." but now I've spent a bit of time reading it I don't actually think my snap response was particularly on point. This is a bit of a stream-of-consciousness but I wanted to draw attention to that RFC.
- Buge 9y ago
  >Reading through, this outlines a way to avoid using deep packet inspection by using Squid and Tomcat instead. Huh? It sure seems to be using deep packet inspection to me. If it's looking at the data section of your packet, that's deep packet inspection. And Squid and Tomcat do that. They're not just inspecting the packets, they're altering them, creating new packets, splitting packets, etc. The "RFC" seems to be outright lying by claiming they don't do DPI.
  - exikyut 9y ago
    Hmmmm. > Pre-established TCP sessions on port 80 are identified by the SMB and forwarded with no impact. (SMB = Session Management Broker) How does the system identify a "pre-established session"? This seems to corroborate what you're saying
    - Dylan16807 9y ago
      That part just requires looking at the TCP header. So I guess the answer is "no deep packet inspection until it picks a connection to inject, and then it inspects everything in that connection". Which simplifies to "yes deep packet inspection".
- jlivingood 9y ago
  An RFC is not always a standard - often they are simply 'informational'. For us, when we wrote the document, it was a way to document as transparently as possible how the system worked so that folks would not need to speculate about it and for us to explain the rationale and alternatives considered. This seemed to me at the time far better than being evasive about it. And a request for comment is often a way to solicit exactly that - good comments (e.g. suggestions on alternatives). In this case, it has led in part to things like the IETF's new(ish) CAPPORT working group being created to develop a better Internet-wide standard for how to interact with so-called captive portals. See https://datatracker.ietf.org/wg/capport/about/ https://datatracker.ietf.org/wg/capport/about/ for more details and feel free to join the mailing list and contribute!

Most interesting part was the reply from the Comcast employee.

by vages 9y ago

Most interesting part was the reply from the Comcast employee.

throwaway613834 9y ago

Specifically the last sentence!

tylerruby 9y ago
For those that haven't seen it: Customer: "Comcast has my phone office number, my cell for texts, my email, and my home address, yet they choose to molest my requested web pages by injecting hundreds of lines of code." Comcast Response: "The notice is typically sent after a customer ignores several emails. Perhaps some of those ended up in your spam folder?" To me this sounds like a crazy ex-lover. "You didn't respond to my texts so I came to your house." No, Comcast, don't do that. They ignore your emails because you're trying to sell them something they don't want. Here is the Twitter of the Comcast rep for anybody interested: https://twitter.com/jlivingood https://twitter.com/jlivingood
- sleavey 9y ago
  And I bet that by "ignore" they mean "didn't allow remote tracking images in emails to be loaded therefore stopping us from knowing if, when and where the email was viewed".

exikyut 9y ago

Yes, indeed it was. It's a fairly standard, unsurprising response for this situation; doesn't try to be defensive, doesn't try to provoke. [Edit: I'm horribly under-perceptive, after reading other comments I see I'm a bit off.] But... this bit. > ... [JL] This is our web notification system, documented in RFC 6108 https://tools.ietf.org/html/rfc6108 https://tools.ietf.org/html/rfc6108, which has been in place for many years now. ... Oh, interesting, what Internet technology are they using? > "RFC 6108: Comcast's Web Notification System Design" > February 2011 Cue jawdrop. My instinctive response was to WAT and think "this is not what RFCs were for..." But then I read this part, > Status of This Memo > This document is not an Internet Standards Track specification; it is published for informational purposes. > This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; ... Hmm. Reading through, this outlines a way to avoid using deep packet inspection by using Squid and Tomcat instead. Initially when I read this my brain was sort of going in the direction of "this kind of thing is where the net neutrality repeal thing started..." but now I've spent a bit of time reading it I don't actually think my snap response was particularly on point. This is a bit of a stream-of-consciousness but I wanted to draw attention to that RFC.

Buge 9y ago
>Reading through, this outlines a way to avoid using deep packet inspection by using Squid and Tomcat instead. Huh? It sure seems to be using deep packet inspection to me. If it's looking at the data section of your packet, that's deep packet inspection. And Squid and Tomcat do that. They're not just inspecting the packets, they're altering them, creating new packets, splitting packets, etc. The "RFC" seems to be outright lying by claiming they don't do DPI.
- exikyut 9y ago
  Hmmmm. > Pre-established TCP sessions on port 80 are identified by the SMB and forwarded with no impact. (SMB = Session Management Broker) How does the system identify a "pre-established session"? This seems to corroborate what you're saying
  - Dylan16807 9y ago
    That part just requires looking at the TCP header. So I guess the answer is "no deep packet inspection until it picks a connection to inject, and then it inspects everything in that connection". Which simplifies to "yes deep packet inspection".
jlivingood 9y ago
An RFC is not always a standard - often they are simply 'informational'. For us, when we wrote the document, it was a way to document as transparently as possible how the system worked so that folks would not need to speculate about it and for us to explain the rationale and alternatives considered. This seemed to me at the time far better than being evasive about it. And a request for comment is often a way to solicit exactly that - good comments (e.g. suggestions on alternatives). In this case, it has led in part to things like the IETF's new(ish) CAPPORT working group being created to develop a better Internet-wide standard for how to interact with so-called captive portals. See https://datatracker.ietf.org/wg/capport/about/ https://datatracker.ietf.org/wg/capport/about/ for more details and feel free to join the mailing list and contribute!