📱 Revise `Daily spending wallet` -> `Security` page

[Bosch-0]

The current Security page in Daily spending wallet is more of a general overview of wallet security and isn't specific to a daily spending wallet. We should make the content of the page specific to daily spending wallets and add some UI designs illustrating the concepts.

Some of the more general content may be more suited for a Security page in the How it works section which covers the technology / general considerations outside of specific contexts like a daily spending wallet. Though this is an issue for another time.

Page: https://bitcoin.design/guide/daily-spending-wallet/security/

[Bosch-0]

Add content around hiding home screen balances: https://github.com/BitcoinDesign/Guide/issues/578

[Bosch-0]

For these revision pages the images should also be generally updated:

• Ensure they reflect what is shown in the UI kit
• Apply new modal formatting to images
• Remove grey area on the iPhone 'dip' at the top of the phone (see below).

[GBKS]

I would not remove the grey area. I remember trying this a while back and it not looking good. IIRC, it had something to do with CSS shadows working best with rounded rectangles and it looking goofy on this more complex shape.

Second thing is that it's a mess to deal with in Figma because you need to set up a mask for every screen, which is problematic with fixed-position elements like the top bar and the home indicator bar. Requires you to wrap the whole screen design in another frame, just for the mask.

[GBKS]

The whole part about "Hiding sensitive information" should be moved to the Wallet privacy page.

Information about watchtowers will be added to this page in #798.

The security checklist paragraph can be made more specific to lightning (watchtowers, rename key backup to backup as it will also include channel data). We can move the privacy checklist screen to the privacy page.

[Bosch-0]

My review of this page

• Proactive support is mentioned at the start, I like this idea, but it isn't really instilled throughout the section. We could give more examples where this should be practiced.
• Should give an overview of a security section of the wallet at the top (show a frame with all the options listed).

Security & privacy checklists section

• Remove 2-2 multi-key tick box in security & privacy checklists frame (not part of a DSW)
• Same frame mentions 'Key backup,' 'Recovery phrase backup' would be better
• Remove the privacy frame (move to privacy page)
• Clean up the Automatic Cloud Backup frame (lots of text), also not sure how this frame fits into the checklist?

Reminders & recommendations section

• Add some details here about periodic reminders of the importance of the users recovery phrase backup (I like the space repetition way to do this).

Preventing unwanted access section

• Personal take, but biometrics aren't good for bitcoin apps. If I'm incapacitated something could hold my phone to my face or use my finger to access my wallet and steal my funds. It's great UX but the security trade-off isn't worth it imo. Bitcoin wallet apps should have much higher security standards than general use apps.
• Mention how PIN should be required to view recovery phrase
• Add info around a wipe mode that wipes the wallet from the users phone after X amount of failed PIN attempts (maybe 10?). User will need to use their recovery phrase to restore their wallet after this.
  • A duress PIN could also be used that does this wipe when the duress PIN is entered.
• Mention the ability to make a scrambled PIN (preferably toggle able in the settings).
• Mention other lock screen methods - PIN is a good default but users should have the option to also use pattern, swipe, and password methods of encryption
• Would be cool if dummy wallets, when setup, got auto-funded with some testnet coins so users can get the advantage of this without staking real corn.

Blocking critical activity section section

• Mention Blixt as an example of a DSW that lets you delete a recovery phrase
• PIN should have to be entered to delete the recovery phrase.

Hiding Sensitive Information section

• Refer to private keys as recovery phrase for simplicity
• This section seems very long for, to me anyways, is a simple concept - could reduce it.
• The frame in 'An application-wide setting' should have the hide sensitive data toggle on
• Add tap and hold to the quickly hiding balance section - much better way to do this imo.

Content to add

• Info around backing up wallets meta data in the cloud
• Info around backing up channel states (LSP option, automatic cloud, manual)
• Watchtowers (PR open)
• Ensuring the home screen shows no sensitive info (issue)
• Info on LSP zero-conf channels. LSPs should use this, users should be able to disable it though as the LSP could reverse the transaction on the user.
• We should start the page off with the more simple security practices then move on to more advanced things (maybe make a clear break in the page where this transition happens).

Anything else? I imagine more LSP stuff may be necessary but this is my thoughts for now.

[GBKS]

Phew, that's a long list. Nice and thorough.

• For "Clean up the Automatic Cloud Backup frame" - you see this the you tap "Learn more", so a larger amount of text is appropriate
• I think biometrics are just fine for the daily spending wallet that is not supposed to hold large amounts of funds. Not sure how often you are incapacitated, but that doesn't seem like a broad concern. A simple option to address this would be to require PIN entry when sweeping all funds (or sending funds over a certain amount). Overall, I think we should try to think about what's appropriate for this particular reference design, and can list more hardcore options at the bottom
• For all the things that require PIN entry, we can just list them as considerations in the PIN protection section
• I just created a PR to move "Hiding sensitive info" to the privacy page, we can tackle the copy edits in #758
• In regards to meta data backup, channel states and LSP details, we might be adding duplicate content here that's already covered in other pages. Might be able to just link out.

A distinction to consider would be security stuff related to the particular technical specs of the product vs user action.

[sbddesign]

Info around backing up channel states (LSP option, automatic cloud, manual)

@Bosch-0 better suited for the backup section, perhaps? Sounds like overlapping content.

Not sure how often you are incapacitated, but that doesn't seem like a broad concern.

@GBKS I think that "how often are you incapacitated?" is the wrong question to ask. The correct question to ask is "if you are incapacitated, what damage is an attacker capable of?" In fancier words, the risk calculation has more than one variable. It's not just "probability of X occurring", it's also "value of damage inflicted if X happened to occur". Both of these variables must be weighed for one to make a risk assessment.

that doesn't seem like a broad concern

Correct, it's not a broad concern for most people. Maybe that's the problem we're trying to solve for.

However, I agree that perhaps the biometric convenience may be a reasonable trade-off for a certain amount of funds. If that's the case, maybe we should talk about that? Let's talk about putting spend limits for biometrics in this section of the Guide.

[GBKS]

I'd just consider that the app operates in in the context of smartphone security. An attacker still has to be able to unlock the phone in the first place, which the user can make as hard as they want. Also, Face ID on iOS does check for attention, meaning a users eyes have to be open and looking at the screen. There seems to be support on at least some Android devices.

[Bosch-0]

@Bosch-0 better suited for the backup section

Yeah would be better there

I think biometrics are just fine for the daily spending wallet that is not supposed to hold large amounts of funds.

It's too hard to define what is and isn't a large piece of value to someone.

Biometric data is not as secure or private like a PIN or password is, they should not be safeguarding a bearer asset like bitcoin. It goes against our privacy principle imo. https://www.ipswitch.com/blog/3-reasons-biometrics-are-not-secure

Biometrics also mean dummy accounts are not possible - you can't have two faces! You need to be using a PIN / password / pattern for this.

I'd just consider that the app operates in in the context of smartphone security.

Bitcoin storage warrants higher security than a smartphone.

[moneyball]

I agree with the comments that using biometric for a spending wallet/small amounts is perfectly fine. Reasonable defaults can be made and certain UIs will allow users to adjust the threshold.

Also the Block wallet will have a biometric fingerprint sensor on the hardware device which is intended for storing savings. A thief would need to obtain a person's phone, break into the location storing their hardware wallet, and compromise the authentication of both devices.

While biometric sensors have risks they have benefits too. They improve availability in case a user forgets their PIN (and thus losing their funds). This is probably far more likely than a physical theft.

IMO the design guide should not be as extreme as recommending to never use biometrics but instead describe the tradeoffs.