Helping ckbk Remove Ad Tracking

Article Comments
1

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
2

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

3

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
4

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 blogger.com / blogspot.com service. :face_with_symbols_over_mouth:

5

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
6

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.

7

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!

8

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:

1 Like