Closed Bug 870534 Opened 11 years ago Closed 11 years ago

Please add a "disable snippets" feature to about:config

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: hoosteeno, Unassigned)

Details

The snippets area of about:home is a tiny block of content underneath the search bar. It is one of the most powerful tools we have for communicating with the Firefox user community, and we continue to enhance the capabilities of snippets (for example, we recently added snippet geolocation in bug 836532, and other enhancements are regularly requested). 

It's only natural that some users would rather not see these messages. For them, can we add a parameter to about:config that will completely disable the request for snippets? The URL for snippets is already a part of the config (browser.aboutHomeSnippets.updateUrl).
This would be trivial for an addon (or Stylish) to hide. Generally we don't add options/preferences unless there's a compelling need.
Thanks -- we hadn't thought about going the add-on route. I think it would definitely satisfy the technical requirements of this request. 

Before WONTFIXing, I just want to make sure we consider another aspect of this request: the principle of it.

Right now, when people download Firefox and open it up, their browser makes a request to the snippet service, and then makes a request to a geolocation service, and then displays certain promotional messages. Those messages currently come from Mozilla only; depending on various other conversations[1], they may also include well-reviewed and relevant messages from select partners someday.

This has all been discussed and considered from every possible angle by people throughout the project, and it has passed rigorous review, and it is explained in our privacy policy. I don't mean to question whether we should have snippets; I think we should. But, since we are embedding a marketing channel in our product, oughtn't we to embed an opt-out? I think we ought to, not because it is technically required, but because it serves a principle.

Of course if I'm the lone voice on this, I'll explore the add-on route. Thanks!

