md_

Ugh. Thanks! :)

No.

The “famous” cases of hyperinflation—Weimar Germany, Argentina, etc—all come with extraordinary political instability as well. I’m not an economist, but it seems to me safe to say that hyperinflation is as much a political phenomenon as it is a monetary one.

Now, it’s certainly possible that the US is facing such political risks, what with efforts to disenfranchise large groups of people, entrenched rule-by-minority, and one of the two major parties expressing strong support for anti-democratic ideologies. (See https://carnegieendowment.org/publications/86352, for example.)

But when people express concerns about hyperinflation—without mentioning the political component—it’s a bit like having a suspicious growth on your shoulder, and worrying that the diagnosis might come back that you’re not going to be able to walk around shirtless anymore.

In May 2020, the definition of M1 changed to include savings accounts that were previously excluded. If you look at the “old” series it’s _much_ less alarming: https://fredblog.stlouisfed.org/2021/05/savings-are-now-more....

Federal debt isn’t really directly related to what you are concerned about, since there’s no monetarist argument that issuing more debt itself is inflationary. (If it were, then private debt would also be inflationary, which is nonsensical!) The only reason debt would be inflationary is if it’s bought by the Fed, printing money. But a) we already covered that, with money supply (not as scary as it looks!) and b) the % of debt held by the Fed has only increased slightly (https://fredblog.stlouisfed.org/2017/03/the-depth-and-breadt...).

No.

Also, bootcamps don’t turn out experienced senior engineers or talented managers. If you’re really good at that, grow your leadership and management skills—those are rarer and more valuable than your ability to hack JavaScript.

I don’t think that’s necessarily true.

Do I trust ProtonVPN’s free tier less than I trust a random access point named (say) “NYC Free WIFI”? I would say no: I know who ProtonVPN is, and I’m only trusting them, not all their other users.

I agree a lot of free VPNs are shady as fuck, but free tiers from reputable companies are reasonable, and if anything may be more trustworthy than your home ISP.

As I said to the other reply, I was thinking “that you host yourself” (i.e. Algo) when I wrote this.

That said, I think this is a bit too absolute. ProtonVPN has a free tier, for example, and they’re seemingly a legit company (who make their money from the paid tier). I would not disrecommend ProtonVPN—it’s probably as or more trustworthy than most free public wifi.

But the same argument for public wifi applies to VPNs: you shouldn’t be that worried, because important things don’t rely on network trust anyway.

This is what I use when:

a) I'm traveling b) I remember to turn it on c) I'm not blocked by the wifi (which is common)

IOW, while Algo is great, and I'm pretty paranoid, "distrusting public wifi" is sufficiently far down my personal threat model stack rank that I don't really care about it much.

I meant like Algo. My point was only that the threat here is so small as to not be worth spending real money to mitigate it.

But I'm being a bit tongue in cheek--most users are not going to want to set up Algo. And you're right that otherwise, the VPN is probably as sketchy as the wifi itself.

Private Relay DNS appears to be a default (at least on my device).

Doesn't Android do DoT by default? And iOS does iCloud Private Relay by default?

It's not a "yes/no" answer. If you're visiting http:// sites, if your OS doesn't use DoH/DoT, if you have unpatched vulnerabilities exploitable by same-subnet attackers, then maybe it's dangerous.

The question is, is it dangerous enough to:

- Use a VPN? Yes, if the VPN is free, trustworthy, and not blocked by the wifi.

- Not use the Wifi, and instead pay for data/roaming? Nah.

- Tell lay users that "avoiding public wifi" is one of the top things they should do to stay secure online? Hell no. User attention is expensive, and wifi is relatively safe.

"I don't use public wifi without a VPN" is the new "I never click links in email." It's something semi-technical users say to show off how much less pleasant their online experience is for no particularly good reason. ;)

I do think the author is correct to imply that there's substantial survivorship bias when people talk about US market returns over the 20th century. (A stronger statement than the author makes: the causality is bidirectional; strong US market returns are not merely a consequence of the 20th century being "the American century", but a cause of it.)

But equally weighting other country markets is also nonsensical; the lower returns of the Nikkei in the last 20 years go hand-in-hand with that exchange have a smaller total market cap.

A more meaningful comparison would be to look at whole-world market-weighted returns, and try to correct for survivorship bias, as the authors of this paper have done: https://www.nber.org/digest/jul97/century-global-stock-marke....

