This CL moves the base::Feature from content_features.h to
a generated feature from runtime_enabled_features.json5.
This means that the base::Feature can be default-enabled
while the web API is co...
I’m not even sure why I’m trying to argue with you, but let me address a few points one last time even if I doubt you’re doing so in good faith.
I don’t do bad faith. I detest lies and those who tell them.
I also don’t appreciate being accused of wrongs I haven’t committed. I suffered more than enough of that as a child; I don’t need it in adulthood too.
Do you know that literally every (even) consumer PC has a firmware chip that has complete access to the system, including networking, and runs even when the PC is off?
I know about wake-on-LAN, which is why I keep it turned off. I know about the Intel Management Engine, which is why I buy AMD and look forward to fully-open RISC-V machines.
I also know about telemetry and the possibility of back doors in proprietary OSes, which is why the only computing device I completely trust is my Linux desktop, and I do my best to secure it. That involves keeping proprietary code off it as much as possible.
You think an OS is an issue compared to this?
The OS also has complete access to the system, so yes.
You won’t get your identity stolen by your bank.
No, but I will get it stolen by criminals who exploit a data leak, and the telemetry in proprietary OSes is a data leak by design.
It’s the same problem as with the government being able to decrypt all private communications: there’s a golden key that, sooner or later, criminals will obtain, and a giant central repository of sensitive data that, sooner or later, criminals will break into.
If it’s by malware, that’s the exact thing attestation can help prevent. Anything else is irrelevant to this discussion.
False. MITM attacks on telemetry and breaches of telemetry servers are also relevant.
So is the possibility of a hidden back door in proprietary OSes. If the code isn’t public, you don’t know that there isn’t one, and it certainly wouldn’t be the first time.
We’re talking about additional security layers provided by (in this case) a browser, not necessarily the OS (though proper attestation needs to be fully verifiable from the bottom up, from firmware level up to application level).
Since there’s now a proprietary OS in the middle of the stack, that removes security rather than adding it.
I know about the Intel Management Engine, which is why I buy AMD
You should read about AMD PSP. It’s effectively the same crap as IME.
I also know about telemetry and the possibility of back doors in proprietary OSes, which is why the only computing device I completely trust is my Linux desktop, and I do my best to secure it. That involves keeping proprietary code off it as much as possible.
That’s admirable, but not a solution for the vast majority of people.
No, but I will get it stolen by criminals who exploit a data leak, and the telemetry in proprietary OSes is a data leak by design.
Telemetry in software generally does not touch user data at all. They care about how you use the product, which features, etc. Even open source projects need this so they know what to focus on in development.
And yeah, it’s not great if you can’t see what is sent or if you can’t fully disable it like in Windows, but that doesn’t make it inherently bad. In theory it potentially widens the attack surface on the OS, but there probably much easier ways to exfiltrate data.
Regardless though, once again, I’m talking about protection against third party attackers, not your OS vendor or whatever. You keep talking about insecure OSes being an issue, but that’s not the subject of the discussion. The actual question is whether does attestation help security assuming all other parts of the stack are the same? Because that’s a definitive yes. Whether it’s done on Windows or Linux doesn’t matter.
You should read about AMD PSP. It’s effectively the same crap as IME.
I already did, and no, it’s not. It has no networking stack. It can only communicate with the outside world through a user-space application, and the user-space application cannot communicate with the PSP without an OS device driver. If either of those components is missing—which, on my Linux desktop, both are—then the PSP is inert.
That’s admirable, but not a solution for the vast majority of people.
And that is why their identities get stolen every other week: because they can’t be bothered to learn how to secure their computer properly.
Telemetry in software generally does not touch user data at all.
(x) Doubt
Even open source projects need this so they know what to focus on in development.
Rarely does open-source software contain telemetry at all, let alone telemetry that isn’t strictly opt-in and honest.
And yeah, it’s not great if you can’t see what is sent or if you can’t fully disable it like in Windows, but that doesn’t make it inherently bad. In theory it potentially widens the attack surface on the OS, but there probably much easier ways to exfiltrate data.
The entire point of telemetry is to exfiltrate data. Even if you trust the OS vendor receiving the data, telemetry is still a gold mine of sensitive information, waiting to be stolen by cybercriminals.
Regardless though, once again, I’m talking about protection against third party attackers, not your OS vendor or whatever.
Then you’re not talking about the entire problem, only one small part of it.
The actual question is whether does attestation help security assuming all other parts of the stack are the same?
That’s a false assumption, because attestation forces other parts of the stack to not be the same.
Whether it’s done on Windows or Linux doesn’t matter.
Yes it does, because Linux cannot and will not be attested.
I already did, and no, it’s not. It has no networking stack. It can only communicate with the outside world through a user-space application, and the user-space application cannot communicate with the PSP without an OS device driver. If either of those components is missing—which, on my Linux desktop, both are—then the PSP is inert.
It has full access to the OS memory and full control over the CPU. It controls the bootstrapping process and loads UEFI. That means it has access to literally everything, all the time, and nothing would prevent it from accessing the network stack, too. And since it’s a binary blob, you can’t confirm it doesn’t have this capability.
Then you’re not talking about the entire problem, only one small part of it.
Yeah, imagine talking about the actual topic of the linked article.
That’s a false assumption, because attestation forces other parts of the stack to not be the same.
You completely misunderstood me. What the attestation runs on is an implementation detail. Yeah, to have it actually secure you need to ensure it’s secure from the bottom up to the very top, and nothing has been tampered with - which is impossible with the way open source operating systems work nowadays - but that doesn’t mean it’s an inherent requirement. You could conceivably create a system for securing open source software too, though it’d still have to be signed and approved by whatever authority decides what is and isn’t secure, and the user wouldn’t be allowed to tamper with at least some components that are crucial to keep the attestation.
What I meant by all parts of the stack being the same is that if you have any given stack, attestation will improve security. That’s not up to debate, that’s a fact. Whether it forces some people into options they deem less private, that’s a different issue. Obviously a huge one, but it doesn’t inherently make anything less safe.
It has full access to the OS memory and full control over the CPU.
Yes, I know, and that’s why I look forward to fully-open RISC-V hardware.
But, as long as the PSP doesn’t go poking around the OS on its own initiative and doesn’t have its own network stack, it’s probably harmless. Probably. I hope. It’s the best I could do with what was available to me at the time I purchased this machine, at any rate.
That means it has access to literally everything, all the time, and nothing would prevent it from accessing the network stack, too.
Sure there is: the fact that poking around a non-proprietary operating system’s network stack from underneath it is extremely brittle, and will almost certainly cause boot to fail if you so much as recompile the kernel.
Generally, doing that sort of thing in an automated and reliable fashion requires the OS to cooperate. For example, the BIOS can contain arbitrary Windows binaries that will be executed during boot, but this only works because Windows intentionally goes looking for such binaries. Linux, obviously, does not cooperate in such schemes.
The Intel ME firmware avoids this problem because it has its own network stack, and, again, the PSP firmware is not currently known to have one. The PSP firmware isn’t exactly wrapped in Denuvo, so I expect someone would have noticed by now if it did have one.
That said, you’re right that it is best to use hardware with no IME, PSP, or similar treacherous components. When it comes time to replace this machine, I will definitely have that in mind.
Yeah, to have it actually secure you need to ensure it’s secure from the bottom up to the very top, and nothing has been tampered with - which is impossible with the way open source operating systems work nowadays - but that doesn’t mean it’s an inherent requirement.
Remote attestation is useless if it isn’t secure from top to bottom. Without that, you (or a criminal who has compromised your computer) can easily defeat it with an emulator, virtual machine, DLL injection, or the like. So yes, of course it will check for tampering at every level—I thought that was a given.
What I meant by all parts of the stack being the same is that if you have any given stack, attestation will improve security.
In theory, I suppose, but it’s a moot point because attestation of stacks based on open-source operating systems is not feasible. Rolling-release and/or always-self-built Linux distributions (like Arch, Debian Sid, and Gentoo), in particular, will be virtually impossible to attest because the binaries are constantly changing.
It’s also a moot point because no one will honor the attestation of a Linux-based system. Chase Bank, for example, proudly proclaims that everything other than Windows and macOS is forbidden, and although Linux-on-x86 is currently permitted, less-common platforms like OpenBSD are denied access unless they use a forged User-Agent. With the machine’s entire software configuration being validated, it’s safe to assume that, at best, only one or two prominent Linux distributions will be permitted, only those distributions’ builds of Chromium will be permitted, and only if the TPM is enabled and driver loaded (which, as you yourself have pointed out, is extremely dangerous).
Whether it forces some people into options they deem less private, that’s a different issue. Obviously a huge one, but it doesn’t inherently make anything less safe.
I don’t do bad faith. I detest lies and those who tell them.
I also don’t appreciate being accused of wrongs I haven’t committed. I suffered more than enough of that as a child; I don’t need it in adulthood too.
I know about wake-on-LAN, which is why I keep it turned off. I know about the Intel Management Engine, which is why I buy AMD and look forward to fully-open RISC-V machines.
I also know about telemetry and the possibility of back doors in proprietary OSes, which is why the only computing device I completely trust is my Linux desktop, and I do my best to secure it. That involves keeping proprietary code off it as much as possible.
The OS also has complete access to the system, so yes.
No, but I will get it stolen by criminals who exploit a data leak, and the telemetry in proprietary OSes is a data leak by design.
It’s the same problem as with the government being able to decrypt all private communications: there’s a golden key that, sooner or later, criminals will obtain, and a giant central repository of sensitive data that, sooner or later, criminals will break into.
False. MITM attacks on telemetry and breaches of telemetry servers are also relevant.
So is the possibility of a hidden back door in proprietary OSes. If the code isn’t public, you don’t know that there isn’t one, and it certainly wouldn’t be the first time.
Since there’s now a proprietary OS in the middle of the stack, that removes security rather than adding it.
You should read about AMD PSP. It’s effectively the same crap as IME.
That’s admirable, but not a solution for the vast majority of people.
Telemetry in software generally does not touch user data at all. They care about how you use the product, which features, etc. Even open source projects need this so they know what to focus on in development.
And yeah, it’s not great if you can’t see what is sent or if you can’t fully disable it like in Windows, but that doesn’t make it inherently bad. In theory it potentially widens the attack surface on the OS, but there probably much easier ways to exfiltrate data.
Regardless though, once again, I’m talking about protection against third party attackers, not your OS vendor or whatever. You keep talking about insecure OSes being an issue, but that’s not the subject of the discussion. The actual question is whether does attestation help security assuming all other parts of the stack are the same? Because that’s a definitive yes. Whether it’s done on Windows or Linux doesn’t matter.
I already did, and no, it’s not. It has no networking stack. It can only communicate with the outside world through a user-space application, and the user-space application cannot communicate with the PSP without an OS device driver. If either of those components is missing—which, on my Linux desktop, both are—then the PSP is inert.
And that is why their identities get stolen every other week: because they can’t be bothered to learn how to secure their computer properly.
(x) Doubt
Rarely does open-source software contain telemetry at all, let alone telemetry that isn’t strictly opt-in and honest.
The entire point of telemetry is to exfiltrate data. Even if you trust the OS vendor receiving the data, telemetry is still a gold mine of sensitive information, waiting to be stolen by cybercriminals.
Then you’re not talking about the entire problem, only one small part of it.
That’s a false assumption, because attestation forces other parts of the stack to not be the same.
Yes it does, because Linux cannot and will not be attested.
It has full access to the OS memory and full control over the CPU. It controls the bootstrapping process and loads UEFI. That means it has access to literally everything, all the time, and nothing would prevent it from accessing the network stack, too. And since it’s a binary blob, you can’t confirm it doesn’t have this capability.
Yeah, imagine talking about the actual topic of the linked article.
You completely misunderstood me. What the attestation runs on is an implementation detail. Yeah, to have it actually secure you need to ensure it’s secure from the bottom up to the very top, and nothing has been tampered with - which is impossible with the way open source operating systems work nowadays - but that doesn’t mean it’s an inherent requirement. You could conceivably create a system for securing open source software too, though it’d still have to be signed and approved by whatever authority decides what is and isn’t secure, and the user wouldn’t be allowed to tamper with at least some components that are crucial to keep the attestation.
What I meant by all parts of the stack being the same is that if you have any given stack, attestation will improve security. That’s not up to debate, that’s a fact. Whether it forces some people into options they deem less private, that’s a different issue. Obviously a huge one, but it doesn’t inherently make anything less safe.
Yes, I know, and that’s why I look forward to fully-open RISC-V hardware.
But, as long as the PSP doesn’t go poking around the OS on its own initiative and doesn’t have its own network stack, it’s probably harmless. Probably. I hope. It’s the best I could do with what was available to me at the time I purchased this machine, at any rate.
Sure there is: the fact that poking around a non-proprietary operating system’s network stack from underneath it is extremely brittle, and will almost certainly cause boot to fail if you so much as recompile the kernel.
Generally, doing that sort of thing in an automated and reliable fashion requires the OS to cooperate. For example, the BIOS can contain arbitrary Windows binaries that will be executed during boot, but this only works because Windows intentionally goes looking for such binaries. Linux, obviously, does not cooperate in such schemes.
The Intel ME firmware avoids this problem because it has its own network stack, and, again, the PSP firmware is not currently known to have one. The PSP firmware isn’t exactly wrapped in Denuvo, so I expect someone would have noticed by now if it did have one.
That said, you’re right that it is best to use hardware with no IME, PSP, or similar treacherous components. When it comes time to replace this machine, I will definitely have that in mind.
Remote attestation is useless if it isn’t secure from top to bottom. Without that, you (or a criminal who has compromised your computer) can easily defeat it with an emulator, virtual machine, DLL injection, or the like. So yes, of course it will check for tampering at every level—I thought that was a given.
In theory, I suppose, but it’s a moot point because attestation of stacks based on open-source operating systems is not feasible. Rolling-release and/or always-self-built Linux distributions (like Arch, Debian Sid, and Gentoo), in particular, will be virtually impossible to attest because the binaries are constantly changing.
It’s also a moot point because no one will honor the attestation of a Linux-based system. Chase Bank, for example, proudly proclaims that everything other than Windows and macOS is forbidden, and although Linux-on-x86 is currently permitted, less-common platforms like OpenBSD are denied access unless they use a forged
User-Agent. With the machine’s entire software configuration being validated, it’s safe to assume that, at best, only one or two prominent Linux distributions will be permitted, only those distributions’ builds of Chromium will be permitted, and only if the TPM is enabled and driver loaded (which, as you yourself have pointed out, is extremely dangerous).Privacy is safety. Loss of privacy is less safe.