The entire article talks about “guessing” the bucket name as being the attack enabler, not the leaking of it. What does the landscape look like once you start doing the basics like hashing your bucket names? Is this still a problem worth engineering for?
that doesn't help either. 'Salt' is public and usually different/unique per entry/name.
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.
If they can't make the bucket before you do then they are not "bucket squatting", and they can't do so for a salted and hashed bucket name without knowing the salt at runtime.
The public/private distinction seems moot here, too: the salt is a throwaway since you just need the bucket name.
Even if you do need to keep track of the salt, it should be safe for the attacker to know, at least with respect to this attack, because you already own the bucket which the attacker would otherwise hoard.
The "squatting" part of "bucket squatting" is a bit of a misnomer here. The attack vector is actually in the opposite direction.
1. You set up an aws bucket with some name (any name whatsoever).
2. You have code that reads and/or writes data to the bucket.
3. You delete the bucket at some later date, but miss some script/process somewhere that is still attempting to use the bucket. For the time being, that process lies around, silently failing to access the bucket.
4. The bucket name is recycled and someone else makes a bucket with the same name. Perhaps it's an accident, or perhaps it's because by some means an attacker became aware of the bucket name, discovers that the name is available, and decided to "squat" the name.
5. That overlooked script or service is happy to see the bucket it's been trying to access all this time is available again.
You now have something potentially writing out private data, or potentially reading data and performing actions as a result, that is talking to attacker-owned infrastructure.
Seen this happen with Terraform. One team tears down a stack, bucket gets deleted, but another stack still has the name hardcoded in an output. Next CI run uploads artifacts to a bucket name that's now up for grabs. You only notice when deploys start failing. Or worse, succeeding against someone else's bucket.
> I guess I didn't quite say my point clearly, the time and physical cost to get to a grocery store puts up barriers against perfect price matching. You likely are not going to go out of your way to visit a grocery store for just a single item.
I think you’re a bit out of touch with the common man. People do this constantly, some to a comical degree, going so far as to make two loops on their shopping trip to return groceries they found cheaper at the next store.
> People do this constantly, some to a comical degree, going so far as to make two loops on their shopping trip to return groceries they found cheaper at the next store.
To go less far, it is pretty common for normies to have at least two supermarkets in their shopping list: one with lower prices and one with higher prices, but fancier goods.
I have never heard of someone returning groceries (unless it turned out to be moldy or something). Definitely not because they were cheaper elsewhere. Surely there would be food safety issues with accepting such returns.
Step into any Walmart and look at the carts in the customer service section full of just-returned merchandise, waiting to be returned to the shelves. You might be surprised with what you see.
amazing reading this thread and realizing just how much HN is disconnected from the reality of majority of people in America. returning food and hitting multiple stores is like a daily thing for several people I know
It's a great joke (and yes, a hilarious thread!), it's $10 in the original joke though so I would say it still works for now (not sure what a banana costs in the US today. Here it's about $1).
You may be assuming a car-centric approach to shopping, where the distance between stores is large. In cities where shops are mixed into residential areas, people often walk because stores are usually within about 10 minutes, and there are multiple options with different selections and prices.
That makes it easy to rotate: stop by one store one day, another the next, often on the way home from work since you’re taking the subway or bus anyway. For example, I buy most of my groceries at one store, and then pick up certain items in bulk at other stores every 1-3 months when they carry the brand I want at a good price (unless my usual store has a sale). Most people I know do something similar, especially as groceries have gotten more expensive, particularly since COVID.
And those people probably aren’t developers by trade, just power users who superficially understand the moving parts but who cannot write code themselves.
I think you severely overestimate your understanding of how these systems work. We’ve been beating the dead horse of “next character approximation” for the last 5 years in these comments. Global maxima would have been reached long ago if that’s all there was to it.
Play around with some frontier models, you’ll be pleasantly surprised.
This point is irrelevant when discussing capabilities. It's like saying that your brain is literally just a bunch of atoms following a set of physics laws. Absolutely true but not particularly helpful. Complex systems have emergent properties.
> that's a whole different level of ignorance, that's much more dangerous.
Why? Is it more dangerous to not know how to fry an egg in a teflon pan, or on a stone over a wood fire? Is it acceptable to know the former but not the latter? Do I need to understand materials science so I can understand how to make something nonstick so I’m not dependant on teflon vendors?
It's relative, not absolute. It's definitely more dangerous to not know how to make your own food than to know something about it - you _need_ food, so lacking that skill is more dangerous than having it.
That was my point, really - that you probably don't need to know "materials science" to declare yourself competent enough in cooking so that you can make your own food. Even if you only cooked eggs in teflon pans, you will likely be able to improvise if need arises. But once you become so ignorant that you don't even know what food is unless you see it on a plate in a restaurant, already prepared - then you're in a lot poorer position to survive, should your access to restaurants be suddenly restricted. But perhaps more importantly - you lose the ability to evaluate food by anything other than aspect & taste, and have to completely rely on others to understand what food might be good or bad for you(*).
(*) even now, you can't really "do your own research", that's not how the world works. We stand on shoulders of giants - the reason we have so much is because we trust/take for granted a lot of knowledge that ancestors built up for us. But it's one thing to know /prove everything in detail up until the basic axioms/atoms/etc; nobody does that. And it's a completely different different thing to have your "thoughts" and "conclusions" already delivered to you in final form by something (be it Fox News, ChatGPT, New York Times or anything really) and just take them for granted, without having a framework that allows to do some minimal "understanding" and "critical thinking" of your own.
When it comes to food prep, I'd agree with you that the more time of your life passes, the more irresponsible is the risk of not knowing how to fry an egg, for example.
At the same time, you only need to learn how to fry an egg once, and you won't forget it. You can go your entire life without ever having to fry an egg yourself - but if you ever had to, you could.
When it comes to coding, the analogy breaks down, I think. Aside from the obviously different stakes (survival versus control of your device), coding also requires keeping up with a lot of changing domain knowledge. It'd be as if an egg is one week savoury, another week sweet, and another a poisonous mushroom. It's also less of a single skill like writing a for loop, and more of a combination of skills and experiments, like organizing a banquet.
Coding today suffers from having too many types of eggs, many of which exist because some communities prefer them. I also don't like the solution "let the LLM do it", but it's much easier. Still, if we manage to stabilize patterns for the majority of use cases, frying the proverbial egg will no longer be as much of domain knowledge, choice or elitism as it is today.
You do need to be able to understand nonstick coating is unhealthy and not magic. You do need to understand your options for pan frying for not sticking are a film of water or an ice cube if you don't want to add an oil into the mix. Then it really depends what you are cooking on how sticky it will be and what the end product will look like. That's why there are people that can't fry an egg, people that cook, chefs, and Michelin chefs. Because nuance matters, it's just that the domain where each person wants to apply it is different. I dont care about nuance in hockey picks but probably some people do. But some domains should concern everyone.
> You do need to be able to understand nonstick coating is unhealthy and not magic.
Prove it. Please, show me a method by which polytetrafluoroethylene is going to kill me. Because if you're like everyone else moaning about "plastic bad" online, you'll be wrong, and if you have some secret insight that no one else has, I'd love to hear it. But a basic understanding of chemistry reveals that PTFE is functionally inert. It doesn't react with damn near anything, it needs heats well in excess of anything you should be exposed to cooking to melt or burn, and even if you were eating the stuff straight, the whole "inert" thing applies to just about any digestive process your body could apply to it, too.
Many places have "dev", "test" "prod"... but IMHO you need "sandpit" as well.
From an ops point of view as orgs get big enough, dev wraps around to being prod-like... in the sense that it has the property that there's going to be a lot of annoyed people whose time you're wasting if you break things.
You can take the approach of having more guard rails and controls to stop people breaking things but personally I prefer the "sandpit" approach, where you have accounts / environments where anything goes. Like, if anyone is allowed to complain it's broken, it's not sandpit anymore. That makes them an ok place to let agents loose for "whole system" work.
I see tools like this as a sort of alternative / workaround.
Sandpit should be a personal (often local, if possible) dev environment. The reason people get mad about dev being broken for long periods of time is that they cannot use dev to test their changes if your code (that they depend on) is broken in dev for long periods of time.
There’s no sandpit, only prod and dev, and you’re not allowed to break prod. Your developers work in partitions of prod. Dev is used for DR and other infra testing.
Hey, I get it. I don't want LLMs on prod at all. I made this to let agents connect to production cloned sandboxes, not production itself. I hope this helps your concerns, but I understand either way. Lmk with any other questions.
For example, if you had an on-prem footprint with thousands of VMs, a production cloned sandbox would be a clone of a VM to let AI safely make changes, install packages, etc.
Yeah, working on the landing page. Feel free to ask any other questions!
reply