Disabled cookie micro-management feature causes various problems

[Hugues de Lassus Saint-Geniès]

Dear Firefox developers,

Since the patch for bug #606655 "Remove "Ask me everytime" cookies
option" was merged into Firefox 44 release, many comments have been made
on Bugzilla about the problems caused by the loss of such a functionality.

I will try to summarize a bit some of what has been said on the tracker:

The option was somewhat bogus (see bug #365772) and it had a pretty bad
UI, plus it was apparently unmaintained.

Those inconveniences were outweighed by the fine-grained cookie control
it gave the users.

The functionality was useful for many, plus it was instructive as it
would show which cookies were set by which domain.

It was one of the few differentiating factors between Firefox and other
browsers. Someone even said that many everyday users - not powerusers -
liked the feature and switched to Firefox thanks to it.

Modifying an already-set exception was quite easy for browsed domains as
it would just involve a click on the address bar icon and a click in a
drop down list.
Now the bare options are very limited, and the default setting for those
who were using the "Ask every time" option has become "Accept" instead
of "Reject", which would have been the safest option for privacy matters.
Many websites are broken when one selects the "Reject" option, and the
UI for allowing/blocking domains from modifying cookies has become worse
than before since it now involves many clicks, keyboard inputs and
navigation across menus instead of single clicks on popup windows before
browsing a new website.
Some even experienced the loss of their Exception list, that allows,
allows for session, or blocks cookies from user-specified domains.

Extensions such as Privacy Badger or Cookie Controller are presented as
an alternative, but they either make use of public white-lists or have a
rather old UI.

Firefox communicates a lot on protecting its users privacy, but this
update seems to head in the opposite direction, giving less control to
its users.

--
Hugues
_______________________________________________
firefox-dev mailing list
firef...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev

[Boris Zbarsky]

On 2/4/16 12:54 PM, Hugues de Lassus Saint-Geniès wrote:
> The option was somewhat bogus (see bug #365772) and it had a pretty bad
> UI, plus it was apparently unmaintained.

Plus it violated Gecko invariants and thus led to lots of crashes, yes?

-Boris

[Gijs Kruitbosch]

On 04/02/2016 17:54, Hugues de Lassus Saint-Geniès wrote:
> Dear Firefox developers,
>
> Since the patch for bug #606655 "Remove "Ask me everytime" cookies
> option" was merged into Firefox 44 release, many comments have been made
> on Bugzilla about the problems caused by the loss of such a functionality.
>
> I will try to summarize a bit some of what has been said on the tracker:
>
> The option was somewhat bogus (see bug #365772)

That bug indicates it broke sessionStorage completely. In ways that
broke websites and that you couldn't recover from per-website without
turning off the functionality entirely.

> and it had a pretty bad
> UI, plus it was apparently unmaintained.

It also had stability problems (ie, it caused Firefox crashes), wasn't
really an effective way of giving people control over their experience,
and would have been even more problematic once we enabled multi-process
Firefox.

> Those inconveniences were outweighed by the fine-grained cookie control
> it gave the users.
>
> The functionality was useful for many, plus it was instructive as it
> would show which cookies were set by which domain.

You can still see which domains set which cookies through various means
(page info, the preferences, the network inspector in devtools, 'cookie
list' in GCLI (shift-f2), add-ons...). That functionality has not gone away.

> It was one of the few differentiating factors between Firefox and other
> browsers. Someone even said that many everyday users - not powerusers -
> liked the feature and switched to Firefox thanks to it.

Is there data about this and how many people were involved? Do you also
have data about how many people stopped using Firefox because they
changed the setting without really understanding it, then found there
browser unusable and gave up in despair? (see also
http://limi.net/checkboxes-that-kill/ )

"Differentiating" is really just a fancy-ification of "different", with
an implication of "better". I disagree that there were or are "few" such
factors - that is, I think there are quite a number! - but not everybody
benefits from each of them. Clearly, you benefited from this one and
presumably not from some of the other ones.

However, if we couldn't remove anything that was making us different,
that would severely restrict our ability to innovate. Our library
(bookmarks + history + downloads manager) is different (and arguably
better) than that/those of other browsers. Does that mean we can't
change it? Does that mean that for any such "different" piece of UI or
functionality, we can't make decisions about which parts of it are more
or less desirable and therefore should be kept/axed/replaced?

Even if we accept that we want to increase the number of differentiating
factors, we also need to ensure that we can remove old things that
nobody uses anymore. Until Firefox 32 (only released about 1.5 year
ago!), we had a hidden pref to disable frames (
https://bugzilla.mozilla.org/show_bug.cgi?id=1013457 ). No other
browsers I know of had such functionality anymore - should we have kept
that?

Purely the fact that it's different and that there might be niche
usecases is not enough justification to keep/implement functionality in
the core browser.

> Now the bare options are very limited, and the default setting for those
> who were using the "Ask every time" option has become "Accept" instead
> of "Reject", which would have been the safest option for privacy matters.
> Many websites are broken when one selects the "Reject" option,

... which is presumably why people were migrated to 'accept', rather
than 'reject', because effectively breaking their internet access and
then leaving them to dig through the options to figure out how to fix it
would have been a pretty bad idea.

Note also that we still give you separate control over third-party
cookies, and so "accept" and "reject" aren't actually the only options.

> Extensions such as Privacy Badger or Cookie Controller are presented as
> an alternative, but they either make use of public white-lists or have a
> rather old UI.

Sorry, but the 'ask me every time' cookie dialog UI hadn't been updated
for at least 5 years, maybe closer to a decade. "old UI" doesn't sound
like a great reason not to use something if that was what you were using
before.

If there is sufficient demand for this degree of control, I'm sure folks
who want it will write/update add-ons for it and provide better UI.

> Firefox communicates a lot on protecting its users privacy, but this
> update seems to head in the opposite direction, giving less control to
> its users.

I would say that we are removing something that pretended to give you
control, but didn't really (and had a whole host of other downsides).

The underlying assumption here is that it is possible for a user to
assess whether you should accept a cookie based on the modal dialog.
That is fundamentally not the case because you cannot know a-priori
whether that cookie is used "just" for tracking or for login
functionality. Yes, cookie names give you some clues, but only if the
programmers were kind to you and not misleading (which is an
unreasonable assumption if you also want to use this functionality to
stop 'malicious' use of cookies). The only way you can really know is if
you look where it is sent/used, which you don't know at the point when
it's set, which is when you were interrupted by a modal dialog asking
you what to do.

The old model also involves everyone making these decisions manually all
the time, when those decisions could be shared out meaning people can
spend more time doing what they want to do instead of trying to decide
what to do about cookies. The shared keeping of lists for things like
this as a model has proved thousands of times more successful if you
look at add-on usage of things like Ghostery, Disconnect.me or Adblock
Plus and its block lists. Very very very few people have the time and
energy to spend hours or days of their time over the course of a year
just to micromanage their cookies, especially when they are such a small
part of what tracks you on the web today.

In a certain sense, this boils down to a very basic principle: Firefox
should not burden the user with extra/complex choices when we can reduce
those choices to simpler ones. Blocking images, JS or cookies
specifically are all really proxies for higher-level user intentions,
whether it's avoiding tracking, reducing bandwidth consumption, or
testing website behaviour as developers. We should make (and are
making!) tools and options that cater to those high-level intentions and
take care of the mechanics "as if by magic", instead of forcing users to
learn about the machinery of the web just to get Firefox to "do what
they mean".

~ Gijs

[Mike Hoye]

On 2016-02-04 12:54 PM, Hugues de Lassus Saint-Geniès wrote:
> Dear Firefox developers,
>
> Since the patch for bug #606655 "Remove "Ask me everytime" cookies
> option" was merged into Firefox 44 release, many comments have been made
> on Bugzilla about the problems caused by the loss of such a functionality.

If you go to take a look at addons.mozilla.org and search for "cookies",
there a couple of great addons that let you manage or manipulate cookies
in various ways - "Self Destructing Cookies" is a personal favorite, but
there are a couple of good choices there, and I think that a few of them
have whitelist/blacklist/ask options built in.

https://addons.mozilla.org/en-US/firefox/search/?q=cookies

Something in there might have what you're looking for, or better!

> It was one of the few differentiating factors between Firefox and other
> browsers. Someone even said that many everyday users - not powerusers -
> liked the feature and switched to Firefox thanks to it.

I think we're going to have to agree to disagree about that.

- mhoye

[Hugues de Lassus Saint-Geniès]

Le 04/02/2016 19:56, Gijs Kruitbosch a écrit :
> You can still see which domains set which cookies through various means
> (page info, the preferences, the network inspector in devtools, 'cookie
> list' in GCLI (shift-f2), add-ons...). That functionality has not gone
> away.

For instance, how do I know that blogger.com needs to set some cookies
in order for blogspot.com to work?
Of course, blogspot.com cookies will show up in page info, prefs, cookie
list, but not blogger.com ones if I do not ask specifically for them.

>> It was one of the few differentiating factors between Firefox and other
>> browsers. Someone even said that many everyday users - not powerusers -
>> liked the feature and switched to Firefox thanks to it.
> Is there data about this and how many people were involved? Do you also
> have data about how many people stopped using Firefox because they
> changed the setting without really understanding it, then found there
> browser unusable and gave up in despair? (see also
> http://limi.net/checkboxes-that-kill/ )

Not at all, I just did a sum up of the Bugzilla comments. Of course
provided data only engage their original authors, I am not here to claim
anything for someone else.
Link is interesting, though a bit extremist IMHO: any fresh install of
Firefox should not break the Internet for the user, with appropriately
set options, etc. Having said this, I think the user should be allowed
to customize his experience wrt. his knowledge without having to
download and install 20 extensions. Disabling Javascript can increase
your privacy at the expense of breaking many websites, but I think you
*should* have the ability to do this with a bare Firefox.
I am not saying that extensions are useless, they are great, but I'd
like to see features stay in the core if they still seem meaningful.
Take this silly example: imagine if we removed RSS support because many
average users do not use them, and say that those who want to have to
install the extensions they want between the 177 extensions relevant
with the keyword "RSS". I think we would make a big step back (when I
used Sage as an RSS reader ^_^) if the functionalities used by a
minority were removed just "because they can break the average user's
Internet".

>
> "Differentiating" is really just a fancy-ification of "different", with
> an implication of "better". I disagree that there were or are "few" such
> factors - that is, I think there are quite a number! - but not everybody
> benefits from each of them. Clearly, you benefited from this one and
> presumably not from some of the other ones.

Was just summing up Bugzilla comments, I really enjoy Firefox for many
reasons, at the top of which its community and spirit. :)

>> Many websites are broken when one selects the "Reject" option,
> ... which is presumably why people were migrated to 'accept', rather
> than 'reject', because effectively breaking their internet access and
> then leaving them to dig through the options to figure out how to fix it
> would have been a pretty bad idea.

I guess few people were effectively using the functionality without
knowing what it did and what "risks" it involved, so breaking their
Internet for 5 minutes would not have been a plague.

> Note also that we still give you separate control over third-party
> cookies, and so "accept" and "reject" aren't actually the only options.

Yes, but unfortunately not enough to refuse unnecessary cookies.
Plus there may be a regression found, see comment #67 in bug #606655.

> Sorry, but the 'ask me every time' cookie dialog UI hadn't been updated
> for at least 5 years, maybe closer to a decade. "old UI" doesn't sound
> like a great reason not to use something if that was what you were using
> before.

Just a matter of taste, I guess. In this case I prefer a popup than a
lot of cascading menus I get easily lost in.

> The underlying assumption here is that it is possible for a user to
> assess whether you should accept a cookie based on the modal dialog.
> That is fundamentally not the case because you cannot know a-priori
> whether that cookie is used "just" for tracking or for login
> functionality. Yes, cookie names give you some clues, but only if the
> programmers were kind to you and not misleading (which is an
> unreasonable assumption if you also want to use this functionality to
> stop 'malicious' use of cookies). The only way you can really know is if
> you look where it is sent/used, which you don't know at the point when
> it's set, which is when you were interrupted by a modal dialog asking
> you what to do.

100% agree but you had the choice to refuse subdomain cookies. Now you
just don't. For instance I guess while browsing foo.com and accepting
only 1st-party cookies then metrics.foo.com can write any cookie they
want. And that's precisely what I liked so much about the functionality.

> The old model also involves everyone making these decisions manually all
> the time, when those decisions could be shared out meaning people can
> spend more time doing what they want to do instead of trying to decide
> what to do about cookies. The shared keeping of lists for things like
> this as a model has proved thousands of times more successful if you
> look at add-on usage of things like Ghostery, Disconnect.me or Adblock
> Plus and its block lists. Very very very few people have the time and
> energy to spend hours or days of their time over the course of a year
> just to micromanage their cookies, especially when they are such a small
> part of what tracks you on the web today.

Letting the majority decide for everyone else what to think or do is
pretty obnoxious don't you think?

> In a certain sense, this boils down to a very basic principle: Firefox
> should not burden the user with extra/complex choices when we can reduce
> those choices to simpler ones. Blocking images, JS or cookies
> specifically are all really proxies for higher-level user intentions,
> whether it's avoiding tracking, reducing bandwidth consumption, or
> testing website behaviour as developers. We should make (and are
> making!) tools and options that cater to those high-level intentions and
> take care of the mechanics "as if by magic", instead of forcing users to
> learn about the machinery of the web just to get Firefox to "do what
> they mean".

If you asked me, I'd say this boils down to fresh installers vs. old
drivers.

Best regards,
--
Hugues

[Hugues de Lassus Saint-Geniès]

Le 04/02/2016 19:38, Boris Zbarsky a écrit :
> Plus it violated Gecko invariants and thus led to lots of crashes, yes?

During the six or seven months I used this option I did not experience
any noticeable crash, whether it be on Windows or Linux.

--
Hugues

[Hugues de Lassus Saint-Geniès]

Le 04/02/2016 20:06, Mike Hoye a écrit :
> If you go to take a look at addons.mozilla.org and search for "cookies",
> there a couple of great addons that let you manage or manipulate cookies
> in various ways - "Self Destructing Cookies" is a personal favorite, but
> there are a couple of good choices there, and I think that a few of them
> have whitelist/blacklist/ask options built in.
>
> https://addons.mozilla.org/en-US/firefox/search/?q=cookies

Yeah thanks for the suggestion, I have already begun my quest for the
Grail because I know the probability to see this backported to core is
close to zero :-)

> Something in there might have what you're looking for, or better!
>> It was one of the few differentiating factors between Firefox and other
>> browsers. Someone even said that many everyday users - not powerusers -
>> liked the feature and switched to Firefox thanks to it.
>
> I think we're going to have to agree to disagree about that.

Well, I must say I am skeptic about it too.

Best regards,
--
Hugues

[Marco Bonardo]

On Fri, Feb 5, 2016 at 12:34 AM, Hugues de Lassus Saint-Geniès <hugues.d...@univ-perp.fr> wrote:

Take this silly example: imagine if we removed RSS support because many
average users do not use them, and say that those who want to have to
install the extensions they want between the 177 extensions relevant
with the keyword "RSS". I think we would make a big step back (when I
used Sage as an RSS reader ^_^) if the functionalities used by a
minority were removed just "because they can break the average user's
Internet".

It's not that silly, indeed the removal of support to RSS has been evaluated multiple times (I usually opposed, if you care to know). Releasing a software like Firefox to hundreds millions users is a complex task and until you are actually doing it, many things may indeed look "silly", but often they are not.

Also, add-ons are not an enemy nor an evil thing, we should stop saying things like "requiring a user to install 20 add-ons is wrong...". Nothing wrong with that, it's customization.

-m

[L. David Baron]

On Friday 2016-02-05 21:40 +0100, Marco Bonardo wrote:
> Also, add-ons are not an enemy nor an evil thing, we should stop saying
> things like "requiring a user to install 20 add-ons is wrong...". Nothing
> wrong with that, it's customization.

I think there is something wrong with it, though: the quality bar
for addons tends to be a lot lower than for core Firefox code (since
they don't get the level of testing, including testing in continuous
integration, that core code does). Thus addons tend to have memory
leaks, performance problems, etc. A user with 20 addons is likely
to hit multiple such problems, and then to blame them on Firefox.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[Brendan Barnwell]

On 2016-02-05 12:40, Marco Bonardo wrote:> On Fri, Feb 5, 2016 at 12:34

AM, Hugues de Lassus Saint-Geniès

> <hugues.d...@univ-perp.fr <mailto:hugues.d...@univ-perp.fr>>

This philosophy is cast into doubt when Firefox deprecates the existing
extension mechanism, casting hundreds or thousands of existing, working
customizations into limbo. If the way for people to customize Firefox
is with extensions, then making sure upgrades never break extensions
becomes as important as making sure upgrades don't remove functionality
from core Firefox.

-- Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown

[Dave Townsend]

That is one of the reasons for deprecating the existing extension
mechanism, because we can never be sure that updates won't break
extensions using that mechanism.

[Boris Zbarsky]

On 2/4/16 6:34 PM, Hugues de Lassus Saint-Geniès wrote:
> Le 04/02/2016 19:38, Boris Zbarsky a écrit :
>> Plus it violated Gecko invariants and thus led to lots of crashes, yes?
>
> During the six or seven months I used this option I did not experience
> any noticeable crash, whether it be on Windows or Linux.

It's possible you got lucky. It really depends on what scripts on the
page end up running while the dialog is up, and hence on what pages you
visit. But it was pretty simple to create pages that would crash every
time. With a bit more work, I expect those pages could exploit the
browser via this codepath to run arbitrary code...

-Boris

[Brendan Barnwell]

That is interesting. Are you saying that, once the new extension
mechanism is in place, you will guarantee that upgrades will never again
break extensions?

--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown

[Dave Townsend]

On Fri, Feb 5, 2016 at 12:49 PM, Brendan Barnwell <bren...@brenbarn.net> wrote:
> On 2016-02-05 12:47, Dave Townsend wrote:
>>
>> On Fri, Feb 5, 2016 at 12:45 PM, Brendan Barnwell <bren...@brenbarn.net>
>> wrote:
>>>
>>> This philosophy is cast into doubt when Firefox deprecates the
>>> existing extension mechanism, casting hundreds or thousands of existing,
>>> working customizations into limbo. If the way for people to customize
>>> Firefox is with extensions, then making sure upgrades never break
>>> extensions
>>> becomes as important as making sure upgrades don't remove functionality
>>> from
>>> core Firefox.
>>
>>
>> That is one of the reasons for deprecating the existing extension
>> mechanism, because we can never be sure that updates won't break
>> extensions using that mechanism.
>
>
> That is interesting. Are you saying that, once the new extension
> mechanism is in place, you will guarantee that upgrades will never again
> break extensions?

I would never make any guarantees like that but maintaining
compatibility for a well-defined and sandboxed API is far easier than
maintaining API compatibility for the entire internal code of Firefox.

[Marco Bonardo]

On Fri, Feb 5, 2016 at 9:44 PM, L. David Baron <dba...@dbaron.org> wrote:

I think there is something wrong with it, though:  the quality bar
for addons tends to be a lot lower than for core Firefox code

You are right, but here we are comparing an add-on maintained by someone vs a feature/piece of code with no maintainer and known issues, likely untouched from years.

I'd not want to generalize the discussion too much, since we are not discussing removal of the location bar or the menubar and pretending an add-on developer can do better. It's not about any feature, just things we can't guarantee sufficient quality.

-m

[Brunoais]

I concur. I didn't have any issues yet with the popup asking what do I
want to do with certain cookies.

How do I do now to select the cookies I accept to have and the ones I do
not accept to have? What are the real viable alternatives? I don't want
to be tracked by ads, for example.

[Matt]

On 05/02/16 20:47, Boris Zbarsky wrote:
> On 2/4/16 6:34 PM, Hugues de Lassus Saint-Geniès wrote:
>> Le 04/02/2016 19:38, Boris Zbarsky a écrit :
>>> Plus it violated Gecko invariants and thus led to lots of crashes, yes?
>>
>> During the six or seven months I used this option I did not experience
>> any noticeable crash, whether it be on Windows or Linux.
>
> It's possible you got lucky. It really depends on what scripts on the
> page end up running while the dialog is up, and hence on what pages
> you visit. But it was pretty simple to create pages that would crash
> every time. With a bit more work, I expect those pages could exploit
> the browser via this codepath to run arbitrary code...

I've been using this feature since netscape 4.x and I've never seen it
crash; mind you I've only run it on Linux.

Matt

[Tanvi Vyas]

On 2/5/16 1:53 PM, Brunoais wrote:
> I concur. I didn't have any issues yet with the popup asking what do I
> want to do with certain cookies.
>
> How do I do now to select the cookies I accept to have and the ones I
> do not accept to have? What are the real viable alternatives? I don't
> want to be tracked by ads, for example.
>

Shouldn't disabling third party cookies be good enough to disable
tracking? Maybe combined with Tracking Protection?

Within a particular domain, it is really tough to tell which cookies you
need and which one's you don't. How did you decide which cookies to accept?

It would be nice if we had a cookie blocking override UI. That way,
privacy conscious users could block all cookies all third party cookies
(or even block all cookies), and then use the override for sites that
break or sites that they need to login to.

[Marco Bonardo]

On Sat, Feb 6, 2016 at 12:11 AM, Tanvi Vyas <ta...@mozilla.com> wrote:

Shouldn't disabling third party cookies be good enough to disable tracking?  Maybe combined with Tracking Protection?

Yes there are indeed alternatives that don't require micro-management to be effective, like disallowing third party cookies, using tracking protection with the Strict list and the various add-ons that can block unwanted contents (Ghostery, Cookie controller, Privacy Badger, Ublock, AdBlock plus) and that can also handle personal lists.

It would be nice if we had a cookie blocking override UI.  That way, privacy conscious users could block all cookies all third party cookies (or even block all cookies), and then use the override for sites that break or sites that they need to login to.

Provided it's not an usability modal dialogs nightmare like the old one. Fwiw tracking protection allows to unblock single pages, as well as most of the above add-ons.
But honestly, are we sure today's Web is still compatible with cookies micro-management on the user side, as it used to be 10 years ago?

-m

[Brunoais]

My default policy is to deny cookies and javascript from everywhere I don't explicitly know. Websites that I believe that contain information for me based on websearches I do are a good example.

For most non-recurring websites, I actually, usually, visit them while denying all cookies from everywhere and denying javascript. My experience may be diminished but it is a choice I made. It may requite more work and more clicks to get things done but it is a choice I made.
Then, for websites that require cookies and are in the same "kind", I usually decide to set to deleting the related cookies when I finish my browsing session. They may recognize me when I'm back but it has to be in the same browsing session.

How do I make such decision with with so much ease using a different UI? Is there an addon capable of it, also?

[Mike Hoye]

On 2016-02-06 11:46 AM, Brunoais wrote:

For most non-recurring websites, I actually, usually, visit them while denying all cookies from everywhere and denying javascript. My experience may be diminished but it is a choice I made. It may requite more work and more clicks to get things done but it is a choice I made.
Then, for websites that require cookies and are in the same "kind", I usually decide to set to deleting the related cookies when I finish my browsing session. They may recognize me when I'm back but it has to be in the same browsing session.

How do I make such decision with with so much ease using a different UI? Is there an addon capable of it, also?

Self Destructing Cookies, here:

https://addons.mozilla.org/en-US/firefox/addon/self-destructing-cookies/?src=search

does a thing that comes close to doing what you want and might make your life a bit easier in the process. Rather than denying all cookies, it promptly removes cookies that aren't being used by open browser tabs and removes tracking cookies immediately. A few moments after you've closed all the tabs with some site open, it removes the cookies for that site.

NoScript should cover the JS side of things for you, and it's here:

https://addons.mozilla.org/en-US/firefox/addon/noscript/?src=search

Both of those have whitelists, if you want to allow some sites. The combination of this, using the built-in password manager and setting your Firefox preferences to accept cookies only until you close the browser, that should get you where you'd like to be as far as tracking cookies are concerned, while making it a bit less tedious to stay logged into places or buy stuff if you're so inclined.


- mhoye

[Mike Hoye]

On 2016-02-05 4:48 PM, Marco Bonardo wrote:
> It's not about any feature, just things we can't guarantee sufficient
> quality.

I think the admission that we can't make a feature great, either because
it doesn't have a large enough audience or we don't have sufficient
resources, isn't the same as saying that feature can't be made great by
somebody.

We've got a rapidly-growing design community now, and as the addons
situation shakes out we're going to spend more time connecting addon
creators with aspiring designers.

We're going to have a lot more discussions like this as more features
lose the great-or-dead coin toss, so I'm pretty confident the Right
Thing for us is to do the up-front work of helping people who rely on
some soon-dead feature find a migration path towards a decent
replacement addon or set of addons, and help their developers ship
something great.


- mhoye

[Brunoais]

I'm already using NoScript.

I'll look into self-destructing cookies. It will probably be good enough for me. Thank you for the suggestion.

[Robin Laing]

Self destructing cookies doesn't come close to Ask me everytime. Ask me
everytime allowed me to control cookies as they were presented. Accept
the number and what cookies I felt I wanted. Don't accept the cookies
that are tracking cookies for a different site under the site I want to
visit's domain.

I have looked at recommended cookie managers and none provide the same
feature.

No Script doesn't deal with the cookies.

Robin

[Robin Laing]

I do understand this and part of me agrees that an addon could do this
job. I even suggested it in a gmane post to take the code and convert
it into an addon.

My only concern about any addon is the issue of will they work when
there is an update to Firefox. Also, do I have to turn them off to
debug a rare problem.

As one person said, Firefox is becoming more like Chrome so there is no
reason to use Firefox anymore. Integrated cookie management was one of
the reasons that they used Firefox and one of the reasons they are
sticking with an older Firefox for now. They were the first one to warn
me about this change.

Maybe one of the other cookie manager addon developers would like the code.

Robin

[Brunoais]

I think the addon doesn't do the job. I think that I can accept it as an
alternative but not as a complete alternative.

[Hugues de Lassus Saint-Geniès]

Le 06/02/2016 00:11, Tanvi Vyas a écrit :
> Shouldn't disabling third party cookies be good enough to disable
> tracking? Maybe combined with Tracking Protection?

Unfortunately, disabling third-party cookies causes some websites I log
into to be completely broken, even when allowing 3rd-party cookies "from
visited websites".
Because I usually log into a big 'hub' from a more specific website that
is supposed to redirect me towards the hub.
When I *always* allow third-party cookies, then it works, and I get
redirected to the hub. But I obviously lose *all* the advantages of
disabling third-party cookies...

That is one of the reasons why I miss the "Ask me every time" option so
much. Now I'm stuck with accepting third-party cookies every time!

Side questions:
Is the "Keep until" preference referring to ALL cookies or just
third-party? I find this quite unclear in the UI. Would it reduce the
"Always accept 3rd-party cookies" to "just" a session-storage storage
issue instead of a global-storage problem?

--
Hugues de Lassus Saint-Geniès

[Chris Peterson]

On 2/5/16 12:40 PM, Marco Bonardo wrote:
> Also, add-ons are not an enemy nor an evil thing, we should stop
> saying things like "requiring a user to install 20 add-ons is
> wrong...". Nothing wrong with that, it's customization.

Customization with add-ons is great, but it is also an indicator of what
Firefox users want and do not get with the default Firefox. Add-ons are
also not easily discoverable. Among AMO's 40 most popular add-ons, 11
are privacy-related add-ons (mostly ad blockers) and 10 are video
downloaders (mostly YouTube). Perhaps we should incorporate the best
features from these add-ons directly into Firefox, while providing API
hooks so add-on developers can continue to innovate.

For example, Adblock Plus is the most popular add-on, but it has a
reputation of increasing Firefox memory usage and hurting performance.
We now include Tracking Protection in Firefox itself, but Mozilla
manages the Tracking Protection list. Why not allow users to specify
their own personal lists and community-managed lists (like uBlock), in
addition to Mozilla's?

[Francois Marier]

On 10/02/16 09:01 AM, Hugues de Lassus Saint-Geniès wrote:
> Is the "Keep until" preference referring to ALL cookies or just
> third-party? I find this quite unclear in the UI. Would it reduce the
> "Always accept 3rd-party cookies" to "just" a session-storage storage
> issue instead of a global-storage problem?

"Keep until" is for all cookies. So it you change it to "until I close
Firefox" then both first-party and third-party cookies will become
session cookies (which are removed when the browser exits).

There is a preference in about:config to turn only third-party cookies
into session cookies:

network.cookie.thirdparty.sessionOnly = true

With that on, first-party cookies will stick around, but third-party
cookies will be cleared when you close Firefox.

I blogged about our cookie options recently. You might find this useful:


https://feeding.cloud.geek.nz/posts/tweaking-cookies-for-privacy-in-firefox/

Francois

[Panos Astithas]

On Fri, Feb 12, 2016 at 10:03 PM, Chris Peterson <cpet...@mozilla.com> wrote:

For example, Adblock Plus is the most popular add-on, but it has a reputation of increasing Firefox memory usage and hurting performance. We now include Tracking Protection in Firefox itself, but Mozilla manages the Tracking Protection list. Why not allow users to specify their own personal lists and community-managed lists (like uBlock), in addition to Mozilla's?

It's not entirely accurate that we manage the tracking protection list ourselves, we rely on our partner for that. But we do have plans to enable user-provided lists in the future. Of course we first need to ship tracking protection in normal mode (beyond Nightly) for that work to become important and resourced.

Panos

[Robin Laing]

On 11/02/16 11:28, Brunoais wrote:
> I think the addon doesn't do the job. I think that I can accept it as an
> alternative but not as a complete alternative.
>
> On 09-02-2016 05:21, Robin Laing wrote:
>> On 08/02/16 07:57, Mike Hoye wrote:
>>> On 2016-02-05 4:48 PM, Marco Bonardo wrote:
>>>> It's not about any feature, just things we can't guarantee sufficient
>>>> quality.
>>> I think the admission that we can't make a feature great, either because

>>

>> I do understand this and part of me agrees that an addon could do this
>> job. I even suggested it in a gmane post to take the code and convert
>> it into an addon.
>>
>> My only concern about any addon is the issue of will they work when
>> there is an update to Firefox. Also, do I have to turn them off to
>> debug a rare problem.
>>
>> As one person said, Firefox is becoming more like Chrome so there is
>> no reason to use Firefox anymore. Integrated cookie management was
>> one of the reasons that they used Firefox and one of the reasons they
>> are sticking with an older Firefox for now. They were the first one
>> to warn me about this change.
>>
>> Maybe one of the other cookie manager addon developers would like the
>> code.
>>
>> Robin
>>

A properly written addon to restore the "Ask me every time" would meet
the task for me. BUT, at present, there is no addon that even comes close.

I am now relegated to changing cookie settings and watching what I do on
a per click basis to maintain some sense of privacy. What used to take
seconds now takes minutes. It is a major problem to maintain privacy
when doing major searches. Used to be able to check cookies from a
single source, now I have to change tabs and play with settings for each
click on a link from a search.

I wish I was like someone else that DIDN'T upgrade to F44+. I wish I
had kept F43 on my system. I will look at downgrading on Monday or
moving to Seamonkey. I cannot use F44 for work, it is to slow.

[Brunoais]

That is global for all 3rd party cookies. I don't want to do that to all
3rd party cookies. Some (minority) are not bad. I do agree, though that
most 3rd party cookies are meant to do stuff that annoys, though.

[Brunoais]

About those "options that can kill", I'd choose to keep them existing
but behing a "wall" that stated that it is an advanced feature.
"about:config" home page is a good example, IMO.

On 04-02-2016 18:56, Gijs Kruitbosch wrote:
> On 04/02/2016 17:54, Hugues de Lassus Saint-Geniès wrote:
>> Dear Firefox developers,
>>
>> Since the patch for bug #606655 "Remove "Ask me everytime" cookies
>> option" was merged into Firefox 44 release, many comments have been made
>> on Bugzilla about the problems caused by the loss of such a
>> functionality.
>>
>> I will try to summarize a bit some of what has been said on the tracker:
>>
>> The option was somewhat bogus (see bug #365772)
> That bug indicates it broke sessionStorage completely. In ways that
> broke websites and that you couldn't recover from per-website without
> turning off the functionality entirely.
>
>> and it had a pretty bad
>> UI, plus it was apparently unmaintained.
> It also had stability problems (ie, it caused Firefox crashes), wasn't
> really an effective way of giving people control over their
> experience, and would have been even more problematic once we enabled
> multi-process Firefox.
>
>> Those inconveniences were outweighed by the fine-grained cookie control
>> it gave the users.
>>
>> The functionality was useful for many, plus it was instructive as it
>> would show which cookies were set by which domain.
> You can still see which domains set which cookies through various
> means (page info, the preferences, the network inspector in devtools,
> 'cookie list' in GCLI (shift-f2), add-ons...). That functionality has
> not gone away.
>> It was one of the few differentiating factors between Firefox and other
>> browsers. Someone even said that many everyday users - not powerusers -
>> liked the feature and switched to Firefox thanks to it.
> Is there data about this and how many people were involved? Do you
> also have data about how many people stopped using Firefox because
> they changed the setting without really understanding it, then found
> there browser unusable and gave up in despair? (see also
> http://limi.net/checkboxes-that-kill/ )
>
> "Differentiating" is really just a fancy-ification of "different",
> with an implication of "better". I disagree that there were or are
> "few" such factors - that is, I think there are quite a number! - but
> not everybody benefits from each of them. Clearly, you benefited from
> this one and presumably not from some of the other ones.
>
> However, if we couldn't remove anything that was making us different,
> that would severely restrict our ability to innovate. Our library
> (bookmarks + history + downloads manager) is different (and arguably
> better) than that/those of other browsers. Does that mean we can't
> change it? Does that mean that for any such "different" piece of UI or
> functionality, we can't make decisions about which parts of it are
> more or less desirable and therefore should be kept/axed/replaced?
>
> Even if we accept that we want to increase the number of
> differentiating factors, we also need to ensure that we can remove old
> things that nobody uses anymore. Until Firefox 32 (only released about
> 1.5 year ago!), we had a hidden pref to disable frames (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1013457 ). No other
> browsers I know of had such functionality anymore - should we have
> kept that?
>
> Purely the fact that it's different and that there might be niche
> usecases is not enough justification to keep/implement functionality
> in the core browser.
>
>> Now the bare options are very limited, and the default setting for those
>> who were using the "Ask every time" option has become "Accept" instead
>> of "Reject", which would have been the safest option for privacy
>> matters.
>> Many websites are broken when one selects the "Reject" option,
> ... which is presumably why people were migrated to 'accept', rather
> than 'reject', because effectively breaking their internet access and
> then leaving them to dig through the options to figure out how to fix
> it would have been a pretty bad idea.
>
> Note also that we still give you separate control over third-party
> cookies, and so "accept" and "reject" aren't actually the only options.
>
>> Extensions such as Privacy Badger or Cookie Controller are presented as
>> an alternative, but they either make use of public white-lists or have a
>> rather old UI.
> Sorry, but the 'ask me every time' cookie dialog UI hadn't been
> updated for at least 5 years, maybe closer to a decade. "old UI"
> doesn't sound like a great reason not to use something if that was
> what you were using before.
>
> If there is sufficient demand for this degree of control, I'm sure
> folks who want it will write/update add-ons for it and provide better UI.
>
>> Firefox communicates a lot on protecting its users privacy, but this
>> update seems to head in the opposite direction, giving less control to
>> its users.
> I would say that we are removing something that pretended to give you
> control, but didn't really (and had a whole host of other downsides).
>
> The underlying assumption here is that it is possible for a user to
> assess whether you should accept a cookie based on the modal dialog.
> That is fundamentally not the case because you cannot know a-priori
> whether that cookie is used "just" for tracking or for login
> functionality. Yes, cookie names give you some clues, but only if the
> programmers were kind to you and not misleading (which is an
> unreasonable assumption if you also want to use this functionality to
> stop 'malicious' use of cookies). The only way you can really know is
> if you look where it is sent/used, which you don't know at the point
> when it's set, which is when you were interrupted by a modal dialog
> asking you what to do.
>
> The old model also involves everyone making these decisions manually
> all the time, when those decisions could be shared out meaning people
> can spend more time doing what they want to do instead of trying to
> decide what to do about cookies. The shared keeping of lists for
> things like this as a model has proved thousands of times more
> successful if you look at add-on usage of things like Ghostery,
> Disconnect.me or Adblock Plus and its block lists. Very very very few
> people have the time and energy to spend hours or days of their time
> over the course of a year just to micromanage their cookies,
> especially when they are such a small part of what tracks you on the
> web today.
>
> In a certain sense, this boils down to a very basic principle: Firefox
> should not burden the user with extra/complex choices when we can
> reduce those choices to simpler ones. Blocking images, JS or cookies
> specifically are all really proxies for higher-level user intentions,
> whether it's avoiding tracking, reducing bandwidth consumption, or
> testing website behaviour as developers. We should make (and are
> making!) tools and options that cater to those high-level intentions
> and take care of the mechanics "as if by magic", instead of forcing
> users to learn about the machinery of the web just to get Firefox to
> "do what they mean".
>
> ~ Gijs

[Brunoais]

Although It is not the path I like most, I'm OK with it because I
understand how it is to deal with such things in a project where only a
handful of developers are actively maintaining and improving it.

If you do the homework to make sure that for each feature removed an
addon exists that replaces it well enough and that there's enough API
for it to exist, then I'm fine with it.

[Robin Laing]

Looked at your blog and still not satisfied as no suggestions provide a
workable solution for me.

Okay, after a month, I still find this is a real problem. I tried to
downgrade but I couldn't find a 43 version for my Linux.

I have tried to use different add-ons but none have restored the feature
and convenience. I have had so many broken web sites now that I don't
allow any cookies unless I really need too.

Even sites that I go to regularly are now a problem as I have to check
so see if they are adding third party tracking site cookies as many do.

Luckily for me at work, I cannot get Firefox 44 to download through our
firewall.

Robin

[Hugues de Lassus Saint-Geniès]

Le 09/03/2016 05:40, Robin Laing a écrit :
> On 12/02/16 17:19, Francois Marier wrote:
>> On 10/02/16 09:01 AM, Hugues de Lassus Saint-Geniès wrote:
>>> Is the "Keep until" preference referring to ALL cookies or just
>>> third-party? I find this quite unclear in the UI. Would it reduce the
>>> "Always accept 3rd-party cookies" to "just" a session-storage storage
>>> issue instead of a global-storage problem?
>>
>> "Keep until" is for all cookies. So it you change it to "until I close
>> Firefox" then both first-party and third-party cookies will become
>> session cookies (which are removed when the browser exits).
>>
>> There is a preference in about:config to turn only third-party cookies
>> into session cookies:
>>
>> network.cookie.thirdparty.sessionOnly = true
>>
>> With that on, first-party cookies will stick around, but third-party
>> cookies will be cleared when you close Firefox.

I think that this should be in the UI, do you agree?

>> I blogged about our cookie options recently. You might find this useful:
>>
>>
>> https://feeding.cloud.geek.nz/posts/tweaking-cookies-for-privacy-in-firefox/

Will check this when I have got some time :-)

> I have tried to use different add-ons but none have restored the feature
> and convenience. I have had so many broken web sites now that I don't
> allow any cookies unless I really need too.

As for me, I returned to allowing every cookie, including third-party,
except that I kept my already existing black-and-white list active.
I find it a really ugly solution, as my cookie database now contains a
lot of unwanted cookies but this is the only option I have come up with
for the moment, as I don't have much time to work on this issue right now.

--
Hugues de Lassus Saint-Geniès

[Mike Hoye]

On 2016-03-08 11:40 PM, Robin Laing wrote:
>
> I have tried to use different add-ons but none have restored the
> feature and convenience. I have had so many broken web sites now
> that I don't allow any cookies unless I really need too.

Cookie Whitelist With Buttons, here:

https://addons.mozilla.org/en-US/firefox/addon/cookie-whitelist-with-buttons/?src=search

has the block-all-and-whitelist feature.



- mhoye

[Robin Laing]

On 09/03/16 09:59, Mike Hoye wrote:
> On 2016-03-08 11:40 PM, Robin Laing wrote:
>>
>> I have tried to use different add-ons but none have restored the
>> feature and convenience. I have had so many broken web sites now
>> that I don't allow any cookies unless I really need too.
>
> Cookie Whitelist With Buttons, here:
>
> https://addons.mozilla.org/en-US/firefox/addon/cookie-whitelist-with-buttons/?src=search
>
>
> has the block-all-and-whitelist feature.
>
>
>
> - mhoye

It is an option but still doesn't help when you have a site that wants
to setup cookies for tracking sites under their domain. Such as
bad-tracker.good-domain.com

You allow for a domain but don't want THAT cookie. Now you don't know
if it is there or not.

With the privacy UI now a TAB, it is a pain to monitor cooikies. I can
open a private session and then open the privacy TAB in that window so I
can real time monitor cookies. It a another painful workaround.

As a side note, in the comments for some other issue, I read that the
reason some people think options are not being used is because of no
usage details being sent to Firefox. I for one, due to privacy, refuse
to send this data. I have no idea what is in the data and thus don't
trust it, as I don't trust MS data gathering.

Now, if those interested in privacy turn off this "feature" and this is
why they decided that few people are using "Ask me every time", then
they are working with bad metrics.

All those that I know that are upset about losing "Ask me every time"
are all concerned about privacy and tracking. Looking at other options
that protect privacy since they now feel that Firefox is becoming Chrome II.

Robin

[»Q«]

On Mon, 14 Mar 2016 21:21:09 -0600
Robin Laing wrote:

> On 09/03/16 09:59, Mike Hoye wrote:
> > On 2016-03-08 11:40 PM, Robin Laing wrote:
> >>
> >> I have tried to use different add-ons but none have restored the
> >> feature and convenience. I have had so many broken web sites now
> >> that I don't allow any cookies unless I really need too.
> >
> > Cookie Whitelist With Buttons, here:
> >
> > https://addons.mozilla.org/en-US/firefox/addon/cookie-whitelist-with-buttons/?src=search
> >
> >
> > has the block-all-and-whitelist feature.
>

> It is an option but still doesn't help when you have a site that
> wants to setup cookies for tracking sites under their domain. Such as
> bad-tracker.good-domain.com
>
> You allow for a domain but don't want THAT cookie. Now you don't
> know if it is there or not.

Your best bet is probably to file issues at
<https://github.com/7adietri/cookie-whitelist-with-buttons> in hopes
that the extension can be upgraded to better suit your needs.

> As a side note, in the comments for some other issue, I read that the
> reason some people think options are not being used is because of no
> usage details being sent to Firefox. I for one, due to privacy,
> refuse to send this data.

Note that I'm not in any way involved in Mozilla decision-making.

IME, Mozilla rely heavily on usage data for decisions about keeping
ditching features; they do not rely on a small (vanishingly small in
this case, considering number of Fx users) number of people posting
that they want a feature. Whether Mozilla's reliance on data is good,
bad, or ugly, people who refuse to provide any data to Mozilla can't
reasonably expect Mozilla to cater to their wants and needs. It's hard
to help people who are hiding from you.

> I have no idea what is in the data and thus don't trust it, as I
> don't trust MS data gathering.

You can actually see what data is being sent and read about how
Mozilla handle it once it's on their servers. Studying it may be
tedious, but it can't be much more tedious than studying cookies one by
one. ;) (Years ago I used to micro-manage cookies, but I gave it up as
ineffective, pretty much for the reasons Mike Connor went into in a
recent post here.)