Historically, these have been issued by "consumer credit" specialized banks like Sofinco; and retail chains ("carte Aurore"); traditional banks would seldom advertise them, if offered at all.
Things have been changing a bit in recent years. Since the "debit" and "credit" nature of the card is now written on them, French folks have started to request "credit" ones for travelling (to rent a car for instance).
My understanding is that for car rental purposes, anything using Visa/MC (and not a national debit network like Visa Debit in the US) will work, it doesn't actually need to be backed by a revolving credit. At a US gas pump, a Frenchie needs to select "credit" even though the card has "debit" written on it. Still, should the clerk refuse the card because it reads "debit" without running it... better have this "credit"-labeled one.
> My understanding is that for car rental purposes, anything using Visa/MC (and not a national debit network like Visa Debit in the US) will work, it doesn't actually need to be backed by a revolving credit.
Many companies will refuse all debit cards, or all cards with "electronic use only" restriction, at least for the deposit, irrespective of the payment network involved.
The "they" is any corporation that has an interest in the user not controlling their system, and whom this technology caters to. This sea has plenty of fish already. Streaming services serving Hollywood content, banks, dating apps...
Lastly I even faced another one. Something as simple as a gym token wants GMS, attestation and GPS positioning because it treats its users as liars prima facie. That's the new norm this attestation enables. No conspiracy needed, simple business interest and greed to juice "customers" to the last penny drives you there.
You're on a tangent from the discussion you're replying to. Individual services get to decide requirements for their users, but that's not at all the same as "banning" KeePassXC from the entire ecosystem.
Like, there are lots of services that require SMS or email link MFA. I guess KeePassXC is just banned from everything, then?
To repeat, the GitHub issue digiown linked is not a threat to ban KeePassXC. A random guy from Okta doesn't have that power. Okta itself doesn't have that power or want to have that power. The GitHub issue is simply a description of what attestation is.
OPs point is that we shouldn't allow "individual services get to decide requirements for their users". If the spec requires being implemented in a way that allows that, it's a user-hostile spec.
That wasn't their point and is orthogonal to their misunderstanding of the GitHub issue where, again, no threat is being made.
But in any case services do get to decide, because the service runs on someone else's computer, not yours. You get to decide what happens on your computer, they get to decide what happens on theirs.
> any IP in a /64 is the same as a single IP in a /32 in IPv4
This is very commonly true but sadly not 100%. I am suffering from a shared /64 on which a VPS is, and where other folks have sent out spam - so no more SMTP for me.
That's the thing. I can only provide a piece of software with the guarantee it can run on my OS. It can trust my kernel to let it run, but shouldn't expect anything more. The editor is free to run code it wants to guarantee the integrity of on its own infrastructure; but whatever reaches my machine _may_ at best run as the editor intends.
Please don't bring attestation to common Linux distributions. This technology, by essence, moves trust to a third party distinct of the user. I don't see how it can be useful in any way to end users like most of us here. Its use by corporations has already caused too much damage and exclusion in the mobile landscape, and I don't want folks like us becoming pariahs in our own world, just because we want machines we bought to be ours...
A silver lining, is it would likely be attempted via systemd. This may finally be enough to kick off a fork, and get rid of all the silly parts of it.
To anyone thinking not possibile, we already switched inits to systemd. And being persnickety saw mariadb replace mysql everywhere, libreoffice replace open office, and so on.
All the recent pushiness by a certain zealotish Italian debian maintainer, only helps this case. Trying to degrade Debian into a clone of Redhat is uncooth.
> A silver lining, is it would likely be attempted via systemd. This may finally be enough to kick off a fork, and get rid of all the silly parts of it.
This misunderstands why systemd succeeded. It included several design decisions aimed at easing distribution maintainers' burdens, thus making adoption attractive to the same people that would approve this adoption.
If a systemd fork differentiates on not having attestation and getting rid of an unspecified set of "all the silly parts", how would they entice distro maintainers to adopt it? Elaborating what is meant by "silly parts" would be needed to answer that question.
Attestation is a critical feature for many H/W companies (e.g. IoT, robotics), and they struggle with finding security engineers who expertise in this area (disclaimer: I used to work as a operating system engineer + security engineer). Many distros are not only designed for desktop users, but also for industrial uses. If distros ship standardized packages in this area, it would help those companies a lot.
This is the problem with Linux in general. It's way too much infiltrated by our adversaries from big tech industry.
Look at all the kernel patch submissions. 90% are not users but big tech drones. Look at the Linux foundation board. It's the who's who of big tech.
This is why I moved to the BSDs. Linux started as a grassroots project but turned commercial, the BSDs started commercial but are hardly still used as such and are mostly user driven now (yes there's a few exceptions like netflix, netgate, ix etc but nothing on the scale of huawei, Amazon etc)
Linux has been majority developed by large tech companies for the last 20+ years. If not for them, it would not be anywhere close to where it is today. You may not like this fact, but it's not really a new development nor something that can be described as infiltration. At the end of the day, maintaining software without being paid to do so is not generally sustainable.
As a complete guess, I would say that 90% of Linux systems are run by "big tech drones". And also by small companies using technology.
Open source operating systems are not a zero sum game. Yes there is a certain gravitational pull from all the work contributed by the big companies. If you aren't contributing "for-hire", then you choose what you want to work on, and what you want to use.
General purpose operating systems are fine and in some cases, preferable. However, they should be small, simple and designed with first class portability. Linux is none of those.
Why shouldn't they use the kernel, systemd, and a few core utilities? Why reinvent the wheel? There's nothing requiring them to pull in a typical desktop userspace.
Because different tasks requires different trade-offs and Linux has only one set of trade-offs. You cannot do good universal tool. It is like Leatherman, good enough to fix-up your bike on the side of the road, not so for normal workshop.
You say: reinvent the wheel.
I say: use pickup truck for every task, from farming to racing to commuting moving goods across continent. Is it possible? Of course. Is it good idea? I don't think so.
All cars are the same if you squint enough, wheels, engine, some frame, some controls, which are not very different between even F1 car and 18-wheel truck.
I agree but it's difficult to argue against it. There is just so much you get for free by starting with a Linux distro as your base. Developing against alternatives is very expensive and developing something new is even more expensive. The best we can hope for is that someone with deep pockets invests in good alternatives that everyone can benefit from.
How are you defining "general-purpose OS"? Are you saying IoT and robotics shouldn't use a Linux kernel at all? Or just not your general purpose distros? I would be interested to hear more of your logic here, since it seems like using the same FOSS operating system across various uses provides a lot of value to everyone.
I think, that I want at least hard-real-time OS in any computer which can move physical objects. Linux kernel cannot be it: hard RTOS cannot have virtual memory (mapping walks is unpredictable in case of TLB miss) and many other mechanisms which are desired in desktop/server OS are ill-suited for RTOS.
Scheduler must be tuned differently, I/O must be done differently. It is not only «this process have RT priority, don't preempt it», it is design of whole kernel.
Better, this OS must be verified (as seL4). But I understand, that it is pipe dream. Heck, even RTOS is pipe dream.
About IoT: this word means nothing. Is connected TV IoT? I have no problems with Linux inside it. My lightbulb which can be turned on and off via ZigBee? Why do I need Linux here? My battery-powered weather station (because I cannot put 220v wiring in backyard)? Better no, I need as-low-power-as-possible solution.
To be honest, O think even using one kernel for different servers is technically wrong, because RDBMS, file server and computational node needs very different priories in kernel tuning too. I prefer network stack of FreeBSD, file server capabilities (native ZFS & Ko) of Solaris, transaction processing of Tandem/HPE NonStop OS and Wayland/GPU/Desktop support of Linux. But everything bar Linux is effectively dead. And Linux is only «good enough» in everything, mediocre.
I understand value of unification, but as engineer I'm sad.
I'm not too big in this field but didn't many of those same IOT companies and the like struggle with the packages becoming dependent on Poeterings work since they often needed much smaller/minimal distros?
I don't think this is generally true. If you are running Linux in your stack, your device probably is investing in 1GiB+ RAM and 2GiB+ of flash storage. systemd et al are not a problem at that point. Running a UI will end up being considerably more costly.
Sure, but devices that do that are not running a Linux distro off the shelf. They are creating something custom with the minimal amount of dependencies possible.
I work on embedded devices, fairly powerful ones to be fair, and I think systemd is really great, useful software. There's a ton of stuff I can do quite easily with systemd that would take a ton of effort to do reliably with sysvinit.
It's definitely pretty opinionated, and I frequently have to explain to people why "After=" doesn't mean "Wants=", but the result is way more robust than any alternative I'm familiar with.
If you're on a system so constrained that running systemd is a burden, you are probably already using something like buildroot/yocto and have a high degree of control about what init system you use.
You already trust third parties, but there is no reason why that third party can't be the very same entity publishing the distribution. The role corporations play in attestation for the devices you speak of can be displaced by an open source developer, it doesn't need to require a paid certificate, just a trusted one. Furthermore, attestation should be optional at the hardware level, allowing you to build distros that don't use it, however distros by default should use it, as they see fit of course.
I think what people are frustrated with is the heavy-handedness of the approach, the lack of opt-out and the corporate-centric feel of it all. My suggestion would be not to take the systemd approach. There is no reason why attestation related features can't be turned on or off at install time, much like disk encryption. I find it unfortunate that even something like secureboot isn't configurable at install time, with custom certs,distro certs, or certs generated at install time.
Being against a feature that benefits regular users is not good, it is more constructive to talk about what the FOSS way of implementing a feature might be. Just because Google and Apple did it a certain way, it doesn't mean that's the only way of doing it.
Whoever uses this seeks to ensure a certain kind of behavior on a machine they typically don't own (in the legal sense of it). So of course you can make it optional. But then software that depends on it, like your banking Electron app or your Steam game, will refuse to run... so as the user, you don't really have a choice.
I would love to use that technology to do reverse attestation, and require the server that handles my personal data to behave a certain way, like obeying the privacy policy terms of the EULA and not using my data to train LLMs if I so opted out. Something tells me that's not going to happen...
I’m skeptical about the push toward third-party hardware attestation for Linux kernels. Handing kernel trust to external companies feels like repeating mistakes we’ve already seen with iOS and Android, where security mechanisms slowly turned into control mechanisms.
Centralized trust
Hardware attestation run by third parties creates a single point of trust (and failure). If one vendor controls what’s “trusted,” Linux loses one of its core properties: decentralization. This is a fundamental shift in the threat model.
Misaligned incentives
These companies don’t just care about security. They have financial, legal, and political incentives. Over time, that usually means monetization, compliance pressure, and policy enforcement creeping into what started as a “security feature.”
Black boxes
Most attestation systems are opaque. Users can’t easily audit what’s being measured, what data is emitted, or how decisions are made. This runs counter to the open, inspectable nature of Linux security today.
Expanded attack surface
Adding external hardware, firmware, and vendor services increases complexity and creates new supply-chain and implementation risks. If the attestation authority is compromised, the blast radius is massive.
Loss of user control
Once attestation becomes required (or “strongly encouraged”), users lose the ability to fully control their own systems. Custom kernels, experimental builds, or unconventional setups risk being treated as “untrusted” by default.
Vendor lock-in
Proprietary attestation stacks make switching vendors difficult. If a company disappears, changes terms, or decides your setup is unsupported, you’re stuck. Fragmentation across vendors also becomes likely.
Privacy and tracking
Remote attestation often involves sending unique or semi-unique device signals to external services. Even if not intended for tracking, the capability is there—and history shows it eventually gets used.
Potential for abuse
Attestation enables blacklisting. Whether for business, legal, or political reasons, third parties gain the power to decide what software or hardware is acceptable. That’s a dangerous lever to hand over.
Harder incident response
If something goes wrong inside a proprietary attestation system, users and distro maintainers may have little visibility or ability to respond independently.
I can see usefulness if the flow was "the device is unlocked by default, there are no keys/certs on it, and it can be reset to that state (for re-use purpose)"
Then the user can put their own key there (if say corporate policies demand it), but there is no 3rd party that can decide what the device can do.
But having 3rd party (and US one too!) that is root of all trust is a massive problem.
The giveaway is that LLMs love bulleted lists with a bolded attention-grabbing phrase to start each line. Copy-pasting directly to HN has stripped the bold formatting and bullets from the list, so the attention-grabbing phrase is fused into the next sentence, e.g. “Potential for abuse Attestation enables blacklisting”
Calling this a "giveaway" is kind of hilarious. LLMs use bulleted lists because humans have always used bulleted lists—in RFCs, design docs, and literally every tech write-up ever. Structure didn't suddenly become artificial in 2023. lol.
You will be able to do this kind of filtering only on systems where you'll be allowed to run arbitrary code. This capability will be exclusive from running mainstream apps, because of device attestation.
The 10-year-old me is still trying to understand why altering the lyrics of his song, in the metadata of a WMA file, does not change what's heard on the record...
Byrne has to be a landmark in the personal history of many of us with computers.
> People complain about lack of space, misc fees etc. But when it comes down to it, people for the most part, still pick the cheapest flight.
This is true. One thing I note is that with the same dollar amount, you get even less legroom, luggage, etc. today than you used to back 10-15 years ago on traditional airlines. Granted the airline costs rose over time, but it's hard to imagine they went up to the scale traditional airfare has increased at equivalent service levels... Also the fact that things that used to be included are now considered "extra" looks like a good excuse for folks to complain about.
He indeed used to speak about him in the third person and would casually say "Alain Delon did this" (instead of "I did this"). He was widely mocked for it but he claimed it was a sign of "humility" (?!) because it was a way to avoid using "I" or "me"...
He became a huge international star in 1960 with Purple Noon, the first (of many) adaptations of Patricia Highsmith's The Talented Mr. Ripley. He was 25 and from that moment onward was recognized the world over as the sexiest and most handsome man alive. He continued to work with some of the most acclaimed European directors and starred in over 80 movies.
It's probably difficult to handle that level of fame and stardom if you're not prepared for it (or even if you are).
I even had a teacher in the States who referred to herself in the third person, so it had been a thing there too, but she (~1915?) was from a generation before Delon (1935).
Things have been changing a bit in recent years. Since the "debit" and "credit" nature of the card is now written on them, French folks have started to request "credit" ones for travelling (to rent a car for instance).
My understanding is that for car rental purposes, anything using Visa/MC (and not a national debit network like Visa Debit in the US) will work, it doesn't actually need to be backed by a revolving credit. At a US gas pump, a Frenchie needs to select "credit" even though the card has "debit" written on it. Still, should the clerk refuse the card because it reads "debit" without running it... better have this "credit"-labeled one.