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
bici wrote #311081:
i had never heard of AMP until now
I have become an internet relic.
Who knows? I think there’s a good chance that in X years AMP will have become a relic but you will still be here :-)
TXP Builders – finely-crafted code, design and txp
Offline
Re: Txp cookies, visitor logging, and GDPR stuff in general
Destry wrote #311080:
I guess your not talking about a Txp site, or are you?
What was it about the site prior to AMP that was making it so slow?
Here is a great example. The author, Dean Murphy, was trying to figure out why iMore was so slow to load.
With no content blocked, there are 38 3rd party scripts (scripts not hosted on the host domain) running when the homepage is opened, which takes a total of 11 seconds. Some of these scripts are hosted by companies I know, Google, Amazon, Twitter and lots from companies I don’t know. Most of which I assume are used to display adverts or track my activity, as the network activity was still active after a minute of leaving the page dormant. I decided to turn them all off all 3rd party scripts and see what would happen. After turning off all 3rd party scripts, the homepage took 2 seconds to load, down from 11 seconds. Also, the network activity stopped as soon as the page loaded so it should be less strain on the battery. – An hour with Safari Content Blocker in iOS 9
I can remember (and probably most everyone here can) when the goal was to get your page to load to load in as few kbs as possible. Then came broadband and it didn’t matter as much. And more and more sites – especially news-oriented – started flat out abusing this.
You don’t have to like Google to think things are definitely better now.
Offline
Re: Txp cookies, visitor logging, and GDPR stuff in general
Destry wrote #311074:
You probably don’t want to hear what I would suggest about AMP (Google in general).
I didn’t mention what I think about AMP (and Google…). It is not nice.
But I don’t know what kind of data AMP has access to in your code. Depends on what’s marked up, I guess. If it’s got fingers on private data, then me thinks that would concern the third-party ‘pocessor’ sections of the GDPR because that’s what Google is in that case, I think. You’re not paying them to process data, but you’ve kind of entered an agreement with them to do so by using their “free” service.
Given the Google tradition of bending the shape of light to get its grubby hand on data, I’m not optimistic about what they try to get. But yeah, like you, “third party processor” is probably relevant here. That needs thus be noted in the Privacy policy, as far as I understand it.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
#100 2018-04-17 07:36:53
Re: Txp cookies, visitor logging, and GDPR stuff in general
<destry::rant type="mild" />
You’re not the target here, Michael, just the trigger.
michaelkpate wrote #311084:
Here is a great example. The author, Dean Murphy, was trying to figure out why iMore was so slow to load.
So, when you say “we” (earlier), you’re not talking about a site you and some collaborators own, but “we” in the sense we are all benefactors of the benevolent Google?
Google, to name one tech monopoly, got us into this mess to begin with, by seed-blasting the concept of more, more, more and getting the zombies hooked on their free drugs. Google can take AMP and stick it, along with its contributions to American military defense.
Hey, Google! ??
I can remember (and probably most everyone here can) when the goal was to get your page to load to load in as few kbs as possible.
You say that like it’s not the goal anymore. ;)
Granted, yes, there are too many abusers, both oblivious of the fact and knowingly so. As there are in every other aspect of human society. One look at comments on any randomly-selected YouTube video demonstrates everything you need to know about the intelligence of the former. Your mention of news media, corrupt with surveillance capitalism, is the epitome of the latter.
Nevertheless, I see articles all the time from people conscientious about page size and loading times, and getting rid of the crap that causes the problems — the kind of crap Google and other tech giants love to dish out. These conscientious people are nobodies who nevertheless fight the good fight to big names in the web industry, Aral comes to mind (though a reputation to maintain, thus his ubiquitous presence in the platforms he chides). We don’t even have to look beyond this community to see people talking about benchmarks and speeds of this feature or that content item. But then we are a conscientious group here, no?
Then came broadband and it didn’t matter as much. And more and more sites – especially news-oriented – started flat out abusing this.
Yes, again, lots of abusers. Certainly more than otherwise. Which is exactly why ‘re-revolution’ and resistance is important. Caving to the tech monopolies is a fast-track to a lobotomy.
Another thing that always nags me about technology (and I admit I’m a rare bird here, unfortunately), especially web technology, is how much energy it demands, which is measurably disastrous on the environment. Point is, we need — by the very idea of saving our critical biome — to adopt a conservation stance when it comes to web tech. Not a glutton stance to fill up free cloud quotas and bloat websites with script injections just because we can. That is the thinking of evil-doers and denialists. Devil spirits out! ?
You don’t have to like Google to think things are definitely better now.
On the contrary, I think a lot in the world now has never been more precipitous, and tech monopolies like Google are one big reason why.
The worst thing humanity can keep doing is throwing technology at issues that simply need less of it.
Offline
#101 2018-04-17 07:59:58
Re: Txp cookies, visitor logging, and GDPR stuff in general
phiw13 wrote #311085:
That needs thus be noted in the Privacy policy, as far as I understand it.
I’d have to read the parts more on processor, but from skimming the GDPR, my impression is that if you have data being processed externally, then you do need to account for it in the CoC. Probably a statement of some shape and length that identifies the processor, why they’re being used and how, and what rights a user has in relation. Whether parts of the statement can pass the buck to Google, I don’t know. Probably not, because it’s a controller’s choice to use a free service.
But, I’m avoiding the whole ‘processor’ aspect by cutting out all of that stuff in my own sites, so I can’t say with any confidence what anyone should do there.
If anyone comes across examples of how these external processors are being addressed in SME websites, that would be useful to see.
Offline
#102 2018-04-17 21:36:10
Re: Txp cookies, visitor logging, and GDPR stuff in general
I was looking for articles from an American perspective so I don’t have to worry about getting extradited to the Hague or something. As a Google Analytics user, this one seems useful.
Offline
#103 2018-04-17 22:25:02
Re: Txp cookies, visitor logging, and GDPR stuff in general
I actually got to wondering about this the other day.
Whois is dead as Europe hands DNS overlord ICANN its arse
Except, according to this:
WHOIS Privacy is available for more TLDs, but there are some exceptions. For instance, .CA and *.UK allow WHOIS Privacy for individuals, but not for companies. Some do not allow WHOIS Privacy at all, for example, .SEXY, .DE, .EU, and .US. And then there are others, such as .AT, that allow WHOIS Privacy only in very specific instances. – Protecting your personal information
So .eu domains are required to give out personal information, which is now about to be banned in the EU.
Offline
#104 2018-04-17 22:34:49
Re: Txp cookies, visitor logging, and GDPR stuff in general
michaelkpate wrote #311137:
So .eu domains are required to give out personal information, which is now about to be banned in the EU.
It just goes to show that this argument can be twisted any which way it suits people…
As I see it, it’s about accountability. That includes stating clearly what you do with people’s data and not hiding behind vague anonymous identities that make it impossible for people to hold people accountable. Any firm has the names of its directors in the official company records that anyone can look up. In Germany, pretty much all sites are legally obliged to have an imprint / colophon / site ownership details. Of course not everyone is honest about adding those details and there are some cases – like actors – where another representative can state their details as a representative but for the most part it is supposed to improve behaviour – much like car number plates.
TXP Builders – finely-crafted code, design and txp
Offline
#105 2018-04-17 23:13:39
Re: Txp cookies, visitor logging, and GDPR stuff in general
I’m still real hazy on all this “IP address is personally identifiable information”. I know to date I’ve been rather flippant about it, but I don’t know how far a CMS has to go to protect its users who design sites. Sidestepping the whole “should Txp have logging at all” thing, if you visit stefdawson.com right now, the very act of visiting any page on the site results in:
- Txp logging that access attempt because any flood attempts or repeat form submissions are diverted to spam/bot bin by various plugins (rah_comment_spam, smd_prognostics, …).
- Apache logging the access attempt because, well, it does by default in my vhosts file.
- The logwatch script keeps a daily check on my system log levels, disk usage and hack attempts. This includes summarising bad access attempts (based on the number of attempts from the same IP) and in a few cases, the IP addresses of any server that “probed” the site to try and hack into it.
Do I use this information? Not really. Only for forensic analysis in case I’m the victim of a DOS attack or some other hack attempt. Or possibly if I’m testing functionality of a plugin, or even Txp itself in preparation for a release. And it all relies on whether the browser emits referrer info anyway.
Let’s say I leave these settings on after GDPR-day. Should I pre-order my Gitmo-orange jumpsuit or look down the back of the sofa for 20million Euros?
There’s all this talk of consent (actual, not implied). Implied consent is me updating my Code of Conduct (regardless that you might not read it prior to visiting) to state that I collect the above and do nothing with it unless you hack me, whereby I might look through it. Or I might see your IP address as I’m scanning the log to check my own access attempts during code testing.
Actual consent is me putting up a notice on every page – remember I can’t collect a cookie to shut off a message until there’s consent – that your IP may have been logged. What options do I offer on every page view?
- A banner “If you agree to your IP being logged, click Yes”.
- A banner “If you disagree, click No” whereby I have to somehow check the IP they’ve given (store it, which is, ummm, “profiling” right?) and match any incoming requests to omit them from any logs, now and forever. And, oops, it’s too late to do anything about this initial page request, because the access attempt has already been logged by Apache since I can’t shut it off on a per-IP basis. So I need to somehow be notifed of the “non-consent” notification and retrospectively remove the offending row. And, if their ISP changes their IP allocation, they need to go through the consent thing again.
- Notification only – either a persistent banner or a link to the CoC in the footer – that you consent to collection of data as governed by the CoC.
But even with the soft option (3), if someone makes a hack attempt and I thwart it through blocking their IP or analysing the logs, I’m “profiling” them as I’m using information that GDPR claims is personally identifiable to do so.
Am I in hot water if I look through any logs? I’m using it as a preventative measure and might look at it once every few years, but can this be construed the same as putting wire mesh on your windows to prevent burglaries? i.e. all it takes is someone to make a sustained hack attempt, wait for me to block them and then cry foul that I profiled them using illegally obtained PII?
Even if I turn it off by default, both at the Apache level and in Txp, if I turn it on for a moment while testing a plugin and someone else visits my site during that time period, they’ll get logged. Will they ever find out? Probably not, but that’s not the point. The point is, this law gives them the right to request I provide details if they suspect I have any info and request that it be purged. I’ve no idea what happens if that message never gets through (my email provider has a level of spam filtering that I annoyingly cannot turn off). Presumably, I’m screwed.
Pretty much all the blogs and advice I’ve seen on the interweb to date is about Analytics or compliance aimed at corporations, not the little guy who runs his site for the benefit of the community he supports in his spare time. I’m not using third party data processors or controllers. I’m the controller and (potentially) processor. I run my own server. I capture IP for post-apocalyptic traversal and forensics, as well as automated spam prevention. I can’t conceivably see a way to turn it off wholesale without opening myself up to a level of risk I’d rather not accept. Nor can I see a way to permit users to control what’s stored that complies with the letter of the GDPR’s definition of PII.
I guess step one is to add this to my privacy policy/CoC and hope it’s enough:
I’m a hobbyist coder. My server collects IP address information for detection of fraudulent access attempts by scripts/bots, and for spam control. If you don’t like it, fuck off.
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
#106 2018-04-17 23:16:19
Re: Txp cookies, visitor logging, and GDPR stuff in general
well done! how about: sod off you stupid git
…. texted postive
Offline
#107 2018-04-17 23:49:30
Re: Txp cookies, visitor logging, and GDPR stuff in general
Bloke wrote #311141:
I’m still real hazy on all this “IP address is personally identifiable information”.
I remember when I was new to the Internet and fascinated by all this TCP/IP stuff and actually cared what my IP address was.
I am at work right now. I have no idea if my current public IP is unique to this machine or part of a pool (I just checked on my phone and got a different number but I don’t know how they handle staff vs public wifi either).
At home, I know I get one randomly assigned from Xfinity but I have no idea how often that changes – on every renewal or reboot or what.
When Cell Provider is Fi from the evil G company. Which means my phone bounces around between 2-3 networks, which I assume changes each time.
So if you want to track me by IP, good luck.
Offline
#108 2018-04-17 23:59:50
Re: Txp cookies, visitor logging, and GDPR stuff in general
michaelkpate wrote #311143:
So if you want to track me by IP, good luck.
Exactly. We took out banning by IP from Txp ages ago because it’s useless. Google stop me from viewing YouTube content outside of my country. Hello VPN, hello content. It’s such a nebulous piece of information I can’t see how it’s enforceable as de facto identification.
If you visit my site today, whether or not you agree to the collection of IP address, tomorrow you might be on a different IP thanks to the pool at your ISP. Or the device you use. You might even get an IP assigned that someone has had before and who has previously agreed to being tracked on my site. How will you know about it? You won’t. If you ask me, I can look through my server logs and maybe see that “you” (an IP) agreed to it a few years ago, even though you posit otherwise. Who’s right?
Fascinating. I can’t wait to see someone successfully sue someone else for storing an IP address from a shared pool.
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