It’s a little odd to me that the author hopes FIDO keys as a single factor is rare. This is explicitly supported by FIDO and Yubico, and available in the Microsoft ecosystem (https://support.microsoft.com/en-us/windows/sign-in-to-your-...)!

As tomxor said elsewhere here, though, batch attestation allows you or relying parties to check that the key is a “real” Yubico key.

In any sufficiently long discussion of PGP’s merits, it becomes obvious that those arguing for PGP are not motivated by a desire to keep communications confidential, but, rather, to justify use of PGP.

So, why not just use Signal or WhatsApp?

‘Cause they’re not PGP.

It feels like you’re arguing that, technically, GPG _can_ be used to achieve the same level of security as modern messaging platforms. That’s probably true. (I say “probably” because I’m not a cryptographer, so I’m not qualified to speak to the cipher algorithms used.)

My claim was never that, though. My claim is that in the “normal” usage of PGP, it’s substantially less secure than modern alternatives, and that this is a mostly inherent byproduct of the use cases for which PGP appears to be constructed.

Succinctly: it’s hard to use PGP securely.

Can you do it? Probably. Could PGP be the default if everyone gave up on the easier to use, more secure alternatives? Well, on this point I am skeptical: before Signal, Wire, Threema, WhatsApp, etc—some of us remember those days!—the “default” was plaintext email. Not PGP.

PGP had 30 years to become the norm. During the first twenty or so, it had no real competitors other than S/MIME. And, here we are.

There are a lot of areas—fountain pens, for example, or vintage sports cars—where old technology has its own appeal, but encrypted communications isn’t one of them.

> Sounds like poor security if their client isn't doing the encryption, not an issue with encryption itself. Regardless, the point of encrypting email isn't to worry about what happens on the receivers end. If the receiver messes up then that is on them.

Surely it’s on me, if I wanted the content to be secret?

> What metadata are you concerned about here? Subject lines?

I was mostly thinking subjects and traffic patterns itself. PGP trivially leaks both.

> Change your subkey then. Forward secrecy is more for real-time communication though, but if you want to generate a subkey to exchange a message then I'm sure it can be automated.

As I noted elsewhere in this thread, PFS doesn’t work for PGP’s normal usage model (without a lot of hassle, as you noted, with subkeys). I don’t think it’s that people don’t want PFS for asynchronous communication; it’s that email doesn’t make it easy to do.

> I hear that a lot but I think the real issue is that users don't want to change anything and just want someone to do it for them

I think that’s a fair characterization. But if you, as a software or product person, want to improve user security, the first thing you have to do is make usable secure products. PGP is almost never usably secure; it’s arguably not usable most of the time, and that’s doubly true when used securely!

Yeah, I think that’s fair.

As a nerd, it does seem to me like I should be able to give the bank a public key and let me worry about my own security. But I don’t think this is actually what the bank or the user wants—they don’t want encryption per se, they want authentication, and an HTTPS link in an email (that you have to login to view) achieves that.

OMFG. This is the sort of thing that makes people not want to use PGP.

"It's totally easy to get PFS with PGP. You just have to read my 1000-word blog post about manually creating and distributing subkeys and be super careful you are editing the correct key before you proceed..." ;)

The other person replying already pointed out why this is an apples-to-oranges sort of argument, but for one specific point:

> There is no technical reason that you can't do forward secrecy for PGP. There is simply no real need for it.

Erm, I think there is such a reason--or at least, I can't imagine how you would implement PFS with PGP without substantially changing the usage. How would you do session key management a la https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm?

The entire premise of PGP seems to be that I can email you using just your long-lived key, without any other sort of session keying. That seems to fundamentally prevent PFS, no?

IMAP with OAuth is standard. What am I missing?

App passwords are not limited in scope, AFAIK.

You can use XOAUTH with IMAP just like any other IMAP client (including Thunderbird, as I noted above).

I think that’s the biggest problem, but there are others.

Off the top of my head:

- PGP key discovery is hard to do securely. Do you just trust what’s on the public keyserver? Do you use RFC 7929? S/MIME is relatively better in this respect, but obviously still quite behind the state of the art for e.g. Web PKI.

- PGP has so many different potential client configurations that it’s hard to reason about what security you are getting. Someone can (and for S/MIME, this is quite common!) have a PGP or S/MIME gateway that encrypts/decrypts mail to/from MUAs—meaning messages sit unencrypted in mailboxes and end user devices.

