ragona

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.

> encrypts it with a static key

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."

It’s handy for uploading a dataset and having it play with it.

> it's about being genuine

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.)

The CDK and Pulumi teams must be truly delighted by this move.

You don’t think handling edge cases and errors is fundamentally necessary?

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.