Does Apple really log every app you run? A technical look(blog.jacopo.io) |
Does Apple really log every app you run? A technical look(blog.jacopo.io) |
OCSP is a good thing, and the web - and your signed applications - are better off with it.
Active OCSP is far from being considered a good thing universally.
Spoiler alert, you've probably already used OCSP on the web.
It's worth noting a couple differences between HTTPS OCSP and Developer ID OCSP. First, with Developer ID, the only DNS request is for ocsp.apple.com, so the DNS request by itself doesn't expose any information about the Mac app being launched, unlike with HTTPS.
Second, the caching of Developer ID OCSP responses tends to be much much shorter than for HTTPS. Prior to Thursday's outage, the standard cache length for Developer ID OCSP responses seemed to be 5 minutes. (Apple seems to have raised it to 12 hours now.) In contrast, I just checked the latest response in my OCSP cache, which was for http://ocsp.digicert.com, and its validity is 7 days. So the rate at which Developer ID OCSP requests are made seems to be much higher than for HTTPS, and thus there's greater chance of exposure.
That’s why CT came around.
Some background for those unfamiliar.
It logs app certificate requests which in real life is pretty much equivalent to logging app runs. And that line about only calling the server from time to time is bullcrap. I have years of experience on this issue because my internet is pretty shitty. And that "from time to time" is every couple of hours.
You know, before declaring the end of the world, is there any information from the source (Apple)? Discussions here seem to have had several thousand comments without obtaining this basic info. It would be good to know, I would think?
I write a lot of Go on my Mac at home. The first run is _always_ slow, but I've never measured it or bothered to find out why. This is a real "lightbulb moment" for me.
I just built a Go executable and timed it: 0.194 for the first, and ~0.018 for subsequent. I haven't signed code on Mac platforms before, so I figured I'd give it a go using the Apple code signing guide [0]. So, I created a self-signed certificate using Keychain, changed and built a Go project, signed the executable [1], and ran it: ~0.400 for the first run, and ~0.018 for subsequent. It... doubled? Will this happen on every first run still? Is there a way to exclude executables?
[0] https://developer.apple.com/library/archive/documentation/Se...
[1] codesign -s <cert_id> <path>
Periodically there would be an issue downloading the updates. Would result in similar problems.
Managing size of updates was a big issue. Just checking against an online server is certainly a more up to date approach
It’s a good thing to do regardless. I also know way more than I want to about Windows, too, and could make do if given only that for a workweek.
Learn languages, learn OSes, learn architectures. Get more computers. :)
I made the switch and I'm not looking back.
Why not take a more privacy-centric approach? Antivirus companies have been working with “virus definitions” for ages. Ad blockers use the same model, but for locally stored blacklists. Why can Apple not regularly download a list of revoked certificates and maintain it locally?
"You should be aware that macOS might transmit some opaque information..."
Why don't the author post the OCSP request of Thunderbird too? And how about another request for Firefox so we can compare the data? This article really doesn't clear anything up for me...
This would explain why some games take minutes to launch the first time to run them. I've experienced this many times with Steam. You install a game, you launch it, and nothing happens for up to several minutes, and then the game runs. No delays after in launching after that.
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.
Also i don't get the argument for using HTTP. Aren't these two separate systems?
How does one go about setting up (easy) server of some sort to see what servers are being connected say when investigating a different area?
They backpedaled a little bit when you were forced to log in through a Microsoft account and people semi-rioted but came back pretty strong.
https://medium.com/@alexeysamoshkin/how-ssl-certificate-revo...
Although OCSP stapling is used more now IIRC.
HN doesn’t set OCSP must staple so we’re still a while away from being able to trust it.
* There is no information on how often the validation happens. All this investigation concludes is that it doesn't happen when closing and immediately re-opening an app. Is it every week? Every reboot? Every hour? If it's less, that's essentially the same as doing it on every launch.
* There is no justification for sending this information in cleartext. I don't follow the "browsers and loops" argument. This is a system-service that only has to trust a special Apple certificate, which can be distributed via other side-channels.
* Many developers only publish a single app or a certain type of app. So it still is a significant information leak. It's really not much different from sending a app-specific hash. Think: remote therapy/healthcare apps, pornographic games, or Tor - which alone could get you into big trouble or on a watchlist in certain regions.
I assume they will push a fix with better timeouts and availability detection.
But Apple simply has to find a more privacy-aware system designs for this problem which does not leak this kind of data without an opt-in and also does not impact application startup times. (revocation lists?)
I imagine this data might just be too attractive not to have. Such a "lazy" design is hard to imagine coming out of Apple otherwise.
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-defense. Good guys can turn bad, they can be coerced by the bad guys, and
3) since the requests fly out in plain text, there is an unknown number of questionably-aligned guys in between capable of sniff your data. You only need one bad enough guy to get into serious trouble if that's what they want.
This is not alarmist. It's just common sense. The same common sense that you use to avoid certain neighborhoods at certain times of night.
At that point, what’s to prevent you from providing unacceptably slow service for the certs of those apps you don’t like and soft-locking the user out of particular apps on their own device?
Also, this is what every bad guy believed him or herself to be throughout the history of humanity.
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.
I wrote a blog post about this. My analysis indicates that Developer ID OCSP responses were previously cached for 5 minutes, but Apple changed it to half a day after Thursday's outage, probably to reduce traffic:
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 you agree with those developers or not), this is aimed squarely at dissent.
It’s not each application launch. It’s from time to time. It’s for each application as it might be detected to have malware in the future. Also if the app isn’t signed there is no check.
There is no justification not to switch to HTTPS here.
Now in this specific instance, OCSP is being used in quite a different use case. For one, the plaintext issue is not a problem when browsing, as attackers can see what sites/certs you're accessing in the clear anyway (certificates are plaintext in TLS sessions), while app launch is an otherwise offline activity. So in this instance it makes sense for Apple to switch to HTTPS (and if they have OCSP on the server cert for that, that should go via HTTP to avoid loops or further issues).
But what Apple did here is just standard practice, it's just that there happen to be good reasons to diverge from the standard here.
How to we know the certificate presented by the OSCP server has not been revoked? We can’t ask the OSCP server cos that’s what we’re trying to handshake with!
The loop is very real and non trivial to solve. I’d expect something similar to what ESNI/ECH does leveraging DNSSEC + DoH may be possible NOW, but that’s a recent development.
Even if there was some wrinkle about the loop argument that I didn't understand, and HTTPS is out: Apple could encrypt the base64 payload, and the sniffable info is reduced to which computer is phoning home, which is something that someone with the ability to middle comms probably knows already.
"roll your own encryption and send it over HTTP" is a bad idea in general but... this is Apple, they can and do implement encryption. Why not here?
Even doing unauthenticated TLS is better than what they do now, because the current situation allows for full passive monitoring.
[1]: https://blog.cloudflare.com/validating-leaked-passwords-with...
That's my biggest issue personally. There's a bit of information leak, but most wouldn't care and would just do the standard and be done with it. Firefox still uses OCSP in some case...
My issue is that a company like Apple, which currently market itself as a company that care about privacy of their user, would have let this comes out of that same process that's supposed to care... and still hasn't said that was a mistake out of their process and that they are correcting it.
They could easily use k-anonymity like HaveIBeenPwned, or even as push, which would means no cache, which is even better for their argument of security.
There's nothing alarmist here, it's all alright, it would just means that this is the same false advertising that so many companies do, but still, is important to be aware of.
Call home features can be spoofed by a poisoning type of attack upstream in various forms.
This is not bullet proof and a cop-out with a poor solution for security.
You know who has effective call home features? Vendors that sell to major enterprises. It is a natural progression and a particularly nasty environment to live within.
If they are legitimately trying to protect the brand through force or merely forcefully controlling the app ecosystem... it's an abusive relationship to be in.
The fact this is not configurable without dead lettering the route is all they need to do to show tethering is something they consider as a viable security measure.
I'll pass.
The idea that you need apple to certify the developer over the software you run on your phone is nonsense though. You don't do that on your computer, so why do you need to be nannied on your phone?
Potentially it could now be tackled with DNSSEC + DoH similar to the records ESNI/ECH puts in the DNS to encrypt initial HTTPS client hellos.
But the loop issue is quite real. How can you validate the certificate the OSCP server gives you has not been revoked, using OSCP???
I'm not surprised. Apple fanatics routinely deny evidence to support their sorta-religion.
As do anti-Apple fanatics. That’s what being a “fanatic” means. You can say the same about gun fanatics, or meat fanatics, or vegetarian fanatics, or Android fanatics. It’s staggering how often people who are anti something fail to perceive the irony in behaving exactly in the manner they are decrying. Someone having a contrary opinion doesn’t make them a fanatic.
To log in to my banking account, I need the correct password. No problem, I keep it in a password manager. To open the password manager, I need the correct password. No problem, I keep it in a password manager. To open the password manager, I need the correct password. No problem, I keep it in a password manager. To open the password manager, I need the correct password. No problem, I keep it in a password manager. And so on.
Imagine that, but for “verifying the HTTPS connection”.
Technically what I’m describing is that you can vary the behaviour of OCSP lookups such that if you’re already looking up an OCSP certificate to establish an SSL connection to an OCSP server, downgrade and check over HTTP only when trying to connect to the OCSP server itself. Yes, it would mean one more TLS connection to a random server. Yes, it would mean an extra OCSP lookup. But just one, and just for the OCSP server itself. Which means privacy is preserved in regards to which developer certificate you’re checking. It would be only checking Apple’s OCSP server certificate in the clear, which it could equally cache easily.
You can DH with an untrusted cert. It might be interceptable.
HTTP is always interceptable.
But there should be zero reason not to set this connection up with a full proper cert. HTTP is just mega sloppy.
As others mentioned, you can bootstrap TLS by first checking OCSP (in the open) on your cert auth service, then use that opaque, freshly-checked connection to check the rest.
Is it not common knowledge how telemetry works for the operating systems? They generally batch up a bunch of logs like this, encrypt them, compress them, and then send them to the mothership (hopefully when you're on WiFi).
And no, it's not widely known or documented - there is no good description of what telemetry exists or contains on iOS that I know of.
Yes, and no. If you're using software that the state deems to be subversive or "dangerous", a developer certificate would make the nature of the software you are running pretty clear. They don't have to know exactly which program you're running, but just enough information to put you on a list.
> You shouldn’t probably block ocsp.apple.com with Little Snitch or in your hosts file.
I never asked them to do that in the first place, so I'll be blocking it from now on.
Apple's working on making sure you can't block it. They already keep you from blocking their own traffic with Little Snitch and similar tools: https://news.ycombinator.com/item?id=24838816
* Your Mac periodically sends plain text information about the developer of all apps you open, which in most cases makes it trivial for anyone able to listen to your traffic to figure out what apps you open. Better not use a Mac if you're a journalist working out of an oppressive country.
* Because of this Macs can be sluggish opening random applications.
* A Mac is not a general purpose computing device anymore. It's a device meant for running Apple sanctioned applications, much like a smartphone. Which may be fine, depends on the use case.
Yeah... No Mac for me anytime soon then.
Wow, that is bad from a privacy perspective!
Since certificate revocation is rare, it makes more sense to simply periodically update a list of revoked certificates instead of repeatedly checking each certificate. That would solve the privacy issue while still allowing certificates to be revoked.
OCSP seems like a bad idea for web browsing for similar reasons.
Replace "Apple" with "Google", "Facebook", "Verizon". Re-read the article. If it sounds horrifying, then it's also horrifying if Apple does it. There's no such thing as "trust" into a single corporation - especially the one which just argued that you not paying 30% to them is "theft".
Applying this test helps weed out the marketing bias these corpos constantly try to push at you.
To me, it sounds like they decided to take the quick-and-easy path of reusing an existing protocol for the use case of stopping malware, but it doesn't really fit. The latency, privacy, and availability guarantees of OCSP just don't match with the requirements for "run a local application".
Stapling and crl-shipped-with-browser still works.
If that's happening, they need to put more work up front into certifying them in the first place.
In the example from the article: if Mozilla's certificate is sent, then it's very likely that the app that has been opened is Firefox, as the a priori likelihood of using Firefox is way higher than eg using Thunderbird.
If the developer is Telegram LLC, then ... and so on.
And just by looking ip address, and app usage and other data they receive they can connect the data and identify its me. And what security has apple provided till now?
"You shouldn’t probably block ocsp.apple.com with Little Snitch or in your hosts file."
That's far better than freezing computer which doesn't work, doesn't run any apps. If I don't need apple mercy and protection please don't force me.
Already installed Linux and its a start.
This is the reason people laugh at this website.
I wonder how big a local revocation list would be. I would support a on-by-default local check.
http://ocsp.apple.com/ocsp-devid01 is Developer ID, but http://ocsp.apple.com/ocsp03-apevsrsa2g101 is something else, which if blocked can prevent the Mac App Store from loading.
Relatedly, does anyone know if Big Sur allows one to use a custom DNS server on the device level with those privileged destinations? (He says, mulling the complexities of getting a pi-hole working with his mesh system.)
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.
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.
It wasn’t a misunderstanding, it was a simplification so that people could understand the issue without me explaining OCSP and app signing and x509 and the PKI. Dozens of people wrote me to thank me for explaining it in a way that they could understand.
It is indeed a hash, and it does indeed uniquely identify most apps, and it is indeed sent in plaintext, when you launch the app (and is cached for a half day IIRC). I very deliberately didn’t claim it is a hash of the content of the app file.
It also doesn’t send a unique identifier, but I would be willing to wager that the set of apps that you launch in 48h is probably enough to uniquely identify your machine in the vast majority of cases.
Uninformed advice - apple prevents little snitch from blocking this traffic in big sur.
>If you use macOS Big Sur, blocking OCSP might not be as trivial.
> Uninformed advice - apple prevents little snitch from blocking this traffic in big sur.
You can prevent Apple from preventing Little Snitch from blocking that traffic: https://tinyapps.org/blog/202010210700_whose_computer_is_it....
Then unencrypted requests are also a Bad Thing, because anyone has access to the same info - it may require a lot of work to get general knowledge of what apps someone is using, but if you were looking for a specific one then I don't see any real difficulty identifying that.
e.g. if I wanted to know if someone was using signal I just look for the signal cert being queried. That's a much easier problem, and can be dangerous to the end user.
Question, is there a good justification to use not use hierachical certificates like web browsers or other OSes ?
Apple does not prioritize privacy. Apple does not prioritize availability.
sudo defaults write /Library/Preferences/com.apple.security.revocation.plist OCSPStyle None
sudo defaults write com.apple.security.revocation.plist OCSPStyle NoneIf there's a hit, a subsequent request can be sent to Apple to verify the same - reducing the impact.
According to Wikipedia "[OCSP stapling] allows the presenter of a certificate to bear the resource cost involved in providing Online Certificate Status Protocol (OCSP) responses by appending ("stapling") a time-stamped OCSP response signed by the CA to the initial TLS handshake, eliminating the need for clients to contact the CA, with the aim of improving both security and performance."
I'm not aware how widely deployed OCSP stapling is in reality. I looked at my Firefox settings which seemed to be the default for OCSP and it looked like this:
security.OCSP.enabled 1
security.OCSP.require false
security.OCSP.timeoutMilliseconds.hard 10000
security.OCSP.timeoutMilliseconds.soft 2000
security.ssl.enable_ocsp_must_staple true
security.ssl.enable_ocsp_stapling true
I also don't know what other TLS implementations (like OpenSSL) do and how users of such libraries usually configure them.
Addendum: Oh and of course, OCSP stapling is useless when you weren't about to open a TLS connection (like in this case when checking software signing certificates). I'm also curious if and how this works for other applications of X.509 certificates such as mutual TLS authentication.
This is bad for users that download apps to solve problems, or to get work done, because then they can't those apps without having an expert tell them what the magic ritual to run un-Notarized apps is. If they don't have an expert around to show them how to perform the magic ritual, then they just think the apps are broken.
They just keep making stuff not private so you have to choose between security versus privacy.
A well thought system would be able to provide both.
Phoned signing verification is another thing that is a precursor to distribution to Apple-only distribution.
Yeah, what's up with that, having to buy a Mac just to run XCode! And having to register as a developer to get a certificate.
Apple should bring back Lisas and the UCSD Pascal/Clascal for Mac development like it was in the 1980s. And they should also bring back 4-letter developer signatures. ;-)
I mean I guess I already know the answer, "marketing". "Look, macOS doesn't require antivirus!"
Personally I don't want Apple verifying or revoking anything. I bought the computer, it's mine. You don't get to tell me what I can run, period. Inform me, sure, give me links to go learn why you don't want me to run something, sure. Don't prevent me from choosing to do with my machine what I want.
Enumerating “all possible badness” is basically impossible, which is why AV software really doesn’t work. Every ransomware attack you read about in the news bypassed up-to-date AV software.
Enumerating “known-good” entities is actually a tractable problem... this is what vendor-signing does. Even Google and Microsoft understand this and have had code-signing infrastructure in place for decades.
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.
I don't really see a problem here how that could cause a loop. This way, an attacker can only see:
- When you boot your Mac because it verifies the HTTPs certificate once.
- When the OSCP daemon makes a clear text request to check that the HTTPs cert is still ok
- That you have just opened an application (but not which application)
IMO that still leaks an unacceptable amount of meta data but it is miles better then using cleartext. Maybe a bloom filter here would be a much better solution + make the daemon regularly fetch bad signature that are not added the the filter yet instead of pulling. Sure the filter may hit false positives sometimes but in that case, the OSCP server could be checked and apple could see if a certificate has a high rate of false positives and adjust the bloom filter accordingly.
I don't know, I haven't dug deep enough to find the answer for myself.
However, after blocking Google's DNS servers on my network and designating my own DNS servers via DHCP, my Chromecast ceased to function, and certain Android apps that serve ads had functionality that ceased to work correctly. That leads me to believe that apps and systems with DoH baked in are actively hostile to mitigations against their DoH implementations.
https://tinyapps.org/blog/202010210700_whose_computer_is_it....
Want to point out that certs are encrypted with TLS1.3, and DNSSEC+DoT/DoH makes ESNI/ECH possible by putting keys in the DNS.
Ultimately maybe OSCP could do something similar, or fall back to DANE or some alternate validation method that wouldn’t cause a “loop.”
Reality is a little different of course, and compression can cause problems for encryption because compressed data tends to be highly predictable (especially things like compression headers and compression dictionaries). This allows for potential “known/chosen plaintext” attacks on the encryption.
Some classic examples of this type of attack are breaking Enigma (known plaintext, no compression) by assuming the content of some messages[0] and the more recent CRIME[1] attacks against TLS using compression to help produce a chosen plaintext.
The simple solution in these scenarios is to avoid using compression completely.
[0] https://www.quora.com/Did-the-inclusion-of-Heil-Hitler-at-th... [1] https://en.m.wikipedia.org/wiki/CRIME
It's sensible to require waiting for a certificate check the first time an app is launched, but after that, the cache validity should be indefinite, and updates should occur asynchronously in batches.
The timeout settings were also excessive.
Can't forget the blatant lack of encryption. They either forgot or thought it would be too much effort to set up.
The difference in my mind is that no console markets itself as a general computing device, and the user understands they can't use it as such (you can't install whatever you want on an xbox).
Apple could encrypt the payload though, using the Apple public key, which would solve the snooping by intermediaries problem.
TLS encrypts the payload just fine if you want that. That’s what TLS is for.
PS: You don’t encrypt something to someone else using your own public key.
You probably can't update the whole list that often though, compared to Apple's current OCSP revalidate time of 5 min. [edit: seems "delta patches" are supported by crlite so maybe that can work too]
Given that Apple currently doesn't even encrypt the requests during transit, I think they just didn't pay much attention to the problem, which I think the main reason is why they haven't adopted it yet. As for the number of revoked certificates, I'm not sure it's larger than the number of revoked TLS certificates, given that there are way more websites out there than there are registered apple developers.
There is no valid reason that the full information needs to be sent to the server to implement this kind of protection IMO
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?
Apple knows this. They have cryptography experts.
Taken in context with their backdooring of their e2e messenger and collaboration with military intelligence on FISA 702, I tend not to give them the benefit of the doubt any longer. Apple knows how to take pcaps.
There are only so many times the OS design gets to leak either keys or plaintext remotely before you need to stop assuming ignorance over malice.
I don’t know how many times that is, but it’s less than ten, probably less than 5, and because it’s a count of legitimate “assume ignorance”, then “goto fail”[2] also counts in the tally.
Between this OCSP plaintext telemetry leak, and iMessage default key escrow, scrapping their plan for e2e backups at the behest of the FBI that fixes the key escrow backdoor[3], and “goto fail” not authenticating TLS, we’re at 4.
I’m not even counting the recent story about Apple’s history of willing collaboration with intelligence agencies to make a custom classified firmware for the iPod to aid in espionage.[1]
As Goldfinger’s famous saying goes: “Once is happenstance. Twice is coincidence. The third time it’s enemy action.”
[1]: https://news.ycombinator.com/item?id=24212520
[2]: https://www.zdnet.com/article/apples-goto-fail-tells-us-noth...
[3]: https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...
What would this ‘count’ as?
- 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.
They wouldn't need to install anything new on your computer to start tracking you in more detail or building a user profile on you, they could just start doing it invisibly behind the scenes on a server someplace. That's a big deal, because even though you're trusting them to administer your device, if they did start pushing out spyware, there's a good chance a security researcher would notice it. But there's no way for us to know what Apple does with this data once it leaves our devices.
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.
My point stands, Apple introduced a security feature then used it for contract enforcement against a company that opposed them. There is no reason to believe that they wouldn't do the same thing here. Whether or not you believe that Epic was the villain in that story is irrelevant to the current conversation.
Sure, Apple was completely in the right to stop distributing Epic software after they breached their contract with Apple. But Epic didn't breach any contract with their users, so there was no reason to remove Epic's software from user devices, or affect companies redistributing Epic software. Those are obvious overreach.
Epic lied about the content of their software. If Apple doesn’t remove software from suppliers who lie about the contents, people will continue to exploit this.
There was no overreach. This was the consequence of Epic intentionally lying about the content a software update.
It’s also worth pointing out that Epic expected this result, and caused it on purpose. Both Apple, and the court gave them the chance to rectify the situation which they refused.
That makes Epic responsible for the outcome. No one else.
Again, I fully agree that Epic was knowingly in breach of their contract with Apple, and wanted to use the public as leverage. But that doesn't, in any way, make their update malicious for the end user.
As for developers... I mean, how much of a big deal is it, really? I looked at the documentation and it didn't seem like a huge hassle. It even looks like it is automatable in your CI/CD processes via `altool` and `stapler`.
I do imagine that some people would go for that bargain, but it strikes me as short-sighted.
Besides, you can still run non-notarized binaries if you want to. The UI does make it difficult, but not impossible.
If you want a totally open computer, that's fine (to the extent you don’t spread it via negligence), but everything has tradeoffs. If you're comfortable with the risk of malware, that's also fine; but not everyone is -- and certainly not the business world.
Negative responses are typically cached for short periods of time. Can you imagine if people cached NXDOMAIN for half a day and someone creating a record had to wait 12 hours for it to go live because someone queried it?
This is how antiviruses have always worked, without affecting user privacy (of course, most antiviruses also did other things that DID affect user privacy, but malware detection at least worked perfectly fine without it).
But if you have a cached OCSP response for the cert of a malware author, then you've already launched their app, so it's probably too late.
Settings > WIFI > Proxy
As for whether the update was malicious for the end user, we could say we trust epic to operate a payment method, and therefore the update was not malicious.
But there are many actors who would use this exact same methodology, and the update is malicious. Such Trojans exist on Android.
Security policies always prevent behaviors that could be used for non-malicious purposes.
If the argument is that the end users should be the ones to decide, it’s really just another way of saying that Apple shouldn’t be allowed to enforce any security policy.
Of course there are those who believe that Apple shouldn’t be able to enforce security policies, but there is no overreach here.
On ios and ipad (from your first sentence) you cannot.
I think a good goal would be to scream it as loud as possible and make sure people are buying it based on this dimension as well.
If they are willing to break their contract for money what is to stop them from harvesting my data for money?
The security feature is a part of the apple ecosystem. I bought a Mac because of that not desire of it.
> If they are willing to break their contract for money what is to stop them from harvesting my data for money?
This argument was weak enough that a judge specifically rejected it after Apple failed to prove any kind of immediate threat was being presented from the Unreal Engine.
> what is to stop them from harvesting my data for money?
The fact that the contract dispute in question had nothing to do with data harvesting in the fist place.
> I bought a Mac because of that
That's fine. And if Apple wants to try and tie all of this to security, then honestly whatever. But when this signing feature came out, people made fun of critics for suggesting Apple would do the exact thing you're now saying they're justified in doing. Try to lump it under the banner of security, try to lump it under the barrier of whatever you want. When avalys says:
> 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.
they're expressing doubt that Apple would do any of the things that you're praising Apple for doing with app signing. And the fact remains, it's very plausible that they would use this as a tool to enforce contracts. You're in the comments, right now, saying that they should use this feature as a tool to enforce contracts.
So what exactly do you disagree with me on? It still seems pretty reasonable to believe that Apple will be willing to use app logging as a contract enforcement tool, and that when they do people will jump on HN to defend them, given that you are currently defending them for doing so right now.
The argument over whether preemptively blocking app updates based on a vague sense of 'distrust' falls into the category of security is a semantic argument, and I don't really care about digging into it. The point stands, people are worried that Apple will use this feature to target apps beyond normal malware, trojans, or worms, and they are right to be worried about that.
Users frequently comment that the apps are now "broken" because they don't understand the changes Apple made to macOS to treat un-Notarized apps as if they're radioactive.
If you can’t confidently change a system preference back and forth, maybe you are very vulnerable to being hacked in general? So maybe it’s ok for Apple’s defaults, at least, to be restrictive?
I just want a preference that allows me to turn all of this off.
Tl;dr: no.
going back to the original topic, apple hardware/software, i've used apple hardware and software (company-issued macbook pro and iphone 7/8).
The software is great as long as you want to stay within apple-defined boudaries. If you want to go outside that, it's an experience similar if not worse than using gnu/linux.
The hardware is great when the machine is brand new but decays very quickly, it's not designed to be serviced by either end-users or specialized users or specialized shops -- you're supposed to return it to an apple store and pay an expensive price to basic maintenance. As an example, cleaning up the fans from dust is very important in those machines but you have to buy special hardware to take off the screws, and in generally you risk breaking something. Keyboards failed spectacularly in last gen, and apple waited like two years before fixing it. Audio is great, until it breaks. My macbook pro (15" top of the line) couldn't sustain full-audio, and distorted audio after ~30 sec of full volume audio (imagine that during a conference call in a meeting with other people). The screen is great, but the glass panel retained ALL of the fingerprints and it was a PITA to clean, i had to buy special glass-cleaning liquids. WTF.
All the above issues appeared all shortly after the first year of life of the laptop. Call me an anti-apple fanatic, I don't care, but I expected more from a 3500+€ machine.
At the new job i've been given a 13" dell latitude 7390. It works flawlessly, it rarely skips a beat and it has none of the problems stated above. Fuck Apple.
You’ve missed my point, which is that you could remove the word “Apple” from your original comment and it would have made no difference. One kind of fanatic does not excuse another, nor have I claimed it does.
There’s no need to list Apple’s faults. I’m aware of them and support a large part of Apple criticism in the Tim Cook era (and not just technical[1]), including most of yours.
Where we disagree is in the insinuation the author is a fanatic simply for defending Apple. They’ve written a technical post and gave their conclusions, which may indeed sound apologetic but are far from rabid fanaticism.
> Fuck Apple.
In sum, it’s fine to decry the company but I disagree that people who like it and accept its tradeoffs should be immediately labeled as extremists.
Well Apple is notoriously abusive of the developers on its platform. Two things are particularly cried about across most of the ecosystem: the 30% cut they take off pretty much everything and the vague terms that you have to comply with, and that they enforce in a mostly random way (app gets pulled out of the app store, won't tell you why, won't tell you what you did wrong).
Now add the exhorbitant prices for their low-specced, low-quality hardware.
Now add the continual rip-off of their users.
Now add the subject of the original linked page.
At this point I think that yes, defending Apple is extremism.
It's fine to accept the tradeoffs, it's not fine to pretend they do not exists:
- "Yeah this stuff is unreasonably expensive but we have to use it"
that is honest
- "the apple ecosystem is the best for creative and developers and what apple does across all the spectrum is fine"
that is dishonest.
> Apple: "We have never heard of PRISM"[115] "We do not provide any government agency with direct access to our servers, and any government agency requesting customer data must get a court order."[115]
* https://en.wikipedia.org/wiki/PRISM_%28surveillance_program%...
Certainly American companies are subjects to warrants and NSLs, but Google (to give one example) had its dark fibre connections between data centres tapped by the NSA. Is that the "participation" that was referred to by the Snowden documents?
* https://arstechnica.com/tech-policy/2013/10/new-docs-show-ns...
* https://www.theguardian.com/technology/2013/oct/30/google-re...
* https://venturebeat.com/2013/11/25/level-3-google-yahoo/
* https://www.washingtonpost.com/world/national-security/nsa-i...
No, that's a separate thing. They do both. See the "you should use both" slide.
https://github.com/iamcryptoki/snowden-archive/blob/master/d...
As to the apple claims that they didn't participate in PRISM, I think they were just lying. Clapper lied to congress as well, so this isn't unheard of. They would likely have breached their government contract by telling the truth. That being said, them having never heard about the program name might be true because it might not have been known to them under that name, but that's just a detail.
(And even if you disable backups, Apple can still read most if not all of your messages, because the persons on the other side of the conversations have not disabled backups)
Having you messages deleted because you forgot your iCloud password is good security but a terrible default.
It's been engrained in them since the 80s and with the growth of Google, it became fun to vilify Apple because of it.
I wish we could do away with the whole "public company" thing - just imagine how much better Facebook, Google, and countless other companies (yes, Apple too) would be if they were private, and more accountable to their users.
Instead, what would be really nice is imagining how those companies would fare as worker-owned companies. Especially with these big internet behemoths, where the entire families of all the workers are users, the standard of user care would easily sky-rocket.
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 had a serious uninstaller bug, but that's all it was, and it's not relevant to the current discussion.
https://sneak.berlin/20200604/if-zoom-is-wrong-so-is-apple/
They were going to actually encrypt it, but suddenly had a change of heart after the FBI had a chat with them:
https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...
https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...
This is clearly indicated on the PRISM Wikipedia page that was linked above.
> PRISM is a code name for a program under which the United States National Security Agency (NSA) collects internet communications from various U.S. internet companies.[1][2][3] The program is also known by the SIGAD US-984XN.[4][5] PRISM collects stored internet communications based on demands made to internet companies such as Google LLC under Section 702 of the FISA Amendments Act of 2008 to turn over any data that match court-approved search terms.
As I've said, that's a detail and splitting hairs. If a sentence has multiple interpretations and one of them is true, but you phrase it in a way that most people interpret the sentence in the wrong way, you are intentionally deceiving people. They should have said "we have never heard the name PRISM" or something like this.
That is the crux of our disagreement, which I doubt we’ll resolve over an internet text interaction.
Thank you for the conversation thus far. Maybe we’ll resume it if we happen to ever meet.
I find that you're the kind of person that only find what they're looking for.
> Thank you for the conversation thus far. Maybe we’ll resume it if we happen to ever meet.
thank you too and have a nice day.
I expressed an opinion on a belief you seem to hold, not a value judgement on yourself. I don’t presume to know which “kind of person” you are from a short text-based interaction pertaining to single subject matter. I’ll ask you extend me the same courtesy.
> The Niva was described by its designers as a "Renault 5 put on a Land Rover chassis"
So I guess one example of a car that was not copypasted from fiat?
Isn't the Volga a copy of a Mercedes? ;)
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...
> It’s relevant because you argue that there is no value to having the ability to do this.
No, I did not. We haven't talked about that other mechanism, so I've said nothing about it here either positively or negatively.
> Something you have dismissed as a non problem.
I said "Zoom had a serious uninstaller bug". So no, I did not dismiss it as a non problem. It just has nothing to do with Developer ID certificate OCSP.
Please stop putting words in my mouth or completely warping the words that I do say.
You said “But if you have a cached OCSP response for the cert of a malware author, then you've already launched their app, so it's probably too late.”
I.e. once you have launched the app, the damage is done.
This is not the case, and the Zoom situation is a clear counterexample. Even if a problematic app has been launched one or more times, it is still worth preventing subsequent launches if you can.
It doesn’t matter what mechanism is used to prevent the subsequent launch. This applies to any mechanism including OCSP. The Zoom example is a refutation of the particular point you made, a point which dismisses a real security concern.
It demonstrates that there is value in Apple having the ability to prevent harmful software from running, no matter how many times it has already been run.
Because "true socialism" (like your true Scotsman) requires ideal übermenschen on all levels everywhere. This is not how the humankind works. Humankind is full of flawed, sometimes outright malicious people, and you have to deal with that.
Most versions of socialism at some point came up with a need to breed ideal happy socialist people that won't keep breaking their paradise all the time. And until this Übermensch is born, they chose to break and bend the rest into behaving, like bonsai trees. Of course, Dear Leader and their team is exempted from being broken or bent, and many others aspire to become like them. This is how every socialist rule to date grew into a totalitarian oligarchy.
Thank you but no thank you. I'd better choose a form of government that adapts to and deals with people as they are, and doesn't try to force them into some better version according to their understanding.
I was talking about MALWARE. As I said before, Zoom is not malware, so no, it's not a counterexample.
This is my last reply to you. You're clearly not interested in having a good faith conversation, you continue to misinterpret me and want to score "internet points" or something. I'm done.
Zoom is not malware in that as far as we know it isn’t Zoom’s intent to cause harm.
However in this instance it exhibited a behavior which many forms of malware exhibit - opening an insecure or exploitable port. It was shut down because it was behaving the way some malware behaves.
It’s a perfectly reasonable example of using these types of mechanism to mitigate a real security issue.
You can’t seriously be claiming that malware never opens ports, or that malware always does all of its harm on the first run.
Therefore the use of the distinction ‘malware’ is arbitrary and irrelevant.
The mechanism is useful to protect against vulnerabilities, regardless of whether the vulnerabilities were intentional or not.