notorious_pgb

You're right and I was misremembering (we had only developed against modern mobile browsers), though I am 100% certain we made use of these extensions on iOS Safari, so I honestly don't believe caniuse when they assert that it supports _neither_ extension. Per my recollection, iOS Safari supported the large blob extension quite early on.

Apologies for the brash statement earlier; that was wrong of me.

Very fair (see my edit), though I would submit to you that this isn't a sufficient polyfill for PRF, since PRF allows for a _secondary secret_ alongside the public key, allowing the server to safely store the public key without storing the cryptographic seed material itself.

The inability to use a passkey for the purposes of both authentication and secret storage (at least, without building non-trivial additional cryptographic plumbing) seems to me a reason to just use and push for the continued adoption and acceleration of the purpose-built extensions, instead of reusing a _public_ key as private material.

Interesting, but the PRF / LargeBlob extensions already enable just such functionality (and more) without relying on the secrecy of a public key.

Why not just use those?

Edit: that's what I get for not reading far enough -- the article addresses this, though I would quibble with the confident assertion that the extensions are not available in major browsers, given I worked for a startup literal years ago which built major functionality on top of these extensions, which were available in (at least) all relevant mobile browsers.

Deeply, deeply insulting.

I don't mean to be rude, but what could possibly have given anyone with eyes and ears a positive -- friendly, even -- impression of Google?

Not the most gracious post, I suppose.

I would draw a distinction between "working in the tech industry" and "being instrumental to the rise of a terribly consequential corporation over the course of decades".

Copyright is a strange thing to bring up, given I mentioned it not and I couldn't possibly care less about it.

Really tired of reading LLM blog posts, especially ones used to hock SaaS.

Respectfully, it's not clear to me what you're saying. You're clearly displeased with both the author of the article and with myself, but beyond that, I'm not sure what your thesis is.

Primarily poor wording on my part.

I think in terms of language features and patterns which actually mean something. OOP doesn't really mean anything to me, given that it doesn't seem to mean anything consistent in the industry.

Of course I work with classes, inheritance, interfaces, overloading, whatever quite frequently. Sometimes, I eschew their usage because the situation doesn't call for it or because I am working in something which also eschews such things.

What I don't do is care about "OOP" is a concept in and of itself.

I think that "OOP" is an incredibly overloaded term which makes it difficult to speak about intelligibly or usefully at this point.

Are we talking about using classes at all? Are we arguing about Monoliths vs [Micro]services?

I don't really think about "OOP" very often. I also don't think about microservices. What some people seem to be talking about when they say they use "OOP" seems strange and foreign to me, and I agree we shouldn't do it like that. But what _other_ people mean by "OOP" when they say they don't use it seems entirely reasonable and sane to me.

With respect, none of this sounds like "amazing" work on DuckDB's part. It's not bad work, either! It's competent work.

Comparing it to a naive approach (encrypting an entire database file in a single shot and loading it all into memory at once) is always going to make competent work seem "amazing".

I say this not to shit on DuckDB (I see no reason to shit on them); rather, I think it's important that we as professionals have realistic standards that we expect _ourselves_ to hit. Work we view as "amazing" is work we allow ourselves not to be able to replicate. But this is not in that category, and therefore, you should hold yourself to the same standard.