Google's Evolving Approach to User Privacy on Location Data
Introduction
Google is set to change its storage and access of users' "Location History" in Google Maps, reducing the data retention period and making it impossible for the company to access it. This change will significantly impact "geofence warrants," a controversial legal tool used by authorities to force Google to hand over information about all users within a given location during a specific timeframe. This decision is a significant win for privacy advocates and criminal defense attorneys who have long decried these warrants.
The company aims to protect people's privacy by removing the repository of location data dating back months or years. Geofence warrants, which provide police with sensitive data on individuals, are considered dangerous and could turn innocent people into suspects.
Understanding Geofence Warrants
Geofence warrants, also known as reverse-location warrants, are used by law enforcement agencies to obtain locational data stored by tech companies within a specified geographical area and timeframe to identify devices near a crime scene. In contrast to general warrants, which allow law enforcement agencies to obtain data of one individual (usually the suspect), geofence warrants enable law enforcement authorities to obtain data for all individuals in a specific location and subsequently track and trace any device that may be linked to a crime scene. Geofence warrants have become a major issue, with law enforcement agencies utilising them to obtain location data from tech companies.
Privacy Concerns of Geofence Warrants
While Geofence warrants allow law enforcement agencies to determine and identify potential suspects, these warrants have sparked controversy for their invasive characteristics. Civil rights activities and various technology companies have raised concerns over the impact of these warrants on the rights of data principals. It is noted that geofence warrants mark a rise in cases of state surveillance and police harassment. Not only is any data principal in the vicinity of the crime scene classified as a potential suspect, but companies are also compelled to submit identifying personal data on every device/phone in a marked geographic space.
From Surveillance to Safeguards
Geofence warrants have become a contentious tool for law enforcement worldwide, with concerns over privacy and civil liberties, especially in sensitive situations like protests and healthcare. Google is considering allowing users to store their location data on their devices, potentially ending the use of geofence warrants, which law enforcement agencies use to obtain location data from tech companies.
Google is changing its handling of Location History data, moving it on-device instead of on its servers. The default data retention period will be reduced. Google Maps' product director, Marlo McGriff, stated that the company will automatically encrypt backed-up data for cloud backups, preventing anyone from reading it. When these changes are implemented, Google will have no geodata fishing options for users. Google confirmed that it will no longer be able to respond to new geofence warrants once these changes are implemented, as it will not have access to the relevant data. The changes were designed to put an end to dragnet searches of location data.
Conclusion
Google's decision to change storage and access policies for users' location history in Google Maps marks a pivotal step in the ongoing narrative of law enforcement's misuse of geofence warrants. This move aims to safeguard individual privacy by significantly restricting the data retention period and limiting Google's ability to comply with geofence warrants. This change is welcomed by privacy advocates and legal professionals who express concerns over the intrusive nature of these warrants, which may potentially turn innocent individuals into suspects based on their proximity to a crime scene. As technology companies take steps to enhance user privacy, the evolving landscape calls for a balance between law enforcement needs and protecting individual rights in an era of increasing digital surveillance.
References:
- https://telecom.economictimes.indiatimes.com/news/internet/google-to-end-geofence-warrant-requests-for-users-location-data/106081499
- https://www.forbes.com/sites/cyrusfarivar/2023/12/14/google-just-killed-geofence-warrants-police-location-data/?sh=313da3c32c86
- https://timesofindia.indiatimes.com/gadgets-news/explained-how-google-maps-is-preventing-authorities-from-accessing-users-location-history-data/articleshow/106086639.cms
Related Blogs
Executive Summary
A video featuring the newly appointed Chief of Army Staff (COAS), General Dhiraj Seth, is going viral on social media. The video claims that he made controversial remarks regarding Operation Sindoor and alleged that the previous military leadership hid the bodies of Indian soldiers martyred during the operation. It further claims that Defence Minister Rajnath Singh and Prime Minister Narendra Modi were also kept unaware of the matter. CyberPeace Research Wing research found the claim to be misleading. The research revealed that the viral video was digitally manipulated using artificial intelligence (AI), and the voice heard in the video is not authentic.
Claim
A viral video shared on social media platform X claims that newly appointed Chief of Army Staff (COAS) General Dhiraj Seth said that the bodies of Indian soldiers martyred during Operation Sindoor were hidden and that Defence Minister Rajnath Singh and Prime Minister Narendra Modi were not informed about it. https://archive.ph/oaOgB , https://x.com/InsiderWB/status/2072434480543899826
Fact Check
To verify the viral claim, we searched the internet using relevant keywords including “General Dhiraj Seth statement on Operation Sindoor”, “Operation Sindoor martyrs”, and “dead bodies hidden.” However, we did not find any credible media report stating that Army Chief General Dhiraj Seth made the remarks attributed to him in the viral video. We also checked the official social media handles of the Indian Army, but found no official statement or information supporting the viral claim. During the research, several keyframes from the viral video were extracted and analysed through reverse image search. The search led us to an ANI report published on July 1, 2026, whose watermark is also visible in the viral video. The original footage shows General Dhiraj Seth addressing the public after assuming charge as the Chief of Army Staff. We carefully reviewed General Dhiraj Seth’s entire address but found no mention of hiding the bodies of martyred soldiers or any statement related to the viral claim. The same address was also shared on the official platform of the Indian Army. The video review confirmed that it does not contain any such remarks.
https://www.facebook.com/reel/1592505052458589
During the analysis, it was also observed that the name tag on General Dhiraj Seth’s uniform appears distorted in several frames. Such inconsistencies are commonly seen in AI-generated or digitally manipulated videos. To verify the authenticity of the video, we analysed it using multiple AI detection tools. The results from all the tools were consistent. Hive Moderation’s analysis indicated a high probability that the viral media contains AI-generated or deepfake content.
Undetectable AI’s analysis also concluded that the voice heard in the viral video was likely generated using artificial intelligence (AI).
Conclusion
Our research found that the viral video is not authentic. There is no evidence that Chief of Army Staff General Dhiraj Seth ever accused the previous military leadership of concealing the bodies of soldiers martyred during Operation Sindoor. The video has been digitally manipulated, and the claim being circulated on social media is misleading.
.webp)
Executive Summary
Ahead of the final phase of the West Bengal Assembly elections, a claim regarding Uttar Pradesh cadre IPS officer Ajay Pal Sharma began circulating widely on social media. Users claimed that Sharma was being sent to West Bengal on deputation for a period of five years. However, research conducted by CyberPeace Research Wing found the claim to be false. Sources close to the IPS officer confirmed that no such deputation order has been issued so far and that Ajay Pal Sharma is currently posted as Additional Commissioner in Prayagraj, Uttar Pradesh. Ajay Pal Sharma had earlier been deployed as a police observer during the West Bengal elections. During that period, a video of him warning Trinamool Congress candidate Jahangir Khan from the Falta constituency had gone viral on social media.
Claim
Several users on Facebook and X claimed that Ajay Pal Sharma had been transferred to West Bengal for five years under an administrative arrangement involving experienced officers from different states. One Facebook user wrote:“This decision has been taken under an administrative arrangement through which experienced officers are deployed in different states.”
- https://www.facebook.com/photo.php?fbid=818902764628152&set=a.296761956842238&type=3
- https://perma.cc/FD8Q-CF7L?type=standard
Fact Check
Our research found that the deputation claim is false. Ajay Pal Sharma is currently serving as Additional Commissioner in Prayagraj, a position he has held since 2025. Further scrutiny revealed that the claim appears to have originated from a parody account on X. On May 4, around 6 PM, the account @abdullah_0mar posted the claim regarding Sharma’s alleged five-year deputation to Bengal. However, in the comments section, the user later clarified that the post was intended as satire.
We also reviewed several news reports regarding Ajay Pal Sharma’s role during the West Bengal elections. Reports confirmed that the Election Commission had deployed him as a police observer in South 24 Parganas district during the polls. However, none of the reports mentioned any five-year transfer or deputation to West Bengal.
Conclusion
The viral claim is false. No official order has been issued regarding IPS officer Ajay Pal Sharma’s deputation to West Bengal for five years. Sources close to the officer confirmed that he continues to serve as Additional Commissioner in Prayagraj, Uttar Pradesh. Sharma had only been deputed as a police observer during the West Bengal Assembly elections, during which a video of him warning TMC candidate Jahangir Khan went viral online.
Introduction
For years, Indian companies could get away with vague privacy promises. That window closed on 13 November 2025, when the government notified the Digital Personal Data Protection Rules, giving teeth to the broad principles Parliament had passed back in 2023 under the DPDP Act. The Rules turned soft commitments into specific, auditable duties, and a lot of organisations are only now realising how much that actually changes.
Start with Section 8(4). It requires every Data Fiduciary to put "appropriate technical and organisational measures" in place. Most readers skim past "organisational" and focus on the technical half, but that's a mistake, because the word is doing real work. It's asking for defined roles, written policies, staff training, and someone actually watching whether any of it holds up over time, not just firewalls and encryption keys. Section 8(5) goes further, demanding reasonable security safeguards against breaches, and Rule 6 spells out exactly what that phrase means in practice: encrypt data at rest and in transit, restrict access on a need to know basis, require multi factor authentication, log and monitor activity, run regular vulnerability checks, bind your data processors contractually to the same standard, and keep relevant logs for at least a year.
Then there's Rule 7, and this is where the clock starts running. Once a Data Fiduciary becomes aware of a breach, the Data Protection Board must be told without delay, and a full report has to follow within 72 hours covering what happened, when, why, what's being done about it, and confirmation that affected individuals were notified. Unlike GDPR, there's no minimum severity threshold here. A breach affecting ten people triggers the same obligation as one affecting ten million. And CERT-In's existing six hour reporting window under its 2022 Directions still applies separately, which means a serious incident can trigger two overlapping regulatory clocks running side by side.
Put all of this together and a pattern emerges. The law assumes an organisation already knows what it's protecting, has actually protected it, kept usable records the whole way through, and can explain clearly what happened the moment something breaks. That coordination job belongs to Governance, Risk and Compliance, or GRC for short. GRC decides who's accountable, which risks actually matter, which controls address them, and how anyone checks whether compliance is real rather than assumed. Skip that structure and security work tends to splinter into a pile of disconnected tasks nobody truly owns.
GRC gives a legal duty somewhere to live. Forensic readiness is what lets an organisation prove, months or years later, that the duty was actually being met.
The Role of Governance, Risk and Compliance
On paper, most cybersecurity programmes look fine. There's an incident response plan somewhere, access control rules exist, logging is "in place," and someone has a title that says they're responsible for security. None of that gets tested until something actually breaks. A phishing compromise, a ransomware infection, a leaked database, a hijacked admin account, whatever the trigger, the questions that follow are always the same, and they're not comfortable ones. What happened, exactly, and when did it start? Which systems, which data, were actually touched? Were the controls the organisation claims to run genuinely functioning at that moment, or just described in a slide deck somewhere? And can anyone produce records solid enough to answer those questions with confidence rather than a shrug?
This is the exact seam where GRC and digital forensics meet. GRC lays out what's expected, who's responsible, and what evidence a control should be generating in the background. Digital forensics is the craft of taking whatever technical traces actually exist and turning them into an account of events that will hold up to scrutiny. Passing an audit was never really the point. Being able to stand in front of a regulator, mid incident, and show that the processes described on paper were real, active, and generating trustworthy evidence, that's the actual bar.
Why Compliance Alone Falls Short
Compliance, in the narrow sense, just means meeting whatever legal, contractual, or internal requirement applies. But a policy sitting in a document repository proves nothing about what actually happens on a Tuesday afternoon when someone requests admin access. A written incident response plan says nothing about whether the team can actually execute it under real pressure, at 2am, with a ransomware note on every screen. A logging policy is close to worthless if the logs it promises were switched off somewhere along the way, or overwritten, or scattered across systems that were never synchronised to the same clock.
NIST's Cybersecurity Framework 2.0 essentially built this concern into its core structure, placing "Govern" alongside Identify, Protect, Detect, Respond, and Recover as one of five equal functions rather than background paperwork sitting off to the side. India's own regulatory posture pushes in the same direction. CERT-In's 2022 Directions require certain incidents to be reported within six hours of discovery, and its guidance for government entities leans heavily on documented incident handling and disciplined evidence practices. The underlying message from both is identical: figure out, before anything goes wrong, whether the evidence you'll eventually need is actually going to exist when someone asks for it.
Where GRC and Forensics Actually Connect
A good GRC programme spells out what's supposed to happen. Forensic readiness is what lets you later prove what actually did.
Access control is a useful example here. On the GRC side, an organisation might require least privilege access, multi factor authentication, periodic reviews of who holds privileged accounts, and prompt removal of access once someone leaves or changes roles. On the forensic side, none of that means anything without the underlying records that let investigators actually test it, authentication logs, MFA usage history, privilege change records, and account activity trails. The table below lines up a few common GRC controls against the specific evidence needed to show they were genuinely operating.
A Practical Scenario: After a Ransomware Incident
Picture a mid-sized company waking up to find half its file servers encrypted. There's an incident response plan somewhere in the shared drive, technically, but nobody's actually run through it in over a year. The security team isolates the obviously compromised endpoint and starts escalating. Now the forensic side of the house has to reconstruct what happened, working backward through endpoint telemetry, authentication logs, firewall events, email traffic, and file activity, hunting for the original point of entry, how the attacker escalated privileges, how they moved sideways through the network, what data they actually touched, and finally how the ransomware got deployed.
This is where the quality of everything collected beforehand suddenly matters a great deal. If server clocks were never properly synchronised, the timeline investigators build might not line up cleanly enough to trust. If logs only ever lived locally on individual machines rather than being pulled centrally, some of them are probably gone by now. If nobody ever bothered logging administrator actions, there are going to be real, unexplained gaps in the story. And if whatever evidence does exist wasn't collected the right way, its integrity can be challenged later, sometimes fatally, in a legal or regulatory proceeding. CERT-In actually ran a programme on exactly this in July 2026, "Inside the Breach," covering system artefacts, investigative technique, and chain of custody requirements, precisely because this is where real investigations tend to succeed or quietly fall apart.
Building a Forensic Ready GRC Programme
For an organisation starting more or less from scratch, forensic readiness doesn't need to be bolted on as some separate initiative. It can be built straight into the GRC programme that already exists. Start by identifying the systems, applications, cloud services, and privileged accounts that actually matter. Map the real risks and regulatory requirements onto the controls meant to address them. Then get specific about what evidence each control should be generating, and how that evidence gets protected and kept over time. Time synchronisation, centralised logging, tightly controlled access to security records, and clear ownership of preservation, escalation, and investigation all need to exist well before an incident, not be improvised during one. And none of it means much until it's actually been tested, through tabletop exercises and simulated incidents rather than assumed to work because it's written down somewhere. NIST SP 800-61 Revision 3 frames incident response as one continuous loop of preparation, detection, response, recovery, and improvement, rather than a series of separate boxes to check.
There's one question worth asking of every important control an organisation runs: could you actually prove this was working at the moment an incident happened? If the honest answer is no, what you have is a compliance process on paper, and a forensic readiness gap sitting quietly underneath it.
Conclusion
Cyber readiness was never really about how many policies sit in a binder or how many boxes get ticked in an audit. It shows up, or doesn't, in the hours right after something breaks, when an organisation has to move fast, preserve evidence that can actually stand up to scrutiny, explain clearly what happened, and prove that governance and technical controls were genuinely working together rather than just coexisting on paper. GRC sets the direction, the accountability, the risk priorities, and the compliance expectations. Digital forensics does the work of preserving and interpreting the technical evidence once something actually happens. Forensic readiness sits in between the two, making sure they're actually talking to each other long before an incident forces the conversation. The practical task for most organisations comes down to something simple to say, if not always simple to build: design controls that hold up under real incident response, not just an auditor's checklist. The strongest compliance posture was never the one with the thickest binder. It's the one that can back every document up with evidence, on the day it actually matters.
References
- Digital Personal Data Protection Act, 2023, Sections 8(4), 8(5), 8(6). https://www.meity.gov.in/writereaddata/files/Digital%20Personal%20Data%20Protection%20Act%202023.pdf
- Digital Personal Data Protection Rules, 2025, Rules 6 and 7, notified 13 November 2025. https://www.meity.gov.in
- National Institute of Standards and Technology, The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29, 2024. https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final
- Indian Computer Emergency Response Team (CERT-In), Directions under Section 70B of the Information Technology Act, 2000, dated 28 April 2022. https://www.cert-in.org.in/Directions70B.jsp
- Indian Computer Emergency Response Team (CERT-In), Guidelines on Information Security Practices for Government Entities. https://www.cert-in.org.in/Downloader?fileName=CIPS-2026-0014.pdf&pageid=5&type=2
- National Institute of Standards and Technology, SP 800-86: Guide to Integrating Forensic Techniques into Incident Response, 2006. https://csrc.nist.gov/pubs/sp/800/86/final
- International Organization for Standardization, ISO/IEC 27037:2012, Guidelines for identification, collection, acquisition and preservation of digital evidence. CERT-In, "Inside the Breach: Advanced Cyber Forensics & Incident Investigation," 31 July 2026. https://www.cert-in.org.in/s2cMainServlet?pageid=PRSTNVIEW03&reCode=CIWS-2026-3569
- National Institute of Standards and Technology, SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management, 2025. https://csrc.nist.gov/pubs/sp/800/61/r3/final
- Matters.ai, "DPDP Breach Notification: 72-Hour Rule & ₹200 Cr Penalty." https://www.matters.ai/article/dpdp-breach-notification MediaNama, "Data Breach Reporting Timeline of DPDP Rules 2025 Explained." https://www.medianama.com/2025/11/223-data-breach-reporting-timeline-of-dpdp-rules-2025-explained/
