2,063 karma · joined June 28, 2016
Unclear to me why you think the user--and not the IdP--should have the final say here.
> You shouldn't. That's like expecting to be able to use your work laptop for personal stuff.
Except FIDO identities are unlinkable even if using the same hardware.
In my experience, the vast majority of (consumer) RPs do not require specific batch attestation, which is why you can make your own FIDO key: https://github.com/google/OpenSK.
I am under the impression support for attestation was controversial in FIDO--it's clearly useful for enterprise scenarios (e.g. where an enterprise requires some silly certification like FIPS: https://support.yubico.com/hc/en-us/articles/360016614760-Ac...), but there's always the risk that consumer-facing RPs require it for no good reason.
My employer requires FIPS certification due to FedRAMP; I'd be interested in how you would propose to change FIDO such that--as now--I can use a single key for work and for all my consumer needs while eliminating attestation. (One obvious option is for my employer to issue already-enrolled keys and disallow self-enrollment, but that has other headaches...)
> Because it was in reply to my earlier comment saying this is not SSO.
The person you were replying to was also not talking about SSO, which makes me think you don't understand that (valid, and fundamental) criticism of your proposal. :-/
> Webauthn is too complex.
Which functionality would you remove, and what tradeoffs does that get you?
> Passwords are bad. Hashes are dumped from databases and cracked.
Surely it's easier for an IdP to use scrypt with some meaningful salt than to implement this fully novel and unsupported scheme.
> Passwords are stuffed, etc.
These seem like problems that affect password reuse. According to your design, users should just know better than to reuse keys, so...why not just know better than to reuse passwords?
> There is no CA signing TLS certs, etc.
So why not use self-signed X509 client certs instead? This is actually a thing browsers actually support.
> The web service and its users are in full control of the process and they are using open-source software.
This is a category error. We were discussing a protocol. If you think your specific implementation of that protocol is better than all the open source implementations of FIDO+WebAuthn, X509 client certs, PAKE, etc...well, you're probably wrong. :)
> One goal I have is user anonymity.
You have not explained how your system is more anonymous than the existing, well-defined, standards-compliant alternatives.
Edit: Just to be clear about the tone of my feedback: my intention is to help you understand the context in which you are making your proposal and, ideally, understand the design tradeoffs existing systems have made. I know it's easy to become attached to an idea and take criticism like a personal attack. I hope you can take this constructively.
Anyway, unclear to me how this is better than x509 client certs, except that the author probably doesn't know about them.
My comment has nothing to do with federation or SSO, so I'm not sure why you mentioned those?
Ideally, we make WebAuthn easier to use (via libraries, identity providers, etc), rather than, you know, replacing it with something less secure than passwords.
Just sayin’. ;)
What’s broken here is not that user agents are or aren’t validating the origin (or relying party)—it’s that the same key+challenge is used for every origin. (As a result, there’s nothing for the user agent to validate, because the same signature is used for all origins!)
It’s like using the same password for every website you log into. As severe understatement, this is a very, very bad protocol design, and nobody should use it.
The employee is likely to underperform for the first few comp cycles after being hired, due to the new role, new context, etc. So the employer is willing to guarantee an "optimistic" salary up front for the first year (or, with equity vests, perhaps longer).
But the employer is unwilling to guarantee this indefinitely; after a year or two, they want to see you performing at level--and thus qualifying for merit increases--or else you'll revert to the lower salary.
Viewed this way, a rational employer will offer you a lower total comp for the first year if it's all salary; taking more of your first year's comp as bonus represents a bet on your own impact (and the fairness of the merit-based comp modeling).
I'm shocked it's that high, but, honestly, for an early effort, that's pretty competitive. If I'm reading Microsoft's 2005 annual report right, Home & Entertainment revenue was $3bn in 2005.
I still don't think VR is going to supplant console gaming, but console gaming is a big business--Xbox-level revenue would be a 15% increase in total revenue for Meta.
I also don't think Zuck's stated aspirations are a +15% boost in revenue by becoming a successful competitor in the gaming market, which is why it's so easy to criticize the insanely overstated goals of the "metaverse."
This seems far-fetched to me.
Mojo (https://spectrum.ieee.org/ar-in-a-contact-lens-its-the-real-...) claims to be on track for this, but:
- their "working demo" is apparently not actually wearable
- it has no built-in battery -- if I have to wear an inductive charger around my eye, I may as well wear smart glasses, right?
- the whole thing has a bit of a Theranos feel about it
I'm skeptical.
Sure, but plenty of tech companies have never paid dividends and never will. FB's shareholders would have legal claim to a portion of: a) a buyout (but nobody could afford to take FB private), b) a liquidation (so, you're buying in in case FB goes bankrupt), or c) future dividends (but FB's boy-king privileged stockholder doesn't want to pay dividends)...
Which I think was Ben's point.
a. Replies don't know if I'm being sarcastic or not.
b. I don't know if people who upvoted this comment thought I was being sarcastic or not.
Actually, what am I saying. Of course it's the only kind of reward most of us imagine.
Suckers.
Why would it be different for, say, Sendmail? I mean, I agree, but isn’t this the heart of why “open source” is not a meaningful differentiator? (Taviso wrote something similar about reproducible builds and “bugdoors” here a while ago: https://blog.cmpxchg8b.com/2020/07/you-dont-need-reproducibl....)
My claim is not at all that it would be noticed immediately. My claim is that distributing source code doesn’t help for exactly the same reason.
> which might explain why you keep mis-characterizing my position. Please RTFA and then opine. The section on threshold signed auditable builds isn't even long or complicated, it's a few paragraphs at most.
It’s never stopped me before. ;)
More seriously: I don’t disagree with the proposal, but it strikes me as less radical than you suggest, for a few reasons:
- It seems to me you can already do this with signed git commits plus—what we talked about before—reproducible builds.
- You still have to incentivize review. For a significant project, yeah, you might get it (and it’s cheaper than the dev time to maintain multiple overlapping projects, I guess). But are you going to get it for every, I dunno, NPM package to make text a pretty color which turns out to be critical infrastructure? Nah.
- As Tavis points out in the above link, source code is not at all a panacea.
So, yes, if people want to do multiple-auditor-signed updates, I’m all for it. App stores should make it easier than they do today. Agreed?
> CT…
I guess I no longer understand what we’re disagreeing about. To be clear, I’m all in favor of enabling multiple auditors to sign binaries, I guess. I don’t think it solves major problems in most cases, nor do I think source code access is a panacea for supply chain attacks. But if people want to do it, sure, I guess?
> …there’s only one client…It’s encryption that lasts as long as the owner thinks it should last…
I think this is a big leap. It’s a open source client with verifiable builds. If a future version removes encryption, users will migrate to Wire, or Threema, or Matrix, or whatever. How does there being only one client make the encryption non-resistant to an adversary?
It’s genuinely unclear to me what you consider the difference between:
- Multiple open source clients, distributed as source or prebuilt binaries, possibly signed and verifiable, possibly downloaded over TLS, depending on what Linux distro you use. <— This is the state of the art for most open source software.
- A single open source client, developed in the open and distributed with verifiable builds where feasible via broadly reliable and unlikely-to-collude third-party distribution mechanisms (the app stores). <- This is how Signal works.
- A single open source client, developed in the open and distributed with verifiable builds everywhere. <— This would be nice, if the app stores would support it!
> The point of defining an adversary is…not just noticing if they do
Well, no, I disagree. As a prominent example, Certificate Transparency.
“Noticing”—aka accountability—is extremely useful. As I noted above, there is a multitude of free, secure Signal competitors. The only thing that keeps millions of users using Signal is trust based on accountability. Building better accountability mechanisms means that if Signal violates that trust, users can switch, before they discuss hiring hitmen/buying meth/overthrowing the government on an unencrypted channel.
> …threshold signatures…
TBH, I didn’t read this part of your post that closely. There is a lot of work being done on binary transparency, and your proposal seems broadly in the same direction, but I’m not following this space very closely.
What I don’t follow is why you think it requires multiple clients.
> …you can just switch to a better implementation…
Aha. And here’s your point—not that a single client thwarts encryption, but that a single client for a sufficiently sticky centralized service would reduce the ability of users (who may not care that much) to switch away, should the encryption be disabled.
And sure, I think this is true to a degree. But as Aol/Google Talk/WhatsApp-post-ToS-change can tell you, messaging is not that sticky!
Anyway, ultimately the market has spoken. Ping me when everyone is using XMPP/Matrix/whatever. In the meantime, I hope the Signal Foundation keep building usable secure products for people like me. When they sell out, I’ll switch to Threema.
Who proposed binary transparency for Gmail (the server)? The whole premise of tools like Signal is that enough happens in the client--which is amenable to binary transparency--that the server is immaterial.
Sure, if you attack that strawman sufficiently, the only alternative is running your own Sendmail. And yes, it could suck less.
My point was a bit bolder than that, though: not only does binary transparency (which, to be clear, is about client code, not the server itself) substantially mitigate the concerns you might have trusting a centralized service, but running a computing stack of millions of lines of code yourself does not at all mitigate those concerns.
Sendmail isn't "yours", even if it's open source. It's a bunch of random patches from random people, some of which will erroneously "fix" a Valgrind error and remove cryptographic entropy from the RNG, others of which will contain intentional backdoors, etc, etc. The fact that you're running it yourself in your closet just doesn't matter. Physical locality--and hardware ownership--don't make a difference.
If that were true--in the case of WhatsApp, I'm pretty sure it's not, as another poster here pointed out--it would be equally true for any open source app. Like, I dunno, Debian (https://jblevins.org/log/ssh-vulnkey).
There's absolutely a place for reproducible builds and binary transparency in the ecosystem. But those seem to me to be examples of what Moxie described: using cryptography to provide privacy and security guarantees while building on top of centralized infrastructure.
Would you rather binary transparency, or would you rather run Sendmail on your Debian server in your closet because, hey, it's physically yours? The conclusion that the latter is better is just nonsensical.
(And of course, Bitcoin Wallet is in the Play store, distributed in exactly the same way as Signal...)
- Most users of Bitcoin Wallet download it from the Play Store
- Even if it's open source (as is the Signal client), "nobody's" reading through it and compiling their own builds
This sort of sweeping argument--that e2ee doesn't work because most users don't read source code--applies to everything, and as such isn't at all illuminating.
“Our incredible supply chains and manufacturing automation have lowered most consumer prices such that we don't really notice inflation…”
What’s your definition of “inflation”? It sounds like it’s something other than purchasing power, which is surprising to me.
“The US gets away with it because of its military”
So do countries with smaller militaries have…less inflation? More? More or less monetary growth? It’d be interesting to see if the data bear out your hypothesis.
I’m not at all an expert, but I’ve been wondering if a world where we all regularly use Bitcoin, but only via large, centralized L2 networks, would be one which feels exactly like the world of today, except (say) Visa or Stripe use Bitcoin instead of…fedwire? I dunno?…for clearance. And as a user, would that actually benefit me?
The reason for OpenSea et al. providing centralized services isn't accidental--it's not that it's "early days"--but that whenever there's an opportunity to innovate, those innovations will first appear for centralized services.
If we hope for distributed solutions to be on par with centralized, we are in effect hoping for an inefficient market, or one without innovation (giving distributed services time to catch up).
This criticism, in a way, has little to do with "Web3" at all. Instead, it's justification for the alternative solution Moxie has been working toward: one where crypto(graphy, not currency) allows the cost and feature advantages of centralization while preserving (or in fact exceeding) the user privacy of distributed solutions.
(I have some criticisms of Moxie's vision, but the author seems not to engage with the argument's real substance.)
China has a central bank, but it's fully publicly owned and is not politically independent of the CCP. The ECB, in comparison, is owned by the central banks of constituent banks. And on the other extreme, the Swiss National Bank is publicly traded and a minority of its shares are privately held (i.e., not by governments). (Perhaps related or perhaps not, the Swiss Franc also has historically had very high trust and very low inflation.)
My point is, there are multiple flavors of "central bank" ownership and independence; it seems odd to argue that the primary purpose of central banking is to allow private bankers to violate political oversight when, in some cases, the bank is fully public and not politically independent. Conversely, some examples of significantly more private central banks than the Fed seem to show a history of good management in the public interest.