675970 - [Tracking Bug] Stub Installer Project

Status: RESOLVED FIXED

(Marketing :: Design, task)

Description

[Laura Mesa [:lmesa] [:lvmesa]]

Use this bug as tracking bug for all copy, design and branding changes to the Stub Installer.

Comment 1

[matthew zeier [:mrz]]

Is this going to happen for reals?  Woot.

Do you have a timeline when you think it'll go live?  There's some infrastructure that might need to be spun up.

Comment 2

[Laura Mesa [:lmesa] [:lvmesa]]

(In reply to comment #1)
> Is this going to happen for reals?  Woot.
> 
> Do you have a timeline when you think it'll go live?  There's some
> infrastructure that might need to be spun up.

Not too clear--I should know later today what the real timeline is, but probably late this Quarter at the earliest.

Comment 3

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Stub installer UI mockup (i2)

Comment 4

[Robert Strong (they/them - no direct email)]

Adding bug 594474 since it will greatly simplify building the custom ui with the newer version of NSIS

Comment 5

[Laura Mesa [:lmesa] [:lvmesa]]

Additional details:

As for the size of the installer, see Rob's comment from an email exchange:

"There really isn't a minimum or maximum size for image sizes in a stub installer or an installer. The rule of thumb is that the larger the images are the larger the installer will be and hence the larger the download will be and it is just a judgement call as to whether the additional size is worth taking when compared to the value the images provide. Another example, we have done several things to limit the current installer size and hence the download size in the past but if it needs to be larger due to Firefox code additions then all we can do is accept that fact. So, the images should be designed with keeping their size when compressed by the installer as small as possible.

When you have a set of images to test I can compile them into a compressed NSIS installer to give you the size they will add so it can be evaluated whether their size is too large."

As for having to use bitmap images:

"Windows UI requires using bitmaps. To use other formats from within NSIS will require the use of either an existing NSIS plugin or the creation of a new NSIS plugin depending on the the image. I know there are plugins that have some support for jpeg and gif though their quality isn't good so we will likely need to create new plugins. "

As for being able to update copy and images in the installer:

"Anything that is included with the installer can't be updated though you can host images and have the installer download them but this is not appropriate for:
1. images that need to be shown immediately on launch since there can be a significant lag before the image download has completed.
2. images that can be shown before it is reasonable to assume that the image download has completed such as the first image shown when displaying the downloading / installing page. For example, it should be possible to include the first image in the downloading / installing page and prevent access to the other ones that the user can hover over until after they have been downloaded. "

More details to come.

Comment 6

[Laura Mesa [:lmesa] [:lvmesa]]

Here's the link to the feature page for the stub installer:https://wiki.mozilla.org/Features/Firefox/Network_Installer

Take note we will be focusing on getting the Windows version built first, with customization of the installer and the OSX installer in a secondary phase to come in the future. 

It's also important to take into account that this will need to be localized. 

As for timing, I would like to get graphics and copy together for the 2nd of September--Tara, can you confirm if Sean and Matej can do that? If not, what about September 9th?  We're still trying to get more details on when our engineering resource can start on this. Hopefully more details in the next week or so. 

Lastly, Kev is going to get more numbers from the metrics team around failed downloads to make sure we're all on the same page.

Comment 7

[Tara (musingt)]

Should be doable, but am double checking with Sean and Matej as to which timeframe works best.

Comment 8

[matthew zeier [:mrz]]

Does anyone care what hostname the installer is hosted from?   Right now you eventually get to a link like:

http://download.mozilla.org/?product=firefox-6.0&os=osx&lang=en-US

Does anyone have a preference on the hostname?  https://download-installer.mozilla.org/... ?

Comment 9

[John Slater]

No strong preference from me, although my list of requirements would include:

1. .org domain
2. inclusion of the word "download" somewhere in there
3. keeping it as simple as possible

Comment 10

[Laura Mesa [:lmesa] [:lvmesa]]

(In reply to John Slater from comment #9)
> No strong preference from me, although my list of requirements would include:
> 
> 1. .org domain
> 2. inclusion of the word "download" somewhere in there
> 3. keeping it as simple as possible

Sounds good to me.

Comment 11

[Alex Faaborg [:faaborg] (Firefox UX)]

I would like us to avoid complex sub-domains when the user is installer software, so they are less likely to install Firefox from:

http://download-installer.mozilla.org.ihackedyou.net/?product=firefox-6.0&os=osx&lang=en-US&spyware=true

Comment 12

[matthew zeier [:mrz]]

Can I put a stick in the sand and say we'll go with

download-installer.mozilla.org 

?  I think that meets the requirements in comments #9 & #11.  Who will second?

Comment 13

[John Slater]

Works for me.

Comment 14

[matthew zeier [:mrz]]

Thanks.  This now makes my second contribution to Firefox that's been put into the product itself (see bug 416416).  I shall celebrate accordingly.

Comment 15

[Alex Faaborg [:faaborg] (Firefox UX)]

>?  I think that meets the requirements in comments #9 & #11.

it doesn't matter a huge amount, but this doesn't meet the requirements of comment #11 (no sub-domains).  We constantly mock sites that create domains like

secure.accounts.bankofamerica.com/blah and think that is acceptable, so asking users to trust download-installer.mozilla.org/stuff but not download-installer.mozilla.evil.org/stuff is really just as bad.

Is there a technical reason why we absolutely have to use a sub-domain?

Comment 16

[Kev Needham [:kev]]

(In reply to Alex Faaborg [:faaborg] (Firefox UX) from comment #15)
> secure.accounts.bankofamerica.com/blah and think that is acceptable, so
> asking users to trust download-installer.mozilla.org/stuff but not
> download-installer.mozilla.evil.org/stuff is really just as bad.
> 
> Is there a technical reason why we absolutely have to use a sub-domain?

I don't understand why no sub-domains would be a requirement. What does it buy us, other than having to manage another domain? At the end of the day, it's a hostname, and a domain.tld can be used in a similar fashion in a larger hostname under a "bad" domain as simply as host.domain.tld.

Using a separate hostname gives us considerably more flexibility with infrastructure, and ideally users wouldn't typically hit the hostname directly, but on a redirect from mozilla.com with the right attributes (which is how download.mozilla is used now).

Comment 17

[Alex Faaborg [:faaborg] (Firefox UX)]

>having to manage another domain?

we already manage mozilla.org

>Using a separate hostname gives us considerably more flexibility with >infrastructure

yeah, then we should just use the sub-domain.  but if there was no tradeoff, I would recommend we go with a simpler URL for users to parse.

>I don't understand why no sub-domains would be a requirement

we directly tell all sorts of other sites that we think they should stop using sub-domains in what are meant to be security sensitive transactions.  But, I would imagine the conversation over there goes about the same way as it is going over here, easier to manage, etc.

Comment 18

[Corey Shields [:cshields]]

mozilla.org/foo is insanely more difficult to manage for us than foo.mozilla.org

The former will be wrought with redirects and proxy passing that eats up resources unnecessarily, and the only justification I can see not to use foo.mozilla.org is because someone mocks other sites for doing so? I think we have some real technical issues with putting this on mozilla.org versus a subdomain.

Comment 19

[matthew zeier [:mrz]]

(In reply to Alex Faaborg [:faaborg] (Firefox UX) from comment #15)
> >?  I think that meets the requirements in comments #9 & #11.
> 
> it doesn't matter a huge amount, but this doesn't meet the requirements of
> comment #11 (no sub-domains).  We constantly mock sites that create domains
> like
> 
> secure.accounts.bankofamerica.com/blah and think that is acceptable, so
> asking users to trust download-installer.mozilla.org/stuff but not
> download-installer.mozilla.evil.org/stuff is really just as bad.
> 
> Is there a technical reason why we absolutely have to use a sub-domain?

I don't understand what you're saying (and I suspect this is getting out of scope from this bug).

download-installer.mozilla.org is either a hostname or a sub-domain without any hosts.  www.download-installer.mozilla.org would be a hostname within the sub-domain download-installer.mozilla.org and I wouldn't advocate that.

For a large number of reasons this can't be just "mozilla.org" and can not be a directory path under a shared hostname for all the reasons I had in bug 416416.  It becomes an Operational issue to scale a site that sits on a single IP address.

This also conflicts (or changes) the scope of the One Mozilla merge because it changes what those servers are doing.  

Also how much of this is even exposed to the user?

Comment 20

[Alex Faaborg [:faaborg] (Firefox UX)]

Download path will show up in the IE trust dialogs, but anyway never mind, it clearly isn't a possibility.

can we shorten down to download.mozilla.org?

Comment 21

[matthew zeier [:mrz]]

downlaod.mozilla.org conflicts with the existing bouncer installation.  I'm not at all clear that the two can co-exist.  If they can, I support that.  Copying Morgamic who'd know best.

Comment 22

[Laura Mesa [:lmesa] [:lvmesa]]

Tara--just wanted to check and see if this is on your radar? When can we can assets for this? Also, Matej and I can sync on copy direction. Let me know if I can follow up with him.

Comment 23

[Tara (musingt)]

Hey Laura.  Sean is taking this.  Can you please reiterate/confirm timing  on this please?  Thanks.  Also, filing under "design" as this was just filed under marketing/general.

Comment 24

[Laura Mesa [:lmesa] [:lvmesa]]

Thanks Tara--our contractor can start (at the earliest) the 2nd week of September. 

Can we try and get finalized assets September 9th? What are next steps for copy and direction? Open a copy bug?

Comment 25

[Jacob Appelbaum]

I'd like to suggest the use of TUF for a stub-installer: https://www.updateframework.com/

I'd also like to suggest that a stub-installer is signed with platform specific code signing tools and that the stub itself is first fetched over SSL/TLS.

Comment 26

[[e-mail]]

According to the spec, it doesn't look like bookmarks and settings are currently planned as part of this (though personas and add-ons are).

The Build Your Own Browser system (byob.mozilla.org) has been down for more than a year from what I can tell. Would be great to get that functionality back.

I also agree with Jacob in comment #25 that SSL/TLS needs to be built in. See bug #358384 for more discussion on that.

Comment 27

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Jacob Appelbaum from comment #25)
> I'd also like to suggest that a stub-installer is signed with platform
> specific code signing tools and that the stub itself is first fetched over
> SSL/TLS.

Bug 322206 is the bug for the stub installer; this one is for marketing-related aspects of it. The stub installer is going to be Windows-only (at least the initial version), and we will Authenticode sign it just like we sign the full installer.