Requiring authorized silicon (and software) isn't even the biggest problem here.
They do not use zero knowledge proof systems or blind signatures. So every time you use your device to attest you leave behind something (the attestation packet) that can be used to link the action to your device. They put on a show about how much they care about your privacy by introducing indirection into the process (static device 'ID' is used to acquire an ephemeral 'ID' from an intermediate server) but it's just a show because you don't know what those intermediary severs are doing: You should assume they log everything.
And this just the remote attestation vector, the DRM 'ID' vector is even worse (no meaningful indirection, every license server has access to your burned-in-silicon static identity). And the Google account vector is what it is.
There are several possible reasons for this, the obvious one is that they want to be able to violate your privacy at will or are mandated to have the capability. The other is that because it's not possible to link an attestation to a particular device the only mitigation to abuse that is feasible is rate limiting which may not be good enough for them - an adversary could set up a farm where every device generates $/hour from providing remote attestations to 'malicious' actors.
> The other is that because it's not possible to link an attestation to a particular device the only mitigation to abuse that is feasible is rate limiting
I still don't see how you can keep something anonymous and still rate limit it. If a service can tell that two requests came from the same party in order to count them then two services can tell that two requests came from the same party (by both pretending to be the same service) and therefore correlate them.
The way it would work with blind signatures is that the server will know the device that comes to it to request a blinded signature and will be able to rate limit how often that device asks it.
But once you get the response you can unblind the signed signature and obtain the token (which is just the unblinded signature). This token can then be used once either because its blacklisted after use (and it expires before the next day starts for example).
The desired property of blind signatures is that given a token it's information theoretically impossible to determine which blinded signature it came from (because it could have come from any of them) even if the cryptographic primitive is broken by a mathematical breakthrough or a quantum computer. There is technically the danger that if the anonymity set is too small and all the other participants collude you can be singled out.
Correlating times is a threat vector that needs to be managed either by delaying actions (not tolerable by normal users) or by acquiring tokens automatically and storing them in expectation. Or something other I haven't thought of probably. There is also a networking aspect to this, you will need a decentralized relay server network that masks origin of requests.
> But once you get the response you can unblind the signed signature and obtain the token (which is just the unblinded signature).
The premise of this is to keep the person issuing the tokens and the person accepting them from correlating you.
The issue is when you have more than one service accepting them. You go to use Facebook and WhatsApp but they're both Meta so you present the same unblinded signature to both services and now your Facebook and WhatsApp accounts are correlated against your will. And they have a network that does the same thing, so you go to use a third party service and they require you to submit your unblinded signature to Meta which allows them to correlate you everywhere.
That's the point. You go to example.com and get the "sign in with Google" box as the only login option, but now you can't have separate uncorrelated Google accounts. Or if browsers do it automatically then every site does a background load or redirect through adtracker.nsa so you're presenting the same token on every service.
It's not the user who wants any of this to begin with. "You would never do that" except that it's now the only way to be let into the service.
If A adopts a Blind Signature scheme it implies A is cooperating in establishing privacy infrastructure. If A is so malicious that it would advertise a sound privacy system and then it immediately sabotages it that's a different matter...
The proposals are generally to have the government do the blind signature scheme. But then even if they do so in good faith, the ad services will immediately set to work thwarting it.
Just to give an example to prime your intuition: define your "usage token" as H(private_key|service_domain_name|date|4-bit_counter). Make your scheme provably reveal the usage token when you authenticate. Now you can use the service 16 times a day on a particular domain and no more simply by blocking token reuse. And yet the service has no ability to link different tokens to each other or to a specific person because they don't have anyone elses private keys.
You can make variations on this for a wide spectrum of rate limiting behaviors.
But also I agree with xinayder's comment-- the anticompetative, anti-privacy, invasive surveillance is unacceptable. There is a lot of risks with ZKP's that we just make the poison a little less bitter with the end result being more harm to humanity.
I think ZKP systems are intellectually interesting and their lack of use helps make it more clear that the surveillance is really the point of these schemes, not security because most of the security (or more of it) could be achieved without most of the surveillance.
But allowing the apple google duoopoly to control who can read online is wrong even if they did it in a way that better preserved privacy.
Because-- in this hypothetical-- your user agent restricts the usage to the name displayed on the screen and also because your agent won't send the same value twice either (it'll increment the counter or tell you that its run out of tokens).
Requiring the name to be displayed isn't going to do much for ordinary people. They mostly wouldn't look at it and even if they did, "continue as-is or no service for you" means they continue as-is.
Not sending the same value twice would prevent them from being correlated, but now what are you supposed to do when you run out? Running you out could even be the goal: You burn a token to get a cookie and now you can't clear your cookies or you'll be denied a new one since you're out of tokens.
I'll be the first to admit that the technology can be abused-- that it's even ripe for abuse. That sort of problem can be avoided by allowing 'enough'-- and if the goal is to just prevent a site being flooded out 'enough' could be pretty high.
Of course, I think the effective purpose of google's attest feature is to invade everyone's privacy which we should assume is part of why they don't use privacy preserving techniques. Privacy preserving techniques could still be abused, however.
Maybe they're even worse for humanity because they make bad schemes more palatable. I think right now I lean towards no: the public in general will currently tolerate the most invasive forms of these systems, so our issue isn't that they're being successfully resisted and the resistance might be diminished by a scheme which is still bad but less bad.
I have sympathy for the desire but that isn't something you actually get through google's surveillance-ware.
You can change the information you put into the hash in my example to get them one go per site per day or one per year or even one per site ever. But without giving cross site linkablity that does you no good or giving google visibility into everyone all the time.
But that still doesn't get you to your desired unevadable bans, but with suitable parameters it can get as close as google's spyware approach while being much more private.
I think time a time oriented rate limit makes the most sense considering the limits in practice (attacker just gets access to another discarded phone, or tricks someone into authenticating for them via theirs)-- basically means the best you can do against dedicate attackers is rate limit them. So why subject honest users who may have good privacy reasons to use multiple accounts over time to worse effective limits than attackers?
But you don't have to agree with that to accept that schemes much more private than google's are possible.
With the current system, Google can permanently ban a device. Then you have to pay a hundred dollars to get unbanned. This is the desired intention - any system that doesn't let Google do this will not be accepted by Google.
> I still don't see how you can keep something anonymous and still rate limit it.
Constructions like this exist for many years. E.g. semaphore RLN (rate limiting nullifier). This particular construction was found unfeasible 7 years ago, but since then zksnark tech made huge progress and it is way cheaper now.
I'm as biased against cryptocurrency as everyone, but couldn't we have the requestor do a bit of mining work to mint that initial id? I mean, if the service is actually making a bit of money from each request, the need for rate limiting just vanishes, right?
If proof of work is the "payment" to prove that you're human, many AI startups will outbid poor people living third world countries. They will even outbid some Americans.
Yes, those AI startups can also buy cheap Android phones at scale, but it's a bit harder because they'll pay for stuff that their bots have no use for (a screen, a battery, a 5G radio, software, branding, distribution, customer support etc).
As I see it, living requires money. If we have people on this planet that are too poor to digitally prove that they're alive, then we need to figure out a way to distribute the Earth's wealth more equally in general, rather than to require hardware attestation, which seems to be worse on essentially every metric, including inequality.
i genuinely don’t think the idea of being too poor to prove you’re alive is on their radar. it’s just not in their priorities. this is why we need regulations. companies only care about bottom line and increasing profits not the wellbeing of humanity
> If proof of work is the "payment" to prove that you're human, many AI startups will outbid poor people living third world countries. They will even outbid some Americans.
The difference is that if you're human you can create an account and then carry on using it for decades, whereas if you're an aggressive scraper bot or spammer then you get banned and have to buy new accounts over and over.
An "account" which is somehow linked to enough of your browsing history to determine if you're a scraper or a spammer. Then the company(s) administrating these accounts will be able to collect a lot of info on the account holders over decades.
Google hardware attestation idea won't give them that much data: All Google will know is which phones visited which websites and only when the website asks the phone for hardware attestation. If the website gives the phone a cookie for bypassing subsequent attestations, then Google will know only of the first visit.
Attestation is a service, like every other service. Why should it necessarily be free? Especially now that we all know that "free" on the web means ads & tracking?
I think we should just accept that some things should cost a bit of money and move the discussion to "how much should it cost", rather than trying to sweep economics under the rug.
Can we stop normalizing being surveilled online and on our devices?
Saying something like "the problem is not hardware attestation, but that they don't use ZKP".
You are normalizing the new behavior. You shouldn't. It doesn't matter if they use ZKP or the latest, secure technology for hardware attestation. The issue is hardware attestation. It's the same with age ID. The issue is not that Age ID is prone to data leaks, the problem itself is called Age ID.
Let them know. Write a letter to the CEO. And vote with your wallet and switch banks if you can. There's always a bank willing to offer you a non-app 2FA scheme.
Banks don’t do this because of profit. They do it because of decades of laws pushing in this direction. Anti-money laundering, know your customer, digitalised currency, abandoning cash, preventing tax evasion etc… it’s been getting more extensive over time.
None of the things you mentioned inherently require the user to own (and babysit) an expensive general-purpose computing device produced by tracking-obsessed adtech giants and with software obsolescence built into the product.
I think you're naively presuming the issue is simple and easy to address with a letter.
Regardless of your bank, payment systems such as Visa and Mastercard have blocked transactions involving mainstream online stores such as Steam because they unilaterally deemed some games to be problematic. You cannot fix this problem with an email.
These are two unrelated problems. One is "payment systems use imperfect heuristics in their own operations to fulfil their regulatory obligations." The problem I was referring to is "banks push 2FA onto end users but are unwilling to give them alternatives that don't involve meddling with the user's own most private and expensive device."
The latter is absolutely a thing where customers can (and should IMO) push back hard.
> These are two unrelated problems. One is "payment systems use imperfect heuristics in their own operations to fulfil their regulatory obligations."
No, they are not. You have people reliant on this software infrastructure for very basic aspects of their life such using their own money to buying whatever they feel like buying, and you have people being deprived of their rights because operators of said infrastructure actively prevent and deny their rights to do so. This has nothing to do with heuristics, and everything to do with granting people the power to dictate what you may or may not do with the things you own.
Do you think banks are using attestation gratuitously? It helps prevent a lot of fraud. You are opposing something that saves people’s savings every day just because you think it takes “freedom” away from a few hobbyists. Do you even have a phone that does not support hardware attestation or is all this posturing about something hypothetical?
Can you show me examples where locking down an OS has prevented fraud in banking?
Honestly, if the only way to secure your banking system is by locking down users' devices, there is something really bad going on at your end, security-wise. Your system should be secure even without locking down user hardware.
One of the threat models is that a fraudster tricks a non-technical user into installing malware, which then manipulates the user interface so that next time the user tries to send money to Bob, it actually goes to Mallory.
That's a legitimate concern, and one of the causes why PSD2 mandates that all 2FA devices must have a display that shows the user where they're about to send the money and how much.
And one of the threat models that police use in the US is tracking women suspected of going for abortions through the use of road cameras, and other surveillance methods.
Once you have the attestation in place you have no guarantee who is going to get access to data like what apps are present on your device, and there will be nothing you can do to stop it.
Meanwhile, we could educate people against common scams.
How is this not just trading one smaller bad for a bigger bad? Why is this touted as an improvement?
That's why I'm strongly against remote attestation of general-purpose hardware.
I use a handheld card reader with a display as a 2FA for my bank transactions. It shows me the transaction and, after I confirm, sends a TAN to the bank. It is not a general-purpose device but a certified, tamper-evident/-resistant black box that does just that one thing.
> Meanwhile, we could educate people against common scams.
There's a million ways you can get scammed, no matter how many hours of training you've had.
You can't educate (many) people against common scams. But people should have the freedom to opt out of surveillance in their private lives, at the risk of exposure to scams.
When online banking was first created it was an absolute chaos zone. Everyone was accessing it from desktop machines riddled with viruses and malware. There are endless stories of being discovering their life savings had been wired to Belarus by some malware running on their machine that had grabbed their banking credentials when they logged in.
> U.S. prosecutors say Citadel infected more than 11 million computers worldwide, causing financial losses of at least a half billion dollars.
Half a billion dollars, by a single guy with a single virus!
Different parts of the world came up with different solutions for this. The US made all ACH payments reversible and international wires difficult, but that just meant the receiver paid for fraud instead of the person whose machine was full of viruses. This was an obviously bad set of incentives and hacky panic-based fix. Banks elsewhere in the world settled on providing users with authenticator devices that looked like small calculators into which you could type transaction details after plugging in a smart card. Malware could still steal all your financial data but it couldn't initiate transactions.
Obviously, all this was a hack. What was needed was computers that were secure. Apple and the Android ecosystem eventually delivered this, and the calculator devices were retired in favour of smartphones with remote attestation. This was better in literally every way, for 100% of users. Firstly, it protects financial privacy and not just transaction initiation. Secondly, it's a lot more convenient to use a device that's always with you than a dedicated standalone single-use computer. Thirdly, adding remote attestation made no difference because that's what the calculator devices were doing anyway. Fourthly, even in the case of customers of small American banks that weren't capable enough to manage dedicated hardware rollouts, getting rid of fraud instead of pushing liability around allows for lower prices and fewer headaches.
So remote attestation is a non-negotiable requirement for digital banking of any form. When Microsoft didn't deliver most banks preferred to literally manufacture and sell their customers single-use smartcards that remotely attested by you manually copying numbers back and forth between screens. Or they hid the cost of rampant fraud in the price of other services until such a time that Apple/Google saved them.
> Secondly, it's a lot more convenient to use a device that's always with you than a dedicated standalone single-use computer.
The price the owner pays for this is that they're locked out of their own expensive general-purpose computing device while still having to bear all the inconveniences (babysit OS updates, configure stuff, keep it charged, have the battery fail, buy a new device every five years, etc.)
In the meantime, the standalone chip-and-TAN device costs 30 bucks, is powered by three AAA batteries that hold their charge for five years, lives for 20 years, and never needs a single software update.
I'd choose the small single-purpose device over the enshittified, locked-down smartphone every single time.
Spectre doesn't work across process boundaries, so I don't think they are. You can't Spectre your way into a banking app on an iPhone. Or if you can I'd like to see it in action.
I don’t think "Spectre doesn’t work across process boundaries" is correct as stated; cross-process and cross-security-domain Spectre attacks have been demonstrated. But I agree that "a malicious app can trivially Spectre its way into an arbitrary banking app on a patched iPhone" is a much stronger claim, and I’m not aware of a public demonstration of that exact attack. My point is only that process isolation alone is not, in principle, a complete answer to Spectre-class attacks.
The only similar bug I'm aware of was Meltdown, an Intel only bug that was immediately patched with a microcode update. But Meltdown was a different bug to Spectre. Spectre is a class of attacks that's hard to solve by design, Meltdown was a specific bug that was easy to solve.
You could also open your front door with your smart phone. It would look high tech until your battery is empty.
Sometimes I see people captured by the train station unable to check out. They usually find someone with a charger but technically the formula is to fine them for not having a ticket. Then one might still need to buy a ticket to continue the journey. (bring cash)
Phones are usually empty when things [already] aren't going as planned.
Back in my iPhone days, I once got bitten by a bug where the app developer failed to raise that flag "dear OS, I'm in the middle of presenting a ticket for optical scanning, and it would be really amazing if you could just, you know, not disturb the screen with random shit for a couple seconds."
Unfortunately for me though, the turnstile that I was about to pass to exit the train station had both an optical scanner and some NFC thing lumped into the same physical module, and every time I tried to scan my ticket, the phone would raise its NFC screen and hide the 2D matrix code.
So yes, you can have a fully charged phone and a perfectly valid ticket with the latest software and still get stuck in a train station.
>....the calculator devices were retired in favour of smartphones with remote attestation. This was better in literally every way, for 100% of users.
Not 100%. A robber can force people to activate facial recognition or finger print sensors. Forcing someone to type a pin code is harder but doable. If one doesn't bring the authenticator & bank card they cant initiate transactions.
Remote attestation is a technology, not a policy or a political effort, so it can't be inherently evil. You can disagree with all its known or proposed uses, but then I think it makes more sense to name these.
DRM is a technology and is inherently evil.
Web attestation is DRM for the web, and is inherently evil.
Age ID is a technology and is inherently evil.
We have over 30 years of the world wide web and for these more than 3 decades this was never a problem. Suddenly, we "need" to create new technology that seem to be security features, but are essentially just being used for evil, thus being inherently bad.
It's not like these technologies were created for the greater good and misappropriated by bad actors. They were proposed by bad actors in the first place, they cannot not be inherently good.
DRM is arguably a specific use of various generic technology ranging from whitebox cryptography to trusted computing.
I don't think remote attestation (or even more so its umbrella technology, trusted computing) is nearly as specifically targeted as DRM.
> We have over 30 years of the world wide web and for these more than 3 decades this was never a problem. Suddenly, we "need" to create new technology that seem to be security features, but are essentially just being used for evil, thus being inherently bad.
I agree that requiring remote attestation for generic web use is evil. It's way too heavy-handed an approach better reserved
I still don't think this somehow outright disqualifies the technology itself.
>I still don't think this somehow outright disqualifies the technology itself.
A technology squarely and 100% percent intended to give people other than the end user the ability to sleep soundly at night knowing those dastardly end users can't muck with their software (the non-end user) on their (the end user's) devices is only a tool for the authoritarian minded. Sorry mate, but if you're sitting here thinking it's useful and neutral, you are part of the problem, because you're eyes-wide-shutting the fact the only people gaining from the technology are those that already have a terrible trustworthy-ness record in terms of not abusing the sovereignty of another person's machine.
Show me an industry that ships source code, and manuals with all software that runs on the device, along with hardware manuals and the manuals to write your own drivers and doesn't use hardware primitives to enforce their business models over you, then we can talk about an industry where "trusted computing" might be neutral to the end user. History has not seen this relationship bore out, however.
The "Trust" in "Trusted Computing" has only ever been realistically unidirectional in terms of favoring entrenched industry players. As a rule of thumb, if the primary benefactors of a feature are over 90% legal fictions; your feature ain't neutral. It's hostile to humanity. Period.
> Show me an industry that ships source code, and manuals with all software that runs on the device, along with hardware manuals and the manuals to write your own drivers and doesn't use hardware primitives to enforce their business models over you, then we can talk
>We have over 30 years of the world wide web and for these more than 3 decades this was never a problem.
Are you seriously trying to suggest copyright infringement has not been an issue over the last 30 years? Both of them are solutions to problems that we've had over the last 30 years and were created for the greater good to solve problems that developers were facing.
Grocery stores are a trillion dollar industry yet you will see stores that close due to theft being possible. The simplest way games and music struggle is losing a sale because people can play them without paying.
Individual self employed photographers successfully use the DMCA to get significant payouts from large publishers and news organisations every single day.
The policy is "I will not let you access this system unless your system software implements this technological protection."
A camera is technology. A security camera is policy, because it's a camera hooked up to policies on how to watch, record, and respond to what is required, and it is a political effort when connected with laws about face masks, prohibiting spray painting of the cameras, and allowing privacy intrusions.
I think people are too quick to dismiss the possibility that some technologies are just bad and harmful and we can't shrug off responsibility and say I'm just making a neutral technology and the people using it are the ones causing harm.
Different technologies may selectively amplify existing power. If the actions that it enables are disproportionately evil, it may at the very least be considered very useful for evil.
Suppose someone invents a mind-reader that lets the user read the thoughts of anybody else in range. But the mind-reader requires great up-front costs to produce and also allows people with stronger readers to remotely destroy weaker readers, where strength is basically a function of cost.
In a vacuum, the mind-reader is "just a technology". But it aids autocratic surveillance much more than it aids citizens who want to surveill back. It's "neutral" but its impact is decidedly not.
TPMs and remote attestation enable entities with power to enforce their existing power much more effectively. In contrast, a general-purpose computer does the opposite because anybody can run whatever code they want, they can adversarially interoperate with anybody they feel like, and so on.
One of these is more evil than the other, even though they're both "just technologies".
I have 2 servers, Alice and Bob, Bob has a secret, I want Bob to be able to share that secret with Alice. However, I want Alice to be able to prove to Bob that it is actually Alice, that it is running the correct AliceOS, and that AliceOS was loaded on bare metal Alice without nefarious pre-book or virtualization hooks.
A TPM with measured boot (SecureBoot) does exactly this, remote attestation is how Alice proves to Bob that it is in a trusted configuration and wasn't tampered with.
That's the academic viewpoint, but in practice it's used for far more hostile purposes.
(One argues that since you own both of them, you should simply set up the two servers yourself with a key of your own choosing, asymmetric or otherwise, and then restrict physical access to them.)
Alice runs many services and has a rather large attack surface. I don't want Alice to persist those secrets, only to have them briefly at startup (think joining tokens). Bob however has exactly one job, verify that Alice-1 to Alice-N are in a trusted configuration before granting them access to the cluster.
Very recent events in the Linux kernel prove that it isn't safe to assume "0600 root:root" is sufficient to protect secrets from a misbehaving container.
As someone who wanted to improve users security, that’s exactly why I find this thread fanatical opposition to attestation baffling. Nearly everyone uses a device that supports hardware attestation. It’s the best available tool to protect users from malware. We do implement a fallback that lowers security but lets the few users who have devices not able to attest properly to continue, but that really lowers security since we can’t even know if the device cryptography is itself compromised and hence can’t really trust anything it sends. If you have a different solution, do share it! I would love to use something you guys don’t find abhorrent! But until then I don’t really see the reason for all this negativity.
Sadly, the problem isn't the TPM or Remote Attestation. It's Google et al choosing to only talk to devices and software they like without concern for what the user wants or trusts. Compounded by everyone else just going along with it.
A TPM where the device owner can't take ownership of the root key is worse then no TPM at all.
If the price to pay for security is freedom, then let users's devices be insecure. With time, they will learn good security hygiene. And if they don't, maybe they don't deserve it.
How should a government act to prohibit misrepresentation of one’s characteristics online, from accessing services for which that government has formally defined regulations based on characteristic into law?
If your answer is “they shouldn’t ever do that”, then you’re promoting an uncompromising position that governments are disinclined to adopt, being the primary user of identity issuance and verification on behalf of their citizens.
If your answer is “they should do that differently”, then you have a discussion about (for example) ZKP or biosigs or etc., such as the thread you’re replying to.
Which of these two paths are you here to discuss? I want to be sure I’ve correctly understood you to be arguing for the former in a thread about the latter.
You're not necessarily being surveiled just because you're forced to authenticate yourself. It often is the case practically, but it's not inherent, and mixing the two up makes the discussion too imprecise in a technical forum.
Hardware attestation often also has problems of centralization, but that's something else as well.
By just labeling it as an abstract bad thing without seeing nuance, I'm afraid you won't be convincing those in power to pass or block these laws, or those convincing your fellow voters which efforts to support.
> It often is the case practically, but it's not inherent
Oh my god. It's 2026, and we're still repeating the "I trust Apple/Google/Microsoft enough to resist the government" spiel.
Hardware attestation is a surveillance mechanism. If China was enforcing the same rule, you would immediately identify it as a state-driven deanonymization effort. But when the US does it, you backpedal and suggest that it could be implemented safely in a hypothetical alternate reality. Do you want to live in a dystopia?
> Oh my god. It's 2026, and we're still repeating the "I trust Apple/Google/Microsoft enough to resist the government" spiel.
Who is?
> But when the US does it [...]
I don't live in the US, and while US is often setting global trends, in this case I don't think that's actually that likely, unless it somehow goes significantly better (i.e., the benefits actually vastly exceed the collateral damage to anonymity and resiliency via heterogeneity) than expected.
I think labeling this an abstract problem because all the existing implementations as having concrete but different problems is a little bit of a Motte and Bailey fallacy.
The surveillance of the future will be powered by the things we produce today. If the accepted algorithms leave cookies those cookies will be used tracked and monitized. The bad argument is the forced verification to do things on the internet. Making that start at the hardware is a lock in thats not okay. Business will always own the services and making standards that trade our practical liberty for the sake of security is a very compromised position in my opinion.
And it does start with the age verification, followed by id checks, etc. Its compromising precisely because no lines are drawn and no rights to privacy are codified in law. Without guiderails the worse path will likely be taken for maximum profit
Having thought about ads, what is the ideal feedback info channel loop from manufacturers to consumers? How best to distribute the information of who can manufacture what at what cost/price and what does it do and when is it appropriate for consumers to receive or pull info from where? And if it ends up being a monopoly of 1 centralized system how do you allow for a competitor to break through without ads?
A counterexample is not a valid refutation of the general point. It can be both true that Google will deanonymize you, given the chance, and that anonymous attestation is possible.
There is a problem where it's becoming increasingly harder to determine which internet packets that are coming to your service are at the behest of a human in the course of normal activities or an automated program.
If all the internet was is static content, that wouldn't be much of a problem. But we live in world where packets coming to your service result in significant state changes to your database (such as user generated content).
I suspect that we are currently in the valley of do-something-about-it on the graph which is why you see all this angst from the big players. Would Google really care if automated programs were so good that they were approximating real humans to such an extent that absolutely no one can tell? I suspect they would not only be happy with such a state of affairs, they would join in.
> Requiring authorized silicon (and software) isn't even the biggest problem here.
It is indeed the biggest issue. It prevents be from owning and using the hardware I pay for, own, or make myself. It's switching the personal computers as we know it from being open to proprietary and owned by 2 large US corporations.
I simplified the process in my description. The DRM ID Android has is not what I was referring to.
I was referring to the static private key that is stored in the silicon. At any time an application can initiate a license request process using DRM APIs which will elicit an unchangeable HWID from your device. The only protection is that it will be encrypted for an authorized license server private key so collusion may be required (intel agencies almost certainly sourced 'authorized' private keys for themselves). Google or Apple also has the option to authorize keys for themselves. In 'theory' all such keys should be stored in "trusted execution environments" on license servers and not divulge client identities for whatever that's worth: <https://tee.fail>.
The "license challenge" (it might be a mistake I think it's supposed to be a license request) is just a packet (that can be saved and later sent to anywhere) and it contains the encrypted certificate which doubles as your HWID. An adversary needs to control the private key of the license "server" the challenge is for (this is a privacy measure introduced to prevent the CDM from offering the HWID to anyone who wants it). Now if you want the HWID you need to work for it (one time) by stealing a private key, bribing/blackmailing employees or issuing secret edicts ("here is a new license server we need a certificate for"). Working for Hollywood is also an option I suppose.
Pirates sacrifice devices when they publish ripped content due to the certificate being revoked after Hollywood downloads the torrent and by doing things like this:
For large-scale per-viewer, implement a content identification strategy that allows you to trace back to specific clients, such as per-user session-based watermarking. With this approach, media is conditioned during transcoding and the origin serves a uniquely identifiable pattern of media segments to the end user.
Can you revoke certificate for a specific device using privacy schemes?
Like imagine that someone managed to extract key from the specific device and distributed that key in a software implementation to fake attestation. Now Google needs to revoke that particular key to disallow its usage. This is obvious requirement.
Yes, with blind signatures you still have a central authority which voluntarily 'launders' tokens for you. When you present it your certificate and ask it to give you a blind signature it can reject the certificate.
However if someone extracts a key and keeps it private, and instead gives out unblinded tokens there is nothing you can do other than rate limit - realistically, an adversary is going to trial different rates anyway to figure out which don't make them an outlier.
Ultimately, the point of hardware attestation isn't to ensure that your device is trusted, but that the action you're trying to perform was done by a human, not a bot doing millions of them per second. It's just another CAPTCHA mechanism in disguise, required because bots have gotten so good at solving the existing ones.
With a secure device, the only way to get an attestation for an account signup is to do the signup on that device, with real fingers clicking real buttons on a real screen. There's no way to short-circuit the process by automatically sending a JSON request and bypassing the actual signup flow from a Python script, like you can do with an insecure endpoint.
With blind signatures, a single compromised device destroys the value of the entire scheme, as it can be used to issue an infinite number of attestations with 0 human oversight.
What we need is a blind signature construction where the verifier can revoke a signature, each signature carries proof that none of the revoked signatures comes from the same signer, and where it is impossible for one signer to issue more than n distinct signatures during one time window. Not sure if this would be possible with ZKPs; my cryptography knowledge doesn't extend that far.
> Ultimately, the point of hardware attestation isn't to ensure that your device is trusted, but that the action you're trying to perform was done by a human, not a bot doing millions of them per second. It's just another CAPTCHA mechanism in disguise, required because bots have gotten so good at solving the existing ones.
...no? Maybe this is true of end-user device attestation. But there are other use-cases for attestation.
Server device attestation is an entirely different thing. It's used in e.g. IaaS "Confidential VM" offerings, where the audience for the attestation information is the customer, rather than the server host. It's a very pro-privacy / pro-data-sovereignty feature.
And while embedded device attestation is sometimes about preventing customers from tampering with IoT stuff you "sold" them, more often it's about being able to trust and confidently assert that e.g. the climate sensors you've deployed all over a forest as part of a research project haven't been fucked with to report false data by someone with an agenda. (Or to "apply denial" to your unmanned military satellite downlink station the moment you detect that there's some unknown person out there futzing with it.)
They do not use zero knowledge proof systems or blind signatures. So every time you use your device to attest you leave behind something (the attestation packet) that can be used to link the action to your device. They put on a show about how much they care about your privacy by introducing indirection into the process (static device 'ID' is used to acquire an ephemeral 'ID' from an intermediate server) but it's just a show because you don't know what those intermediary severs are doing: You should assume they log everything.
And this just the remote attestation vector, the DRM 'ID' vector is even worse (no meaningful indirection, every license server has access to your burned-in-silicon static identity). And the Google account vector is what it is.
Using blind signatures for remote attestation has actually been proposed, but no one notable is currently using it: <https://en.wikipedia.org/wiki/Direct_Anonymous_Attestation>
There are several possible reasons for this, the obvious one is that they want to be able to violate your privacy at will or are mandated to have the capability. The other is that because it's not possible to link an attestation to a particular device the only mitigation to abuse that is feasible is rate limiting which may not be good enough for them - an adversary could set up a farm where every device generates $/hour from providing remote attestations to 'malicious' actors.