> The ATECC608 is a fixed-function device for private key storage. [...] To be able to read the secrets (ie. wallet seed) out of the secure
element [...]
It's my experience that having had any crypto-adjacent accounts associated with my main email over the last decade has caused the single largest increase in email spam of anything I have ever done. I used to engage in the industry (in the mid to late 2010's when most trading was done through centralized exchanges) and it seems a few of the old platforms have leaked/lost/sold their email databases. I get ~2-3 emails daily now that I assume are all scams saying various things along the lines of "You have n free XYZ token waiting to be collected!" and "Ensure you update your ledger for the latest security patches! Here is a link to it! Please ignore that its not to an official ledger domain!"
A lot of the spam seems to be either proxied through insecure wordpress comment plugins or simply signing my email up for accounts on random websites and somehow injecting their phishing attempts into the account confirmation emails. They come from all sorts of domains, most of which having nothing to do with crytpo, and nearly all of the messages are embedded in some sort of broken HTML email body.
Although I no longer follow or have much interest in the industry, I am hesitant to outright blacklist crypto terms. Has anyone come up with a good solution to combating crypto email spam?
Beautiful, but tip for Ledger team: pics & video should include more common items for size reference.
Even placing alongside some-generic-iPhoneish-smartphone isn't a great help, as those now vary in size so much.
Here's a thought, given its use: show it alongside some of the world's most-recognized fiat monies, like the USD bill or quarter, or several EUR bills/coins.
I'm not sure I agree, I think the video's example of it's slightly smaller than a phone is more than enough. If I need more than that I can look at the specs which are also readily available further down the page.
Slightly smaller than which of the dozens of phones of varying sizes that look like that phone, which only appears for ~1 sec, 5/6ths of the way through a video many visitors won't play?
Numerical specs are a poor substitute for a visual-intuitive sense of something's size, versus common referents.
My suggestion is only if Ledger wants their product to be easily understandable to the largest possible audience of buyers. If they're only interested in the smaller subset of people for spend extra time digging, & can interpret numerical dimensions well (perhaps with the aid of rulers/etc), then being more obscure about its size makes sense.
Not sure I missed some leak, but if you're referring to what I think you're referring to, it was a marketing newsletter email list that got leaked/hacked, not the customer shipping database or who owns a wallet. I for one doesn't see my email listed in the leak, I'm not subscribed to the newsletter but I do own a Ledger ordered directly from their website.
Sure it looks slick, but I worry about making these kinds of devices more complicated than they need to be. Especially if it has a battery inside. More complexity = more points of failure.
One of the rules of thumb for long-term key storage (especially secure hardware storage) is parsimony: you don't want any unnecessary hardware or software (both because it makes the storage less resilient, and because it introduces additional security concerns).
Given that, I'm not sure I understand why you'd put an e-Ink display (much less a JPEG parser, presumably, given the NFT stuff) on what should really just be an HSM. That seems like asking for trouble.
Edit: Not to mention Bluetooth and wireless charging, apparently.
Sounds like you have never used hardware wallets, these are not just a yubikey with a button to push and a notification diode. Having a screen is essential to display information about the transactions you're going to sign . Recent blockchains and new bitcoin signing schemes tend to have big chunks of data that require screen estate to be validated by the signer, so the bigger the better.
The nano S and nano X screen were a pain to use with their super small screens, this improvement is welcomed.
About Bluetooth, well, that's simply a transport layer, like USB. Pretty convenient when you want to trigger a transaction from your phone. People don't necessarily use these devices with a cable and a laptop.
I don't see a use for wireless charging. Maybe you can charge your wallet by placing it over your phone ?
Bluetooth is a wireless technology, and including it necessitates an onboard power source, a battery. This changes the security model a lot, an attacker now only needs proximity to the device, not physical access.
No, the attacker still needs physical access to the device, because signing requires on-device approval.
The security model already assumes that the entity requesting authorization is untrusted, so the security model is basically unchanged. An attacker who can forge BT packets to submit bad data for approval is not really different from an attacker who compromises the laptop/phone/etc to submit bad data for approval.
> No, the attacker still needs physical access to the device, because signing requires on-device approval.
You're assuming that the Bluetooth implementation does not introduce vulnerabilities that thwart this assumption; GP & GGGP are suggesting that you shouldn't have to make this assumption in a hardware wallet (or hardware that requires this very high level of assurance), by not including it at all. The same goes for, say, an attacker who's able to swap your wireless charger for a malicious one, and potentially execute a power usage-based side channel if you access the device while it's charging, or who's able to extract some useful information from the RF noise produced by the monitor.
The counterargument to this, in my mind, would be that you plan to use these features of the wallet regularly, and that they provide sufficient benefit to justify the risk (which you may argue is quite modest), and perhaps that you've implemented additional mitigations against them (like never using it while it's charging). Your argument about a monitor adding additional assurance in a sibling thread was quite good I thought, and a tact I didn't anticipate in this list originally.
Yes, but for this reason, the Bluetooth implementation is on physically separate, untrusted hardware that has no access to the buttons or screen other than by communication with the secure element (see [0] for the Nano X; I’m assuming the Stax will be basically similar).
So this isn’t really different from having a USB cable: in either case, some untrusted messages arrive at the secure element over some wires, and get processed there. The only difference is that the wires come from another chip on-device rather than from an external cable.
I'd be surprised if that was the case. Nano X and S+ use the secure element for key operations as well as for user I/O (display and button control), which is significantly better than delegating that to a "main processor".
Given the complexity of driving a touchscreen and e-ink display, I think they might have had to return to that weaker "multi-chip" model (used in the original Nano and earlier and by many other hardware wallets), where the non-secure chip drives both the UI and I/O, rather than only latter.
Bluetooth is a huge attack surface. Most Bluetooth stacks are something like 100k lines of C, written by electrical engineers. It's a nest of bugs and vulnerabilities.
There's probably more code in the Bluetooth stack than the entire rest of the code on the device.
I think the presence of any connection and data transfer is more important than the physical layout of the hardware. Compare, for example, baseband exploits.
Baseband exploits are as devastating as they are because at least until a few years ago, they've had full SoC memory access and as a result more privileges than even the operating system running on the SoC.
Treating the baseband more like a peripheral device and less as a coprocessor can prevent against much of this attack surface.
That said, just adding Bluetooth (even given a perfectly isolated stack) opens several unnecessary attack vectors, including a MITM between the wallet and the device driving it. This could be used to e.g. subtly modify destination addresses or transfer amounts.
Right. I'm not saying it isn't a reasonable hardening choice, only that it isn't a proof of security. It's table stakes for something claiming to be secure hardware in 2022.
It might be, and it might not be. It's hard to say.
If your device can receive OTA updates via Bluetooth, no. If your device has a "developer" API, almost certainly no. If the two chips share a power rail, possibly not. Without serious thought to security of requests and responses (such that MITMs are impossible), no.
There are a lot of ways this can go wrong even with separate chips.
Yes, a compromised Bluetooth chip may be able to replay an old update or simply block a new one and leave you with a vulnerable version of your software.
TLDR: Google research exploits wifi firmware of broadcom chip in iphone, then uses that to exploit a driver bug, and manages to root the iphone. All without even connecting it to a specific AP, just from broadcast packets.
If your secure hardware doesn’t have a display, how do you know what you’re signing?
You can’t, so you’re forced to trust that the software talking to the HSM isn’t lying to you about what data it’s asking to be signed, and at that point you’re only marginally more secure than not using an HSM at all. (Sure, it’s harder to steal the long-term key material, but if I compromise your software, I get a signing oracle, and that might be good enough.)
This is actually something that the blockchain ecosystem gets right: every hardware wallet has a secure display of some kind, to avoid blind signing, because it’s a context where security actually matters (unlike, e.g., “signing git commits with a yubikey”, which nobody cares enough about to attack).
Not to mention, you already trust github if your code is there, and you can typically get that code back from the git history, so it's not usually a big risk to authenticate with a yubikey.
> unlike, e.g., “signing git commits with a yubikey”, which nobody cares enough about to attack
I'm not so sure about this one, there's plenty of damage you could do if you were a malicious actor who could send trusted commits to a git repo. Especially if said repo were for some important software (like Linux, wget, glibc, etc. I know they're not necessarily on public repos but we're assuming at least somewhat targeted attacks here).
> If your secure hardware doesn’t have a display, how do you know what you’re signing?
I might be missing what you mean, but with a normal security module I control the inputs and outputs: the device only signs what I tell it to sign, and I can test it for honesty by verifying that any signature(s) I get back are actually signatures over the inputs I put in. That still requires me to trust that my interface to the hardware is the only interface, but that's the point of the parsimony (no bluetooth to worry about!).
HSMs have plenty of problems (and I've encountered a good share of them from designing trust ceremonies), but I don't think adding a screen addresses any of them. If I was an attacker, the pins on an e-ink display would probably be much easier to tamper with than the secure hardware itself.
The only way to be sure that your HSM is about to sign what you told it to is if it shows you what was sent to it to sign. Otherwise you’re trusting that something didn’t MITM between your computer and the HSM (eg: driver) such that you see one thing but end up signing something else.
I don't think this is true: I can be certain that my HSM signed what I wanted it to sign by verifying the signature against my known input. I know what I asked it to sign, so this is trivial.
A screen doesn't eliminate the necessity of this check; it's a pure convenience. And that's not to say that it's a bad one, per se, just one that is in tension with the normal key management desiderata (as few moving pieces as possible, as little code as possible, etc.).
> I can be certain that my HSM signed what I wanted it to sign by verifying the signature against my known input.
But what if, after checking, you realize that instead of "send $50 to $friend for dinner", you signed "send my life savings to $fraudster"? That's the main attacker model of cryptocurrency wallets.
That's the kind of attacker model I wouldn't invite in the first place!
But more seriously: I've never fully understood why this is such a common issue with cryptocurrencies. My understanding of how Bitcoin works is that you need to actually submit your transaction for inclusion in a block, meaning that you have ample opportunity to verify the transaction's correctness before offering it for submission. Why aren't hardware wallets encouraging that?
How is the rest of the network supposed to tell the difference between you signing and submitting a transaction and you signing and then a malicious program on your machine submitting the transaction?
> with a normal security module I control the inputs and outputs
In the threat model that hardware wallets address, you don't, though. Your computer could be running malware that swaps your desired target address with that of the attacker, for example.
In that sense, they go beyond (low-level) HSMs by introducing a trusted user interface so that you can verify what you sign.
However, they arguably also fall short of really solving that problem: What are you going to compare the destination address to, if you can't trust your computer to correctly display it?
Turns out that I don't have a compelling use case for it even though I own some crypto.
If I wanted liquidity in my crypto (to transfer or buy stuff) then I would just store my keys in my password manager which I seem to trust with the rest of my assets (I get crypto transactions are non-reversible).
If I do not want liquidity then I really am better off writing/engraving my keys on something and into a safe.
A combination of these two make the most sense for me.
I mostly use it for two purposes. 3rd factor for using my phone for cryptocurrency transactions and for a second validation of that the address, amount and data is correct, on a second device that is (theoretically) impossible to compromise and show something else.
> I would just store my keys in my password manager
The trouble here is the transfer of assets from the manager into your apps. Lots of opportunity for thefts or screw up. Imagine you use the clipboard and some random app happens to be scanning it.
Valid. I've accepted much larger risk by storing all of my other sensitive information in my password manager though. What crypto needs is a form of 2FA - turns out I don't care enough to have another factor that's only useful for crypto.
The compelling use case is not having to store your private keys on your computer, even momentarily. Of course, if you don't deem that too risky, a hardware wallet will do nothing for you.
That being said, I believe storing private keys on a general computing device is very foolish and you will likely find out the hard way. I wouldn't store any more in a hot wallet than the amount of cash I'd be comfortable walking around with in my pocket.
I’m not really a crypto fan. But it’s a really neat device. A cool tech that has a creative use of e-ink. Something I wouldn’t mind keeping in my pocket.
The neat thing about crypto hardware wallets, is that they're essentially just private key storage and signing devices. Even if you never want to touch any cryptocurrency, the ubiquity of these devices could be a huge enabler for expanded use of end to end encryption like PGP or for simple second factor authentication like yubikeys.
Of course, when you lock real money with it, the average person puts much more energy into ensuring good passcodes and backups.
This looks neat, but even after reading their FAQ I don't understand the namesake feature -- why or when would I need more than one; and in that case, why is it a benefit that they snap together? I mean, is it just because it looks tidy/neat or is there a user story where this has additional value?
According to your other comment you haven't even seen the payment page. If you had you would indeed see that you can pay with crypto even from Norway. You're conflating payment options with the display price.
In what stores do you pay before you enter your shipping address? You haven't even gotten to the payment page yet so how can you say there is no such option?
In his (Tony Fadell's) mind, the wallet should be about the size of a credit card and have a touchscreen. ...envisioned people owning several wallets, one for each category of digital collecting or banking. He liked the concept of stacking them on top of each other, like a cash bundle of $100 bills. He came up with the idea of having magnets to snap the units into a tidy stack. That feature provided the name for the device: Stax.
So don't keep this anywhere near your actual wallet unless you are 100% sure your life is 100% free of any need to ever swipe a magstrip from anything else that lives in your wallet, then? Awesome.
home made framework like the previous devices, I'd say. The
UI is running directly in the secure element (~1.5MB flash, ~50kb ram) so it's very memory constrained.
I just asked a guy working there, he confirmed that the screen and the touch inputs are solely driven by the SE. Basically the OS only stores a few fonts and all the graphical shapes are rebuild at runtime, it's a time for space trade-off.
Wow, and all that runs on the SE? That would be really impressive!
It's still not ideal though, given that every additional feature or library blows up the trusted code base and increases the scope of any audit as a result.
Well, I just hope the existing wallets will remain supported going forward.
They have a modular approach where the OS is not updated very often, and over it are running userland applets that define their own UI and features and can be audited separately. These applets are built using Ledger's SDK which make use of the security features of the OS through a bunch of scrutinized syscalls.
The correct play is writing to the display buffer directly using a thin wrapper that has fonts, drawing primitives etc. I hope they don't have a GPOS and Qt on this.
I have no need for this device but it's definitely pretty. I love the wrap around e-ink. It looks kind of like an e-ink book cover. Cool project, gorgeous design. Would love to see more design iteration in different categories like this.
I wish this website would make the case for what it offers beyond the Ledger Nano X as easily as they did previously. From what I can tell, I am just staying to my ledger nano x because I am not interested in NFTs yet (or ever if they never become useful beyond gaming).
I'm not sure they're even useful in gaming. The NFT games of 2020 have all collapsed, and there was huge backlash among gamers against normal games incorporating NFTs.
The USB port and the left button had a short somewhere. Everytime you plugged it in, it would rapidly trigger the left button.
Two months of support for them and they kept making my jump through hoops, including uploading a YouTube video of the problem. And still the best the can say is "It's the USB-C cable, use a different one." I tried 8 cables, including the one that shipped with it, and 4 different computers. Same failure every time.
I had to file a claim with my payment processor because they would not refund me either. Another month I and finally got refunded.
What in the fuck is this company doing? They're supposed to be marketing security oriented hardware, not hype and flash and accessories. Their app is full of all sorts of affiliate nonsense, they're bloating coin specific applications to deliberately make their original product obsolete, now they have a good idea, an e-ink display, and they're packaging it like this? Marketing it like this? They must be desperate for money.
113 comments
[ 3.3 ms ] story [ 216 ms ] threadDidn't even have the decency to delete my email from their spam list after hackers got my name address, phone number and that I have a ledger.
No matter how much I unsubscribe from their mailing list.
Passport is my recommended bitcoin wallet
> Like Coldcard, the Bitcoin private keys are encrypted on the processor and stored on the secure element
And from https://coldcard.com/docs/faq:
> The ATECC608 is a fixed-function device for private key storage. [...] To be able to read the secrets (ie. wallet seed) out of the secure element [...]
Finally, you can apparently just display it in the "advanced" menu: https://coldcard.com/docs/advanced
So it seems to me like the secure element limits PIN attempts, but when successfully enter it, the keys are indeed exposed to the main processor.
A lot of the spam seems to be either proxied through insecure wordpress comment plugins or simply signing my email up for accounts on random websites and somehow injecting their phishing attempts into the account confirmation emails. They come from all sorts of domains, most of which having nothing to do with crytpo, and nearly all of the messages are embedded in some sort of broken HTML email body.
Although I no longer follow or have much interest in the industry, I am hesitant to outright blacklist crypto terms. Has anyone come up with a good solution to combating crypto email spam?
Yeah, stop using centralized services
That being said if I could go back in time and avoid making them, I think I still would....
Even placing alongside some-generic-iPhoneish-smartphone isn't a great help, as those now vary in size so much.
Here's a thought, given its use: show it alongside some of the world's most-recognized fiat monies, like the USD bill or quarter, or several EUR bills/coins.
Numerical specs are a poor substitute for a visual-intuitive sense of something's size, versus common referents.
My suggestion is only if Ledger wants their product to be easily understandable to the largest possible audience of buyers. If they're only interested in the smaller subset of people for spend extra time digging, & can interpret numerical dimensions well (perhaps with the aid of rulers/etc), then being more obscure about its size makes sense.
Credit card-sized.
Dimensions: 85mm x 54mm x 6mm
Weight: 45,2g
https://web.archive.org/web/20221030030843/https://cointeleg...
https://web.archive.org/web/20220901153130/https://www.coind...
https://old.reddit.com/r/ledgerwalletleak/comments/ki1nsz/re...
https://old.reddit.com/r/CryptoCurrency/comments/rts1w2/got_...
https://twitter.com/yeolddoc/status/1353139243548364805
Just kidding.
Given that, I'm not sure I understand why you'd put an e-Ink display (much less a JPEG parser, presumably, given the NFT stuff) on what should really just be an HSM. That seems like asking for trouble.
Edit: Not to mention Bluetooth and wireless charging, apparently.
I don't see a use for wireless charging. Maybe you can charge your wallet by placing it over your phone ?
The security model already assumes that the entity requesting authorization is untrusted, so the security model is basically unchanged. An attacker who can forge BT packets to submit bad data for approval is not really different from an attacker who compromises the laptop/phone/etc to submit bad data for approval.
You're assuming that the Bluetooth implementation does not introduce vulnerabilities that thwart this assumption; GP & GGGP are suggesting that you shouldn't have to make this assumption in a hardware wallet (or hardware that requires this very high level of assurance), by not including it at all. The same goes for, say, an attacker who's able to swap your wireless charger for a malicious one, and potentially execute a power usage-based side channel if you access the device while it's charging, or who's able to extract some useful information from the RF noise produced by the monitor.
The counterargument to this, in my mind, would be that you plan to use these features of the wallet regularly, and that they provide sufficient benefit to justify the risk (which you may argue is quite modest), and perhaps that you've implemented additional mitigations against them (like never using it while it's charging). Your argument about a monitor adding additional assurance in a sibling thread was quite good I thought, and a tact I didn't anticipate in this list originally.
So this isn’t really different from having a USB cable: in either case, some untrusted messages arrive at the secure element over some wires, and get processed there. The only difference is that the wires come from another chip on-device rather than from an external cable.
[0]: https://www.ledger.com/ledger-nano-x-bluetooth-security-mode...
I'd be surprised if that was the case. Nano X and S+ use the secure element for key operations as well as for user I/O (display and button control), which is significantly better than delegating that to a "main processor".
Given the complexity of driving a touchscreen and e-ink display, I think they might have had to return to that weaker "multi-chip" model (used in the original Nano and earlier and by many other hardware wallets), where the non-secure chip drives both the UI and I/O, rather than only latter.
There's probably more code in the Bluetooth stack than the entire rest of the code on the device.
Treating the baseband more like a peripheral device and less as a coprocessor can prevent against much of this attack surface.
That said, just adding Bluetooth (even given a perfectly isolated stack) opens several unnecessary attack vectors, including a MITM between the wallet and the device driving it. This could be used to e.g. subtly modify destination addresses or transfer amounts.
But why make it such a large/complex one, that definitely requires more trusted hardware and software in the validation and confirmation path?
Their previous wallets did this much better, in my opinion. The Stax just seems flashy at the expense of security.
If your device can receive OTA updates via Bluetooth, no. If your device has a "developer" API, almost certainly no. If the two chips share a power rail, possibly not. Without serious thought to security of requests and responses (such that MITMs are impossible), no.
There are a lot of ways this can go wrong even with separate chips.
Second case would be obvious to user, he would see the failing attempts at updating.
pt 1: https://googleprojectzero.blogspot.com/2017/04/over-air-expl... pt 2: https://googleprojectzero.blogspot.com/2017/04/over-air-expl...
TLDR: Google research exploits wifi firmware of broadcom chip in iphone, then uses that to exploit a driver bug, and manages to root the iphone. All without even connecting it to a specific AP, just from broadcast packets.
You can’t, so you’re forced to trust that the software talking to the HSM isn’t lying to you about what data it’s asking to be signed, and at that point you’re only marginally more secure than not using an HSM at all. (Sure, it’s harder to steal the long-term key material, but if I compromise your software, I get a signing oracle, and that might be good enough.)
This is actually something that the blockchain ecosystem gets right: every hardware wallet has a secure display of some kind, to avoid blind signing, because it’s a context where security actually matters (unlike, e.g., “signing git commits with a yubikey”, which nobody cares enough about to attack).
I'm not so sure about this one, there's plenty of damage you could do if you were a malicious actor who could send trusted commits to a git repo. Especially if said repo were for some important software (like Linux, wget, glibc, etc. I know they're not necessarily on public repos but we're assuming at least somewhat targeted attacks here).
I might be missing what you mean, but with a normal security module I control the inputs and outputs: the device only signs what I tell it to sign, and I can test it for honesty by verifying that any signature(s) I get back are actually signatures over the inputs I put in. That still requires me to trust that my interface to the hardware is the only interface, but that's the point of the parsimony (no bluetooth to worry about!).
HSMs have plenty of problems (and I've encountered a good share of them from designing trust ceremonies), but I don't think adding a screen addresses any of them. If I was an attacker, the pins on an e-ink display would probably be much easier to tamper with than the secure hardware itself.
A screen doesn't eliminate the necessity of this check; it's a pure convenience. And that's not to say that it's a bad one, per se, just one that is in tension with the normal key management desiderata (as few moving pieces as possible, as little code as possible, etc.).
But what if, after checking, you realize that instead of "send $50 to $friend for dinner", you signed "send my life savings to $fraudster"? That's the main attacker model of cryptocurrency wallets.
But more seriously: I've never fully understood why this is such a common issue with cryptocurrencies. My understanding of how Bitcoin works is that you need to actually submit your transaction for inclusion in a block, meaning that you have ample opportunity to verify the transaction's correctness before offering it for submission. Why aren't hardware wallets encouraging that?
If it's on your computer or phone, this means that you trust it enough to not need a hardware wallet in the first place.
If your computer is compromised, you can trust the attacker to take care of the submission for you.
I think the idea is malware on your computer could submit the signed, fraudulent transaction against your will.
In the threat model that hardware wallets address, you don't, though. Your computer could be running malware that swaps your desired target address with that of the attacker, for example.
In that sense, they go beyond (low-level) HSMs by introducing a trusted user interface so that you can verify what you sign.
However, they arguably also fall short of really solving that problem: What are you going to compare the destination address to, if you can't trust your computer to correctly display it?
Turns out that I don't have a compelling use case for it even though I own some crypto.
If I wanted liquidity in my crypto (to transfer or buy stuff) then I would just store my keys in my password manager which I seem to trust with the rest of my assets (I get crypto transactions are non-reversible).
If I do not want liquidity then I really am better off writing/engraving my keys on something and into a safe.
A combination of these two make the most sense for me.
The trouble here is the transfer of assets from the manager into your apps. Lots of opportunity for thefts or screw up. Imagine you use the clipboard and some random app happens to be scanning it.
Android does well, but my experience with Windows has remained copy paste
That being said, I believe storing private keys on a general computing device is very foolish and you will likely find out the hard way. I wouldn't store any more in a hot wallet than the amount of cash I'd be comfortable walking around with in my pocket.
Of course, when you lock real money with it, the average person puts much more energy into ensuring good passcodes and backups.
But you know… if these guys thinks that crypto is a real currency and think you should use it for trade…
Why do I have to pay for it using “real” money? They don’t really seem to be fully invested in what they’re selling.
A crypto-wallet vendor is literally blocking crypto payments, even when they (according to you) support it (for some users)?
I mean come on. That’s ridiculous?
I’ve added one to the cart and gone to checkout and literally gone all the way until I’m required to enter a shipping address and register an account.
At no point yet have I been offered the option to pay in anything except local currency (NOK).
If crypto payment is an option they are doing everything they can to keep it secret.
Tony Fadell Is Trying to Build the iPod of Crypto
https://www.wired.com/story/tony-fadell-is-trying-to-build-t...
In his (Tony Fadell's) mind, the wallet should be about the size of a credit card and have a touchscreen. ...envisioned people owning several wallets, one for each category of digital collecting or banking. He liked the concept of stacking them on top of each other, like a cash bundle of $100 bills. He came up with the idea of having magnets to snap the units into a tidy stack. That feature provided the name for the device: Stax.
[1] https://developers.ledger.com/docs/nano-app/bolos-hardware-a...
It's still not ideal though, given that every additional feature or library blows up the trusted code base and increases the scope of any audit as a result.
Well, I just hope the existing wallets will remain supported going forward.
The Stax is designed by Tony Fadell, creator of the iPod.
Edit: Ah, Tony Fadell, makes sense.
This one looks really cool and I like the features but I will never buy one because too many features and too much connectivity.
The USB port and the left button had a short somewhere. Everytime you plugged it in, it would rapidly trigger the left button.
Two months of support for them and they kept making my jump through hoops, including uploading a YouTube video of the problem. And still the best the can say is "It's the USB-C cable, use a different one." I tried 8 cables, including the one that shipped with it, and 4 different computers. Same failure every time.
I had to file a claim with my payment processor because they would not refund me either. Another month I and finally got refunded.
Never ever again.