Personal Black Box?

Karl gmkarl at gmail.com
Thu Jun 11 14:30:46 PDT 2020


Jim, I'm reading your e-mail while replying.

On Thu, Jun 11, 2020, 4:43 PM jim bell <jdb10987 at yahoo.com> wrote:

> "I am interesting in participating in designing and building one.  It
> helps me to set a norm of speaking concisely and to the point, as reading
> can be hard for me when working.  I am sorry if I have skimmed over
> something already said.  Have you started any projects?"
>
>
> I've done a substantial amount of electronics in the 1970's and to the
> early 1990's, but I haven't done an electronics project since then.  Not
> that I couldn't pick it up quickly:  The major thing I'm missing is
> knowledge of the current set of devices available and construction
> techniques.
>

> I designed and built a constant-temperature bath in the ealry 1970's, also
> a 4-digit audio frequency counter, also a 4.5 digit digital voltmeter.  In
> 1977 I built a "Dyna-Micro" microprocessor trainer, from the design in
> Radio-Electronics magazine.
>

I was born in 83 and I believe I built a robot hand by following a design
in Radio-Electronics as a child.  I was self and family taught, but mostly
software.

https://en.wikipedia.org/wiki/Single-board_computer
>
>
> http://www.vcfed.org/forum/showthread.php?57918-Dyna-Micro-Single-Board-Computers
>
>
> I added to that with a custom-PC board with 8K by 8 memory, which actually
> seemed like a lot of memory at that time!
>
> Starting in 1978, I designed and built my custom-bus Z-80 microprocessor
> computer which at one point had about 600 IC's, mostly wire-wrapped.  My
> father and I set up the ability to make 2-sided PC boards around 1972, but
> since we couldn't plate-through the holes, actually assembling such a board
> was a bit tedious.  I built two 32K by 8 DRAM cards using Motorola 4k x 1
> 6605 DRAM chips, later replacing them with static RAM.
> https://datasheetspdf.com/datasheet/MCM6605A.html    In hindsight, I
> decided that I should have used one of the 16k x 1 DRAMs that had become
> available.
>
>
> In 1980, I invented the solid-state disk, I called it a "SemiDisk", and in
> late 1981 I started a company which built them for 10 years, for the S-100
> bus, the TRS-80 Model II, the IBM PC, and the Epson QX-10.  The first three
> started as 512k byte cards, with software that implemented a virtual disk.
>  http://www.storagesearch.com/consumer-ssd.html
>
>
> http://www.s100computers.com/Hardware%20Folder/SemiDisk/History/History.htm
>
>

You are very experienced with electronics.


> In 1990, I designed and built a device which used 76 IRLEDS to flash,
> activating the Opticom traffic control system to turn red traffic lights
> into green traffic lights.   Had I gone into major production, I would have
> used as its motto:   "It's the most fun you can have in a moving car !!!".
>

That sounds awesome.


>
> HOW I FORESEE THE PERSONAL BLACK BOX:
>
> I see a central box, about the size and shape of a common smartphone, but
> with no user interface.  It will include connectors to:
>
> 1.   USB, to a standard, commercial smartphone.
> 2.   To the camera stack, 4-6 HD cameras.   (About 3 gigabytes per hour
> per camera.)
> 3.   To a battery pack.
> 4.   To a SSD.      At 3 gigabytes/camera/hour x 6 cameras, about 18
> gigabytes per hour.  So, a 1 terabyte SSD should be sufficient, if its data
> transfer rate is enough.
>
> The central box will probably include 2-3 multi-core microprocessors, and
> its main task will be taking the data outputs of the cameras, compressing
> them, and sending the result to the SSD.
>

Sounds reasonable for now.  Thinking of making the number of cameras
customizable.  Any thoughts on supporting a standalone phone app, on the
software side?

You mentioned a lot of experience making new hardware designs.  Are you
imagining designing a custom board?  I imagine that would open options up a
lot but it sounds like a big investment of effort and time for most people.

It will probably not be possible to send more than a tiny fraction of this
> data directly to the Internet, so I anticipate sending maybe 1 frame/second
> for each camera, to be stored remotely.  I've read that eventually, 5G
> technology will be able to transfer 10 gigabits/second, but I doubt that
> this will be kept up in a crowd of thousands of people, many of whom will
> be using their own cell phones.
>

You can also compress it super-low quality when quick motions matter.


> The smartphone might also be linked to a nearby confederate (is that word
> too anti-PC these days?) by WiFi, whose system might mirror as best as
> possible the video material being collected.  One goal is to ensure that
> complete destruction of the system will not lose all the data collected.
> If the location of the event was anticipated, perhaps a remote
> data-collection box could be installed, which would act as a safe data
> backup.
>

