nh2

You're saying the app has the feature to export its sqlite DB?

If yes, that's exactly what the users in the linked bug report are asking Signal to add to be able to fix this problem themselves.

An owner of a device in physical possession of it and with the knowledge of all keys and passwords involved, they should be able to get all their personal data stored on it out of it, yes I think so, no matter who signs what on whatever app store.

Because Signal developers do not spend time on this.

Which is all well; after all nobody is paying them to do it.

My complaint is that they + iOS simultaneously prevent able users from fixing it themselves, or paying somebody to fix it.

Among

    Copyable vs Non-Copyable passkeys
    Transferable vs Non-Transferable passkeys
    Hardware-Backed vs Software-Backed passkeys
    User-Present vs Non-User-Present passkeys
    User-Verified vs Non-User-Verified passkeys
    Attested vs Non-Attested passkeys

They forgot

    Roaming vs Platform passkeys

(roughly: movable vs device-bound).

This is what e.g. PayPal uses to prevent you from using your Yubikey as a passkey, while it works perfectly as a passkey on other providers (e.g. Wise bank)

It's checkable in the browser with e.g.: `await PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()`

I'd be interested in a blog post on what those problems are.

There are lots of cases of "we wrote our own X, here's how it works", but rarely the concrete internal knowledge shared about what existing Xs can't do and why.

When the motivation stops at "look, the naive thing wouldn't work" even before the "normal" thing everybody does (fetch), it leaves many open questions to which you probably have an answer already.

> for a tech-stupid person

> password doesn't show up you know there's a problem

Here is your contradiction.

The normal person will just assume that some tech isn't working today again.

A key point of passkeys seems to be that it guarantees to the site owner that the user cannot be phished, without having to make assumptions on whether the user is tech-stupid.

Put stones into a desktop PC until it weighs 30kg and drop it from 1.20 m height while its running, onto your parquet, a couple times, I guess, to know if you and whoever lives with or below you is up to robotics testing?

Makes sense. I wasn't suggesting that one should do a shallow clone though. If your company repo is 100 GB, it seems sensible to keep it cached locally on each machine once (100 GB isn't large for current NVMe disks), and `git fetch` the updates the normal way. Then checkouts don't fetch anything large.

No, of course not.

As the article explains, "over 600 PB" = 25M code checkouts * 25 GB "compressed working copy".

So "fetched naively" here means doing a full `git clone` on every need for `git checkout`, which of course nobody should do, nor does that refer to "code that needs changing daily".

Pretty sure TCP is only linearly worsened by latency.

For me, RSS 35 MB, SHR 23 MB. The vaultwarden executable is 38 MB (typical Rust executable that links Rust code statically, and only dynamically links libssl.so and libc.so dynamically).

So probably its RSS usage is just mostly its own executable code?