Last Comment Bug 275743 - Capability to require agreement to EULA, etc. before user installs
: Capability to require agreement to EULA, etc. before user installs
Status: NEW
:
Product: Core Graveyard
Classification: Graveyard
Component: Installer: XPInstall Engine (show other bugs)
: Trunk
: All All
: -- enhancement (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 364308 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-22 16:56 PST by Duke Fan
Modified: 2015-12-11 07:21 PST (History)
21 users (show)
asa: blocking1.8b3-
benjamin: blocking1.8b5-
darin.moz: blocking1.8.1-
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Duke Fan 2004-12-22 16:56:54 PST
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; yie6; YPC 3.0.0; Infowalker v1.01; .NET CLR 1.1.4322)
Build Identifier: 

we'd like to list extensions for Mozilla and Firefox, but need to display a 
EULA before users installs. is there support for this? can we link to a web 
page instead of the XPI file? i'm assuming other companies have the same issue?

Reproducible: Always

Steps to Reproduce:
1. click a link to install Extension
2. extension downloads, but no opportunity in install flow to display EULA for 
user acceptance
Actual Results:  
no opportunity to display EULA for user acceptance

Expected Results:  
display a EULA before install. if user disagrees, then cancel the install.
Comment 1 Nickolay_Ponomarev 2004-12-22 22:46:09 PST
Is this a question about update.mozilla.org?
Comment 2 Duke Fan 2004-12-23 13:47:23 PST
yes. this is a question about update.mozilla.org

can we list an extension using an html URL?

if we have to list the URL to the XPI, how can we display
an End User License Agreement?

thanks,

 duke
Comment 3 Nickolay_Ponomarev 2004-12-23 14:13:50 PST
I'm afraid it is not possible to display an EULA during an installation of a
package compatible with Firefox 1.0/Thunderbird 1.0 extension managers.

