Txp cookies, visitor logging, and GDPR stuff in general

Bloke · 2018-04-10 23:33:53

So if we were to take this ‘remove logging from core’ seriously, this is what would probably need to happen:

Convert it to a Module, which is fancy speak for moving all log-related code into a self-contained unit of “stuff”.
“Stuff” in this case is:
- A table definition for txp_log that’s installed if you add the module to your Textpattern vendors/Module directory.
- Prefs that get inserted if you add the module.
- UI furniture to render the panel.
- Finding some way of injecting the panel link into the menu.
- Removing the current log_hit() functionality from core, and instead making the Logging module raise a callback where log_hit used to occur (or as near as dammit). Thus it switches the onus away from core saying “log every time a page is served”, onto the module advertising “I’m here, and every time a page is served, run this here function of mine.”

I think that’s it. Non-trivial, but doable. It’s pretty much the same as a separate plugin would need to do, with the difference being a plugin would be stored in the database instead of adding files to the filesystem in a known location.

Anyway, then we would have to find some way of distributing this Module (or plugin) – whatever that comprises; probably a directory full of code and config files – separately from core.

And the big problem is what happens to people who want to upgrade and retain this functionality. We can’t just delete the txp_log table on upgrade. We’d have to retain the table (you could delete it if you wanted). But if the module/plugin is missing, no further logging would take place to this leftover table until you installed the module and enabled it from prefs.

Then comes the bonus question: if we go with Modules, it’d be nice to modularise a lot of other stuff in the same vein: comments for one. A nice add-on would then be a Modules panel where you could see what modules are available and install them (i.e. download the code and install it) and enable/disable them. Think glorified plugins panel with access to a repo we control.

Sounds grand, right? So you want comments, you don’t need to faff with going to the repo and downloading it manually, you could enable its module, which gets the code and does the necessary installation steps on your behalf.

BUT, playing Devil’s Advocaat (sic) here, we then can’t offer Destry’s proposed assurance of “It’s not possible to do logging” because it is possible by visiting the Modules panel and enabling it. So we’re not gaining anything really. You can get compliance now by visiting the Prefs and setting Logging to “None”.

If, however, we don’t do this convenient Module panel for Logging and other modules, so each module you want requires a separate download/install step (by hand), it’s still “possible” to do logging by manually installing the code, so how is that any different from stating “it’s not possible?” The same goes if it was a plugin.

What’s the difference between:

“I’ve not installed the code that handles logging, therefore I’m not doing it on this site.”

vs:

“I’ve disabled the code that permits logging, therefore I’m not doing it on this site.”

vs:

“It’s possible to do logging in Textpattern, but the code to do so is available separately and I haven’t downloaded it, therefore I’m not doing it on this site.”

I can’t really see the distinction, sorry. If some troll/wannabe opportunistic money-grabber wants to try their hand, surely you still have to prove the absence of a txp_log table and code vs an empty txp_log table without code that runs to populate it? Making it a module doesn’t prevent logging full stop.

Surely the only way to avoid someone asking you to prove it, and to be able to assert that, would be if there were no Logging Module in existence, or no plugin available at all. i.e. we outlawed logging plugins.

Any plugin could do additional logging now. It’s one callback away. If we remove log_hit() and its associated code, logging is still one callback away. I can’t see how we can use any system – or lack thereof – to automatically remove the burden of proof. But it’s late and I might have missed something.

Last edited by Bloke (2018-04-10 23:36:17)

Bloke · 2018-04-10 23:49:36

This is kind of analagous to the TV licence thing in the UK. I don’t have a satellite dish. I don’t have an antenna (well, I do because the previous occupants left it on the roof, but it’s horribly disfigured due to storm damage, at a jaunty angle which is impossible to pick up a signal, and I’ve snipped the coax cable off that comes into the house). But I do have an Internet connection.

The BBC and licensing authority used to assert that if you had any equipment that was capable of receiving a transmission in real-time then you needed a TV licence. So if you had a VCR (showing my age here…) but no telly, you still needed a licence because you had the capability of recording the feed and going round a mates house to watch it on their screen.

I don’t pay for a licence because I don’t have the requisite equipment to receive a broadcast. I also don’t have iPlayer installed anywhere. So currently I don’t have a means to receive a broadcast, as they define it, in order to attract a licence fee. But I have the capability of doing so because I have an Internet connection. I fully expect the licensing authority to soon try and claim this is enough to warrant everyone needing a licence, regardless of whether they use the service.

