43% (of the 158 3rd-party requests) is... google. youtube, fonts, and analytics. 55% if you include facebook and twitter.
a government app shouldnt have crazy analytics and tracking and whatever. but i dont think loading google fonts or embedding youtube videos is really all that wild in the grand scheme of things.
given the title, i was half expecting some sort of egregious list with, like, palantir and some ICE domains or something. i dont like the app, but google? facebook? that is pretty boring.
the title probably should focus on nature/severity of the requests. titling it with a % of all requests feels bait-y if google/facebook/twitter isnt off in its own category. they have all sorts of dumb little requests to all sorts of domains that really inflate the numbers.
(as a note, atomic.computer also loads analytics and google fonts. which is whatever. but if they are going to imply 3rd-party requests are inherently bad just by nature of being 3rd-party, they may want to clean their own house a little bit.)
edit: original title at the time of my comment was "We intercepted the White House app's traffic. 77% of requests go to 3rd parties"
> given the title, i was half expecting some sort of egregious list with, like, palantir and some ICE domains or something. i dont like the app, but google? facebook? that is pretty boring.
Are ICE and Palantir forbidden from buying data from Google or Facebook?
This sounds like a smart way to own an app where you decide what you want to track and nobody is stopping you from getting the data you are phoning home. And you can launder it through normal tracking providers.
If you read through the article, you'll see that the author focuses more on the OneSignal and Elfsight requests. The generic third party requests to Google, YouTube, etc. presumably were included for completeness + transparency and aren't meant to be some damning evidence against the White House app.
Though if your comment is solely based off of the previous title alone, then fair enough.
> given the title, i was half expecting some sort of egregious list with, like, palantir and some ICE domains or something. i dont like the app, but google? facebook? that is pretty boring.
Current government tries to steer the ship that is the US in the direction of an autocratic state as can be seen by most of their actions. But it's a huge ship and it takes time, no matter how hard you try (luckily).
"(as a note, atomic.computer also loads analytics and google fonts. which is whatever. but if they are going to imply 3rd-party requests are inherently bad just by nature of being 3rd-party, they may want to clean their own house a little bit.)"
Opinions may differ on this but mine is that this form of argument^1 is extremely weak and only strengthens the counter position, i.e., that third party requests are _in practice_ worth reporting on. As with any reported information, the readers of the reporting may draw their own conclusions and make value judgments about what is "good" or "bad"
1. The form of argument goes something like "X website is reporting on Y phenomenon, e.g., data collection, tracking, etc., using Z website as an example, but because X is also an example, X cannot or should not report on Y." The later is arguably "shooting the messenger"
AFAICT this atomic.computer web page does not suggest third party requests are "inherently bad". That is a conclusion presented by the HN commenter. What the atomic.computer web page does is examine the use of third party requests as a means of data collection and tracking. The HN commenter then cites an imaginary opinion about third party requests being "inherently bad". For me, this suggests there may be something behind that idea. Perhaps the commenter has "insider" knowledge of some sort regarding data collection and tracking. It's like a leak from a guilty conscience
Generally, there is no way for a computer user to monitor and control how data is used once it is collected nor where it may or may not be transferred
As such, this is not question of "bad" versus "good" in any universal sense. That may be something that weighs on the minds of people connected to data collection and/or tracking practices. But every user is different. The issue for the user is control. The user cannot limit how the data is used or where it could be transferred, even he had some opinion about what uses were "good" and what uses if any were "bad"
What companies do with data collected from "apps" is within their control, not the user's. Generally the operators of "app" endpoints have no obligation to disclose (a) how the data collected is used, whether it is used to "improve the service", improve their own sales/revenue, improve someone else's sales, etc. or (b) where the data might be transferred, whether that transfer is voluntary or involuntary, e.g., data breach, mergers and acquisitions, bankruptcy, requests from law enforcement, etc.
> We installed mitmproxy on a Mac, configured an iPhone to route traffic through it, and installed the mitmproxy CA certificate on the device.
> All HTTPS traffic was decrypted and logged. No modifications were made to the traffic. The app was used as any normal user would use it.
Is it really that simple to inspect network traffic on an iPhone, namely to get it to trust the user-installed cert? I do quite a bit of network inspection on Android and I find it to be painful, even if the apps don't use certificate pinning.
Regardless, it highlights the importance of having control of our own devices, including the ability to easily inspect network traffic. We have the right to know where our data is being sent, and what data is being sent.
I recall during COVID it was discovered that Zoom was sending traffic to China. There was also the recent case of Facebook tracking private mobile browsing activity and sending it to their servers via the FB app. Imagine how much questionable traffic goes unnoticed due to the difficulty in configuring network inspection for apps.
I filter the vast majority of adware such as doubleclick.net right at the DNS level. Not that I would use the app anyway...
It's shocking how many third party connections an average website opens. It's particularly true for news websites. Interestingly, atomic.computer also attempts to load Cloudflareinsights and some Google fonts, both of which are denied on my network. This is precisely the kind of requests that make it trivially possible for Google to follow people around the Internet, and the vast majority of webmasters are complicit of this.
So like... most b2c apps out there? I checked app privacy report for a few such apps I have installed and also got a very high proportion of third party domains. Maybe not as high as 77% but definitely above 50% (ie. more domains are third party than first party). The most surprising part here is them refusing to put correct info in the "data collected" section of the app store listing.
edit: they seemed to have updated the store listing, so the "data collected" section is correct.
Government apps should absolutely be held to a higher standard than consumer B2C apps. Loading Google Fonts is one thing — sending telemetry to OneSignal and Facebook from an official government app is a different conversation entirely.
In Australia, apps handling government data must comply with the PSPF (Protective Security Policy Framework) and the ISM, which explicitly restrict data flows to untrusted third parties. A government app routing 77% of requests externally would fail an IRAP assessment on day one.
The fix is straightforward: self-host fonts, use first-party analytics, and treat every external request as a data exfiltration vector. Government digital teams know how to do this — the question is whether anyone is actually reviewing the network behavior post-deployment
Don't get me wrong, the government requires a high level of scrutiny.
I would be interested to see how this compares to industry standard though, 77% doesn't seem outrageous to me given all the trackers and advertising code I've seen over the years. It wouldn't surprise me if this is inline with many apps people install and don't think twice about.
the privacy manifest declares no data collected while the app sends your device model, ip address, session count, and a persistent tracking id to onesignal on every launch. false attestation anyone?
72 comments
a government app shouldnt have crazy analytics and tracking and whatever. but i dont think loading google fonts or embedding youtube videos is really all that wild in the grand scheme of things.
given the title, i was half expecting some sort of egregious list with, like, palantir and some ICE domains or something. i dont like the app, but google? facebook? that is pretty boring.
the title probably should focus on nature/severity of the requests. titling it with a % of all requests feels bait-y if google/facebook/twitter isnt off in its own category. they have all sorts of dumb little requests to all sorts of domains that really inflate the numbers.
(as a note, atomic.computer also loads analytics and google fonts. which is whatever. but if they are going to imply 3rd-party requests are inherently bad just by nature of being 3rd-party, they may want to clean their own house a little bit.)
edit: original title at the time of my comment was "We intercepted the White House app's traffic. 77% of requests go to 3rd parties"
> given the title, i was half expecting some sort of egregious list with, like, palantir and some ICE domains or something. i dont like the app, but google? facebook? that is pretty boring.
Are ICE and Palantir forbidden from buying data from Google or Facebook?
This sounds like a smart way to own an app where you decide what you want to track and nobody is stopping you from getting the data you are phoning home. And you can launder it through normal tracking providers.
Though if your comment is solely based off of the previous title alone, then fair enough.
> given the title, i was half expecting some sort of egregious list with, like, palantir and some ICE domains or something. i dont like the app, but google? facebook? that is pretty boring.
Current government tries to steer the ship that is the US in the direction of an autocratic state as can be seen by most of their actions. But it's a huge ship and it takes time, no matter how hard you try (luckily).
Opinions may differ on this but mine is that this form of argument^1 is extremely weak and only strengthens the counter position, i.e., that third party requests are _in practice_ worth reporting on. As with any reported information, the readers of the reporting may draw their own conclusions and make value judgments about what is "good" or "bad"
1. The form of argument goes something like "X website is reporting on Y phenomenon, e.g., data collection, tracking, etc., using Z website as an example, but because X is also an example, X cannot or should not report on Y." The later is arguably "shooting the messenger"
https://en.wikipedia.org/wiki/Shooting_the_messenger
AFAICT this atomic.computer web page does not suggest third party requests are "inherently bad". That is a conclusion presented by the HN commenter. What the atomic.computer web page does is examine the use of third party requests as a means of data collection and tracking. The HN commenter then cites an imaginary opinion about third party requests being "inherently bad". For me, this suggests there may be something behind that idea. Perhaps the commenter has "insider" knowledge of some sort regarding data collection and tracking. It's like a leak from a guilty conscience
Generally, there is no way for a computer user to monitor and control how data is used once it is collected nor where it may or may not be transferred
As such, this is not question of "bad" versus "good" in any universal sense. That may be something that weighs on the minds of people connected to data collection and/or tracking practices. But every user is different. The issue for the user is control. The user cannot limit how the data is used or where it could be transferred, even he had some opinion about what uses were "good" and what uses if any were "bad"
What companies do with data collected from "apps" is within their control, not the user's. Generally the operators of "app" endpoints have no obligation to disclose (a) how the data collected is used, whether it is used to "improve the service", improve their own sales/revenue, improve someone else's sales, etc. or (b) where the data might be transferred, whether that transfer is voluntary or involuntary, e.g., data breach, mergers and acquisitions, bankruptcy, requests from law enforcement, etc.
> We installed mitmproxy on a Mac, configured an iPhone to route traffic through it, and installed the mitmproxy CA certificate on the device.
> All HTTPS traffic was decrypted and logged. No modifications were made to the traffic. The app was used as any normal user would use it.
Is it really that simple to inspect network traffic on an iPhone, namely to get it to trust the user-installed cert? I do quite a bit of network inspection on Android and I find it to be painful, even if the apps don't use certificate pinning.
Regardless, it highlights the importance of having control of our own devices, including the ability to easily inspect network traffic. We have the right to know where our data is being sent, and what data is being sent.
I recall during COVID it was discovered that Zoom was sending traffic to China. There was also the recent case of Facebook tracking private mobile browsing activity and sending it to their servers via the FB app. Imagine how much questionable traffic goes unnoticed due to the difficulty in configuring network inspection for apps.
https://news.ycombinator.com/item?id=47555556 https://news.ycombinator.com/item?id=47577761
It's shocking how many third party connections an average website opens. It's particularly true for news websites. Interestingly, atomic.computer also attempts to load Cloudflareinsights and some Google fonts, both of which are denied on my network. This is precisely the kind of requests that make it trivially possible for Google to follow people around the Internet, and the vast majority of webmasters are complicit of this.
edit: they seemed to have updated the store listing, so the "data collected" section is correct.
In Australia, apps handling government data must comply with the PSPF (Protective Security Policy Framework) and the ISM, which explicitly restrict data flows to untrusted third parties. A government app routing 77% of requests externally would fail an IRAP assessment on day one.
The fix is straightforward: self-host fonts, use first-party analytics, and treat every external request as a data exfiltration vector. Government digital teams know how to do this — the question is whether anyone is actually reviewing the network behavior post-deployment
I would be interested to see how this compares to industry standard though, 77% doesn't seem outrageous to me given all the trackers and advertising code I've seen over the years. It wouldn't surprise me if this is inline with many apps people install and don't think twice about.
https://appgoblin.info/apps/gov.whitehouse.app/sdks