16 ms·

One must understand that E2EE is used when you don't trust your service provider to handle your data. In other words, the adversary in your threat model is the

One must understand that E2EE is used when you don't trust your service provider to handle your data. In other words, the adversary in your threat model is the service provider - and in this case, Apple. And what good is that encryption, if Apple obviously can do almost anything with your device? They can remotely wipe apps. They can force-install apps and force updates. It is not too far-fetched to think that they can just remotely copy anything stored on your device to their servers. So, with an adversary that capable, I'm not sure encrypted backups provide a meaningful improvement to security and privacy.

voxic11 4y ago
I think it mostly matters in the context of US case law, specifically the third party doctrine. > The third-party doctrine is a United States legal doctrine that holds that people who voluntarily give information to third parties—such as banks, phone companies, internet service providers (ISPs), and e-mail servers—have "no reasonable expectation of privacy" in that information. A lack of privacy protection allows the United States government to obtain information from third parties without a legal warrant and without otherwise complying with the Fourth Amendment prohibition against search and seizure without probable cause and a judicial search warrant. https://en.wikipedia.org/wiki/Third-party_doctrine https://en.wikipedia.org/wiki/Third-party_doctrine
supertrope 4y ago
In theory it adds a speed bump. Apple as the cloud service provider can respond to the legal order by saying they don't have the key. And then the police can ask for a booby trapped update for just your phone which may or may not happen. Or they can lobby the legislature for an encryption backdoor for all devices which will force them to show their hand in terms of "lawful intercept" capability. If you want maximum security use an air gapped computer. But that won't let you send messages on the go.
- Andrew_nenakhov 4y ago
  If you want maximum security then just obviously don't use Apple services, or any other provider that has a capability to fetch your data under any circumstances.
  - smoldesu 4y ago
    > then just obviously don't use Apple services How is this possible on iPhone/iPads, where using Apple services like the App Store is required to install software?
    - supertrope 4y ago
      Don't buy an iPhone.
      - smoldesu 4y ago
        Or just wait long enough for the EU's digital markets act to take effect. But my point stands.
        scarface74 4y ago
        I can’t wait for the mandated pop ups “did you know you could install a third party App Store” every time you go to the Apple App Store.
        jdiez17 4y ago
        What makes you think there will be such "mandated popups"?
        scarface74 4y ago
        Have you heard of the GDPR and seen how it’s made the web browsing experience worse?
