296078 - Adding an option to allow a single short cookie per domain to be persistent

Status: RESOLVED EXPIRED

(Core :: Networking: Cookies, enhancement)

Description

[MozillaUser]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.7.8) Gecko/20050511
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.7.8) Gecko/20050511

For good reasons, lots of users either disable cookies or allow them only for
the current session.

However, many websites use cookies to store non personally identifiable
preference configuration such as preferred language, favorite layout,
simple/advanced mode, etc ...

These uses are no threat to privacy and can significantly enhance the user's
experience.

The proposal would add a check box in the UI and corresponding code to allow the
normal policy to be bypassed if a cookie follows all these rules :
- The cookie content is 4 characters or less (too short to store a GUID)
- The cookie is from the originating website only (prevents a long cookie to be
formed by joining short cookies from many domains)
- There is no other cookie stored for that domain, or the other(s) cookie(s) for
the domain are limited to the current session (prevents a long cookie to be
formed by joining short cookies)

The option could be called 'Allow a single short cookie per domain' and be
checked by default (since cookie storage is enabled by default too)

A side effect of the change would be to allow websites to offer a better
experience for privacy conscious Mozilla/Firefox users compared to 'alternative'
browsers, without breaking any standard rules.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Dave Townsend [:mossop]]

What do you expect the site to store in 4 characters? Lanugage could sensibly be
5 characters (en-US etc.) or more (english).

How would Mozilla decide which of the cookies that the site returns it should
store permanently if there are multiple cookies that fit this scheme?

What's to stop a site using a single cookie to store a GUID, but flipping it,
having the GUID as the cookie name and setting the value to something short
enough to fit this scheme?

Comment 2

[MozillaUser]

(In reply to comment #1)
> What do you expect the site to store in 4 characters? Lanugage could sensibly be
> 5 characters (en-US etc.) or more (english).
 
A lot can be stored in a 4 character cookie (or less).
Imagine a site that offer choice between English, Spanish, French and German,
allow entry by either the main page or the boards and offer a beginner/normal/
advanced mode.

All this could be stored in a single character cookie
Code : 0x40 + 0x00(English) / 0x01(Spanish) 0x02(French) 0x03(German) +
0x00(Main)/0x04(board) + 0x00(beginner)/0x08(normal)/0x10(advanced)

For an advanced German language user who goes directly to the board, the cookie
would be:

0x40 + 0x03(German) + 0x04(board) + 0x10(advanced) = 0x57 (ASCII='W')

the cookie would be
cfg=W


> How would Mozilla decide which of the cookies that the site returns it should
> store permanently if there are multiple cookies that fit this scheme?

The last one (erasing the previous one, or all the previously stored cookies in
case some got stored before the user changed the option, unless the site is
authorized in the cookie manager)

> What's to stop a site using a single cookie to store a GUID, but flipping it,
> having the GUID as the cookie name and setting the value to something short
> enough to fit this scheme?

You're right, both the name and the content should be length limited for it to
work ...

Comment 3

[Hermann Schwab]

*** Bug 296084 has been marked as a duplicate of this bug. ***

Comment 4

[Steve England [:stevee]]

*** This bug has been marked as a duplicate of 296084 ***

Comment 5

[MozillaUser]

circular duplicate reference ...

Comment 6

[Michiel van Leeuwen (email: mvl+moz@)]

imo, this is a wontfix, because the heuristic is a bit random, and i don't think
it helps in a significant amount of sites to make them not track you but do
allow them to store your prefs.

Comment 7

[MozillaUser]

(In reply to comment #6)
> imo, this is a wontfix, because the heuristic is a bit random,

What's random about this ?

If the website designer wants his cookies properly baked, he makes them short /
safe ( less than 5 characters, or whatever 'privacy experts' deem appropriate to
prevent any significant form of tracking), else, he makes them longer,
compatible with GUID tracking and a lot of users will throw them away at the end
of every session.

> and i don't think it helps in a significant amount of sites
> to make them not track you but do allow them to store your prefs.

Not all websites want to invade their user's privacy ...

Storing the user prefs without the worries of being tracked would be a very
useful feature, applications include:
- Store the chosen language in multilingual sites (so that you won't need to
repeatedly switch from the default to your preferred language)
- Store the user's city (from a drop down list of world's main cities) to allow
personalized weather forecast, local time display, local news
- Track return visitors (visit counter) while respecting their privacy
- Store the CSS style the user selects
- store which parts of the site the visitor already visited
- Return a visitor to the last page he visited
- all the features cookies were designed for, except tracking. 

As the cookie system is currently implemented, you either allow them and forget
about privacy to gain a better experience, or you choose privacy at the expense
of personalization.

The goal of my proposal is to allow the user to 'unbundle' the personalization
and the tracking function of cookies. Just like popup blocking, this would be
popular with Firefox/Mozilla users and user oriented websites / quite unpopular
with marketers.

Comment 8

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 9

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.