On Sun, Dec 08, 2019 at 09:43:03AM +0000, jim bell wrote:
> A few days ago, there was a news item about a bank robber who was caught 
> because he (stupidly) took his cell phone to the robbery.  He was exposed by 
> the technique called "geo-fencing".  
> https://www.nbcnews.com/news/us-news/police-used-google-location-data-find-accused-bank-robber-he-n1086836
>     The legitimacy of the use of this technique is currently a subject of his 
> appeal, but is not relevant to my comment, below.  
> Maybe if he had been smart enough to know how to activate his
> phone's "airplane mode", which supposedly turns off all electronic
> transmissions, he wouldn't have quite as identifiable.  But, as
> cypherpunks know, it isn't clear that a smartphone's promise that
> it won't transmit and thus reveal its location can be relied upon. 
> Further, even if we can know, for sure, that a phone didn't
> TRANSMIT during that relevant period, that doesn't mean that it
> didn't record its path in space (by GPS) and time during such a
> period, later to be uploaded to Google servers.


We know that does happen.



>  Perhaps wrapping
> that phone in a few layers of aluminum foil would have blocked the
> (already quite weak) GPS signals, so the phone wouldn't know where
> it was.  
> However, it occurred to that there may one day be a need for a person to 
> enter a geographic area that has cellular phone service, but not have his 
> smartphone emit signals that would (immediately) identify that phone's 
> presence there.  Okay, "airplane mode".  But, he could also want his presence 
> to be unknown including later, by disabling Google location services.  MAYBE 
> that would 'work'.  He might want to visit like this multiple times, leaving 
> that area each time, not leaving an electronic trace.  Yet, maybe he'd want 
> to use that smartphone's camera (to record video and still frame) and audio 
> (to record sound).  
> Even more, maybe an event would occur, and he would have evidence of it in 
> video and audio, and he might (later) want to document the fact by uploading 
> video and audio evidence to a server somewhere, at that time or seconds 
> later.  But he might not want to record the video, still frames, or audio 'in 
> the clear'.  And, there would be no reason that he'd have to upload the 
> entire (huge) video and audio files:   He could subject the resulting data to 
> a 'cryptographic hash', 
> https://en.wikipedia.org/wiki/Cryptographic_hash_function   so that he could 
> upload only 256 bits.  That hash could itself be encrypted, and could 
> actually be a hash of a table of hashes:  A hash for each one second of video 
> and/or audio, or even a smaller quantity of time, just for an example.   
> Initially, he could upload just the overall hash.  And if, later on, he 
> wanted to prove that he had acquired some data at a specific time, or at 
> least prior to some specific time (when it was uploaded), he could do so by 
> releasing files which correspond to the segments of video and/or audio files, 
> and show that their hashes match the hashes in the uploaded hash-files.   
> How could he transmit that short hash back to his home base, or anywhere 
> else?   How about 
> https://www.popularmechanics.com/promotions/a20777855/the-mesh/?src=syn&dom=yah&mag=pop
> His release of that hash would allow him to later prove, once the source 
> files are released, that he had generated them, at or before a specific time 
> (If you believe the system to which the transmission was initially sent, or 
> your own computer if it's sent along quickly enough), and the video and audio 
> would provide evidence of the event he chooses to claim.  But he might not 
> release the open, unhashed and unencrypted information, immediately:  His 
> claim might be challenged, and he could hold that in reserve as evidence he 
> was correct.  
>               Jim Bell
> 
> 
> 
> https://www.popularmechanics.com/promotions/a20777855/the-mesh/?src=syn&dom=yah&mag=pop
> 
> Or:   https://gotenna.com/pages/sdk   Full technical 
> specs:https://gotennapro.com/pages/spec-sheets#pro-pro-x-spec-sheet
>  True, it would be better if this was an SDR, or "software defined radio".  
> I just found this a couple of days ago.  

Reply via email to