Comcast is injecting 400+ lines of JavaScript into web pages

I paged through the JS curiously, and found the URL bnpsa.g.comcast.net/images/mydevicealert/browser/. I wondered what would happen if I hit that from my ISP in Australia. I was surprised: I got an NXDOMAIN back.

But I discovered that googling the above URL as a quoted string finds a bunch of copies of the JS scattered around the Internet. Might be useful.

So then I tried hitting bnp-service-alerts.gslb2.comcast.com/images/. This actually resolved, and Chrome hung at "Connecting...". After rechecking the URLs I noticed this one was referenced in the JS as HTTPS, so I added that, and promptly got 403 Forbidden.

Question to anyone on Comcast [edit: which has been answered]: does http://bnpsa.g.comcast.net/images/mydevicealert/browser/ resolve for you?

Re: Comcast is injecting 400+ lines of JavaScript into web pages

#5

Post by throwaway613834 » Sun, Dec 10, 2017, 9:48 AM UTC

vages wrote: post #3

Most interesting part was the reply from the Comcast employee.

Specifically the last sentence!

Re: Comcast is injecting 400+ lines of JavaScript into web pages

#6

Post by mehrdadn » Sun, Dec 10, 2017, 9:49 AM UTC

exikyut wrote: post #4

The gigantic image: https://i.imgur.com/kN2rMhK.jpg (source: http://comcastsupport.i.lithium.com/t5/image/serverpage/imag... - URL manually edited to display largest possible size) I paged through the JS curiously, and found the URL bnpsa.g.comcast.net/images/mydevicealert/browser/. I wondered what would happen if I hit that from my ISP in Australia. I was surprised: I got an NXDOMAIN back. But I discovered that goog…

> Question to anyone on Comcast: does http://bnpsa.g.comcast.net/images/mydevicealert/browser/ resolve for you?

Nope, it does not for me. Non-existent domain.

Re: Comcast is injecting 400+ lines of JavaScript into web pages

#7

Post by ksk » Sun, Dec 10, 2017, 9:50 AM UTC

I wonder if a website could sue Comcast for copyright violation.

Re: Comcast is injecting 400+ lines of JavaScript into web pages

#8

Post by tosh » Sun, Dec 10, 2017, 9:59 AM UTC

"Comcast's Web Notification System Design" https://tools.ietf.org/html/rfc6108

Re: Comcast is injecting 400+ lines of JavaScript into web pages

#9

Post by tylerruby » Sun, Dec 10, 2017, 10:00 AM UTC

throwaway613834 wrote: post #5

vages wrote: post #3

Most interesting part was the reply from the Comcast employee.

Specifically the last sentence!

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

Re: Comcast is injecting 400+ lines of JavaScript into web pages

#10

Post by exikyut » Sun, Dec 10, 2017, 10:02 AM UTC

vages wrote: post #3

Most interesting part was the reply from the Comcast employee.

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, 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.