> One complication is that the counters have an "anti-tearing" feature for additional security
Two questions:
1. Why is it a "complication"? Is it just that it makes the counters more complicated, or is there something frustrating about the counters?
2. I would love to learn more about how the anti-tearing feature works!
The problem is that if the user tears the card away from the reader in the middle of an update, that card can end up with corrupted data. This makes implementing the increment-only counters more complicated. For instance, the straightforward approach might hold 00 FF in two bytes. If you increment the counter by updating the low-order byte first, but the card gets torn away before you update the high-order byte, you end up with 00 00, and the counter has gone backward.
A simple way of preventing tearing is to have two copies of each counter; if there is tearing, then the two values will be different.
Looking at an NXP patent [1], they use a much more complicated approach, using a level of indirection. They write the new value to a different memory page and then update a pointer to
the new page. There are various progress bits recorded along the way so they can roll back as needed.
For no Newton iterations, I thought I found 0x5f37641f had the lowest relative error, and I measure it at 3.4211. Of course I’m not super certain, Lomont’s effort is way more complete than mine. Lomont’s paper mentions 0x5f37642f with a relative error of 3.42128 and Wikipedia and the paper both talk about 0x5f375a86 being best when using Newton iterations.
I was feeling motivated last night at 1am, and it took every inch of my body to NOT whip out VS Code.
Still couldn't sleep until 4am. Woke up today at 1pm.
--
I used to think that growing up would mean that I could go to sleep whenever I wanted, and do what I want.
Turns out that growing up means you learn that you shouldn't do those things.
But why? My mornings are usually clear of meetings, and I could just work PST hours from the east coast, and it would be fine.
Turned out that working every evening is not good for your social life, and having a social life is something I try to prioritise more than hacking all day all night.
If these things are a good idea, they should be applied generally. Depending on individual sites to apply them, and individually at that, means that most sites will never get them, and that the “best practice” has an ever-increasing weight and burden over time.
The problem is, changes to the web platform need to be backward compatible. You can't make a global change without potentially breaking existing content. In this case, you could easily end up triggering scrolling in a bunch of places, or with punctuation being invisible or looking bad. So it has to be opt-in.
In the footnotes you said:
> One complication is that the counters have an "anti-tearing" feature for additional security
Two questions:
1. Why is it a "complication"? Is it just that it makes the counters more complicated, or is there something frustrating about the counters? 2. I would love to learn more about how the anti-tearing feature works!