[walterbell]

Thanks for outlining a defensive design. Could you recommend good references or example projects for learning how to design open hardware/software for sensor data acquisition, tamper-resistant signals storage, and decentralized analysis?

[DoctorOetker]

I won't refer you to specific projects, but I will list a number of keywords, as those should help anyone willing to contribute to explore these ideas further in journal articles, although it seems you already know relevant terms I didn't mention (like "tamper-resistant", although you may have more success with "security envelope").

Specifically regarding bullet detection, you may wish to consult ballistic software which takes into account air friction. Once you can generate random trajectories in air for a representative distribution of initial bullet speeds, it should be relatively simple to transform these to relative pulse arrival times at a 3D array of microphone locations.

For precise pulse arrival times one may wish to look at "constant fraction discriminaors", so that for rising pressures of the pulse, the timing is independent of pulse strength.

For decentralized analysis, and compatibility with the courts it would be best if it didn't output a "Holy Answer", but instead computes an interpretation of the recordings and why it believes in the trajectory it heard, so that at all times an alternative interpretation with a better fit can be proposed, and algorithms improved. This would require the decentralized code to effectively run a formal verifier on the audio evidence backed proof. Reimplementing the metamath verifier on a decentralized blockchain should work.

The devices themselves would best be constructed by and for the population, with individuals selected at random, trained to understand how the device works, and then implementing it and its security envelope.

It would be best if the protocol allowed new concerned citizen to continuously join the protocol, to use threshold cryptography so that the police can only consult the recordings with permission of civilian population, keeping an eye on how often they request to check for a bullet when there was none (some should be tolerated, but bulk collection denied).

The devices should store candidate recordings in a rotating buffer overwriting older / less probable bullet recordings, but always encrypted towards the group by treshold cryptography. These on-device recordings should be considered a backup failsafe only in case internet connectivity disappears. The usual operation is to (immediatly) send the encrypted shards to the group of civilians running the protocol (for time stamping purposes). Individuals or small groups can not decode the recordings on their own, only with sufficient ( K out of N ) civilians agreeing the recordings should be published can they be published, in which case that recording is public for all (including the police). Either everyone gets to hear the shots fired, or no one. Regarding the agreement procedure: that too would use formal verification, the rules and conditions when civilians are supposed to agree should fall under democratic control, and the user agent (software client) the civilians run automatically release or withhold according to these rules. Unreliable citizens that refuse to release their share of the secret when they are supposed to, or leak their share of the secret when they are not supposed to are temporarily banned from participating in the protocol (and will for such duration no longer be remunerated for their participation). This means you don't get cliques of interested parties joining up in large numbers amid a disinterested and unincentivized population cherry picking when to release a recording or not (by modifying the source code of their local client in order to cherry pick against due process when to release the recordings).

[walterbell]

Thanks, this is super helpful, especially the civilian and clique game theory scenarios. Will use search terms to find related material.

There may be attempts to use WiFi 7 sensing/radar in 2024 Meteor Lake laptops and 2025 routers to make claims about the presence of specific humans (e.g. gait, breathing, typing signatures), https://www.lumenci.com/post/wi-fi-sensing-applications-and-.... Some of the techniques you've outlined above could be appplied to through-wall WiFi Sensing devices.

[DoctorOetker]

typing signatures? that would probably result in an overall decrease of security in the landscape, considering things like passwords are ... typed!

[walterbell]

Yes, it's unclear how the FCC is allowing IEEE 802.11bf to proceed if it can be used to collect passwords and other typed data, not to mention what people are physically doing in different rooms of their homes and businesses. Good for vendors of 2FA and faraday rooms, but bad for the millions of buildings about to become transparent.

As for keystroke timing, it could theoretically have been collected for years by local and web (search?) services which offered autocomplete. Research and investment is ongoing, e.g. https://arxiv.org/pdf/2101.05570

> Our approach called TypeNet achieves state-of-the-art keystroke biometric authentication performance with an Equal Error Rate of 2.2% and 9.2% for physical and touchscreen keyboards, respectively ... the databases used in this work are the largest existing free-text keystroke databases available for research with more than 136 million keystrokes from 168,000 subjects in physical keyboards, and 60,000 subjects with more than 63 million keystrokes acquired on mobile touchscreens ... The global keystroke biometrics market is projected to grow from $129.8 million dollars (2017 estimate) to $754.9 million by 2025, a rate of up to 25% per year.

Meteor Lake has a dedicated IP block for sensor fusion, https://community.intel.com/t5/Blogs/Tech-Innovation/Client/... & https://venturebeat.com/games/intel-unveils-meteor-lake-proc...