I currently have to reaffirm every two years – self-certify – that I do not have a licence and have no desire to watch mainstream media streamed to my home. They always write back and say they don’t believe me and threaten to send someone round. I have a special baseball bat by the front door with “I don’t want no stinking TV feed” embossed on it just in case they ever do.

The point is, even though I don’t have the capability nor the desire to watch mainstream TV and have asserted this intent in my self-certified Privacy Policy (a.k.a. the form they periodically send me) many, many times over the last ten plus years, it’s still deemed by the TV licence trolls not enough proof that I don’t have it. Because, like, everyone needs TV, right? Thus the onus is still on me to prove it despite not having the capability to do so.

Destry · 2018-04-11 06:23:57

Bloke,

I agree the distinction between the three scenarios you gave is small. Some may argue there’s none. There’s a degree of trust that needs conveyed (or begged for) in this scenario from controller to visitor no matter what.

But where I think there’s a difference is in the idea of “intention” and “possession” by the installation of “third-party software designed for logging” (essentially what a plugin or mudule becomes). By not having any such logging software in core, it best communicates no intention to use such functionality because you don’t possess it, and that’s the strongest trust argument you can make, even if not 100% perfect. At that point any decision by the controller to install such functionally can be argued to be an intention to use, whether or not it’s turned on.

I like your TV analogy. Same in France. Here’s another one. You have 5 kilos of your favorite narcotic in your attic. You’re not using any of it (yet), but are the police going to believe you and leave you alone if they knew?

Intention. Possession. Why do you possess it if you don’t intend to use it? That’s what you leave them able to demand.

In the end, probably nobody will get in trouble for using Txp with logging turned off and being as forthright about it as they can. Because it’s not narcotics, or Giant Facebook, it’s a little harmless open sourse CMS, and most users of it have probably only had a dozen visitors in the life of their sites anyway. I’m just trying to show there is a difference that could be legally interpreted as much.

All that said, I like the idea of modules and a modules update panel, I think. Besides comments and logging, two modules I would never use, what others could there be? Multilingual?

Destry · 2018-04-11 07:21:48

Of course we could try and read the GDPR and see if Txp’s humble logging feature is even relevant. I’m not sure yet.

But this, from Article 4. Definitions

(1) ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person

Does an IP address factor into that somehow? Is there any data type collected in logging that does? Is the relationship accumulative rather than just direct? In other words, can an IP address be used in relation with other data from elsewhere on the website to then identify someone on a personal level?

If the answer to all that is no, then this may all be a moot discussion as far as Txp logging is concerned. But I wouldn’t bet the farm on it yet.

Note that “data subject” is indirectly defined there too, meaning the website user, but it’s not actually one of the main Article 4 defined terms. Still a definition, though.

This one is useful as it concerns contact forms:

(11) ‘consent’ of the data subject means any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her;

So the “clear affirmative action” would include situations like willingly choosing to use a contact form, thus transferring name, email, location, and whatever else might carry along in the packet/header info of an email. (What all is in those unfolded headers, anyway?)

Here’s another interesting one…

(18) ‘enterprise’ means a natural or legal person engaged in an economic activity, irrespective of its legal form, including partnerships or associations regularly engaged in an economic activity;

I’m not positive on this one, but “irrespective of legal form” could mean you don’t have to even be a business. If you’re just shuttling money between people (e.g. donations, pledges, etc) and using “third party (10)” technology, you’re likely subject to be compliant to these laws.

On the flip-side of that one, though, the emphasis seems to be on websites concerned with “economic activity”, which would certainly mean every business site, regardless of nature. But if you were just Jim-Bob blog owner with comments, contact form, and Txp logging turned on, you may not be of interest. But better safe than sorry.

In Txp’s case, as an open source CMS provider, it has a reputation to keep and may not want to put the onus on the data subject’s back about how to deal with logging. Provide them with a tool that’s safe out of the gates, and you earn the Good-Samaritan badge.

Which makes me wonder… How many other CMSes provide logging in core?

jakob · 2018-04-11 07:49:37

Bloke wrote #310855:

What’s the difference between:

“I’ve not installed the code that handles logging, therefore I’m not doing it on this site.”
vs:
“I’ve disabled the code that permits logging, therefore I’m not doing it on this site.”
vs:
“It’s possible to do logging in Textpattern, but the code to do so is available separately and I haven’t downloaded it, therefore I’m not doing it on this site.”

While I totally get this, I think the trust difference to the average user is minimal. Only technical users will appreciate the difference (at least for the moment). However important it may be, very few people ever actually look at such ‘privacy policy’ links. The straightforward message that “we do not log user access” is what matters to people more than the how, and if one does, what information and what for. If a site owner takes the trouble to provide an honest, short, no-spin overview of their privacy policy, rather than just slapping in the huge disclaimer to cover their backs, that is already an indication that the site owner has at least given some thought to the issue and how it affects their users.

And even the statement “we do not log user access” actually needs conditioning with “in the CMS” because well-nigh every server logs user access. And as soon as you start with “except for …” or “but our provider does…” your visitors’ trust antennae are already quivering.

BTW Destry: most hosts – including Webfaction – give you access to the server logs so you would be the person to approach for them. I couldn’t tell quickly if it’s possible to switch off logging. Aside from that, logging can sometimes be useful, for example if you want to lock out bad bots or ban troublesome spammers…

…

And while I like the idea of modularising out ‘core’ functionality that may simply not apply to entire sites (logging, comments, contact form, multilingual), I’m concerned that it will sidetrack more important issues that have long been in the queue and are also, in part, already underway … custom fields/content types, unlimited categories, better image handling etc.

Destry · 2018-04-11 08:09:49

jakob wrote #310867:

Destry: most hosts – including Webfaction – give you access to the server logs so you would be the person to approach for them.

Thanks. That was nagging me. Now I need to learn how to streamline that.

logging can sometimes be useful, for example if you want to lock out bad bots or ban troublesome spammers…

Yes. And this is certainly a valid point to use in policy statements that few people will argue with.

And while I like the idea of modularising out ‘core’ functionality that may simply not apply to entire sites (logging, comments, contact form, multilingual), I’m concerned that it will sidetrack more important issues that have long been in the queue and are also, in part, already underway … custom fields/content types, unlimited categories, better image handling etc.

+1

Legal situations would be a valid reason to adjust game plan, if necessary, but maybe that doesn’t mean it has to be to the full module-panel extent Bloke presented. I can appreciate he’s looking at adjusting early if that’s the direction Txp ultimately takes. But maybe at first just plugin-ize logging as a safeguard interim step, then return to custom fields/content types and the other roadmap milestones, keeping the modules vision in mind along the way. (Says the non-developer. )

Bloke · 2018-04-11 08:44:19

Destry wrote #310863:

Why do you possess it if you don’t intend to use it?

That makes sense.

most users of it have probably only had a dozen visitors in the life of their sites anyway.

Speak for yourself! I’ve had thirteen.

Besides comments and logging, two modules I would never use, what others could there be? Multilingual?

Longer term, who knows. Articles, Image, Files, Links, Videos, Your-content-type-here, … with the four we include now in core included by default.

jakob wrote #310867:

The straightforward message that “we do not log user access” is what matters to people more than the how, and if one does, what information and what for.

Sure. From our marketing standpoint though it gets hairy. “Use Txp, the privacy CMS. We don’t log visitor stats anywhere in our code.”

^{Smallprint: well, you can if you want by installing an optional module/plugin so it’s not totally off-limits in case you need it for logging or you want to ban bots and spammers to potentially protect other user data from script kiddies trying to break into the site, or… oh, wait. Alright we do have logging really. Just kind of not on by default. So, uhhh… same as now really}

while I like the idea of modularising out ‘core’ functionality that may simply not apply to entire sites (logging, comments, contact form, multilingual), I’m concerned that it will sidetrack more important issues that have long been in the queue and are also, in part, already underway

Understood. Full disclosure: we (well, makss did primarily) have already begun the concept of Modules. We have one that is almost self-contained now: pophelp. Go to prefs and turn off Display admin-side inline help links in 4.7.0. In fact, if you turn it off you can almost go to the length of removing/renaming the vendors/Module/Help/HelpAdmin.php file. 95% of the core works without it. Only the prefs panel is affected right now, and maybe any plugins that call the pophelp() function directly. A line or three of defensive code in core will fix that.