[1] https://wiki.mozilla.org/Mobile/Projects/Dynamic_Snippets
(In reply to Justin Dolske [:Dolske] from comment #1)
> This would be trivial for an addon (or Stylish) to hide. Generally we don't
> add options/preferences unless there's a compelling need.

Why was the socialAPI build with a social.enabled in about:config, but there was nothing like browser.aboutHomeSnippets.enabled for controlling the rendering of about:home snippets? I understand that it is not trivial. What is the process to get such a feature added to Firefox to give users control over if they want their Snippets to be part of their Firefox experience?
(In reply to Justin Crawford [:hoosteeno] from comment #2)

> [...] Those messages
> currently come from Mozilla only; depending on various other
> conversations[1], they may also include well-reviewed and relevant messages
> from select partners someday.
> 
> This has all been discussed and considered from every possible angle by
> people throughout the project, and it has passed rigorous review

First I've heard of it. In any case, if/when that's deployed and there's a need for it, that changes things and can be reconsidered.

(In reply to Chris More [:cmore] from comment #3)

> Why was the socialAPI build with a social.enabled in about:config

Because when new features land they're intended to have an easy way to be disabled, lest a problem be found at the last minute and they're not ready for widespread use.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
> 
> First I've heard of it. In any case, if/when that's deployed and there's a
> need for it, that changes things and can be reconsidered.
> 

This geo located snippet technology has already deployed and partner snippets will be going out post-Firefox OS launch. For your reading pleasure about the new service: https://groups.google.com/forum/?fromgroups=#!topic/mozilla.governance/A4eNbXdW1uk

> 
> > Why was the socialAPI build with a social.enabled in about:config
> 
> Because when new features land they're intended to have an easy way to be
> disabled, lest a problem be found at the last minute and they're not ready
> for widespread use.

With that logic, this is actually a valid bug because the about:home snippet service was landed in Firefox 4, i.e. a new feature, and it didn't not include an easy way for it to be disabled.

> Generally we don't add options/preferences unless there's a compelling need.

Can you explain what a compelling reason is? We just launched the ability to geo locate snippets based on IP address. We were told by legal/privacy that the only way that they support moving forward with launching geo located snippets is if we soon work with Firefox engineering on getting an "easy way to be disabled" method within about:home snippets. Now that snippets are geo located on top of the normal language targeted, we should be giving the users the ability to opt-out of that experience. Telling users they have to download an add-on to disable a in-product feature seem to not be true to our principles.

Should we have legal/privacy chime in on what technical method is accessible to them? i.e. changing Firefox home page, create add-on, about:config flag, etc.
(In reply to Chris More [:cmore] from comment #5)

> > > Why was the socialAPI build with a social.enabled in about:config
> > 
> > Because when new features land they're intended to have an easy way to be
> > disabled, lest a problem be found at the last minute and they're not ready
> > for widespread use.
> 
> With that logic, this is actually a valid bug because the about:home snippet
> service was landed in Firefox 4, i.e. a new feature, and it didn't not
> include an easy way for it to be disabled.

That's not how that works - putting features behind disable flags is one manifestation of the engineer's responsibility to the tree; it's an internal quality measure to ensure they don't break things for other engineers. Many of those flags are later removed once the feature has shipped, since they add extra code to maintain and test. In some cases a flag isn't even the guard used, engineers opting instead to just be on the hook for backouts if something goes wrong. But this isn't a policy tool to argue for post hoc pref guarding - as dolske says, that comes only from a user need which justifies the technical cost.


> > Generally we don't add options/preferences unless there's a compelling need.
> 
> Can you explain what a compelling reason is? We just launched the ability to
> geo locate snippets based on IP address. We were told by legal/privacy that
> the only way that they support moving forward with launching geo located
> snippets is if we soon work with Firefox engineering on getting an "easy way
> to be disabled" method within about:home snippets. 

I'll be honest, I don't feel very good about the fact that Legal/Privacy gave you approval conditional on changing code in Firefox, and you pushed to deployment without getting those changes sorted out ahead of time.

Having said that, I confidently assert without data that we are the only people on the planet who think of the about:home page and the snippet within it as separate things. I am happy that we provide the clean, relevant, and engaging default home page that we do, but if a user doesn't like it (because of the once-a-day snippets update, or the geolocating, or the choice of colour scheme), we have a user-visible pref on the first page of preferences to change their home page to something else.

The edge case of "likes our home page, but not our snippet service" isn't one I'd personally choose to support, but for what it's worth I bet that blanking out the existing aboutHomeSnippets.updateURL pref would do the job; as would hoosteeno's addon (thanks for that!) 

Would you agree? (Cc'ng Jishnu and Asa, since there was a side thread in email that I redirected here)
Hey Johnathan.

Are you comfortable with the add-on route and/or just having users change their homepage preference to something other than about:home? I like hoosteeno's add-on. I'm fine with whatever we all agree too and the direction we got from legal was to provide an opt-out mechanism in Firefox. Legal's preference was a Firefox preference, but a flag in about:config was suffice. We can let Jishnu talk more about that.

We had no time to sort this all out a head of time because of agreements with Firefox OS partners that stated we had the ability to tell users the phone was available in specific countries via about:home. Previously, we only had the ability to talk to users based on language and build of Firefox. We were given an 2013/04/02 deadline to have the service built and available for production use. It has been used successfully for the past few months.

More about the geo service:

https://wiki.mozilla.org/Websites/Snippets/Geolocated-Snippets

Obviously, the timeline to get the geo snippets out the door was not ideal.
I coded the page originally, there is no pref to disable snippets, cause there is a giant pref to not use about:home as homepage, as Johnathan said.  That was the pref we could have used to disable the feature too.
(In reply to Marco Bonardo [:mak] from comment #9)
> I coded the page originally, there is no pref to disable snippets, cause
> there is a giant pref to not use about:home as homepage, as Johnathan said. 
> That was the pref we could have used to disable the feature too.

Works for me! Let's see if Jishnu agrees.
Sorry for the delay:

TL;DR:

(In reply to Chris More [:cmore] from comment #10)

> Works for me! Let's see if Jishnu agrees.

I agree - the about:home pref continues to work. We'll work to surface it in SUMO/privacy notice.


(In reply to Johnathan Nightingale [:johnath] from comment #7)
> (In reply to Chris More [:cmore] from comment #5)

> I'll be honest, I don't feel very good about the fact that Legal/Privacy
> gave you approval conditional on changing code in Firefox, and you pushed to
> deployment without getting those changes sorted out ahead of time.

I want this to be better - we can change the way we approach approvals like this for Firefox from now on. We gave Justin and Chris the green light to push but asked that they attempt this fix this shortly after, knowing about the about:home pref as an acceptable, but less than optimal route. I didn't know about the utility of preffing code and what it meant - thanks to you and dolske - I get it now. In the future - should we change the way this went down and how?

> Having said that, I confidently assert without data that we are the only
> people on the planet who think of the about:home page and the snippet within
> it as separate things. I am happy that we provide the clean, relevant, and
> engaging default home page that we do, but if a user doesn't like it
> (because of the once-a-day snippets update, or the geolocating, or the
> choice of colour scheme), we have a user-visible pref on the first page of
> preferences to change their home page to something else.
> 
> The edge case of "likes our home page, but not our snippet service" isn't
> one I'd personally choose to support, but for what it's worth I bet that
> blanking out the existing aboutHomeSnippets.updateURL pref would do the job;
> as would hoosteeno's addon (thanks for that!) 
> 
> Would you agree? (Cc'ng Jishnu and Asa, since there was a side thread in
> email that I redirected here)

This is all good - I didn't know about the user visible preference. Also, I think we could conceptualize about:home as one feature - the snippets service being a part of that. On the next rev - we can update the privacy policy to indicate this.  I think Justin Crawford helped write a SUMO page describing how to disable about:home also.
> I think Justin Crawford helped write a SUMO page
> describing how to disable about:home also.

For the record: I didn't write such documentation. It probably exists in numerous places already. Here are a couple good examples:

https://support.mozilla.org/en-US/kb/startup-home-page-download-settings

https://support.mozilla.org/en-US/kb/How%20to%20set%20the%20home%20page?esab=a&s=default+home+page&r=2&as=s
So, is this resolved? Are we fine with the SUMO article on how to change the start page and the addon being available? If so, I'm good too with keeping this WONTFIX.
You need to log in before you can comment on or make changes to this bug.