Hacker News new | ask | show | jobs
by compbio 3834 days ago
Visit http://1.2.3.50 to disable this image compression for your device.

Add "Cache-Control: no-transform" to your headers to disable image compression for all your site's visitors.

Web devs should make sites that work without javascript, so that turning on NoScript is also a solution.

The bmi.js injection may look a bit nasty, but it is there to save bandwidth for users who are on a bandwidth budget. Vodafone would profit from higher bandwidth usage.

5 comments

What you say is technically true, but for a user it's complete BS:

- As a developer I looked for a way to disable this system - maybe something changed, but ~5 years ago I couldn't find any information about the 1.2.3.50 address and support told me it's not possible.

- Unless you're running a site that's professionally based on image distribution, you're unlikely to know no-transform exists.

- NoScript can block the bmi script specifically, not everything. Vodafone doing MITM shouldn't concern webdevs.

- The injection does not look nasty. It is nasty - you get no easy switch for it and cannot decide for yourself what behaviour you want. If you really want bandwidth saving, use opera mini - it's available for all phones now.

Sorry for being harsh, but I don't see how Vodafone's MITM can be defended in any way.

Use https.
> Web devs should make sites that work without javascript, so that turning on NoScript is also a solution.

Sorry but this is a ridiculous statement, it's like saying websites should still be able to run on Gopher. (Which some people want)

It's cool if you want to run NoScript but if you think website should/would be made around that you have cognitive dissonance.

Other than that, informative comment.

Progressive enhancement is easy. Your framework or development tools should do most of the work for you. Maybe try different tools?

> run on Gopher

Nonsense - CSS is very powerful, and all the functionality most websites need works fine with <form>s.

Part of the problem may be the difference between nice features with necessary features. Nobody would expect fancier features such as custom buttons/widgets or fancy client-side form verification to work without Javascript. You have to do all the checking on the server anyway.

> cognitive dissonance

Err, no - leaving out progressive enhancement is just lazy. Why would you prefer to shows people a broken website as a first impression? Do you even know how many people see a broken website? (i.e. do you check server logs?)

Do you do web development professionally every day? If so, how long would you estimate you spend on making sure HTML-only pages render correctly?

Do you ever do advanced sites where multiple actions exist on one page that can't be easily encapsulated in HTML?

I ask because calling devs lazy for not backwards-checking their JS scripts is a bit much. So you want them to solve the problem they just solved, except this time, do it without some code assistance? That seems a bit unreasonable.

For many sites these days it is acceptable and justifiable to run Javascript. That was not true in the early 2000's, but we are a long way from there.

Agreed. Neither Facebook nor YouTube run without JS enabled, which means that the vast majority of your users will never even consider turning it off.
Facebook and YouTube, as highly interactive applications, are not "most websites".

Practically ever single blog, news site, store, business page, and the like have zero need for Javascript, and requiring it only makes your site look broken. The maybe better with Javascript, of course.

While I haven't worked on websites in the last year or so, I have made websites professionally in the past for many years. Making a progressively enhanced store that works without Javascript in Rails 2/3 was really easy.

> vast majority of your users will never even consider turning it off.

How do you know this? Are you guessing? Are you relying on Javascript-based analytics and are therefore blind to people that disable Javascript? Do you have server logs that show how many people disable Javascript? Is you site broken without Javascript so this claim becomes a self-fulfilling prophecy?

I ask this every time someone makes that claim, and have never gotten a response.

> How do you know this? Are you guessing?

> I ask this every time someone makes that claim, and have never gotten a response.

Well, i am glad to help out. Have a look at [1] which presents data of 509.314 visitors.

Isn't that great? Now you don't have to ask every time somebody makes that claim!

[1] https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...

