Open Bug 844623 Opened 9 years ago Updated 5 years ago

Expire cookies only used as third-party after some time

Categories

(Core :: Networking: Cookies, enhancement, P5)

enhancement

Tracking

()

People

(Reporter: geekboy, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-would-take])

In bug 818340 comment 71, Brendan writes:
> Dolske on dev.privacy suggested "Add a timestamp for when the
> last first-party visit was for the site, and if you've not made a
> first-party visit within X weeks, drop the cookie." Recording here without
> splitting discussion, since it seems actionable in a code patch (followup
> bug fine).

We could also convert them to session cookies, though it's unclear what the lifetime of those would be.

See also bug 202690 and bug 589417 for some relevant info.
See also bug #576347.
Note that Western Federal Credit Union at <https://www.western.org/> -- one of the largest credit unions in the U.S. -- requires 3rd party cookies to enable Web-based bill-pay services.  Making those cookies session-only requires extra navigation to login and use bill-pay services each time I want to use those services.  If this RFE is implemented there should be a user-interface (not merely a preference reached via about:config) to disable it.
Severity: normal → enhancement
(In reply to David E. Ross from comment #2)
> Note that Western Federal Credit Union at <https://www.western.org/> -- one
> of the largest credit unions in the U.S. -- requires 3rd party cookies to
> enable Web-based bill-pay services.  Making those cookies session-only
> requires extra navigation to login and use bill-pay services each time I
> want to use those services.  If this RFE is implemented there should be a
> user-interface (not merely a preference reached via about:config) to disable
> it.

This bug is just completing the work on bug 818340 so that the transition from our current behavior to the new behavior makes sense. So, I expect that this bug's fix will be controlled by the setting of the pref that controls bug 818340. No UI needed.
OS: Mac OS X → All
Hardware: x86 → All
(In reply to Brian Smith (:bsmith) from comment #3)
> This bug is just completing the work on bug 818340 so that the transition
> from our current behavior to the new behavior makes sense. So, I expect that
> this bug's fix will be controlled by the setting of the pref that controls
> bug 818340. No UI needed.

Is scope of bug:

A) Modify all cookies that exist at time of installation of FF 22 to have a timer that requires a 1st party interaction or the cookie is deleted.
B) Enforce a new max-age on cookies stored by FF based on last 1st party interaction with the origin.  

I think that (A) meets the requirement of the migration, whereas (B) may introduce unexpected behavior even on sites that are only ever visited in the 1st party context, if they are visited infrequently.
So just to clarify, this is entirely a transitional fix for when bug 818340 lands?  And after that it will effectively do nothing?  Will the "timeout" only be effected if the new default cookie setting hasn't been changed by the user?
Bug 818340 has landed already, effective in Gecko 22.0 (current trunk nightlies).
(In reply to Brendan Butterworth from comment #4)

> Is scope of bug:
> 
> A) Modify all cookies that exist at time of installation of FF 22 to have a
> timer that requires a 1st party interaction or the cookie is deleted.
> B) Enforce a new max-age on cookies stored by FF based on last 1st party
> interaction with the origin.  

I originally proposed it only in the context of (A), but a general solution to the problem of "oops I once visited foo.com and now it's always a legit 3rd party cookie" would probably be interesting.

It wouldn't have to involve max-age; one could keep the cookies around as long as they would stay today, but simply stop sending them in a 3rd party context after X weeks. Dunno if that's useful (or worth the potential confusion), though, especially for large values of X.
One financial service that I use online is Western Federal Credit Union.  As I use that site, it requires cookies that are NOT session-only for the following domains:  www.western.org, .western.org, and ebankingwestern.org.  I would expect the first to be part of the second.  However, would ebankingwestern.org be considered a third-party cookie?
(In reply to Justin Dolske [:Dolske] from comment #7)
> 
> I originally proposed it only in the context of (A), but a general solution
> to the problem of "oops I once visited foo.com and now it's always a legit
> 3rd party cookie" would probably be interesting.
> 
> It wouldn't have to involve max-age; one could keep the cookies around as
> long as they would stay today, but simply stop sending them in a 3rd party
> context after X weeks. Dunno if that's useful (or worth the potential
> confusion), though, especially for large values of X.

Hmm, that's different than both (A) and (B).  Should this be moved to forums for proper scoping?
(In reply to Justin Dolske [:Dolske] from comment #7)
> 
> It wouldn't have to involve max-age; one could keep the cookies around as
> long as they would stay today, but simply stop sending them in a 3rd party
> context after X weeks. Dunno if that's useful (or worth the potential
> confusion), though, especially for large values of X.

This is precisely what I've been thinking. A motivating use case: We shouldn't treat clicking an ad once as a signal of perpetual user trust in all the various entities that the landing page redirects through. That said, it could be a bit risky to start deleting cookies altogether.

Microsoft does something similar ("leashing") in their cookie policy, for what it's worth.

http://msdn.microsoft.com/en-us/library/ms537343(v=vs.85).aspx
It is not simplier (even tough different) to have all non session cookes have a maximum lifetime? (indifferent of being 1st or 3rd party)
(In reply to Camilo Viecco (:cviecco) from comment #11)
> It is not simplier (even tough different) to have all non session cookes
> have a maximum lifetime? (indifferent of being 1st or 3rd party)

The general consensus seems to be that "logged in forever" is a supported use case. It certainly would be simplest to just acknowledge the problems with this and expire all cookies after some reasonable lifetime. Implementing this would only be a pref change, I think. This would be way out of the scope of this bug, however, so even if this was desired it might be a good idea to start by only expiring 3rd party cookies first.
Non-session cookies already have expiration dates.  At the least, users should have the option to choose between using the inherent expiration date and some user-set shorter lifetime.
Cookie expiration based on the dates a site sets don't really fit very well with the concerns at issue here. An entity (whether a site or a third party) which really wants to track users can just set cookies with far distant future expiration dates. That's not really helpful.

"Logged in forever" is definitely an important use case. It would be frustrating to find oneself logged out of a Gmail or Facebook account suddenly, and not know why. However, those sorts of accounts are easier to expire a certain amount of time after the cookie was last touched, or the site was last visited.

More frustrating might be sites like banks which have a convoluted an inconvenient initial log-in process, but then recognise a cookie (and possibly other fingerprint info) and allow subsequent log-ins using just a username and password. Such a site might be visited infrequently (perhaps only every month or two), and having to do the highly secure login method every time would be frustrating.

Overall, I think that the "first party" heuristic for interaction is the right one. Setting a timer between successive first-party interactions seems plausible, but needs to be calibrated right.
Whiteboard: [necko-would-take]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.