41–50 of 187 posts
Why all that stuff with namespaces when they could just not allow name reuse?
I'd allow re-use, but only by the original account. Not being able to re-create a bucket after deleting it would be annoying. I think that's an important defense that AWS should implement for existing buckets, to complement account scoped bucket.
Sometimes I wonder if package names, bucket names, github account names and so on should use a naming scheme like discord. Eg, @sometag-xxxx where xxxx is a random 4 digit code. Its sort of a middleground between UUID account names and completely human generated names. This approach goes a long way toward democratizing the name space, since nobody can "own" the tag prefix. (10000 people can all share it). This can al…
Notably Discord stopped using that format two years ago, moving to globally unique usernames. Their stated reason[1] for doing so being: > This lets you have the same username as someone else as long as you have different discriminators or different case letters. However, this also means you have to remember a set of 4-digit numbers and account for case sensitivity to connect with your friends. [1]: https://support.d…
Sometimes I wonder if package names, bucket names, github account names and so on should use a naming scheme like discord. Eg, @sometag-xxxx where xxxx is a random 4 digit code. Its sort of a middleground between UUID account names and completely human generated names. This approach goes a long way toward democratizing the name space, since nobody can "own" the tag prefix. (10000 people can all share it). This can al…
For buckets I thought easy to use names was a key feature in most cases. Otherwise why not assign randomly generated single use names? But now that they're adding a namespace that incorporates the account name - an unwieldy numeric ID - I don't understand.
In the case of buckets isn't it better to use your own domain anyway?
Earlier quoted context omitted.
I don't think that'd prevent this attack vector.
Ok; salt, and then hash your bucket names
If you mean to use a "secret" prefix (i.e. pepper) then, that would generate effectively globally unique names each time (and unpredictable too) but you can't change the pepper and it's only a matter of time it'd leak.
Earlier quoted context omitted.
I just want to be able to use a verified domain; @example.com everywhere.
That still has "squatting" risks as described in the original article though, domains expire and / or can be taken over.
For particularly high risk activities if circumstances permit you can sidestep the entire issue by adding a layer of verification using a preshared public key. As an arbitrary example, on android installing an app with the same name but different signing key won't work. It essentially implements a TOFU model to verify the developer.
Sometimes I wonder if package names, bucket names, github account names and so on should use a naming scheme like discord. Eg, @sometag-xxxx where xxxx is a random 4 digit code. Its sort of a middleground between UUID account names and completely human generated names. This approach goes a long way toward democratizing the name space, since nobody can "own" the tag prefix. (10000 people can all share it). This can al…
Notably Discord stopped using that format two years ago, moving to globally unique usernames. Their stated reason[1] for doing so being: > This lets you have the same username as someone else as long as you have different discriminators or different case letters. However, this also means you have to remember a set of 4-digit numbers and account for case sensitivity to connect with your friends. [1]: https://support.d…
Imagine trying to connect with your friends... by telephone.
Earlier quoted context omitted.
Notably Discord stopped using that format two years ago, moving to globally unique usernames. Their stated reason[1] for doing so being: > This lets you have the same username as someone else as long as you have different discriminators or different case letters. However, this also means you have to remember a set of 4-digit numbers and account for case sensitivity to connect with your friends. [1]: https://support.d…
It was honestly a downgrade i ended up just putting the 4 digits I had before at the end of my username cause surprise the name was taken immediately
When a name becomes free and somebody else uses it, it points to another thing. What that means for consumers of the name depends on the context, most likely it means not to use it. If you yourself reassign the name you can decide that the new thing will be considered to be identical to the old thing.
I started treating long random bucketnames as secrets years ago. Ever since I noticed hackers were discovering buckets online with secrets and healthcare info. This is where IaC shines.
This is all good and we'll on the IaC side,yes. But at the end of the day, buckets are also user facing resources, and nobody likes random directory / bucket names.
If anyone wants them to be user facing resources, then treat them as such, and ensure they're secure, and don't store sensitive info on them. Otherwise, put a service infront of them, and have the user go through it.
The S3 protocol was meant to make the lives of programmers easier, not end users.