yeah it's a delicously juicy problem for me to ponder on
you need to just remember that we can avoid storing actual valuable data of our clients, for a start, no kyc, at least, not on the gear that is doing the service
then you have threat models
the network side, the cryptography is pretty solid, but we have issues that may grow in complexity when the number of administrators increases, 1 admin, easy, 5 admins, that is 25x the risk level
the physical level, not sure how to address that one nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkjis probably more geared towards this vector of attack in his work with secure elements... my inclination would be to say we colocate and put strong squealers on our hardware
AI scraping means that a lot of data can be guess due to other data. Things happening near the same time stamp from the same region, for example. And even anons behind a VPN or Tor want some privacy.
Thread collapsed
The admin issue is what makes it tough. If someone can get to it and they control the encryption key, then they can leak it.
So, you need to anonymize or obfuscate it and/or isolate it programmatically and/or physically, as well as encrypt it.
i know you are a bit excited about this but after you think it all through for a while, digest it, you will have some good insights
i think that nip-86 was not really quite the right direction to go with this issue, it really needs a bigger plan than just addressing the superficial requirements, because of the threats that could be involved
for sure, limiting risk can be easily achieved by only having one owner who has superseding rights and technical skill to detect and remedy problems
the more people you give administrative rights, the less powerful administrative rights have to be
Ideally, even a person who can leak the decrypted data wouldn't be able to make sense of that data.
Like, if you used multisig. 🤔
Or batch discovery. Hmm. The server holds the key, maybe, and three people hold the server key.
Thread collapsed
this is a painful rabbithole you are diving into there
we have to define our threat model, and you must not think outside of it for reasons you are experiencing
we have to trust our server's physical security, for example, or otherwise we have to have physical hardening on our servers, which is a great increase in cost
it can be mitigated by making encryption schemes that defeat physical breaches, but there is limits to how strong you can make this security, especially with scale, cryptography gets astronomically expensive at scale, the math is absurdly expensive compared to simple ordinary computations, the overflows and so forth involved tend to be in the dozens if not hundreds of cycles per operation
Yeah, that's why we want different machines. Then you move the threaten more internal, which is easy to manage with permissions.
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
LOL you know how much I love this logic stuff.
you have work to do i seem to recall, stoppit
Okay okay.
Just realized that you could brute-force list discovery by just trying to AUTH with any active npub.
yes, "privacy protected" means that every user is an entry point
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