- gjsman-1000 4y ago
  Nothing is secure. Once we remember that, we'll stop nitpicking improvements. Use your own server? Great, it's secure software-wise, but if someone broke into your house, it's all of the sudden the worst liability ever. The next thing you know, your entire identity, your photos, everything is stolen. You have excellent technical security, perhaps the weakest physical security. So new plan, you use a self-hosted NextCloud instance on a VPS somewhere. That's actually not much smarter than using iCloud - VPSs handle data warrants all the time. They also move your data around as they upgrade hardware, relocate servers, and so forth. So new plan, you use iCloud E2E encryption. You have to trust that Apple does as they say, and trust that their algorithms are correctly functioning. Maybe you don't want to do that, so new plan: You use a phone running GrapheneOS, with data stored on a VPS, with your own E2E setup. Great - except you need to trust your software, and all the dependencies it relies on. Are you sure GrapheneOS isn't a CIA plant like ArcaneOS was? Are you sure your VPN isn't a plant, like Crypto AG? And even if the VPN is legitimate, how do you know the NSA doesn't have wiretaps on data going in and out, allowing for greatly reducing the pool of suspects? Are you sure that even if the GrapheneOS developers are legitimate, the CIA hasn't stolen the signing key long ago? Apple's signing key might be buried in an HSM in Apple Park requiring a raid, but with the GrapheneOS developer being publicly known, perhaps a stealth hotel visit would do the trick. So new plan, you build GrapheneOS yourself, from source code. Except, can you really read it all? Are you sure it is safe? After all, Linux was nearly backdoored with only two inconspicuous lines hidden deep in the kernel (the 2003 incident). So... if you read it all, and verify that it is perfect, can you trust your compiler? Your compiler could have a backdoor (remember the "login" demo?), so you've got to check that too. At this point, you realize that maybe your code, and compiler, is clean - but it's all written in C, so maybe there are memory overflows that haven't been detected yet, so the CIA could get in that way (kind of like with Pegasus). In which case, you might as well carefully rewrite everything in Rust and Go, just to be sure. But at that point, you realize that your GrapheneOS phone relies on Google's proprietary bootloader, which is always signed by Google and not changeable. Can you trust it? You can't, and then you realize that the chip could have countless backdoors that no software can fix (say, with Intel ME, or even just a secret register bit), so new plan. You immediately design and build your own CPU, your own GPU, and your own silicon for your own device. Now it's your own chip, with your own software. Surely that's safe. But then you realize there's no way to verify, even after delidding the chip, to verify that the fabrication plant didn't tweak your design. In which case, you might need your own fabrication plant... but then you realize that there's the risk of insider attacks... and how do you even know those chip-making machines are fully safe? How do you know the CIA didn't come knocking and make a few minor changes to your design, and then gag the factory with a National Security Letter from giving you any whiffs about it? But even if you managed to get that far, great, you've got a secure device - how do you know that you can securely talk to literally anyone else? Fake HTTPS Certificates from Shady Vendors are a thing (TrustCor?). You've got the most secure device that is terrified to talk to anybody or anything. You might as well start your own Certificate Authority now and have everyone trust you. Except... aren't those people... in the same boat now... as yourself... And also, how do you know the NSA hasn't broken RSA and the entire encryption ecosystem with that supercomputer and mathematicians of theirs? How do you know that we aren't using a whole new DUAL_EC_RBG and that Curve25519 isn't rigged? The rabbit hole will never end. This doesn't mean that we should just give up - but it does mean we shouldn't be so ready to nitpick the flaws in every step forward, as there will be no perfect solution. Oh, did I mention your cell service provider always knows where you are, and your identity, at all times, regardless of how secure your device is? Edit @INeedMoreRAM: For NextCloud, from a technical perspective it's fantastic, but your data is basically always going to be vulnerable to either a technical breach of Linode, an insider threat within Linode, or a warrant served (either a real warrant, or a fraudulent warrant, which can happen). You could E2E encrypt it with NextCloud (https://nextcloud.com/endtoend/ https://nextcloud.com/endtoend/) which would solve the Linode side of the problem, but there are limitations you need to look into. Also, if a warrant was served (most likely going to be authentic if police physically show up, at least more likely than one they served your data over), you could always have your home raided, recovery keys found, and data accessed that way. Of course, you could destroy the keys and only rely on your memory - but, what a thing to do to your family if you die unexpectedly. Ultimately, there's no perfect silver bullet. Personally... It's old school, I use encrypted Blu-rays. They take forever to burn, but they come in sizes up to 100GB (and 128GB in rare Japanese versions), they are physically stored in my home offline, and I replace them every 5 years. This is coupled with a NAS. It's not warrant-proof but I'm not doing anything illegal - but it is fake-warrant-resistant and threats-within-tech resistant, and I live in an area where I feel relatively safe (even though this is, certainly, not break-in-proof). Could also use encrypted tape.
- jazzyjackson 4y ago
  > If you want maximum security use an air gapped computer. But that won't let you send messages on the go. You can, with some inconvenience, use optical diodes to transmit data from a trusted input device to an untrusted network device for transport over tor, and then push the received messages over a second diode to a display device that decrypts the messages, so that even if you receive an exploit/malware, there is no physical connection that allows unencrypted data to be exfiltrated. https://github.com/maqp/tfc https://github.com/maqp/tfc
  - brokenmachine 4y ago
    Thanks, that was actually super interesting, never heard of a data diode before. BRB, just setting up six new PCs so I can chat with my friend, lol.
  - aryik 4y ago
    This was incredibly interesting. Thanks for sharing!
- gtvwill 4y ago
  They don't have to lobby anyone for this. Apple has operations in aus. We have laws here gov can force you to put a backdoor in software or hardware and you are not allowed to tell even your employer you have been requested to do so. Tbh in theory apple aren't allowed to tell you they have done it or otherwise. So their phones have probably been backdoored for a few years now at request of aus gov.
  - theshrike79 4y ago
    Who pays for the work required to add the backdoor? Does the company have to do it for free?
  - supertrope 4y ago
    I would not be surprised if there is a backdoor already. Either explicitly ordered or secretly inserted like Dual_EC_DRBG. They’re not burning a zero day vulnerability or certificate authority just to convict one defendant. They’re saving them for something like Stuxnet.
vineyardmike 4y ago
> And what good is that encryption, if Apple obviously can do almost anything with your device? Because apple isn’t in control of apple for data at rest, and that’s the specific risk. You have to trust control of the device sure, but you cannot trust cloud data - almost at all - between subpoenas from over eager LEOs and break ins from criminal and state hackers
- smoldesu 4y ago
  > Because apple isn’t in control of apple for data at rest That's not really true if Apple also holds copies of your iCloud decryption keys. If they want to access your data, they already have all the necessary components.
  - vineyardmike 4y ago
    Yea, thats the point. Let me re-phrase, by giving Apple control over the keys, you give control over the data to whoever controls apple - which is non-zero (Eg. LEO), and whoever may gain control (security vuln).
    - smoldesu 4y ago
      I don't want Apple to give over the keys. I just want my key to be the only in existence.
      - vineyardmike 4y ago
        Yea… that’s what they’re changing. That is the point. They’re not going to be in control over the keys - which is a good thing to you, it seems.
  - rodgerd 4y ago
    > That's not really true if Apple also holds copies of your iCloud decryption keys. That is literally the thing that this announcement changes. I see that Hacker News has plummeted below Reddit in the "bothering to check the link" stakes.
sedatk 4y ago
Apple isn't a monolithic entity. For example, a rogue engineer might be able to access your iCloud data, but it's orders of magnitude more complicated to push a specifically manufactured app to your device. There's a similar variance of complexities for hacking and law enforcement overreach scenarios. E2EE isn't a solution for all attack vectors, but it's a significant mitigation in itself.
schrodinger 4y ago
There are multiple meanings of trust in this scenario: belief in honesty, and confidence of ability. Eg I can trust you to tell me the truth but not trust you to protect me from a missile. I trust Apple’s honesty. I don’t trust many attack vectors. Someone could gain access to their data center. E2EE protects that. A gov could legally compel them to provide data. I trust when they say they’ve engineered it in such a way that they can’t currently do it, and that they would publicly cause a scene and legal battle if attempted-as they have before. Accidental data leaks also happen. In all these scenarios I trust Apples intentions but know that nothing is perfect. E2EE adds a lot for me.
- jiggawatts 4y ago
  Also, companies like Apple are huge, with thousands of staff. These protections aren't there to protect you from "Apple", but Apple staff. So for example if someone at Apple has been compromised by a foreign state, they can't copy sensitive customer data just willy nilly. They'd have to jump through a lot of hoops that would be prohibitively difficult. Google had issues like this in the past where some employees were sending data to the Chinese government. E.g.: information about dissidents, political opponents in Taiwan, etc... This is one of the reasons Google encrypts even internal server-to-server traffic, because the threat is on the inside of the firewall!
  - SpelingBeeChamp 4y ago
    >Google had issues like this in the past where some employees were sending data to the Chinese government. Was that reported anywhere?
    - schrodinger 4y ago
      It was all over the news, example from 2013 (when the NSA spying was a hot topic): https://arstechnica.com/information-technology/2013/11/googlers-say-f-you-to-nsa-company-encrypts-internal-network/ https://arstechnica.com/information-technology/2013/11/googl...
judge2020 4y ago
> They can remotely wipe apps. Technically no. I still have Fortnite on my iPhone, it just can't be opened. Apple can't wipe apps from your phone, but if they're App Store installed (as opposed to Ent MDM/Sideloaded), they can render them inoperable by revoking the certificate attached to the bundle.
- lxgr 4y ago
  What's the functional difference between "remotely deleting" and "remotely rendering inoperable"? Remotely deleting probably just exposes them to all kinds of legal issues, since it would wipe user data too (which you can otherwise possibly still extract, e.g. through the "Files" app).
  - quitit 4y ago
    What’s missing is context - Fortnight’s account is in breach of the agreement and can’t deliver updates to address issues with the latest version of iOS. This is identical to any developer that doesn’t deliver updates or suspends their developer account. Those which have downloaded Fortnight at least once can still download and use the game on earlier versions of iOS and even with iOS 16 by following certain mitigations. Contrary to some online posts Apple haven’t done anything unique to the fortnight account.
- fragmede 4y ago
  It's all a closed source jumble though. Even if they can't do it right now, they have the power to install an update that allows them to add that power, if they had to.
dgdfhdfhj 4y ago
One must also understand that you're wrong. My threat model isn't Apple. My threat model is a) Overreaching law enforcement, which want to take a look at what I'm up to. b) Data breach at Apple exposes all my data c) Errors where my pictures gets in another users photo album, as seen on Google Photos once. E2EE defends against all 3
tshaddox 4y ago
> In other words, the adversary in your threat model is the service provider - and in this case, Apple. And what good is that encryption, if Apple obviously can do almost anything with your device? The adversary in this threat model isn't the service provider. The adversary is someone attacking the service provider, like a hacker or a government with a warrant, and getting access to Apple's storage of your data. Now of course it's not impossible for such an adversary to also defeat other systems at Apple and get your data another way, for example by controlling Apple's ability to send over-the-air updates to Apple devices. But I think that is a sufficiently distinct threat that it's not worth dismissing solutions to the first threat. That would be like dismissing the importance of a web server storing passwords salted and hashed, since attackers could just use a totally different attack to bypass the web server's database access control. Another way to illustrate this might be to point out that attackers can physically coerce you to hand over data regardless of any security measures any service provider could possibly make, but that doesn't mean we should dismiss all such security measures.
- Terretta 4y ago
  We used to call this "NSL-proof". If your provider is architected to be NSL-proof, then the warrant has to get served to you. This is now possible to achieve in AWS, for example.
  - stevewatson301 4y ago
    Can you please elaborate? I haven't seen any info from AWS to that end, and with KMS they control the keys.
    - acdha 4y ago
      I’m assuming they’re referring to this new feature: https://aws.amazon.com/about-aws/whats-new/2022/11/aws-kms-external-key-store/ https://aws.amazon.com/about-aws/whats-new/2022/11/aws-kms-e...
  - acdha 4y ago
    I think the right way to advocate for this really is to focus on the warrant aspect. It’s not about preventing law enforcement but keeping it above board where there’s at least the possibility of oversight and targets can exercise their rights to things like legal representation.
