4 ms·

Not for long. Will be patched in hours, I bet.

0x0 8y ago
They would probably need to at least blacklist every affected ios version from the facetime servers, there will be a long trail of devices not updating soon
- xfitm3 8y ago
  This is assuming there is no possible server side mitigation.
  - 0x0 8y ago
    Even if there is a server side mitigation, it's a big black eye to have devices being remotely tappable with no user interaction. The devices are obviously not trustworthy anymore with the current software, and you are at the mercy of apple's servers. So a spying apple could always undo the server side mitigation (if even this is mitigatable server side). It's also a wakeup call to see that it is even possible for devices to start sharing audio or video with no user interaction. Obvious in hindsight for a software engineer perhaps, but the public perception might be forever changed.
    - j16sdiz 8y ago
      > but the public perception might be forever changed. No. Human fix their first impression and seldom change. Soon after Apple release a fix, they will boost how fast Apple fix bugs. It take a decades to realize no software is secure.
    - giancarlostoro 8y ago
      I mean, you can disable Facetime: https://www.imore.com/how-to-turn-on-off-restrict-facetime-iphone-ipad https://www.imore.com/how-to-turn-on-off-restrict-facetime-i... So I wouldn't get all the tinfoil over this matter, I would probably disable Facetime if I were most people though. Then it's likely to only be an issue of audio being streamed, much less horrible than inappropriate video streaming. I would hope they roll out a server-sided fix initially. "If calling user, if user ads themselves to group call, hang up group call" or some silly logic. I rather see that first, and then the client-side fix.
deleted 8y ago
[deleted]
oil25 8y ago
This would actually be a fun interview question - how to emergency patch 1B+ globally distributed mobile devices. I would say at least several days for the obvious QA which needs to be done.
- tehlike 8y ago
  Desperate times call for faster-deployment. Been there. Sometimes, you might even need to patch a binary.
  - saagarjha 8y ago
    For this? I seriously doubt that this would require binary patching. A simple recompile with the fix should be good enough.
    - tehlike 8y ago
      Not for this one, no.
      - pertymcpert 8y ago
        Why would you need to patch the binary? If you're pushing out an update to fix the issue, the update may as well push out a rebuilt app than a binary diff.
        tehlike 8y ago
        I had been involved in a really hairy service interruption that involved hardcoded urls into an sdk (http://a.com/b.js http://a.com/b.js), and a.com was remapped to a brand new web service / target which no longer had the file. As if it's not enough, the server returned 301 permanent redirect with 60 day ttl to http://c.com http://c.com. Our traffic dropped 40% because of that mistake (not 100 because in previous couple releases i have changed that url to be something that's widely used and had no risk of getting messed up, but old clients still had the urls embedded). As if that is not enough, the IOS library for some reason had implemented "hand rolled "caching with a lot of hardcoding. To fix the issue... i made c.com homepage also serve b.js at the bottom. There is no way in hell this would be committed and tested within qa timelines of either a.com set up or c.com setup. It's rather complex to fully explain without giving more context on what it is but when traffic drops 40% and you are generating 5M$/day.... You do whatever to bring it back.
imandride 8y ago
Replies from Apple stated, "Later this week". So you have this week to spy on whoever you need.
deleted 8y ago
[deleted]

0x0 8y ago

They would probably need to at least blacklist every affected ios version from the facetime servers, there will be a long trail of devices not updating soon

xfitm3 8y ago
This is assuming there is no possible server side mitigation.
- 0x0 8y ago
  Even if there is a server side mitigation, it's a big black eye to have devices being remotely tappable with no user interaction. The devices are obviously not trustworthy anymore with the current software, and you are at the mercy of apple's servers. So a spying apple could always undo the server side mitigation (if even this is mitigatable server side). It's also a wakeup call to see that it is even possible for devices to start sharing audio or video with no user interaction. Obvious in hindsight for a software engineer perhaps, but the public perception might be forever changed.
  - j16sdiz 8y ago
    > but the public perception might be forever changed. No. Human fix their first impression and seldom change. Soon after Apple release a fix, they will boost how fast Apple fix bugs. It take a decades to realize no software is secure.
  - giancarlostoro 8y ago
    I mean, you can disable Facetime: https://www.imore.com/how-to-turn-on-off-restrict-facetime-iphone-ipad https://www.imore.com/how-to-turn-on-off-restrict-facetime-i... So I wouldn't get all the tinfoil over this matter, I would probably disable Facetime if I were most people though. Then it's likely to only be an issue of audio being streamed, much less horrible than inappropriate video streaming. I would hope they roll out a server-sided fix initially. "If calling user, if user ads themselves to group call, hang up group call" or some silly logic. I rather see that first, and then the client-side fix.

deleted 8y ago

[deleted]

oil25 8y ago

This would actually be a fun interview question - how to emergency patch 1B+ globally distributed mobile devices. I would say at least several days for the obvious QA which needs to be done.

tehlike 8y ago
Desperate times call for faster-deployment. Been there. Sometimes, you might even need to patch a binary.
- saagarjha 8y ago
  For this? I seriously doubt that this would require binary patching. A simple recompile with the fix should be good enough.
  - tehlike 8y ago
    Not for this one, no.
    - pertymcpert 8y ago
      Why would you need to patch the binary? If you're pushing out an update to fix the issue, the update may as well push out a rebuilt app than a binary diff.
      - tehlike 8y ago
        I had been involved in a really hairy service interruption that involved hardcoded urls into an sdk (http://a.com/b.js http://a.com/b.js), and a.com was remapped to a brand new web service / target which no longer had the file. As if it's not enough, the server returned 301 permanent redirect with 60 day ttl to http://c.com http://c.com. Our traffic dropped 40% because of that mistake (not 100 because in previous couple releases i have changed that url to be something that's widely used and had no risk of getting messed up, but old clients still had the urls embedded). As if that is not enough, the IOS library for some reason had implemented "hand rolled "caching with a lot of hardcoding. To fix the issue... i made c.com homepage also serve b.js at the bottom. There is no way in hell this would be committed and tested within qa timelines of either a.com set up or c.com setup. It's rather complex to fully explain without giving more context on what it is but when traffic drops 40% and you are generating 5M$/day.... You do whatever to bring it back.

imandride 8y ago

Replies from Apple stated, "Later this week". So you have this week to spy on whoever you need.

deleted 8y ago

[deleted]