3 ms·
Apple has said they plan to do this, and also encrypt the checking payload. Sounds good to me, though definitely a privacy failure that they didn't do this in t
by dilap 6y ago
Apple has said they plan to do this, and also encrypt the checking payload. Sounds good to me, though definitely a privacy failure that they didn't do this in the first place.
The other thing I'd like to see is the app open immediately, w/ the check happening asynchronously in the background. (This seems like super-basic good engineering to me.) No idea if they're planning to fix that or not.
- ascagnel_ 6y ago> The other thing I'd like to see is the app open immediately, w/ the check happening asynchronously in the background. (This seems like super-basic good engineering to me.) No idea if they're planning to fix that or not. How would this work? The point of the check is to block malware from running, and opening without the check would, by definition, negate the entire system. If malware authors get wise to the async scheme, they can write programs that deliver their payload in the opening milliseconds of an app’s execution, while the network call is running (even the fastest pings would leave 1 or 2 ms worth of window).
- angry_octet 6y agoSurely this check could be done on install/first run, then cached? If you want rapid blacklisting, a frequent call to Apple to say "anything new blacklisted?" would suffice. Same as push notification.
- deleted 6y ago[deleted]
- dilap 6y agoFair question. My thinking was the system is already not designed to be failproof, just mitigitive (it turns off entirely if no internet), and that malware would be pretty limited in what it could do in just a few hundred ms. Waiting to open an app based on a network request is basically just guaranteed to give you a terrible experience some % of the time. Maybe fancier solutions like a local blacklist are needed. (Which weirdly it looks like Apple had and then moved away from?)