deleted 4y ago
[deleted]

voxic11 4y ago

I think it mostly matters in the context of US case law, specifically the third party doctrine. > The third-party doctrine is a United States legal doctrine that holds that people who voluntarily give information to third parties—such as banks, phone companies, internet service providers (ISPs), and e-mail servers—have "no reasonable expectation of privacy" in that information. A lack of privacy protection allows the United States government to obtain information from third parties without a legal warrant and without otherwise complying with the Fourth Amendment prohibition against search and seizure without probable cause and a judicial search warrant. https://en.wikipedia.org/wiki/Third-party_doctrine https://en.wikipedia.org/wiki/Third-party_doctrine

supertrope 4y ago

In theory it adds a speed bump. Apple as the cloud service provider can respond to the legal order by saying they don't have the key. And then the police can ask for a booby trapped update for just your phone which may or may not happen. Or they can lobby the legislature for an encryption backdoor for all devices which will force them to show their hand in terms of "lawful intercept" capability. If you want maximum security use an air gapped computer. But that won't let you send messages on the go.

Andrew_nenakhov 4y ago
If you want maximum security then just obviously don't use Apple services, or any other provider that has a capability to fetch your data under any circumstances.
- smoldesu 4y ago
  > then just obviously don't use Apple services How is this possible on iPhone/iPads, where using Apple services like the App Store is required to install software?
  - supertrope 4y ago
    Don't buy an iPhone.
    - smoldesu 4y ago
      Or just wait long enough for the EU's digital markets act to take effect. But my point stands.
      - scarface74 4y ago
        I can’t wait for the mandated pop ups “did you know you could install a third party App Store” every time you go to the Apple App Store.
        jdiez17 4y ago
        What makes you think there will be such "mandated popups"?
        scarface74 4y ago
        Have you heard of the GDPR and seen how it’s made the web browsing experience worse?
