That's a cool idea, I'd definitely like to add the ability to create a little store with more safety, and that totally works with the goal of simplicity. I'll give it a shot.

It's a cool idea, but the old anti-pattern about security through obscurity applies.

People get this wrong a lot.

Security only through obscurity is no security at all. The argument was generally made in the context of secret, proprietary encryption algorithms. In this context, it was frequently true - security reduced to reverse engineering.

But security isn't a thing. It is a property of a system. And many secure systems strategically employ obscurity for multiple purposes.

Reciting a mantra is a poor substitute for carefully considering your problem domain.

Right, but in the context of this application, there is NO OTHER security except the obscurity of the UUID or it’s hash. The mantra applies quite well here since an attacker could stumble upon a valid hash or UUID and then change the data.

The attacker could stumble upon a valid hash like they could stumble upon a valid password.

I never really understood this argument, obscurity add an obvious layer of protection, not impenetrable of course, but still valid. Why is this different than an API key for example?

If compromised, you can change an API key. The key is like a password, and keeping that secret is important.

Where the "obscurity" aspect comes in, as an example, can be through the mechanism used to generate and validate that key.

Let's say you decide you don't want to or can't store the keys, and don't want a full pki system (public/private keys or certificates), so go with: sha256(clientid + userid + "hardcoded secret"). Your security now 100% relies on no one knowing that algorithm. If someone figures it out, you need to release a new version of your software, invalidate ALL API keys, and for that effort you still haven't done anything to prevent the same thing happening again.

A good test of this is: if someone has your source code, can they break your security mechanism? If yes, you're probably relying on security though obscurity. By contrast, if you're using asymmetric encryption to generate keys, it doesn't matter if someone knows that: if they don't have the private key, they can't do anything. (This leaves aside the issue of storing your private key or other secrets in source code, but I'd describe that as an operational failure rather than a fundamental design problem).

If a cryptographic hash function is used, the security of this scheme doesn't rely on keeping the algorithm secret, though. Therefore, it's not security through obscurity. Of course, weaknesses could still exist (e. g. a too small input space because the ID that is hashed has too little entropy).

Security through obscurity refers to relying upon keeping the details of the security mechanism secret. An API key itself is a secret, but the mechanism for how that key is generated and used is public knowledge.

In fact, the reason the best security mechanisms used today are so robust is specifically because they are made public in the first place.

It is done, lmk if it works alright. The read only hashes should be visible beneath the data editing view on a new one.

Adding it to the homepage would be cool too ^^

How would you phrase it?

"write only link here"?

I really wanna keep the basic information visible and am not sure about about adding another line

i meant under "Access your data with:" something like "Or read old link:"

but you're right it can be discovered