Textpattern CMS support forum

You are not logged in. Register | Login | Help

#41 2018-04-10 08:41:56

Destry
Moderator
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,292
Website

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

phiw13 wrote #310837:

I thought the CLOUD act was a US government intervention / land grab ? (Wikipedia seems to agree – wiki link as it was the 1st link in DDG).

It is totally a land-grab, by the Trump administration. Totally B.S. for the most part. And I don’t know the ins-and-outs of it, by any measure, but here’s the relevant bold bits from Wikipedia:

United States data and communication companies must provide stored data for United States citizens on any server they own and operate [even if stored on servers overseas] when requested by warrant, but provides mechanisms for the companies or the courts to reject or challenge these if they believe the request violates the privacy rights of the foreign country the data is stored at. It also provides an alternative and expedited route to MLATs through “executive agreements”; the Executive branch is given the ability to enter into bi-lateral agreements with foreign countries to able to provide requested data related to its citizens in a streamlined manner, as long as the Attorney General, with concurrence of the Secretary of State, agree that the foreign country has sufficient protections in place to restrict access to data related to United States citizens.

The part as it concerns your question is the bi-lateral agreements. So, in fact, the CLOUD act would probably have no bearing or relevance to the muse I made earlier because it requires the governmental handshake and they wouldn’t waste Executive Branch time with petty squabbles. But who knows, the GDPR is nothing to shake a stick at. Millions and billions are seemingly up in the air for legal grabs.

I made that other part bold, though, because I find that interesting. It seems to suggest even if Trump wanted to scan data records for Apple iPhone logs stored in Switzerland (just a hypothetical example), Switzerland could still legally challenge it if it thought there was risk to it’s citizens. But in doing so they would probably lose all future rights to investigate data on US soil. Be my guess.


Wordworkin’ for you.

Offline

#42 2018-04-10 09:47:41

gaekwad
Admin
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 2,633

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

Destry wrote #310830:

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.’

Honestly, I don’t know if it can or cannot be done, technically speaking. My questions were genuine, no antagonism intended.

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.

Agreed on all points. I actually typed and deleted a lengthy paragraph on my attitudes/approach to the sustainability of plugins, having been caught out a few times before. In my view, the dev team is the strongest it’s been in my years with Textpattern, but by the nature of this project there’s always going to be uncertainty when handling the incredible efforts, attention from and nuances of a relatively small team of people on the core team.

I actively avoid using plugins because, to me, I’ve been burned before when compatibility breaks. It’s really selfish, I know, getting annoyed when something that someone has spent many hours working on (and invariably offers up for free) just stops working, and they’ve moved on to another project. It’s frustrating, I know, but wholly manageable with limited exposure to plugins. And yeah, probably tin foil hat territory, but c’est la vie.

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?

Because you and I are different from the average/typical Textpattern user, we poke and prod and discuss taking things away as well as adding stuff in. Because while we might not use the feature as it’s intended, a whole bunch of other people do use it and won’t go through the added faff of installing a plugin to achieve the same thing when it’s taken away, they’ll just start looking around for something else or get a bit grumpy that this thing that used to just work doesn’t work any longer.

Yes, I’m exaggerating these lines to make the distinction clear.

I cannot disagree, and I think you’re right to do so. From a compliance point of view, if you’ve made best efforts to ensure the elements within your control are privacy-compliant (in whatever shape that takes), then your liability is minimal. Yes, it’s an ass-covering exercise – and no, I’m not a lawyer – but there has to be a point where feasible steps end.

Btw, here’s another honest question: If a Txp site has logging on, can a site visitor tell that by any measure or tool?

Honestly? I don’t know 100%, but I’m reasonably sure they can’t. If a site is in debug mode, there’s no obvious reference to any kind of client logging.

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.

Another question I can’t answer. Anecdotally, a huge majority of people I know who use Facebook continue to use it, even after the recent (and continuing) revelations. We have the burden of technological awareness, sir – it’s a bit of a buzzkill sometimes. Many or most non-technical people don’t give two hoots about the behind-the-scenes nonsense, they just want to buy their tat, read their clickbait and post photos of their idyllic life for other people to fawn over.

Is it worthless, though? Which one of those statements above would you prefer to see as a gun-shy web user these days?

Maybe ‘worthless’ wasn’t my best choice of words…but my point about the site operator’s liability has to end at a point. I typically use roll-your-own servers from Digital Ocean, and I know they have internal metrics for monitoring their servers. As a site operator/consultant to a site advisor, I have a clear privacy policy with as little legalese as possible outlining what data is gathered, for how long, how it’s stored, and what I do with it. That use is sometimes purely indicative for me when I need to upgrade the server or add in load balancing because it gets super-busy or runs slowly (hi, Magento). I’m experimenting with anonymised IP logs at the moment as another way to reduce my liability.

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. ;)

Maybe ‘confidence’ isn’t the best choice of word… ;) I take an admittedly pragmatic approach to doing web stuff, making sure I make notes and any auditor can see what I’ve done, and while I don’t profess to knowing a lot about a lot (see above, and posts passim), I follow a fairly good standard of opsec and can prove it when required.

