61–70 of 79 posts
I'd already been pondering the paperclip-machine universe that could be created by a Twitter bot that just pipes tweets to bash and posts the output. Now it could just trawl Twitter for addresses at https://textdb.dev , and throw the contents through bash, post the result back to textdb, and tweet a new link... :]
It would be cool if it was possible to read the data not just by the ID, but also by the hash of the ID. That would let us serve stuff like version information and links to the latest version, without the fear that somebody is going to reverse engineer our app and replace the data with something malicious. We, as the app author, would have the full key, so we could read and write, whereas users would have nothing but…
It is done, lmk if it works alright. The read only hashes should be visible beneath the data editing view on a new one.
I see some of you are realizing that I haven't enforced any data url to be a UUID, good on you. I hope it opens up new neat things like https://textdb.dev/data/hello-hackernews or more creative ideas.
I see some of you are realizing that I haven't enforced any data url to be a UUID, good on you. I hope it opens up new neat things like https://textdb.dev/data/hello-hackernews or more creative ideas.
That's awesome! I was wondering if I had to go to https://textdb.dev using the browser to get an ID x)
Earlier quoted context omitted.
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 ^^
"write only link here"?
I really wanna keep the basic information visible and am not sure about about adding another line
Earlier quoted context omitted.
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 se…
This seems to be in a similar spirit to https://patchbay.pub/ . I love these small services, but I still don't have an idea how they can be scaled up: If you want to use them for anything serious you probably have to prevent abuse and comply to all kinds of regulations.
Earlier quoted context omitted.
Really simple cool! One minor thing on the IP rate limiting side.... LOTS of mobile/cell users might end up NAT'ed behind a single IP. Just an FYI.
That's a good point. How does one rate limit correctly in that case?
Earlier quoted context omitted.
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 p…
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.