TidBITS cookies

While we’re on the subject of tracking and the skepticism it triggers, I always notice (and similarly, grumble under my breath), that TidBITS own website has a heavy-handed cookie notification with only one “choice”: “Close and Accept”. Unlike most sites, which provide the ability to opt-out of non-essential cookies, TidBITS appears to require accepting all cookies without sharing what more information about what they do. And while I appreciate the colloquial tone of your cookie message, it’s vague. I can see how newer readers might find that to be equally suspicious - just saying!

1 Like

TL/DR: Looking at the cookies generated by TidBITS and TidBITS Talk, they all fall into three categories:

  • Google Analytics
  • WordPress (for TidBITS). Looks like just the minimum necessary to track your login state
  • Discourse (for TidBITS Talk). Looks like the minimum necessary to track your login state.

And now the ugly details of what I dug up and what I could figure out. Sadly, this is far from complete:

The following four cookies appears on both TidBITS and TidBITS Talk. These are Google Analytics cookies. Since both belong to the .tidbits.com domain, I assume I’m actually seeing the same cookies on each site:

  • _ga_##### - Has a value of the form GS1.1.####.... According to Google this is the persistent session state.

    The ##### in the cookie name is a container ID. The GS1.1. prefix indicates the Google Analytics version. Followed by a Unix timestamp (for today). Followed by two numbers I don’t understand (35.1) followed by another Unix timestamp (about 15 minutes later than the first).

  • _gat - Has the value 1. Don’t know what this means

  • _ga - Has a value of the form GA1.2.####.... According to Google, this is a user ID. The GA1.2. prefix is their Universal Analytics system. It is followed by a random number and a timestamp (in my case, November 2022. So that’s probably how long Google’s been tracking me with this ID)

  • _gid - Has a value of the form GA1.2.####..., but different from the _ga value. Probably the same general idea - a random ID number and a timestamp. This timestamp is for two days ago, so it may be for tracking more recently-changed data.

The following cookies only appear on the TidBITS site (not on Talk). They belong to the tidbits.com domain (note: no leading ., so subdomains are not included). These appear to be WordPress cookies:

  • eucookielaw - Has a 13 digit number. it appears to be a Unix timestamp, in millisecond resolution. In my case, it’s for June 3, 2023. So it’s probably an expiration date of some kind (after which you need to re-click on a cookie notice?)

  • PHPSESSID - A session cookie (expires when the browser is closed). The value is 26 seemingly random alphanumeric characters.

    It is used by WordPress to provide a persistent session ID for PHP scripts. I assume TidBITS has some server-side PHP which requires this cookie.

  • pmpro_visit - Another session cookie. This is part of the Paid Membership Pro WordPress plugin. I assume this is how TidBITS runs the paid-membership site features.

  • wordpress_logged_in_####. This cookie (and its value) appear twice - once for the / path and once for the /wp/ path. These are your WordPress login cookies - they are created after you log in and should be deleted when you log out.

    It is a URL-encoded string of the form: name|timestamp|user hash|other hash, where:

    • name is my WordPress user ID
    • timestamp is a 10-digit decimal number. It appears to be a UNIX timestamp value. In my case, representing a time on November 9 2023. So maybe that’s when the login will expire?
    • user hash is a 43-character alphanumeric string representing a hash of something, but I don’t know what. Given that this string appears in another WordPress cookie, I assume it’s related to my WordPress account.
    • other hash is a 64 character alphanumeric string, but I don’t know what it means
  • wordpress_sec_####. This is almost the same as the wordpress_logged_in_#### cookie. It’s another URL-encoded string of the same form, with the same values for the name, timestamp, and user hash fields, but a different value for the other hash field.

    Given it’s name, I assume this is part of WordPress’s security system. It is for the /app/plugins path. There is unfortuntely very little documentation about this cookie.

  • wp-settings-time-#####. The number in the cookie is your WordPress ID. Web searches are claiming that the value stores preferences for the WordPress personal dashboard settings. But I don’t believe them, because the value is a number that very much looks like a Unix timestamp (in my case, corresponding to December 5, 2022, which I think was the last time I changed my dashboard settings).

