Self-destructing Cookies — Feature Request: 1st- VS. 3rd-party cookies

Add-ons for Pale Moon and other applications
General discussion, compatibility, contributed extensions, themes, plugins, and more.

Moderators: FranklinDM, Lootyhoof

VLMin
Astronaut
Astronaut
Posts: 535
Joined: 2015-10-20, 17:20
Location: Earth

Self-destructing Cookies — Feature Request: 1st- VS. 3rd-party cookies

Unread post by VLMin » 2018-12-14, 06:55

I am currently using two cookie-related extensions, SD Cookies and Cookie Controller. I am experiencing behavior that I find undesirable. Here is my intended setup:

1. PM custom cookie settings in Preferences > Privacy:
. Allow sites to store cookies and data CHECKED
. Accept third-party cookies NEVER
. Allow cookies to remain UNTIL I CLOSE PALE MOON

Thus, ALLOW ONLY 1ST-PARTY COOKIES AND DISCARD AT END-OF-SESSION is my (intended) PM default setting, before extensions.

I then use SD Cookies to modify the retention period of cookies, the default, of course, being to destroy each site's cookies after closing its tabs rather than waiting for end-of-session. Sometimes, to get a site to work, I use SD Cookies change the cookie retention period to SESSION (delete at end-of-session) or to ALLOW (never delete). When SD Cookies is installed and Cookie Controller is not installed, this all works as intended.

When needed to interact satisfactorily with a site, I use Cookie Controller to ALLOW 3RD-PARTY COOKIES or, when necessary, to DENY COOKIES altogether. However, this is not done explicitly: to allow 3rd-party cookies for a specified site, one must invoke either SESSION or ALLOW (permanent cookies).;

(As with SD Cookies, I sometimes use Cookie Controller to change the cookie retention period to SESSION (delete at end-of-session) or to ALLOW (never delete). This is not the source of the problem I am experiencing.)

From my perspective, it seems that first two abovementioned actions — allowing 3rd-party cookies and denying cookies — ought to be possible explicitly and independently, without affecting SD Cookies. In fact, when Cookie Controller is installed and SD Cookies is not installed, this all works as intended.

Before continuing, I wish to communicate crystally clearly why I use both of these extensions together:
  • SD Cookies automatically destroys cookies sooner than any PM policy to which I have access.

    Cookie Controller makes it possible for a user to enable 3rd-party cookies or to deny all cookies to specific sites, albeit implicitly.
Each of these features is unique, within this setup, to only one of these extensions. My request to the SD Cookies developer it to add the capability to specify 1st-party-only or 1st+3rd-party cookies independently, without impacting the self-destruct timing settings and without impacting the PM custom (user-specified default) cookie settings.

Following are notes about what happens with both extensions installed together, in the hope that these might prove useful.

When both extensions are installed together, here is what DOES work:

1. When I use Cookie Controller to change the site cookie setting to ALLOW and reload the page, SD Cookies matches by changing its setting to ALLOW.

2. When I use Cookie Controller to change the site cookie setting to ALLOW 1st-PARTY ONLY, SD Cookies matches by changing its setting to ALLOW.

3. When I use Cookie Controller to change the site cookie setting back to SESSION and reload the page, SD Cookies matches by changing its setting to SESSION.

4. When I use Cookie Controller to change the site cookie setting to DENY, SD Cookies responds by changing its setting to destroy site cookies AFTER YOU CLOSE ITS TABS, which works because no cookies for the specified site are ever permitted.

5. When I use SD Cookies to change the site cookie setting to ALLOW, Cookie Controller complies (without requiring a page reload).

6. When I use SD Cookies to change the site cookie setting back to SESSION, Cookie Controller again complies, again without reloading the page.

When both extensions are installed together, here is what DOES NOT work:

7. When I use SD Cookies to change the site cookie setting to destroy site cookies AFTER YOU CLOSE ITS TABS, Cookie Controller responds by changing its setting to the PM default cookie setting, 1st-PARTY COOKIES ALLOWED, destroyed on END-OF-SESSION. Thus, changing the SD Cookies setting causes 3rd-party cookies to be blocked, as specified in the PM custom cookie settings; the implicit override is eliminated.