gjsman-1000 4y ago
Nothing is secure. Once we remember that, we'll stop nitpicking improvements. Use your own server? Great, it's secure software-wise, but if someone broke into your house, it's all of the sudden the worst liability ever. The next thing you know, your entire identity, your photos, everything is stolen. You have excellent technical security, perhaps the weakest physical security. So new plan, you use a self-hosted NextCloud instance on a VPS somewhere. That's actually not much smarter than using iCloud - VPSs handle data warrants all the time. They also move your data around as they upgrade hardware, relocate servers, and so forth. So new plan, you use iCloud E2E encryption. You have to trust that Apple does as they say, and trust that their algorithms are correctly functioning. Maybe you don't want to do that, so new plan: You use a phone running GrapheneOS, with data stored on a VPS, with your own E2E setup. Great - except you need to trust your software, and all the dependencies it relies on. Are you sure GrapheneOS isn't a CIA plant like ArcaneOS was? Are you sure your VPN isn't a plant, like Crypto AG? And even if the VPN is legitimate, how do you know the NSA doesn't have wiretaps on data going in and out, allowing for greatly reducing the pool of suspects? Are you sure that even if the GrapheneOS developers are legitimate, the CIA hasn't stolen the signing key long ago? Apple's signing key might be buried in an HSM in Apple Park requiring a raid, but with the GrapheneOS developer being publicly known, perhaps a stealth hotel visit would do the trick. So new plan, you build GrapheneOS yourself, from source code. Except, can you really read it all? Are you sure it is safe? After all, Linux was nearly backdoored with only two inconspicuous lines hidden deep in the kernel (the 2003 incident). So... if you read it all, and verify that it is perfect, can you trust your compiler? Your compiler could have a backdoor (remember the "login" demo?), so you've got to check that too. At this point, you realize that maybe your code, and compiler, is clean - but it's all written in C, so maybe there are memory overflows that haven't been detected yet, so the CIA could get in that way (kind of like with Pegasus). In which case, you might as well carefully rewrite everything in Rust and Go, just to be sure. But at that point, you realize that your GrapheneOS phone relies on Google's proprietary bootloader, which is always signed by Google and not changeable. Can you trust it? You can't, and then you realize that the chip could have countless backdoors that no software can fix (say, with Intel ME, or even just a secret register bit), so new plan. You immediately design and build your own CPU, your own GPU, and your own silicon for your own device. Now it's your own chip, with your own software. Surely that's safe. But then you realize there's no way to verify, even after delidding the chip, to verify that the fabrication plant didn't tweak your design. In which case, you might need your own fabrication plant... but then you realize that there's the risk of insider attacks... and how do you even know those chip-making machines are fully safe? How do you know the CIA didn't come knocking and make a few minor changes to your design, and then gag the factory with a National Security Letter from giving you any whiffs about it? But even if you managed to get that far, great, you've got a secure device - how do you know that you can securely talk to literally anyone else? Fake HTTPS Certificates from Shady Vendors are a thing (TrustCor?). You've got the most secure device that is terrified to talk to anybody or anything. You might as well start your own Certificate Authority now and have everyone trust you. Except... aren't those people... in the same boat now... as yourself... And also, how do you know the NSA hasn't broken RSA and the entire encryption ecosystem with that supercomputer and mathematicians of theirs? How do you know that we aren't using a whole new DUAL_EC_RBG and that Curve25519 isn't rigged? The rabbit hole will never end. This doesn't mean that we should just give up - but it does mean we shouldn't be so ready to nitpick the flaws in every step forward, as there will be no perfect solution. Oh, did I mention your cell service provider always knows where you are, and your identity, at all times, regardless of how secure your device is? Edit @INeedMoreRAM: For NextCloud, from a technical perspective it's fantastic, but your data is basically always going to be vulnerable to either a technical breach of Linode, an insider threat within Linode, or a warrant served (either a real warrant, or a fraudulent warrant, which can happen). You could E2E encrypt it with NextCloud (https://nextcloud.com/endtoend/ https://nextcloud.com/endtoend/) which would solve the Linode side of the problem, but there are limitations you need to look into. Also, if a warrant was served (most likely going to be authentic if police physically show up, at least more likely than one they served your data over), you could always have your home raided, recovery keys found, and data accessed that way. Of course, you could destroy the keys and only rely on your memory - but, what a thing to do to your family if you die unexpectedly. Ultimately, there's no perfect silver bullet. Personally... It's old school, I use encrypted Blu-rays. They take forever to burn, but they come in sizes up to 100GB (and 128GB in rare Japanese versions), they are physically stored in my home offline, and I replace them every 5 years. This is coupled with a NAS. It's not warrant-proof but I'm not doing anything illegal - but it is fake-warrant-resistant and threats-within-tech resistant, and I live in an area where I feel relatively safe (even though this is, certainly, not break-in-proof). Could also use encrypted tape.
jazzyjackson 4y ago
> If you want maximum security use an air gapped computer. But that won't let you send messages on the go. You can, with some inconvenience, use optical diodes to transmit data from a trusted input device to an untrusted network device for transport over tor, and then push the received messages over a second diode to a display device that decrypts the messages, so that even if you receive an exploit/malware, there is no physical connection that allows unencrypted data to be exfiltrated. https://github.com/maqp/tfc https://github.com/maqp/tfc
- brokenmachine 4y ago
  Thanks, that was actually super interesting, never heard of a data diode before. BRB, just setting up six new PCs so I can chat with my friend, lol.
- aryik 4y ago
  This was incredibly interesting. Thanks for sharing!
gtvwill 4y ago
They don't have to lobby anyone for this. Apple has operations in aus. We have laws here gov can force you to put a backdoor in software or hardware and you are not allowed to tell even your employer you have been requested to do so. Tbh in theory apple aren't allowed to tell you they have done it or otherwise. So their phones have probably been backdoored for a few years now at request of aus gov.
- theshrike79 4y ago
  Who pays for the work required to add the backdoor? Does the company have to do it for free?
- supertrope 4y ago
  I would not be surprised if there is a backdoor already. Either explicitly ordered or secretly inserted like Dual_EC_DRBG. They’re not burning a zero day vulnerability or certificate authority just to convict one defendant. They’re saving them for something like Stuxnet.

vineyardmike 4y ago

> And what good is that encryption, if Apple obviously can do almost anything with your device? Because apple isn’t in control of apple for data at rest, and that’s the specific risk. You have to trust control of the device sure, but you cannot trust cloud data - almost at all - between subpoenas from over eager LEOs and break ins from criminal and state hackers

smoldesu 4y ago
> Because apple isn’t in control of apple for data at rest That's not really true if Apple also holds copies of your iCloud decryption keys. If they want to access your data, they already have all the necessary components.
- vineyardmike 4y ago
  Yea, thats the point. Let me re-phrase, by giving Apple control over the keys, you give control over the data to whoever controls apple - which is non-zero (Eg. LEO), and whoever may gain control (security vuln).
  - smoldesu 4y ago
    I don't want Apple to give over the keys. I just want my key to be the only in existence.
    - vineyardmike 4y ago
      Yea… that’s what they’re changing. That is the point. They’re not going to be in control over the keys - which is a good thing to you, it seems.
- rodgerd 4y ago
  > That's not really true if Apple also holds copies of your iCloud decryption keys. That is literally the thing that this announcement changes. I see that Hacker News has plummeted below Reddit in the "bothering to check the link" stakes.

sedatk 4y ago

Apple isn't a monolithic entity. For example, a rogue engineer might be able to access your iCloud data, but it's orders of magnitude more complicated to push a specifically manufactured app to your device. There's a similar variance of complexities for hacking and law enforcement overreach scenarios. E2EE isn't a solution for all attack vectors, but it's a significant mitigation in itself.

schrodinger 4y ago

There are multiple meanings of trust in this scenario: belief in honesty, and confidence of ability. Eg I can trust you to tell me the truth but not trust you to protect me from a missile. I trust Apple’s honesty. I don’t trust many attack vectors. Someone could gain access to their data center. E2EE protects that. A gov could legally compel them to provide data. I trust when they say they’ve engineered it in such a way that they can’t currently do it, and that they would publicly cause a scene and legal battle if attempted-as they have before. Accidental data leaks also happen. In all these scenarios I trust Apples intentions but know that nothing is perfect. E2EE adds a lot for me.

jiggawatts 4y ago
Also, companies like Apple are huge, with thousands of staff. These protections aren't there to protect you from "Apple", but Apple staff. So for example if someone at Apple has been compromised by a foreign state, they can't copy sensitive customer data just willy nilly. They'd have to jump through a lot of hoops that would be prohibitively difficult. Google had issues like this in the past where some employees were sending data to the Chinese government. E.g.: information about dissidents, political opponents in Taiwan, etc... This is one of the reasons Google encrypts even internal server-to-server traffic, because the threat is on the inside of the firewall!
- SpelingBeeChamp 4y ago
  >Google had issues like this in the past where some employees were sending data to the Chinese government. Was that reported anywhere?
  - schrodinger 4y ago
    It was all over the news, example from 2013 (when the NSA spying was a hot topic): https://arstechnica.com/information-technology/2013/11/googlers-say-f-you-to-nsa-company-encrypts-internal-network/ https://arstechnica.com/information-technology/2013/11/googl...

judge2020 4y ago

> They can remotely wipe apps. Technically no. I still have Fortnite on my iPhone, it just can't be opened. Apple can't wipe apps from your phone, but if they're App Store installed (as opposed to Ent MDM/Sideloaded), they can render them inoperable by revoking the certificate attached to the bundle.

lxgr 4y ago
What's the functional difference between "remotely deleting" and "remotely rendering inoperable"? Remotely deleting probably just exposes them to all kinds of legal issues, since it would wipe user data too (which you can otherwise possibly still extract, e.g. through the "Files" app).
- quitit 4y ago
  What’s missing is context - Fortnight’s account is in breach of the agreement and can’t deliver updates to address issues with the latest version of iOS. This is identical to any developer that doesn’t deliver updates or suspends their developer account. Those which have downloaded Fortnight at least once can still download and use the game on earlier versions of iOS and even with iOS 16 by following certain mitigations. Contrary to some online posts Apple haven’t done anything unique to the fortnight account.
fragmede 4y ago
It's all a closed source jumble though. Even if they can't do it right now, they have the power to install an update that allows them to add that power, if they had to.

dgdfhdfhj 4y ago

One must also understand that you're wrong. My threat model isn't Apple. My threat model is a) Overreaching law enforcement, which want to take a look at what I'm up to. b) Data breach at Apple exposes all my data c) Errors where my pictures gets in another users photo album, as seen on Google Photos once. E2EE defends against all 3

