tsergiu
Joined 14 years ago
Joined 14 years ago
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
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?
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.
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:
- common types for both client and server: https://github.com/stoarca/presupplied/blob/master/images/ps...
- client's typed fetch: https://github.com/stoarca/presupplied/blob/master/images/ps...
- server's typed endpoint definitions: https://github.com/stoarca/presupplied/blob/master/images/ps...
[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.
So I looked back at the 2014-2016 reports from Flint, Michigan to see if they correctly predicted the water crisis.
They did, but only very subtly.
In 2014, there was a single violation of too many total trihalomethanes: https://www.cityofflint.com/wp-content/uploads/2014/01/CCR-2...
In 2016, there were no declared violations, even though the 90th percentile sample of lead concentration (20 ppb) was over the 15 ppb limit: https://www.cityofflint.com/wp-content/uploads/City-of-Flint...
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.
@stoarca on twitter