eTags, pixel tags, beacons, etc

Destry · 2018-04-26 09:43:56

I’ve never given these concepts much thought before. I don’t even know if they are all the same. Not being a developer, it’s hard to tell from what I’m reading. Colak first brought eTags to my attention in the other thread on GDPR and nobody really replied to my inquires about it. That thread has become very long and sinuous, and not very focused at this point but for general comments about the GDPR itself. I’d like this thread to focus specifically on these kinds of tags to understand them better and how they may or not need to be dealt with in privacy policies. At the very least, I’d like to be able to say I’m not using them, but I need to understand them better first, and whether anything applies to Txp.

First some background reading. Again, I’m not clear on the difference yet, so I’ll just list a few things based on labels. But the fact Wikipedia has separate pages suggests there may be differences between at least eTags and web beacons.

eTags (entity tags)

eTags (Wikipedia)
Cookieless cookies
Flash Cookies and Privacy II: Now with HTML5 and ETag Respawning (HTML abstract ; full PDF article download, 1.7MB)
ETag (Mozilla Developer)
AOL, Spotify, GigaOm, Etsy, KISSmetrics sued over undeletable tracking cookies

In summary of entity tags, they seem to be an acceptable (but optional) W3C http / 1.1 header [‘headers used with entity tags are described in sections 14.19, 14.24, 14.26 and 14.44. The entity tag MAY be used for comparison with other entities from the same resource, see section 13.3.3’], also html header (though attitudes about it’s use may be changing now), it’s accounted for in Apache, can be useful for reducing bandwidth thus page loads (i.e., cache tech)… By their nature, however, they’re invisible (can’t be detected by the average web user), thus they’re easily abused. For example, they can be made to be unflushable (undeletable), and there have been some major lawsuits as a result of using them for tracking reasons. They can be used to collect/record IP addresses, which we now know the GDPR considers a kind of “digital personal data” that can not be collected and processed without user consent.

With all that in mind, what I’m curious about is:

Does Txp use any such eTags?
Do any Txp cache plugins, or any other plugin types, use eTags?

I don’t use any cache plugins, only because I’ve been lazy, but I may not in light of GDPR if they employ eTags.

Ultimately I’m looking for a way to say “this site doesn’t use eTags, period,” but I just want to understand if that’s true, whether via my site or some tech I rely on (e.g. Apache). Are they inherent of web server logs?

Web beacons, pixel tags, web bugs …

Web beacons (Wikipedia)
W3C beacons, candidate recommendation
Mozilla implementation and Chrome implementation
Squeezing the most into W3C’s new beacon API
Did they read it? (warnings about beacons or “web bugs”)

Web beacons and the like seem to be different from eTags in implementation, but similar in being able to do sneaky things near undetected. They’re supported by industry standards bodies and browsers, but can be used for evil by shady software manufacturers and marketing companies. They especially seem to be dodgy in email use, where it’s easy to exploit non-techy types like my parents, and even those a little more aware (and lazy). The first two paras of Wikipedias notes on web mail beacons is enough for me to make sure I keep my mail in .txt-only mode with no allowance for downloading images from anyone. ProtonMail is good about this as a default.

So, again, I want to understand how I might indirectly be using these things, and if unavoidable by tech I might use, how to account for it in legal notes.

All thoughts on this topic welcome. Maybe we try to keep it focused on figuring out the nuts and bolts of compliance to GDPR?

I suspect this is one of those gray areas of web tech that is going to bite people hard in relation to the Regulation if controllers don’t really look at it; accounting for it properly in both implementation and their data policies.

etc · 2018-04-26 09:56:54

Destry wrote #311421:

With all that in mind, what I’m curious about is:

Does Txp use any such eTags?

Do any Txp cache plugins, or any other plugin types, use eTags? (I don’t use any cache plugins, only because I’ve been lazy, but I may not in light of GDPR if they employ eTags.)

Ultimately I’m looking for a way to say “this site doesn’t use eTags, period,” but I just want to understand if that’s true, whether via my site or some tech I rely on (e.g. Apache). Are they inherent of web server logs?

AFAIK, the only ETag sent by Textpattern is a last site modification date fingerprint. It is common to all visitors and contains absolutely no personal information. Independently of txp, servers can send ETags too, but I doubt they personify them either. Cache plugins do what they want, etc_cache does not track anything. We are clean :-)

Destry · 2018-04-26 13:12:37

etc wrote #311422:

AFAIK, the only ETag sent by Textpattern is a last site modification date fingerprint. It is common to all visitors and contains absolutely no personal information.

Good to know.

