Thanks for your input here, John. It’s great having people like yourself challenge our design approach so we can all think through these factors as thoroughly as possible.
Your tweet was brought up in our Discord community as well in case you’d like to jump in there and discuss it with us via chat.
First thing I’d say is that I regret not mentioning in this forum post that we are preparing a MetaMask-like browser extension for release when Blockstack Connect leaves its “beta” period, and that extension will generally match this webpage-based UX while making it even clearer (per your point) that seeds / private keys (what we call “Secret Keys”) are handled client-side only.
We actually began all of this work to replace the current Blockstack Browser with a code rewrite intended to prepare authentication for delivery as a web extension. So, the aim to provide a fully “self-sovereign” option (and one that’s even more usable than the current native download) has been close to our hearts from the start. And we don’t intend to go backwards here by removing the option.
I didn’t mention this in the original post above in part since the extension isn’t quite ready, and in part since we’ve tried to focus squarely on our most common user characteristics then build outwards from there.
Here are the characteristics we’ve have in mind, which I believe differ materially from the standard cryptocurrency trader (but which are debatable – so let’s certainly debate!):
- User does not hold significant amounts of cryptocurrency with their Blockstack credentials and is not taught to use them for managing, receiving or purchasing cryptocurrency (with Blockstack apps or any other place online).
- User encounters Blockstack while getting started with a (likely consumer) cloud app they’ve discovered independently and simply want to try out.
- User is very unlikely to install another app (extension, mobile or otherwise) upfront just to try that cloud app
- User has security needs that grow in proportion with both the data they create with Blockstack apps and the social capital they develop with their Blockstack identity, each of which takes place gradually over time / not instantly as with e.g. large single crypto purchases.
Two important things to note here:
These characteristics don’t necessarily describe us as community members or Blockstack PBC employees perfectly. We may very well have transferred some BTC and purchased an ID or two with our credentials, but the vast majority of Blockstack users have never done this (and never will – and that’s ok!). Also, we may likely have discovered Blockstack as an ecosystem first and apps second which means we have a very different propensity towards wanting to install a local authenticator upfront for managing our self-sovereign identities vs. simply using a Blockstack app or two that meet specific needs while keeping us safer.
These characteristics are prone to shift as we work towards Stacks 2.0 and smart contracts, upon which Blockstack users may very well start managing significant amounts of crypto / STX so they can sign transactions. As such, we should be mindful about how our design needs may evolve on this front – while staying clear-eyed about who our current users actually are. The UX team at PBC is actively researching the needs posed by Stacks 2.0 and is certainly interested in navigating them with the community.
If you take the characteristics above to be accurate, then I believe our current user needs and tradeoffs are markedly different than what you’d find with services like MyCrypto.
Perhaps most importantly, neither Blockstack as a whole nor any single app represents a significant “honeypot” for scammers or phishers interested in crypto. Any potential abuser would be woefully disappointed if they tried to collect remnant BTC transferred by power users to purchase IDs (finding no BTC – and certainly no STX – for the vast majority of Blockstack users who are satisfied with their sponsored / free IDs).
This is the main reason I believe the MyCrypto comparison is apples-to-oranges. A phisher could mount an attack by cloning a Blockstack app, replacing its authentication flow with a fake UI that harvests Secret Keys, and somehow contacting and convincing that app’s user base to sign in at the wrong domain. But the rewards would be paltry, and it’s not even clear to me that susceptible users would notice the difference between a fake popup and a real extension-based auth flow a la MetaMask (had they been required to install one from the start). Consequently, any attempt to prevent this attack by taking Secret Key entry out of a hosted popup and requiring an authenticator install may be likely ineffective (though I’d love to see more data on this topic should anyone here know of quantified studies about phishing as related to extensions).
Also per the above characteristics, new Blockstack users have a very different mindset and risk asessment when onboarding than the average crypto purchaser, and consequently require a more gradual security enhancement scheme. Put simply, they start with very little to lose – and require much more convincing – when starting to invest their time and attention (not money), which over time will hopefully result in a valuable data set and identity they’ll want to secure further with greater measures.
We saw through various design tests that new Blockstack users do not want to install anything separate when their main concern is trying a specific app. They barely recognize that Blockstack is a separate thing, let alone want to deal with it any more than the bare minimum before getting a chance to use an app and realize it gives them value. Test subjects literally retreat from the onboarding flow when presented with the option to install a local authenticator because the work is simply not worth it – nor contextually appropriate – to them yet.
This is a critical difference with MyCrypto (and many other cryptocurrency-first user experiences) wherein users are onboarding for MyCrypto and for a very specific use case (to buy and trade crypto) that’s known and valued clearly before onboarding. With MyCrypto, users can be bothered to install something during onboarding since they’re there for that one service and can quickly grok the security-to-value pairing of their upcoming crypto purchase or transfer. With Blockstack, users generally can’t be bothered since they’re here for BlockSurvey, Xor Drive, Nomie, etc. and know they don’t and won’t have anything at stake until they spend significant amounts of time using those apps first. While they may very well love the chance to protect their app experience further, it’s an option they need to see further down the road and no sooner.
All this said, our design approach is ultimately in the hands of Blockstack app developers since PBC is here to serve their needs. Our research here is merely an attempt to anticipate their users’ needs broadly. If we find that developers prefer to build their apps in a way that requires new users to install an extension or similar before onboarding, we can provide that as a configuration option for integrating Blockstack Connect. We’ve already discussed internally how this may be an important feature to provide in the SDKs if we expect financial applications to get built with Stacks 2.0. As such, I don’t mean to suggest any of the above is a “case closed” perspective of ours.
Thanks for reading my long-winded reply. And thanks again, John, for your input! I’m looking forward to more.