zlacker

>>EthanH+(OP)
This is pretty incredible. These aren't just good practices, they're the fairly bleeding edge best practices.

1. No more SMS and TOTP. FIDO2 tokens only.

2. No more unencrypted network traffic - including DNS, which is such a recent development and they're mandating it. Incredible.

3. Context aware authorization. So not just "can this user access this?" but attestation about device state! That's extremely cutting edge - almost no one does that today.

My hope is that this makes things more accessible. We do all of this today at my company, except where we can't - for example, a lot of our vendors don't offer FIDO2 2FA or webauthn, so we're stuck with TOTP.

>>static+ua
I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaningfully access networked services, all those who compile their own artifacts (even from completely identical source code) will be excluded from accessing that remote side/service.

Banks and media corporations are doing it today by requiring a vendor-sanctioned Android build/firmware image, attested and allowlisted by Google's SafetyNet (https://developers.google.com/android/reference/com/google/a...), and it will only get worse from here.

Remote attestation really is killing practical software freedom.

>>c0l0+IH
Let's note that this very concerning problem is only one if organizations take an allowlist approach to this "context aware authorization" requirement.

Detecting changes — and enforcing escalation in that case — can be enough, e.g. "You always uses Safari on macOS to connect to this restricted service, but now you are using Edge on Windows? Weird. Let's send an email to a relevant person / ask for a MFA confirmation or whatever."

>>Signez+rI
Somebody made the front page here a few days ago because they were locked out of Google with no recourse from precisely that kind of check.

>>hansvm+3v1
It wasn't I, but this has been an absolute plague on an organization I work with. There are only 3 people, and we all have need to access some accounts but they are personal accounts. Also, the boss travels a lot, often to international destinations. Every time he flies I can almost guarantee we'll face some new nightmare. The worst is "we noticed something is a tiny bit different with you but we won't tell you what it is. We've emailed you a code to the email account that you are also locked out of because something is a tiny bit different with you. Also we're putting a flag on your account so it raises holy hell the next 36 times you log in."

>>freedo+gH1
Three people sharing a personal account, with one of them frequently traveling internationally, is such an unusual usage pattern that I'd be really disappointed with a service provider if they _didn't_ flag it for extra verification.

>>sciuru+t02
This is the problem with this kind of thing. It just perfectly captures the privilege/shelter of the programmers who come up with these heuristics of “obviously unusual”.

You just described the usage pattern of a pilot with a family, a truck driver, a seaman, etc.

It’s only unusual if your definition of usual is “relatively rich, computer power user”.

>>kortil+bm2
Not really. What's the use case there, everyone sharing a Google account?

I travelled a lot for work, and never had issues with account access. Nor did my wife ever have issues related to accounts. We don't share Google accounts though. It sounds like that user has personal accounts being used by three people for business use... Which isn't "A seaman and his family".