7 ms·
I like the reasons they give why users might not have JS, even though they haven't blocked it themselves. Here are three: * user’s hotel is intercepting the c
by adrianratnapala 10y ago
I like the reasons they give why users might not have JS, even though they haven't blocked it themselves. Here are three:
* user’s hotel is intercepting the connection and injecting broken JavaScript
* user’s telecoms provider is intercepting the connection and injecting broken JavaScript
* user’s country is intercepting the connection and injecting broken JavaScript
Broken or not: all three of those sound like good reasons to intentionally block JS.
- allendoerfer 10y agoThese are not solved by progressive enhancement but by SSL.
- pmlnr 10y agoHow exactly SSL will solve this when there is a middleman proxy?
- allendoerfer 10y agoIt is the whole point of SSL that there are not any.
- robin_reala 10y agoMy 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.
- pjc50 10y agoAnd 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.
- NoGravitas 10y agoUnfortunately, most employers and many countries violate this expectation. I expect businesses providing wifi to customers to start doing this, too.
- madeofpalk 10y agoI 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.
- zeveb 10y ago> 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?
- CJefferson 10y agoIf someone has got a CA to produce a fake certificate for your website, you have more serious things to worry about that progressive enhancement!
- asib 10y agoThe 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.
- allendoerfer 10y agoIf 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.
- richmarr 10y agoYou'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).
- lmm 10y agoHow 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?
- robin_reala 10y agoLast 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.
- asib 10y ago
- neximo64 10y agoNot 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.
- zeveb 10y agoSSL 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.
- aarongustafson 10y agoYou mean this SSL? http://www.symantec.com/connect/blogs/gogo-inflight-internet-intentionally-issuing-fake-ssl-certificates http://www.symantec.com/connect/blogs/gogo-inflight-internet...
- josteink 10y ago* ...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.
- joelanman 10y agoit's real: https://news.ycombinator.com/item?id=10795344 https://news.ycombinator.com/item?id=10795344
- robin_reala 10y agoSee also: https://www.mysociety.org/2011/08/11/mobile-operators-breaking-content/ 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.
- DanBC 10y agoI think all mobile providers in UK do it, especially around downgrading images.
- josteink 10y agoAt 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.
- paublyrne 10y agoYou are part of a tiny minority who has the technical interest / proficiency to do this.
- moreati 10y ago
- pluma 10y agoAlso good reasons to use HTTPS.
- yread 10y agoIf they inject broken JS, JS execution can stop and if you're not careful you might end up with a broken page.