Closed Bug 834385 Opened 12 years ago Closed 7 years ago

about:newaddon should support messages from the vendor, read from install.rdf

Categories

(Toolkit :: Add-ons Manager, defect)

Product:
Toolkit
Component:
Add-ons Manager
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: WeirdAl, Unassigned)

References

Details

(Whiteboard: [squeaky])

Attachments

(6 files, 5 obsolete files)

Option 1 mock
128.05 KB, image/png
limi
: feedback-
Details
Option 2 mock
148.98 KB, image/png
jorgev
: feedback+
Details
patch, v1
19.32 KB, patch
jorgev
: review+
Unfocused
: review-
Details | Diff | Splinter Review
test extension with lorem ipsum and vendor icon
1.02 KB, application/x-xpinstall
Details
Proposed new design
288.91 KB, image/png
limi
: ui-review-
Details
131009 wireframes r1.png
85.65 KB, image/png
Details
The about:newaddon page simply asks users to confirm an addon install, but provides no built-in way for the vendor to say why the addon is there. I propose about:newaddon itself looked for an entry in install.rdf, a vendor message explaining why the XPI install was requested, and presented that to the user. Either a URL to a content iframe (sandboxed) or a brief text message. I will gladly write up a patch for this.
I'm not certain whether install.rdf is the place to store this message, but I would be in favor of supporting some sort of vendor-defined message in about:newaddon. I think the fact that it does not currently indicate the source of the install is confusing to users (especially since it's not guaranteed to show within any particularly short timeframe after the install for users who don't restart often), and such a feature might go a long way to improving user experience and preventing vendors from attempting to bypass the opt-in screen.
Whiteboard: [squeaky]
Attached file test extension (obsolete) —
This test extension has as its vendorMessageURL a data: URL with a bright green background and a little bit of text: data:text/html;charset=utf-8,<!DOCTYPE HTML PUBLIC "-%2F%2FW3C%2F%2FDTD HTML 4.0%2F%2FEN">%0D%0A<html lang%3D"en">%0D%0A <head>%0D%0A <title>Test<%2Ftitle>%0D%0A <%2Fhead>%0D%0A <body style%3D"background-color%3A %2300ff00%3B">%0D%0A <p style%3D"font-style%3A italic%3B">Hello World!<%2Fp>%0D%0A <p>This is a test extension.<%2Fp>%0D%0A <%2Fbody>%0D%0A<%2Fhtml>%0D%0A
Attached image screenshot on Windows (obsolete) —
Attached patch patch as proof of concept (obsolete) — — Splinter Review
Attachment #709428 - Attachment is patch: true
Comment on attachment 709428 [details] [diff] [review] patch as proof of concept I'd like some initial feedback on this, please - not a code review, just a checkpoint.
Attachment #709428 - Flags: feedback?(bmcbride)
I think using iframe is overkill. Loading random stuff from the network and letting that page to run scripts etc. Shouldn't just text and perhaps an icon be enough. (not sure I can think of good use cases for the icon.) Also, no loading from the network, if possible. Couldn't the .xpi contain the text in some file. And, letting the vendor to style the message would be just confusing to the user - inconsistency in UIs is rarely a good thing. (but I'm not an ui-designer ;) )
I agree. This is more extensibility than I was imagining. A plain-text string and possibly the icon64.png image should be sufficient. I don't expect that most of the implementations will be quite as offensive to the eyes as he test case (which, not being a designer, I can sympathize with), but I still don't think this is quite what we should be aiming or.
Attachment #709428 - Flags: feedback?(bmcbride)
Attached image Option 1 mock —
Attachment #709425 - Attachment is obsolete: true
Attachment #709426 - Attachment is obsolete: true
Attachment #709428 - Attachment is obsolete: true
Attached image Option 2 mock —
Here are two mockups our UI team at APN came up with. What do you think, Jorge et al?
Attachment #722433 - Flags: feedback?(jorge)
I like option 1, with the understanding that the type of markup that the message can contain is severely restricted. I don't think your use of bold is out of line, but allowing anything other than <strong> or <em> tags seems excessive.
(In reply to Kris Maglione [:kmag] from comment #11) > I like option 1, with the understanding that the type of markup that the > message can contain is severely restricted. I don't think your use of bold > is out of line, but allowing anything other than <strong> or <em> tags seems > excessive. I agree with Kris. I would also move the first line ("Message from the add-on provider") up, so that it aligns with "Install add-ons only from..." and then have the icon and message next to each other.
(In reply to Kris Maglione [:kmag] from comment #11) > I like option 1, with the understanding that the type of markup that the > message can contain is severely restricted. I don't think your use of bold > is out of line, but allowing anything other than <strong> or <em> tags seems > excessive. OK. I'd considered reusing this XSLT stylesheet, but it allows quite a bit more than that: http://mxr.mozilla.org/mozilla-release/source/toolkit/mozapps/extensions/content/updateinfo.xsl I'll write a separate XSL transform for this case.
Status: NEW → ASSIGNED
Comment on attachment 722431 [details] Option 1 mock This needs UX review.
Attachment #722431 - Flags: feedback?(ux-review)
Attachment #722433 - Flags: feedback?(jorge) → feedback+
Comment on attachment 722431 [details] Option 1 mock The feedback I have received to this entire thing is very negative. Why do we feel we need to do this?
Attachment #722431 - Flags: feedback?(ux-review) → feedback-
I don't understand why we would do this. What's the rationale? Having separate icons and messages from the add-on is just going to increase the potential for user confusion, and spammy/malicious add-ons are going to use this to further obfuscate their purpose.
The point of this change is to find some middle ground between the current UI and what add-on distributors would like to see in the installation process. It will help mitigate the amount of cases in the wild where developers overlay or completely bypass the opt-in screen because it's scary-looking and impersonal. Minimizing confusion is important, of course, which is why we're asking for UX review. Spammy / malicious add-ons can easily bypass this screen, so that's not really important in this discussion.
Spammy/malicious add-ons have no trouble obfuscating their intent as-is. Most of them just bypass the screen entirely until we blocklist them. Some, like the Ask Toolbar, use an external application to overlay it. In the case of legitimate add-ons, there should be some viable way for the publishers to explain the purpose and the origin. Granted, I'm not sure how legitimate even most "legitimate" system-installed add-ons are, but add-ons like Adobe's PDF toolbar, and Kaspersky's myriad extensions at least have uses related to the software they come with and should have an opportunity to explain their purpose so users at least have an idea of what they're being asked to install and whether they want it. In the case of the spammy ones, I'd rather they have this than resort to more extreme measures.
Attached file test extension with lorem ipsum (obsolete) —
Attached file work in progress (obsolete) —
* This implements the text part of the messaging. * Localization is not yet supported. * In testing this, I notice the text is unbounded; an add-on could at least try to write a lot of text and push things like the accept button off screen. I'll have to stick the text in a box with vertical scrollbars and a max height to prevent that.
(In reply to Jorge Villalobos [:jorgev] from comment #17) > The point of this change is to find some middle ground between the current > UI and what add-on distributors would like to see in the installation > process. I'm still not convinced this is needed or useful. The newaddons page is in response to lots of users being frustrated with software dropping in unwanted addons. I know add-on distributors don't like that, but that's hardly surprising. We can always adjust the existing page's wording and style if we find it's actually too scary. Is there any evidence that the current page is actually causing complaints from _users_? That's who we should be concerned about.
(In reply to Justin Dolske [:Dolske] from comment #21) > (In reply to Jorge Villalobos [:jorgev] from comment #17) > > The point of this change is to find some middle ground between the current > > UI and what add-on distributors would like to see in the installation > > process. > > I'm still not convinced this is needed or useful. The newaddons page is in > response to lots of users being frustrated with software dropping in > unwanted addons. I know add-on distributors don't like that, but that's > hardly surprising. We should be doing what we can to allow users to make an informed decision about the add-ons they install. The current static page can't give the user the information they need to make that choice
Attached patch patch, v1 — — Splinter Review
This is the best I could do. I couldn't quite get the image to render without stretching to the left of the vendor message, even with this tech note: http://starkravingfinkle.org/blog/2008/06/xul-tip-wrapping-boxes/
Attachment #723130 - Attachment is obsolete: true
Attachment #723131 - Attachment is obsolete: true
Attachment #724174 - Flags: review?(jorge)
(In reply to Justin Dolske [:Dolske] from comment #21) > We can always adjust the existing page's wording and style if we find it's > actually too scary. Is there any evidence that the current page is actually > causing complaints from _users_? That's who we should be concerned about. Users don't really provide direct feedback about these kinds of things (see e.g. how we base changes to our installer/download process on conversion metrics, rather than direct user feedback). Add-on distributors wanting to increase their conversion rate is clearly the motivation here. The point of contention is the subjective evaluation of to what degree auto-bundled Firefox add-ons are likely to be "wanted" by users. We obviously know there are many that are unwanted, but I don't think we can reasonably claim that that's true across the board. Finding the right balance is tricky.
Hey guys. I'd like to echo what Mossop and Dolske said about making sure our users can make an informed decision about what they install. I'd also like to pose one question. Are we making it easier for these add-on distributors to convince users to install something they may not need through clever marketing lingo? Users may either A) Be falsely under the impression that the message comes from us or B) The add-on distributor may make false claims such as "Your computer is in extreme peril unless you install this" etc. Do we have a mitigation plan for B?
I think the text in the first mockup makes it clear that the message is not coming from Mozilla. It's true that this can be used to mislead users, but again there are already plenty of ways for bad actors to do that, or bypass the opt-in entirely. Unless we intend to remove the possibility of these kinds of third party installs altogether (I'm not wholly averse to the idea, but I don't think it's practicable), we really need some way for the add-ons in question to explain where they come from and what they do. There might be other changes we can modify the page to improve the experience, such as framing the text in terms of "Software on your system includes a Firefox add-on. Would you like to install it?" rather than "Another program is trying to modify Firefox", but I don't think that solves the problem of giving users enough specific information about the add-on to make an informed decision.
Comment on attachment 724174 [details] [diff] [review] patch, v1 Review of attachment 724174 [details] [diff] [review]: ----------------------------------------------------------------- This looks okay to me upon some cursory inspection. However, this needs to be reviewed by someone more familiar with the Add-ons Manager code. Also, we need a UX review for the way it looks. I think that the message needs to be styled in a way that it clear that it isn't part of the opt-in UI, without giving it too much prominence.
Attachment #724174 - Flags: review?(jorge)
Attachment #724174 - Flags: review?(bmcbride)
Attachment #724174 - Flags: review+
Attached image Proposed new design —
I think we should go ahead with this. We know that the existing UI currently isn't good enough - part of that is because we currently don't (and can't) provide enough useful information regarding where an add-on came from and why someone may or may not find it useful. That said, this kind of feature does open up the possibility for abuse - so it needs to be designed cautiously. With that in mind, here's a proposed design tweak that makes it makes it clearer that the text is supplied by a 3rd party. The first half is the default view, which just adds a "Why am I being asked to install this add-on" link - clicking that would expand the section to show the message from the vendor (as seen in the second half). Additionally, it moves the existing install warning so it remains grouped with the "allow installation" checkbox. I'm still not entirely happy with the "Message from the add-on provider" text. It feels clumsy. And it may be better to have it in the inset box, just to reduce visual noise. Limi - thoughts?
Attachment #729418 - Flags: ui-review?(limi)
Comment on attachment 724174 [details] [diff] [review] patch, v1 Review of attachment 724174 [details] [diff] [review]: ----------------------------------------------------------------- Code seems reasonable, mostly just r- because we need to sort out the design. And, of course, we'll eventually need a test for the backend and frontend changes (see comment 29). Design first though.
Attachment #724174 - Flags: review?(bmcbride) → review-
Blair, do you want to take this bug? I can turn patches around quickly, but I'll be on vacation next week. We've no idea when the UI team might respond.
(In reply to Alex Vincent [:WeirdAl] from comment #31) > Blair, do you want to take this bug? I can turn patches around quickly, but > I'll be on vacation next week. We've no idea when the UI team might respond. I'm kinda swamped at the moment, so don't know if I'd be able to get to it next week anyway (beyond reviews/coordinating). I'll jump in if I get time.
Comment on attachment 729418 [details] Proposed new design (In reply to Kris Maglione [:kmag] from comment #18) > Spammy/malicious add-ons have no trouble obfuscating their intent as-is. > Most of them just bypass the screen entirely until we blocklist them. Some, > like the Ask Toolbar, use an external application to overlay it. Yes. And they should both be blacklisted. Circumventing our systems for keeping add-ons from inadvertently being added through bundling is never OK. > In the case of legitimate add-ons, there should be some viable way for the > publishers to explain the purpose and the origin. If the user wants the add-on, they will know. If they installed it with the intent of using it and adding it to Firefox, they will jump through the hoops necessary to get it. Motivation is not a problem if they actually want the functionality. > Granted, I'm not sure how > legitimate even most "legitimate" system-installed add-ons are, but add-ons > like Adobe's PDF toolbar, and Kaspersky's myriad extensions at least have > uses related to the software they come with and should have an opportunity > to explain their purpose so users at least have an idea of what they're > being asked to install and whether they want it. If the user sees an extension with "Adobe" or "Kapersky" in the title, and actually trust those names, they won't have a problem here. If they installed Java, and now Firefox is asking whether they want the Ask.com toolbar, that's not OK. > In the case of the spammy ones, I'd rather they have this than resort to > more extreme measures. If they work against our system and guidelines, we should blacklist. No exceptions. This entire approach doesn't make any sense, and we shouldn't do it. If we want to make it a bit more obvious what is happening, the best way is to: Not use a checkbox for installation, but instead have two buttons: [Install] [Continue without installing] Continue without installing should be the default action.
Attachment #729418 - Flags: ui-review?(limi) → ui-review-
(In reply to Alex Limi (:limi) — Firefox UX Team from comment #33) > (In reply to Kris Maglione [:kmag] from comment #18) > > Spammy/malicious add-ons have no trouble obfuscating their intent as-is. > > Most of them just bypass the screen entirely until we blocklist them. Some, > > like the Ask Toolbar, use an external application to overlay it. > > Yes. And they should both be blacklisted. Circumventing our systems for > keeping add-ons from inadvertently being added through bundling is never OK. We do block add-ons that bypass our opt-in screen. However, we want to reduce the incentive to do so by making the opt-in screen a little friendlier. > > In the case of legitimate add-ons, there should be some viable way for the > > publishers to explain the purpose and the origin. > > If the user wants the add-on, they will know. If they installed it with the > intent of using it and adding it to Firefox, they will jump through the > hoops necessary to get it. Motivation is not a problem if they actually want > the functionality. But in this case the user is not necessarily installing just an add-on. In most cases he's installing X software, which includes an add-on, so I think it makes sens to clarify to the user that the add-on installation is connected to this software, especially considering that Firefox may be opened days after the installation, showing the opt-in screen out of context. > > Granted, I'm not sure how > > legitimate even most "legitimate" system-installed add-ons are, but add-ons > > like Adobe's PDF toolbar, and Kaspersky's myriad extensions at least have > > uses related to the software they come with and should have an opportunity > > to explain their purpose so users at least have an idea of what they're > > being asked to install and whether they want it. > > If the user sees an extension with "Adobe" or "Kapersky" in the title, and > actually trust those names, they won't have a problem here. If they > installed Java, and now Firefox is asking whether they want the Ask.com > toolbar, that's not OK. That's up to the user to decide. We're trying to make that decision easier for them. > > In the case of the spammy ones, I'd rather they have this than resort to > > more extreme measures. > > If they work against our system and guidelines, we should blacklist. No > exceptions. Blocklisting has its own UX problems, and users have rejected large scale blocks of add-ons they actually wanted to have. We can't take these decisions lightly, and our experience shows that it is much more fruitful to work with developers than to outright fight them. > This entire approach doesn't make any sense, and we shouldn't do it. I think Asa owns this decision, so I'll leave this call to him. > If we want to make it a bit more obvious what is happening, the best way is > to: > > Not use a checkbox for installation, but instead have two buttons: > > [Install] [Continue without installing] > > Continue without installing should be the default action. This is a good suggestion, but it doesn't address the main concern in this bug, which is that the opt-in screen is not informative enough.
Flags: needinfo?(asa)
(In reply to Alex Limi (:limi) — Firefox UX Team from comment #33) > If the user wants the add-on, they will know. If they installed it with the > intent of using it and adding it to Firefox, they will jump through the > hoops necessary to get it. Motivation is not a problem if they actually want > the functionality. That is demonstrably false. In the same way that we try to streamline our download/installation process to "widen the funnel", authors of legitimate, useful add-ons want to reduce the likelihood that the user-desired installations will fail because of confusion/unnecessary roadblocks. So it's not reasonable to claim that us putting up infinite hoops is acceptable solely because "users who want it can still get it". In practice, we know that that _will_ mean that users who want it don't get it, and legitimate add-ons suffer from not having a good way to easily get users what they want. It's reasonable to claim that that problem is relatively minor compared to the problem of users being unintentionally junked by bad add-ons, and that given no magical solution that will avoid both, we should err on the side of avoiding the larger problem - I am inclined to agree. But your argument would carry more weight if you acknowledge the trade-off. We are in the position of trying to police an add-on eco-system. The "bad add-ons we should blocklist"/"good add-ons who can live with any number of hoops" dichotomy is far too simplistic to be a useful model for reasoning about the state of the add-ons world, so I wish people would stop relying on it.
Blocks: 769495
Flags: needinfo?(dtownsend+bugmail)
Mossop: mfinkle recommended we reach out to you to find a UX person who can assist us in moving this forward.
Larissa, Madhava said you'd be able to help us out here
Flags: needinfo?(dtownsend+bugmail) → needinfo?(lco)
Yes, let's give the search hijackers with their evil install tactics one more shot at our users. They have a god-given right to Firefox users and Mozilla revenues and who are we to deny them that. It's not like we're here to protect our users from their dark patterns or to help ensure Mozilla sustainability.
Flags: needinfo?(asa)
(In reply to Asa Dotzler [:asa] from comment #38) > Yes, let's give the search hijackers with their evil install tactics one > more shot at our users. They have a god-given right to Firefox users and > Mozilla revenues and who are we to deny them that. It's not like we're here > to protect our users from their dark patterns or to help ensure Mozilla > sustainability. http://darkpatterns.org/what_is_a_dark_pattern/
(In reply to Asa Dotzler [:asa] from comment #38) https://bugzilla.mozilla.org/page.cgi?id=etiquette.html Seriously, this isn't the place for it. If you want to discuss it further, take it to newsgroups/blogs/whatever - but keep it civil here and restricted to constructive comments. We need UX on this, and we need a plan for this bug that fits with the long-term plan[1]. I won't be accepting any patch without that - same as any other bug. But comments like that aren't helping. [1] A big part of that long-term plan is the Add-on File Registration System, which we're working on a detailed spec for right now - thus the holdup from my end.
(In reply to Blair McBride [:Unfocused] from comment #40) > We need UX on this, and we need a plan for this bug that fits with the long-term plan We don't *need* UX for this. We *need* (if one assumes *we* all share the same mission[1]) to stop pandering to an industry of hostile actors abusing Firefox users and diverting Mozilla's precious lifeblood. We *need*, if we are to live up to our commitments to our users (yes, they come first, well ahead of search hijackers and other malware vendors) to WONTFIX this bug. [1] http://www.mozilla.org/en-US/about/manifesto/#principles
(In reply to Asa Dotzler [:asa] from comment #41) > (In reply to Blair McBride [:Unfocused] from comment #40) > > > We need UX on this, and we need a plan for this bug that fits with the long-term plan > > We don't *need* UX for this. We *need* (if one assumes *we* all share the > same mission[1]) to stop pandering to an industry of hostile actors abusing > Firefox users and diverting Mozilla's precious lifeblood. We *need*, if we > are to live up to our commitments to our users (yes, they come first, well > ahead of search hijackers and other malware vendors) to WONTFIX this bug. > > [1] http://www.mozilla.org/en-US/about/manifesto/#principles Asa, this is not the place to be fighting hostile actors. This is about item 5 from the principals you point to. Users should have access information about what add-ons they are considering installing otherwise they can't make an informed choice. Item 9 is also applicable here, commercial involvement in Firefox is good if properly balanced. If developers are abusing the ability to add messaging to this page then the way to deal with it is through things like the blocklist and the file registration API. WONTFIXing this just means that users will have less information to work with to make a decision about whether to install an add-on.
I agree that the central issue here is how we can provide users with the information they need to make a decision to install the add-on or not. I think it would be more productive if we discussed what a diligent user needs in order to make a more informed choice, since there will always be users who will go ahead and install the add-on without thinking. In my opinion it's the following: 1. Who is the publisher / author of the add-on? 2. What does the add-on do? 3. Why is the add-on trying to install itself on my browser? I think the current UI only addresses question #1. I think the proposed message from the add-on provider would be one way to answer question #2, but I'd welcome other ideas. (At the risk of adding more dimensions to this conversation, I actually think we address question #3 poorly; though we say that some other program on the user's computer would like to install the add-on, we don't really say which program it is. I think it makes a huge difference to the user whether the software they just installed would like to add a companion add-on to the browser, or if a free game they downloaded is trying to install a search-hijacking toolbar.) I'll attach a mock of what I've been thinking of in my next comment. P.S.: The implicit assumption in this bug is that we think it's valuable to provide users with the choice to install the add-on or not. If we don't agree that this is important, there are other options: For example, we could say that our policy is not to allow other software to install add-ons, and treat all of these side-installs as "malicious". We could take the opposite extreme and say that add-ons are automatically installed without any user permission. If we want to discuss this, then the mailing list might be the best place to do so.
Flags: needinfo?(lco)
I think Blair's mocks aren't too far from what I'd propose. The important changes I made are: 1. A clearer indication of which information is coming from the add-on publisher rather than from Mozilla 2. Streamlining of the text organization so that it doesn't seem overwhelming and complex 3. Giving the user explicit button choices for what they can do, rather than a checkbox + button combo (which adds cognitive load since it's the user has to parse what checking the box and pressing the button means) 4. Condensing information beyond the add-on title and author into a "more information" box 5. Removing the "you can always change your mind..." text from the dialog (This may be a controversial choice, and I'm open to discussion. I just thought it was ambiguous because the message is relevant only when you choose to install an add-on) As I mentioned in my previous comment, I also added the name of the software trying to install the add-on because I think it makes things clearer to the user.
(In reply to Larissa Co [:lco] from comment #43) > P.S.: > The implicit assumption in this bug is that we think it's valuable to > provide users with the choice to install the add-on or not. If we don't > agree that this is important, there are other options: For example, we could > say that our policy is not to allow other software to install add-ons, and > treat all of these side-installs as "malicious". We could take the opposite > extreme and say that add-ons are automatically installed without any user > permission. If we want to discuss this, then the mailing list might be the > best place to do so. Just FYI, this has been discussed to great lengths: https://groups.google.com/forum/#!topic/mozilla.addons.user-experience/48q3mGXpdJg. There's no unanimous agreement on whether this choice is valuable or not, but the position of most participants is that it is and we should improve it rather than remove it entirely.
Assignee: ajvincent → nobody
Status: ASSIGNED → NEW
about:newaddons is no more, and much of the discussion here is now irrelevant. If somebody wants to propose something analogous for the new sideloading flow, lets start over with a new bug.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: