qml/android: protect WIF keys from screenshots in more places
What the developer wrote
Authored by SomberNight
qml/android: protect WIF keys from screenshots in more places
also fix bug in AddressDetails where we were never unsetting the secure flag
notes re dialog stacking:
- if we stack two "secure" dialogs and then pop one of them, the remaining "secure" dialog should still have secureWindow == true.
- we could either impl some refcounting for the number of alive "secure" dialogs
- or perhaps simpler but less robust, qml binding magic using the "when" as done here might work?
- ref https://doc.qt.io/qt-6/qml-qtqml-binding.html#restoreMode-prop
- the default restoreMode (Binding.RestoreBindingOrValue) seems to do what we want here
- I don't explicitly set it as the Qt docs have this note:
> Note: This property exists for backwards compatibility with earlier versions of Qt. Don't use it in new code.
- seems to work on my phone
What changed, and why it matters
This commit tightens screen-shot protection for private Bitcoin wallet keys (WIF keys and seed phrases) in Electrum's Android/QML user interface. It also fixes a bug where one screen (AddressDetails) was leaving the 'secure window' flag permanently on, which could leave the app in a protected state at the wrong time. The change makes sure the secure flag follows whether the dialog is actually visible, and adds the same protection to two more dialogs that handle private keys.
Treat as a routine hardening fix. Users running the Android/QML build should update to a release containing this commit. No independent action is required beyond normal patching.
Security signals we found
Adds FLAG_SECURE-style screenshot protection to additional private-key dialogs
Fixes a bug where secureWindow was never unset in AddressDetails
Uses QML Binding 'when' with restoreMode semantics to handle stacked secure dialogs safely
Evidence from the diff
The patch adds QML Binding elements that set AppController.secureWindow to true only while the containing dialog/page is visible (using the ‘when: root.visible’ condition). This prevents Android screenshots/recents-screen thumbnails from capturing WIF keys in ImportAddressesKeysDialog and SweepDialog, and fixes stacking behavior so that popping one secure dialog does not accidentally disable protection while another secure dialog is still open. AddressDetails and WalletDetails had their existing bindings updated with the same visibility-gated logic, and the wizard page binding was updated similarly.
Changed components
electrum/gui/qml/components/AddressDetails.qmlelectrum/gui/qml/components/ImportAddressesKeysDialog.qmlelectrum/gui/qml/components/SweepDialog.qmlelectrum/gui/qml/components/WalletDetails.qmlelectrum/gui/qml/components/wizard/Wizard.qmlInspect captured patch +17 / −0
### electrum/gui/qml/components/AddressDetails.qml
@@ -351,6 +351,7 @@ Pane {
Binding {
target: AppController
property: 'secureWindow'
+ when: root.visible // enables stacking multiple secureWindow dialogs
value: Boolean(addressdetails.privkey)
}
}
### electrum/gui/qml/components/ImportAddressesKeysDialog.qml
@@ -123,4 +123,11 @@ ElDialog {
id: bitcoin
}
+ Binding {
+ target: AppController
+ property: 'secureWindow'
+ when: root.visible // enables stacking multiple secureWindow dialogs
+ value: true
+ }
+
}
### electrum/gui/qml/components/SweepDialog.qml
@@ -162,4 +162,11 @@ ElDialog {
Bitcoin {
id: bitcoin
}
+
+ Binding {
+ target: AppController
+ property: 'secureWindow'
+ when: root.visible // enables stacking multiple secureWindow dialogs
+ value: true
+ }
}
### electrum/gui/qml/components/WalletDetails.qml
@@ -677,6 +677,7 @@ Pane {
Binding {
target: AppController
property: 'secureWindow'
+ when: rootItem.visible // enables stacking multiple secureWindow dialogs
value: seedText.visible
}
### electrum/gui/qml/components/wizard/Wizard.qml
@@ -155,6 +155,7 @@ ElDialog {
Binding {
target: AppController
property: 'secureWindow'
+ when: pages.visible // enables stacking multiple secureWindow dialogs
value: pages.contentChildren[pages.currentIndex].securePage
}
}Why this scored 48/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.