So I think it can only be solved by linking to HTML page or putting EULA on
extension's page at u.m.o. Moving back to Update product.
Comment 4 Wolf [:wolf] 2004-12-23 14:41:29 PST
To answer your question:
Update is not designed to support linking directly to html documents. Its
designed to link to XPIs and JARs directly. (The Javascript calls used for the
install links are explictly for Mozilla/Firefox's XPInstall.) It does not
support, at this time, inserting an EULA in the middle of this process.

Bouncing bug to the correct component.
Comment 5 alanjstr 2004-12-24 03:51:29 PST
I thought this would be a Extension Manager issue, displaying an EULA during the
install process.
Comment 6 alanjstr 2004-12-24 03:56:13 PST
Nor do I think it is appropriate for UMO to redirect to a non mozilla.org URL. 
It would be possible to have an interstitial on the website if an EULA is included.
Comment 7 Daniel Veditz [:dveditz] 2004-12-24 12:08:57 PST
However it happens, we *do* need the ability to display a EULA, if only our own.
Comment 8 Daniel Veditz [:dveditz] 2004-12-24 12:10:57 PST
Agreed w/comment 4 and 5, the EULA should be hosted by us somehow and not
remote. Either part of the package and handled by the client (comment 5) or
uploaded along with the package.
Comment 9 Daniel Veditz [:dveditz] 2005-01-11 11:00:33 PST
This is most appropriate as an XPInstall feature, so that no matter how the
package is obtained the EULA is shown. If it's done as merely an
update.mozilla.org feature then it wouldn't get seen by anyone digging around
directly on the ftp servers for the install.

The down side is that the EULA wouldn't be shown before the download, but that's
actually standard behavior for binary installs like Java, Adobe Reader, etc. and
those are much, much larger than Firefox extensions.

taking.
Comment 10 Jon Granrose 2005-05-04 14:58:18 PDT
just to clarify - this bug is still about creating a mechanism for an extension
to display a EULA (either built into the xpi or from a URL) if the xpi creators
needs to do so.

is that correct?
Comment 11 alanjstr 2005-05-31 12:27:30 PDT
How does PFS handle this?  This would allow us to satisfy the MPL/GPL because
the authors could document where to find the source in that license agreement.
Comment 12 Jon Granrose 2005-06-28 12:41:57 PDT
alan - what's PFS?

the more I run into the problem, the bigger it becomes.  I don't suppose there's
anyone on the cc list with time to look at this?
Comment 13 alanjstr 2005-06-28 13:25:47 PDT
Plugin Finder
Comment 14 Benjamin Smedberg [:bsmedberg] 2005-07-08 13:24:14 PDT
Not a blocker, there are more important EM features to deal with first
(dependencies and multi-extension installs).
Comment 15 Jon Granrose 2005-08-19 09:06:02 PDT
not to mention handling global extensions more happily...

with the new schedule and version #, any chance of this getting into 1.5?
Comment 16 Benjamin Smedberg [:bsmedberg] 2005-08-19 09:07:55 PDT
No. We're already in string freeze and a feature like this is too much for 1.5.
Comment 17 Chris Beard 2005-08-19 09:32:02 PDT
My understanding is that hooks for this have already been added as part of the
extension manager work done earlier in this development cycle.  Or am I
mistaken? Was that for software update only?  beng, can you shed some light here?  

/cb
Comment 18 Ben Goodger (use ben at mozilla dot org for email) 2005-08-19 09:50:25 PDT
There is no support for this currently for Extensions, only for Software
Updates. It should be fairly trivial to write code in the extension though that
asks once and then uninstalls if the user declines, or on the distribution page
(see toolbar.google.com) to show a message prior to installation. 
Comment 19 alanjstr 2005-08-19 10:40:10 PDT
> asks once and then uninstalls if the user declines
The question should be  before it installs.  We don't want things to happen
without the user's approval.
Comment 20 Jon Granrose 2005-08-22 14:02:27 PDT
yes, installing software before the user agrees to the EULA makes the EULA more
or less useless.  so the EULA and agreement has to happen before any changes are
made to the profile.
Comment 21 Jon Granrose 2005-12-21 10:59:40 PST
any chance of getting this into the extension mgr redesign for 2.0?

easier distribution drives more commercial development of extensions which drives broader firefox adoption...
Comment 22 Mike Connor [:mconnor] 2006-01-10 08:37:08 PST
Provisionally putting this on the core blocking list, since this is growing increasingly important to extension developers.
Comment 23 Eyal Rozenberg 2006-02-09 02:05:38 PST
To the best of my knowledge, EULAs are not legally binding in the U.S. (maybe even less so in other countries), modulo adoptions of UCITA, and I submit that mozilla should not promote their use. So I suggest this be marked WONTFIX.

See:

http://www.informit.com/guides/printerfriendly.asp?g=security&seqNum=116&rl=1
http://www.gnu.org/philosophy/ucita.html
Comment 24 Jon Granrose 2006-02-09 08:40:25 PST
you might want to talk to your lawyer, and a US judge, before you make sweeping, and incorrect, statements like that.
Comment 25 Jean-Marc Desperrier 2006-02-13 01:50:16 PST
I think the discussion is wrongly headed by focussing about describing this feature as the display of an EULA.

It's just about including in the XPI a text that the author think the user should read and approve before he install the software.
And that's a useful feature for a lot of XPI. 
This is also a feature that would enable to make it much harder to push someone to install an XPI without knowing in advance what this XPI does, and they are some security risks associated with that.

The ideal implementation would be to do the same as what is done today for the signature, that is put that text inside the META-INF directory, require it to be at the start of the XPI compressed file so that it's possible to download and display it ahead of the download of the rest of the XPI. 

We could BTW include the possibility to put a short description that appears in the download dialog, but that the user doesn't have to approve separatly.
Comment 26 Eyal Rozenberg 2006-02-25 05:29:02 PST
(In reply to comment #25)
> I think the discussion is wrongly headed by focussing about describing this
> feature as the display of an EULA.
> 
> It's just about including in the XPI a text that the author think the user
> should read and approve before he install the software.

And what if the user doesn't approve? No, this feature is about EULAs.

(In reply to comment #24)
> you might want to talk to your lawyer, and a US judge, before you make
> sweeping, and incorrect, statements like that.

Ok, it seems you're mostly-corrected: http://www.eff.org//wp/eula.php says EULAs have been upheld several times. Still, they may not be legally binding elsewhere, and regardless of this, Mozilla shouldn't promote their use IMHO. How about providing a "diregard EULA as much as applicable law allows" button, at the very least?
Comment 27 Robert Strong [:rstrong] (use needinfo to contact me) 2006-02-26 19:18:48 PST
I talked with dveditz about how best to accomplish this and I won't be able to do this for the foreseeable future.
Comment 28 Matthias Wallner 2006-04-24 12:54:37 PDT
(In reply to comment #25)
> It's just about including in the XPI a text that the author think the user
> should read and approve before he install the software.

Is Plain Text enough, or do we want to display HTML too? (maybe even with Images included?)

The idea is: some extentions are somewhat hard to find once installed and this page could display a short "HowTo Use me" page.

the EULA guys probably want to apply formating too.

(do we want more than one page (e.g. Info and EULA), or just one?)
Comment 29 Darin Fisher 2006-06-26 12:48:08 PDT
This is something that can be worked around by the extension author.  You can easily construct a first-run dialog.  Look for a preference and if not set, then put up your EULA in a dialog, and then set the preference.  That way, your dialog will only be shown to the user once after post-install.  You could also show the EULA on a website before granting access to the XPI download.

Moreover, without a patch or interest from some developer, it doesn't seem likely that any patch will appear in the FF2 timeframe.  Not blocking for 1.8.1
Comment 30 Jon Granrose 2006-06-26 13:17:51 PDT
see comment 20 - EULA has to be displayed before the extension is installed to be effective.
Comment 31 carglue a t ya hoo do tcom 2006-06-26 14:30:55 PDT
Using a first-run dialog means the target xpi file was already installed, defeating the purpose of a pre-install agreement.  See comments #19 and #20.  Also, showing the information via a website prior to download might be a workable alternative, but it doesn't work for addons.mozilla.org (unless you're given the same exemption that Google has) and listing there is critical for most extensions.  Also, as mentioned in comment #9, decoupling the displayed agreement/information from the .xpi doesn't work if the xpi file can be referenced directly & installed from virtually anywhere.

I've tried displaying a custom (scrolling) dialog via install.js just before installing the xpi, but found that the super-restrictive install environment scope doesn't appear to permit the openDialog command, even when trying to invoke the method from an existing window.  I also read somewhere that addons.mozilla.org no longer accepts extensions with only the install.js script -- and since the presence of an install.rdf file cancels out use of the install.js file, it was yet another dead-end.

One option is to embed the xpi as a file within a separate 'installer' xpi.  Thus, the actual xpi file (the payload) would only be installed if the user accepts/acknowleges the displayed info.  On acceptance, the installer would load the real xpi file directly (by setting the location bar to the URI of the local xpi file in the installer's extension directory) and then would automatically uninstall itself.  The downside to this double-wrapped approach is that FF must be restarted twice, once for the installer then again after the real xpi file is installed.  Such an approach might become commonplace if a generic 'XPI-installer' extension were created for anyone to use by simply adding their own xpi file within it, along with any agreement/information text they wanted to display prior to installation of the payload xpi file.

...but it certainly would be better to implement a new 'preinstallURL' fact in the install.rdf file that would display the specified url page prior to install - similar to right-clicking the "Visit Home Page" option in the Extensions dialog.
Comment 32 Mike Shaver (:shaver -- probably not reading bugmail closely) 2006-06-28 07:14:54 PDT
For display-before-install from AMO, I have filed 342973.

It is categorically untrue that a EULA needs, by its EULA nature, to be agreed to before installation.  In fact, many EULAs bind the _user_ of the software, and not the _installer_ of the software (such that each user of a single computer has to agree to it -- see also preinstallation by OEMs), which might explain why they're not called "EILAs".  That said, _this_ bug is about before-install.  If we need some unified facility for "on first use", that's another bug.

This bug is not the place for anti-EULA activism, nor for pro-EULA activism for that matter.  This is about the facility for an extension to require that a user agree to something before they install (possibly a privacy policy, esp. for EU/safe-harbour jurisdictions).  LiveJournal still has room for more accounts, if you have some angst that you need to express. :)
Comment 33 Phil Ringnalda (:philor) 2006-12-18 20:27:24 PST
*** Bug 364308 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.