It's very difficult to have users give us about:support (since it involves copy-pasting from a relatively difficult-to-find location in the UI) and hence less than 10% of SUMO threads have this info. On the other hand, the information has been deemed to be very useful in supporting users and helping them as well in being useful in providing new avenues of investigation for top issues during the release process. We should have an API that submits the JSONed about:support information to the webpage after asking the user. (Similar to the way geolocation works). This would also be useful for input.

bug 554174 is the bug to json about:support

As a strawman API, something like navigator.support.getSupportInformation(function(obj) { /* ... */ }); would be perfect. Hopefully it could work exactly like navigator.geolocation.getCurrentPosition, i.e. we could drop a door hanger or whatever the current standard of prompt is, and on success, fire the callback. Denied or never clicked, it's never called. Bonus points for whitelisting https://*.mozilla.org/.

I think we'd certainly need a domain whitelist for this. Even with that, the privacy implications of making this data retrievable from the web is a little worrying.

(In reply to Gavin Sharp (use gavin@gavinsharp.com for email) from comment #3) > I think we'd certainly need a domain whitelist for this. Even with that, the > privacy implications of making this data retrievable from the web is a > little worrying. ^and for that reason I'm ccing geekboy.

Domain whitelists scare me. That aside, the API would be *okay* if it's limited to sites we control and there's an interstitial that shows the user the about:support page and asks if they'd like to submit it. The point is that users should absolutely know what data they're sending to a web page calling this api (even if it's us). It's not as simple as geolocation because it's way more than just two data points. Is it really too hard for users to to click a link ("about:support"), click the copy button, and paste it into a web form? cww suggests it is, but that's only correlation, I don't think it's a cause. I'm skeptical the cause of "lack of this in sumo threads" is that users can't click, copy, paste. Facebook users do this all the time when a web page says "we'll give you farmville points you if you type these keystrokes" -- see bug 527530.

about:support already restricts information shown in the preferences section for privacy reasons, because copy/pasting it somewhere is the intended use case. As long as nothing new gets added to the page that could pose a notable privacy risk I would think things would be fine. (In reply to Sid Stamm [:geekboy] from comment #5) > Is it really too hard for users to to click a link ("about:support"), click > the copy button, and paste it into a web form? Users can't click a link to an about protocol page from http. They have to be told to type it in or get at it from the help menu. More to the point, the actual ease of doing this isn't really the main problem. There are quite a few people that seek tech support that have the mistaken impression that those helping them already know way more about them, their issue, and their system than they do. Basically, some people may already expect that support already has access to this information from the start. Asking someone to go fetch some data might be simple, but it adds another hurdle that slows down and possibly stalls things (way more than it should).

I think if we did this we'd at least want to limit to only some specific Mozilla server, and not allow random webpages to request this. Another thought would be to make this system akin to how the crash reporter works... Click a button in about:support, data submits to mumble.mozilla.org, user gets an ID for the report, access to the report on the server is restricted to those with access. (Including, somehow, the user. Might be nice to allow them to delete reports afterwards too! Win-win!). If the main issue with that is that it's hard for users to get at "about:support", we should look at how we can improve that UX. EG "button in about:support" could be a menu item, or something hooked up to content only for support.mozilla.org.

Similar request for Telemetry data in bug 732522.

(In reply to Sid Stamm [:geekboy] from comment #5) > Domain whitelists scare me. As well they should. > That aside, the API would be *okay* if it's limited to sites we control and > there's an interstitial that shows the user the about:support page and asks > if they'd like to submit it. The point is that users should absolutely know > what data they're sending to a web page calling this api (even if it's us). > It's not as simple as geolocation because it's way more than just two data > points. Honestly, users who don't read EULAs aren't going to read this, are they? UX should comment here, too. (CCing Crystal who can CC someone else.) Because while it make us feel better, if it's meaningless to users, does it really do them any good? Maybe something like, only allowed over HTTPS: This website (https://support.mozilla.org) would like to know more about your copy of Firefox. [More Info] [OK/Always/No/Never] Where the [More Info] button (with better copy) tells you what's going to be submitted. > Is it really too hard for users to to click a link ("about:support"), click > the copy button, and paste it into a web form? cww suggests it is, but > that's only correlation, I don't think it's a cause. I'm skeptical the > cause of "lack of this in sumo threads" is that users can't click, copy, > paste. Facebook users do this all the time when a web page says "we'll give > you farmville points you if you type these keystrokes" -- see bug 527530. As Dave said, you can't click to about:support. Maybe putting a "copy support information to clipboard" under the "help" menu would help, but it's still several active steps the user has to take, and we need to be collecting this data on Input and SUMO at much higher rates to get statistical usefulness. (Cww can back that up.) (In reply to Justin Dolske [:Dolske] from comment #7) > I think if we did this we'd at least want to limit to only some specific > Mozilla server, and not allow random webpages to request this. If we have a way to do that, sure. Telemetry must have that sort of restriction, right? I only care that support.mozilla.org and input.mozilla.org have access. > Another thought would be to make this system akin to how the crash reporter > works... Click a button in about:support, data submits to > mumble.mozilla.org, user gets an ID for the report, access to the report on > the server is restricted to those with access. (Including, somehow, the > user. Might be nice to allow them to delete reports afterwards too! > Win-win!). We still rely on the user ending up with something in their clipboard, possibly overwriting something they had there, and then pasting it into a form. > If the main issue with that is that it's hard for users to get at > "about:support", we should look at how we can improve that UX. EG "button in > about:support" could be a menu item, or something hooked up to content only > for support.mozilla.org. That's one of two main issues. The other main issue is that this information is copied as localized text. Parsing it is nearly impossible. We really need a structured, even if the structure has to change sometimes, JSON or XML (please JSON) blob of data that isn't a series of localized HTML headings and content.

(In reply to James Socol [:jsocol, :james] from comment #9) > (In reply to Justin Dolske [:Dolske] from comment #7) > > I think if we did this we'd at least want to limit to only some specific > > Mozilla server, and not allow random webpages to request this. > > If we have a way to do that, sure. Yes, this is the trivial part. Restricting an API or other method of content/chrome communication is pretty simple. > > Another thought would be to make this system akin to how the crash reporter > > works... Click a button in about:support, data submits to > > mumble.mozilla.org, user gets an ID for the report, access to the report on > > the server is restricted to those with access. (Including, somehow, the > > user. Might be nice to allow them to delete reports afterwards too! > > Win-win!). > > We still rely on the user ending up with something in their clipboard, > possibly overwriting something they had there, and then pasting it into a > form. Wouldn't have to be done in the clipboard, the request could be fed back to the requesting page... EG navigator.support.getSupportDataID(callback), or postMessage fun. I don't see any significant barriers, mostly we just need someone to create a spec, hammer out some details, and then implement it. Help me help you. :) > The other main issue is that this information > is copied as localized text. Parsing it is nearly impossible. We really need > a structured, even if the structure has to change sometimes, JSON or XML > (please JSON) blob of data that isn't a series of localized HTML headings > and content. The code for building the current page it pretty simple/basic... https://mxr.mozilla.org/mozilla-central/source/toolkit/content/aboutSupport.js I would take a refactoring patch that adds splits this into two phases: one to build a JS object / JSON blob with the relevant data, and a second to build the page from a given JSON blob. Have a few spare intern hours? Maybe even [good second bug]...

To add a bit of context on why we would like to make this process easier: https://bugzilla.mozilla.org/show_bug.cgi?id=813472#c1 "Only 13% of users succeed in giving us the troubleshooting information we need, while 22% try and fail. 65% of users never give us any trouble shooting information." Making this process easier will help us improve the quality and ease of our support.

So we know have this implemented as an add-on in the Ask A Question flow of SUMO. Users are given the option to install the add-on to give us their about:support data. The results are quite positive. Before the add-on: 5-10% of users gave us about:support data. After the add-on: 30%+ are giving us about:support data. Building this right into the product would be incredibly awesome, and would probably drive that number even higher. The more useful information we have (such as extensions, modified prefs, etc.) allows us to more accurately gauge the impact of issues, troubleshoot issues more easily, etc.)

Hi all, I showed this to Ally Naaktgeboren (one of our engineering privacy friends) and she asked whether there a way we can put it in the FF menu, where someone can push a button and upload it to a hard coded site? That way, the user is initiating, so that the website isn't the one asking, and the user doesn't have to copy/paste.

(In reply to Stacy Martin [:stacy] from comment #14) > I showed this to Ally Naaktgeboren (one of our engineering privacy friends) > and she asked whether there a way we can put it in the FF menu, where > someone can push a button and upload it to a hard coded site? That way, the > user is initiating, so that the website isn't the one asking, and the user > doesn't have to copy/paste. A disadvantage to this is we can never change the forms. "Uploading" in an isolated fashion is extremely difficult to manage, we'd need some kind of ID submitted with the form to identify the data, anyway, so at some point, something needs to get put in an HTML form and submitted. If the browser is entirely responsible for populating a form field, that form field can never be renamed, modified, refactored, whatever. (At worse, we couldn't even change the DOM around it.) If we have a JS API, we can use a callback to populate a form field, and if that field changes, we just change the callback. It also helps us test because we're not hardcoded to submit to production.

Is there really a meaningful distinction, from a user privacy concern point of view, between "web site caused Firefox to request additional data from the user, user approved the request" and "web site prompted the user to click a menu to submit the data"? The latter is a less streamlined process (worse user experience), and will likely drop submission rates (which may factor in to the privacy concerns, of course).

Can you file a privacy review bug, using our project kickoff form? (https://bugzilla.mozilla.org/form.moz-project-review)

Bug 862203 and dependencies has been filed and is waiting for privacy and other reviews.

One thing that I would like to request as a SUMO developer is that the whitelist for this feature (if that is how it is implemented) be configurable. The add-on we are using for this right now allows configuring the whitelist via an environment variable, which is a little clunky, but it works. If the white list was hard coded and not configurable by advanced users, it would be much harder to develop the tie in feature for the SUMO site, as I would have to spoof the SUMO site for the duration of my development. For the same reason, I request that it be possible to change a setting to cause this data to work over http as well as https, since https development environments aren't common.

> Domain whitelists scare me. > That aside, the API would be *okay* if it's limited to sites we control and there's an interstitial > that shows the user the about:support page and asks if they'd like to submit it. ditto. That user confirmation part is an important piece. The dialog shouldn't be scary, but it should be there.

Reviving this :) Having a good functioning "Firefox Hospital" functionality is much easier / more powerful the easier it is for people to know the system. 1. Most of the information that is in the TroubleShoot module [1] is already in the FHR packet [2]. 2. Having a very short (or 0 length!) retention policy around this data might help alleviate the privacy concerns. 3. Helping and protecting the user has many prongs, because 'the user' is heterogeneous. Part of why Firefox exists as a project is to allow people to achieve their goals on the internet. If they are visiting `about:support`, it is failing to do so in some way. 4. Giving a sumo page chrome privs is scary. There is the same risk with it that there would be if many other Mozilla pages were compromised. 5. By not doing this, we are losing users to browsers that are inconsistent with our values, and allowing our current users to have experiences (malicious addons, search hijacking, home page hijacking) that are against our values, and against the wishes of the users having them. [1]: "resource://gre/modules/Troubleshoot.jsm", used by `about:support` [2]: Modified prefs are not.

Privacy and Legal review are passed.

We're going to do this in bug 1079563.