Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#229 2018-05-03 08:27:01
Re: Txp cookies, visitor logging, and GDPR stuff in general
Zuck was recently accused in the post Cambridge Analytica scandal that he was going to charge those fb members who wished their details and behaviour to remain private. Registrars have been doing it for years. With the new law coming into effect I was wondering what the opinion is regarding domain name registrars and privacy.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
#230 2018-05-03 09:40:27
Re: Txp cookies, visitor logging, and GDPR stuff in general
colak wrote #311592:
Zuck […] was going to charge those fb members who wished their details and behaviour to remain private.
Do you have a source?
Offline
#231 2018-05-03 09:47:49
Re: Txp cookies, visitor logging, and GDPR stuff in general
Jakob wrote #311527:
On the one hand, we need to keep a record of consent and at the same time, we pledge to delete personally identifiable data held on them after a certain amount of time, which presumably also includes that kind of record of consent – it is, after all by nature personally identifiable.
If consent has been withdrawn and you no longer need the data for any other processing, then you should delete the whole record.
Which —technically— means that you should maintain a list of identifiers to be re-deleted in case of a DB restore from backup dating back before the delete.
Offline
#232 2018-05-03 09:51:11
Re: Txp cookies, visitor logging, and GDPR stuff in general
planeth wrote #311593:
Do you have a source?
Hi Planeth,
It was part of his testimony before the congress.
Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.
Offline
#233 2018-05-03 10:59:15
Re: Txp cookies, visitor logging, and GDPR stuff in general
Q about Txp’s logging… This simply pulls from the web host’s (if relevant) web server logs, right? So whatever they collect/allow is what Txp has access too, limited to whatever fields Txp uses. Is that correct? Or is there some more local voodoo happening that makes Txp logs independant of host logs?
Related. WebFaction says in their WF privacy policy that, for their own log collection, data is anonymized. Assuming they were talking about client logs too (e.g. logs for my site), then would that anonymized data pass to Txp logging?
Btw, worth looking at their PP for insights about Data Retention.
Oh, one more… If Txp changed core logging to simply not collect IP addresses, would core logging still have any value? If not, then, imo, that’s yet another reason to extract the functionality as a plugin and let people decide to install/use by irrefutable (would stand up in court) voluntary action. But if so, then why not do that? Stop collecting IPs. Then logging wouldn’t even be an issue for business Txp users (controllers) in relation to the new laws.
Offline
#234 2018-05-03 12:14:32
Re: Txp cookies, visitor logging, and GDPR stuff in general
Destry wrote #311596:
Q about Txp’s logging… This simply pulls from the web host’s (if relevant) web server logs, right? So whatever they collect/allow is what Txp has access too, limited to whatever fields Txp uses. Is that correct? Or is there some more local voodoo happening that makes Txp logs independant of host logs?
Yes, I believe the server is simply queried by the $_SERVER PHP variable and then entries written to a Textpattern database table. Nothing more esoteric than that happening. Other devs may be able to confirm, but that is my basic understanding.
Oh, one more… If Txp changed core logging to simply not collect IP addresses, would core logging still have any value? If not, then, imo, that’s yet another reason to extract the functionality as a plugin…
I’d be fine with removing the whole logging system from Textpattern, but allowing plugin authors to write something if the desire is there. It’s stuff you could retrieve from server logs anyway so I’d let hosting company, or server owner, worry about the whole GDPR issue and avoid it entirely within Textpattern core.
And also worth mentioning is the comments system collects IP addresses when you submit a comment – although since we removed the ban list a couple of major versions ago I don’t see any use in saving those IPs now, unless of course that is how the comment ‘remember me’ cookie recognises you? Not sure.
Offline
#235 2018-05-03 12:38:03
Re: Txp cookies, visitor logging, and GDPR stuff in general
Textpattern logs do not depend on the host’s server logs. As Phil says, it’s a fully txp-made construction: all the necessary data are retrieved from the $_SERVER array. I’m ok with removing the IP address or even delegating logging to plugins, this shouldn’t break anything.
philwareham wrote #311598:
And also worth mentioning is the comments system collects IP addresses when you submit a comment – although since we removed the ban list a couple of major versions ago I don’t see any use in saving those IPs now, unless of course that is how the comment ‘remember me’ cookie recognises you?
IP addresses are still used if an admin wants to ban a visitor. Cookies are optional, so the recognition is based on the IP. This protection is weak, of course, but better than nothing. Dunno whether we should add a “your IP address will be stored” notice to comply with GDPR.
Offline
#236 2018-05-03 13:02:14
Re: Txp cookies, visitor logging, and GDPR stuff in general
etc wrote #311599:
IP addresses are still used if an admin wants to ban a visitor.
Yes, though admins can no longer ban IPs by hand from Txp as that functionality was removed last version. However, the blacklist pref is still available if you enable comments and wish to check third-party spam blacklists for specific IPs.
As Oleg says, pretty crappy defence overall, since IPs are often transient anyway. But if spam companies are stupid enough to bulk dump stuff to your site from the same IP, it can be useful.
Note that if comments are off, the blacklist pref is bypassed, but the level of logging remains controlled by a separate pref, and is gathered from whatever PHP passes onto us from the page request.
Last edited by Bloke (2018-05-03 13:04:27)
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
#237 2018-05-03 13:17:45
Offline
#238 2018-05-03 13:23:54
Re: Txp cookies, visitor logging, and GDPR stuff in general
planeth wrote #311594:
If consent has been withdrawn and you no longer need the data for any other processing, then you should delete the whole record.
Sure, in cases where consent is withdrawn its clear.
The case above was about deleting records after some specified period but still keeping a record of the consent they gave to appear in a photo which might still feature on a website long after the record has been deleted. In practice this means, either:
- Present multiple forms with requests for consent = more nuisance to the recipients and more paperwork
- Collect different specific consent in a single form, but split out some results into a second database for longer retention so that the first can be removed at a given interval.
Which —technically— means that you should maintain a list of identifiers to be re-deleted in case of a DB restore from backup dating back before the delete.
Yes, tricky. For small sites/organisations, that’s probably doable but for larger sites/organisations, some system needs to be in place.
In the case of deleting from backups, I think it’s not feasible to extract single records from past backups, nor is it reasonable to have to throw out all one’s backups when one person wants a record removed. In such cases I think it’s fair to say, deleted information disappears from backups after X months (or however many backups you keep).
TXP Builders – finely-crafted code, design and txp
Offline
#239 2018-05-03 13:33:35
Re: Txp cookies, visitor logging, and GDPR stuff in general
etc wrote #311601:
there is no need to store commenters IP anymore?
Well, is_blacklisted() is still called from publish/comment.php. If we remove storage of commenter IPs, we’ll need to deprecate that function and remove the blacklist pref too.
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
#240 2018-05-03 13:45:01
Re: Txp cookies, visitor logging, and GDPR stuff in general
Bloke wrote #311603:
Well,
is_blacklisted()is still called frompublish/comment.php. If we remove storage of commenter IPs, we’ll need to deprecate that function and remove the blacklist pref too.
Not necessary, its $ip argument is pulled from $_SERVER['REMOTE_ADDR'] on comment, and we don’t seem to use txp_discuss_ipban table anymore. This table does not even exist in 4.7.
Offline