On Friday, June 12, 2020, 03:27:06 AM PDT, Karl <gmk...@gmail.com> wrote:
 
On Fri, Jun 12, 2020, 12:00 AM jim bell <jdb10...@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]

"The SpeakEasy SDR system in the 1994 uses a Texas Instruments TMS320C30 CMOS 
digital signal processor (DSP), along with several hundred integrated circuit 
chips, with the radio filling the back of a truck. By the late 2000s, the 
emergence of RF CMOS technology made it practical to scale down an entire SDR 
system onto a single mixed-signal system-on-a-chip, which Broadcom demonstrated 
with the BCM21551 processor in 2007. The Broadcom BCM21551 has practical 
commercial applications, for use in 3G mobile phones.[9][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 (SoC) semiconductor products for 
mobile devices designed and marketed by Qualcomm Technologies Inc. The 
Snapdragon central processing unit (CPU) uses the ARM RISC instruction set. A 
single SoC may include multiple CPU cores, an Adreno graphics processing unit 
(GPU), a Snapdragon wireless modem, a Hexagon Digital signal processor (DSP), a 
Qualcomm Spectra Image Signal Processor (ISP) and other software and hardware 
to support a smartphone's global positioning system (GPS), camera, video, 
audio, gesture recognition and AI acceleration. 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, Windows Phone and netbooks.[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

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
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 <gmk...@gmail.com> wrote: 
 
 
 Jim, I'm reading your e-mail while replying.

On Thu, Jun 11, 2020, 4:43 PM jim bell <jdb10...@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

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
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

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
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    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

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
the consumer SSD guide on StorageSearch.com


 |

 |

 |



   
    S100 Computers - SemiDisk History

| 
| 
| 
|  |  |

 |

 |
| 
|  | 
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 <gmk...@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 <jdb10...@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



  
  
  

Reply via email to