Personal Black Box?
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
> 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
> 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
> 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.
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
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
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>
> 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
> 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.
> 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
> Jim Bell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 18574 bytes
Desc: not available
More information about the cypherpunks