Unless I’m misunderstanding, this was not causing such a problem. Casting it as a customer good is rhetorically amusing, and probably holds water with people who are predisposed to agree with you, but I can make any number of morally bankrupt decisions using exactly the same logic. You have simpler ways to deliver this message, that do not cause nearly as much harm to your customer and do not require you to intercept and modify their traffic.
And mail pieces don't produce the potentially rather widespread indignation that traffic injection does. Granted, I don't see the harm in it that a lot of people here do. Unencrypted traffic is unencrypted traffic - open to tampering by anyone, not just Comcast, and for many less innocuous reasons than the one for which you've chosen to do so. But with Let's Encrypt, browser manufacturers, and friends leading the charge toward TLS everywhere or as nearly so as is practical, and with most sites that most people use already employing TLS, the attack surface is closing for even an other-than-innocuous variant of your notification methodology. Of course, that also means that that methodology itself is reaching a natural end-of-life, as it cannot work anywhere that TLS exists, and the majority of the web where it does exist continues to grow. If this low-latency notification scheme is of unique value to your business, then now is the time to consider replacing the outdated technology that underpins it with something which will continue to work reliably over the next decade or two.
All that said, I appreciate your decision to engage in this forum. That's unprecedented in my experience from someone in a position like yours, and I wouldn't mind seeing more of it.
Lots of reasons, including years of experience with response rates for particular types of messages / calls to action. Clearly one particular communications channel won't work for everyone - each person has their own preferences. One of the things we're working on is to better enable you to control just that - basically one person may ask for SMS messages, another alerts via their mobile app, another via email, another via phone call, etc. You can see the beginnings of that in MyAccount / Settings / Communication & Ad Preferences.
> But with Let's Encrypt, browser manufacturers, and friends leading the charge toward TLS everywhere or as nearly so as is practical, and with most sites that most people use already employing TLS, the attack surface is closing for even an other-than-innocuous variant of your notification methodology.
Agree. And more TLS is better IMHO. I also like the work that Let's Encrypt has been doing - they've had a really big impact on the adoption of TLS. (See also http://labs.comcast.com/innovation-fund-spotlight-lets-encry...)
> Of course, that also means that that methodology itself is reaching a natural end-of-life, as it cannot work anywhere that TLS exists, and the majority of the web where it does exist continues to grow. If this low-latency notification scheme is of unique value to your business, then now is the time to consider replacing the outdated technology that underpins it with something which will continue to work reliably over the next decade or two.
You bet - totally agree! One of the places we're engaging to try to do that is in the IETF's CAPPORT working group and I think the charter describes reiterates all the points you made: https://datatracker.ietf.org/wg/capport/about/
> All that said, I appreciate your decision to engage in this forum. That's unprecedented in my experience from someone in a position like yours, and I wouldn't mind seeing more of it.
My pleasure & thanks for being a customer that's willing to offer constructive criticism. :-)
The fact that Comcast has and abuses its monopoly is bad enough. That you would try to standardize your abusive behavior is appaling.
This reminds me of the part in Romeo & Juliet where Sampson says "I do not bite my thumb at thee, but I do bite my thumb."
As other commenters have mentioned, these are such small distinctions to legitimize something as fundamentally troubling as javascript injections.
Here's what a customer should do:
Just file a complain. Via snail mail. To the FCC. Include screenshots of VP explaining how this is all ok.
After that the customer should enjoy the show. I'm sure at least the customer is going to be provided a top tier service for the rest of his life in any comcast service region. Most likely for free.
This is how one teaches companies to behave. He or she finds a pressure point and exploits it. It does not matter that the opponent is 350lb gorilla. Small joint manipulation by a 95lb girl puts that gorilla on its back. For Comcast, VZ, etc that pressure point is a snail mail complain to the FCC. For national banks, it is the OCC. It works every time it is tried. What does not work is bitching about it on HN.
Well, what I meant (within the response length constraints of Twitter) was that we're not saying you can only buy it from us. Just that the customer needs to buy it someplace. That way a customer can do as the wish - ranging from buying a used one on eBay to getting a new one from Amazon or Best Buy.
Ultimately the objective is to ensure a customer is on a device that can (1) deliver the performance for which they pay and (2) is up to date technically (i.e. supports IPv6 and channel bonding) and is supported by the vendor (i.e. software updates & bug fixes).
One of the big risks we have to help mitigate is when a device goes EOL, which means no more software updates, and a security or significant performance issue arises in the future. By proactively beginning the replacement process this helps minimize any future impact when it is a major issue like that. So taking action gradually on a proactive basis prevents a more severe impact later on. In many cases, these are DOCSIS 2.0 devices and that technology and often the software is from 2001, the same year as the 1st gen iPod and when Windows XP was released.
Eventually a modem will go into End-of-Service (EOS) status. At that point there is a definite date/time limit for the device, after which it is de-provisioned from the network and the customer must replace it to continue service. This has been the case in the past with DOCSIS 1.0 and 1.1 devices for example, after years of work to encourage customers to replace them.
See also https://www.xfinity.com/support/articles/end-of-life-devices and the start of the EOL/EOS process for DOCSIS 1.1 devices https://www.dslreports.com/forum/r27473499-Speed-Heads-Up-Ti... and https://www.dslreports.com/forum/r28497383-Speed-Upgrade-You... and https://www.dslreports.com/forum/r30524429-Equip-Reminder-Pl... and https://www.dslreports.com/forum/r30450278-Speed-Heads-Up-Ti...