Can you explain how that works, exactly, for the likes of me? A conceptual walk-through of what happens/transfers in a typical situation, maybe?

Independently of txp, servers can send ETags too, but I doubt they personify them either.

Anonymized data (e.g. IP addresses) is okay, as it concerns the GDPR, but a specific statement should, ideally, still be made about it if the tags are used at all. Thus it would be necessary to know if the servers are doing that and how/why. (Maybe that’s a question for WebFaction in my case.)

Cache plugins do what they want, etc_cache does not track anything. We are clean :-)

Good to know. Thanks.

etc · 2018-04-26 14:41:30

Destry wrote #311425:

Can you explain how that works, exactly, for the likes of me? A conceptual walk-through of what happens/transfers in a typical situation, maybe?

Ha, wish I knew… Let’s say first that browsers and servers automatically exchange some preliminary information (headers) on each connection. Etag headers can be part of this information.

Now, roughly, when you visit a live txp site, it sends a fingerprint (something like 1dcn8cm) of the last modification date. Technically, it’s an Etag, but this is a detail. The browser stores it and sends back to the server on the next connection. If the values match, txp replies “304, nothing new, use your cache”.

So, theoretically, txp can detect if you have already visited the site, but not how many times neither who are you, since this Etag is common to all visitors until the next site modification. Actually, txp can get the same information from Last-Modified header which is not concerned by GDPR AFAIK. If you still mind, you can disable Send "Last-Modified" header? option, but both your site and your visitors will be penalized.

philwareham · 2018-04-26 15:27:18

You can simply add this to your apache httpd.conf file or a site’s .htaccess file to disable ETags:

<IfModule mod_headers.c>
    Header unset ETag
</IfModule>

FileETag None

More info: https://developer.yahoo.com/performance/rules.html#etags

etc · 2018-04-26 20:41:13

philwareham wrote #311433:

You can simply add this to your apache httpd.conf file or a site’s .htaccess file to disable ETags:

Would this also affect the ETags headers set by PHP?

Destry · 2018-04-27 20:31:41

etc wrote #311432:

Ha, wish I knew…

That’s a pretty good explanation, in any case. It’s all a bit like walking in thick fog for me, but every bit helps. ;)

you can disable Send "Last-Modified" header? option, but both your site and your visitors will be penalized.

Glad you brought that up. I’ve never really understood what that means, in fact. Some things I just whistle and look the other way about, hoping defaults don’t screw me. That’s one of them.

What is this penalty you speak of?

Bloke · 2018-04-27 21:06:00

Destry wrote #311486:

What is this penalty you speak of?

Performance. Every page load would then download every asset instead of caching them. Slow site, more bandwidth, poorer user experience.

Pick your potion: speed, throughput and bandwidth saving vs greater anonymity for visitors.

etc · 2018-04-27 21:18:25

Bloke wrote #311488:

Performance.

Server-side load too, since txp would need to process everything again, instead of just sending a 304 and exiting.

michaelkpate · 2018-04-27 21:22:58

Bloke wrote #311488:

Performance. Every page load would then download every asset instead of caching them. Slow site, more bandwidth, poorer user experience.

“Netscape 1.1 owed part of its speed advantage to its use of a cache. Every time it fetched a new file it stored a copy of it locally; if it got a request for the same file again, it would just check to see whether it had changed, and if not, use the copy stored in the cache. However, the cache tended to fill up with hundreds or thousands of small files. Netscape 2.0 uses a database to keep track of information about files in its cache, so that it spends less time wallowing around trying to figure out whether to display the cached file or fetch a new copy.” – Netscape 2.0 reviewed

So the goal of GDPR is return the Web back to the glory days before March 6, 1995, when Navigator 1.1 Beta was released. Fantastic.

jakob · 2018-04-27 22:26:13

So the goal of GDPR is return the Web back to the glory days before March 6, 1995, when Navigator 1.1 Beta was released. Fantastic.

Hmm, you took the cynical shortcut there. That’s the stuff of fake news headlines. And you’re usually so diligent in your reporting :-/

Destry · 2018-04-28 08:03:27

Okay. Thanks etc, Bloke… The fog is clearing.

Reading up on this list of headers is helping too. I see the ‘last modified’ part in there.

And here’s a fun toy, whatismybrowser.com, which shows what headers your browser is passing.

Reminds me of the Cookiless Cookie demo showing what ‘ETag(s)’ are passing. (Or something.)

Is there a way to easily see what headers a server passes back? Is that what servers logs are about then?

Rudimentary questions here, I know. Should have dug into this long ago.

Textpattern CMS

Textpattern CMS support forum

#1 2018-04-26 09:43:56