Live data from Hacker News

Does Apple really log every app you run? A technical look

blog.jacopo.io

221–230 of 355 posts

Re: Does Apple really log every app you run? A technical look

#221
post #56

Earlier quoted context omitted.

A better privacy solution would be to sync revocation lists every so often (and, if you must, right before opening a new app). Is there any privacy-preserving reason to not go this direction? How often would you expect certificates to be rescinded? You could also use a bloom filter to significantly reduce the false-positive rate.

Or something akin to OCSP stapling, which has been mentioned in a few places?

Stapling makes sense for the Web but not here.

With OCSP Stapling the remote web server whose identity you want to assure yourself of periodically gets an up-to-date OCSP answer about its own certificate. When you connect to that server, it gives you the certificate, and the OCSP answer, which assures you that the certificate is still good, and is signed by the Issuer of the certificate.

So, you visit Porn Hub, Porn Hub knows you visited and can reasonably guess it's because you like porn (duh). Porn Hub talks to their CA. The CA knows Porn Hub are Porn Hub and could reasonably guess it's a porn site (duh) but this way the CA doesn't learn that you visited Porn Hub. That's Privacy preserving. Nobody learns anything you'd reasonably expect they shouldn't know.

But how can we apply that to an application on your Mac? If every app reaches out from your Mac to Apple to get OCSP responses, they learn what you have installed, albeit I guess you can avoid telling them when exactly you ran it. This is enormously more costly and not very privacy preserving.

CRL-based ideas are much better for your privacy, although they might cost you some network traffic when the CRL is updated.

Of course one reason for Apple not to want to do CRLs is that they're transparent and Apple is not a very transparent type of company. With OCSP you've got no way to know if and when Apple revoked the certificate for "Obvious Malware II the sequel" or equally for "Very Popular App that Apple says violated an obscure sub-clause of a developer agreement".

But with CRLs it'd be easier for any researcher to monitor periodically for revocations, giving insights that Apple might not like. Do revocations happen only 9-5 Mon-Fri Cupertino time? Are there dozens per hour? Per day? Per Year?

Re: Does Apple really log every app you run? A technical look

#222

Earlier quoted context omitted.

Most "alarmist" articles have two points you cannot really ignore, not if you don't want to end up living in interesting times one day. 1) Even plain access logs — basically what a HTTP request, or a TCP connection can tell you — is a lot . Gather those for a couple of days, and you have a good map of the user. More so if you have an ID of machine and the actual executable hash. 2) "But we are the good guys" is a non…

> "But we are the good guys" is a non-defense. Good guys can turn bad, they can be coerced by the bad guys, That’s true, but not very useful, since if Apple turns bad or is coerced by the bad guys, they could just issue an OS update that begins doing new bad things anyway.

A couple of problems:

- This give Apple access to data right now. If they turn evil in the future, they have access to data from the past, which gives them more leverage.

- The security industry (overall) pays attention to Apple updates. If Apple turned evil in the future by issuing an OS update, someone might notice it happening. But if they start organizing this data and handing it off to the government, they don't need to change anything public or issue an update. They can do it all serverside without anybody noticing.

- One of the ways we tell whether a company is trending evil is that we pay attention to how its willingness to invade people's privacy evolves over time. This is a more subtle point.

Imagine that I was administering your phone. There's trust involved in that kind of relationship; if I turned evil, I could install some tracking software or viruses and violate your privacy. So imagine that one day you find out I have installed tracking software on your phone, but when you ask me about it, I say, "it doesn't matter whether or not the tracking software is installed on the phone. If you trust me not to invade your privacy, then you might as well trust me not to look at the data the software is collecting. As long as you trust me, it makes no difference what I install on your phone, since you can trust me not to use that software to violate your privacy."

You probably wouldn't be satisfied by that excuse. In reality, seeing that I am now the type of person who is willing to install tracking software on your phone should give a suspicion that I have either already turned evil or that I am on my way to turning evil.

So similarly with Apple, it's true that trusting Apple means putting them in a position where they could start collecting people's private data. The fact that we have now seen them start collecting private data means that we should be more suspicious that Apple either is already evil, or at least that it is more willing now to play with evil ideas than it used to be.

Re: Does Apple really log every app you run? A technical look

#223

Earlier quoted context omitted.

IMO especially when stock holders wanting a monetary return on investment are involved. I give my money to the FSF every month, because they provide value to me, but not because I expect them to surreptitiously extract it from others and give it to me as cash dividends.

I think that's one of the big problems with public companies, especially those that have "regular people" as their main money maker (the "consumers") - invariably, the company's needs (duty) to make money for their real customers (the shareholders) will take precedence over what would be "the best thing" for consumers. I wish we could do away with the whole "public company" thing - just imagine how much better Facebo…

private companies are still accountable to their shareholders. But I do think that the very public number of share price encourages slightly different behavior than a private, illiquid, and probably out of date number

Re: Does Apple really log every app you run? A technical look

#224
post #193

Earlier quoted context omitted.

