Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Txp cookies, visitor logging, and GDPR stuff in general
What I still find kinda funny about all this is that in order to opt out of any cookies being stored on a site, a cookie needs to be stored. The domain controller (site owner) has access to that information. That, potentially, has personally identifiable content or at the very least can be used to “profile” groups of people who have opted out per geographic region.
So is it now implicit that the act of saying “no” to cookies is also a “no” to profiling of any kind? Or are they treated separately? Does the wording on all of those annoying banners that pop up (on every site every time you visit a site from a new private browsing session) need to reflect this, now that GDPR is upon us?
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Online
Re: Txp cookies, visitor logging, and GDPR stuff in general
gaekwad wrote #310792:
I’ve been using this with my clients, it’s the best explanation I’ve found to date: blog.varonis.com/gdpr-requirements-list-in-plain-english/
Thanks. That’s quite clear. Now I need to find something that clear in German.
Bloke wrote #310804:
What I still find kinda funny about all this is that in order to opt out of any cookies being stored on a site, a cookie needs to be stored.
That is the irony of it, yes!
The domain controller (site owner) has access to that information. That, potentially, has personally identifiable content or at the very least can be used to “profile” groups of people who have opted out per geographic region.
I’m not sure about this one. The cookie is stored in the visitor’s browser and if it only holds the “opt-out” information and nothing more (i.e. you don’t do anything extra on your site to track which site visitor IPs have opted in or out), then surely it has no personally identifiable content…
So is it now implicit that the act of saying “no” to cookies is also a “no” to profiling of any kind? Or are they treated separately? Does the wording on all of those annoying banners that pop up (on every site every time you visit a site from a new private browsing session) need to reflect this, now that GDPR is upon us?
From what I’ve read, each kind of use of personal data has to be explicitly agreed to, so a) you have to opt in to any tracking that is not totally anonymous, not just “using this site implies agreement” and b) other uses also need agreeing to separately. So the default should be “no personal tracking” and I presume the wording will need changing in many cookie usage messages.
I’m a bit hazy on the specifics but my understanding is that you only need explicit permission for uses that hold potentially personalisable information. So cookies used purely for the visitors’ site navigation and use that you do not connect to anything personalisable should stay “under the radar”.
A murky area, however, might be if you want to track the relative proportion of people who have opted out versus those whose visits are logged in your webstats, to obtain a measure of how representative your site stats are of your visitors overall. Even if you anonymise that so that all you have in the end is “these web stats apply to N% of the site’s visitors”, are you not contravening the user’s wish not to be tracked?!
FWIW: In Germany, the EU cookie directive has not – until now – been converted into German law (they’re lagging behind here), so those warnings are less prevalent on German sites!!
I know many people here think web stats are pointless but for organisations/non-profits who don’t sell things, it’s one of the few ways of measuring and documenting the “success” and value of their website (and of the need for website updates) to their membership.
TXP Builders – finely-crafted code, design and txp
Online
Re: Txp cookies, visitor logging, and GDPR stuff in general
jakob wrote #310806:
A murky area, however, might be if you want to track the relative proportion of people who have opted out versus those whose visits are logged in your webstats, to obtain a measure of how representative your site stats are of your visitors overall. Even if you anonymise that so that all you have in the end is “these web stats apply to N% of the site’s visitors”, are you not contravening the user’s wish not to be tracked?!
That’s precisely what I was getting at. You can “profile” people based on whether they opted in or out of cookies by virtue of them having a cookie stored on their computer (that the domain controller can access) saying they don’t want to be tracked.
Whether or not it’s personally identifiable, the act of consenting (or not) to cookies leaves the possibility of aggregating that info and may come under the banner of ‘profiling’. Even if that is just, as you say, to judge the success or not of page visits to help clients improve their site wording for better engagement.
And let’s not get into A/B split testing eh?!
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Online
Re: Txp cookies, visitor logging, and GDPR stuff in general
jakob wrote #310806:
I know many people here think web stats are pointless but for organisations/non-profits who don’t sell things, it’s one of the few ways of measuring and documenting the “success” and value of their website (and of the need for website updates) to their membership.
I probably give that impression with my wood-palette proselytizing. But much of that is in context of my own pithy websites.
You’re right, and I’m well-aware, that analytics are important readings for other needs. And this is where it’s going to be very interesting to see what strains through 24 months of GDPR being in effect. Some sites use analytics for reasonable/necessary operational purposes, while others (media sites, as one notable example) load their sites excessively with so much tracking BS, largely because they’ve given their souls to ad agencies and our data to brokers.
Offline
Re: Txp cookies, visitor logging, and GDPR stuff in general
The one thing that’s got me confused at the moment in relation to Txp is the Visitor logs panel, and where IP address data falls on the scale of what’s “identifying” data or not in relation to GDPR. If IP data is remotely considered an opt-in data type, then the Visitor logs functionality will essentially become obsolete because nobody will opt-in to have their visits logged. Why would they?
Could the Visitor logs be extended to only log non-human visits? (Spam tech, bots, etc) so that it’s at least providing some value? I’ve never used it for that reason but maybe somebody has and would like to keep doing so.
If not, let me ask the elephant in the room question: Should Txp drop supporting the Visitor logs functionality and leave it to site Controllers to decide for themselves whether or not to install/use third-party tracking technology? Or maybe this is a rare instance where core functionality is removed to become a plugin. Not a bad idea, actually.
It kind of makes sense to me… Takes the hazy middle ground out of the equation. I, or anyone, could then say matter-of-factly: “We do not have software installed than can track you. Period.”
Maybe that’s a question for a new thread in Core topics? Let me know and I can repost.
Offline
Re: Txp cookies, visitor logging, and GDPR stuff in general
Bloke wrote #310804:
What I still find kinda funny about all this is that in order to opt out of any cookies being stored on a site, a cookie needs to be stored.
In fact, you can’t store cookie unless your visitor has given you explicit permission to do so.
The EU cookie banner is dying in favor or a more granular and “just-in-time” way to opt-in.
There’s a lot to say about GDPR, I don’t have time now to read and react to the rest of the thread.
Offline
Re: Txp cookies, visitor logging, and GDPR stuff in general
Destry wrote #310811:
Could the Visitor logs be extended to only log non-human visits? (Spam tech, bots, etc) so that it’s at least providing some value? I’ve never used it for that reason but maybe somebody has and would like to keep doing so.
How would you differentiate? Query the user agent? Measure rate of moving around on the site? Compare origin with a spam blocklist in real time?
If not, let me ask the elephant in the room question: Should Txp drop supporting the Visitor logs functionality and leave it to site Controllers to decide for themselves whether or not to install/use third-party tracking technology? Or maybe this is a rare instance where core functionality is removed to become a plugin. Not a bad idea, actually.
-1 from me. Intranets, geographically-fenced extranets and some territories where GDPR (or similar) just doesn’t apply are all perfectly valid environments for Textpattern.
It kind of makes sense to me… Takes the hazy middle ground out of the equation. I, or anyone, could then say matter-of-factly: “We do not have software installed than can track you. Period.”
Turn logging off inside Textpattern, done. If it’s off, there’s no logging, and within the confines of the site CMS, something the Operator (I do like this choice of term, btw) can confirm is done and no longer be liable.
…but just because internal logging is off, that just moves it up the tree – the web host will typically store data about who accesses what, either for auditing, compliance, poops-and-giggles, and then any proclamation – while virtuous – is sorta worthless at the same time.
Textpattern logging is disabled out of the box, which is fine. It can be turned on, and if there’s sufficient proof that setting Logging to None doesn’t actually store anything identifiable, and the code is readily audit-able, that’s Job Done. Anything beyond this is overreaching, in my humble.
Offline
Offline
Re: Txp cookies, visitor logging, and GDPR stuff in general
This whole thing reminds me a lot of COPPA, the Children’s Online Privacy Protection Act passed here in the US in 1998.
For those of you who don’t know, COPPA required parental permission for anyone under 13 to sign up for online services. That is why to this day most sites just blanket ban children below that age from signing up. And the net result has been that children often lie, sometimes with their parent’s encouragement..
It will be interesting to see if any sites ban EU users.
Offline
Re: Txp cookies, visitor logging, and GDPR stuff in general
Destry wrote #310800:
But, Michael, I don’t know if your free advertising for YouTube and Denise is warranted. ;)
All I did was link to the video. FluxBB has a feature that turns any standard link into an embed.
"This Week in Law 418: FOMO Re EU":https://www.youtube.com/watch?v=WGUSXb7FeiAOffline
Re: Txp cookies, visitor logging, and GDPR stuff in general
etc wrote #310814:
That’s nearly illegal indeed and not true anymore, hope nothing is broken.
Excellent – now the “Remember me” setting is opt-in. Thank you.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Txp cookies, visitor logging, and GDPR stuff in general
gaekwad wrote #310813:
How would you differentiate? Query the user agent? Measure rate of moving around on the site? Compare origin with a spam blocklist in real time?
That’s why I asked could it be done, Pete. So I guess what you mean to say is, ‘no, it can’t be done because it’s impossible to differentiate the referrals.’
So now the context of discussion switches to full functionality as a plugin.
-1 from me. Intranets, geographically-fenced extranets and some territories where GDPR (or similar) just doesn’t apply are all perfectly valid environments for Textpattern.
Intranets/extranets sound like low uses cases considering Txp’s relatively low uptake in the wild. You might find a lot of SharePoint, on the other hand. ;) Likewise with popularity in odd regions of the world. But regardless whether there are 1 or 1 million Txp intranets, that doesn’t obviate adding the functionality as a plugin.
Turn logging off inside Textpattern, done. If it’s off, there’s no logging, and within the confines of the site CMS, something the Operator (I do like this choice of term, btw) can confirm is done and no longer be liable.
Yes. This is the obvious status, under the circumstances, for any controller (the term, btw, if you mean site owner) who wants to do the most they can for piece of mind.
But if it’s left off forever, I guess one could ask, what’s the point of it being there at all like a boneless thumb?
…but just because internal logging is off, that just moves it up the tree – the web host will typically store data about who accesses what, either for auditing, compliance, poops-and-giggles…
Fine. “It’s not in my tree anymore,” as the thinking would go. At that point one can switch from saying…
“I don’t have logging on in the CMS, which provides the functionality OOB, and you’ll just have to trust that I’m not using it.”
To…
“I definitively do not have any technology installed that can track you, even if I wanted to flip it on for a few yours at rush hour.”
Yes, I’m exaggerating these lines to make the distinction clear.
Btw, here’s another honest question: If a Txp site has logging on, can a site visitor tell that by any measure or tool?
If not, then you see how trust really comes into the equation. And trust is running low on the web these days. How would that be policed? Hell if I know. I’m only speaking to eliminate any worry about it.
…and then any proclamation – while virtuous – is sorta worthless at the same time.
Is it worthless, though? Which one of those statements above would you prefer to see as a gun-shy web user these days?
Textpattern logging is disabled out of the box, which is fine. It can be turned on, and if there’s sufficient proof that setting Logging to None doesn’t actually store anything identifiable, and the code is readily audit-able, that’s Job Done. Anything beyond this is overreaching, in my humble.
Your confidence suggests your grasp of the GDPR nuances are better than mine. If it’s really “job done” to satisfy them by simply turning logging off, then good. There’s a least peace in the jungle. ;)
But I’m not sure logging as a plugin option for a Controller would be “overreaching”. More work, certainly, but not totally pointless.
Offline