- PGP doesn’t encrypt metadata.

- PGP doesn’t give forward secrecy.

I’m sure there are other things I’m not thinking about, but for at least these reasons, PGP is in some ways less secure than SMTP TLS, hard to use correctly, and in general a lot of effort to leave you worse off than if you just chatted over WhatsApp/Signal/Wire/Threema/etc instead.

Transport layer security (and enforcing that) is definitely good for email, and we’ve moved the state of the art beyond where it was in the ‘70s, but I think the quest for true e2ee in SMTP-based email is probably not worth the effort.

Email should be thought of as having certain tradeoffs (like messages living unencrypted on servers, and relying fully on server to server trust), and for things that need e2ee, you should use something like Signal instead.

> Google, not the Thunderbird team, are to blame for why your Gmail password is the same as your Google Vault password…

Hmm, but couldn’t third party developers just use OAuth instead? Thunderbird works with Google’s standard XOATH Oauth IMAP implementation, last I checked.

The nice thing about FIDO is that I can use the same USB key for a bunch of different websites. I have a single key on my keyring, and I use it for Github, for my brokerage, for Gmail, for my work, etc.

And the reason I can do that is because my work cares that I use a FIPS compliant key, but nobody else does—because consumer RPs don’t do this.

Have you encountered any consumer RP enforcing attestation? Or is this concern of yours totally speculative?

I don’t know what this Bank of America card you refer to is, but presumably it was phishable auth, since it had an LCD key? Without a standard supported by user-agents, I don’t know how someone would enforce an out-of-band/unphishable auth mechanism like FIDO+Webauthn on their own, but I’m curious to hear you explain it!

> People love wireguard for its simplicity because it doesn’t use certs and PAKEs and whatnot.

I don't know of a VPN that uses PAKE, so I don't get this comparison, but whatever.

My point about certs was that OP was effectively proposing self-signed X509 client certs. It's unclear to me in what way those are harder to use than the proposal here, except that they actually are a widely accepted standard with user agent support.

> WebAuthn’s crowd and browser implementers on the other hand seem fixated on making sure users never have the option to deploy the protocol in such a way. That’s the problem.

https://github.com/herrjemand/awesome-webauthn#software-auth...?

It depends a lot on the situation. I think it’s reasonable, for example, for banks who have different liability standards depending on how transactions are authenticated to require batch attestation.

But like I said, most consumer IdPs aren’t doing attestation checks, and it’s discouraged, so I think you’re making a big deal of it. :)

Which part was knee jerk? I read everything on the (minimal) webpage. It doesn’t explain anything of substance, nor does it anticipate the (obvious) issues other commenters here noted. It’s like the author just proposed to remove everything they didn’t understand from Webauthn and was left with this.

Honestly, this discussion isn’t worth the time.

As for software webauthn keys:

- What do you mean “locked up in browser land?” You can use FIDO elsewhere (e.g. ssh https://ubuntu.com/blog/enhanced-ssh-and-fido-authentication...).

- Softkeys are available—in fact, iOS, Android, MacOS, and Windows 11 all do webauthn by default, without the need for a hardware token.

But then what's it actually demonstrating? That public key cryptography can be used to...validate that someone has a private key?

I feel like I knew that already. ;)

I think if I'm being generous, the proposal is to eventually have a credential management ecosystem (with cross-device key syncing, and keys per origin) similar to WebAuthn.

However, if you do this, you rapidly start to discover some of the reasons behind WebAuthn's design choices. For example, to prevent phishing/replay/linkage, the "authenticator" (the thing managing the keys) has to know the origin/RP. And to allow hardware and software authenticators, you need some protocol like CTAP to abstract that out. And because some RPs want to require hardware-backed or biometric authenticators, you need an authenticator type. Etc, etc, etc.

If WebAuthn is hard to use, it's because we haven't build the right libraries and abstractions yet, and that indeed sucks. (Though I think we mostly have, and it's not that hard to use.)

But the criticism here of complexity--contrasted with the simplicity of a trivially broken, horribly unusable "proof of concept"--is a bit like someone who says "I can make a working demo of a car without power steering, antilock breaks, an entertainment unit, an ECU, a catalytic converter, or headlights--just four wheels and a two-stroke engine! Clearly all that complexity isn't needed!"