The following cookies only appear on the TidBITS Talk page. They belong to the talk.tidbits.com domain and are created by the Discourse software:

  • _forum_session. This is a session cookie. According to Discourse, this is the session cookie and is created when the page is loaded.

    It is a URL-encoded string that decodes to 332 characters of alphanumeric data. And the characters are not Base-64 encoded. It appears to be structured data (there are several / characters that appear to be delimiting blocks of content.

    I noticed that this cookie changes a lot. Every few seconds, so it may be related to the scripts that keep the screen up to date as the site changes. Probably as a result of refreshing various bits of content.

  • _t. This is the Discourse user-authentication token. It is created when you log in and is deleted when you log out. Its expiration date is configurable by the site, with a default of 60 days.

    It’s a URL-encoded string that decodes to 324 characters of alphanumeric data. It also appears to be structured data (the / characters).

See also:


Huge thanks for listing those out, @Shamino! @joe5, the cookie notice is vague because it’s already too long, but you can read more about all those cookies in our privacy notice, linked at the bottom of the TidBITS site.

Basically, the only cookies we have are WordPress, Paid Memberships Pro, Discourse, and Google Analytics. I don’t care what cookies anyone accepts or rejects since they’re all functional—our sites might not work properly, but that’s the user’s problem. The closest we come to tracking is basic Google Analytics (which I’m considering dropping at some point too).

1 Like

You can use Wordpress’s Jetpack for analytics if you still want to get some basic stats. I don’t know what the impact is on cookies, but it’s at least one less external dependency so makes management cleaner/easier.

My annoyance is that I get this prompt almost every time I visit TidBITS (but not Talk).

Is there a reason that the acceptance doesn’t persist for an extended for a period, e.g., a month? Am I the only person being asked to accept cookies nearly every session?

And I do use Jetpack for stats too—it’s the reason I’d be able to turn off Google Analytics. What’s stopping me is that I rather like having all the historical data so I can see how things have changed from current times.

It’s supposed to appear again only after 180 days, and I’ve just upped that to 365. I suspect it can only stay hidden if there’s a cookie set, ironically, so if you do something to clear cookies or even use another browser, it will come back.

If you’re logged in, I don’t think you’ll see it, and that will also hide some ads if you’re a TidBITS member.

1 Like

That’s the eucookielaw cookie. I just tried deleting it and the notification popped up on the next page-reload.

Makes sense, thanks—a WordPress cookie set by Jetpack.

It’s probably Safari’s Intelligent Tracking Protection (ITP). If you don’t visit tidbits.com for a week, that device discards cookies set by JavaScript (vs. being sent in a server response), regardless of the expiration date set; I don’t know if using iCloud to sync Safari would mean visiting tidbits.com from any device within a week would keep them “fresh” on all devices.

The cookies will last longer in different browsers on a Mac. This article seems like a good summary: How Different Browsers Handle First-Party and Third-Party Cookies.


My grumble is that the cookie storage seems to grow without bound. Right now, I have 7.8 MB of TidBITS cookies, and it increases with each visit. While i realize this is small potatoes in the modern world, I have not made the emotional adjustment from life with single-sided 5.25 inch floppy disks, and I’m jealous with my bytes. (For comparison, the site with the second largest cookie storage has 111 KB, and I think that’s excessive.)

When the TidBITS storage hits 10 MB, I delete all TidBITS cookies. Other than needing to present login credentials, I notice no effect on my user experience. What does multi-MB cookie storage do for TidBITS?

1 Like

10 MB of cookies seems high. Possibly the number includes the browser’s cache? The browser cache of images/pages would be expected to grow until the browser decides to trim it.

When I examine the cookies/local-storage for TidBITS I see around 1,230 bytes - that’s about 16 punch cards or 10 feet of paper punch tape!


That seems likely. Firefox shows the information in a subset of “Cookies and Site Data” in its Preferences, and Site Data could reasonably include cache.

I just checked, and “Firefox > Preferences > Privacy & Security > Cookies and Site Data > Clear Data…” offers two choices, “Cookies and Site Data” and “Cached Web Content”. It is after clearing “Cached Web Content” that “Firefox > Preferences > Privacy & Security > Cookies and Site Data > Manage Data…” indicates that TidBITS is using megabytes of storage. In other words, Firefox implies that the storage does not include cache.

If you visit TidBITS, open Firefox’s Web Developer Tools and look at the Storage tab, you can see exactly what cookies are stored and what they contain.

1 Like

Thanks, and wow.

I cleared Cached Web Content in Preferences. Then, under Cookies, there were four items, with sizes 476, 52, 30, and 362. Since no units were specified, I assume those were bytes. Under Cache Storage (“discourse-1” at a lower level), there were many many items but none of them indicated a size. Under Indexed DB (“cache-entries” at a lower level), there were many many entries but none of them indicated a size. Local Storage had five entries but no sizes, and Session Storage had no entries.

Firefox > Preferences > Privacy & Security > Cookies and Site Data > Manage Data… showed TidBITS had 7.9 MB storage.