Okay, pophelp isn’t all that ambitious in its modularisation as it’s only a simple set of links and files with no additional tables and whatnot. And the pref itself should probably be bundled in the module too so it disappears entirely if not used. But softly softly, we’re testing the waters of bringing the concept of modularisation to core already.

Destry · 2018-04-11 15:50:39

I’ve spent too much time today reading portions of the GDPR (aka “Regulation”), kind of just jumping around through it. But it’s interesting, and not that hard to read, actually. Might be because I’ve had NARA certification, but hey. It’s dry, of course, but not as mind-numbing as an Apple ToS.

One thing I notice is that much of it has to do with talk around how member states of the Union must deal with things. For we ‘data subjects’ and ‘controllers’, this is not a whole lot relevant. It’s like listening in on the board discussion of it all. You can skip over that shit.

Anything referring to ‘data subject’ and ‘controller’, however, is worth slowing down for.

The Regulation begins with 173 recitals. Most are just a paragraph long. I’m not up to speed on European law formation, but these seem to be like general conditions that must be met, which are discussed in more detail in the Articles. They probably came from different people who worked on the law, whatever.

Recitals are followed by the 99 Articles, which are the bulk of the Reg. The Articles are organized by Chapter, then by Section.

Probably the most interesting and relevant details are in Chapter III and IV.

Chapter III (Articles 12–23) concern the data subjects (aka “natural person”) rights.

I haven’t read through it thoroughly yet, but it is really in these Articles where you learn what needs to be communicated to data subjects “in clear and plain language… in writing”, and what they can demand from you, depending on what type of data is collected.

The controller must respond to all data subject requests with regard to Articles 15 to 22, free of charge. But, this at least is in the controllers favor, from Article 12.5-6:

5. … Where requests from a data subject are manifestly unfounded or excessive, in particular because of their repetitive character, the controller may either:

(a) charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or

(b) refuse to act on the request.

The controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request.

6. Without prejudice to Article 11, where the controller has reasonable doubts concerning the identity of the natural person making the request referred to in Articles 15 to 21, the controller may request the provision of additional information necessary to confirm the identity of the data subject.

5.b sounds like getting a lawyer time. ;)

Chapter IV (Articles 24–43) concerns the responsibilities of ‘controllers’ (site owners) and ‘processors’ (third-party data handlers)

I haven’t read all those yet either, but there are some interesting things in there.

For example, we’ve been talking about how to prove compliance. It seems the Reg has a mechanism for this: ‘Codes of Conduct’ policies (probably the new name for privacy policies).

Article 24 : Responsibility of the Controller
- Articles 40–41: Codes of Conduct

I was also half-joking earlier on about niche auditing services arising from all this. They have that covered too. Beginning with Article 35, they start talking about “data protection impact assessments”, which tie-in with certification (Article 42) and then measure of compliance with the code of conducts. The certification stuff all seems to be in relation to a regulatory system that each member state must create, or something. I’m a little hazy there, I blew through it.

It seems big orgs may end up with in-house roles (Article 37: Data protection officers). But you can imagine consultants appearing on the scene to help smaller orgs make sense of things.

After reading through things a bit, you start to see that this Reg is really oriented around larger organizations — big fish — but it occasionally reminds you that any size org is subject to the Regulation. Nevertheless, they seem focused on big data processing and transfer situations. So we (er, I, mostly) are likely making a lot of noise for nothing.

In any case, it’s probably a good idea to pick through the Reg, pull out the relevant pieces that would apply to small sites, and then make a call about what to do with logging.

Another thing I pick up from the Reg: it seems to imply Union members must provide their own version of the law, or whatever, like this version is just a umbrella statement to work from. I don’t know. This is confusing to me. Maybe they just mean communicate it through the proper channels, or something. I’ve seen no such mention of a French Regulation so far, for example, and I’d like to if one exists. Anyone seen a something local for their country?

colak · 2018-04-11 17:07:57

The question is what happens to sites controlled by EU citizens but hosted in a non-EU country?

Destry · 2018-04-11 17:11:59

colak wrote #310889:

The question is what happens to sites controlled by EU citizens but hosted in a non-EU country?

If the site serves EU citizens — i.e. collects data about them — it doesn’t matter what country it’s in, or where the data is stored. The site owner (‘controller’) still has to respond to any requests about that data.

