ethereum
New contract interface and EIPs should be required to include a privacy considerations section
Proposed Change
This one was a bit obvious to me and it's only once I started reading through EIP-1 that I realized it's not required. Pretty simple to remediate. Let's just add a requirement that new EIPs being created and any EIPs entering the final call stage are required to include a Privacy considerations section. A reference to how to help developers define this section can be linked to here: https://datatracker.ietf.org/doc/rfc6973/
I think this should be an (optional?) subsection of the security considerations section. Privacy is a security consideration, and all non-obvious privacy considerations should be listed there.
There are plenty of EIPs where privacy considerations are not an issue. On the blockchain, everything is public by default, and everything should be assumed to be public except when commonly known to be private (e.g. private keys) or explicitly stated.
Privacy and security are often separate issues to be considered. This is why IETF cites the necessity for both of them. Even in the case where no known privacy or security issue is known a simple statement can be stated as such. For example, a document outlining how to define privacy considerations still defines a security considerations section even though it's defining how to write a document. https://www.rfc-editor.org/rfc/rfc6973.html#section-9
I don't think it's unreasonable to require an author to include these sections. Even if it's as simple as stating that nothing needs to be considered.
I don't think it's unreasonable to require an author to include these sections. Even if it's as simple as stating that nothing needs to be considered.
The vast majority of EIPs don't need this section. As previously mentioned, everything is public by default. Could you point to a specific EIP in which this section would be useful?
@kdenhartog thank you for the proposal, can you give us a bit of examples based on some EIP what their privacy section will look like?
I tend to agree that core category EIPs don't seem to have any need for these considerations. I've not found one so far as I've briefly skimmed them and come up with some things that could be discussed in a few EIPs.
Starting from the beginning. Here's just a few things I'd be thinking about to enhance the privacy of these different EIPs if I was considering implementing them. There's plenty more and I can keep going if you think it would be useful to show how this would be useful.
EIP-20: Considerations around the usage of too large of a decimal value allowing too much precision which can be used to correlate transfers even when moving through a coin mixer (this is an issue with Z-Cash's shielded transactions). Considerations around linkability of transfers between users and well known addresses such as exchanges.
EIP-86 (and various other account abstraction works): considerations how various types of contract logic such as multi-signatures and delegation links two persistent identifiers (e.g. Ethereum accounts)
EIP-107: Fingerprinting concerns to identify the user as a web3 user.
EIP-137: linking of persistent identifiers. Fingerprinting concerns. Usage of a new persistent identifier. Basically all the did-core privacy considerations apply here too: https://www.w3.org/TR/did-core/#privacy-considerations
EIP-162: Same considerations apply as 137
EIP-173: correlating activity done as a contract owner with other on chain activity. E.g. should a personal be used when deploying the contract separate from an account used for interacting with other contracts?
EIP-181: probably lots of similar considerations as 137 and 162 here.
EIP-191: Displaying warnings to users about checking to make sure no PII is included in the transactions
EIP-600: Considerations around the ability for people with access to a public key being able to derive child path keys and link ownership of ETH accounts
EIP-601: Same as 600
EIP-627: Usage of this protocol for a P2P messaging scheme to link two communicating parties by a passive malicious actor.
EIP-634: Lol this one is funny because it's now encouraging storing PII on chain which has generally been regarded as a bad idea due to the immutability property
I see. Thank you for a very long list of examples. That's very helpful. I am weakly in favor of adding a privacy consideration section, and make it optional. I do think that the complexity of privacy consideration also lies in the different expectations of web3 vs web2...
Okay, I think that's a big enough list to justify it being its own 2nd level section. I still don't think it's large enough to warrant being a required section though.
I'd be in favor of requiring for Interface/ERC but optional for network and core. The purpose really is to force the authors to consider the adversarial aspects of privacy invasions and to spur the discussion. If there truly isn't any than a quick short sentence would be suffice I think.
For example EIP-190 I couldn't come up with anything for this one even though it's an ERC track. Would take all of an additional 30 seconds to state that though and it opens up the discussion for authors to start considering these aspects. I'd be concerned that if this is optional then I'm left fighting an up hill battle for each one where I want to advocate for privacy considerations. Also, I don't believe this should be a normative section. It's really just about calling out some privacy problems and tradeoffs that implementers should be thinking about here and trying to find ways to address.
I still don't think it should be a required section for ERC category EIPs, if only because the expectations of privacy on the blockchain are greatly lowered. For interface EIPs, though, I would be in favor of requiring it since most of them do introduce privacy risks when using web2.
Main reason I saw them as useful is to highlight how clients should be interacting with the ERCs. Assuming a user interacted with a single discrete contract the risk is quite minimal. However, this is an uncommon pattern in this space so making recommendations to wallet developers is that are interacting with these standard contracts will assist with how they go about implementing support for the contracts. Once the data is public I agree there's little that can be done. Including this section as a required option can open up a discussion that justifies a modification to an interface to reduce the amount of information that gets published.
For example of this see the recent privacy considerations section I've been working on with the author of account bound tokens in #5686
It significantly changes how users would interact with a contract to expand the definition beyond an interface to also include expected behavior such as including off chain URLs rather than the data directly on chain.
None of the active editors are lawyers, so I don't think we're qualified to review privacy concerns.
I don't think any of the listed EIPs have enough privacy concerns to justify more than a sentence in the Security Considerations section. EIPs that specifically deal with PII should certainly have a privacy subsection, but generally speaking EIPs deal with interfaces, algorithms, and pseudonymous accounts; not personal information.
None of the active editors are lawyers, so I don't think we're qualified to review privacy concerns
Privacy concerns don't have to have a legal element to them. In fact, that's one of the things being discussed in #5686 is that GDPR isn't a good basis for why a technical consideration is considered.
This is how W3C handles privacy considerations sections and horizontal reviews of them:
https://www.w3.org/Guide/documentreview/#how_to_get_horizontal_review
https://www.w3.org/Guide/documentreview/#how_to_get_horizontal_review
Side note - the EIP process really needs a horizontal review process like that.
There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
I think the general consensus for this has landed on keep it optional and I'm good with that (Personally, I think requiring it would be more beneficial, but I'm willing to compromise). The part that's not clear is whether this should added as a new top level section or if this should be made a subsection of the security considerations section. It seems that making it a subsection of security implies that privacy is a subset of security considerations when often times they are considered separate. For example, correlation of an EoA account across different dApps isn't a security issue because it's a public key that has no effect on the outcome of the security model. However, it does allow for the user to be tracked across dApps which does impact privacy still. Therefore, it makes sense that if we want this section to be added to the template it should be considered a separate top level section that is optional to include.
I personally would prefer a 2nd-level "Considerations" with 3rd-level "Security", "Privacy", and "Other".
+1
Agree with @kdenhartog that we want security and privacy considerations in the same level.
Agree with @Pandapip1 that it's better to have a top level "Considerations" with security and privacy as second level section.
I'm +1 to that, that seems like something that could achieve consensus and then lead naturally to a path overtime as expertise is built up. I'm willing to update the template and Walidator bot if the other editors are in alignment with this as well.
My idea for how this might play out is that for we could make all these sections optional. Then overtime if we build up proper expertise for security/privacy (accessibility is another horizontal review process that could be useful later on) "review boards" that can help review and provide feedback to these sections. At that point it may make sense to turn these sections from optional to required, but until we have sufficient number of people with expertise willing to help I think this is the best middle ground for now.
There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.
I think this should be an (optional?) subsection of the security considerations section. Privacy is a security consideration, and all non-obvious privacy considerations should be listed there.
@Pandapip1 Privacy and security overlap but neither is strict subset of the other. Lumping both types of considerations into one section would be a mistake. In general privacy is about a person while security is about data.
@Pandapip1 Privacy and security overlap but neither is strict subset of the other. Lumping both types of considerations into one section would be a mistake. In general privacy is about a person while security is about data.
There would be subsections. So:
Considerations
Security
(Security considerations here)
Privacy
(Privacy considerations here)
Other
(Other considerations here)
There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.
There has been no activity on this issue for 1 week. It will be closed after 3 months of inactivity.
re-pinging @axic @gcolvin @lightclient @SamWilsn to see if they've got an opinion on this. If they don't weigh in within the next 2 weeks I think we should assume that they've seen this and chosen to abstain from the consensus process. Wdyt about that @Pandapip1?