Closed
Bug 275743
Opened 20 years ago
Closed 5 months ago
Capability to require agreement to EULA, etc. before user installs
Categories
(Core Graveyard :: Installer: XPInstall Engine, enhancement)
Core Graveyard
Installer: XPInstall Engine
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: duke, Unassigned)
References
Details
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.
Component: Listings → Extension/Theme Manager
Product: Update → Firefox
Target Milestone: 1.0 → ---
Comment 1•20 years ago
|
||
Is this a question about update.mozilla.org?
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•20 years ago
|
||
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.
Status: UNCONFIRMED → NEW
Component: Extension/Theme Manager → Listings
Ever confirmed: true
OS: Windows XP → All
Product: Firefox → Update
Hardware: PC → All
Comment 4•20 years ago
|
||
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.
Assignee: nobody → psychoticwolf
Component: Listings → Administration
I thought this would be a Extension Manager issue, displaying an EULA during the install process.
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.
Summary: we'd like to list extensions for Firefox, but need a way to display EULA before user installs → Display EULA before user installs
Comment 7•20 years ago
|
||
However it happens, we *do* need the ability to display a EULA, if only our own.
Comment 8•20 years ago
|
||
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.
Updated•20 years ago
|
Assignee: psychoticwolf → nobody
Comment 9•20 years ago
|
||
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.
Assignee: nobody → dveditz
Severity: normal → enhancement
Component: Administration → Installer: XPInstall Engine
Product: Update → Core
Target Milestone: --- → mozilla1.8beta
Version: unspecified → Trunk
Comment 10•20 years ago
|
||
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•20 years ago
|
||
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.
Updated•20 years ago
|
Flags: blocking1.8b3?
Updated•20 years ago
|
Flags: blocking1.8b4?
Flags: blocking1.8b3?
Flags: blocking1.8b3-
Comment 12•19 years ago
|
||
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•19 years ago
|
||
Plugin Finder
Updated•19 years ago
|
Assignee: dveditz → rob_strong
QA Contact: mozilla.update → benjamin
Comment 14•19 years ago
|
||
Not a blocker, there are more important EM features to deal with first (dependencies and multi-extension installs).
Flags: blocking1.8b4? → blocking1.8b4-
Comment 15•19 years ago
|
||
not to mention handling global extensions more happily... with the new schedule and version #, any chance of this getting into 1.5?
Comment 16•19 years ago
|
||
No. We're already in string freeze and a feature like this is too much for 1.5.
Comment 17•19 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
> 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•19 years ago
|
||
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.
Updated•19 years ago
|
Flags: blocking-aviary2.0?
Comment 21•19 years ago
|
||
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•19 years ago
|
||
Provisionally putting this on the core blocking list, since this is growing increasingly important to extension developers.
Flags: blocking-firefox2? → blocking1.8.1+
Comment 23•19 years ago
|
||
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•19 years ago
|
||
you might want to talk to your lawyer, and a US judge, before you make sweeping, and incorrect, statements like that.
Comment 25•19 years ago
|
||
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•19 years ago
|
||
(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•19 years ago
|
||
I talked with dveditz about how best to accomplish this and I won't be able to do this for the foreseeable future.
Assignee: robert.bugzilla → xpi-engine
QA Contact: benjamin
Target Milestone: mozilla1.8beta1 → ---
Comment 28•19 years ago
|
||
(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•18 years ago
|
||
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
Flags: blocking1.8.1+ → blocking1.8.1-
Comment 30•18 years ago
|
||
see comment 20 - EULA has to be displayed before the extension is installed to be effective.
Comment 31•18 years ago
|
||
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•18 years ago
|
||
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. :)
Summary: Display EULA before user installs → Capability to require agreement to EULA, etc. before user installs
Comment 33•18 years ago
|
||
*** Bug 364308 has been marked as a duplicate of this bug. ***
Updated•15 years ago
|
Assignee: xpi-engine → nobody
QA Contact: xpi-engine
| Assignee | ||
Updated•9 years ago
|
Product: Core → Core Graveyard
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•