Helping ckbk Remove Ad Tracking

Originally published at: Helping ckbk Remove Ad Tracking - TidBITS

It pays to speak up. After being introduced to the ckbk cookbook service, Adam Engst expressed his disappointment in the app asking to track and was rewarded a few weeks later with an update that resolved the issue.

1 Like

Have you considered just disabling tracking all together, or are you using this more as a means to track the trackers? :blush:

Precisely! I let apps ask if they can track me rather than just denying it so I can see how prevalent it is and which companies are engaging in it.

1 Like

Is your conclusion anything other than “everybody everywhere all the time”?

That’s what it seems like to me. Even my own personal blog tracks me because it’s hosted by Google’s / service. :face_with_symbols_over_mouth:

Yes, actually. There are quite a few apps that ask to track, but it’s only a small percentage of all those that I have.

1 Like

A couple of years ago I started using some tracking blocking features in Firefox (Mac, not iOS) and soon ran into problems getting access to many web sites by things like unsolvable Captchas. I did some digging around and found that tracking results are being widely used in security systems, so if they don’t have any tracking data for you, you are considered a risk and likely to be blocked. At that point, I decided that blocking all or most tracking could cause more trouble than it was worth, although I do block some tracking, particularly location when not necessary (e.g. by banks).

I don’t use a smartphone, so I don’t know what’s going on with apps, but from what has been described so far, it looks lime many are asking for much more information than they need. I wonder how much they are used in security systems.

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!

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 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 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 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:

1 Like