The idea was to launch the proof of concept with public URLs, then if I discovered people were interested, create private URLs. Thing is private URLs require an authentication system, which is fine, but I didn't want to overdevelop the proof-of-concept.
I like the flexibility, but I would suggest you add a "generate GUID" button when choosing the group name in case the user does want a random URL, which seems quite likely.
Yes and no. You could argue that use of passwords or private keys is security through obscurity, but that definition is pretty meaningless. Security through obscurity doesn't really apply when you can make the search space arbitrarily (often exponentially) big very cheaply, as is the case of URLs here.
Manu times you need a counter just to get a unique id. If the counter is incremented by someone else it's not important. On the other hand if the counter can be reset because it hasn't been used for 48 hours it's a big problem...
Comments
So anyone can increment your counter without you knowing? Seems like this means you can never rely on the count being right.
As a side note, the link on the bottom is broken.
The idea was to launch the proof of concept with public URLs, then if I discovered people were interested, create private URLs. Thing is private URLs require an authentication system, which is fine, but I didn't want to overdevelop the proof-of-concept.
I fixed the link. Thanks! :)
You can just use a 128-bit random string as a group key. That's how "private" photos are implemented on most photo sites, for example.
I think that's the way to go for the public URLs. I'm going to leave it up to the user to come up with a unique group name though.
I like the flexibility, but I would suggest you add a "generate GUID" button when choosing the group name in case the user does want a random URL, which seems quite likely.
Unless they know what counter you're using or you make it public, it's unreasonable that anyone could mess with your counter.
...or you choose convenient, meaningful $group and $id names, which makes even unintentional collisions not at all unlikely.
This would be an example of security through obscurity.
Yes and no. You could argue that use of passwords or private keys is security through obscurity, but that definition is pretty meaningless. Security through obscurity doesn't really apply when you can make the search space arbitrarily (often exponentially) big very cheaply, as is the case of URLs here.
Manu times you need a counter just to get a unique id. If the counter is incremented by someone else it's not important. On the other hand if the counter can be reset because it hasn't been used for 48 hours it's a big problem...