And what should users who use shamir backup or seed XOR and store parts of their secret in geographically different locations do, in the author's opinion? I also think that the standard warning is quite sufficient.

Yes, you can use different Bitcoin accounts by changing the account number in the derivation paths.
https://coldcard.com/docs/paths/

The essence of XOR is changing the value of a bit to the opposite. Having two Seeds, we lay them out bit by bit, then change the value of the bits to the opposite in the first Seed only in those places where in the corresponding places of the second Seed there will be a unit.
The only thing is, you will need to recalculate a new checksum for the 12th or 24th last word.
Example: you have two 12-word (132-bit) Seeds, you invert the corresponding first 128 bits, and recalculate the remaining 4 bits of the checksum for the new resulting Seed.
This way you don't have to worry that any online tool will stop working or will work incorrectly, in extreme cases you can restore everything yourself with a piece of paper and a pencil.

Now why are developers of other wallets not rushing to add this function? Adding such a function will require additional memory, which is already not large in modern hardware wallets. The same Trezor created its own SLIP39 standard, but I don't know of any third-party wallet except Keystone that would add this standard. The reason is simple - they don't want to clutter up the memory of their wallets with functions that are not of primary importance.

As far as I understand, this is not entirely true.
The Trezor article says the following:


That is, only those users who made a purchase from official sources are safe.

 

Found two other interesting comments under this article on Reddit:

What could it be? Another real Ledger hacking story or an attempt by a scammer to foist a victim on expensive legal help that is unlikely to help him?


I also found this message:

In general, in our time, when there is a huge number of scammers, it has become difficult to determine the truth from a lie.

I read this in the comments to his post:

Wim1441 asks the author:
Programmierus answers him:

Very strange story. The author claims that he downloaded Ledger Live from the App Store and the wallet passed the authenticity check normally. So the problem is unlikely to be in the wallet itself  

The following things also confuse me:
According to the author, the victim was new to cryptocurrency, but transferred an impressive amount of more than $200,000 to the wallet.

The provided screenshot shows that the wallet has been checked and no applications have been installed on it, although ETH and TRX should be installed at least. That is, the screenshot was taken before the hack, which is very strange, because, according to the author, after the hack the wallet was not touched again, nothing was installed or deleted.

Of course, you can check your wallet by resetting it to factory settings, create a new SEED, put a not very large amount on it and see if it gets stolen. But, in my opinion, they are not telling you something, or it's a trivial leak of SEED by an inexperienced user.

If you have the task of keeping the balance for the first wallet in the Suite desktop application, then use the web version of Trezor Suite on the same computer for the second wallet, which will pull up the balance of this wallet each time you connect again.
https://suite.trezor.io/web/

Shamir Backup (SLIP39) is a standard created by SatoshiLabs, shards created in Trezor wallets will be compatible with Keystone wallets.
https://blog.keyst.one/why-keystone-implemented-shamir-backups-71e319f972a6

You can also create shards using the converter.

Each shard contains information about share groups and the group threshold.
https://bitcointalk.org/index.php?topic=5515901.msg64685551#msg64685551


Keystone also supports Shamir backup.
https://guide.keyst.one/docs/shamir-backup

I did not find in their description what type of memory they use. Usually, if the manufacturer does not indicate this, then they use the cheapest type of QLC, in which case for the money they are asking for, it does not make sense, since it has nothing to do with the reliability of data storage. If they used SLC or at least MLC memory type, then buying this device would make some sense.

There are also discounts on ColdCard wallets for Black Friday.

ColdCard MK4 - $126.35
ColdCard Q - $175.99

https://store.coinkite.com/store/coldcard

You can exchange small amounts if you are not worried about high fees. I would recommend storing and exchanging bitcoins in other wallets, and use Ledger only to store altcoins.

First, get a display for your wallet, if you don’t find a suitable display, then order a donor wallet from Trezor, from which you can remove the display and take everything to a mobile phones or laptop repair service to have the display replaced. The wallet can be purchased for 49 euros.
https://trezor.io/trezor-model-one

