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
michaelkpate wrote #310819:
All I did was link to the video.
That was the whole point of my rib. The embed isn’t giving YT the juice. The visits are. (And considering this whole can of beans centers around surveillance capitalism and data privacy… well, the link just seemed like a big, plump pimple on the tip of a nose. A Facebook link couldn’t have been more ironic. ;)
But I’m just ribbing you, not attacking. Carry on.
Offline
Re: Txp cookies, visitor logging, and GDPR stuff in general
michaelkpate wrote #310818:
It will be interesting to see if any sites ban EU users.
I’m certain it will happen. I can hear all the red-faced [American stereotype here]s complaining about it now. But that will only hurt them, not achieve anything. In fact, you’ll probably see blacklists emerge for sites that don’t respect EU citizens. The pissing wars will be interesting indeed. I suspect a few high profile business losses or heavy fines dealt will straighten things out in the end, though.
And I wonder how the CLOUD act will influence that too, which gives EU governments (and any other world gov) the right to access American data stores for “criminal” investigation.
Offline
Re: Txp cookies, visitor logging, and GDPR stuff in general
Interesting thread – thanks all.
I’ve realised that I need to update the Privacy Policy on Textpattern.com to reflect this and the work we did a couple of months back to remove all user tracking and suchlike from the site(s). Some of the sections there are just plain incorrect now (e.g. “We may use information in the aggregate to understand how our Users as a group use the services and resources provided on our Websites.”).
Offline
Re: Txp cookies, visitor logging, and GDPR stuff in general
Destry wrote #310833:
And I wonder how the CLOUD act will influence that too, which gives EU governments (and any other world gov) the right to access American data stores for “criminal” investigation.
Am I confused here? 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).
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
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.
Offline
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
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
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
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.
Offline
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?
Offline
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! ;)
Offline
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