Whoops

Okay, so I realized a critical error a little bit ago that is like so “duh.” DeleteMessage currently just verifies the signature on the payload, and doesn’t verify any authorization because, currently the records are being stored such that there is no externally identifiable information about the user. So unless (totally possible) I’m missing something significant, I think we only can have the option where we try and enforce “don’t delete other people’s crap” via strict regulation and process, and bad actors have no real gate from just deleting everybody’s messages other than $.

Or maybe there’s another way…

There may be a better alternative that can actually preserve the user’s identity on the record while still achieving the same goal, but for now I think I have something that is secure enough because there’s no reason for us to do that… but I don’t know how that affects things like requests for content? What if it’s all just stored locally as fast as possible? It’s the “keeping it on the server for an extended period” that’s the hard part. Maybe we’re okay with the trade-off? And then you ask, “okay, well then if somebody gets the raw record, they can check right away” and I would just say that we should encrypt it with a key that the database server owns, before inserting it into the record.

Anyway, if we did go that way (encrypted signature stored alongside record for authorization purposes on deletes), then we would just have to understand that our users would be vulnerable in the case where we were commanded to disclose. Maybe the answer really just is “the only safe data is the data that lives with you, and nowhere else.” We could just encourage “dumping it out” of our system. Basically they throw a message up for a day, all clients collect, bam it deletes. So you got 24hrs for your own security… or we can have you set the time for how long before the message should clear? And just explain the risks to users when they set up the account.

Okay, anyway I also changed up the plan on InnerMessage and decided that it just goes in straight up as binary because then I don’t have to deal with the whole struct matching bullshit and the oneof (which I already feel like I overuse, but they are kinda useful in a way that I don’t know how to get over… kinda like the Rust-style enum). This works because we’re including the “reserved client id” in every payload. basically every client gets their own id to prefix the pod with. I feel like this is something that can be reasonably enforced. Basically the most they can do is send nonsense payloads and annoy the client for having to catch bad parsing errors, or for making users “visit” more records. Idk, anyway I think this one is fine because URLs IRL are fine. But basically just remembered that you can get pretty fancy with the prefixes and for that reason we can actually just utilize “pod for everything” concept. Just change the prefix to the string.

The thing that would be good about trying to get people to download the data and delete it fast… super low overhead for me, personally, long term. The longer people decide to hold it, the more $ they spend on storage, and the higher the risk that something could happen with the signature verification (or actually, just being on the server is a kind of a vulnerability), so we should just encourage them to delete their data as fast as possible. I bet most people pick a month? I feel like a me before tech would’ve picked 30 days. Me after tech is like “2min. If you give a fuck about my content… you’ll consume it and download your encrypted copy in less than 2min.”

Okay, anyway lower data expense is nice and I feel like it’s easier to manage across regions because I think data transfer is supposed to be one of the more expensive things to look out for, and it encourages better security practices. You have to understand that while it’s not unencrypted on the payload, the signature is visible to our system, in order to authorize deletion. I feel like it should also just be stored as a separate record maybe? And I feel like for longer form content or anything where you want it to last a long time, you don’t actually care if your signature is tied to it. So really, it only matters for people who care about their signature being visible. So yea, I guess just explain the risks, maybe some security person can tell me that I’m overthinking it, idk, but we’ll figure out how to make users happy.

So yea, everything holds, just slightly less secure and we should comfort the people who care by emphasizing the better security practice of only storing on devices you own. The client can manage how fast disappearing happens (hopefully giving the reins mostly to its users), but we now need to support it “natively” for the client. exp.

Okay, cool cool. The exp can be set on the client. We just index the <exp>#<MESSAGE_ID> -> String { string pk = 1; }. And then every random seconds in a minute or ms or whatever granularity causes not everything to explode… on some cadence within a short period of time of triggering the call to get the exp key’d String value, it will run the job to delete it from the database.