Typically, batteries in new devices of the same type can swell for the following reasons:
1. The layout is too dense. If components are located very close to each other, the battery may become pinched or subject to mechanical stress. This increases the risk of physical damage to the battery and may also cause it to overheat due to heat buildup from nearby cells.
2. Incorrect charge management. The charge controller may be configured incorrectly, allowing the battery to overcharge or deep discharge. Without correct voltage and current regulation, the battery overheats and is subjected to increased stress, which leads to swelling.
These problems often arise due to insufficient testing of the prototype device under various conditions or flaws in the design stage.
It would be better if Ledger made wallets with replaceable batteries like the Passport or Coldcard Q.

Where did you read what I wrote about hacking SLIP39?
I just wrote that having access to one of the parts of the backup you can get information about share groups and the group threshold. If you do not understand this point, then create a multi-share backup using the converter, publish one part of it here, and I will provide you with information about share groups and the group threshold.

I'm not criticizing the SLIP39 standard, I created a post for people who buy a Trezor wallet and will be faced with choosing a backup type when setting it up.

The attacker does not need to decrypt everything down to the bits, since the 3rd and 4th word contain information about share groups and the group threshold, source. In addition, as I wrote above, the fourth word can only have 4 options, so it can hardly be called a full-fledged 10-bit segment, information about the fourth word could easily be encoded using 2 bits (00, 01, 10, 11), but Trezor, for some reason, decided to do otherwise.
Also, an attacker does not have to contact the converter every time, but rather create several tables of correspondence between 3 and 4 words to possible backup options.

I meant that a single-share backup of 20 words has no advantage over a backup of 12 words.

In their new wallets such as Trezor safe 3 or Trezor safe 5, the company suggests switching to the new 20-word SLIP39 backup. Whether to create a backup in the new format or to create it in the more familiar format of 12 or 24 words of BIP39 standard we will consider below.
By default, the user is offered to create a single-share backup of 20 words (with the option to upgrade to multi-share backup) or go straight to creating a multi-share backup.
The advantage of multi-share backup is that you split your secret phrase into several parts and set a threshold (minimum number of parts) to restore access to your funds and if an attacker gains access to one part, he will not be able to access your funds.

Still, if an attacker gains access to one part of the secret, he will be able to obtain information about the total number of parts into which your backup is divided and the minimum threshold.
This information is contained in the 3rd and 4th words of any of the parts.
For example, if you create a regular single-share backup, then the 3rd and 4th words will always be: academic academic.
In multi-share backup, the 4th word is responsible for the total number of parts:
For 2 parts: easy
For 3 parts: leader
For 4 parts: romp
For 5 parts: academic
For 6 parts: easy
For 7 parts: leader
For 8 parts: romp
And so on.
There are a total of 4 possible options for the fourth word. The number of minimum parts (threshold) required to restore access to funds can be determined by the third word using a converter.

Example: Let's say we have one part of the secret:

eraser senior beard leader blanket verify declare exercise rumor year submit custody spine expand document always round photo prevent sugar

Our fourth word is: leader, which means the total number of secrets can be 3. Now we launch the converter and generate phrases (click on the 128bits button), set 3 in Total shares, and select the minimum number of parts in Threshold. In our example, with Threshold equal to 2, we find in the second phrase the word: beard which is the 3rd word of our secret. If the searched word is not found, then set the Total Shares parameter to 7, since the 4th word: leader can also refer to a secret divided into 7 parts. And again we select the Threshold parameter in the search for a match of the third word. But, I don’t think in practice anyone will split their backup into more than 5 parts.

Thus, an attacker, having access to one part of your backup, will be able to assess his prospects. In this case, he will need to gain access to only one more part of the backup.

So should you switch to the new 20-word backup or continue to use the familiar 12 or 24 words?
In my opinion, switching to a single-share backup of 20 words makes sense only if in the future you decide to switch to multi-share backup, which will not be difficult to do with the help of Trezor suite.
In case of creating multi-share backup you need to understand what information an attacker will have when accessing one part of the backup. 
There are no other special advantages of a 20-word backup over a 12-word backup, in both cases random entropy of 128 bits is used.

С проблемой до сих пор не разобрался.
Пока только удалось выяснить, что Бинанс обратился в сообщество Zcash с просьбой разработать механизм с помощью которого он сможет отказывать в депозитах с защищенных адресов и возвращать их вкладчику. Для этого был разработан новый формат адресов начинающийся на TEX. Более подробно можно почитать здесь. Какие кошельки поддерживают этот формат пока мне не ясно (Леджер кстати тоже не понимает этот формат).