Personal Black Box?

Karl gmkarl at gmail.com
Fri Jun 12 03:23:31 PDT 2020 

On Fri, Jun 12, 2020, 12:00 AM jim bell <jdb10987 at yahoo.com> wrote:

> >Sounds reasonable for now.  Thinking of making the number of cameras
> customizable.
>
> Certainly.  The number of cameras is somewhat arbitrary, the main feature
> desired is an arrangement that can record the entire 360 degree horizontal
> landscape.  6 cameras should be sufficient with the (older) 4x3 screen
> aspect ratio.  With the modern HD's 16 x 9 ratio, it's conceivable that a 4
> camera system would be sufficient, and probably 5 cameras. The compression
> hardware allowing for as many as 6 cameras should be more than plenty, and
> there would not be any need to have all cameras installed at any given
> time.  This same system could also be used to run a fixed system, perhaps
> mounted on a high location.
>

For full transparency, when you describe a lot more recording than most
people do on their phones (like mounting 360 video on a high location
without specifying that it is confined to private property, or in an area
where people have asked for it, or is publicizing its recordings), I start
feeling scared because I'm reminded of the current surveillance state.
Just so you know, because others might have that response too occasionally.


> >  Any thoughts on supporting a standalone phone app, on the software side?
>
> I think the App running on the smartphone device will control the rest of
> the device.  Most of the processing (video compression) should be done by
> the central board, not by the smartphone.  I think the smartphone would be
> able to run anything you ordinarily would want to run, such as telephone
> service.
>
> >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.
>
> Yes, I think that a custom board will be very desireable, and probably
> necessary.   Is it possible that an existing design compresses the output
> of 6 HD video cameras?   I haven't looked, but it seems unlikely.
>

My experience with consumer single board computers was that you have to
drop the quality very low or use multiple boards in a pluggable way.  I
value seeing from multiple angles more than seeing in all directions,
myself, but it seems needed no matter how it functions.


>   I've just started looking at the Qualcomm Snapdragon series of
> microprocessors.
>

I understand you are beginning to prepare a board design.  I mostly know
software nowadays so I'll leave the chip review to the rest of the list.

On the software end of hardware freedom, I'm aware of a need for common
hardware that has good support for software defined radio, especially with
multiple receivers and antenna types.  Do you have any interest in
including possible radio logging in the system maybe as a plan for eventual
expansion?

Radio logging might further expand to drone tracking, planted device
detection, etc; and would stimulate better emissions control and reduced
undiscussed wireless communication in response, which helps privacy.

  https://en.wikipedia.org/wiki/Qualcomm_Snapdragon
>
> Their most recent devices use 8-cores.  Perhaps that will handle the
> compression of 3 HD video devices, but I don't expect to rely on that.
> Three, or possibly two such physical CPUs (with few other responsibilities)
> will probably easily handle 6 HDTV cameras.
>
> PC board layout these days is rather easily done.  It shouldn't be a
> problem.  A six-layer PCB, with components on both sides of the board,
> should be more than sufficient.
>
> *"Snapdragon* is a suite of system on a chip
> <https://en.wikipedia.org/wiki/System_on_a_chip> (SoC) semiconductor
> <https://en.wikipedia.org/wiki/Semiconductor> products for mobile devices
> designed and marketed by Qualcomm <https://en.wikipedia.org/wiki/Qualcomm> Technologies
> Inc. The Snapdragon central processing unit
> <https://en.wikipedia.org/wiki/Central_processing_unit> (CPU) uses the ARM
> <https://en.wikipedia.org/wiki/ARM_architecture> RISC instruction set
> <https://en.wikipedia.org/wiki/RISC_instruction_set>. A single SoC may
> include multiple CPU cores <https://en.wikipedia.org/wiki/CPU_core>, an
> Adreno <https://en.wikipedia.org/wiki/Adreno> graphics processing unit
> <https://en.wikipedia.org/wiki/Graphics_processing_unit> (GPU), a
> Snapdragon <https://en.wikipedia.org/wiki/Qualcomm_Snapdragon_LTE_modem> wireless
> modem <https://en.wikipedia.org/wiki/Wireless_modem>, a Hexagon
> <https://en.wikipedia.org/wiki/Qualcomm_Hexagon> Digital signal processor
> (DSP) <https://en.wikipedia.org/wiki/Digital_signal_processor>, a Qualcomm
> Spectra <https://en.wikipedia.org/wiki/Qualcomm_Spectra> Image Signal
> Processor (ISP) <https://en.wikipedia.org/wiki/Image_processor> and other
> software and hardware to support a smartphone's global positioning system
> <https://en.wikipedia.org/wiki/Global_positioning_system> (GPS), camera,
> video, audio, gesture recognition
> <https://en.wikipedia.org/wiki/Gesture_recognition> and AI acceleration
> <https://en.wikipedia.org/wiki/AI_accelerator>. As such, Qualcomm often
> refers to the Snapdragon as a "mobile platform" (e.g., Snapdragon 865 5G
> Mobile Platform). Snapdragon semiconductors are embedded in devices of
> various systems, including Android
> <https://en.wikipedia.org/wiki/Android_(operating_system)>, Windows Phone
> <https://en.wikipedia.org/wiki/Windows_Phone> and netbooks
> <https://en.wikipedia.org/wiki/Netbook>.[1]
> <https://en.wikipedia.org/wiki/Qualcomm_Snapdragon#cite_note-1> They are
> also used in cars, wearable devices and other devices. In addition to the
> processors, the Snapdragon line includes modems, wi-fi chips and mobile
> charging products."    [end of quote]
>
>
>
> 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.
>
> Yes, that's possible.  As with many things, there will always be a
> trade-off in these matters.  According to this,
> https://en.wikipedia.org/wiki/Wi-Fi   , WiFi 6 has a link rate of between
> 600-9608 megabits/second.  18 gigabytes per hour (what I calculated as 3
> gigabyte/camera/hour, with 6 cameras) is 40 megabits/second.  According to
> this,   https://en.wikipedia.org/wiki/4G   4G was/is supposed to handle
> as much as 1 Gbit/second.  But in a crowd of smartphone-users, what this
> will translate to 'in real life' is questionable.
>