tshaddox 4y ago

> In other words, the adversary in your threat model is the service provider - and in this case, Apple. And what good is that encryption, if Apple obviously can do almost anything with your device? The adversary in this threat model isn't the service provider. The adversary is someone attacking the service provider, like a hacker or a government with a warrant, and getting access to Apple's storage of your data. Now of course it's not impossible for such an adversary to also defeat other systems at Apple and get your data another way, for example by controlling Apple's ability to send over-the-air updates to Apple devices. But I think that is a sufficiently distinct threat that it's not worth dismissing solutions to the first threat. That would be like dismissing the importance of a web server storing passwords salted and hashed, since attackers could just use a totally different attack to bypass the web server's database access control. Another way to illustrate this might be to point out that attackers can physically coerce you to hand over data regardless of any security measures any service provider could possibly make, but that doesn't mean we should dismiss all such security measures.

Terretta 4y ago
We used to call this "NSL-proof". If your provider is architected to be NSL-proof, then the warrant has to get served to you. This is now possible to achieve in AWS, for example.
- stevewatson301 4y ago
  Can you please elaborate? I haven't seen any info from AWS to that end, and with KMS they control the keys.
  - acdha 4y ago
    I’m assuming they’re referring to this new feature: https://aws.amazon.com/about-aws/whats-new/2022/11/aws-kms-external-key-store/ https://aws.amazon.com/about-aws/whats-new/2022/11/aws-kms-e...
- acdha 4y ago
  I think the right way to advocate for this really is to focus on the warrant aspect. It’s not about preventing law enforcement but keeping it above board where there’s at least the possibility of oversight and targets can exercise their rights to things like legal representation.

deleted 4y ago

[deleted]