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