Personal Black Box?

[Karl]

On Sun, Jun 14, 2020, 8:20 AM other.arkitech <other.arkitech at protonmail.com>
wrote:

> I've been very busy and there's a log going on here that i missed, but in
> general I am very interested in this project as well (together with the
> tor-replacement one),
>
> Isn't it like those google-maps cars that are using a rotating camera to
> capture 360deg pics while in motion?
> Which brings the idea of using a single rotating minicamera instead of 8
> or so. .
>
> Since I am doing this USPS thing which consists on basically a personal
> negociator-box/electronic-you siting at home managing all of your private
> data I cannot avoid to think about using it as the final storage of the
> data coming from the portable device.
>

Would you be excited about contributing open source code to a pluggable
storage backend, so that USPS could be used for storage?

Open source is pretty import, and so is using existing work like USPS, so
I'm imagining a pluggable backend.


> best,
> OA
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, June 12, 2020 9:49 PM, jim bell <jdb10987 at yahoo.com> wrote:
>
>
> On Friday, June 12, 2020, 03:27:06 AM PDT, Karl <gmkarl at gmail.com> wrote:
>
> 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.
>
>
> I am proposing building a useful tool.  I don't work under the illusion
> that it is possible to always prevent "bad people" from using that tool for
> "bad things".  Nevertheless, I am quite confident that given the large
> number of applications of this tool, an enormous net benefit to people will
> occur.
>
> I look at it this way:  I am not proposing a major leap in technology.
> Most of it already exists.   Smartphones, SSD's, battery packs, and
> cameras.  WiFi and cell-phone data transmission.  What I'm proposing could
> be readily done with existing chips and devices.  If "cops" (term used
> generically) actually WANTED a 360-panorama video recording system, for
> recording demonstrations or riots, don't you think somebody would have
> already put this together?
>
> My answer to that is this:  Cops DON'T want their 'standard of
> performance' to be raised in ways they don't want to see, all the time.
> Sure, they'd no doubt love in very limited cases to use such a device to
> provide evidence against a few defendants, but they know it wouldn't stay
> limited to that!  People would start to EXPECT that every 10th cop would
> have this kind of device, with the video eventually made publicly
> available.  Or "worse", to them, how about EVERY cop?   And all that video
> would have to be made available to every defense attorney, in every trial
> !!!
>
> Already, many and perhaps most jurisdictions have cop-body-cams, which I
> consider an enormous advance.  That is, it's an advance IF the cops are
> REQUIRED to wear the cameras, and even more importantly, they are not
> allowed to push some sort of "reset and erase data" button if they've just
> murdered a citizen.  The issue isn't so much "surveillance", but "who
> controls and benefits from that surveillance?".
>
> Have you ever heard of the "CSI effect"?
> https://en.wikipedia.org/wiki/CSI_effect    Future jurors exposed to
> technology begin to expect that technology to be used in just about every
> case, not just the few that cops and prosecutors would like to see.
>
> (A few years ago, I saw a show on an advance in evidence collection.
> While photography has long been used in collecting crime-scene evidence,
> the problem is, it isn't immediately clear what photographs have to be
> taken.  What was being described amounted to a 'photograph robot', a device
> which drives through a crime scene (indoors or out) and photographs
> 'everything'.  Not merely in the 360 degree horizontal plane, but in fact
> "up" and "down" as well.  At extremely high resolution.  Unfortunately, a
> few minutes of searching YouTube, I cannot find an appropriate video.)
>
> When we think of 'reasons that cops have to fear video surveillance',
> perhaps we mostly think of incidents like Rodney King in 1992, George Floyd
> in 2020, and a few other incidents over the years.  And yes, that's a big
> matter.  But I think there is also a class of surveillance that would show
> cops in a bad light, even when they are seemingly doing 'nothing'.
>
> Portland Oregon, a city a few miles away from me, is actually somewhat
> famous for a series of skirmishes that go on.  There is a repeated
> suspicion that the leftist government of Portland orders its cops to turn
> away when there is a disturbance by leftist protestors.  Occasionally,
> organizations like Patriot Prayer announces a rally, and shortly afterwards
> Antifa shows up, and a riot ensures.  Example:
> https://www.youtube.com/watch?v=fECgG5NLUr4
>
> The Portland Police, operating under the leftist Portland government, have
> frequently been accused of following orders to allow Antifa to riot.  That
> might be true, but it's hard to collect evidence supporting (or opposing)
> such an accusation.  Most publicly-accessible evidence is limited to
> reporting and broadcasts by news media, and there are few such news crews,
> and their cameras only point in one direction at a time.  And they choose,
> if for no other reason than the lack of broadcast time, to air only a
> limited portion of their photography.
>
>   I've seen some broadcasts, and given these major limitations (and major
> cuts) it is very difficult to figure out who is actually doing what.  As
> importantly, it isn't clear if (for example) the cops are
> accidentally-on-purpose FAILING to respond to assaults.  A few seconds of
> an assault, with a cop somewhere in the background, might not unambiguously
> show the kind of deliberate negligence that would resolve the ambiguity.
>
> In one rather-well publicized example, gay conservative journalist Andy
> Ngo was violently assaulted by Antifa-types about a year ago.
> https://www.youtube.com/watch?v=8WzMZxT-41k   Naturally, he wasn't
> assaulted because he is gay; nor was he assaulted because he was a minority
> (Asian).  Apparently he was simply assaulted because he is called
> "conservative".  In this day and age, that is enough to merit a cracked
> skull or even worse.
> Also:   https://www.youtube.com/watch?v=JKwT3PoRErM
>
>
> If a person wearing a  Personal Black Box had been around, many minutes
> before, during, and after this kind of assault, I think it would have been
> far more clear who was complicit in the events. I have no doubt that cops
> fear that kind of exposure.  And that's exactly why we should welcome it.
>
>
>
> >  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.
>
>
> Fortunately, existing technology (or technology that can be readily
> assembled) could do so much better.  See this, which is over 7 years old!
>
>
> http://itersnews.com/?p=24633#:~:text=During%20its%20demonstration%2C%20Qualcomm%20showed,higher%20bit%20rate%20of%206Mbps.
>
> "During its demonstration, *Qualcomm* showed that the *Snapdragon* 800
> chipset compressed 1080p 30 frame video clips at a bit rate of 4Mbps using
> its built-in HEVC codec software stack. On the other hand, the predecessor
> H. 264 video codec technology encoded the same 1080p 30 frame at far higher
> bit rate of 6Mbps.Feb 13, 2013"           [end of quote]
>
>
>
>
>   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.
>
> I am now simply anticipating what such a 'central board' would contain,
> and how big it will be.  However, at this moment, I am woefully  unaware of
> the history of smartphone CPUs.  And there is apparently a  lot to learn,
> see this example:
> https://arstechnica.com/gadgets/2019/12/qualcomms-new-snapdragon-865-is-a-step-backwards-for-smartphone-design/
>
>
> I am trying to keep the added-technology things a simplified great deal,
> using mostly existing technology:  Using a smartphone as a controller and a
> communications (WiFi, cell phone data) box.  This allows future upgrades to
> 5G as well.   An existing SSD, an existing battery back, too.   What I've
> become aware of, literally in the last two days, is how much functionality
> is in a modern smart-phone, especially a 5G one.
>
> I calculated that the as-compressed output of 6 HD cameras could be 40
> megabits/second, but from the cite above even 7-year-old technology
> compressed a 1080P, 30 frames per second vide at 4 megabytes/second.  .
> Even a 4G phone will be able to transfer that data rate, 4 x 6 cameras, or
> 24 megabytes per second.  I think.  And I also discovered
> https://en.wikipedia.org/wiki/Wi-Fi  that WiFi 4 and above has a
> high-enough link rate to accomodate this.
>
> The two main things that must be designed are the camera stack and the
> video-compression central board.
>
>
> >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?
>
> If the video-compressing central board is as uncrowded as I anticipate
> (perhaps two, multi-core CPUS, maybe Snapdragons?), there will probably be
> a lot of extra room available for an SDR, and other devices.
> I found this:    https://en.wikipedia.org/wiki/Software-defined_radio
>
> "2000s[edit
> <https://en.wikipedia.org/w/index.php?title=Software-defined_radio&action=edit&section=7>
> ]
>
> "The SpeakEasy SDR system in the 1994 uses a Texas Instruments TMS320C30
> <https://en.wikipedia.org/wiki/Texas_Instruments_TMS320> CMOS
> <https://en.wikipedia.org/wiki/CMOS> digital signal processor
> <https://en.wikipedia.org/wiki/Digital_signal_processor> (DSP), along
> with several hundred integrated circuit
> <https://en.wikipedia.org/wiki/Integrated_circuit> chips, with the radio
> filling the back of a truck. By the late 2000s, the emergence of RF CMOS
> <https://en.wikipedia.org/wiki/RF_CMOS> technology made it practical to
> scale down an entire SDR system onto a single mixed-signal
> <https://en.wikipedia.org/wiki/Mixed-signal> system-on-a-chip
> <https://en.wikipedia.org/wiki/System-on-a-chip>, which Broadcom
> <https://en.wikipedia.org/wiki/Broadcom> demonstrated with the BCM21551
> processor in 2007. The Broadcom BCM21551 has practical commercial
> applications, for use in 3G <https://en.wikipedia.org/wiki/3G> mobile
> phones <https://en.wikipedia.org/wiki/Mobile_phones>.[9]
> <https://en.wikipedia.org/wiki/Software-defined_radio#cite_note-9>[10]
> <https://en.wikipedia.org/wiki/Software-defined_radio#cite_note-10>    "
>
>
>
>
> >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,   Wi-Fi
> <https://en.wikipedia.org/wiki/Wi-Fi>
>
>
>
>
> Wi-Fi
>
> Wi-Fi (/ˈwaɪfaɪ/)[1] is a family of wireless network protocols, based on
> the IEEE 802.11 family of standards, wh...
>
>
>
>    , 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?
>
> What about doing a Google search for "snapdragon programmer" or
> "smartphone programmer" ?
>
>
>
>
> 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 am merely going to be an invited speaker, not an organizer.  I want to
> be able to show how technology can be used to assist freedom, rather than
> to oppose it.
>
>
>  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
>
> An old saying:  "After everything is said and done, a lot more gets said
> than done".
> Cypherpunks are (or, at least, were) supposed to actually be able to
> accomplish things.  I'm trying to return to that era.
>
>
>
> 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...
>
>
>
>
> 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....
>
>
>
>
> 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.
>
>
>
> 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
>
>
>
>
>
>
>    S100 Computers - SemiDisk History
> <http://www.s100computers.com/Hardware%20Folder/SemiDisk/History/History.htm>
>
>
>
>
> S100 Computers - SemiDisk History
>
> S100 Computers
>
>
>
>
>
> 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: 78914 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20200614/f562c0d4/attachment.txt>