I’ve had a couple of clients have audits before (that I know about), and in one case the web host was found to be at fault for not adequately plugging a security hole after knowing about it for a few years, so I suppose I could have a biased view on this stuff.

But I’m not sure logging as a plugin option for a Controller would be “overreaching”. More work, certainly, but not totally pointless.

Honest question in response: would your preference be for something Textpattern-made from scratch (effectively), or something like Matomo (was Piwik) or other GPL-friendly analytics repurposed into a plugin, or something else? I’m thinking about the remit of Textpattern within the confines of a CMS…where is the line drawn, if there is one? Is Matomo stable enough to rely on, assuming (fairly, I think), that they know what they’re doing? If logging is to be jettisoned to a plugin, does it need to be invented here?

(Great chat, btw – thanks!)

Offline

#43 2018-04-10 10:10:38

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 3,588
Website

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

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.

From what I’ve read, there is the possibility of getting your GDPR efforts certified by external certifiers. I assume that’s only for the big guys.

In the end, it’s a policy statement. Aside from independent verification, I guess there’s little you can do to verify it is actually upheld other than exercising your right to request your information.

On that note, I wonder if there are any practical guides on suitable formats (I read somewhere information has to be provided in a suitably readable/portable format). In Textpattern, it would be feasible enough to create an own external output form or page template that could output, for example, a breakdown of stored content in XML format. One would just have to ensure that only the actual site owner could access it.


TXP Builders – finely-crafted code, design and txp

Offline

#44 2018-04-10 11:47:23

philwareham
Core designer
From: Farnham, Surrey, UK
Registered: 2009-06-11
Posts: 3,216
Website

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

I’ve updated the Textpattern.com privacy policy to reflect the current behaviour of our Websites and for better compliance with GDPR.

Offline

#45 2018-04-10 12:01:05

Destry
Moderator
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,292
Website

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

gaekwad wrote #310839:

would your preference be for something Textpattern-made from scratch (effectively), or …?

I’m only talking about current logging functionality. Just moving it out to the ultimate option (a plugin). Any logging/analytical functionality more is just gas on the house fire.

jakob wrote #310840:

In the end, it’s a policy statement.

Exactly. But there might be different ways of approaching that statement, and getting the words right, depending on the nature of a site and the tech it uses. As you made clear earlier with that example, even just a little opt-in generates a tonne of legalese. But if you don’t collect anything. Period. That makes it easy. (Again, I know not every site can do that.)

Aside from independent verification, I guess there’s little you can do to verify it is actually upheld other than exercising your right to request your information.

That’s exactly why I’m beating this horse. It seems to me a controller would want to do everything in their power to avoid giving any reason for users to make that request. And I have a feeling people will want to — especially tech-savvy troll types testing the perimeter, if you will, and looking for ops to pounce and sue.

So showing (by saying and “proving”) that you not only don’t do this but can’t do it, would go a long way there, I would think. Take “proving” with a grain of salt, The idea is more to dissuade potential requests.

Using my exchange with Pete as an example… If Visitor logs were a plugin (i.e. not core technology), then that would reflect in Txp user documentation, which could be pointed to from a policy statement, clear and concisely to show, yeah, this is not core functionality. So if a controller says they don’t have it installed — meaning they would know if they’re blatantly lying — then they must really mean it, and asking for proof is impossible because there’s not even an empty database table to show. One could reply: “You’ll have to get a warrant, if you want my root password. And get ready to be counter-sued for calling me a liar and wasting my time.”

Instead, just pass the buck up the tree line to the web host, make them hand over the server logs.

Or use the logging plugin, if you really want to play the game, and export all requests as a CSV file from the table showing their records, if any. The plugin would still allow that if it was used.

As it is now, my statement might look like: “This site does not use software to log your visits, whether third-party analytics or via the content management system. Not even your IP address is known or stored because the functionality is off. Contact WebFaction if you want logging data.

I will probably use a variation of that, and thus improve those doc pages for that reason. But you can see how much more weight that would have if logging functionality was in fact not in core.


Wordworkin’ for you.

Offline

#46 2018-04-10 12:34:06

Destry
Moderator
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,292
Website

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

planeth wrote #310812:

There’s a lot to say about GDPR, I don’t have time now

Looking forward to it. I’m out of steam. ;)

Maybe you can answer this question?


Wordworkin’ for you.

Offline

#47 2018-04-10 13:43:17

Destry
Moderator
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,292
Website

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

As far as I can tell, this is the official link to the full GDPR law. Lots of language options available there.

And this is kind of a cover page on it.

Enjoy! ;)


Wordworkin’ for you.

Offline

#48 2018-04-10 18:38:48

gaekwad
Admin
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 2,633

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

Destry wrote #310845:

So showing (by saying and “proving”) that you not only don’t do this but can’t do it, would go a long way there, I would think.

Penny drops – now I get it!

+1 from me. Great idea. That sets the perimeter of accountability perfectly.

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,832
Website

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

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)


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

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,832
Website

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

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.


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

Offline

Board footer

Powered by FluxBB