This is honestly just out of touch with most modern Web development. Even if its "easy" to develop (which is debatable), if its not a priority with product managers it will simply not happen in today's "more with less" technology industry. Consider also that users who block JavaScript also block most analytics packages (by design)--from a data-driven product management standpoint, users who block JavaScript literally don't exist. Web QA is hard enough across multiple browsers and OSes; adding to that a second version of the site for users whose presence can't even be quantified is not going to be popular.
> Nonsense - CSS is very powerful, and all the functionality most websites need works fine with <form>s.

"You don't need a language other than __. __ is a Turing-complete language, thus is very powerful, so it should have all the functionality most developers need."

> a Turing-complete language

Most websites don't even need a Turing-complete language. Which is kind of the point - Javascript is a security risk and a privacy risk precisely because it is Turing-complete.

Css is also turing complete. Seriously.
No need to apologize for giving your opinion. I have strong feelings on accessibility and security, perhaps a bit too strong. Others may rank design or "a fast development pipeline" higher than me.

I expect content websites to function without requiring JavaScript. I'll settle for a much poorer experience, as long as I can access the content.

Put more strongly: Nothing is gained (from a user perspective) by requiring JavaScript, but security is lost (Tor disabled NoScript because too much of the web would break, leading to disclosure of user data [1])

[1] http://www.wired.com/2014/08/operation_torpedo/

"Sorry but this is a ridiculous statement, it's like saying websites should still be able to run on Gopher."

Web devs should indeed make sites that work without javascript. They don't have to be fancy, or do every little advanced thing, but they should work.

>> Web devs should make sites that work without javascript, so that turning on NoScript is also a solution.

> Sorry but this is a ridiculous statement, it's like saying websites should still be able to run on Gopher.

Sorry, but your statement is ridiculous. Unless the website is an application, that is, it does something useful, it's just bunch of text and images. You should not expect people to give you full Turing capability just because you're too full of your awesomeness that you can write a program.

> It's cool if you want to run NoScript but if you think website should/would be made around that you have cognitive dissonance.

I don't think that term "cognitive dissonance" means what you think it means.

Also please avoid ad hominem statements on Hacker News. It's not far away from saying "if you think that then you are stupid", and no more constructuive.

1.2.3.50 is within the "APNIC Debogon Project" range. I don't understand using these kinds of ranges as internal IPs - Vodafone controls the DNS servers for these devices so just make it optout.voda and resolve that somewhere that you actually own.
Well it's pretty much the addresses you start using when you've run out of IPv4 addresses everywhere else.

A very popular example of this is 100.64/10, but one can find little bits here and there. Plenty of providers don't just use that range but 1/8 is pretty safe to use.

There are even posts on networking mailinglists about tests for using the multicast ranges (multicast doesn't work* anyway and is now widely considered a "never gonna happen" design). Leave 224.0.0.0/24 alone and you can pretty much use the rest of 224.0.0.0/4. Also, most of broadcast is fine to use on most networking equipment.

* of course, locally within a network it does work for a very small number of multicast streams (certainly doesn't work for 2^28 multicast streams as designed, so in ipv6 they upped the number of available multicast channels to 2^120)

1/8 is absolutely not safe to use. There are many real IP addresses assigned in that range; for instance, 1.5/16 is assigned to a Japanese ISP.
> Web devs should make sites that work without javascript, so that turning on NoScript is also a solution.

Ideally, I guess that would be true, but from a development cost perspective and user interface perspective that is just not possible in 2015.

For complex platforms I may see your point. But what about personal pages or blogs (including hosted like Wordpress)? Why do webdevs even remotely consider publishing an empty webpage in case the client does not run javascript?

What do you think my impression of your website is when all I see is a blank page or an endlessly spinning loading wheel?

Yes, I agree. For static content pages, the content should largely render and its content should be largely digestible whether or not the client's javascript engine is running.

That being said, an easy defense against webscrapers and content re-purposers is to make sure the client is running javascript.

Of course, there are ways around this, but I liken it to this scenario: If there are two similar houses on a block and only one has an alarm system, the cat burgler will choose the one without the alarm.

and HTTPS :)