> [article] editing your /etc/hosts file. Personally, I wouldn’t suggest doing that as it prevents an important security feature from working. Exactly the apologetic that you are talking about. Everyone has a different security update cadence (e.g. patch Tuesday for Microsoft), but each application launch is not a reasonable one. Given Apple's recent propensity for banning developers who stand against them (whether y…

I don’t see how you can so confidently reach that conclusion. It seems perfectly plausible that Apple wants a way to quickly quash malware, worms, etc.

> I don’t see how you can so confidently reach that conclusion.

I'm not going to 100% say that control is the reason Apple is doing this. I'm sure that they do genuinely want a way to quickly quash malware, worms, etc...

But we've also seen that Apple is clearly willing to use security features to ban developers that stand against them, so I don't understand how people can be so confident that they wouldn't be willing to use this feature in the same way, even if they did internally think of it as primarily a security tool. It would be very consistent to how we've seen app signing evolve from a pure security feature into a contract-enforcement tool.

Re: Does Apple really log every app you run? A technical look

#225
Technically AFAIK, the revocation list could be turned into a Bloom filter (or one of its alternatives) and updated from the servers periodically.

edit: on 2nd thought just a list of hashed cert ids could suffice because it is hard to imagine there ever being thousands of revocations.

That way the provider would have no knowledge of which certs are being verified.

Re: Does Apple really log every app you run? A technical look

#226
post #204
post #199

Earlier quoted context omitted.

https://www.zdnet.com/article/apple-update-kills-off-zoom-we... This was a seriously exploitable issue that was a problem every time it was run. I agree that this certificate mechanism is absurdly problematic. That doesn’t justify dismissing the security risks it was intended to prevent.

Zoom isn't malware, Apple did not revoke Zoom's Developer ID certificate, and indeed Zoom still exists on the Mac. Zoom had a serious uninstaller bug, but that's all it was, and it's not relevant to the current discussion.

Incorrect - zoom exposed a serious vulnerability, and Apple shut it down, using another mechanism but nonetheless the same effect.

It’s relevant because you argue that there is no value to having the ability to do this.

It is also a problem which occurred every time the app was launched. Something you have dismissed as a non problem.

https://www.theverge.com/2019/7/10/20689644/apple-zoom-web-s...

Re: Does Apple really log every app you run? A technical look

#227

Not sure whether the non-privacy related aspect about OCSP is less worrying. Officially Apple does this to protect innocent users from malware, but as we've seen it also allows them to remotely disable any developers' software. Not really something that I'd want on my machine.

OCSP also allows CAs to revoke random websites’ certificates, yet nobody is making a big fuss about that (presumably because no OCSP server has encountered what Apple’s did and prevented websites from opening).

Your reasoning is wrong.

Other than Internet Explorer (and maybe Edge? I honestly have no idea) browsers don't do OCSP. This is because it's a huge privacy problem (as we saw here for Apple) and because the OCSP servers have too often been unreliable.

Firefox has OCSP Must Staple, but in that scenario the remote web server is responsible for periodically ensuring it has a sufficiently up-to-date OCSP response about its own certificate which it then "staples" to the certificate to prove its identity. So if the OCSP server fails for an hour a good quality stapling implementation just keeps using older responses until it comes back. Also it's optional, most people haven't chosen to set Must Staple anyway.

Everybody else has various CRL-based strategies, so your browser learns about certain important revocations, eventually, but it doesn't pro-actively check for them on every connection and thus destroy your privacy.

Re: Does Apple really log every app you run? A technical look

#228

By default, Android logs every app you use. You have to disable - bafflingly - features including saving locations in Google Maps and fully-functional voice recognition to (supposedly) disable that behavior. What I'm saying is: don't look so surprised.

You seem to be confusing sharing "usage and diagnostics" with enabling location history.

Re: Does Apple really log every app you run? A technical look

#229
post #4

Earlier quoted context omitted.

A low effort comment. Doubly bad, because the actual post is about how Apple doesn't actually do the "tracks your every use of an app" peeping they original post that made all the fuss says they do.

Learn about Big Sur(veillance). You can't block telemetry and it bypasses any VPN.

I've learnt about it. I've also commented about it in other threads here.

Re: Does Apple really log every app you run? A technical look

#230

Has anyone used a pi-hole to block apple privileged servers, like the OCSP one, while running Big Sur? I'm thinking of setting one up---not necessarily to block OCSP, because the points in this post about actually wanting to know when a certificate has been revoked are sensible---but to at least have the option in case of another disaster... Relatedly, does anyone know if Big Sur allows one to use a custom DNS server…

Vendors are already baking in DoH into their apps and systems, and that entirely bypass your DNS servers altogether. I went from blocking about 45% of my entire network's traffic at the DNS level two years ago, to only blocking 10% of the traffic today.

But how are those apps finding the DoH server's IP then?

If they use public DoH servers you could just block those at the network level. Andv if they're running their own DoH service on a fixed IP, they could simply run the app itself over that IP and avoid the whole DNS lookup altogether.

Post reply on HN