Hacker News new | ask | show | jobs
by qwerty_asdf 4623 days ago
I find it irritating that Mozilla now herds its Firefox users toward the Stub installer, and not the full offline-install redistributable binary.

The actual download itself is available on the "Systems & Languages" page:

> https://www.mozilla.org/en-US/firefox/all/

This kind of download is important, when you want to try out a new release, without committing yourself to it. For example, let's say you want to load it up in a VM, without contaminating your normal environment.

Googling for things like "firefox standalone redistributable offline install" are a road to nowhere.

You sort of just have to "know" that "Download Firefox in your language" means "Download the standalone installer, and not the stub installer". They don't explain this, or make it obvious that this is how you can get a copy of a static binary for predictable results.

14 comments

Large downloads dramatically decrease the number of users who get from a download page to actually running an application, even for web browsers. As a result, any steps you can take to make an install process faster or easier will have a tangible impact on the number of customers you have (and any revenue potential that results). Mozilla, like any other company, has salaries to pay, so they would be foolish to make things worse for the majority of users just to make them slightly easier for theoretical users who want to install in a networkless VM and can't figure out that the stub is a stub.

It's a complication, but it eliminates the need for the user to come back after waiting for some dozens of megabytes to download and then interact. You can download a stub near-instantaneously, do things like pick your install directory, and then forget about the install process entirely as it completes without your supervision. That's a good thing, and it isn't possible with offline installers.

Browsers like Firefox and Chrome already need network access after installation anyway. They update on a regular basis, and pull down optional packages like Chrome's software WebGL rasterizer, malware blacklists, and Firefox's GPU blacklist. So, in practice, it is already impossible to do a true offline install of either browser; you just may not be aware of the things that are left out of the installer.

  > Large downloads dramatically decrease the number of 
  > users who get from a download page to actually running 
  > an application
I think I almost entirely agree with you on that.

  > they would be foolish to make things worse for the 
  > majority of users 
I'm arguing that this provision (clearly pointing the way toward an offline install) would not make things worse for anyone.

  > just to make them slightly easier for theoretical users
I am not a "theoretical" user. I am an actual user.

  > ...do things like pick your install directory, and then 
  > forget about the install process entirely as it 
  > completes without your supervision. That's a good thing, 
  > and it isn't possible with offline installers.
What?! What are you even talking about? I can pick my install directory with the full installer. I double click the icon, it asks me for the directory, it runs, and then the end.

Firefox's installer is dead simple, and believe me, I am HUGELY grateful for that. The only thing easier than the Windows installer is unzipping the Linux tarball into whatever path I choose. I hate Adobe's Flash and PDF installers, and I fucking DESPISE the Java installer, with its damnable bundling of that bloody Ask.com toolbar.

Seeing Firefox add these additional layers of background updater services and stub installers deeply worries me, and fills me with concern that as a "salary paying organization" (albeit, ostensibly non-profit), they might veer down an ugly path, go the way of the Sith, and start engaging in questionable behavior that is inappropriate for an open source project.

Consider the example of Ubuntu's desktop file search bundling Amazon ads in the results. What if one day, Mozilla decides that in order to pay the bills, it needs to negotiate a deal, whereby all those users with automatic updating enabled should get railroaded with some kind of optional-but-defaulted-to-enabled third party feature suggesting helpful reminders to buy more burritos from Jimbo's Refried Beans Emporium. Just sayin'...

  > Browsers like Firefox and Chrome already need network 
  > access after installation anyway. 
Not to do things without my permission, they don't. This "need" business... I disagree.

A browser only "needs" to to exactly what I ask it to do, and not much else. I tell the browser what to do, not the other way around.

  > They update on a regular basis, and pull down optional 
  
Optional. That's an important adjective in your sentence.

  > packages like Chrome's software WebGL rasterizer, 
  > malware blacklists, and Firefox's GPU blacklist. 
Yeah, the very same blacklist that I'm frequently bypassing to check out all the cool Web GL experiments people post here on HN. I know all about that.

Malware blacklists are another concept that I tend to reject as mostly ineffective in achieving their stated goal. We could go round and around with that argument for days. Let's not get started on THAT can of worms.

  > So, in practice, it is already impossible to do a true 
  > offline install of either browser; you just may not be 
  > aware of the things that are left out of the installer.
