The concept of a proxy injecting/removing sensitive data has been for much longer, e.g. VGS has a JS SDK and proxy to handle credit card data for you and keep you out of PCI scope.
I'm surprised it's not mentioned yet, but this seems to compliment last year's acquisition of observability tool HyperDX[1] (part of ClickStack[2]) quite well. I'm in the market for a new o11y platform and it seems all vendors are working to add LLM observability one way or the other, if they haven't added it already.
> This is one of the frustrating realities of these attacks: once the malware runs, identifying the source becomes extremely difficult. The package doesn't announce itself. The pnpm install completes successfully. Everything looks normal.
Sounds like there’s no EDR running on the dev machines? You should have more to investigate if Sentinel One/CrowdStrike/etc were running.
> Using UUIDv7 is generally discouraged for security when the primary key is exposed to end users in external-facing applications or APIs.
I would not call this “generally discouraged” when APIs generally surface a created_at timestamp in their responses. A real life example are Stripe IDs which have similar properties (k-sorted) as UUIDv7: https://brandur.org/nanoglyphs/026-ids#ulids
The problem starts earlier with the secret key which you can't place "into" a TKey. You can deterministically derive one between the TKey and a server using some thing like a (semi) static DH but that isn't how it is implemented in general.
I understand that the ability to place stuff "into" a TKey would be needed to support discoverable WebAuthn credentials ("passkeys"). But would it also be needed for non-discoverable credentials?
Yes, to set a PIN protecting the non-discoverable credentials. The FIDO PIN can be changed while you have access to the authenticator and not to the credentials it previously created.
Well, it could still provide credBlob (up to 32 bytes of data stored in the non-discoverable credential and handed back after verification). But mostly yes, it's losing the advantages of FIDO2.
We've used it for about a year - Blazer is okay if you need a quick SQL query console, but we found it lacking as a business intelligence tool. The support for graphs and dashboards is limited, for graphs it requires you to structure the query in an exact way as you can see in the Blazer readme. There is no customizability at all.
After some research on available alternatives that don't break the bank, we decided to deploy a self-hosted instance of Metabase[0]. This took only a few minutes to set up using their Docker image[1] and it has much better graphing capabilities and you can easily put a custom layout together for dashboards. Upgrading is similarly easy (just redeploy). Also easy to configure: additional data sources, hiding or changing the data type of a column, G Suite sign-in for our domain. It has 'models' as sources of truth to build other queries in - eg a single definition of an 'active user'.
In short, moving from Blazer to Metabase was a huge win for us. Highly recommend it if you need anything more than Blazer's table output.
Quickly? They acquired 6 River Systems and announced the Shopify Fulfillment Network back in 2019. The were some pivots along the way (using 3rd party vs building out own warehouses) but it seems to me they've been at it for some time.
