[HN Gopher] Apple reportedly dropped plan for encrypting backups...
___________________________________________________________________
Apple reportedly dropped plan for encrypting backups after FBI
complained (2020)
Author : samename
Score : 378 points
Date : 2021-01-14 15:12 UTC (7 hours ago)
(HTM) web link (www.theverge.com)
(TXT) w3m dump (www.theverge.com)
| sneak wrote:
| I've been posting that Reuters link repeatedly to HN (in context)
| for the last year or so; hopefully this is common enough
| knowledge now that I can stop.
|
| This whole "Apple cares about your privacy and encrypts your
| data" false narrative really needs to finally end.
| Simulacra wrote:
| Are they not encrypted when you backup to the computer?
| chopin24 wrote:
| (2020)
| luxuryballs wrote:
| This is why I use local only backups but there's been a number of
| times where iCloud backups will mysteriously re-enable and I have
| to go delete the backup and disable. Not a fan of that!
| dylan604 wrote:
| I'm in tech, and I don't trust the cloud. I use the cloud at
| employer's behest, but I don't put my personal anything in the
| cloud that I don't have to. No, I do not have anything to hide.
| It's more of I have seen too many instances of services getting
| shut down, or deciding they don't want to offer that service,
| or just plain going out of business to trust anything to a 3rd
| party. That's before even deciding if they are able to maintain
| security and privacy.
| modeless wrote:
| It's also important to realize that the backup includes your
| encrypted iMessage messages, _and_ the key required to decrypt
| them. Meaning that if you have backups enabled, all the "end-to-
| end" encryption in iMessage is defeated. Apple and by extension
| the FBI can read your messages. This is documented by Apple here:
| https://support.apple.com/en-us/HT202303
|
| Even if you disable backups, whenever you correspond with someone
| that has backups enabled those messages are still accessible to
| Apple.
| lights0123 wrote:
| (if you have Messages in iCloud enabled, but you don't loose
| much by turning it off)
| modeless wrote:
| If you turn off Messages in iCloud then your messages are
| included in the regular iCloud backup. This is documented
| here: https://support.apple.com/guide/icloud/messages-
| mm0de0d4528d...
| bhaile wrote:
| Good point. Pasting the relevant section and the explanation
| why they chose to implement it that way.
|
| --
|
| _Messages in iCloud also uses end-to-end encryption. If you
| have iCloud Backup turned on, your backup includes a copy of
| the key protecting your Messages. This ensures you can recover
| your Messages if you lose access to iCloud Keychain and your
| trusted devices. When you turn off iCloud Backup, a new key is
| generated on your device to protect future messages and isn 't
| stored by Apple._
| whatever1 wrote:
| And this is something not clear at all in the advertising
| campaigns of Apple.
| gruez wrote:
| I don't see how this is an issue. Let's say google proudly
| advertises that chrome is backdoor free. But at the same time
| they provide a remote desktop solution (aka backdoor) that
| users can optionally enable. Is this an issue?
| zingermc wrote:
| If the messages are encrypted at rest on your phone, it
| seems reasonable to expect the same of backups on the
| server.
| capableweb wrote:
| The iCloud backups are opt-out, not opt-in, that's the
| issue. Most people leave settings at their default, and if
| a company says "We care about your privacy and security",
| you expect that to be reflected in the default, but here it
| seems Apple went the other way.
| j45 wrote:
| It's good this is getting attention.
|
| While there maybe encryption in transit of messages, the
| encryption of messages at test is effectively defeated when the
| messages are at rest in icloud.
|
| I am curious, is it possible to do an icloud equivalent backup
| without using icloud? Perhaps with a different backup app, nas,
| etc?
| joosters wrote:
| Local backups can be completely encrypted (used to be done by
| iTunes, don't know if they've changed that now though?)
|
| ISTR that local backups would contain more than the icloud
| backups as well - there are some things that won't be backed
| up into the cloud?
| whatever1 wrote:
| The worst part is that there is nothing you can do if the
| person you are texting has enabled iCloud backups. There is
| also no notification when you start the conversation that it
| is not e2e protected anymore.
| Ashanmaril wrote:
| It would be nice to have some indication as to whether or
| not the other person has backups enabled, but the issue is
| it wouldn't be a with-certainty indicator that your
| conversation won't be backed up since the other person
| could have it disabled but then turn on backups later.
|
| Ideally it would be nice if you could opt yourself out of
| having any conversations backed up, but I'm sure to Apple
| the privacy benefits doesn't outweigh the amount of
| customer support hours that would be wasted explaining to
| people why some of their conversations aren't transferring
| to their new iPhone.
| gruez wrote:
| >I am curious, is it possible to do an icloud equivalent
| backup without using icloud? Perhaps with a different backup
| app, nas, etc?
|
| itunes.
| amluto wrote:
| libimobiledevice can do it too.
| gruez wrote:
| >Even if you disable backups, whenever you correspond with
| someone that has backups enabled those messages are still
| accessible to Apple.
|
| That's more of a problem with who you choose to communicate
| with and their security practices than a problem with Apple.
| The same counterparty could also have a weak/non-existent
| passcode on their phone, or is jailbroken.
| na85 wrote:
| The exact same flaw (your party might misuse the system and
| expose secrets) exists in the design of PGP/GPG and whenever
| it comes up in that context it's a reason to throw GPG into
| the garbage disposal. But when it's an Apple product suddenly
| the product is fine and it's the parties' fault for not using
| it properly?
|
| Why the disconnect?
| gruez wrote:
| >The exact same flaw exists in the design of PGP/GPG and
| whenever it comes up in that context it's a reason to throw
| GPG into the garbage disposal.
|
| I literally never heard of this. There are problems with
| PGP (eg. no forward secrecy, non-reputability, unencrypted
| headers) but "your counterparty could be compromised" isn't
| one of them.
| na85 wrote:
| I'm referring to "your counterparty can hit reply-all and
| forget to encrypt" which is a mistake in the same
| category as "your counterparty might have backups
| enabled", i.e. it's easy to misuse in a way that ends up
| defeating secrecy.
| upofadown wrote:
| I think the reference is to the idea that a correspondent
| might do a unencrypted CC of a message that contains
| previously encrypted text as per this infamous anti-PGP
| rant:
|
| * https://latacora.micro.blog/2019/07/16/the-pgp-
| problem.html
| morpheuskafka wrote:
| It looks like the main "about backups" page [1] on Apple Support
| misleads about this issue:
|
| > iCloud backups include nearly all data and settings stored on
| your device. iCloud backups don't include:
|
| > Data that's already stored in iCloud... iMessages... Health
| data
|
| Only the more technical "about encryption" page [2] that most
| users wouldn't seek out contains the full story, providing a list
| of regular encryption vs. E2EE services and admitting the key
| issue:
|
| > Messages in iCloud also uses end-to-end encryption. If you have
| iCloud Backup turned on, your backup includes a copy of the key
| protecting your Messages. This ensures you can recover your
| Messages if you lose access to iCloud Keychain and your trusted
| devices. When you turn off iCloud Backup, a new key is generated
| on your device to protect future messages and isn't stored by
| Apple.
|
| The problem is that the first page makes it sound like no
| iMessage related data is backed up, when the truth is that the
| messages themselves aren't but a backdoor copy of the encryption
| key is, and lists it along with other E2EE services like Health
| data that do not have a key backed up and remain E2EE protected
| with iCloud backup. A user would have no reason to even seek out
| the second article to learn that it's not the same.
|
| Concerningly, iCloud Photos are not E2EE at all. It's no more
| secure/private than Google Photos or any other app.
|
| [1] https://support.apple.com/en-us/HT204136 [2]
| https://support.apple.com/en-us/HT202303
| IndySun wrote:
| So, obvious question, how then does iCloud keychain (still)
| work?
|
| I mean, is everything iCloud compromised, all the time,
| everywhere? That kinda flattens Apples privacy claims.
| [deleted]
| [deleted]
| iknowstuff wrote:
| All the apologists worrying about users losing their keys are
| forgetting that even Google has enabled opt-in end to end
| encryption on Android: https://www.androidcentral.com/how-
| googles-backup-encryption...
| mtgx wrote:
| To make things worse they tie iMessage backups to all iCloud
| backups, so the so-called "end-to-end encryption" of iMessage is
| essentially a completely irrelevant/broken feature for 95% of
| iPhone users.
|
| And that's without mentioning that Apple also has the ability to
| add its own key invisibly without users knowing about it to allow
| interception (WhatsApp does this, too, now).
| humps wrote:
| (Jan 2020)
| viktorcode wrote:
| Since user encrypted iCloud backups would prevent password
| recovery to access your data I'm more inclined to believe the
| decision was made out of convenience for the end user.
|
| General public would hate it when the support won't help them
| recover family photos which are still stored in the cloud. Full
| encryption is nice to have, but overwhelming majority of users
| won't get any tangible benefits from that.
| random5634 wrote:
| No kidding. If you run windows deployments the bitlocker key
| backup to domain / azure / whatever is a must / lifesaver.
|
| FAR FAR too many situations where users don't keep their keys.
| It can be as simple as upgrading the chip on your computer -
| which happens with AMD machines because they've had a long run
| of AM4 socket support. Boom, you fTPM is gone now, and user is
| complaining they've lost their irreplaceable stuff.
|
| I've seen this on IT side with backups. They set up an
| encryption key on the backups (pub / private) 6 years ago. 6
| years later, when it comes time to recover under some time
| pressure, no one has a CLUE where the key is and old staff are
| long gone. Absolute nightmare.
|
| For all the folks saying managing encryption keys at scale is
| like tying your shoes - 100% false. To manage keys (especially
| ones where the private key is rarely if ever actually used)
| takes very very HIGH levels of care.
|
| One solution - have encryption keys periodically "fail" so you
| are forced to prove you know how to recover your key - but no
| one does that.
|
| Same issue used to occur with 2FA apps on phone upgrades before
| they made it easier to move stuff over to new devices.
| sneak wrote:
| Reuters says six sources inside Apple said it was the FBI.
|
| My sources inside Apple tell me that there was at least a
| partial implementation for doing e2e backups safely, including
| a system for using friends/family to certify recovery in the
| event of password loss (presumably something like secret
| sharing).
|
| The FBI and Apple actively collaborated to prevent this from
| coming to pass.
|
| > _One former FBI official who was not involved with these
| talks told Reuters that Apple was won over by the agency. "It's
| because Apple was convinced," said the source._
|
| Your claim directly contradicts the article.
| PragmaticPulp wrote:
| > including a system for using friends/family to certify
| recovery in the event of password loss
|
| Having friends and family take ownership of partial secret
| keys is a non-starter. Few people would actually go to the
| lengths of distributing fractional secrets to their friends
| and family. Even fewer people would do a good job of not
| losing them over the years.
|
| Outside of techie circles, account recovery is a relatively
| frequent occurrence. The majority of general public customers
| would prefer being able to recover their account even if it
| means a vanishingly small chance that the FBI would be able
| to access it in the even of an investigation.
| admax88q wrote:
| > Few people would actually go to the lengths of
| distributing fractional secrets to their friends and
| family. Even fewer people would do a good job of not losing
| them over the years.
|
| I feel like this is all a solvable UX problem. The secrets
| could be automatically distributed and stored on
| friends/family devices, could be integrated into iMessage
| directly. "Choose friends you trust to help you recover
| data." If N of your M designated friends and family still
| have access to their phone when you need to recover your
| backup then you can get access, maybe by presenting a QR
| code on each device you can scan, or a notification you can
| interact with after confirming identity via a phone call or
| something.
|
| The secrets wouldn't require any actions to keep intact,
| they could always be synced into iMessage and included in
| your own backups. Kind of like you're operating a RAID
| array across your friends and family, N+X redundancy, so
| long as no more than X of your group needs recovery at the
| same time you're good.
|
| Kind if an interesting approach actually, would be neat to
| build this into Matrix as an experiment.
| boomboomsubban wrote:
| Six sources confirmed the FBI contacted Apple, they can't
| fully prove that that contact caused the decision. I'd bet it
| at least played a role, but the article is not as clear cut
| as you make it out to be.
| admax88q wrote:
| As usual on HN, Apple is always given the benefit of the
| doubt, where any article is interpreted in the strongest
| possible way in favour of Apple. Compare this to any article
| about Google, where anything they do is interpreted in the
| worst possible way for Google.
|
| AMP was my favourite example. You could interpret AMP as
| Google ensuring a better experience for users, or as Google
| highjacking the web into a closed ecosystem to squeeze out
| competitors. HN threads about AMP almost always concluded
| that it was a terrible overreach by Google, anti-competitive,
| and bad for everyone. But an article suggesting that Apple
| maybe put the FBI ahead of users in this instance? Dismissed
| because OP is "inclined to believe."
| random5634 wrote:
| AMP so obviously was better than ginormous ad filled sites
| that jank and jump like crazy it wasn't even funny. The
| idea that there was no user benefit was just a HN view -
| out in the real world plenty of people learned the
| lightening icon meant both faster and usually much cleaner
| and easier to browse.
|
| I think in part a fair number of HN folks maybe do web dev
| work, and having google restrict the junk they can dump on
| users was annoying to them. A fair bit of the anti-trust
| rhetoric is not coming from consumers or consumer advocates
| but other businesses - some of which have just horribly
| seedy business models (the recommendation engine searching
| sites with all the auto-generated fake reviews complaining
| of de-prioritizations etc).
| t0mmyb0y wrote:
| This is correct. Apple works with FBI while publicly saying
| they don't.
| j45 wrote:
| The option to enable full zero knowledge encryption should
| exist for icloud.
| bugfix wrote:
| So why not give users the option to encrypt everything if they
| want to?
| gruez wrote:
| but then again, who's going to be using it? A sibling comment
| mentioned that you can still do local backups which are
| encrypted and don't leave your device. What's the
| intersection of people who cares about their backup being
| encrypted, but can't set up itunes sync on their computer?
| dkonofalski wrote:
| I would use it because I like the convenience of iCloud
| backup and not having to ever plug my phone into anything.
| gruez wrote:
| >and not having to ever plug my phone into anything.
|
| works over wifi too.
| https://www.switchingtomac.com/tutorials/ios-
| tutorials/backu...
| dkonofalski wrote:
| Is that still accurate? You don't use iTunes to sync the
| phone anymore and I don't think the encrypted backups
| could be done via WiFi. If that's changed, then that's
| awesome.
| MagerValp wrote:
| That's essentially what backing up to your Mac instead of
| iCloud gets you. The data is encrypted with your key to a
| device that you control.
| patrickserrano wrote:
| I worked in education and had teachers and administration who
| were smart people, consistently asking to have their
| passwords reset. And the only requirement we had was that it
| needed to be 8 chars long, no special chars or
| capitalization. (This was a result of students and staff not
| being able to remember their passwords for more than a day or
| two)
|
| I can't imagine needing a password for them to recover photos
| and messages.
| xurukefi wrote:
| I'm convinced that if you give the general public the
| "encrypt everything option", then too many people will opt in
| without being aware of the consequences. They will eventually
| forget their password, loose all their family photos and
| blame Apple for it. A disclaimer also wouldn't help here.
|
| If anything, this should be some hidden developder mode kind
| of option to make sure that only those opt in who know what
| they are doing.
| gsich wrote:
| Then you make them aware of those consequences. This is
| solvable.
| mattnewton wrote:
| The set of customers who will both understand the
| consequences and still opt in is so small I think apple
| is comfortable letting someone else take that market,
| unfortunately.
| amiga-workbench wrote:
| Users don't read, they smash Ok buttons without
| understanding.
| gsich wrote:
| So you ask them multiple times. You remind them via mail
| every n months. I repeat this is solvable. If people
| chose willingly ignore multiple warnings, then it's their
| fault.
|
| Don't assume your users are immature just because they
| use a computer. This assumption is only with computers, I
| don't know why.
| kgwgk wrote:
| Make them sign several clauses on a contract and send
| back a scanned copy. Really, if they still go through it
| without understanding what they are doing it will be on
| them.
| mattnewton wrote:
| Signed copies protect you from litigation in court, not
| loss of brand value in the court of public opinion.
| Plenty of people bitten by it will just never use a
| backup product from you again, and every time apple
| sneezes a flurry of journalists are there to document it.
| UnFleshedOne wrote:
| I guess the idea here is to make enabling the option
| enough of a pain so that only people who need it are
| going to use it, and button smashers will be spared.
| Nextgrid wrote:
| In this case, should we also ban power tools and heavy
| machinery because some idiots aren't careful and get
| hurt?
| mattnewton wrote:
| No, but it's perfectly fine for a company to not want to
| be in the table/chain saw industry if they have a brand
| identity around "just works."
|
| It's unfortunate because apple has the cash and panache
| to take it mainstream, but they probably don't have any
| market incentive to do so, at least until someone else
| figures out the ux that doesn't cut clueless user fingers
| off.
| rootusrootus wrote:
| This seems uncharitable. Most people can intuitively
| understand the danger of a table saw. Just the sound
| alone sends a shiver up your spine even if you aren't a
| woodworking expert.
|
| But we've conditioned users to accept a million dialog
| boxes to confirm random choices that are mostly
| inconsequential CYA.
| gruez wrote:
| The analogy isn't helpful because you're actively aware
| of the dangerous machine when you're close to it, whereas
| losing a password is something you unintentionally do
| because you forgot about it 6 months after setting it up.
| A better analogy would be ammonia refrigerators that
| occasionally leaked and killed people in their sleep,
| which _are_ banned.
| mywittyname wrote:
| Make it difficult to find unless the person is actively
| looking for it.
| mattnewton wrote:
| Apple's ultimate goal is to sell iPhones, not solve
| privacy unfortunately. Why would they invest in a feature
| they actively hide and discourage users from using? They
| can't put it in the keynote as a feature to buy an
| iPhone, and then hide it from all the users they just
| advertised to.
| spacedcowboy wrote:
| This.
|
| I'm pretty convinced the proportion of people who would be
| likely to expect Apple to be able to recover from a lost
| password, _even though_ they 'd specifically opted out of
| that, would tend to ~100% of any group of users (not just
| Apple users).
|
| Many people think "The Internet" is their browser (Oh, mum,
| [sigh]). Try to explain public key cryptography
| consequences to them, I dog-dare you. If Betty (Oh, Betty,
| [deep sigh]) from next door said it was "better" then
| they'll go for it anyway, and only pay attention to the
| consequences when it's too late.
|
| The article is a year old, and I think Apple could do some
| stuff around what they already do (if you forget your
| password on one device, you can typically reset it using
| the password from another device, all the while maintaining
| the cryptography chain). There's some interesting avenues
| that could be explored there, but until they have a solid-
| as-they-can-make-it public release-candidate, we won't hear
| anything about it.
| jaywalk wrote:
| Because of the FBI, obviously.
| zahrc wrote:
| And this is also what most people want, most of them don't care
| about security, privacy and safety. It's convenience and
| accessibility.
| whoknew1122 wrote:
| 100% this. Working at AWS, I've dealt with (presumably) IT
| professionals who couldn't understand why we don't backup their
| KMS keys in case they delete their key and data gets orphaned.
|
| This sort of encryption bears a heavy burden on the customer.
| And the customer often doesn't want to accept that burden.
| jtdev wrote:
| But we shouldn't default to "let's compromise data security
| and privacy because some customers can't keep track of their
| keys". That would be like a shoe store only selling velcro
| shoes because some shoe buyers struggle with tying shoe
| laces...
| rusticpenn wrote:
| We do not need a fire engine to put our candles out. The
| solution must match the problem.
| raverbashing wrote:
| "Some customers" do you think the majority of Apple users
| (not picking on them, they're your average non-IT person)
| knows about a password they set last year maybe?
|
| That is the problem. It's very frustrating to tell some
| people that they can't recover their data because they
| forgot the password
|
| If you can keep a password for a long time then you can do
| your backups yourself I guess?
| rootusrootus wrote:
| > Apple users (not picking on them, they're your average
| non-IT person)
|
| To be fair, this also describes Windows users. Most users
| of any platform are average non-IT people.
| Tempest1981 wrote:
| What % of users need to reset their password (for a given
| service) each year? I was guessing 5%.
|
| A web search shows this surprising stat, for all the
| user's services:
|
| "78% of people have had to reset their password in the
| last three months. - HYPR study"
|
| And 57% for work accounts. Wow.
| whoknew1122 wrote:
| How should we handle the majority of customers that aren't
| technically savvy and are just looking to upload pictures
| of granny?
|
| Or to further your shoe store idea. The majority of people
| know how to tie their shoes. Most shoe stores usually don't
| keep a lot of stock of shoes larger than a US size 12 men's
| shoe. My foot happens to be larger. I have a different use
| case. So I often have to go through a different workflow
| (e.g. ordering online, having the store custom order my
| shoes, etc.).
|
| If you want full data security, you need additional
| technical knowledge and a different workflow. iCloud isn't
| for you.
| 34679 wrote:
| Make encryption optional, and explicitly state the
| associated risk of a lost key.
| [deleted]
| vulcan01 wrote:
| This is actually a good idea. Apple does this on macOS
| with File Vault: "WARNING: You will need your login
| password or a recovery key to access your data. ... If
| you forget both your password and recovery key, the data
| will be lost."
|
| They could put a clear warning on the iCloud screen as
| well. However, there is a large market for the iPhone in
| non-tech savvy people, especially old people, who may not
| understand fully what this decision means.
| ghaff wrote:
| As I recall, that's how Mozy did it for online backups
| way back when. (I think it was encrypted in any case but
| they handled the key management by default.) They let you
| handle your own key if you wanted to but gave a stern
| warning if you elected to do that.
| Kalium wrote:
| If memory serves, Apple did precisely this with FileVault
| for a very long time. Google did the same thing with
| encryption on phones. It was all quite thoroughly
| optional and all the warnings were thoroughly clear.
|
| People can, will, do, _and did_ ignore any and all
| warning messages and then look to support to help them.
| It does not seem to matter how large, scary, or clear the
| warnings are. They will be ignored.
|
| So if you're Google or Apple and want to ensure that
| people's identity documents or tax records or business
| documents aren't stolen when the laptop or phone is, you
| make encryption the default. It helps that these devices
| are easier to sell to businesses. I'm thankful for these
| choices.
|
| In my professional capacity as an information security
| practitioner and my personal capacity as a privacy
| advocate, I find the idea at hand distasteful. Improved
| security should be available to everyone, not just those
| with a deep grasp of how to manage cryptographic keys.
| Gaining any measure of data security should not be
| reserved solely for us in the technical elite.
|
| There might, perhaps, be a slightly different discussion
| to be had about making it more common for tools to enable
| advanced users to manage their own keys. But this should
| never come at the expense of the common user. We have a
| profound professional responsibility to be better than
| that.
| curryst wrote:
| > Apple does this on macOS with File Vault: "WARNING: You
| will need your login password or a recovery key to access
| your data. ... If you forget both your password and
| recovery key, the data will be lost."
|
| Many people assume that that when it says "can't", it
| actually means "won't", and that they'll be able to beg
| or browbeat support into helping them.
|
| I can also already see the argument: "but that's not my
| data, it's in My Documents, it's a document so it
| shouldn't be encrypted!"
|
| Communicating these things to users is hard because when
| it comes to computers, the lexicon is often personal.
| What one user calls My Documents might refer to the My
| Documents collection in Windows, and another one might
| mean a random folder they created that they put documents
| in. It's basically impossible to get everyone on the same
| lexicon, although it's getting better as young kids grow
| up with computers.
| [deleted]
| Silhouette wrote:
| _If you want full data security, you need additional
| technical knowledge and a different workflow. iCloud isn
| 't for you._
|
| As someone who very much doesn't use iCloud for exactly
| this reason, I'd have a lot more sympathy with that
| argument if Apple didn't push everyone towards iCloud and
| the accompanying insecurity while simultaneously making
| it much more difficult than it needs to be to move your
| data between, onto and off Apple devices in other, more
| secure ways.
| chillacy wrote:
| iOS has an option to wipe itself after 10 incorrect
| passcode entries. There are lots of warnings, I think
| most people get the idea that this is opt-in.
| bronco21016 wrote:
| > iCloud isn't for you.
|
| I've come to this conclusion. So what are my options
| since Apple keeps such tight control on everything? Plug
| in nightly to iTunes or libimobiledevice? Stand up an
| iTunes server for LAN backups requiring Windows or macOS?
| What about the 30-40% of nights I'm on the road?
|
| I'm all for ditching iCloud for backups but Apple has
| made it really inconvenient to do automated backups with
| anything but iCloud. Libimobiledevice is slowly working
| towards LAN backups so we're getting there but then I'm
| still in need of mDNS reflection to make it happen over
| WAN.
|
| I've made efforts into tying as much of my data to self-
| hosted solutions as possible but full device backup on
| your own hardware is still a gaping hole in the iOS
| ecosystem.
| gruez wrote:
| But you can still make local (itunes) backups that are
| encrypted?
| felipemesquita wrote:
| Yes. It's handled by Finder now since new versions of
| macOS don't have iTunes, but it's the same encrypted
| backup functionality.
| sneak wrote:
| Doesn't matter; all of your iMessage conversation
| partners likely have iCloud Backup enabled (it's on by
| default) and are providing Apple your plaintext chat
| history with them.
| r00fus wrote:
| For those who can avoid using iMessage for meaningful
| discussion, that's why we have Signal/Telegram/etc. Also
| it takes that extra effort to piece together evidence if
| you have to search someone else's phone for my data.
| daxelrod wrote:
| Wouldn't the data stores of these apps be included in
| iCloud backups too?
| r00fus wrote:
| https://www.reddit.com/r/signal/comments/6qcxx7/is_signal
| _da...
| [deleted]
| morpheuskafka wrote:
| Yes, and the encryption on those really isn't that
| important as it can be protected by full-disk encryption
| (ex FileVault) on your hard disk, or throwing the backup
| in an encrypted container (zip, dmg, whatever) manually.
| The local iTunes encryption does have to be enabled for
| call data, health data, WiFi passwords, and browsing
| history to be included.
|
| Frustratingly, if you forget the backup password you have
| to Reset All Settings on the device, no way to change it
| going forward if you lost the old one. Of course, there
| should be no way to get to the old backups if you don't
| have the password, but if you have access to the device
| (thus, the source of the data to begin with) you should
| be able to change it without a reset.
| daemoon wrote:
| And we are not: Computer backups still exist, if you would
| like to do local backups. Privacy, most of the time, means
| less conveniency but it's still possible.
| rootusrootus wrote:
| The problem with this analogy is that it is likely that
| something like 99% of shoe buyers can tie their own laces
| just fine, practically in their sleep. That ratio would be
| inverted when you consider how many users can successfully
| keep track of their own encryption keys.
|
| Regular users just care that they don't lose their data.
| Offer them the option to keep it 100% secure from prying
| eyes at the risk of losing access to it permanently if they
| misplace the password, and 99% will tell you to pound sand.
| ghaff wrote:
| And consider some of the scenarios where an iCloud backup
| is needed which include some sort of fire, flood, etc. So
| now they need to be sure that their key is stored
| somewhere safely online where they can get at it.
|
| >99% will tell you to pound sand
|
| Or they'll select it anyway because they don't really
| understand what they're doing notwithstanding big, scary
| warnings. A lot of tech people want everything to be
| configurable but that often is just not a good idea.
| BoorishBears wrote:
| If anything their analogy shows why that is in fact the
| default.
|
| Most people can tie their shoelaces, so may stores don't
| even bother carrying velcro shoes.
|
| Likewise if the situation was inverted, hardly anyone
| would sell shoes with shoelaces.
|
| When there's finite resources for businesses the needs of
| the many overcome the needs of the few
| the_duke wrote:
| Related to this, it seems FB sort of panicked with the recent
| Signal exodus.
|
| The app demanded cloud backups from me 8 times over 2 or 3
| days.
|
| Presumably so that returning users still have their messages
| intact.
| Beggers1960 wrote:
| "I'm more inclined to believe the decision was made out of
| convenience for the end user."
|
| Bingo. We have a winner.
| soperj wrote:
| This is the company that you all trust with your privacy. Good
| grief.
| ur-whale wrote:
| It's increasingly clear that Apple is not in their user's camp.
| random5634 wrote:
| Good lord - this is a HN only comment. Go ahead and use your
| phone from china with built in spyware! Or almost all android
| phones - never updated. Or use whatsup or facebook messenger
| instead of imessage.
|
| It's increasingly clear that HN commentators pushing towards
| Apple's competitors don't care about privacy at all.
| modeless wrote:
| iPhones in China back up to a version of iCloud owned by a
| Chinese company that presumably shares its data with the
| government.
| esotericsean wrote:
| I know a lot of it is marketing, but they're certainly trying
| much more than competitors.
| modeless wrote:
| Google has enabled end to end encryption of Android backups.
| stepanhruda wrote:
| I'm hoping they simply deferred this for a few years so they
| don't anger feds too much at once.
| zimpenfish wrote:
| Title is missing "reportedly" before "scrapped".
| samename wrote:
| I had to remove a word because title was too long. Maybe
| removing "fully" would've been better
| jaywalk wrote:
| It's far from ideal, but I can live with it since I can still
| backup my phone locally and have those backups be encrypted.
| vulcan01 wrote:
| Theory: Apple has a deal with the government to not properly
| encrypt iCloud backups in exchange for the government not
| regulating them through antitrust.
|
| This is pure speculation, but I wouldn't be surprised if this is
| why the government has been so lax on antitrust regulation with
| Big Tech.
| yreg wrote:
| Maybe stupid question, but how can you do deals like that with
| a democratic government? What binds the next cabinet to uphold
| the bargain?
| boomboomsubban wrote:
| Theoretically nothing, but neither party wants to piss off
| the FBI.
| vulcan01 wrote:
| Well, you can make a deal with each administration. It's
| probably in the best interest of any DoJ, Democrat or
| Republican, to be able to access data unencrypted. So these
| deals probably* carry over each time the administration
| changes hands.
|
| * With the recent investigation into Apple [0] by the DoJ, I
| don't see this deal continuing for far longer. Unless the
| investigation is just for show.
|
| [0]: https://www.businessinsider.com/biden-team-continue-
| scrutini...
| dannyw wrote:
| The FBI and DoJ working together isn't hard to imagine.
| dylan604 wrote:
| Well, also, the sky is blue. The FBI is part of the DoJ, so
| by definition they are working together. The Attorney General
| is the FBI Director's boss.
|
| https://www.justice.gov/agencies/chart
| soperj wrote:
| this phrase always bothered me. Technically the sky isn't
| blue. That becomes quite clear every single night.
| dylan604 wrote:
| Okay, then "s/sky is blue/water is wet/g" or "s/sky is
| blue/fire is hot/g"
|
| Edit: I can't just let this lie. Just because you can't
| see it doesn't mean it's not true. The sky at night is
| still blue, there's just not enough light for human eyes
| to see it. I have plenty of footage from night skies
| where the sky is still clearly blue. This footage [0] is
| clearly taken at night while the moon is below horizon
| then the sky becomes blue again (still at night) when the
| moon rises. The light reflections in the water as well as
| still being able to see the stars in a blue sky shows the
| sky is still blue even at night.
|
| [0] https://vimeo.com/241600503
| boomboomsubban wrote:
| Go watch a sunset and be amazed at a non-blue sky.
| heavymark wrote:
| While only guessing, it would seem more likely that Apple knows
| they do what they are doing, which keeps most people's data
| safe and private (and people who don't use icloud backups can
| have complete privacy), vs if they encrypt all backups, FBI
| will make sure to remind the public and congress more loudly
| everytime they can't catch someone because of it, and then much
| more likely they congress will ban encryption completely
| resulting in far less security and privacy for all users. With
| so many people moving to Telegram and Signal, that might end up
| happening any way, but what they are doing would simply seem a
| way of avoiding/delaying that.
| chopin24 wrote:
| This theory implies a level of coordination and agreement that
| the US Government is simply not capable of. The group most
| interested in such backups (intelligence) does not coordinate
| with the regulatory committees, and even if they did such an
| agreement wouldn't be disclosable to the public and wouldn't
| hold up if demands for regulation got hot.
|
| The most likely reason we haven't seen antitrust action is more
| boring: it's hard, our politicians are old and don't even use
| email, and they've been consumed with more pressing matters.
| [deleted]
| StillBored wrote:
| I'm convinced this is also why after 20+ years of knowing how to
| have a id authenticated/encrypted email system based on public
| keys its not been made the default in pretty much any of the
| mainstream email systems.
|
| The excuses of it being unwieldy are 100% because its not
| transparently integrated.
| PragmaticPulp wrote:
| I suspect such a system would be popular among the tech crowd,
| but you're greatly overestimating the general public's desire
| to deal with any of this complexity.
|
| The average customer from the general public understands that
| they're not going to become the subject of an FBI investigation
| and they'd gladly take simplified UX and account recovery as a
| tradeoff.
| StillBored wrote:
| My point is that it doesn't have to be visibly complex. gmail
| or outlook could automatically generate and store a public
| key for every single account transparently then just append
| signatures to the bottom of emails while providing the public
| key directory for their users.
|
| Then any random client can hit keys.gmail.com (or whatever
| pseudo standard one wants for finding the key servers) cache
| public keys and on some TTL check for revocation/etc.
|
| Then the only thing the user would have to know about is
| whether the from box is "green" indicating that the user was
| validated, "yellow" indicating an invalidated email, or "red"
| indicating a problem with the validation. Once the validation
| is complete via a back/forth exchange the clients then know
| they can encrypt emails to the destination, thereby turning
| the from field green on the next email exchange.
|
| Sure people using those services would also be allowing the
| service to see their private keys, but for phone apps, or
| desktop applications the key generation portion could be done
| on the machine and only the public key pushed to the email
| providers keyserver.
|
| Plenty of other email services (proton mail, symantec) make
| this very easy for the end user.
| freedomben wrote:
| I would have agreed with this a few weeks ago, but given
| recent events you would be shocked at how many people are
| swarming into things like Signal. The average person is
| realizing that they don't get to choose what opinions are
| allowed and what are not allowed.
|
| It's no doubt a reflection of my social circle, but it
| includes plenty of people that barely know how to turn their
| computer on. Many of them are asking me what to do to protect
| their privacy and ability to communicate.
|
| If I were Keybase right now, I'd be starting back up
| development and cranking out some marketing right about now.
| That's a huge opportunity.
___________________________________________________________________
(page generated 2021-01-14 23:02 UTC)