Any thoughts on a data protocol with wifi peers?  https://datproject.org
https://gnunet.org .  I've also found https://git-annex.branchable.com
which uses git of course https://scuttlebutt.nz which is nodejs and json
based but has nice data preservation goals, a modified blockchain might
work.  Haven uses the signal private messenger protocol.  A local webserver
could do a simple handmade one, I suppose; harder to make many backups.


> The actual control of the camera system might be done remotely:  The
> person wearing the system shouldn't be expected to do anything other than
> being a camera platform.
>

Sounds good for journalists working with a team.

This kind of system would probably have an even bigger market to
> journalists and news crews.  I don't expect it to substitute for
> traditional video cameras, but its presence would tend to guarantee that
> most information gets collected.  It would tend to protect the news crews,
> because it would store a record of any attacks on them.
>
> Jim Bell
>

Sorry I jumped excitedly on your project like this.  I can do some software
coding but need to work with others to take something to completion.  That
difficulty is also why I think of reusing existing work where possible.

On Wednesday, June 10, 2020, 12:26:08 AM PDT, Karl <gmkarl at gmail.com>
> wrote:
>
>
> It's obvious that people who are oppressed by local authorities need a
> personal black box.
>
> I am interesting in participating in designing and building one.  It helps
> me to set a norm of speaking concisely and to the point, as reading can be
> hard for me when working.  I am sorry if I have skimmed over something
> already said.
>
> Have you started any projects?
>
> I have started https://github.com/xloem/openrealrecord (nodejs, messy)
> and https://github.com/xloem/libgame/blob/wip-1/source/stream-up.cpp (c++
> livestreams data to sia skynet with hash identifiers).  openrealrecord has
> an open bountysource.com bounty of I think a little over $1000 that a
> contributor never claimed, left over from back when I had money.
>
> I also started developing videorecording in guardianproject's haven app
> towards this goal https://github.com/guardianproject/haven/pull/418 .
>
> I'd like to build this in a way that quickly gets it usable by average
> people.  Once it is easy to use and stable the people who can make the most
> use of it can share it among each other and more developers may contribute
> exponentially.
>
> Am I on the same page as you?
>
> On Mon, Oct 1, 2018, 2:16 AM jim bell <jdb10987 at yahoo.com> wrote:
>
> A few weeks ago, I got done binge-watching every episode of NCIS, and am
> now up to Season 4 of Criminal Minds.  Naturally, this induces a bit of
> what I'll call cinematic paranoia.   In what seems to be a majority of
> episodes, a victim gets attacked, usually ends up dead, and the plucky
> investigators are stuck trying to figure out what happened.  Naturally,
> they usually do, but only after about 45 minutes of high-tension showtime.
> It occurs to me that what people may need, for physical security, would be
> what might be called a "personal black box", analogous to an airplane
> flight recorder.  Or, a civilian version of a cop's body-cam.
>
>   Any modern smartphone would have the basics of such a device:  A
> high-resolution camera, microphone, and a huge amount of storage.  And a
> quick 911-call if necessary.  The mere possession and use of such a device
> would probably deter the large majority of potential attackers.  And even
> if it does not completely protect a given user, it would allow far more
> easy identification of the perpetrator.    Parts of this, of course, are
> not a new idea.
>
>  https://www.sparkfun.com/news/702
>
> https://www.theglobeandmail.com/technology/gadgets-and-gear/gadgets/your-own-personal-black-box/article4300839/
>
>
> https://www.zdnet.com/article/fitbit-activity-data-as-evidence-in-court-wearables-serve-as-personal-black-boxes/
>      https://www.medgadget.com/2005/08/cpod_a_personal.html
> https://newatlas.com/australia-black-box-flight-recorder-soldiers/51267/
>
>
> However, storage is not enough:  In use, in some instances, an attacker
> would presumably be aware enough to take or break the device, so some sort
> of continuous or discontinuous upload of the data could be done, to be
> available no matter what else happens.  Say, a frame per second when
> nothing seems to be happening, and a greater rate when triggered somehow.
> Could a heart-rate monitor be employed, sensed one axis of the phone's
> accelerometers?  Or if the wearer falls down?  Or if a sufficiently-loud
> noise is heard, etc.  Or if a trigger-word is spoken a la Siri?
>
> Can the data transfer be made economical?  Even an average of 1
> megabit/second would be over one gigabyte during a 3 hour usage per day.
> That's substantially greater than most people currently use.  One
> possibility is that the phone could upload the data to the cell phone
> company, where it could be "parked" for a few seconds or minutes.  If
> nothing happens to the phone to cause a trigger (some sort of attack) the
> phone could instruct the cell phone company to abandon the data.
> Conversely, if a trigger occurs, the cell phone company would move 100% of
> the data to a backup system for later retrieval.  Presumably, the cell
> phone company would offer discounted rates for such transfers, and only
> offer that service if the local service is sufficiently unloaded at that
> moment.
>
>             Jim Bell
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 18574 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20200611/57850c3a/attachment.txt>


More information about the cypherpunks mailing list