Slashdot Mirror
Police Are Filing Warrants For Android's Vast Store Of Location Data (theverge.com)
The Verge is reporting about a man who robbed a Bank of America office in Romana, California. A person, named Timothy Graham, matching his profile robbed another bank in November. The investigators, however, didn't have enough evidence to prove that Graham was indeed the same person who robbed the other bank as well. The cops contacted Google and utilised a feature of Maps that builds a comprehensive history of where a user has been -- information that is proved valuable to police and advertisers alike. The publication claims that in the past few months, police have used this Maps' feature in several other instances as well. From the report: Investigators had already gone to Graham's wireless carrier, AT&T, but Google's data was more precise, potentially placing Graham inside the bank at the time the robbery was taking place. "Based on my training and experience and in consultation with other agents," an investigator wrote, "I believe it is likely that Google can provide me with GPS data, cell site information and Wi-fi access points for Graham's phone." [...] It's not clear whether either of the public warrants were filled. No Google-based evidence was presented in Graham's trial, and the other suspect plead guilty before a full case could be presented. Still, there's no evidence of a legal challenge to either warrant. There's also reason to think the investigators' legal tactic would have been successful, since Google's policy is to comply with lawful warrants for location data. While the warrants are still rare, police appear to be catching on to the powerful new tactic, which allows them to collect a wealth of information on the movements and activities of Android users, available as soon as there's probable cause to search.
On the other hand, if you're more likely to be falsely accused than actually commit a crime.... You might come out ahead by outsourcing your alibi.
You don't have to be using maps. Location data is used for all sorts of behind the scenes functionality (updating Google Now, Showing Android Pay cards for store locations you're in, etc.).
Everywhere you've been if you have Location History turned on:
https://www.google.com/maps/ti...
Cite?
Sure.
For several years before our university decided to go with Google Apps, our department had its own Google Apps domain. After the university finally deployed its own version, one of our (non-computing) staff decided she wanted her department calendar moved over to the university system - so we did the export-then-import thing, only using Google's own tools. Unfortunately, she worked closely with several other staff who did not want to move their calendars, and for whatever reason they had trouble with the concept that she was on a different domain... so after a month or so, she gave up and moved back to the department calendar. We went in and deleted all her calendar info on the university Google Apps system, following Google's instructions (it's been several years, but I think it even involved deleting the calendar) - afterwards I verified that her university calendar was empty of all entries (this was important because I wanted to be sure there was no confusion regarding which of her calendars was the correct one for everyone to use).
Fast forward several months. Our department decides to ditch our own Apps domain, and go with the University system. So for each staffer we go through the export-then-import dance... which worked perfectly fine, except for that single staffer who'd made the aborted move before. There was nothing showing on her university Google calendar, but none of the longer-standing repeating events would move over for her - Google would start to import then complain about "existing duplicates" (which were not visible on the target calendar!). Eventually I solved the problem by loading the iCal file and incrementing a particular counter value corresponding to each event, which made it look like we were importing a newer version of the events - then the import happily worked.
I am open to alternative explanations as to why the importer was finding duplicates where none should have existed - but it sure seems like they never actually deleted anything, but just hid it all from the user.
#DeleteChrome