Web hardware revocation API

[akakou]

This proposal achieves privacy-friendly web hardware revocation (i.e., hardware ban). In particular, it makes a web servicer(i.e., web server) capable of blocking users who have previously abused them without users' privacy violations.

Background

As is well known, malicious actions on the internet are increasing, and it is a big problem. One of the factors that their prevention makes difficult is the user's anonymity. So servicer can't block users who have abused in the past because the servicer can't track the user.

The easiest way to solve this problem is to track the user. It means servicers require strong identification schemes of users like SMS or credit card authentication (i.e., 3D secure). However, it causes privacy concerns.

Thus, we need a method that blocks users who abuse in the past without tracking. In the mobile context, the DeivceCheck API of iOS satisfies them; they provide a hardware revocation scheme conscious of users' privacy. However, I can't find Web APIs like them. In addition, DeivceCheck API assumes common trusted execution comportment of devices, so many devices can't support it.

Idea

This idea is for Web APIs to provide a hardware revocation method without violating user privacy.

Mainly this idea consists of a cryptographic protocol and hardware registration protocol. The cryptographic protocol achieves revocation without tracking risk, but it assumes that the user doesn't have multiple secret keys. Therefore the hardware registration protocol limit number of distributed secret key to users to support the realization of the assumption.

The cryptographic protocol which this idea used is named anonymous blocklisting protocol. The most popular anonymous blocklisting protocol is EPID(Enhanced Privacy ID). EPID is a signature scheme that ensures user anonymity but revocability. First, EPID realizes strong user privacy. In EPID, there is one public key and multiple private keys. So the verifier can't track users because the same public key is used to verify all signatures. Second, EPID has strong revocability. The servicer (i.e., verifier) can revoke the user(i.e., signer) with the user's signatures which were used for malicious actions. Note that the verifier doesn't need to track or identify users.

Hardware registration protocol is for limiting the number of distributed secret keys to users. It assumes GM(i.e., Third Party for registration), and the user attests their device ID to GM and obtains the EPID secret key. Concretely, such attestation schemes are available, like TPM EK attestation, Android ID Attestation, or iOS DeivceCheck.

References

EPID:

• https://www.intel.com/content/www/us/en/developer/articles/technical/intel-enhanced-privacy-id-epid-security-technology.html

TPM Attestation:

• https://learn.microsoft.com/ja-jp/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation

Android ID Attestation

• https://source.android.com/docs/security/keystore/attestation?hl=ja

DeivceCheck API

• https://developer.apple.com/documentation/devicecheck

[akakou]

I proposed this PR here, thanks to the advice of privacy community group members.

privacycg/proposals#37

[akakou]

@dvorak42

I found a similar proposal, #14.
Do you think we should discuss it on #14?

[dvorak42]

Yeah, I think there are similarities that merging the threads/discussion might be good. Though if you're interested in presenting on this particular proposal, we can wait on that to see if the CG thinks there's enough differences in the proposals to keep separate.

[akakou]

OK! (I am interested in presenting it, and) I want to wait for the CG's decision.

[dvorak42]

Can you open an issue on https://github.com/antifraudcg/meetings/issues/new with how long you think you'll need for a presentation (to present and time for questions). This week's meeting is full but we can try getting you scheduled for one of the next couple meetings.

[akakou]

@dvorak42

OK! I'll make th issue.

Additionally, I have a question: can I present it a little later? (actually, I expect the next April)

I need experience in how the CG meeting does, and to know whether I have an English skill to participate in it.

[dvorak42]

Yeah, presenting later is fine, we'll just reach out to folks with open agenda items before every couple meetings to see if they're able/interested in presenting at the coming meetings so you can present whenever you feel prepared for it.

[akakou]

I'm sorry that I have not proceeded with this presentation.
I realized that my English skill is insufficient to present this proposal recently.
So I need more time to learn English to explain this.

Fortunately, my English skill is growing up rapidly.
I will be able to propose it this September...could you wait for me?

[dvorak42]

Doing a presentation in September would work.

[akakou]

@dvorak42 Thank you for waiting.

Could I present this topic in August?
This is because I expect I will be busy this September.

My English skill is still not enough yet, but I will try hard to prepare a translator, or I will use an AI translator in the worst case.

[akakou]

By the way, negative reactions to this issue are outstanding.

Hello, @arm64-v9a, @scanlime, @TomasHubelbauer, @Conan-Kudo, and @BurnerWah.
Thank you for sharing your honest reactions with me.

Would you tell me why you think it is not good?
Your input will help me to improve it for future presentations, if you don't mind.

RFC8890 is a good place to start

[akakou]

@scanlime

Thank you for your link.
I have read it first, and it is so interesting!

However I don't understand your intention because of my lack of studying, and I have a question.

Did you mean that this proposal prioritizes the service provider (i.e., Web site) over users so it is not satisfy RFC8890, thus not good?

Yes, at a direct level this is taking control away from users and giving more to device manufacturers and web hosts.

It's also part of a larger project to organize the web around the motivations of large industry players instead of decentralized groups of individuals. The stated anti-fraud goals are not a requirement for making the web a better place, just a requirement for small numbers of entities to run vast empires with a minimum of human connections or oversight.

[Conan-Kudo]

@akakou More concretely, as a Linux user, I can see this API being abused to essentially lock out my platform.

As a general piece of commentary, the various proposals made by this group are designed with the model that someone is going to be a valued, impartial, and reliable arbiter of access. In reality, this almost never happens. As a user and developer of Free Software platforms, it becomes harder and harder every day because features like EME and WEI are created by well-intentioned people who do not realize what they are creating.

It is often stated that the path to hell is paved with good intentions. Proposals like these fall very much in that camp.

I would urge you to evaluate the problem you're trying to solve with a simple question: "what happens if I have no voice and a need for something?" Providing ways to ensure people can't use something means they're ultimately foreclosed from it. There are very few legitimate reasons to enable that on the web.