"The destination address - the address to which funds will be sent in a transaction - is generated by the recipient’s device and must transit many systems without manipulation: from the recipient’s wallet software, through the recipient’s device platform, across the internet, through the sender’s device platform, to the sender’s wallet software, and ultimately to the hardware wallet."
"How can a customer protect against manipulation of the destination address between their wallet (the sender) and the recipient’s wallet?"
"A common response is to compare the destination address shown on the sender device (e.g. a phone or desktop) to the one shown on the screen of a hardware wallet."
"In practice, this protection won’t shield a broad audience from threats like mobile malware or desktop malware. Why? If the sender’s internet-connected device is sufficiently compromised, then the destination address can be poisoned before it ever gets to the hardware wallet."
"With the ability to send data securely between hardware and server, we can potentially use the server to do something the hardware cannot: communicate detailed transaction information like destination address, fees, and amounts directly to users."
"One limitation of this approach is that it cannot be used if Bitkey servers are unreachable. In order to ensure that customers can always move money in that situation, the hardware would need to allow customers to unlock their hardware and use a specific gesture (e.g. long press) to bypass the protection, if they'd opted into it or if we had enabled it by default."
"Furthermore, this type of protection requires careful technical design and review, which we will engage in and publish if we take this approach and find that it can meet our bar for user experience."