181–186 of 186 posts
Earlier quoted context omitted.
Sure, but major banks failing one after the other might not exactly promote confidence in ones bank deposits.
You're working really hard in this discussion. Why?
Is it not that way for you?
Earlier quoted context omitted.
Interesting! Does the WebAuthn API provide enough of a cryptographic basis to fulfill the needs of cryptocurrency wallets? I know it works through public/private key sharing but I wasn't aware that it provides such direct primitives.
It doesn't, at least not for generic/unmodified cryptographic applications. WebAuthN signatures are of a very specific challenge/response format [1] that applications need to explicitly support. For example, SSH had to add new key and signature formats [2] to support it. Theoretically, a blockchain/cryptocurrency application could adopt the WebAuthN signature format as its canonical or an alternative signature format…
Earlier quoted context omitted.
This makes no sense. What source should it be addressed? This is an issue of standard libraries, whereas WASM is a specification of an execution environment. WASM doesn't have a standard library, since it doesn't even have a canonical source language! It's like demanding that x86 or aarch64 offer better Unicode or SVG support.
Developers should never end up in a situation where they feel the best cryptography solution is to "roll their own". That's likely what happened here. And the situation needs to change. It doesn't matter where in the stack that change is affected.
What we can do is provide well-tested and ergonomic high-level cryptographic libraries; I don't see how we can enforce their use.
Earlier quoted context omitted.
Developers should never end up in a situation where they feel the best cryptography solution is to "roll their own". That's likely what happened here. And the situation needs to change. It doesn't matter where in the stack that change is affected.
So you're saying all languages (and in fact ISAs, because that really describes WASM more accurately!) need to come with a static analyzer that detects and prevents any attempts of implementing low-level cryptography rather than calling out to a high-quality library? Because that's what happened here. What we can do is provide well-tested and ergonomic high-level cryptographic libraries; I don't see how we can enforc…
Though admittedly, it seemed terrible if there wasn't, so I would be happy if the post can be proven deficient. I'd have ordinarily assumed many options available in the .js ecosystem, instead accepting it's a WASM OS-access issue.
Earlier quoted context omitted.
This is very interesting and I agree about all the upsides of desktop apps. However, in web3, people’s blockchain credentials could be used to interact with many different websites. This seems hard to reproduce with desktop-based apps, right?
Browser makers don't seem to really want people interacting with non-web stuff from the web, or extending web capabilities with desktop apps, as that reduces your dependence on them. Still, there are some ways to do it. Firstly, the much more common need is to log in to SSO services, not act as an auth provider. OAuth is kind of messy but can be done and Conveyor makes it easy to register URL handlers, there's a demo…