By "internal feedback" do you mean feedback when a user is logged into an account?
We allow you to do fine-grained censoring of any DOM element by adding class="do-not-track". So if there's a field, or an entire page, that you do not want captured, you can easily mask all of it.
Passwords fields are always censored, and there's no way to disable that.
We also have limited session lengths (up to 30 days), unless a user leaves feedback or a member of the team explicitly saves a moment.
Why is it not possible to embed the NFC tag in a destructible medium? Like those annoying stickers that you cannot peel without ripping?
If you use that, then the only way to move the NFC tag to another item would be to cut it out of the original item (including the original adhesive). But this attack also works against the technique in the article.
Regarding the orientation, I understand that it is nondeterministic in the original, but what prevents an attacker from copying it deterministically? Is it just that technology is not good enough to manipulate such small pieces of metal? How long will this limitation persist?
What prevents somebody from scanning it and reconstructing the position of the metal pieces?
Perhaps a better solution is to create a small chip powered by electric induction. The chip would have an embedded private key and solve challenge-response queries issued by the scanning device.
I'm not sure how that compares in cost though.
Edit: it looks like these already exist and cost less than 10 cents a piece. They are called NFC tags.
We tried for years to do things like this, and in the end an approach using typescript is way, way better than anything else I've seen attempted.
In my latest project[1], we set up the types for the API. The server and client are both bound by those types, meaning that one cannot change without the other. This fixes an entire class of bugs where backend code gets updated without the corresponding front-end code changing or vice-versa. It also has the nice side-effect that all of the possible return values (including errors) are nicely documented in one file, and that the errors are very consistent. On the frontend we have a "typed fetch" which returns typed results from the API.
We are also using this for typed access to localStorage, another source of many bugs in past projects, where random keys end up being scattered and causing nondeterministic behavior on different devices.
You can see how our API type system is implemented here:
[1]: We are working on https://app.presupplied.com, a digital home-schooling curriculum to teach 3-year-olds to read. Planning to expand to math, writing, and programming.
I am skeptical of reports published by the cities. There is incentive for the reports to skew positive, since otherwise individuals can lose elections/jobs/contracts.
So I looked back at the 2014-2016 reports from Flint, Michigan to see if they correctly predicted the water crisis.
Also note that while in the US the lead concentration limit is 15 ppb, Canada has recently reduced its limit from 10 ppb to 5 ppb. Nearly every US city I've looked at exceeds 5 ppb.
Almost every date picker I've used is terrible. If you are reading this and are responsible for adding a datepicker, please, please, please do at least the following:
1. There should be a textbox allowing me to type a human-readable date/time (e.g. "monday 5pm" or "july 7, 2015").
2. The textbox should be selected and ready to type into as soon as the datepicker is opened
3. There should be a short list of previously-typed dates because often, for a given date in the UI, the same date is used multiple times in quick succession
4. There should be a typical month view with days of the week visible, in case I'm on mobile
5. The current date should be highlighted on the month view.
6. I should be able to pick the month and the year in at most two taps each (i.e. dropdown for each), no matter how far back in time I need to go.
Shameless plug: we recently implemented an exceptional date picker on momentcrm.com because of how frustrated we were with the default browser experience.
We allow you to do fine-grained censoring of any DOM element by adding class="do-not-track". So if there's a field, or an entire page, that you do not want captured, you can easily mask all of it.
Passwords fields are always censored, and there's no way to disable that.
We also have limited session lengths (up to 30 days), unless a user leaves feedback or a member of the team explicitly saves a moment.
You can learn more here: https://moment.help.guide/v1/user-manual/time-travel/privacy