[HN Gopher] I checked Apple's new privacy 'nutrition labels.' Ma...
___________________________________________________________________
I checked Apple's new privacy 'nutrition labels.' Many were false
Author : bookofjoe
Score : 69 points
Date : 2021-01-30 14:59 UTC (8 hours ago)
(HTM) web link (www.washingtonpost.com)
(TXT) w3m dump (www.washingtonpost.com)
| swiley wrote:
| IMO: nothing on the app store is private.
|
| 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.
| amelius wrote:
| > IMO: nothing on the app store is private.
|
| 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.
| sys_64738 wrote:
| I don't install any apps on my iPhone so how am I affected?
| fingerlocks wrote:
| > One thing we looked for is evidence of apps sending my phone's
| unique ID, known as its Apple IDFA. That's the keys to the
| kingdom for companies that want to track you -- nearly as
| important as your name or Social Security number -- allowing them
| to connect up data they get from one app with lots of other
| sources.
|
| 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.
| morelisp wrote:
| As soon as one company (trivially) links your account with them
| to your IDFA it is no longer anonymous. In the data broker
| world IDFAs are second only to hashed email addresses in value.
|
| 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.
| sologoub wrote:
| Have you tried resetting either your SSN or email address?
| While the OPs' argument is technical in nature, a better
| comparison would be your frequent flyer number. You can
| register for a new frequent flyer relatively easily, but IDFA
| can be reset at will or turned off completely. Good luck
| turning off your SSN or any government issued ID.
|
| Even store loyalty cards are not a good example as they link
| to your actual phone number in the US.
| rootsudo wrote:
| "It has become extremely common for app makers to embed code
| called software development kits (SDKs) in apps that sends your
| data to other companies."
|
| Heh. Ok.
| m463 wrote:
| I think if an app claims "no data collected", it should have no
| network access, or access to apis like apple identifier.
|
| 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)
| ogre_codes wrote:
| > I think if an app claims "no data collected", it should have
| no network access, or access to apis like apple identifier.
|
| 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.
| TheRealPomax wrote:
| It uses Mapbox APIs you say? Then good news: you're reporting
| geoquery data for your users to them simply by using their
| API, with that API by definition being in service of
| someone's behavioural pattern.
|
| 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.
| ogre_codes wrote:
| Without some sort of feedback loop, its going to be
| difficult for Mapbox to cash in on my users data. It's not
| tied to an endpoint where they can sell advertising, nor is
| any of my use real-time.
|
| 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.
| ogre_codes wrote:
| These labels aren't provided by Apple so the very first sentence
| is nonsense.
|
| 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.
| tyfon wrote:
| > Many developers probably don't even realize the Facebook SDK
| they included tracks their users and just looks at what they
| personally collect.
|
| 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.
| bobthepanda wrote:
| Given the fiasco that was the Senate hearing I would be very
| unsurprised.
| bookofjoe wrote:
| https://archive.vn/Ubh2d
| djxfade wrote:
| Link is dead
| [deleted]
| meibo wrote:
| You can't open archive.is links with Cloudflare DNS since the
| owner of the service thinks that they are ruining the
| internet.
| eurg wrote:
| Thanks for the explanation. I don't really understand why
| this service owner wants me rather using my censored ISP
| provided DNS, or Google's, but I'm sure they have a good
| reason.
| Nullabillity wrote:
| It's not so much those two in particular, as it is
| _anything but Cloudflare_ (for reasons I 've already gone
| through elsewhere[0][1]). Running your own resolver would
| also work fine.
|
| [0]: https://news.ycombinator.com/item?id=25973190
|
| [1]: https://news.ycombinator.com/item?id=25973145
| 6gvONxR4sf7o wrote:
| Cloudflare is doing this to archive or archive is doing
| this to cloudflare users?
| Nullabillity wrote:
| They're doing it to each other.
|
| 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).
| CharlesW wrote:
| > _You can 't open archive.is links with Cloudflare DNS
| since the owner of the service thinks that they are ruining
| the internet._
|
| 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.
| Nullabillity wrote:
| > 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.
|
| 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.
___________________________________________________________________
(page generated 2021-01-30 23:02 UTC)