Live data from Hacker News

Comcast injecting JS

gist.github.com

31–40 of 288 posts

Re: Comcast injecting JS

#31

So if you were proxying some other protocol over port 80, Comcast might just inject some JavaScript into the stream and corrupt your data? I don't even like the thought that they're running some kind of hardware that makes this possible. They're sending packets impersonating a web server you actually want to talk to, pretending to be part of a response you requested?

I'm sure they are checking content-type headers...

Just because you can do this doesn't mean you should (i will stay away from comcast xfinity).

Re: Comcast injecting JS

#32
post #5

I'm torn. This seems bad, but the warning (exceeding your bandwidth quota) seems valuable. I can't think of another, better way to message this.

Your profile reveals you're a former Comcast employee. That's a disclaimer worth posting here.

But yeah, if you have service with Comcast they have your home phone, email addresses, and physical address. They can get in touch with you every way that every company that CAN'T read all of your internet traffic already gets in touch with you.

The method they've chosen is terrible for at least the following reasons: - The alert will not work on many platforms & devices. - The alert may not reach the account owner. - The alert will not work on SSL traffic. - There is no record that the customer saw the alert (contrast with phone call) - There are serious privacy issues involved in parsing user's web traffic.

Re: Comcast injecting JS

#33
Wonder how the folks back at Comcast HQ would feel if the rest of the internet started adding messages to their web browsing telling them this kind of thing is unsatisfactory? Hey, this content injection game is a game that we all can play.

This is the old "windows alert" nonsense. Everybody and their brother that touched the windows system thought the user would want a popup when their program did something. So the user experience was/is full of annoying popups, warnings, and information messages. Log onto a heavily-customized windows machine that hasn't been used in a month or two and it's like visiting Los Vegas. Good luck trying to get anything done.

Comcast. All kinds of other internet providers manage to communicate these things to their subscribers without this nonsense. Take a hint.

Re: Comcast injecting JS

#34
post #7

This is nothing new.. Rogers has been doing this for years in Canada already.. They use it to notify subscribers when they are approaching their bandwidth quota (75%) and then again when they hit 100%. You actually have to click a "I understand" button to have it not show up over and over.

If you go into your MyRogers account, they actually give you a log of when you've accepted these notices.

Re: Comcast injecting JS

#35
This code is beyond awful - it fails to display, makes endless AJAX requests, and more; here are a few fun tidbits:

1. The code is not encapsulated in an IIFE, so it clobbers any global variables (like 'image_url') in the page, breaking any scripts relying on those variables.

2. The code spends an inordinate time checking if you're running Netscape Navigator 6.

3. Strangely, they include a whole bunch of code allowing the message to be dragged around the window (which is nice) but they don't allow it to be closed. Of course, it closes itself after making a single AJAX request into a black hole, so there's that. Bugs piled on top of each other make this entire message mostly harmless, if it weren't for the variable clobbering & bandwidth usage (see the next item...)

4. Upon load, checkBulletin() is immediately invoked. This does an AJAX call to '/e8f6b078-0f35-11de-85c5-efc5ef23aa1f/aupm/notify.do?dispatch=checkBulletin'. I assume this is to check if the bulletin has changed, to see if there are new messages, or maybe to check if the user has acknowledged the message yet. Unfortunately:

* This URL is relative, which means it will never actually reach its intended target (instead filling your web logs with this request)

* Upon xmlhttp.readystate=4 (request finished, successful or not, so this will change to 4 even on a 404 error), the comcast message is hidden. This means that the entire 'bandwidth exceeded' message will actually be hidden as soon as this request completes, which may be in * The author makes an attempt to not continue sending AJAX requests to this URL after a successful attempt, but botches it, so this request is actually sent indefinitely, every 5000ms, while every any page is open. This means every single tab on your system is popping AJAX requests every 5 seconds for the whole month that your account is nearing its quota. This likely brings you over quota pretty quickly if you leave your computer on all day.

That's right, this code causes every page served on your system to pop an AJAX request to the wrong URL every 5 seconds, as long as the tabs are open.

We can sit and argue all day whether or not it's ethical to display messages by injecting code into the DOM, but it is certainly unethical to write such awful javascript that clobbers global variables and drives up bandwidth costs by making AJAX requests to the wrong url every 5 seconds until the cows come home. Whoever wrote this script should be fired.

EDIT: Similarly, back in the dialup days, some ISPs would inject ads into their content. One way this was stopped was to argue that it was not legal for the ISP to charge you for data, then artificially inflate the size of that data by injecting ads. This script is doing just the same in a measurable way by causing these AJAX requests to be run every 5 seconds on every tab in your system.

Re: Comcast injecting JS

#36

I'm getting a lot of requests on our servers for "/e8f6b078-0f35-11de-85c5-efc5ef23aa1f/aupm/notify.do" so I can confirm this is in production. I can also confirm they suck at JS.

How about creating /e8f6b078-0f35-11de-85c5-efc5ef23aa1f/aupm/notify.do on your server to notify Comcast users about what their internet service provider is doing? If people started doing that en masse it could bring attention to the problem and with enough publicity get Comcast to reconsider JS injection. I don't really understand the point of this, either. Couldn't they starting redirecting users to a static page s…

Best idea ever! But, they'll probably prosecute who ever does it for some BS reason and sentence them to a term of 500 years

Re: Comcast injecting JS

#37
Comcast is such an incompetent company. I tried to sign up for service once and they charged me ten bucks to ship me two coax cables yet I was never able to get my service activated because I mistakenly thought my place was hooked up to cable when it wasn't and when I tried to call to correct this and schedule an installation I kept getting put on hold for a half hour before being given a message saying there was an error with their phone system and to call back. I mean seriously wtf.

Re: Comcast injecting JS

#38

Earlier quoted context omitted.

So you think they should inject a third-party dependency instead of just some inline js? And that would make it more elegant?

They could just inject it inline. No problem there. The whole document.write block 27-51 (possibly the CSS-block too, but I'm not sure about this) could be written far more elegant in jQuery. But the real saving is that "drag and drop" code - jQuery would abstract all that isIE/isNS crap from them.

Oh man, I thought you were being sarcastic earlier!?

...unless you're still being sarcastic?

Re: Comcast injecting JS

#39
post #35

This code is beyond awful - it fails to display, makes endless AJAX requests, and more; here are a few fun tidbits: 1. The code is not encapsulated in an IIFE, so it clobbers any global variables (like 'image_url') in the page, breaking any scripts relying on those variables. 2. The code spends an inordinate time checking if you're running Netscape Navigator 6. 3. Strangely, they include a whole bunch of code allowin…

That moment you see document.write()'ing style into the document... Yikes.

Re: Comcast injecting JS

#40

Earlier quoted context omitted.

So you think they should inject a third-party dependency instead of just some inline js? And that would make it more elegant?

They could just inject it inline. No problem there. The whole document.write block 27-51 (possibly the CSS-block too, but I'm not sure about this) could be written far more elegant in jQuery. But the real saving is that "drag and drop" code - jQuery would abstract all that isIE/isNS crap from them.

The block of code they injected here was 7.9 KB (3.7 KB gzipped). jQuery is 93 KB (33 KB gzipped). So no, I don't think that would have been more elegant. Injecting anything into users' pages without permission is insane. Injecting a huge library like jQuery would be even more insane.
Post reply on HN