* ...provider is intercepting the connection and injecting broken JavaScript

Who the hell puts up with stuff like this? Is this real?

If so, time to switch provider. Really.

it's real: https://news.ycombinator.com/item?id=10795344

See also: https://www.mysociety.org/2011/08/11/mobile-operators-breaki... where O2 stripped JS comments, without checking to see whether those comment delimiters were part of a string.

Yes, the unfortunate reality is a lot of places have de-facto monopolies in the US, but the monopolies get to claim there is still a free market by pointing to dial up or spotty satellite connections.

The user might not have another provider capable of fulfilling their needs. Either too laggy, too slow, too expensive, unacceptable data caps, or not mobile. It's completely possible for the user to live in an area where slow DSL is their only broadband option, the cell phone signal is weak, and the user can't afford satellite.

…locked in on a contract for 2 years, provided for them by their company, provided for them by their family, etc etc.

I think all mobile providers in UK do it, especially around downgrading images.

At that point I would either be switching providers to someone who didn't mangle my signal (because that's effectively what this is), or if that for some reason wasn't doable, I would at least install a VPN to a known secure, untampered connection (like my home router) and route everything through that connection.

Having someone intercept my signal and process it behind my back is simply not something I would tolerate from any communications-service provider I employ.

You are part of a tiny minority who has the technical interest / proficiency to do this.

To my knowledge Three UK doesn't. That's based on using them and not noticing any degradation, or the click-to-view-original-quality javascript that T-Mobile were (are?) injecting.

Comcast: https://www.aaron-gustafson.com/notebook/the-network-effect/

Some also block JS (sometimes accidentally). Remember Sky? https://www.theguardian.com/technology/2014/jan/28/sky-broad...

Vodafone (Fiji) used to do this.

They did honour the 'Cache-Control: no-transform' header though, so every site I build now includes that directive.

These are not solved by progressive enhancement but by SSL.

The author doesn't say that they are, he's simply listing reasons that a user may have JS disabled, and hence why it's a good idea to employ progressive enhancement, so that such users are not entirely locked out of using your app.

If you want to tackle these specific reasons, just serve the site via SSL. Other reasons for progressive enhancements might still persist, but the listed cause bigger troubles than "JavaScript does not work correctly" and SSL is a complete solution to all of them.

You're conflating user and service designer here. The user has a problem (including but not limited to those listed) and so turns off JS. The service then has the problem that JS is disabled... no amount of SSL will help if your pages require JS to load.

Edit to clarify: The user turning off JS and using the service are likely to happen at entirely different times. If you browse with JS turned off, it's likely off by default and only enabled when needed (if at all).

How many users actually disable JS for these (or any other) reasons? Might it be cheaper to e.g. have a call center that trained to use the website on behalf of such users, rather than increasing the development costs of every government site?

Last time we checked we get ~180k visits a month from people who specifically disable JS, ~810k further visits a month from people who don’t have JS available.

So no, it’d be more expensive to have a call centre.

I don't like this idea because it sacrifices ease of use in order to make small savings during the development phase. You shouldn't subject your users to extra grate where possible, and I think this is especially true for a government site.

My suspicion is that maintaining a call centre is more expensive than using progressive enhancement... but it's a fair question.

You're also assuming that starting from a simple HTML implementation is more expensive than other methods. I'm not sure that's the case.

As a rule, in terms of accessing public services at least, I'd be inclined to be very careful to make sure it was as accessible as possible.

"The user's service provider or corporate firewall blocks ssl"

Not everywhere, sometimes organisations such as the university i'm in make you install a certificate to access the network.

SSL is supposed to work a certain way, in practice it doesn't always work that way.

SSL won't do any good against a nation-state with a CA key, so it won't do any good against JavaScript injection by such a state.

How exactly SSL will solve this when there is a middleman proxy?

It is the whole point of SSL that there are not any.

My last point about the user’s country linked to the example of Kazakhstan, where all HTTPS traffic is blocked unless you install a government-supplied middleman cert.

And here's a good example of one hand giving while the other takes away; other parts of the UK government are quite cozy with Kazakhstan. We probably sold them the HTTPS interception solution.

> It is the whole point of SSL that there are not any [middleman proxies].

Hahahahahaha, you should do stand-up!

In my more cynical moments, I wonder if the whole point of SSL is to obscure when middleman proxies are in use.

Seriously, examine your browser's trusted CA list. Do you really trust every single one of those CAs to vouch for any website in the world?

If someone has got a CA to produce a fake certificate for your website, you have more serious things to worry about that progressive enhancement!

Unfortunately, most employers and many countries violate this expectation. I expect businesses providing wifi to customers to start doing this, too.

I don't know about 'most' employers - so far I haven't worked for one that has. But I'm sure there are many that do.

You mean this SSL? http://www.symantec.com/connect/blogs/gogo-inflight-internet...

If they inject broken JS, JS execution can stop and if you're not careful you might end up with a broken page.

Also good reasons to use HTTPS.