Unfortunately this sounds like a typical pro-Linux rant with the usual scare words such as "Microsoft", "UEFI", "secure boot", etc. To be clear, I am attacking the piece itself, not the author.
The reason there is no explicit threat model defined in the TPM specs is because it defines a general-purpose hardware security module. It is up to integrator to define the threat model (TPM's security properties also depend on the rest of the system) and the application.
Even if a TPM is not perfect and depends on other pieces of the puzzle to also be secure, it at least opens the possibility of making it secure in the future once those vulnerabilities are discovered & fixed. Furthermore, even in this vulnerable state, it still increases the effort required for a successful attack.
Support for TPM-backed full disk encryption means you can now have FDE on by default for everyone with no usability impact at all. Even if it's not secure and a dedicated attack will still break it, it means a casual attacker can't just pull a drive or reboot the machine and run chntpw or steal sensitive data from discarded drives that haven't been properly wiped.
I like TPMs. I like the fact that a rogue datacenter employee or intruder can't just pull one of my servers' drives out and get sensitive data. I like not having to worry about having sensitive keys on the filesystem somewhere because every secret is in memory and is ultimately derived from the TPM doing remote attestation at boot and handing ephemeral keys. I like not having to worry about unattended reboots or entering LUKS passphrases remotely.
While that's a very good use case, the desired one where you're not allowed to use the Internet unless you're using a big three approved device that can attest you're not using an ad blocker isn't so much.
What's the point of TPM-backed full disk encryption with no usability impact (meaning password/pin-less) for the average user who is more likely to get their device stolen vs some covert disk image shenanigan?
> This sounds like the rant of a typical Linux fanboy
Hi, it's me the Linux fanboy whose entire personality is making Hackintosh and VM apps for iOS. Just a friendly reminder that attacks on the author's credentials have no baring on the weight of the arguments.
> The reason there is no explicit threat model defined in the TPM specs is because it defines a general-purpose hardware security module
It sounds like you have zero experience in security :)
> it defines a general-purpose hardware security module
No it doesn't. I think you're hinting at HSM which is another beast I may write another fanboy FUD piece about at some point. But no, HSMs are not the same as TPMs. And TPMs are not HSMs. For one thing, and HSM defines something called a trust boundary where keys should never leave. TPMs will happily hand you the keys when you meet a certain condition. HSMs support key migration and provides a secure way to transfer keys from one HSM to another without leaving the trust boundary. I can go on and on...
> TPM's security properties also depend on the rest of the system
The argument isn't TPM versus no security. The argument is TPM versus the existing security you have on Windows. (Passwords, FDE, etc). Of course all this depends on the system. TPM doesn't add anything (* with the exception already listed in the article).
> it at least opens the possibility of making it secure in the future once those vulnerabilities are discovered & fixed
Nope. Architecturally flawed. But I'd just be repeating the argument from the article.
> means a casual attacker can't just pull a drive or reboot the machine and run chntpw or steal sensitive data from discarded drives that haven't been properly wiped
They can with a $80 FPGA. Read the appendix.
> I like the fact that a rogue datacenter employee or intruder can't just pull one of my servers' drives out and get sensitive data.
They can with a $80 FPGA. (Unless your datacenter uses Intel TXT and tboot and other prerequisites that were talked about in the article)
> I like not having to worry about having sensitive keys on the filesystem somewhere
If you use BitLocker, they are always in kernel memory
> derived from the TPM doing remote attestation at boot
That's not what "remote attestation" means :)
> I like not having to worry about unattended reboots or entering LUKS passphrases remotely
If you like that, just disable your password and you'll get the same result
I might be a bit ignorant towards the topic but so far everything I've seen about TPM has no actual benefits for the home user. For cloud, sure, there are benefits.
It seems like it's a sunken cost fallacy that big tech spent a lot of money on and they are trying to get it back by convincing average Joe that a TPM is good for your PC.
you are right that tpm and such technologies are a right step, you have to start somewhere. (i know it didnt start at tpm ofcourse).
The author is also right that some claims are too markety while in the real world device are still vulnerable. The piece also goes on to say theres further efforts such as TXT etc. taking place, so in essence for me it reads like you mostely agree. microsoft, uefi etc. arent scare words here imho, they are very closely related to claims made and technologies involved.
I thought the piece was ok, but it doesnt add anything new. its another piece pointing at the puzzle a lot of people including you already know exists. its not aimed at you for that matter. (so fair comments, but perhaps a bit harsh?)
There are two issues. One is a false sense of security. You think that you have the same level of security of a full disk encryption, but you don't. On a full disk encryption only who knows the password can access your data. On this system the disk is automatically decrypted at boot, so any flaw in Windows that permits a privilege escalation done by that PC can give access to your data.
If somebody that wants your data steals your PC he will be likely to find a way to access your personal data. It's a protection against a casual thief that is probably not interested in your data and can't probably even figure out how to bypass the Windows password screen.
But if this doesn't make harm, why not have it? Because having disk encryption enabled by default to a user that doesn't know that is enabled by default is not necessary a good thing. Let's face it: users don't do backups. I know even companies that have all their data on a single server with no backups.
Now if the motherboard breaks and you don't have backup... you can't just take the disk out of that computer, connect to another PC and recover the data. You have lost your data!
But wait, you say Microsoft tought about that, indeed if you signed in with a Microsoft account you can recover your Bitlocker encryption key from the Microsoft portal... wait what? Exactly. No security at all! Microsoft knows your encryption keys and it stores it on their servers... again: false sense of security is worse than no security at all!
Finally, even if this system was 100% secure: do you trust the hardware? The same hardware produced by the same manufacturer of the products where nearly once in a year a big security flaw is discovered? The same hardware where we know that the NSA, and probably other government agencies, placed backdoors?
Whatever, typing a password when booting up the computer (that is once in a day) is such a big deal?
Likewise, I am not too concerned about the NSA breaking into my laptop. I just want that if some kid finds it and tries to plug the SSD into his computer, my files aren't all there to be read.
> You can also use the TPM + PIN as a sort of Yubikey
That's not zero. In my mind that's the main thing a TPM is really useful for. It's a secure enclave for a private key used for U2F/WebAuthn style attestation. I agree that the threat model not being explicitly discussed is a huge miss. But to that point, a TPM is still useful because it prevents someone who has hacked into my computer from commanding the TPM's authentication factor.
The other useful application is to prevent block device data extraction without knowing the passkey. And the author's argument there hinges on the notion that Microsoft won't patch OS security vulnerabilities that enable key extraction from memory. Which, OK, third-party drivers suck, but Microsoft's effort to patch is also not zero, and the most common (OS+browser/sandbox) threat model requires a chain of vulnerabilities that are hard to come by.
This is not the way TPMs are used by most of the industry. For example, Microsoft and now Canonical are advertising it as a way to do FDE which Microsoft has known to be broken since 2006. They are requiring it for Windows 11 because of "security" and have provided no software feature on Windows for this kind of use case. It is only done by the OSS community.
> The other useful application is to prevent block device data extraction without knowing the passkey.
Nope, read the appendix. Since 2006, BitLocker without PIN is vulnerable to physical extraction with $80 worth of equipment. And to enable enhanced PIN for BitLocker you have to jump to a lot of hoops that most people don't even know about.
> In my mind that's the main thing a TPM is really useful for.
Unfortunately, it's not much good for that either.
A yubikey has a button to confirm the user's presence - so even if a remote attacker has completely compromised the machine, because they can't press the button, they can't get anything out of the key.
The TPM has no button, so it has to rely on the OS to keep your pin safe from keyloggers. If your OS is that trustworthy, you might as well just store your secrets in the OS keyring.
The TPM is also about 50x more complicated than a yubikey, to support things like multi-user systems. This means there's a much bigger attack surface.
I don't agree with this. Yes, any TPM is necessarily possible to bypass, but it's not easy. I know I could bypass normal password-based FDE with physical access to a machine without any special hardware or software, but not TPM-based. I assume, by the Pareto principle, that there are lots of people with my ability but exponentially fewer who could bypass a TPM. So it's definitely more secure than password-based FDE, and it's good enough for me.
Not a great take. The TPM provides the primitive of "non-extractable keys"; it's not supposed to magic up secure boot.
Even then, the argument that a TPM is worthless because it can't guarantee that software is free of vulnerabilities just belies an un-seriousness of the post. Like okay, that argument applies to every threat model ever.
A boot chain can be secure with or without a TPM. The TPM just says "I'll record what your boot chain told me and spit it back out with a signature that is verifiable by public key cryptography, so that you can tell it's what your boot chain told me. How much you trust your boot chain is up to you."
TPM relies on every link in the chain up to your OS being free of vulnerabilities. If any part has a bug, then the TPM is broken. For this kind of model, why not just put the data in one of those layers then? You've said that it's secure already.
(Most other threat models go "ok we trust some part of this is secure, and that means we can guarantee x, y, z; if that part is not secure then we cannot do this.)
> the signature of the BIOS is checked against a public key whose hash is stored in fuses
> Each of dozens (up to hundreds) of UEFI drivers written by various OEMs with varying levels of competence and care are loaded
Doesn't the BIOS signature encompass those drivers? Put another way, isn't the BIOS vendor attesting those drivers are non-malicious with their signature?
I think the TPM will turn out to be a net negative for consumers since it's going to get used to get used for attestations users can't control (ie: against the will of the user),
but there are some benefits. Having a BitLocker key unlocked via a PIN where the TPM can protect against brute force attacks is useful for me. That alone covers most of my threat model which is having my data extracted from a lost or stolen PC.
Ask Google exactly how they enforce their zero trust, VPN-less remote work environment. Hint: it has to do with the TPM. DRTM + Device Certificates + TLS Token Binding is a huge deal for proving that the endpoint is trusted, and that the principal actually logging in is using an approved device. DRTM prevents boot time tampering by assuring that the measured boot state is consistent with what the network expects.
Yes, when implemented correctly (I've never seen Google's implementation so I can't comment), D-RTM + Secure Boot is good. If Microsoft would give us this before shoving TPM down our throats, it would be good :) But they haven't even fixed the weaknesses they identified on their own in 2006.
None of my machines when I was at Google implemented this. The attestation was a bunch of scripts running on my computer that cobbled together the output of various things they cared to validate.
On the one usage scenario that benefits a PC user, the TPM makes for a really bad yubikey. You can't carry it between computers, you can't back it up, and you are certain to lose it at some point when the computer breaks of gets outdated.
That means it either requires a second protocol for authentication, or that you will lose your accounts with all kinds of services all the time.
The TPM covers cases where you want to authenticate the machine, not the user (who'd have a Yubikey they'd carry with them between machines).
There are plenty of valid use-cases where you'd want the machine to authenticate itself to services (VPN to enterprise network?) before anyone logs in (or ever logs in, as in the case of servers who operate unattended).
Depends on the implementation? For many services, I register my Yubikey, but also the Android fingerprint authentication (as well as TOTP as another fallback).
So for example, if I login to Gitlab on my phone, I can use my fingerprint (lockscreen auth). It's more convenient than using the TOTP app.
Similarly, I could register a TPM from my desktop that could be the same as using the fingerprint auth? It would only work from that desktop, but it's the same logic as my phone, and in a sense, that's a nice benefit.
DRM like full disk encryption, passkeys, etc. What DRM actually uses TPM? Pretty sure wildvine or any other common DRM tech use it to wrap the encryption of the stream. Why would it need?
> There are a plethora of attacks on TPM in the past but we need to be clear that a system that is widely attacked does not necessarily mean it is fundamentally insecure but only that there are many implementation issues. Most of these implementation issues do not touch upon the points raised in this article (it doesn't matter if the gate to your garden is strong or weak if there is no fence around the garden). Nevertheless, many of the attacks demonstrate the lack of care and consideration in the TPM ecosystem.
The issue is that TPM is being heavily pushed while it provides no security value. When you have Secure Boot (no additional hardware required), you get everything that Microsoft promises. The entire idea of TPM is that it gives you an extra level of security and I argue that it doesn't.
Should the title at least be "the trusted computing/measurement functionality of TPMs provide..." rather than "TPM provides..."?
TPMs can do other useful things besides performing attestation measurements for trusted computing, including acting as a secure element to safeguard and rate-limit keys used for SSH, disk encryption and much more.
> The Trusted Platform Module(TPM) requirement enables Windows 11 to be a true Passwordless operating system
Good luck trying to remote (RDP) into a Windows box with a passwordless account or to access a fileshare.
While passwordless Microsoft accounts are very convenient it is only according to MS Marketing department that windows can be a true passwordless system. In reality it is not. There any several components in Windows that does not work with a passwordless account. The RDP and network issues has been know for many years and is a PITA for home networking.
The threat model is "corporation wants hardware attestation so they can implement zero-trust models" but these articles always ignore that, because they don't have any alternatives to suggest.
Been wondering if I should enable these things in the firmware for several years, so the discussion is welcomed.
I do have a travel laptop and recently installed LUKS to it. I like having my long password, but being able to tie unlocking to the hardware sounds like a good idea too. Is there a way to have both? A long password and require the local TPM?
Zero is a stretch. I think they have largely failed to serve their purpose in the consumer device realm, beyond decent integration with BitLocker.
Despite the shortcomings, I think they are very useful devices from the perspective of running data centers. I consider it useless against evil maid attacks though.
I think they failed to serve their purpose because until relatively recently they've only been present on premium-grade machines, so software couldn't rely on the presence of one.
Nowadays with Microsoft making it a requirement (as well as fTPM which means the TPM no longer requires dedicated hardware) we might see more use-cases.
The absolute dumbest shit here gets up voted regarding Linux.
No dang, I don't care about the spirit of the site when absolute ludicrous mindrot garbage is up voted here constantly. You'll note on the Wayland thread that, despite being the 30th Wayland thread, the only substantive reply agreed with me. It's a joke.
Don't worry, I'm changing my password to a random guid, you'll be free of me in 45 seconds.
Its just more garbage DRM. Its Sony telling you that you don't own your PS3 all over again except it's the PC you built and Microsoft telling you what you can and can't do with it. Try to crack your CPU key to fake the TPM and Microsoft will sue you out of existance just like Sony did with Geohotz. Thanks to the DMCA and it's anti-circumvention laws, we no longer own any hardware, we're just borrowing it.
At this point I don't understand why hardware vendors can't just do it like Apple. Put a small ARM SoC with some firmware in ROM onto the mainboard that starts before the main CPU and initializes it, ensuring that the system is in a known state before any components boot.
Nextgrid|2 years ago
The reason there is no explicit threat model defined in the TPM specs is because it defines a general-purpose hardware security module. It is up to integrator to define the threat model (TPM's security properties also depend on the rest of the system) and the application.
Even if a TPM is not perfect and depends on other pieces of the puzzle to also be secure, it at least opens the possibility of making it secure in the future once those vulnerabilities are discovered & fixed. Furthermore, even in this vulnerable state, it still increases the effort required for a successful attack.
Support for TPM-backed full disk encryption means you can now have FDE on by default for everyone with no usability impact at all. Even if it's not secure and a dedicated attack will still break it, it means a casual attacker can't just pull a drive or reboot the machine and run chntpw or steal sensitive data from discarded drives that haven't been properly wiped.
I like TPMs. I like the fact that a rogue datacenter employee or intruder can't just pull one of my servers' drives out and get sensitive data. I like not having to worry about having sensitive keys on the filesystem somewhere because every secret is in memory and is ultimately derived from the TPM doing remote attestation at boot and handing ephemeral keys. I like not having to worry about unattended reboots or entering LUKS passphrases remotely.
hooverd|2 years ago
candiddevmike|2 years ago
osy|2 years ago
Hi, it's me the Linux fanboy whose entire personality is making Hackintosh and VM apps for iOS. Just a friendly reminder that attacks on the author's credentials have no baring on the weight of the arguments.
> The reason there is no explicit threat model defined in the TPM specs is because it defines a general-purpose hardware security module
It sounds like you have zero experience in security :)
> it defines a general-purpose hardware security module
No it doesn't. I think you're hinting at HSM which is another beast I may write another fanboy FUD piece about at some point. But no, HSMs are not the same as TPMs. And TPMs are not HSMs. For one thing, and HSM defines something called a trust boundary where keys should never leave. TPMs will happily hand you the keys when you meet a certain condition. HSMs support key migration and provides a secure way to transfer keys from one HSM to another without leaving the trust boundary. I can go on and on...
> TPM's security properties also depend on the rest of the system
The argument isn't TPM versus no security. The argument is TPM versus the existing security you have on Windows. (Passwords, FDE, etc). Of course all this depends on the system. TPM doesn't add anything (* with the exception already listed in the article).
> it at least opens the possibility of making it secure in the future once those vulnerabilities are discovered & fixed
Nope. Architecturally flawed. But I'd just be repeating the argument from the article.
> means a casual attacker can't just pull a drive or reboot the machine and run chntpw or steal sensitive data from discarded drives that haven't been properly wiped
They can with a $80 FPGA. Read the appendix.
> I like the fact that a rogue datacenter employee or intruder can't just pull one of my servers' drives out and get sensitive data.
They can with a $80 FPGA. (Unless your datacenter uses Intel TXT and tboot and other prerequisites that were talked about in the article)
> I like not having to worry about having sensitive keys on the filesystem somewhere
If you use BitLocker, they are always in kernel memory
> derived from the TPM doing remote attestation at boot
That's not what "remote attestation" means :)
> I like not having to worry about unattended reboots or entering LUKS passphrases remotely
If you like that, just disable your password and you'll get the same result
xinayder|2 years ago
It seems like it's a sunken cost fallacy that big tech spent a lot of money on and they are trying to get it back by convincing average Joe that a TPM is good for your PC.
sim7c00|2 years ago
I thought the piece was ok, but it doesnt add anything new. its another piece pointing at the puzzle a lot of people including you already know exists. its not aimed at you for that matter. (so fair comments, but perhaps a bit harsh?)
alerighi|2 years ago
If somebody that wants your data steals your PC he will be likely to find a way to access your personal data. It's a protection against a casual thief that is probably not interested in your data and can't probably even figure out how to bypass the Windows password screen.
But if this doesn't make harm, why not have it? Because having disk encryption enabled by default to a user that doesn't know that is enabled by default is not necessary a good thing. Let's face it: users don't do backups. I know even companies that have all their data on a single server with no backups.
Now if the motherboard breaks and you don't have backup... you can't just take the disk out of that computer, connect to another PC and recover the data. You have lost your data!
But wait, you say Microsoft tought about that, indeed if you signed in with a Microsoft account you can recover your Bitlocker encryption key from the Microsoft portal... wait what? Exactly. No security at all! Microsoft knows your encryption keys and it stores it on their servers... again: false sense of security is worse than no security at all!
Finally, even if this system was 100% secure: do you trust the hardware? The same hardware produced by the same manufacturer of the products where nearly once in a year a big security flaw is discovered? The same hardware where we know that the NSA, and probably other government agencies, placed backdoors?
Whatever, typing a password when booting up the computer (that is once in a day) is such a big deal?
cm2187|2 years ago
mixmastamyk|2 years ago
The datacenter use case sounds useful—should have led with that.
ak217|2 years ago
That's not zero. In my mind that's the main thing a TPM is really useful for. It's a secure enclave for a private key used for U2F/WebAuthn style attestation. I agree that the threat model not being explicitly discussed is a huge miss. But to that point, a TPM is still useful because it prevents someone who has hacked into my computer from commanding the TPM's authentication factor.
The other useful application is to prevent block device data extraction without knowing the passkey. And the author's argument there hinges on the notion that Microsoft won't patch OS security vulnerabilities that enable key extraction from memory. Which, OK, third-party drivers suck, but Microsoft's effort to patch is also not zero, and the most common (OS+browser/sandbox) threat model requires a chain of vulnerabilities that are hard to come by.
osy|2 years ago
> The other useful application is to prevent block device data extraction without knowing the passkey.
Nope, read the appendix. Since 2006, BitLocker without PIN is vulnerable to physical extraction with $80 worth of equipment. And to enable enhanced PIN for BitLocker you have to jump to a lot of hoops that most people don't even know about.
michaelt|2 years ago
Unfortunately, it's not much good for that either.
A yubikey has a button to confirm the user's presence - so even if a remote attacker has completely compromised the machine, because they can't press the button, they can't get anything out of the key.
The TPM has no button, so it has to rely on the OS to keep your pin safe from keyloggers. If your OS is that trustworthy, you might as well just store your secrets in the OS keyring.
The TPM is also about 50x more complicated than a yubikey, to support things like multi-user systems. This means there's a much bigger attack surface.
unknown|2 years ago
[deleted]
pxeger1|2 years ago
missingrib|2 years ago
How?
EPWN3D|2 years ago
Even then, the argument that a TPM is worthless because it can't guarantee that software is free of vulnerabilities just belies an un-seriousness of the post. Like okay, that argument applies to every threat model ever.
A boot chain can be secure with or without a TPM. The TPM just says "I'll record what your boot chain told me and spit it back out with a signature that is verifiable by public key cryptography, so that you can tell it's what your boot chain told me. How much you trust your boot chain is up to you."
saagarjha|2 years ago
(Most other threat models go "ok we trust some part of this is secure, and that means we can guarantee x, y, z; if that part is not secure then we cannot do this.)
donmcronald|2 years ago
> Each of dozens (up to hundreds) of UEFI drivers written by various OEMs with varying levels of competence and care are loaded
Doesn't the BIOS signature encompass those drivers? Put another way, isn't the BIOS vendor attesting those drivers are non-malicious with their signature?
I think the TPM will turn out to be a net negative for consumers since it's going to get used to get used for attestations users can't control (ie: against the will of the user), but there are some benefits. Having a BitLocker key unlocked via a PIN where the TPM can protect against brute force attacks is useful for me. That alone covers most of my threat model which is having my data extracted from a lost or stolen PC.
helloooooooo|2 years ago
osy|2 years ago
saagarjha|2 years ago
marcosdumay|2 years ago
That means it either requires a second protocol for authentication, or that you will lose your accounts with all kinds of services all the time.
Nextgrid|2 years ago
There are plenty of valid use-cases where you'd want the machine to authenticate itself to services (VPN to enterprise network?) before anyone logs in (or ever logs in, as in the case of servers who operate unattended).
mgbmtl|2 years ago
So for example, if I login to Gitlab on my phone, I can use my fingerprint (lockscreen auth). It's more convenient than using the TOTP app.
Similarly, I could register a TPM from my desktop that could be the same as using the fingerprint auth? It would only work from that desktop, but it's the same logic as my phone, and in a sense, that's a nice benefit.
josteink|2 years ago
Technically speaking, the exact same restrictions apply to a Yubikey.
That’s what makes it secure.
completelylegit|2 years ago
etna_ramequin|2 years ago
adrr|2 years ago
lxgr|2 years ago
hirsin|2 years ago
Time to go back to kernel mode everything I guess. Just run everything as root, get rid of sudo.
osy|2 years ago
> There are a plethora of attacks on TPM in the past but we need to be clear that a system that is widely attacked does not necessarily mean it is fundamentally insecure but only that there are many implementation issues. Most of these implementation issues do not touch upon the points raised in this article (it doesn't matter if the gate to your garden is strong or weak if there is no fence around the garden). Nevertheless, many of the attacks demonstrate the lack of care and consideration in the TPM ecosystem.
The issue is that TPM is being heavily pushed while it provides no security value. When you have Secure Boot (no additional hardware required), you get everything that Microsoft promises. The entire idea of TPM is that it gives you an extra level of security and I argue that it doesn't.
deciduously|2 years ago
stonogo|2 years ago
lxgr|2 years ago
TPMs can do other useful things besides performing attestation measurements for trusted computing, including acting as a secure element to safeguard and rate-limit keys used for SSH, disk encryption and much more.
TowerTall|2 years ago
Good luck trying to remote (RDP) into a Windows box with a passwordless account or to access a fileshare.
While passwordless Microsoft accounts are very convenient it is only according to MS Marketing department that windows can be a true passwordless system. In reality it is not. There any several components in Windows that does not work with a passwordless account. The RDP and network issues has been know for many years and is a PITA for home networking.
PeterStuer|2 years ago
stonogo|2 years ago
mixmastamyk|2 years ago
I do have a travel laptop and recently installed LUKS to it. I like having my long password, but being able to tie unlocking to the hardware sounds like a good idea too. Is there a way to have both? A long password and require the local TPM?
als0|2 years ago
yakkityyak|2 years ago
Despite the shortcomings, I think they are very useful devices from the perspective of running data centers. I consider it useless against evil maid attacks though.
lostmsu|2 years ago
Nextgrid|2 years ago
Nowadays with Microsoft making it a requirement (as well as fTPM which means the TPM no longer requires dedicated hardware) we might see more use-cases.
WirelessGigabit|2 years ago
I'd have to check if bottom cover tampering on my Lenovo actually requires me to put in the BitLocker keys again.
predictabl3|2 years ago
No dang, I don't care about the spirit of the site when absolute ludicrous mindrot garbage is up voted here constantly. You'll note on the Wayland thread that, despite being the 30th Wayland thread, the only substantive reply agreed with me. It's a joke.
Don't worry, I'm changing my password to a random guid, you'll be free of me in 45 seconds.
decodebytes|2 years ago
saagarjha|2 years ago
sidewndr46|2 years ago
avery17|2 years ago
awesomeMilou|2 years ago
mschuster91|2 years ago
unknown|2 years ago
[deleted]