When you use the word "impossible", I have to just flatly disagree with you. And in general, most of the things that you mentioned are things that I don't care about, and will never be interested in.
As I explained in the parent post (which you failed to parse correctly - was my English too complex? I'm not the greatest at writing clearly), the advantage of the new streaming installer is that all user interaction is frontloaded, not that it adds new UI. I don't know why you thought I was claiming the ability to pick an install directory is a new feature.

Anyway, my point re things like the blacklist and webgl rasterizer is that the browser is not completely installed without those components. The offline installer is missing key features and components of the browser; things that show up on feature lists that web applications can rely on. Without the WebGL rasterizer, WebGL demos won't work in your offline-installed copy of Chrome in your VM without hardware accel. Without the GPU blacklist, on some configurations Firefox will be nonfunctional (or worse, crash your machine) because it attempts to do acceleration on a broken driver. Audio/video codecs are another area where it's no longer possible to realistically ship 'everything' in a single offline installer.

If you simply want an offline installer for a bare minimum browser that can do a stripped down subset of HTML5, it's still possible to deliver that. But the amount of the 'web' that works in that bare minimum installation will keep decreasing.

P.S. The reason Firefox has to install a service is because it's not possible to install updates cleanly in any other fashion on UAC-enabled Windows. Your alternatives are installing into %AppData% (like chrome does, which removes the ability to pick an install dir and has other gross consequences) or requiring the user to UAC elevate every time an update installs. As I stated in the parent post, not installing updates puts users at risk when you're dealing with a web browser - the attack surface is enormous.

  > The reason Firefox has to install a service is because 
  > it's not possible to install updates cleanly in any 
  > other fashion on UAC-enabled Windows.
Ah ha! Now you're speaking my language! That I understand perfectly!

It makes sense that Windows UAC has forced bad decision making. Windows, in general, is just a hideous, mutated mess nowadays.

Anyway, it's essentially a correct decision to never marry a browser to device drivers or hardware. The websites that count won't dare crash browsers due to hardware requirements. The browsers that count will fail gracefully, and tell the user that their settings are not compliant with the requirements of the page they are trying to view, before they ever crash. However one wishes to communicate the nature of highly specific user options, and then adapt to the long fragmented tail of hardware conditions, is beyond the scope of a "NORMAL" web browser (no-true-scotsman).

When requirements become that unforgiving, you've entered the realm of the highly specialized plug-in, or custom client-server software. It's cool that Firefox is brave enough to wade into those territories, and still deliver awesomeness, but the core necessities of the web browser should never be sacrificed, for fluff and sugar-coated eye candy.

I'm really not worried about the idea that "The Web" is changing. The sites that matter will always work with the bare minimum, with little more than HTTP GET and HTTP POST, even with JavaScript disabled.

The rest is just cruft.

All your points are valid, but none of them explain why Mozilla couldn't or shouldn't just put an explicit link from the main download page to something like "offline install" or "redistributable install."
> So, in practice, it is already impossible to do a true offline install of either browser; you just may not be aware of the things that are left out of the installer

Some people have lousy Internet connections. Those people use things like download managers to help. Download managers don't work with stub installers.

A simple link to a true offline installer would help those people. (Torrent is fine too, I guess.)

For example, let's say you want to load it up in a VM

You've just excluded >95% of Firefox users. Those that do use a VM will know how to get hold of the full installer.

If they'd stop making full installs, I would be annoyed. But they're just optimising for the most common use cases.

I know. I know. Believe me, I know. That detail is not lost on me.

My complaint is simply that it's hard to find, and for those who want it, there's no real road map or sign postings for where to get it.

Preface: I wrote the following from a more general perspective. Perhaps Mozilla can and will speak to the specific changes under discussion in this thread (e.g. keeping the majority of "non-technical" users on the right/current release).

A bit like the so-called "Chromification" of the UI: I don't want to see too much "power" obscured or sacrificed for the sake of usability. Keep things sane, also, for the "power users".

----

When I see patterns like this, too often as I look further, I become convinced they are deliberate. I suppose one can argue as to motive and intent. Nonetheless, they seem to be forcing all users toward a more dependent and opaque pattern.

Therefore, I consider them "dark patterns". If you want to label that as my personal perspective ("you're weird"), then so be it.

If say 5% of your users want a stand-alone installation package, is that too low to add the description and/or provide a link to "stand-alone installer"? Is it really going to destroy usability if you do so?

And that's where, once again, I -- in my opinion -- start to bump up against today's "designers". Where pages and everything else have to be "streamlined" to the point of excluding any and all minority usage patterns.

"The web" used to be about choice. TIMTOWTDI. Some of us have atypical patterns, sometimes for good reason. In my opinion, that diversity breeds robustness. Things get examined from different angles. And no single pattern becomes irreplaceable.

It's fair to be annoyed by these design changes, but there's nothing you can do. It's already impossible to truly bundle every single dependency into one installer for an application like a web browser. They can and will change on an hourly basis, and having out-of-date (or worse, missing) data for things like blacklists can compromise your security.

It's only natural that an application that's designed to communicate live with servers on the internet would, at some point, have to pull more and more of its configuration and application logic from the same internet. The browser's still open source, so if it bugs you, you're free to compile a build yourself and gather all the dependencies manually.

The fact is that there are still stand alone installers available for all sorts of configurations, right there on the Mozilla FTP where they've been for something like a decade. If you're a power user and you're saying you can't figure out how to hit an FTP server or type 'firefox standalone installer' into a search engine, I don't know what to tell you.

Calling this a dark pattern is absurd. Nobody's being tricked, you're not being conned into opting something other than what you intended. The same Firefox gets installed either way, the install process is just streamlined in ways that increase success rates and simplify it for most users.

I think it's fair for you to call me out, a bit. My preface was probably not sufficient or adequately fair in itself. The specific complaint did trigger my memories of a more general circumstance, upon which I then rattled off a comment.

As to the Firefox installer specifically, now that my brain and memory have had a chance to catch up with the rest of me, I dealt with its "stubification" some time ago. When that first occurred, I was somewhat annoyed. However, I fairly quickly found that full installer downloads were provided under the... "other languages and systems" link/page, or whatever it is specifically labelled.

I did also, over time, observed that the new pattern, including automatic downloads and updates -- or prompts to update -- probably would help significantly in keeping the majority "non-technical" user population up to date, particularly on Windows, that I was using more at that time.

More recently, I've been using Ubuntu primarily, and I've gotten used to the release hitting package management within a couple of hours. I reboot daily, and usually check for and install updates when I do, so Firefox updating has just become part of the daily routine.

I do, nonetheless, think there is something of a "dark pattern" going around, in general, of making erstwhile stand-alone processes more dependent upon network-connected and dependent back-end services.

When I occasionally help family and friends out with a new computer, no longer can I download their ISP-provided security software and get it up and running before plugging into the network. Nope -- that's all network-dependent installs, now. (Used to be, you could sign in to the ISP, generate a license key, and then use that to validate against a stand-alone installation package.)

At least Windows now has a default firewall that actually kind of works, and most people are behind a wi-fi router that has its own firewall. These mitigate the "machine will be probed within minutes if not seconds" scenario that's been described ad nauseum in the last decade plus.

There was also a point in time when moving forward in version could and did sometimes break things. Some of use became sensitized to automated updates and no convenient, or at all officially provided, way to roll back. And some of those update processes could and did get a bit annoying of themselves with their resource use.

Adobe has switched to a online-dependent, "rental"-heavy licensing pattern. To subsequently have X million user accounts compromised. (Thank goodness I purchased my full, stand-alone installation of 5.5 from Amazon.)

Dark patterns...

They want to keep their website simple. If you're installing in a networkless VM, you probably have the technical experience to know to Google for the full installer.
Speaking of hard to find offline installers... google voice/hangouts plugin, holy moly
The stub itself pulls down the full installer, and you can always get that from download/FTP if needed.

The intention is to provide a better download experience: there was a gap between the number of people who begin downloading Firefox (counted via hits on download.m.o), and the ones who open it for the first time (counted via hits on the firstrun page). The stub installer is intended to address this. It also checksums the full file to make sure you're getting what you think you're getting.

(Disclaimers: I work for Mozilla, and am responsible for download.mozilla.org among other behind the scenes web things. I don't work on the installers, but we had to change the download scripts to support the stub. I do not speak for Mozilla.)

I think the stub is for an improved experience for the average user with slow internet access. You're likelier to download and run a 1MB file and then wait for the install to finish, than you are to wait for a 25MB file to finish downloading in the first place.

(I wonder if they push the stub so as to collect more (system) information without having to say that it's Firefox itself that's collecting that information.)

Wrong, the stub is an annoying experience if you are behind a company firewall, or with slow connection. And the point about bandwidth saving doesn't make sense either, since instead of putting Firefox installer in a file share and be done, now I have to put there a stub, instruct everyone how to bypass the proxy, if possible, and then everyone has to download it again and again.
A stub can save bandwidth by only downloading the components needed for your system, instead of having to pack in every possible optional dependency.

The alternative, expecting all users to know precisely which components they need, is absurd and never works. And we all know you can't reliably do configuration detection in a web page to that extent either.

Well, in that case, you can easily put (or link to) the full download, can't you?

Or am I missing something?

You are missing his point that it's not easy to find.

"Systems & Languages" doesn't tell me anything about being able to find the offline installer there. Either changing the phrasing to something more explicit like "Other downloads", and/or adding a title attribute explaining what can you find there could be a good improvement.

Also, giving a hint at the "thank you" page (ex. Having trouble? Try the offline installer) would be a nice addition.

Well, if I understand his post correctly, his process was "putting Firefox installer in a file share and be done." Well, this process still works.

> You are missing his point that it's not easy to find [...]

That, on the other hand, is a valid point.

Well, to be honest, I completely ignored the "putting Firefox installer in a file share and be done" part, because there are infinite reasons why an offline installer is needed (and also because I already saw people killing themselves in this discussion).

Entering in much detail of a specific use case is not really a helpful way to leave feedback, but it's understandable since users have the perception that their use case is completely ignored/forgotten.

When chrome got released, the instantaneous feel of downloading a stub which then pull the rest was enjoyable. I understand your points, but it's not 100% annoyance, it has a little value.
I think it's mostly a tactic to mitigate, prevent, defend against denial of service, since the Mozilla user base is absolutely gigantic.

My suspicion is that it's essentially a "security through obscurity" tactic, so that the majority of users are left with no choice but the "smart" installer, which offers greater control for load balancing heavy duty traffic during peak download periods.

See also: http://news.ycombinator.com/item?id=5613152

Sorry for the trouble you had to go through. If you have access to an FTP client, you can go to ftp://releases.mozilla.org/pub/mozilla.org/firefox/releases/latest

or you can go to http://releases.mozilla.org/pub/mozilla.org/firefox/releases... from a traditional web browser as well

Cheers!

Mozilla uses Akamai as their CDN. As big as Mozilla is, a Firefox release probably is not even visible on a bandwidth graph.
> I wonder if they push the stub so as to collect more (system) information without having to say that it's Firefox itself that's collecting that information.

That sounds rather unlikely.

Should be not too hard to verify.
Yeah, that is if you have dial-up. Even the slowest DSL is enough for 768KBps.
That really depends on the country you live in.
Super annoying, yes! I completely agree with you. It's not just Firefox being the culprit here though... .NET is the same, and so is Chrome, and the list can grow like a mayor's coat-tails!

Also, here's a genuine usecase for a truly offline installer... What if you are the "resident software/pc maintainer" of your extended family.... In such a case, would it not make better sense to have one complete download, then copy it into a pen drive, and install it on every machine, without spending 30 mins to an hour on every machine, doing a download+install for every single one!

The rationale of an online installer might be justified as some of the replies indeed seem to do, but, I think that there is something fundamentally flawed/wrong with having to first "download an installer", only to have it "download the application" again! I mean, what the hell!?

EDIT: Also, the speed of these release cycles (not just Mozilla, but other software too!) are getting old and tired to keep up with, TBH...

Each of the 3 systems you mention have reliable update mechanisms and a track record of not really breaking things on updates.

Especially for consumer PCs, there doesn't need to be anything to keep up with.

Sigh Yes about those three.. But really, I just used those three as immediate illustrations and they are by no means the only ones doing this! And I am really not interested in offering a big list of all the software on my PC, that all do this online thingy, but are not similarly reliable as those three.

>> let's say you want to load it up, [snip] but without contaminating your normal environment.

Add-ons don't necessarily survive every upgrade, and take some time to catch up with the new release. Many people that I know, (in the family and outside) would rather wait on a new release than have one of their add-on break on them.

So, whatever way you put it, I am firm in my statement, that an offline installer should be a de-facto proviso, rather than being buried somewhere else.

The automatic updater takes care of all of the use-cases you mentioned better – why waste time manually copying files around when your relatives could be running the update days before you make it over with that thumb drive?

That said, they do make the full installers easily available (google “Firefox offline installer”) should you need to update a ton of computers behind a slow connection.

In case, you missed it, the moot point in the parent thread as well as my agreement is this: "an offline installer should be a de-facto proviso, rather than being buried somewhere else." In other words, The fundamental issue in this rant of course is, "Why the hell should I do all that? Make it available in the front page!"

For sure, lycos/ddg/ask-jeeves/bing "Firefox offline installer" is an option that is not lost on us luddites :).

But did you also notice the parent comment: "Googling for things like "firefox standalone redistributable offline install" are a road to nowhere"? ;)

