Praveen Mishra logged 348 hourly Pixel requests. Encryption complicates the rest

Why it matters

Independent packet tests can pressure platform vendors and expose background network activity. Mishra's results also show why traffic counts, payload evidence and metric definitions must remain separate.

Praveen Kumar Mishra, a Dubai-based IT operations lead and founder of PraveenTechWorld, published an expanded study on September 19th claiming that an idle Google Pixel 8 made 348.4 outbound requests per hour to Alphabet infrastructure.

Mishra says he and his collaborators placed factory-unlocked Pixel 8 phones on an isolated Wi-Fi network, routed their traffic through a pfSense firewall and recorded 72 hours of activity while the devices remained locked and plugged into power. His headline comparison put stock Android at 348.4 requests per hour and GrapheneOS without Google services at zero.

That is an ambitious bench test from an independent operator. Mishra's public profile says he studied computer science engineering at Guru Tegh Bahadur Institute of Technology in Delhi before working in e-commerce operations, digital marketing and systems administration. PraveenTechWorld is his technical publishing and services operation, where he documents Windows diagnostics, local AI tests and infrastructure work. For this experiment, he wrote that he and his friends "wanted to see what really happens" when phones are left alone.

The resulting work provides a useful count of connections to named infrastructure. Its claims about what traveled inside those connections require evidence beyond the capture method Mishra describes.

What Mishra put on the bench

The research page says Mishra's group bought three 128GB Pixel 8 phones and connected them to a private WPA3-Enterprise network with no other devices present. The phones were reportedly left untouched for 259,200 seconds.

Mishra divided the stock Pixel traffic into services including Google Play Services, location and mapping, device provisioning, Google Photos, Search and Assistant, Firebase Cloud Messaging and diagnostics. The individual categories add up to the stated 348.4 requests per hour. The page reports 42 Alphabet endpoints and 18.6 MB sent per day under the default configuration.

A companion guide describes four profiles: a stock Pixel at 348.4 requests per hour, a stock Pixel with privacy settings disabled at 194.2, GrapheneOS with sandboxed Google Play at 12.1, and GrapheneOS without Google services at zero.

The description of the physical setup shifts between pages. The research article specifies three phones on an otherwise empty network. The guide says there were "four identical test setups," then separately describes three Pixel phones and two PCs connected through a managed switch. The exact number of capture subjects and control devices matters because the headline figures are presented as a reproducible benchmark.

The tooling also needs more precise language. Netgate's pfSense documentation says its packet-capture interface is a front end to tcpdump; captures can then be downloaded and examined in Wireshark. Mishra describes a pfSense firewall "running Wireshark" and capturing every radio wave from the phones. The defensible description is simpler: the firewall observed network packets that crossed its interfaces.

Connection counts do not reveal every payload

The capture can establish that a device contacted an IP address, when it did so, the port and protocol involved, and the number of bytes transferred. DNS and TLS metadata may also help associate traffic with a destination domain.

Mishra goes further. The page says connections contained nearby Wi-Fi identifiers, SIM serial hashes, hardware fingerprints, facial-recognition indices and trending search queries. It assigns these descriptions to destinations including checkin.gstatic.com, device-provisioning.googleapis.com and photosdata-pa.googleapis.com.

Those payload-level conclusions are not established by the published methodology. The page identifies much of the traffic as TLS 1.3. Wireshark's documentation explains that TLS encrypts client-server communications and requires session secrets or other suitable key material for decryption. Mishra's methodology does not describe collecting TLS session keys, installing a trusted interception certificate, instrumenting the phones, or correlating the captures with application logs.

A destination can suggest a service category. It cannot, on its own, prove that a particular encrypted packet carried a Wi-Fi BSSID, serial hash or facial-recognition tag. The downloadable CSV includes a description column for Mishra's interpretation of each transmission, so an independent audit must distinguish captured fields from labels added during analysis.

Google's own documentation confirms the broader premise that Android devices contact its servers in the background. Google says the Android Device Configuration Service periodically sends device and account identifiers, software versions, network information and device attributes. Google also says Play Services system management may collect IP addresses, SIM operator information, identifiers and performance data to provide updates, connectivity and security functions.

That documentation supports the existence and general categories of background communication. It does not validate Mishra's packet-by-packet descriptions or his frequency totals.

The arithmetic needs another pass

Mishra's 348.4 hourly figure produces about 8,362 requests over 24 hours. The page's interactive privacy calculator uses 8,920 daily pings without explaining the additional 558 connections.

The claimed 99.4% reduction is similarly difficult to map onto the displayed comparison. A decline from 348.4 Alphabet requests per hour to 0.0 is a 100% reduction in that stated metric. The study may be using a different denominator, though the page does not define one.

The meaning of zero also changes across the article. At points, Mishra calls it zero Alphabet connections, which is plausible for a GrapheneOS installation with no Google software. Elsewhere, he describes zero outbound requests of any kind and says the phone woke only when an app requested access.

GrapheneOS documents that its system updater checks for releases roughly every six hours while connected and can operate while the phone is locked and idle. A zero result may therefore reflect filtering for Alphabet-owned destinations rather than all network activity. The benchmark needs to state that boundary consistently.

GrapheneOS itself supports sandboxed Google Play, which runs Google's services as regular applications without the privileged access they receive on stock Android. Mishra's reported decline to 12.1 requests per hour in that configuration is potentially the study's most informative comparison. It attempts to measure how much Google traffic remains when users retain app compatibility while changing the trust model.

An independent test worth making reproducible

Mishra has turned a familiar privacy concern into a concrete experiment with hardware, configurations and numerical claims. That is useful work. Independent operators can run tests that larger research groups overlook, and publishing a CSV gives others a starting point for examining the results.

A reproducible release would define what counts as a request, identify the exact Android and GrapheneOS builds, provide the capture dates, reconcile the number of test devices and publish the packet captures and parser used to produce the tables. Payload claims need decryption evidence or narrower wording tied to observable metadata.

With those additions, Mishra's bench could measure a real tradeoff facing Android users: how much background Google communication accompanies stock services, and how that traffic changes when those services are restricted, sandboxed or removed. The first version establishes a testable question. Its strongest numbers still need an audit trail as detailed as the conclusions.