bruv, have you ever designed a fighter jet from a raft?
Because that is the equivalence of comparing OPFS is to a secured PostgreSQL query.
You cannot attain security from a raft, when fighter jets only need to drop bomps like a carpet to write on cities, and traverse microseconds of distances compared to whatever the wind is.
A postgres query is not a filesystem and also not intended at all for large binary blob storage and arbitrary range access? That’s an entirely different tool for completely different use cases.
The existing filesystem API (that the OPFS API appears to build on) is entirely reasonable for its intended use case, and is actually even more entrenched than OPFS given it exists for non-sandboxed uses, and has done for quite a long time. Remember, browser vendors will not break web APIs unless there’s no other option, for good reason.
I also feel like you keep shooting past the fact this is a side channel attack. It’s fairly reasonable to conclude any storage operation that hits the SSD could be used for this kind of thing. So basically any equivalent approach would require the same mitigations.
You’ve still not made any valid case for your claim that it’s insecure by design.
Just so we can draw this to a close: please explain, specifically and succinctly, which fixes you would make and why specifically the existing OPFS is fundamentally incompatible with your suggestions.
So far there has been nothing like that in this thread, just hand waving and it’s insecure by design, just trust me bro
bruv, have you ever designed a fighter jet from a raft?
Because that is the equivalence of comparing OPFS is to a secured PostgreSQL query.
You cannot attain security from a raft, when fighter jets only need to drop bomps like a carpet to write on cities, and traverse microseconds of distances compared to whatever the wind is.
OPFS is insecure by design.
A postgres query is not a filesystem and also not intended at all for large binary blob storage and arbitrary range access? That’s an entirely different tool for completely different use cases.
The existing filesystem API (that the OPFS API appears to build on) is entirely reasonable for its intended use case, and is actually even more entrenched than OPFS given it exists for non-sandboxed uses, and has done for quite a long time. Remember, browser vendors will not break web APIs unless there’s no other option, for good reason.
I also feel like you keep shooting past the fact this is a side channel attack. It’s fairly reasonable to conclude any storage operation that hits the SSD could be used for this kind of thing. So basically any equivalent approach would require the same mitigations.
You’ve still not made any valid case for your claim that it’s insecure by design.
Just so we can draw this to a close: please explain, specifically and succinctly, which fixes you would make and why specifically the existing OPFS is fundamentally incompatible with your suggestions.
So far there has been nothing like that in this thread, just hand waving and it’s insecure by design, just trust me bro