The streaming system should be able to respond to requests to reduce upload
rate during congestion.  It might be good to provide a way for a user to
say when or where something important is happening, so the software could
prioritize it.  It could also be good to be able to look at streams to
verify they are working.


> 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.
>
> Hey, I never was a 'software guy'.  This is well beyond my ability to
> choose.  But one advantage of implementing a WiFi transmission is that
> there may be less competition for data transfer during a
> protest/demonstration in the WiFi bands, rather than cell-phone data
> bands.
>

Any idea how I might connect with other software people around this?


> 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.
>
>
> We should welcome all assistance.  If things seem to be coming along, I
> will probably announce this as a project about July 19 2020 at Las Vegas,
>    http://anarchovegas.com/
>

Thank you.  It's looking unlikely for now that I'll be able to make it to
that event, but congratulations on keeping it held despite the pandemic
scare.  That's inspiring.

 I believe that one theme of the event is development of technology.   I'd
> also like to be able to announce a project of a replacement/competition for
> the TOR anonymization system, perhaps using a Raspberry Pi 4 CPU.  The main
> obstacle to that at this point is finding somebody who would commit to
> write the appropriate software.  I will probably announce both as projects,
> and see what kind of support we get.
>

It's the other topic, but there have been a lot of software attempts to
replace or augment Tor that likely one could contact or even bring back to
life for a project for a dedicated setup.  Somebody may even have compiled
a list of those somewhere.  It seems strange to not have people mention
this.

Karl


> Jim Bell
>
>
> On Thursday, June 11, 2020, 02:31:06 PM PDT, Karl <gmkarl at gmail.com>
> wrote:
>
>
> 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.
>
> Single-board computer
> <https://en.wikipedia.org/wiki/Single-board_computer>
>
> Single-board computer
>
> Unlike a desktop personal computer, single board computers often do not
> rely on expansion slots for peripheral f...
> <https://en.wikipedia.org/wiki/Single-board_computer>
>
>
>
>
> Dyna-Micro Single Board Computers
> <http://www.vcfed.org/forum/showthread.php?57918-Dyna-Micro-Single-Board-Computers>
>
> Dyna-Micro Single Board Computers
>
> This is a discussion forum about vintage computer collecting, use,
> restoration and display powered by vBulletin....
>
> <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.  MCM6605A
> Datasheet | Motorola Semiconductor - Datasheetspdf.com
> <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.
>
>
> MCM6605A Datasheet | Motorola Semiconductor - Datasheetspdf.com
>
> MCM6605A 4096-Bit DRAM datasheet pdf provided by Datasheetspdf.com
> Datasheet pdf Search for MCM6605A.
> <https://datasheetspdf.com/datasheet/MCM6605A.html>
>
>
>
> 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.
>  the consumer SSD guide on StorageSearch.com
> <http://www.storagesearch.com/consumer-ssd.html>
>
> the consumer SSD guide on StorageSearch.com
>
> <http://www.storagesearch.com/consumer-ssd.html>
>
>
>
>
>    S100 Computers - SemiDisk History
> <http://www.s100computers.com/Hardware%20Folder/SemiDisk/History/History.htm>
>
> S100 Computers - SemiDisk History
>
> S100 Computers
>
> <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: 58737 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20200612/f2f81d82/attachment.txt>

More information about the cypherpunks mailing list