Made because I couldn't find a simple, no-sign-up service to sync a list of names for a command line tool. And resubmitted because yesterday I goofed and the curl commands listed didn't point to the right location, which really took the fun out of it.
Favorite part of the project: trying out Phoenix's built in pub sub + live view (the live view subscribes to a data/:id topic, which the api write endpoint publishes to) to get that nice instant update on write if you have the data open in the browser without polling.
It's also fun to see how fast it syncs multiple browser windows watching the same data when you edit it in one window. That's not useful, but I give it 1 "neat".
wellllll there's no GREAT answer. Usuallllllyyy this is why some lightweight authentication is a good idea? Some kind of TGT/token scheme, and then rate limit based on that? But does make it all a little less "just works"
Hey, if you ever wanted to come on my podcast to talk about your tech stack (how it was developed, deployed, lessons learned, etc.) I'd love to have you on.
There's a few Phoenix episodes out currently, but none are using Live View yet. It would be really fun to talk about how someone is using it in production.
If you do, head over to https://runninginproduction.com/ and click the "become a guest" button on the top right to get the ball rolling.
Whoever made this, I love you. I do a lot of prototyping in Framer, and this just make simple prototypes that communicate with one another hell of a lot easier!
Hell yeah, I'm planning to keep it up for a good while and lemme know if something isn't working or you'd like a new feature. bontaq @ the google mail .com
nginx is in front, but it's just doing a proxy and setting some headers, so effectively cowboy's serving everything.
So far it's doing a great job too, CPU is at 2%, 1Gb free ram of the 4Gb available, and a pretty constant 1Mbps outward, on the 20$/m digital ocean droplet. I may have jinxed it by saying this though.
"There currently isn't, but it is intended for small amounts of data. Today or tomorrow I'll probably put a cap at 500Kb or so, which is still a heckload of data."
There currently isn't, but it is intended for small amounts of data. Today or tomorrow I'll probably put a cap at 500Kb or so, which is still a heckload of data.
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.
Yeah they're nice and fun to build. I imagine if you wanted to, you'd run this behind a VPN at #corporation, which will be a huge pain to get approval for, but not that bad.
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 the hash.
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.
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?
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.
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 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.
What language is this? I visited https://www.phoenixframework.org/ and even watched a few minutes of a video but there's no mention of the programming language. I suppose the language is called Phoenix?
Very cool! Do you have any sort of dashboard displaying stats for the service? Simple totals would be interesting, of course (size, # of buckets, # of edits, etc.), but I'd find histograms of edits etc. per bucket particularly fascinating.
I also like the idea of batch requests so you can pul multiple keys at once, or set multiple keys at once. It seems better for everyone.
My only concern is that a small portion of users will undoubtedly try to abuse this with high volumes or large objects, or both.
Have you published any limits on value key size, value size, read/write limits for keys etc? It might be worth thinking about now before you have to shutdown users or shutdown the service due to cost.
Thanks! So far the limits are about 500Kb, which is more than enough for what this service is intended for.
The setting of multiple keys I'd have to think about, as it's already so easy to acquire multiple keys -- ie I don't think I'd be saving or making anything much faster by special handling for it. Pulling multiple keys is likewise, you're free to do it in an async all.
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'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... :]
Nope, especially seeing the current usage / data size I think it's perfectly fine to hang around forever. I may eventually implement something to clean up data with no reads for > 1 month, but again so far it looks fine to leave things around.
I think this is really nice and smart. I would suggest left-aligning the text in the edit/view mode for a few reasons:
1) It's a bit easier to read for longer text sources
2) It makes writing/reading JSON/YAML/other data sources much easier
3) lists are much easier to parse
78 comments
[ 2.8 ms ] story [ 164 ms ] threadFavorite part of the project: trying out Phoenix's built in pub sub + live view (the live view subscribes to a data/:id topic, which the api write endpoint publishes to) to get that nice instant update on write if you have the data open in the browser without polling.
It's also fun to see how fast it syncs multiple browser windows watching the same data when you edit it in one window. That's not useful, but I give it 1 "neat".
> Note that IP addresses can be shared behind NAT devices, so limiting by IP address should be used judiciously.
https://docs.nginx.com/nginx/admin-guide/security-controls/c...
There's a few Phoenix episodes out currently, but none are using Live View yet. It would be really fun to talk about how someone is using it in production.
If you do, head over to https://runninginproduction.com/ and click the "become a guest" button on the top right to get the ball rolling.
BTW, the front page's HTML seems to have a <head> and <body> inside another <body>.
Yeah I'm not sure why it's doing that, v annoying though
https://www.stavros.io/posts/messaging-for-your-things/
A handy substitute for mqtt since it doesn't allow a simple http get/post method to set and query keys - something very useful with iot stuff!
So far it's doing a great job too, CPU is at 2%, 1Gb free ram of the 4Gb available, and a pretty constant 1Mbps outward, on the 20$/m digital ocean droplet. I may have jinxed it by saying this though.
"There currently isn't, but it is intended for small amounts of data. Today or tomorrow I'll probably put a cap at 500Kb or so, which is still a heckload of data."
Your link is a message service that self destructs.
OPs link is a storage service
I usually star things instead of bookmarking and others probably do too.
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.
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 the hash.
In fact, the reason the best security mechanisms used today are so robust is specifically because they are made public in the first place.
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).
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.
"write only link here"?
I really wanna keep the basic information visible and am not sure about about adding another line
but you're right it can be discovered
- https://elixir-lang.org/
- https://www.erlang.org/
I love the idea of Hashing and read/write keys mentioned in this comment: https://news.ycombinator.com/user?id=miki123211
I also like the idea of batch requests so you can pul multiple keys at once, or set multiple keys at once. It seems better for everyone.
My only concern is that a small portion of users will undoubtedly try to abuse this with high volumes or large objects, or both.
Have you published any limits on value key size, value size, read/write limits for keys etc? It might be worth thinking about now before you have to shutdown users or shutdown the service due to cost.
Congrats again!
The setting of multiple keys I'd have to think about, as it's already so easy to acquire multiple keys -- ie I don't think I'd be saving or making anything much faster by special handling for it. Pulling multiple keys is likewise, you're free to do it in an async all.
https://reg.t0.vc
It's useful if you set up bash aliases like "push" and "pull" so you can quickly move snippets of text across servers.
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... :]
1) It's a bit easier to read for longer text sources 2) It makes writing/reading JSON/YAML/other data sources much easier 3) lists are much easier to parse