Talk:Cookies:prompting ui

As far as I can tell, there is no value in rejecting a cookie. If a cookie is session only it can't be used to track users anyway, so what's the use case of rejecting (compared to making session-only)?

Private Browsing mode already makes this assertion: since cookies are session only, it doesn't offer complete cookie rejection.

If "reject" would be removed from the list of choices then suddenly a lot of things get easier: 1. A dialogue with two options "accept" and "accept for session only" no longer needs to block 2. Therefore it can be changed into info bar! :)

So, how about the following UI: two options in Options, "accept all cookies" and "ask before storing a cookie".

"accept all cookies" is like current default: session cookies are accepted, permanent cookies are accepted & saved.

"ask before storing a cookie" operates like this: accepts session cookies without asking. But when a permanent cookie is created, it's initially accepted as session cookie (therefore not blocking pageload) with an info bar asking if the user accepts it. If the user rejects (or doesn't answer), it stays as session cookie. If a user accepts a save, it gets saved permanently.

A possible third option would be "ask for third party only" which would only show the info bar for third party permanents.

This would retain current full control (except possibility of complete cookie rejection, which is useless) while making the UI usable. Not even hard-core micromanagers should complain.

Session cookies can track users

About the first paragraph above:

As far as I can tell, there is no value in rejecting a cookie. If a cookie is session only it can't be used to track users anyway, so what's the use case of rejecting (compared to making session-only)?

Many users run sessions that last days or even weeks without restarting the browser. So even session cookies can often be used to track users. paepse 10:47, 21 January 2009 (UTC)