colak · 2018-04-11 17:19:10

Destry wrote #310890:

If the site serves EU citizens — i.e. collects data about them — it doesn’t matter what country it’s in, or where the data is stored. The site owner (‘controller’) still has to respond to any requests about that data.

Suspected as much. :(

jakob · 2018-04-11 17:30:23

Bloke wrote #310871:

Speak for yourself! I’ve had thirteen.

That really made me LOL!

But softly softly, we’re testing the waters of bringing the concept of modularisation to core already.

Good to know, and amazing you always have an appropriate answer to hand!

Destry wrote #310885:

After reading through things a bit, you start to see that this Reg is really oriented around larger organizations — big fish — but it occasionally reminds you that any size org is subject to the Regulation. Nevertheless, they seem focused on big data processing and transfer situations.

Yes, especially when it comes to things like retrieving your data for re-using with another organisation. I had a brief look at common readable formats and skimmed a paper that discussed open formats that discussed a situation where someone might want to request their data from eBay and then transfer that retrieved data to Amazon ?! Obviously that’s irrelevant for small-scale organisations.

It may be that many large organisations have long dealt with this, especially those dealing with large quantities of sales or data who really have something to lose. The predatory lawyers may instead take aim for the small businesses, SMEs and non-profit associations because they know they rarely have the facilities or personnel to dedicate to this and the whole thing is not simple to deal with. And those are probably the kinds of clients many of us will have.

Granted, I may be a little over-sensitive as I have had to field accusations from such unscrupulous guys before. I’ve had to deal multiple times with fiercely worded demands from photographers whose photographs were used with permission of the supplying party, who however had not asked their photographer (assuming they had purchased the usage rights with the photo). On another site, we once used a map generated and retrieved normally from a service with full attribution on the page it appeared. That was irrelevant to the lawyers who cited only the direct link to the image on its own (i.e. out of context) that did not have the company’s copyright line embedded in it and demanded a very sizeable sum as compensation (it was for a 3 km section of rural Belgium!) and a signed statement that one could be resued should one ever commit another similar grievance in the next 7 years. It never went that far but it still cost us 350€ in lawyers fees. Since then I’ve been very careful.

Anyone seen something local for their country?

In Germany, I believe the GDPR is called the EU-DSGVO. The first line of the “Wikipedia article” on it says

Im Gegensatz zur Richtlinie 95/46/EG, die von den EU-Mitgliedstaaten in nationales Recht umgesetzt werden musste, gilt die Datenschutz-Grundverordnung unmittelbar in allen EU-Mitgliedstaaten ab dem 25. Mai 2018.

in short, that in contrast to Directive 95/46/EG, which needs converting into the respective countries’ national legislation, the GDPR will apply throughout Europe from 25 May 2018.

Textpattern CMS

Textpattern CMS support forum

#49 2018-04-10 23:33:53

Re: Txp cookies, visitor logging, and GDPR stuff in general

#50 2018-04-10 23:49:36

Re: Txp cookies, visitor logging, and GDPR stuff in general

#51 2018-04-11 06:23:57

Re: Txp cookies, visitor logging, and GDPR stuff in general

#52 2018-04-11 07:21:48

Re: Txp cookies, visitor logging, and GDPR stuff in general

#53 2018-04-11 07:49:37

Re: Txp cookies, visitor logging, and GDPR stuff in general

Bloke wrote #310855:

#54 2018-04-11 08:09:49

Re: Txp cookies, visitor logging, and GDPR stuff in general

jakob wrote #310867:

#55 2018-04-11 08:44:19

Re: Txp cookies, visitor logging, and GDPR stuff in general

Destry wrote #310863:

jakob wrote #310867:

#56 2018-04-11 15:50:39

Re: Txp cookies, visitor logging, and GDPR stuff in general

#57 2018-04-11 17:07:57

Re: Txp cookies, visitor logging, and GDPR stuff in general

#58 2018-04-11 17:11:59

Re: Txp cookies, visitor logging, and GDPR stuff in general

colak wrote #310889:

#59 2018-04-11 17:19:10

Re: Txp cookies, visitor logging, and GDPR stuff in general

Destry wrote #310890:

#60 2018-04-11 17:30:23

Re: Txp cookies, visitor logging, and GDPR stuff in general

Bloke wrote #310871:

Destry wrote #310885:

Board footer