I checked Apple’s new privacy ‘nutrition labels.’ Many were false
washingtonpost.com
washingtonpost.com
Well, there you have it folks. That’s the crux of the article. The author is complaining about an anonymous, mutable value that can be changed at any time. It’s the technology constructed and promoted by Apple to track conversions.
And no, it’s nothing like your social security number.
The comparison to an SSN is reasonable to explain this to a normal person. It's also a number that directly says little about you, but is still unique to you, and lots of organizations can map it to some more personal information about you.
Even store loyalty cards are not a good example as they link to your actual phone number in the US.
(Good luck resetting all your IDFAs at the same time and remembering never to log into any of the same accounts again. Yes, you and I know how to do this and that it can be turned off, but I assure you based on data I've worked with people do not.)
You MUST use apps built by someone else on the App Store and it's almost impossible to pull them apart on your own to check if they use libraries from eg. Facebook.
The whole App Store model extremely anti privacy. I think community maintained package repos like what you see on Linux distributions convinced people that this sort of thing would be an improvement, but what made package repos great was the community, the centralization was only a convenience.
Yes, as long as you are acting under an ID that is tied to your own name, then forget about privacy.
The payment system itself has the same problem, but at least they don't fling private information back at me in unexpected moments, and the information they have is usually limited, and banks are (somehow) held to higher privacy standards.
This is self reported. Many developers probably don't even realize the Facebook SDK they included tracks their users and just looks at what they personally collect.
While its possible (likely apparently?), Apple doesn't verify this information, there is a strong chance they will at some point in the future. And falsifying this is likely a quick way to get booted from the App Store.
I'd like to see a developer that does not know that facebook tracks you after everything that's been in the news. Even my almost 80 year old mother knows that.
I'm not entirely sure what you are talking about here. Facebook has been getting a lot of negative press, mostly about enabling hate groups. I haven't seen a ton of press talking about how including sign in with Facebook leaks tons of information back to Facebook.
Lots of negative FB press, none that I can really think of that focuses on how their APIs drive their information dragnet.
I have to wonder also how much of this gets lost in translation. If you are an Indian developer team, do you realize the implication of including the Facebook API?
If it does network access on your behalf, that would be trickier.
Also, apple should not collect data on behalf of the apps like statistics of any kind (unless you opt-in)
It is entirely possible to not collect data but use network APIs. For example the app I work on uses Mapbox APIs and CloudKit to store data. Transmit needs access to the network to do it's job, which is akin to what you suggest.
It would be very tricky to audit these things. However it should be pretty straight forward to audit for the presence of libraries which are widely known to collect user data which I suspect is on the horizon.
Is that tracking on your end? It is not.
Is that tracking on _their_ end? Neither I nor you have any way to actually know, even if they claim no data gets stored in a way that allows behavioural mining. So claiming there is no tracking is wilfully ignoring the entirely possible case that there might be, even if you personally have no reason to believe there is. Geodata is incredibly fingerprinty.
It does allow offline use, so I should experiment with that. While offline use requires pre-loading tiles which reveals something about a person, it doesn't reveal more than a broad regional interest.
But in general, I agree. It's a murky situation. Any web request leaks information about the user.
An IDFA also collected via any other service / broker provides such a feedback loop. Location data is reasonably valuable. Mapbox also offers a navigation API; this would be behavioral data from which companies like to try to derive interest and intent.
And has been mentioned a few times in the thread - even if one app author goes out of their way to reimplement the API in a privacy-preserving way, all it takes is one that doesn't to reasonably link all the other requests based on other data points. (IP would be more than sufficient - but since it's a location service, even if all the apps run the requests through a proxy, location-at-time and location/destination pairs are also useful to help link.)
In the end I don't think there's anything privacy-conscious app developers can do other than eschew external services as much as possible, clearly inform users when external services are used, and push for stronger regulation (from phone / OS manufacturers and the government) about data privacy.
This is the crux of it here. In particular, we seriously need regulations making the things Apple is pushing required by law, not something a company with its own vested interests pushes.
Particularly since as many point out whenever this is discussed, there is a bit of opacity with regards to Apple's own apps.
Remember that every single request to them includes your device's IP, potentially user agent, and maybe even a unique identifier generated on first run which will correlate all those changing IPs together.
Over time, IPs & user agents can very easily be connected together by a data broker with very high certainty.
This would make it impossible to accidentally or maliciously "forget" to declare a tracker, and working around it would become difficult because it breaks the economics of tracking (you can proxy those through your own backend, but the ad company wouldn't trust this data as it would enable you to do ad fraud very easily).
The is only true for the actual showing of ads; data brokers and bidding services already often work this way. (Hell, some data brokers are nothing more than an Excel dump of their internal usage table they'll mail you for a fee.)
Cloudflare is pretty much the only DNS resolver that doesn't provide the source user's IP address when doing recursive requests.
Archive.is is pretty much the only (big) website that refuses to answer DNS requests at all if they don't include the source IP address.
Cloudflare argues that this improves privacy (nevermind that the user's IP shows up anyway as soon as they try to actually connect). Archive.is argues that this prevents them from doing geographic load balancing (which, as it turns out, just happens to be a separate product that Cloudflare is happy to sell to websites).
archive.is blames Cloudflare, but in reality it's easy to verify that archive.is's nameservers are returning different IP addresses depending on the network you're coming in from. This is clearly broken on their end.
Cloudflare literally can't fix this. archive.is is 100% responsible.
Yes, this is the whole point of (this part of) EDNS. It allows you to direct the traffic to a server close to the end user (geographically or based on peering preferences).
> This is clearly broken on their end.
There are two broken things here:
1. Cloudflare doesn't send the source IP with the DNS request
2. Archive.is would rather not respond to broken requests at all than make a best-effort with a degraded experience
Considering that Cloudflare is pretty much the only public DNS server with this problem, and the only motivation seems to be that it competes with their CDN product, I'm far more sympathetic to Archive.is than to Cloudflare.
> Cloudflare literally can't fix this. archive.is is 100% responsible.
Only Cloudflare can fix this properly. Archive.is can work around it (at the cost of degraded performance), but I can understand why they would want to stand their ground.
Yes, because (as they've stated elsewhere) EDNS subnet information leaks information about a requester's IP.
> Archive.is would rather not respond to broken requests at all than make a best-effort with a degraded experience
Broken responses = the most degraded experience.
Is there any other website that just fails when they aren't handed EDNS subnet information? I've never experienced any.
The requester's IP leaks anyway as soon as they actually try to connect.
Heh. Ok.