Definitely, but when we're running around sprinkling PQ algorithms all over the place, it's on top of the asymmetric bits, not replacing the "boring" stuff like your symmetrically encrypted backups. Shit certainly does happen, especially where key management is involved, but I'm not sure I agree that offering an encrypted backup feature is necessarily undoing the FS/PCS story.
edit: Well, let me argue with myself for a moment. I don't think offering an encrypted backup feature undoes the PQ story. But FS/PCS is weakened, sure, since we're talking about all types of shit happening, not just currently known (or strongly theorized) attacks.
What type of static key? If it's just a big symmetric key that isn't derived from an asymmetric handshake of some type then no, that's not our current understanding of the PQ threat model.
I don't think that's quite right. PQ attacks focus on the "trapdoor" functions in asymmetric cryptography, _not_ the symmetric encryption that happens after key negotiation. The current concern is that a future attacker could unwrap the symmetric key, not directly attack the symmetric encryption that is used for something like backups.
(Note: I didn't actually dig into the backup implementation, but my guess is that it's more of a KDF -> symmetric design, rather than the sorts of asymmetric negotiation you'd find in multi-party messaging.)
(Note; I also work for OpenAI Security — though I’ve not worked on our bounty program for some time. These just my thoughts and experiences.)
I believe the author was referring to the standard BugCrowd terms, which as far as I know are themselves fairly common across the various platforms. In my experience we are happy for researchers to publish their work within the normal guidelines you’d expect from a bounty program — it’s something I’ve worked with researchers on without incident.
Yeah if you click into the report per industry it shows a totally different number -- $1.7T, which is obviously smaller than the ~$5T that the same site lists for oil and gas.
The "eval" phase is done after a model is trained to assess its performance on whatever tasks you wanted it to do. I think this is basically saying, "don't evaluate on the entire corpus, find a smart subset."
I think this is an incredibly important lesson. Don't lie, _actually_ find something good to say. It's a goddamned super power, and it's also very good for your own mental health.
I agree that complexity and quality can be unrelated. I think that quality is often misinterpreted as beauty, or brevity, or cleverness — and those are not the same as quality, in my opinion. Often a long function with a bunch of error and edge case handling is seen as ugly, and thus low quality, and what I’m getting at is that an ugly function can also be quite high quality.
And heh yeah it was on my mind because I just spent a few years at a FinTech too — and a lot of that code is incredibly sensitive, and must contain all kinds of “ugly” condition handling that I don’t think is really low quality, it’s just a complicated problem space that requires a ton of attention to detail. And details can be less fun to read, I think we all can get seduced by code golfing and making things prettier, which is again not the same thing as better.
(Which is I think the point of the article — readability and prose is perhaps key in literature, but not always in software.)
I think the problem with this assertion is that over time "good" code often ends up littered with important conditionals to handle cases that upset the general readability and expressiveness of the initial delivery. Imagine a FinTech working on some kind of trading platform. It seems simple and clear at first, but over time more and more safety mechanisms, edge cases, regulatory obligations, and all kinds of other things need to be added -- and often they need to be added _now_, which means that readability is not the primary concern. I think that's the point of the article; readability is often not the most important thing.
I don't think that suddenly catapults the code into "bad" code, and in fact it's this kind of accumulated wisdom that makes full rewrites so famously expensive. The initial core of the idea might be able to be expressed in a simple and beautiful way, but over time it turns out that almost nothing is truly simple, and complexity accumulates. But it's good complexity, it's important to the business, and it doesn't mean that it's bad code.
Yeah I'm sure there are counter-examples. My experience is that I worked at Amazon from 2012-2020, and I recall trying to shut down a project in maybe 2013 and it was _incredibly_ tricky.
Dang, I'm actually surprisingly sad about this. DPReview is _the_ site for extremely detailed analysis of cameras. When I want to buy something I go through their report first, and it's always extremely informative.
It feels like this kind of layoff is part of an end of an era. Amazon used to NEVER cancel projects that customers were using. They just straight up Did. Not. Do. It. I once had to get approval from my VP's VP because we wanted to turn off a product with eleven daily users. 11. The number after ten.
A whole lot more than eleven people used DPReview, and they provided a service that I'm not sure is well replicated from other sources. A loss for the internet, and it makes me sad that these kinds of quasi-public-good projects are getting canned across the industry.
I get that big companies are not retirement homes for nerds but... with as much profit as the profit centers bring in, there was a little wiggle room for passion projects. Now it feels like that wiggle room is being squeezed right out of the industry as we all brace for the recession that hasn't quite shown up yet.
I bet it's easy to make $500/day briefly, and hard to sustain it. Catalytic converters have the benefit of not requiring you to break into someone's house where risk of being caught or harmed is way higher.
This is a bad take. Making good IAM Roles and Policies is incredibly complicated if you have a complicated account. You WILL get it wrong. This becomes much more tractable if you have reasonable account boundaries between workloads.
If you insist on a single massive account you're fighting against the way that AWS designs the system, and you're gonna have a bad time.
> understood that managing down is much more important than managing up and (3) knew how to say "no" to upper management effectively.
Wait, saying "no" to upper management _is_ managing upwards. If you have a high performing team you can damned near ignore them as long as you're paying attention to what matters to them so that you can manage up effectively and keep bullshit off their place. If you have a team that needs a lot of help then yes, you have to focus on managing "down" -- but that's the less common scenario in my experience.
I suspect you're defining "managing up" as "brown-nosing" -- which is just managing up ineffectively. Being good at managing up and out is honestly the bulk of the job at most organizations; engineers can usually just do their thing.
I get it -- it's such a trap to say, "well, <tech giant> does it!" But in this particular case, I actually think they're walking the walk of having small teams that act like startups. You end up with small engineering teams owning a tiny little bubble, and it does a LOT to keep complexity down in terms of what one team has to manage.
(This is of course much more true for greenfield projects, early stage stuff. Of course the giant services are large and complicated.)
I've started to believe that product engineers should manage their own infrastructure. I think the key ingredient is _isolation_, so that it's not that they have to figure out how to fit their service into the unholy single production account with 15,000 running instances, it's that they get to start fresh from a basic template and then move from there. Most services, when isolated from the other microservices, are just not _that_ complicatedl
For what it's worth this is how AWS operates, and I think it's the mindset with which they build products. You certainly _can_ go your own way and run something like k8s on top of it and build a mini-cloud in the cloud, but it's incredibly expensive.
It's a mistake I've made repeatedly -- "Oh, I'll just add this little abstraction to make it easier for developers!" But now the poor developer has to understand both the tools I built on top of _and_ whatever I was thinking at the time, and inevitably it's an under-resourced area.
Now, at a certain scale for core services, sure, you'll end up with infrastructure specialized folks. But I'm unconvinced that the place you want to start is, "Okay, I need a new service, better go talk to the beleaguered central team that never has quite enough time for anyone."
edit: Well, let me argue with myself for a moment. I don't think offering an encrypted backup feature undoes the PQ story. But FS/PCS is weakened, sure, since we're talking about all types of shit happening, not just currently known (or strongly theorized) attacks.