Notes for Browser Security Call 19 Oct

[bumblefudge]

CASA Agenda 19 Oct - Browser Sec call

PRs to refine/move to close

• n/a

Ongoing projects/topics

• Brief Discussion for context: History of recently deprecated MM Enc/Dec API based on EIP-1098 (further receipts: [EIP magicians thread] | github PR history | 2019 rust crate | gitcoin grant )
• Brief discussion as possible input doc/starting point for a CAIP: the new EIP hoping to supercede 1098, 5630 (further receipts: EIP magicians thread | github PR history )
  • @bumblefudge highly recommends everyone read @kdenhartog and Authors' exchange in the Magicians thread
  • Old MM API Deprecated recently;
  • Firn approach: dapps encrypt msgs to wallet; wallet can't encrypt back; API redesign needed to make it more useful anyways to other use cases
    • @kdenhartog: Personally leaning towards wallet_store approach: i.e., bidirectional encryption per wallet (how namespaced tho?)
    • @kdenhartog: Optimize for [outsourceable] wallet storage [backend], not for onchain use-cases (which will be tempting to people in current form)
    • @oed: This CAIP seems to bias pro-Fat wallet, anti- thin wallet? @kdenhartog: Yessir, long-term yes, but supports both now
    • @oed: Coming from GUM community (sp?), I'm inclined the other way actually...
    • @oed: Wallet adoption is always uphill; MM may be exceptional because they can outsource new features to snaps, hardware wallets have historically been resistant to storage functions of any kind...
    • @kdenhartog: Dapps have a hard time knowing about a wallet what their storage capabilities are... This feels like the early days of JS APIs in Browser development; why not agree to web3 platform one API at a time?
    • @oed: CAIP-25 helps with that dapp<>wallet mutual feature discovery, for the dapps and wallets that opt into it...
    • @kdenhartog: but that comes after provider injection; the security of provider injection is the issue here... very uneven field there
      • @kdenhartog less than 24 hours ago, I opened CAIP#154 for this very purposes
  • @kdenhartog: table setting on how to proceed - CAIP#154, CAIP#25, and CAIP#XXX for enc/dec supporting the firn and/or MM approach(es)
    • @kdenhartog: who's building dapps and who's building wallets
      • Jeff: Fission team is working on an IPFS tooling stack, including WalletAuth (which was architected around enc/dec, prototyped with MM); encrypted file system on top of IPFS governed by a wallet; web2/3 bridge qua dev exp;
        • @depatchedmode: This is tooling for dapp devs; we're already demoing it and gathering feedback already so we have some sense of what dapp devs want! Can +1 that we decide some archit. goals up front so we know where our products fit and what to talk to devs about as we go; partic. deep in filecoin ecosystem and hoping to get more communities onboarded to this pattern of development along the way
      • @kdenhartog: Brave is all in on multichain (already have eth, sol, filecoin support); tendermint/cosmos would be a good community to bring into this convo
      • @skgbafa (Spruce): enc/dec for dapps, supported across wallets and chains
    • @oed: but is this a msging standard or just string transform? msg-layer security? TLS alternative? it's hard to know what we're supporting unless we know what the scope is; usecases and goals/intended architecture helpful to define first, before further discussion
      • @oed: what do you mean by messaging protocol?
      • @kdenhartog: Doesn't TLS encrypt a channel, and this encrypts messages?
      • @oed: This is about dapp permissions and authZ
      • @oed: This could already be done with SIWE/ReCap - unless you're proposing wallet handling/storing keys per dapp?
        • @kdenhartog: but wallet returns symmetric key, or wallet returns dec resource?
        • @oed: the more complex solutions ONLY work if wallets willing to get fat and support all the things...
        • @kdenhartog: sure, but which architecture to build first
        • @kdenhartog: Historically, browser design moves slow because web devs outnumber engineers 100:1...
        • @oed: AuthZ in thin-wallet model: maybe the dapp resolves and handles the resource, only asking the wallet to enc/dec?
      • @kdenhartog: see also this discussion predating the firn EIP on the ethers.js repo
    • inbox queue style architecture?
    • timelines and goals
      • short term: enc/dec adopted better (expand what little foundation we have now)
      • longer term: stabler foundation
      • @kdenhartog: have people talked to wallets about supporting enc/dec?
        • @depatchedmode: Well, boris has been on github?
        • @kdenhartog: Can't find it, i'll send it to juan
        • @depatchedmode: I definitely tell every wallet I talk to to support this; will get easier when we have more stable URLs and github commentary to point people to async...
    • CAIP scope and scale? fat/thin CAIPs?
      • @kdenhartog: Think about the EIPs and what little traction the average wallet EIP has... like browser APIs, there is no upgrade path or sunset, it persists forever
      • @kdenhartog: How many foundational APIs have been designed since last winter?
  • is the "version string" enough of an extension mechanism to work on other VMs with radically different key/curve options available, much less different use-cases requiring different discovery, privacy, and/or rotation models?
• SESSIONS and handshakes (CAIP-25 discussion, browser security edition)
  • MM's proposal to make sessions more explicit in CAIP 25
    • but should sessions be declared/authorized as part of call/response or otherwise? awkward separation of concerns given the authZ and session management implied by CACAO/SIWX flow... what's the upgrade path there?
    • need a separate CAIP for expressing these as a data model if anything other than default?
    • who sets default, dapp, wallet, browser, etc?
  • CAIP-154 - Provider foundation, pre-CAIP-25
    • but that's very browser-centric? isn't dapp landscape increasingly mobile-focused to avoid this security issue?
  • need help with corner-cases about cross-dapp and mobile corner cases
    • Jeff f/Fission: browser landscape standardized by browser sec; extensions are only endrun that every env uses
    • @kdenhartog: Secure context as baseline for serious/consented/responsible dev... but that's non-binding
• Domain-binding issues around SIWE/SIWX (as time allows)
  • not address 😞
• wallet namespace idea (as time allows)
  • not really addressed... putting at top of next agenda

Next Steps

• Are we ready for a CAIP about enc/dec?
  • GH discussion habemus PR!
  • @kdenhartog will add USE CASES to the PR clarifying
• People in lisbon - report back on the hearts and minds of the wallets and dapps! Would people support this! Seems easier to start with dapps that only support X wallets by name/explicit allowlist...

[bumblefudge]

@kdenhartog any news on those USE CASES ? 😉

[kdenhartog]

I dropped the ball on that one, but can hopefully get back to it next week.

[kdenhartog]

it's been long enough that I don't remember which PR these use cases were supposed to get added to.

The primary one that I can see would be useful here:

1. wallet -> DApp encrypt so that a user can send a secure message to a DApp's backend service (this would require DApps to have public keys which could be a good usecase for did:web)

2. DApp -> wallet -> DApp messaging so that offchain data can be shared via the wallet (with better consent models) and stored by the user rather than requiring backend storage by the DApps (and backend integrations via partnerships to enable communication between different DApps)