web
web copied to clipboard
gitcoinco
Address isn't 100% private
Describe the bug
Even if a user set the Hide my wallet address option to true under the profile privacy settings, the address can be easily unveiled through a GET request
To Reproduce
You can get any user ETH address by doing a GET request to https://gitcoin.co/tip/address/<user>
Expected behavior
~~Remove the /tip/address/<user> endpoint and change the logic for sending tips on /app/assets/onepager/js/send.js so user address lookup is performed on the backend when sending a POST request~~
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
This issue now has a funding of 0.2 ETH (44.78 USD @ $223.91/ETH) attached to it.
- If you would like to work on this issue you can 'start work' on the Gitcoin Issue Details page.
- Want to chip in? Add your own contribution here.
- Questions? Checkout Gitcoin Help or the Gitcoin Slack
- $83,570.05 more funded OSS Work available on the Gitcoin Issue Explorer
Issue Status: 1. Open 2. Cancelled
Work has been started.
These users each claimed they can complete the work by 1 year, 10 months ago. Please review their action plans below:
1) developerfred has been approved to start work.
https://github.com/gitcoinco/web/issues/6090#issuecomment-592563130
I just asked to be added to this issue 2) akshit-wwstay has applied to start work (Funders only: approve worker | reject worker).
I am new to gitcoin. Excited to resolve an issue and learn how it works.
Learn more on the Gitcoin Issue Details page.
@PixelantDesign Why was I approved and subsequently removed? Did you accidentally approved the wrong worker?
frank from gitcoin here - just as a note for next time.
While we understand that the workplan that we ask you to write can seem potentially long and daunting, we're not asking for a crazy paragraph, but we do wish for more than commenting how long it would take and the depth of difficulty the task is for you.
We'd like you to show us the broad steps that you would take to understand and complete the bounty. This helps us determine who might be a good fit to work on the issue. Of course we'll take this into consideration and also who applied first, but if someone is very articulate about their work plan, it gives me more confidence as a funder as to their confidence and ability to accomplish it.
open to any feedback so feel free to @ me and drop it here too. Happy hunting!
@frankchen07 thanks for feedback, what i'm doing on this issue is a simple modification to preserve the user's wallet.
@frankchen07 Was that supposed to be a reply as to why I was removed? Because I actually left a work plan disagreeing with the approach of removing a backend API endpoint.
hey @KiChjang my bad. Are you still interested in working on it? @danlipert what do you think of the approaches?
I commented that I disagreed with the approach as stated in the issue, because removing an API endpoint may cause some frontend code, test or services to misbehave. It is generally more acceptable to instead deprecate the endpoint and redirect frontend code to a new API endpoint in order to preserve backwards compatibility.
I'm not so affected by being rejected to work on an issue, but I'm more worried that the rejection was a way to stifle discussions about the best way to fix this issue, and it certainly appeared so when I was rejected and subsequently ignored for several days.
@PixelantDesign @kichjang @frankchen07 @santteegt I'm not sure this is even solvable without removing tip functionality as it stands now - we allow a user to directly send a tip to another user with the data collected on our platform for purposes of CLR matching, showing network activity, improving your profile, etc.. Without having the destination user's ETH address theres no way for the sender to properly construct the transaction in metamask. We do have the "proxy tip" flow for users who don't have an ETH address set in their profile. This would require people to sign into Gitcoin to retrieve every tip which would be obnoxious given the micro-tipping on Townsquare.
Honestly, a user's ETH address isn't really something we should expect to be private - Any interaction with the site reveals it on the blockchain anyway. The "Hide my address" feature basically just removes it from the UI, but @santteegt is right, it can be obtained through a direct API request anyway. Even if that wasn't the case, a proxy tip could be traced via the blockchain as well.
i agree that we can't completely solve this, but i do think we can make incremental steps to not dox our users. my vote would be to just make the tip address lookup 1:1 (one handle => one address) and then make that endpoint so that it can only be accessed while logged in + put it behind a rate limiter.
@developerfred Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
- [x] reminder (3 days)
- [ ] escalation to mods (6 days)
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days
I'm down with improving this further - @owocki what did you mean by one handle -> one address?
I immediately thought of using cryptography to protect addresses, only gitcoin backend would be able to encrypt
Address request comes with a cryptographic key, goes to the backend that resolves the cryptography and sends the coins. I believe that the cost of this function is not monstrous.
@danlipert @owocki
Hi everyone,
Here is something I thought about.
Implement "authentication" on that endpoint. Might include a combination of having an ethereum address and some cookies. Need some pointers / ideas on where is the code for this, if this is already implemented (I mean authentication) / or what you think is the best way going about authenticating users for the purposes of making a request to obtain the address of someone they wish to tip.
Hide the address behind a handle, which is stored in the db. The handle is a randomly generated 5-character long base64 encoded string. This will give us 1 billion unique keys (64 ** 5; we can think about changing the length (incrementing by one so that it is 6-character long) once more when more than 12.5% of the world population uses Gitcoin; soon? ;) given the gmv passed $5mil in 2 days lol; granted it was close to 5 mil to begin with :) ). The storage of these keys is negligible. Each char is a byte, if we go by the number of Slack Gitcoin users (actual number of website users with an address is lower I believe). Then 20000 users * 1 byte per char * 5 chars = 100000 bytes = 0.1 MB to store the keys. If the user has this handle, then we retrieve their address with the handle (in the code), if not, we generate one (handle) for them. This can be done on the fly. We need to ensure that the generated handle is not used, for this, we can pre-generate the handles.
For Kevin's rate-limiting suggestion: AFAIK, gitcoin web is using Django, so we can decorate the endpoint with django-ratelimit's decorator.
What are your thoughts?
Think of this issue, as the hackthon of probability protocols, today we have zcash and also tornado.cash that the signal is very promising.
Gitcoin already has a claim service. my idea is simple to execute all the tips and transfer to a service on Gitcoin that uses the user as a flag to identify the address. for example, @developerfred is my user and unique, when a logo receives a message that receives a tip / reward that I authorize transfers that can be a contract that generates dynamic records and makes payments.
flow
🧙♀️[ Alice] -> ✉️ [100 DAI] -> 🛸[gitcoin proxy security contracts or nodes] -> 📬 [ BoB receive 100 DAI]
This process can take place at layer2, we just need to suggest a contract signature for our users.
When the privacy process was placed on layer2, we would only have one transaction per day with the amount already validated, what do you think about that?
Believe that this way you can hide the address from users.
