0.3rc5 breaks protected cookie update and deletion (expiration) by sites about cookie-quick-manager HOT 8 CLOSED

This is a CQM 0.3rc5 regression. Sites can not alter protected cookies (which includes deletion)

from cookie-quick-manager.

Hi, according to my tests, the cookie management Web API does not allow to explicitly ask for the deletion, or modify an already expired cookie by setting a date in the past.
However the deletion is indeed explicit with a date in the past for unexpired cookies.

This behavior (weird) is the responsibility of Firefox. It is indeed weird that a removal request by a site of an expired cookie must first update it with a future expiration date and then an update it with a past date.

I see that if you wish to make this explicit deletion request on a valid and protected cookie, the old cookie is instantly restored (i.e all its attributes). But you can update an expired or unexpired cookie by giving a future expiration date and a new value.
This behavior seems to be logical since the role of protection is indeed to avoid the removal of cookies under surveillance.

Does this answer your questions?

from cookie-quick-manager.

No, I don't think you understood what I am reporting.

In 0.3rc5 sites can not update or delete protected cookies.
In 0.3rc4 they can.

This is a major bug in the protected feature, the whole point of which is to whitelist cookies. Cookies are supposed to be protected from deletion by CQM itself on startup, not the sites that created them.

from cookie-quick-manager.

Ok there is misunderstanding here; the fact that the protection lets sites delete their own cookies was not wanted and was repaired in version 0.3rc5.

Without going into details, the addon listens Firefox events of explicit deletion (not those related to a modification), however it is impossible for me to know if the deletion was requested by the consulted site or by the use of the function cookie.remove() of the API.

Only the behavior of the protection against deletion has been changed between 0.3rc4 and 0.3rc5.
Updating cookies has always been possible with or without protection.

Here is a code to test this behavior with/without the cookie protection in the JavaScript scratchpad:

function create_cookie(name, value, date, path) {
  var expires = date.toUTCString();
  document.cookie = name + '=' + value + ';' +
                   'expires=' + expires + ';' +
                   'path=' + path + ';';
}

// Create a cookie with a valid expiration date
var cookie_name = 'test_cookie';
var cookie_value = 'val';

var date = new Date();
date.setTime(date.getTime() + 60000);

create_cookie(cookie_name, cookie_value, date, "/");


setTimeout(function() {
  // Update its value only , 6 secs later
  // => ok with/without cookie protection
  cookie_value = 'updated_val';
  create_cookie(cookie_name, cookie_value, date, "/");
}, 6000);


setTimeout(function() {
  // Set a past expiration date, 9 secs later
  // => delete the cookie if the protection is disabled
  // => do not delete the cookie with protection enabled
  // => do nothing if the cookie is already expired
  var date = new Date();
  date.setTime(date.getTime() - 10000);
  cookie_value = 'updated_val2';
  create_cookie(cookie_name, cookie_value, date, "/");
}, 9000);

PS: There is a display bug, when there is no more cookie in the selected domain: it remains displayed instead of disappearing, I will fix that.

from cookie-quick-manager.

fact that the protection lets sites delete their own cookies was not wanted and was repaired in version 0.3rc5.

First of all it's not merely deletion. Deletion is merely the special case of setting, where the expiration is set to the past.

The way it worked in rc4 is precisely the cookie whitelisting behavior that was implemented in CookieKeeper/CookieCuller and why I started using CQM as a replacement.

The idea is pretty straightforward and logical. You whitelist specific cookies, with everything else auto-deleted (on startup and/or shutdown and/or periodically). The sites can still set/delete their own cookies, you only need to protect the auto-deletion from your own code.

Please restore the whitelisting functionality I described. It can be optional, since you prefer the current behavior and should be pretty trivial since it was already working in rc4 (only protecting from your own deletion on startup)

from cookie-quick-manager.

First of all it's not merely deletion. Deletion is merely the special case of setting, where the expiration is set to the past.

Yes

The sites can still set/delete their own cookies, you only need to protect the auto-deletion from your own code.

Ok, this is a feature that can be implemented with an option to choose.

from cookie-quick-manager.

This issue will be fixed in the next release, feel free to reopen it if there is still a problem :)

from cookie-quick-manager.

thanks

from cookie-quick-manager.