You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a need to store keys in the browser in a secure way, avoiding plaintext options like localStorage.
Brave Wallet supports only Ethereum signing options. But there is more potential, eg: nostr-protocol/nips#1045
The Web Crypto API is very powerful for one reason: CryptoKey can prevent access of the key data by setting extractable: false. Actually two reasons: you can store it like that in IndexedDB!
This enables a flow were you can show a user their private key to copy down exactly once, and afterwards store their key in the browser so it can ONLY be used to sign. The result is almost as secure as a browser extension, except for the initial point of exposure.
It would enable the creation of much more secure in-browser wallets and sign-in mechanisms.
This has been raised to the W3C, which they closed because "Chrome doesn't want to support it": w3c/webcrypto#82
I see Brave's role in the ecosystem as partly to advance the internet, but also to correct the behavior of Chrome. And since work is already being done with secp256k1, it might make sense to do it.
The text was updated successfully, but these errors were encountered:
There is a need to store keys in the browser in a secure way, avoiding plaintext options like
localStorage
.Brave Wallet supports only Ethereum signing options. But there is more potential, eg: nostr-protocol/nips#1045
The Web Crypto API is very powerful for one reason:
CryptoKey
can prevent access of the key data by settingextractable: false
. Actually two reasons: you can store it like that in IndexedDB!This enables a flow were you can show a user their private key to copy down exactly once, and afterwards store their key in the browser so it can ONLY be used to sign. The result is almost as secure as a browser extension, except for the initial point of exposure.
It would enable the creation of much more secure in-browser wallets and sign-in mechanisms.
This has been raised to the W3C, which they closed because "Chrome doesn't want to support it": w3c/webcrypto#82
I see Brave's role in the ecosystem as partly to advance the internet, but also to correct the behavior of Chrome. And since work is already being done with secp256k1, it might make sense to do it.
The text was updated successfully, but these errors were encountered: