feat(client): hashed targets #2

Open
opened 2025-05-07 03:50:35 +01:00 by nex · 0 comments
Owner

To improve privacy, the observatory client should support hashing targets before setting/fetching. Hashing targets would mean that it's harder for an operator to pry information directly from the database or for someone to just iterate over the database and re-construct it.

Of course, by nature of observatory basically just being a tracked key store, clients can just not send hashed entities, and there's nothing the server can do about it. Hashing on the server-side would get expensive quick, and at the volume of requests i've seen to observatory, would likely end up slowing the service down. Doing it on the client would also mean the server never sees the unhashed tartget.

To improve privacy, the observatory client should support hashing targets before setting/fetching. Hashing targets would mean that it's harder for an operator to pry information directly from the database or for someone to just iterate over the database and re-construct it. Of course, by nature of observatory basically just being a tracked key store, clients can just not send hashed entities, and there's nothing the server can do about it. Hashing on the server-side would get expensive quick, and at the volume of requests i've seen to observatory, would likely end up slowing the service down. Doing it on the client would also mean the server never sees the unhashed tartget.
nex changed title from feat: hashed targets to feat(client): hashed targets 2025-05-07 03:50:57 +01:00
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
nex/observatory#2
No description provided.