> he fundamental issue in this rant of course is, "Why the hell should I do all that? Make it available in the front page!"

They could make it more obvious but, really, the audience for that page doesn't really include people who are familiar with technical issues and have made the calculation that it would be faster to download the full thing & copy it around.

> But did you also notice the parent comment: "Googling for things like "firefox standalone redistributable offline install" are a road to nowhere"? ;)

I did – and part of the point is that that's an unnecessarily complex query. Removing any of the redundant words (e.g. "firefox standalone installer", "firefox offline install") produces the correct result as the first hit. ("redistributable" appears to be the problem as that term hits a bunch of spam download sites)

In other words, that search query was itself an attempt to micro-optimize something which turned out to be unnecessary – rather like the entire post.

If anything "Mozilla herds its Firefox users" into using the auto update system inside Firefox, which is very convenient and helpful.

You're talking about a very small number of people who will update the way you described.

Most Firefox users will update by having Firefox automatically update in the background and then be prompted to restart.

I just downloaded the latest version (in my language) by going to 'About Firefox' and hitting the update button.

I find it irritating that Mozilla now herds its Firefox users toward the Stub installer, and not the full offline-install redistributable binary.

It makes sense though. The modern browser is epitome of "the user is always online, and should always receive and run the latest version of code on the fly" execution model. Why not apply those assumptions to the execution environment too?

