As an American who moved to Berlin 15 years ago, I love not needing a car. We like to visit Paris, Amsterdam, London, Florence, and more cities multiple times a year and we never get a car. Between public transportation and my bicycle, I can get just about anywhere I need to and usually faster than in a car.
If I need a car for some unusual errand, which is rare like once a year, I use an app to cheaply rent a car of the needed size for a few hours.
Recently had to go to the US for a short trip and I had to rent a car. It felt insane how much time I had to spend in my car just to visit people who all live in the same metro area, due to all the sprawl.
This article could have been published 30 years ago. In professional unix admin circles this was already well known back them. Although I could be misreading it as the article is not very clear. I think this are the points it is trying to make:
1. Once upon a time you could rely on the passwd file and shell behavior as an effective means of authentication and access control.
2. It has been a very long time since that was an effective approach, for a variety of reasons, and you should not do this on modern production systems.
Even 30 years ago, the core argument would have been nonsensical.
1. They introduce their argument as if it is solely about shell access (the conclusion also only mentions "login access control"), but then the first example/statement they make is about non-shell access (Samba, IMAP, Apache).
2. The second argument conflates authentication and authorization, and concludes that to implement shell authorization properly, your only choice is to provide multiple authentication systems.
Zero effort is spent on explaining why existing/historic shell authorization systems (such as simple DAC groups or rbash) are inadequate, and it's not clear to me what threat model they are using to arrive at their conclusion.
edit: rethinking this, I think TFA is just lacking a clear problem statement. They seem to be talking specifically about non-shell services that (ab)use the user's shell field in /etc/passwd as authorization information, and then complaining that many services did not follow suit.
authz may be confusing to non USA English speakers. I wouldn't make the connection without it spelled out to me. Unfortunately I don't have a better suggestion because auths as short for authorisation is probably worse.
To me they look like the kind of abbreviations I'd only do when writing. I just say authentication or authorisation when reading them (out loud or in my own mind)
This blog of generally gibberish hits the HN front page with an astounding frequency. IMHO, there are many interesting blogs on "system administration" topics that are submitted to HN every week that never reach the front page while there are a handful of familiar, low-quality ones that routinely appear on page one.
Much of tech is a theatre, a jobs program that keeps people employed in a middle class salary so long as they diligently pretend to be engineers. This theatre serves as a prop for a higher level theatre in our virtual economy for investors and their game of financialization.
Its expected that as tech grows in number of workers clutching to that middle-class life-raft that the baseline of knowledge discussed in tech spheres (like this site) will sink lower.
I think the point being made is that the fact that a user has rksh as their shell means nothing to samba, ftp, some features of ssh, httpd, cron, and etc. Fundamentally unix has pretty simple permissions, you're either root or you're not. The existence of a user account on a system is often enough to enable SMB and SSH access even if the only purpose of the account is to own files and an application process and is never intended to have interactive logins or to transfer data to and from the server.
> I think the point being made is that the fact that a user has rksh as their shell means nothing to samba, ftp, some features of ssh, httpd, cron, and etc
Which has been true for...... 30 years? If not longer?
* Doesn't scale. Having passwords in a plain text file is not a scalable solution for users directory. Can probably go up to a hundred users, but not much more.
* In computer clusters you want user identity to "stick" to the user when they use multiple machines, containers etc. That's why you have LDAP... but it doesn't help all that much because user id is encoded into the file system (huge mistake...) which makes it very difficult to contain users to things they should control. If your only mechanism was the /etc/passwd, it would mean you'd have to constantly synchronize this file across all those machines and containers you have.
It may be old and not particularly appealing, but LDAP has been serving that role effectively at many companies.[0]
Using a terminal remains standard practice for sysadmins and devops.[1]
I believe there's some confusion in both the article and the comment between authentication and authorization. LDAP is fully equipped to handle both tasks.
To anyone reading this and thinking "yeah dummy, of course it doesn't scale because you're not supposed to store passwords in plain text in the first place" I'll direct you to Chapter 7ish of The Linux Programming Interface.
If you look in your /etc/passwd right now, you'll almost certainly see a single "x" where the (EDIT: no, it was still encrypted!) password originally was - nowadays that single "x" is an instruction to go look in /etc/shadow instead, for the salted hash of the password you're trying to check.
I think this minimizes the number of users who need read permissions to /etc/shadow, and the amount of time they need it for.
This has been your seemingly useless bit of Linux trivia for today. :)
/etc/shadow was born not because /etc/passwd had a plain text password but because the hashes became crackable and /etc/passwd is a public read file. Linux has never had them. Here's the man page indicating encrypted passwords for Unix v7 /etc/passwd release in 1979: https://man.cat-v.org/unix_7th/5/passwd
I have a vague recollection of my 20 floppy of Slackware already having /etc/shadow. That would have been fall of 92 or winter 93, based on where I was living at the time.
I have a vague recollection of being given the choice on a 90s vintage distribution with some warning about security and password length if I did not use shadow passwords. At some point in the early 2000s we started authenticating regular users against AD but the shadow file was still there for root.
We had a couple of labs of sparcstations that just went away a couple of times a year because something bad would happen with all of the NFS mounted partitions and they'd have to turn the cluster on one box at a time to prevent thundering herd issues with NFS.
I think they may have been mounting parts of /etc as well. People get the idea that managing accounts for a cluster of boxes should be centralized. It's all fun and games until the network mount disappears.
"unencrypted" is normally written as "cleartext". "plaintext" means "(readable / intended to be read) without a special viewer". Your.ssh /id_rsa is plaintext but not cleartext.
My school had 30k students, including grad and doctoral students. When they gave students shell accounts, they tried to put them all onto a single Sequent box. They got my incoming class, the following, and anyone previous who asked for one onto that box. I’m pretty sure it had an /etc/password file, and would have had about 8-10k people on it.
After that they gave up. Even with aggressive ulimits it was too hard, and each new class was apportioned to a separate Sparc. Which was a shame because we learned an awful lot about Unix administration from users pranking each other, figuring out what they did and how they did it, protecting yourself and retaliating (some people would prank others without first protecting themselves).
Made it a lot harder chatting with people from other classes as well. For electives and humanities you weren’t always in classes with people your exact age. They could be ahead of you or behind.
> Doesn't scale. Having passwords in a plain text file is not a scalable solution for users directory. Can probably go up to a hundred users, but not much more.
This simply cannot be true. A users directory that is frequently read will be in cache. The file is also fairly simple to parse. Even on old hardware you should be able to parse thousands of users.
It's more of a problem of the number of nodes your users will be accessing than the number of users. It's a PITA to make mechanisms for password changes, for adding and removing users, for unlocking accounts, etc. when you have a distinct file on each server that needs to be changed. As well as adding new nodes to the environment and bringing them up to date on the list of users and etc.
Fair point, networking always makes things more complicated. I'm not sure it's really that much more complicated though. Like any concurrency problem with shared state, a single-writer and multiple readers keeps things simple, eg. a single host is authoritative and any changes are made there, and any file changes trigger automated scripts that distribute the changed file over NFS, FTP, etc.
As long as new nodes start with the same base configuration/image this seems manageable. Simple to do with inotify, but even prior to that some simple C programs to broadcast that a change is available and listen for a change broadcast and pull the changed file is totally within the realm of a classic sysadmin's skillset.
You would have to lock the file, or guarantee consistency in some other way. Right now, I don't believe Linux does anything about consistency of reads / writes to that file... which is bad, but we pretend not to notice.
So... the system is kind of broken to begin with, and it's kind of pointless to try to assess its performance.
Also, it would obviously make a lot of difference if you had a hundred of users with only a handful being active users, or if you had a hundred of active users. I meant active users. Running programs all the time.
NB. You might have heard about this language called Python. Upon starting the interpreter it reads /etc/passwd (because it needs to populate some "static" data in os module). Bet a bunch of similar tools do the same thing. If you have a bunch of users all running Python scripts while there are some changes to the user directory... things are going to get interesting.
> You would have to lock the file, or guarantee consistency in some other way.
I think the standard approach to atomicity is to copy, change the copy, then move that copy overwriting the original (edit: file moves are sorta atomic). Not perfect but generally works.
I agree that this approach is not good for a users directory, I'm just disagreeing that the reason it's not good is performance-related.
Moves are atomic. During the move, at no time is it possible to get the contents of file 1 and file 2 confused when reading from the file descriptors. (Confusion by the human operating things is eminently possible.)
Most systems come with "vipw" which does the atomic-rename dance to avoid problems with /etc/password. In practice this works fine. Things get more complicated when you have alternate PAM arrangements.
A whole bunch of standard functions like getpwents() are defined to read /etc/password, so that can't be changed.
`getpwents()` is not defined to only read `/etc/passwd`. There is only a requirement that there is some abstract "user database" or "password database" (depending on if you're reading the linux man pages or the Single Unix Specification man pages).
In practice, `getpwent` on linux uses the nsswitch mechanism to provide return values from `getpwent`. One can probably disable using `/etc/passwd` entirely when using glibc if: all users do use `getpwent`, and you remove `files` from the `passwd` entry in `/etc/nsswitch.conf`.
I had >30k users on a bunch of systems in 2001 (I inherited that approach, mind, I'm not -recommending- it).
We moved to LDAP a couple years later because it was a much nicer architecture to deal with overall, but performance and consistency weren't problems in practice.
This file is a public interface exposed by Linux to other programs. So what if Linux caches its contents when eg. Python interpreter on launch will read this file. And it's not coming from some "fake" filesystem like procfs or sysfs. It's an actual physical file most of the time.
> which makes it very difficult to contain users to things they should control
It's not the file system that's the problem here, it's that "everything is a file" is not true for a whole bunch of important stuff that you might want to apply access control to on a UNIX system. Such as the right to initiate TCP connections. This sort of thing is why containers are so popular.
NIS and LDAP do let you have a large number of users. Heck, we managed a few thousand users in /etc/password back when I was running https://www.srcf.net/ .. in 2000.
> it's not the file system that's the problem here, it's that "everything is a file" is not true for a whole bunch of important stuff that you might want to apply access control to on a UNIX system
I wonder if there has ever been an attempt to really lean into, and push the limits of sticking with the "everything is a file" philosophy in this realm.
I.e. how far could you get with having special files for fine grained permissions like "right to initiate a TCP connection", and making access control management be, essentially, managing which groups a user belonged to?
But in reality a file is not a good abstraction for an internet socket. The ACLs would in essence spell out firewall rules. Because the bigger question is where can it connect to than "user" that is connecting.
That's why this is done on the level of kernel networking, where kernel knows what process is trying to open a socket and can firewall it.
This sounds like a completely unrelated thing and you are not constrained by the plain text password/shadow file for scale. NIS existed for many decades. You can even use Active Directory (or samba) for authentication and user management.
This shows you either didn't read what you replied to or don't understand the subject.
This file is the public interface of the Linux system to everyone who wants to get information about users on the system. It doesn't matter that alternative tools exist: they were already mentioned in the post you replied to. It's not the point...
If I didn't understand I'd be grateful if you could explain it.
As far as I know that file does not get referenced for the users in an external directory server. That's how the systems scale without needing to put the users in the file. Aren't we talking about a high number of users (and their authorization levels) when talking about scalibility in this case?
I've wondered why we don't have a passwd.d folder, the way we do with other things in the UNIX filesystem, with individual user accounts represented by individual files. Could even retain the same line-oriented format, just stored separately.
> * Doesn't scale. Having passwords in a plain text file is not a scalable solution for users directory. Can probably go up to a hundred users, but not much more.
Why not? A file 100,000 line file will only take a moment to scan.
If you have services with even a few users you should set up LDAP (openldap is fine) and then experiment with it.
LDAP is pretty old and very well supported overall. At one point I configured ldap for postfix virtual hosting. I chose LDAP rather than a database backed solution because of widespread first class support everywhere. The same directory later enabled me to use a ton of other things including SSO. You're always finding new ways to use it once you have it.
It's a great skill to have and is nowhere near as complicated as people make it out to be, including live replication.
When Gwen Shotwell was asked about the acronym BFR on international television, she replied "Big Falcon Rocket". Lovely response, quite dependent on context!
This is like how I use 'ofc' to abbreviate 'of course'. Once upon a time the 'f' may have stood for something, but I never use it that way. For me, 'the F is silent'.
In polite company you say "The article" or "read the manual" and patiently await your reward, which is their asking "what does the 'F' stand for?", to which you reply only with a condescending look and raised eyebrow(s).
That look of realisation is precious.
I've manufactured this experience once or twice, and it's wonderful.
Digestible maybe, but swapping "friendly" in for "fucking" changes the tone and intent of someone's statement. At least "freaking" expresses similar, if muted, exclamation.
A recipient who is being not-so-subtly reproached with an F-bomb acronym might misunderstand what is being implied.
> saying “read the article” which is against the guidelines here
The guidelines say that you should not accuse someone of not having read the article. However, as the guidelines say it is fine to point out that something is mentioned in the article.
There is a subtle difference.
From the guidelines:
> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that".
Parent comment was in line with the guidelines IMO.
And as for “TFA” as an acronym I like to read it as meaning “The Featured Article”. Then it seems nice and friendly.
I'd assume any code in a non-memorysafe language that parses any freeform data entered by the user is a potentially exploitable security vulnerability, so an interactive shell is a huge surface area for attacks?
Yes, but irrelevant here. Basically any shell access means you've changed from preventing remote code execution to preventing privilege escalation, which is much harder.
If you fuck up the sudo file while saving it, you might no longer be able to log in to fix it. Before I knew about sudoedit I would open two shells as root, edit the file, then use a third window to make sure I could still sudo.
With two windows I could accidentally close the subshell in one without locking myself out. Think if it like linemen, who use two tethers for climbing structures. They are never detached from the safety lines.
1. system: in the context of setting up secure remote access to a Unix-like system, discuss whether relying on the passwd file and shell behavior as an effective means of authentication and access control is a good approach. What are some reasons this is not (or is) an effective approach, which should not (or should) be used on modern production systems. user: system administrator on a Unix-based network. assistant: technically, there are several reasons...
2. If you have a collection of Unix systems, can you reasonably do a certain amount of access control to your overall environment by forcing different logins to have specific administrative shells?
Last time it might've been effective was probably in old-school Unix time sharing with users connected via tty's rather than TCP/IP. Already early SQL databases, with the possible exception of Informix SE, had a client/server process model where the server process had full access to all data files and would at best authenticate sessions but not individual accesses against /etc/passwd such as via Oracle's pipe/bequeather connector but more commonly would assume fixed global roles and handle auth on the app side. As soon as IP and "services" were introduced, /etc/passwd stopped being effective, as pointed out by bluetomcat [1]. Actually, even gaining shell access is considered game over from a security PoV, due to multiple privilege escalations.
It was effective for a ftp server accessing public directories in the home of users. I can't remember the details but you would use the username and password of the user to exchange files with and get into that directory. All transmitted as cleartext, of course.
30+ years ago we already had services (daemons!) with their own user id, to keep them isolated from root and the human users. This post is as news as the invention of hot water.
I imagine that (at least) 2 things have happened to Google Search.
1. SEO content farmers have filled it up with low quality results.
2. Google used ML to tune the system and it optimized for the lowest common denominator, incompetent searchers.
The average person never learned how to construct succinct search queries and so habitually enters too little or too much into the search box. Current Google Search wants to help the poor searcher so it adjusts their entry, or in some cases rewrites it completely, before processing it and returning results it has decided that they really want.
That's why I laugh when I see they want to charge a subscription for this. It's easy enough for any competent developer to take available open source tools and crank out something to meet their needs in an afternoon.
Before UTM came out I was using xhyve with a little custom scripting. Not a solution for the masses but good enough for me.
That's the "I could implement dropbox with sftp and rsync in an afternoon" response. It's nice not to have to, and people can be forgiven for exchanging money for time.
It’s $10, so they’re clearly also not unaware of the effort needed to support software. It’s fine for different people to have different takes on a common concept and let the market sort it out.
I have the skills to build it myself from source and sideload (mostly dealing with Apple's obnoxious code signing certificate infrastructure), but will gladly pay the $10 to fund the development. Too bad the iOS version of UTM is not available on the iOS App Store and forces sideloading. I might get around to installing it on my iPad one day (there is the excellent QEMU-based iSH on the App Store, however).
I’m so fed up of paying for software subscriptions. If I can choose between a single payment and a subscription service, I go for the one-shot every time. I don’t even know how to describe it, but it just nauseates me at this point. I’ve also cancelled Netflix and Amazon Prime is not going to be renewed either. I know it’s irrational but I’ve just been pushed to the brink.
As an average Joe, if I see a one-off fee of $60, it seems like a lot of money upfront and makes the decision hard and may be if I stall a but, I will forget about the whole thing by next weekend.
Compare that to $5/month, doesn’t look so bad, I spend that amount for a good coffee and donut daily… let me enter my credit-card there… eventually I forget about this in one week but am continued being charged and there are too many little charges for me to go over and figure out where my money is going.
This subscription model is a psychology hack to reduce the resistance of general people and not targeted at us, who try to be extra cautious about the value proposition over long term.
P.S. I attended some marketing fluff seminar from big honcho sales people as part of business trip, thought I’d share it about where this sudden rise of subscription model came from.
That's not typically where the software industry sets the one-time purchase though. 18-30 months is more typical. In your example that would be $5/mo for software costing between perhaps $100-150.
If it's set correctly, and the software is actually valuable enough to be worth something, there's a more balanced tradeoff between the risk of overpaying and underpaying and the benefit of the subscription acting like an inexpensive trial that will likely convert to a one-time purchase if the buyer is budget-minded.
(That said, it's certainly true that you can approach the same pricing strategies fairly or greedily; I've overheard both.)
Yeah, I refuse to buy any product that requires a subscript simply to be able to use it. A subscription should bring new value every month, like a magazine. I'm OK with subscribing to streaming video services as long as they keep updating the content.
I mostly run open source at this point because I'm also tire of everything commercial having telemetry built in.
Yeah that’s a good point: if substantial value is added every month (as in a streaming service), a subscription model is not quite so offensive. Subscription models for software that remains essentially static (aside from bug-fixes and occasional features) is just a rip-off. And yes, I understand that these folks need a constant revenue stream to pay their bills… but so does everybody else, including the mom & pop grocery stores that have to get by with whatever margin they make on the goods they sell and don’t have the option of charging for a monthly membership just to have the privilege of walking through their door.
This crap has to stop. I’ve stopped paying for subscriptions. Hopefully I’m not the only one and revenues will be impacted enough for developers to react.
I’m sure I’ll draw substantial ire from developers here who depend on the subscription model but I don’t really care. You have monthly expenses for your AWS services? Mom & pop pay for rent. Unlike them you can probably re-architect your app to rely on on-device processing. I’m through with this crap.
Afternoon of a competent developer is a cost of $500-2000. If the subscription is $4.99 a month, in the cheapest scenario you would need 8 years to accrue $500.
It's very unlikely that a developer is going to spend 8 years at one company, so spending afternoon on this is a false economy.
Unless you want to learn something and perhaps start selling similar product on the side...
$2000 seems very expensive for an afternoon unless you’re making $1M/year. The other thing missing from your calculus to consider is that it’s a learning opportunity which offsets the actual time for creating it.
Also, plenty of people have hobbies. That’s why we have OSS.
$2000 a day is a standard rate for a short term assignment, I know people who charge this much for software development services.
That being said it's more likely you would look at $500.
> The other thing missing from your calculus to consider is that it’s a learning opportunity which offsets the actual time for creating it.
You are also learning while you are being paid for doing it.
> Also, plenty of people have hobbies. That’s why we have OSS.
OSS is being popularised by big corporations because it saves them money on R&D in the long run. Otherwise they would have to pay for a lot of development of projects that would not necessarily be a success within the company. Instead they can pick and choose from projects already "preselected" for them by the community and written by gullible developers who are unlikely going to get even a tiny fraction of money made on their software.
Don't get me wrong OSS is great, but it should be illegal for businesses to use it without paying royalties, otherwise it's just a pure exploitation.
For some reason there is this notion "if it is a someone's hobby then they shouldn't charge money for it". In my country you have to at least pay someone a minimum wage.
It works great for my needs. I mostly develop infrastructure automation and configuration tooling and I run all my VMs in terminal mode. The wide availability of arm64 distros and OSes makes this easy.
I also use it to run a tiny pi hole instance when I'm traveling.
May I recommend a Dell Wyse thin client from eBay as a replacement for the rPi? They can be had for around $30, and they come with an 8GB onboard eMMC storage as well.
What's the advantage of spinning up an entire VM to run a local Pi Hole instance instead of just setting up a firewall or using a browser blocker like uBlock Origin? I was under the impression that spinning up a Pi Hole instance is really only necesary if you own devices which don't allow for such things, like smart TVs and other internet-connected appliances.
In my recent experience, Google search is totally broken for anything that is hard to find or uncommon.
I recently search for "raspberry pi uart hat" and Google responds with the following:
Not many results include the word "uart" so we eliminated it from your search terms. Here are thousands of irrelevant results about random raspberry pi hats you aren't interested in.
I'm starting to see a lot of products in "beta" that seem to be little more than a very thin wrapper around ChatGPT. So thin that it is trivial to get it to give general responses.
I recently trialed an AI Therapy Assistant service. If I stayed on topic, then it stayed on topic. If I asked it to generate poems or code samples, it happily did that too.
It felt like they rushed it out without even considering that someone might ask it non-therapy related questions.
I’m happy to believe that the therapy was ineffective, but I don’t necessarily understand why going off topic is bad. In my experience, I had a lot of conversations with therapists that were ‘off topic.’
I’ve definitely talked poetry and writing with a therapist, and while I’ve never had my therapist provide code, we’ve definitely talked tech in great detail.
Maybe those therapists were intentionally making me comfortable by engaging with shared interests. And the LLM isn’t being intentional about it, but I’m not convinced that a therapist is ineffective if they fail to stay ‘on topic’ when directed off topic by their patient.
To extrapolate from my own company and the orders we got from the suits, it basically boils down to them saying "Been hearing about this fancy Chat AI thing, can you whip up something like that quick so we can put out a press release saying $COMPANY is doing AI as well?".
Most corpos couldn't give a rat's ass about it, it's just the fancy new toy on the block that's saturating everyone's newsfeeds so they have to jump on it lest they be left in the dust by the competition who are doing the exact same shit, aka calling the "Open"AI APIs and pretending they're doing something groundbreaking.
We got interrupted mid-sprint, mid-epic to make some shitty wrapper around their APIs. I suspect the overwhelming majority of companies with fancy new "AI" features are doing the exact same shit
There's no way to avoid that except training your own model. It will, likely, always be possible to jailbreak chatbots, or just steer the conversation off course. That's why you must never give them direct access to anything.
I don't see the purpose of this. You will add an additional prompt (cost + latency) just to check if the user is on topic. Why? Why do we need to prevent the users of the therapy bot from generating poems or code samples? Shouldn't we rather spend our efforts optimizing the intended use case?
For me this article joins a long list of "I don't believe in X" where the author has apparently only experienced bad versions of X.
Most of the time with the articles, the answer to "X done poorly" is to switch to "Y done well" but doing X well would have likely worked too.
Personally, my most enjoyable job as an engineer was when I worked on a project by myself in 1 week sprints. I spoke to my manager twice a week: 15-30 minutes Monday morning for "sprint kickoff" and 15-30 minutes Friday afternoon for "sprint wrap up" and how I spend the rest of the week was up to me. When a second more senior engineer joined the project it was even more enjoyable to work on it together in the same sprint format.
I have been an engineering leader for over 10 years and in all this time I received almost no training or coaching. I was pulled up from my role as an engineer.
For the past 6 months I have been working with a remote leadership coach and it has been incredible! My coach is extremely experienced and alternates between prompting me to solve my own challenges and sometimes just telling me what to do in a given situation.
I highly recommend it to anyone in a leadership or management role.
I work for a German company and am responsible for GDPR implementation. I would not suggest following the advice in the article. It is full of mistakes and bad advice and would easily put you at risk for a law suit, at least in Germany.
If you are coming at this from any perspective other than "what is the minimum data I need to collect to run my service" then you aren't following the GDPR.
I've noticed that a lot of US based companies claim GDPR compliance but when you read their privacy policy, they clearly aren't compliant. The biggest violations come from what companies try to claim as "legitimate interest." Things such as analytics tracking, that are not tied to service delivery, are not acceptable under legitimate interest. Sharing my visit with Meta will never be legitimate interest. And so on.
I took a look at their privacy policy and the company behind this blog isn't even GDPR compliant, despite their claims. Note the following from their privacy policy:
"Research and analysis - We may process usage data and/or transaction data for the purposes of researching and analysing the use of our website and services, as well as researching and analysing other interactions with our business. The legal basis for this processing is our legitimate interests, namely monitoring, supporting, improving and securing our website, services and business generally."
This for of tracking requires consent. It cannot be justified as legitimate interest. Even this questionable blog post itself says so "Why: Because analytics is not required in order for the site to function."
edit: typos
Their site never asked for my consent.
If I need a car for some unusual errand, which is rare like once a year, I use an app to cheaply rent a car of the needed size for a few hours.
Recently had to go to the US for a short trip and I had to rent a car. It felt insane how much time I had to spend in my car just to visit people who all live in the same metro area, due to all the sprawl.