8. When I use SD Cookies to change the cookie site setting to ALLOW, Cookie Control responds by changing its setting toward the PM default cookie setting, 1st-PARTY COOKIES ALLOWED BUT NOT destroyed on END-OF-SESSION. Once again, 3rd-party cookies are blocked.

Well, hopefully I’ve communicated enough to convey a clear picture: enabling the user to toggle between 1st- and 3rd-party cookies for any specified site, independent of cookie-destruction timing settings, would enhance users’ ability to regulate their own exposure to cookie-based privacy intrusions. I believe that offering this complete set of capabilities in a single extension would ensure inter-feature compatibility better than having distinct extensions. Of course, this would also enable any users who employ the Cookie Controller extension, which remains a Firefox / non-PM extension, to terminate their use of it. But that's a secondary benefit; the primary benefit is increased user control over 1st/3rd-party cookies concurrent with increased user control over cookie destruction/retention.

Who knows, perhaps the resulting extension might be named "Cookie Power!". :clap:

Thanks to everyone who has read this rather long post.

Best to all!

User avatar
Night Wing
Knows the dark side
Knows the dark side
Posts: 5151
Joined: 2011-10-03, 10:19
Location: Piney Woods of Southeast Texas, USA

Re: Self-destructing Cookies — Feature Request: 1st- VS. 3rd-party cookies

Unread post by Night Wing » 2018-12-14, 10:55

The two extensions you're using and want help with, (SD Cookies, Cookie Controller), why did you not include the links to the two extensions where you got these extensions from? I looked at the Pale Moon extensions link below and these two extensions are not listed.

https://addons.palemoon.org/extensions/
Linux Mint 21.3 (Virginia) Xfce w/ Linux Pale Moon, Linux Waterfox, Linux SeaLion, Linux Firefox
MX Linux 23.2 (Libretto) Xfce w/ Linux Pale Moon, Linux Waterfox, Linux SeaLion, Linux Firefox
Linux Debian 12.5 (Bookworm) Xfce w/ Linux Pale Moon, Linux Waterfox, Linux SeaLion, Linux Firefox

VLMin
Astronaut
Astronaut
Posts: 535
Joined: 2015-10-20, 17:20
Location: Earth

Re: Self-destructing Cookies — Feature Request: 1st- VS. 3rd-party cookies

Unread post by VLMin » 2018-12-14, 15:43

Thank you for responding to my inquiry. I apologize for this oversight.

Self-destructing Cookies is on the PM Extensions page.

To my knowledge, the best place to find Cookie Controller is via the Classic Archive extension. First install the archive extension, then type "Cookie Controller" in its search box.

Goodydino
Keeps coming back
Keeps coming back
Posts: 820
Joined: 2017-10-10, 21:20

Re: Self-destructing Cookies — Feature Request: 1st- VS. 3rd-party cookies

Unread post by Goodydino » 2018-12-14, 20:42

I do not see how you could change the expiry time of a session cookie. Session cookies are distinguished from persistent cookies by having no expiry date or time.

VLMin
Astronaut
Astronaut
Posts: 535
Joined: 2015-10-20, 17:20
Location: Earth

Re: Self-destructing Cookies — Feature Request: 1st- VS. 3rd-party cookies

Unread post by VLMin » 2018-12-14, 21:06

Goodydino wrote:I do not see how you could change the expiry time of a session cookie. Session cookies are distinguished from persistent cookies by having no expiry date or time.
I agree, and that is not my request. My request is to integrate the distinction between 1st- and 3rd-party cookies into the existing SD Cookies framework in a way that the one is unlinked from the other. In other words, 1st/3rd-party cookie and cookie retention/destruction policies could be implemented independently, each without affecting the other. I believe this would constitute a discernible improvement in overall privacy protection.

Hopefully, I convey increasing clarity as this discussion progresses.

Locked