Update EIP-4973: Define initial criteria of a privacy considerations section #5686
Conversation
github-actions
bot
added
c-update
|
Thank you @kdenhartog. I'll review this in more depth later but one thing for now: I don't find it convincing to name the GDPR here. The EIP is an international process and some users may not need to specifically comply or even know GDPR so I think we shouldn't invoke it here. Still, whatever was said should be expressed but less GDPR-centric. E.g. there are other data protection frameworks in non EU countries so a more generic framing would be welcome. |
|
Another framing feedback is that we should refrain from giving legal advice and specifically we shouldn't be reminding anyone that they have to comply with the law. That's an obvious precondition for coordination and needs no mention. |
Fair point, I can update it to generally refer to data protection frameworks such as GDPR without specifically citing it as something that needs to be complied with specifically. This way dApp developers are generally aware of the need to consider these frameworks when building around this. |
|
yeah, please do update. But I'm wondering if a principled approach here wouldn't be better. E.g. we could mandate complying to H. Nissenbaum's contextual integrity and hence wouldn't have to invoke legal stuff of which I understand very little |
I'm not familiar with this work. Do you have a link so I could read up on it and consider the trade offs? I think it's fair to argue that using legal arguments aren't useful here |
|
https://en.m.wikipedia.org/wiki/Contextual_integrity surely the original text can be found online |
EIPS/eip-4973.md
Outdated
| @@ -187,6 +187,26 @@ You can find an implementation of this standard in [../assets/eip-4973](../asset | |||
|
|
|||
| There are no security considerations related directly to the implementation of this standard. | |||
|
|
|||
| ## Privacy Considerations | |||
There was a problem hiding this comment.
Defer to @TimDaub, I think authors are free to choose to include additional sections
There was a problem hiding this comment.
We used to be allowed to include Appendices, and in my opinion still should, but I don't care to fight that battle again.
|
I am in support that authors shall have freedom to add privacy considerations. (to avoid confusion, I am not in support for making it a mandatory section for all EIPs) |
|
I think @kdenhartog and I should re-read H. Nissenbaum's Privacy as contextual-integrity and then we should create an EIP "Informal" where we axiomatically discuss how privacy in the context of non-deletable messages on Ethereum should work. IMO this could really help bring consensus to many hot debates in the space respective to e.g. SBTs and Vitalik's negative reputation stuff. And additionally, it'd provide a solid and juristictional-independent guideline in the spirit of an international and inter-border Ethereum community. Sadly though, I have no idea how I'd get this document started lol. Maybe I can draft something after devcon. @kdenhartog would you be on-board with that? Or do you think we should focus on EIP-4973 specifically? |
|
In some ways I think that document would be beneficial independently to help authors produce a privacy considerations section, but without having it at this point I'd be concerned that it would be overly abstract to address all the types of data that get put on chain. This is why I would think it would still be beneficial to address the considerations directly in the document, but also to address the broader context of how privacy works within the ecosystem and how it can be improved over time. |
Pandapip1
changed the title
Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com>
Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com>
|
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
|
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
|
Waiting on consensus. |
|
|
||
| #### Storing Personally Identifiable Information (PII) on-chain presents privacy risks | ||
|
|
||
| Data stored within an account-bound token often times are claims which are directly associated with an account. In general, it's a privacy concern to directly store PII related to a person on-chain or to link data directly to an identifier like an Ethereum account. Doing so would make it impossible for a user to invoke their right to be forgotten which is necessary under GDPR and could place dApp developers under scrutiny if they do so. Even in the case where data is generally regarded as public knowledge, public attributes contained in an account-bound token shouldn't be published on chain as this can lead unexpected behavior that could leak user behavior or insights which can be used to later harm the controller of the account. Instead, dApp developers should consider providing an opaque URL to an off chain storage solution so that the data is not published immutably on chain so that the claim can either be updated, refuted, or forgotten in compliance with GDPR. |
There was a problem hiding this comment.
This section should be entirely removed:
- We're assuming GDPR and "right to be forgotten" regime (EU), but EIP readers/users are international. Generally, it is not our place to tell people what to do.
It is a good idea to suggest putting a claim off-chain to a mutable data source:
Instead, dApp developers should consider providing an opaque URL to an off chain storage solution so that the data is not published immutably on chain so that the claim can either be updated, refuted, or forgotten in compliance with GDPR.
We should leave this in but rephrase it away from GDPR-motivated framing.
|
|
||
| Data stored within an account-bound token often times are claims which are directly associated with an account. In general, it's a privacy concern to directly store PII related to a person on-chain or to link data directly to an identifier like an Ethereum account. Doing so would make it impossible for a user to invoke their right to be forgotten which is necessary under GDPR and could place dApp developers under scrutiny if they do so. Even in the case where data is generally regarded as public knowledge, public attributes contained in an account-bound token shouldn't be published on chain as this can lead unexpected behavior that could leak user behavior or insights which can be used to later harm the controller of the account. Instead, dApp developers should consider providing an opaque URL to an off chain storage solution so that the data is not published immutably on chain so that the claim can either be updated, refuted, or forgotten in compliance with GDPR. | ||
|
|
||
| Additionally, the data contained in the off-chain storage provider requires some sort of costs in order to store the data and as such storage providers that are storing these account bound tokens may be incentivized to store this data on behalf of users for free in exchange for the right to process this data. In general, this practice is likely deceptive in nature and should be discouraged. Instead dApp developers issuing account bound tokens should look to encrypt this data at rest. It's recommended that the keys used to perform this are derived or managed by the controller of the ethereum account that the account bound token is being issued to rather than the issuer themselves. |
| There are no security considerations related directly to the implementation of this standard. | ||
| ### Privacy Considerations | ||
|
|
||
| #### Storing Personally Identifiable Information (PII) on-chain presents privacy risks |
There was a problem hiding this comment.
before we mention privacy risk, we'd have to define privacy as e.g. "violation of contextual integrity." But then again, I think it must not be within the scope of eip4973 but an informal EIP document.
|
|
||
| #### Requiring authorization of data before releasing it to third-party providers | ||
|
|
||
| Furthermore, the off chain storage solution should perform a consent check which has been authorized by the controller of the account before revealing the data to a third party data processor. This check should perform some basic authorization checks which ensure that the controller of the account has authorized the third party data processor access to the data. |
|
|
||
| #### Identifier-based correlation of attributes stored in various account-bound tokens | ||
|
|
||
| Since account based tokens shared a strongly correlating identifier, the ethereum account, dApp developers should be aware of the correlation that's incurred by issuing attributes to the same ethereum account even if they are not all within the same account bound token. Multiple account bound tokens that are linked to the same long lived ethereum identifier will enable the possibility that behavioral data (e.g. commonly visiting a location if multiple location credentials are linked to the ethereum account) or inferential data (inferring a users time zone based on when they commonly use their ethereum account) can be used to deduce further correlation of a user in a way that the user did not consent to. In order to prevent these concerns, dApp developers should leverage the techniques of data minimization so that only the minimal necessary information is included in the account bound token. |
There was a problem hiding this comment.
remove: this isn't isolated to eip4973 and is generally true for any interaction with Ethereum
|
|
||
| #### Validity of account bound tokens for data processors | ||
|
|
||
| Due to the inherent nature of the claims made in a particular attribute of an account bound token, it should not be assumed that the account bound token is considered valid or authentic unless the data processor trusts the issuer and their processes for validating the data of the account bound token. Data processors are encouraged to reject account bound tokens that produce privacy violations or that enable bad privacy practices based on the reputation of the issuer of the account bound token. |
|
This can be closed and I can come up with a formulation that I let @kdenhartog review before we merge it here. |
|
Sounds useful @TimDaub, thanks for taking over to drive this forward. I think we're moving in the same direction more than I originally thought and having some time to put this aside and come back to it has been useful for me to see where you're coming from with this. I still see devs in the community who aren't seeing things in the same way about not putting PII on chain as you and I do. Unfortunately no amount of guard rails via better technical definitions or recommendations against this is going to stop them and they'll have to learn why on their own and all we can do via this privacy section here is point them in the right direction and hope they follow. |
cc @TimDaub here's the start of a privacy considerations section. I've not finished this yet. Just had to time box it for now, but wanted to get it out there for you to be able to review. I'll be adding to it over the next couple of days still, but curious where you land on this.
Much of this has been derived from thinking that's been defined already in the privacy considerations section of the VC spec