Don't get me wrong, there's the excellent Plausible for that, but collecting usage statistics is far from shady.
I don't know why this (false) use case gets banded about so much, but my gods does it annoy me.
Cookies generally make this much easier, at the very least identifying a visit.
With ip logs, you’re not just dealing with the fact that IP addresses are often shared between people (eg behind a NAT), you now also need to record IP addresses, which arguably is an even bigger privacy violation than just using cookies.
I’m not saying that one method is always better than the other, but it’s definitely not as black-and-white as you make it out to be.
Is that truly worth ruining your website and annoy your users to start?
There are very few things in life that are truly as black and white as this.
Why would I not? A brick-and-mortar store can tell when the same person walks in twice; it's easy to imagine webmasters wanting that too (to stay noting of having a chance of distinguishing real people from bots and scrapers).
For logging, just hash it with a salt.
This would not satisfy privacy maximalists because you can easily unmask users later.
> Cookies generally make this much easier, at the very least identifying a visit.
You don't actually need cookies to reliably identify unique users. Browser fingerprinting is very identifiable and difficult to obscure.
First, I would be shocked if Google isn't using fingerprinting data in conjunction with cookies.
But also, this comment misunderstands what FLoC was. FLoC was, at least in theory, an attempt to get the benefits of targeted advertising without uniquely identifying users. That's what the "C" in FLoC refers to - users aren't targeted individually, but rather by the cohort they belong to.
FLoC unfortunately had many issues, one of which is that there were concerns that the cohorts were too granular and could still effectively denanonymize users. There's some research indicating that this was the case - FLoC cohorts revealed more info than they intended to, but also still less than individualized profiles do.
The stated goal of FLoC was actually more privacy-focused than the status quo (individualized profiles). Unfortunately, that's not what ended up happening - or at least, the general public didn't trust that it was.
i am aware what FLoC was and tried to be. it was a horrible idea with it's default optin putting onus on website operators to add headers to opt-out from a mass survelience exercise generating money for the surveillance capitalists.
Well, you asked (perhaps rhetorically) why Google didn't switch to using fingerprinting instead of FLoC. And the answer is that FLoC and fingerprinting suit different use cases. Fingerprinting doesn't serve the goals of FLoC, and FLoC doesn't provide the same data that fingerprinting would.
Before you could get free publications like MacWeek, you had to fill out demographic data to qualify.
Nielsen ratings are for small subsets of users who explicitly opt in to tracking. That's not the same as "uniquely identify all end users of my website" it's like paying user testers.
Exactly. Web masters aren't entitled to that information.
> collecting usage statistics is far from shady
I don't want to be part of any of your statistics. I'm not some human test subject you get to study without my informed consent.
Where's my vested interest as server owner in knowing something about who is exfiltrating my data?
Now we can deny consent, know that they're legally required to respect our choice and enjoy the fact they can't punish us for it by denying service. Whole world needs to adopt and expand upon these laws, and also ramp up enforcement and start fining all these non-compliant cookie banner-displaying web sites out of existence.
They don't get to flip that script. They're not entitled to data about us. It's our information, they don't have an assumed right to collect it for any purpose no matter how benign. That they even think they can do it is offensive. The audacity of these people. Any data we do give them is to be used for our benefit. It's not meant to fuel some surveillance capitalism nightmare.
Yes, I don't doubt web developers would mostly prefer not to be bothered and just keep doing what they've been doing. Much cheaper than doing a system audit to figure out if you're GDPR-compliant, concluding with your lawyers that you have no idea if you're GDPR-compliant, and putting up a cookie banner nobody wants just in case. That's assuming you can afford lawyers.
At this point, it's safer to partner with a host that'll manage all that stuff for you than run an independent site. Which, ultimately, the Googles of the world love to hear, because they can afford the lawyers.
The GDPR is an amazing bit of jiu-jitsu to build a moat around competition. All the big names have to do is spend a pittance every so often to stay in compliance and they win the market, while small operators decide the risk ain't worth it because "Just don't collect user data" is actually quite hard to guarantee on a system built atop infinite cheap copying and arbitrary site access.
Not even the apache default logging config is GDPR-compliant. I don't know how anybody expects indie site admins to keep up.
Welcome to the new normal. Enjoy your cookie pop-ups.
You still need their permission to collect data and you can't revoke their access as punishment for refusing.
You end up at a statistical answer like 20 hits to our home page equal 6.3 users, statistically speaking.
If you decide to hire a sub-processor incorporated in a country that does not respect article 8 of the charta of fundamental rights of the european union (the right to data privacy), you have to ask the user before sharing their data (their data meaning "IP f.o.o accessed our service bar.com") with the geolocation service. See GDPR article 45ff. Please consider using a provider from a country that respects the fundamental right to data privacy. Note that the "privacy shield" collapsed due to the USAs trend towards surveillance capitalism and that the USA is not considered a safe harbor for personal data.
There are some exceptions, where you don't need consent: you could argue you need to geolocate the users to comply with embargos, because your company is american and you are not allowed to do business with people living in some geographic regions, like crimea. But even if you don't need consent you must still disclose that you process your users personal data that way, and why, in your privacy policy, so your users can decide to not use your service, if they don't agree. That may seem to contradict your business interest, but that is consumer protection in a nutshell for you.
Note that, if you now use this data to show graphs to your marketing team and have meetings about improving advertisements by targeting regions, you are in violation of GDPR article 5, because the purpose you stated (embargos) does not match what you actually do (targeted marketing). This is a principle americans often find hard to grasp: only because you have the data for some reason, that doesn't mean you can do whatever you want with it. This becomes clearer if you don't think of personal data as a thing in possession of those who collect it, but as a good that stays in possession of the person it is about and gets licensed to those who use it with a bound purpose. Consent management and privacy policy then being similar to a license agreement.
Now if you ask your users nicely for consent to be geolocated, and if you have a sane reason for wanting that data, the users may even agree. Just tell them about your awesome marketing department and how much they love region targeted marketing and if they don't bite, offer them a goody and they will agree. Hey they will even be offended by mistakes in your providers geo-ip-db and fix those for you. Note that this is a part of the right to data privacy: if you gather and process about the user the personal data that they are from somewhere, they have a right to know that and tell you "well no that is a mistake, i am from elsewhere". If you never tell them that you geolocate them, this is impossible.
The key problem is: most people who want that data (let's avoid the word "you" here) likely don't have a sane reason, they are just nosy and want to track their users out of curiosity. They know their tracking is kinda sus, so they don't want to tell the consumers about it, or ask for permission, or offer any goodies, and they don't care about a small error rate in their big data swamp. Instead they hide behind some "everyone does it" defense and act surprised if people consider them shady. Or worse, they require the data to offer user-unfriendly anti-features like content not being available in some regions (which actually could be a reason to not ask for consent: contracts with third parties like movie corporations requiring geolocation as part of online movie distribution), but in practice all that does is leading consumers to pay third parties to move their traffic around the globe, wasting resources to break the anti-feature.
But i digress, the key takeaway is: don't overfocus on cookies, state how and why you process personal data and it becomes obvious if you should ask for consent. An http-server does not need a consent banner to process the http-clients IP, it could not answer the clients request without it. The client gave it the IP for a very specific reason. But that reason and that process does not mean you can take the IPs from the servers logs and do with them whatever you want. That data does not belong to you, even if you process it. So please don't do that without asking for consent, or at least explaining why you do it. That is our fundamental right as data subjects.
Thank you.
Or don't be lazy/cheap and use a geolocation implementation where you don't need to share the IP at all.
And yeah, by all means, include that in your privacy policy.
I don't know details of the GDPR (as the don't apply to me) but a logged IP address belonging to the original requestor seems odd, do you also own the footprints you physically left behind on the ground as you walk around?
I switched to plausible because the added privacy is also a major UX benefit: there's no GDPR banner on my website.
Also in my experience, there isn't usually a GDPR banner on small businesses websites built on wordpress. A pizzeria, barber, local grocery store, or some other small businesses don't really have or need much on their website. A few images, a page for location/contact, a page about the employees/founders, and for the more advanced ones a web shop. No GDPR needed for any of that, and for those web shops, once a person is registered all the consent are usually given as part of the registration processing.
The typical model that I see for small businesses is also one where no one need or want a graph over visitors. The customer pay the web shops a one-time fee to build the site, and then it mostly sits there until the customer decide to build a completely new website because the old one is getting too old. No A-B testing, no optimization for user retention, no frontend interactions, no user flows. Mostly all the customer want is to not be paying a web developer any more money. This is why some shops will utilize "proprietary modules" in order to keep the customer on their (usually partners) servers, in case the customer might get ideas of moving the site to a better/cheaper hosting provider.
The most common situation that I know of when people are requesting visitor graphs is either when customer apply an marketing campaign and want to see the effect on their website, or when a conglomerate has acquired a bunch of smaller companies and want to make decision about closing down/merging specific website. In those cases the analytics usually get added when that need arrive.
Perhaps I am taking that statement too literally, but in the last century I could just look at my server logs to find out how many, from which IP addresses, and the referrer. No need for cookies for that info at all.
Literally your access logs will give you this information.
Or if you want to avoid the cookie altogether, you could use some static, cachable resource with a cache expiration date. Basically the good old counting pixel. Almost the same as the non-identifying cookie, except caches are more likely to be automatically evicted by browsers.
Some cookies are even mentioned specifically as allowed. The example given is keeping track of a shopping cart across visits. Do that, and you have your uniques. While hinted at, it does not specifically mention those have to be session cookies: you could have a banner with "accept cookies", then use session cookies whether or not accept is pressed. It even seems to be common practice to hide explanations behind a "more info" button.
https://www.privacypolicies.com/blog/eu-cookies-directive/
I'm pretty sure "uniques" stats don't require you to violate the EU cookie directive.
Incorrect, kinda.
The GDPR concerns personal information, and information that can identify people directly (e.g. location data) or indirectly (e.g. an "opaque" unique id, as it can be potentially linked back to a person, or an IP address, as it can be potentially linked back to a person, with the help of a court order compelling an ISP to pass through subscriber information to a complainant or law enforcement, and that subscriber may live alone).[0] The GDPR does not concern itself with stuff that cannot be used to identify a person or is personal data.
The earlier ePrivacy Directive (better known as the "cookie law", although the section concerning "cookies" is only a small part, and does not even mention cookies explicitly) is a vague thing, on the other hand.
Specifically, it says under "Art 5 - Confidentially of communications" that
"Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia, about the purposes of the processing. This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service."
Some people therefore say this rules out all non-"necessary" cookies (unless there is explicit consent). However, this is not the intention of the directive, not how legal experts evaluated it, not how courts in particular evaluated it. If you followed that maximal view of the text, then you couldn't legally serve anything to a user (as the users browser might temporarily or permanently store that information without user-intervention), cannot "make" a browser cache stuff, cannot even store that a user opted against tracking cookies. Instead, it has to be seen in under the "confidentiality" umbrella of that Article, meaning the "information" mentioned has to be information that concerns the user. Non-identifying (neither direct or indirect) cookies do not fit that interpretation, and courts have acknowledged that (and because it's the EU and it's vast, some courts went against it too).
The proposed ePrivacy Regulation (successor to the ePrivacy Directive) is meant to make things less vague and simpler, especially in regards to cookies, and explicitly allows anonymous user counting via cookies, among other things. While the ePR has not passed, courts did take notice, and consider it whe they evaluate the intent of the law makers as it pertains to the still reigning ePrivacy Directive.
>They should be explained to the user, but consent is not necessary.
Correct. You still have to inform people, even if your cookie use is merely "we do not use cookies to track or identify users".
Maybe surprisingly to some, the aforementioned access logs up thread, are likely illegal without user consent, because usually they contain IP addresses of users. While the "visited=true" non-identifying cookie is not (in courts with reasonably knowledgeable judges at least).
[0] https://gdpr.eu/recital-30-online-identifiers-for-profiling-...
Yes, it's not the official website, but also yes, it's the same text of the official directive recitals, except on this unofficial website you can properly link it without fuss.
It's like how search results are almost entirely rubbish now, because things are optimised for what Google looks for. So similarly, I have no sympathy for sites that need that kind of analytics.
If you really care what users like on your site why not ask them?
1. sentry.io breadcrumbs are just a nicer interface to one's own log messages, and log messages are useful and necessary to have a well functioning app. where do log messages end and profiling/behaviour data begin? that's a rather fuzzy line.
2. even if one "logs" every breath the user takes (probably covered in the ToS), it's still only limited to one app and one service, while cookies are trivial to abuse for cross-site/cross-app tracking both inside and outside a company.
EU privacy regulations focus the purpose of personal data processing. If a company makes a contract with their users that says they log personal data for the purpose of debugging, and then they use it for web analytics, that is not allowed, its a violation of the contract. And like you stated many just write consent into the ToS. But let us look at the privacy friendly case where the users are asked if they agree to other behavior analytics not related to debugging. And suddenly the log interface isn't so nice anymore.
In a perfect world personal data is labeled with the purposes it can be used for.
If such issues are not relevant to the company you work for, be grateful, and don't take the warnings personal. But by all that is holy to you don't tell people the log interface is a great substitute to web analytics.
Again, nothing shady, just bad practices. A bit like putting everyone in CC instead of BCC.
Besides, there's only so much you can do with backend logs. It doesn't work so well for small but meaningful frontend interactions, user flows and the like.
I certainly need some sort of stats to operate my website, although I don't need nearly as much info as GA collects.
Also a nitpick: the GDPR is about collecting data, not setting cookies
When I still live in the UK 6 years ago, IP addresses were rarely fixed, and changed everytime you connected. In fact, people paid extra to get a fixed IP.
I guess it's a bit of a grey area though, since sometimes it fits, sometimes it doesn't.
It is "funny" reading that, the amount of energy they spend to be illegal but only just so that they can squeeze as much dark patterns on their users before they get a fine. Rinse and repeat.
For normal companies / webmasters it is quite simple though. You don't have anything to gain from extorting your users. So please respect your users instead.
Don't use shady practices that require you to bring up a cookie-banner in the first place. Just don't.