ethereum
Update EIP-4973: Define initial criteria of a privacy considerations section
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
Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):
(fail) eip-4973.md
| classification |
|---|
updateEIP |
- eip-4973.md requires approval from one of (@timdaub, @ra-phael)
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.
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.
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
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
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.
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.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
I just realized I left this under review the whole time. Looks like this still needs to be updated per @TimDaub request on this. Do you have any specific suggested text for me to start from @TimDaub so I can update it?
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.
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.