Here is a message from @davidyuk discussing the signatures required for getting the cookie consent from the backend:
- to don’t use signing auth for get requests
- encrypt the response to get requests with user’s address if the response contains sensitive data
So, to don’t mix these security measurements
The discussion above is quite theoretical, but in https://github.com/aeternity/superhero-ui/pull/867 we have an issue about getting cookies settings on mobile. In comparison with the desktop extension, we can’t sign a message without confirmation (redirection to the wallet) on mobile. I see these ways how we can proceed with it:
- add a button to load cookies settings on mobile explicitly (I don’t think that this is so useful to make a separate button for that)
- automatically redirect to the wallet to sign a message and get cookies settings each time/the first time (may look weird, because the user didn’t do anything)
- to don’t load cookies settings on the mobile and just persist them locally (no need to implement anything, settings won’t be synced between mobile devices)
- to drop authentication to get cookies settings and implement it back later when we have a better architecture and reasons like adult content (my favorite approach, but require changes in the backend)
I wanted to move this discussion here so anyone can take part with their ideas.
So regarding the above discussion @davidyuk :
I agree that this is painful and we should find a better way but we have to design it so its scalable and works for other applications too. The signature for GET and DELETE requests (not talking about POST & PUT) only covers authentication, there is no data to be verified and the signatures are not stored. So it should be easy enough to replace it with a different mechanism. I have some ideas:
- Take some sort of JWT tokens (maybe even use the jitsi infrastructure). Simply encrypting the information would work for GET requests but not for DELETE where we will have the same problem eventually (although I will admit that GET is a lot more common and “random” feeling to the user than DELETE requests).
- We could choose a different signature / encryption mechanism that can not encode / sign transactions and can therefore be used without user consent.
- We could encrypt sensitive user data in the backend automatically and allow anyone to read them. This would also provide a protection against a data breach. This does however not solve the signature requirements for DELETE requests.
I am against your suggestion to remove the authentication for the consent endpoint as the next issue (retrieving notifications) is just around the corner.
1 Like
- This is fine for me. Initially, I was trying to build https://jwt.z52da5wt.xyz/ compatible with various services.
- Nice idea, we can use a personal message signing isolated to a superhero scope (by adding a prefix), to don’t make it possible to use these signatures in other services. But still it requires switching to the wallet app on mobile (even if confirmation is not needed).
- So, we need a more general solution that will support delete requests as well. The encryption approach is a bit better than the current one because we don’t need to make additional requests for a challenge.
Do we have any sensitive notifications, like private messages? If not, so I’m not sure that retrieving notifications has a privacy issue. Comments and tips are publicly available, not necessary to protect notifications about them.
In conclusion, I’m still for dropping the auth for GET requests or JWT.
How we should proceed with User settings for allowing/disallowing 3rd party content by AtanasKrondev · Pull Request #867 · aeternity/superhero-ui · GitHub cc @bruteforce.chain @maxkpower
1 Like
I agree that for now neither the notifications nor the user consent settings are so private that we need to restrict access to them but I am sure that we will require this privacy feature rather soon. Therefore I think we should find a scalable solution now.
1 Like