Defaulting to the stub is probably a security decision, so you don't end up installing the same old security holes every time you run an out-of-date installer. But they could probably make the full install easier to find for people who want it.
Alternatively, you could wait for the folks over at PortableApps to update: http://portableapps.com/apps/internet/firefox_portable
Uh, no thanks.

That site does not readily provide hashes for their binaries (MD5, SHA512, whatever), and the page is smeared with ads. There's no way to know if the site is trustworthy.

And, anyway, where would I get the trustworthy hashes? They'd need to be communicated to me, directly from the horse's mouth. I'd need to visit ftp.firefox.com, to find out what the correct hashes are in the first place, and then check them against the binary download I receive from your site.

The link you should have provided was:

http://sourceforge.net/projects/portableapps/files/Mozilla%2...

Version 25 isn't listed there yet.

All of this is even less convenient than digging for and deciphering the meaning of Firefox's official downloads.

Umm... Hm. I'm seeing just one ad on that page (a very conservatively placed Google AdSense ad): http://puu.sh/530fg.png

Also, I see the hash right there on the page: http://puu.sh/530kX.png

I think you literally jumped the gun with your assessment of portableapps platform. :)

Take a look again over the weekend. They are completely FOSS and all their bundling and bundled packages are transparent.

The entire project is voluntary, and it usually takes a day or two from the official release dates, before the volunteers bundle, test, and release the portable application to the general users.

This! I wanted to mention this, but since you already mentioned it, I will simply add my comments to yours....

The concept of PortableApps has been simply amazing! (FWIW, I donate to this project too, it's been really worthwhile having the platform).

I have begun to adopt this mechanism for some of my software maintenance strategy. Nowadays, I test the latest version of the updated "PortableApp" on my local copy on my machine first, and if all works well post-update, I ask others to choose the update. Else I simply tell them to uncheck the update until I can confirm that existing functionality remains unbroken. :)

But that's so much hassle, I have to click on the link and then navigate a whole bunch of folders, and possibly know what version and language I need! </sarc>

Users of VMs are more than likely power users at the very least, and if you want to test different versions then you should probably also be testing beta and even nightly. I don't think a full exe just to install in your VM really needs to be "homepage" visible.

As I've had to rollback, I just keep this page in my pinboard account: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/
Do you really want to test out a new release of a web browser on a VM without an Internet connection? It seems like you would be missing out on a lot...
I'm getting the full version download. It might just be location (UK) or maybe random. I don't know.

Edit: It's probably just that I'm using Linux.

Yeah, the stub installer only applies to Windows. Mac and Linux users are always given a full binary.
You can get all the full installer files on the ftp.