3 ms·

How do you know?

by leephillips 2y ago

How do you know?

misja111 2y ago
Why do you want to know?
- barrkel 2y ago
  Indeed, why would you want to know if the keys to your correspondence, bank accounts, investment logins, crypto fortune, backup OTP codes or whatever you might be using a password for, are sent in the clear to a third party.
gruez 2y ago
https://support.apple.com/en-us/102651 https://support.apple.com/en-us/102651 >Passwords and Keychain (6): End-to-end
- leephillips 2y ago
  I understand that Apple claims that this is the case. But given their history of incompetence in the past, that claim affords me little confidence that their closed source software does not contain critical bugs that might lead to recording or exposing the users’ plaintext passwords.
  - acdha 2y ago
    “History of incompetence” really needs some citations, especially for the belief that open source tools are better - they had Gotofail but OpenSSL had Heartbleed, etc. One of the better questions to ask is not how the source code is managed but how it’s audited: there’s a long history of problems in both open and closed software but well audited codebases tend to have them patched before exploits are publicly available.
    - leephillips 2y ago
      > “History of incompetence” really needs some citations Here’s a big one: https://arstechnica.com/gadgets/2007/11/be-cautious-of-that-serious-data-loss-bug-in-leopard/ https://arstechnica.com/gadgets/2007/11/be-cautious-of-that-... The article contains few details. More insight is at the discussion on https://www.cableforum.uk/board/showthread.php?p=34430700 https://www.cableforum.uk/board/showthread.php?p=34430700 Briefly, when implementing file moving in (closed source) Finder code, someone at Apple who was apparently a beginner programmer or student intern made an elementary error that reliably destroyed files. The system already had a battle-tested mv command in its BSD subsystem, but they didn’t use that code. The point of this story (and, yes, there is a large handful of similar stories) is what it tells you about Apple’s culture and practices around testing, care, and concern for real soundness and quality (as opposed to appearance).
      - Klonoar 2y ago
        Something from almost 20 years ago doesn’t quite work the way you think it does. Apple does take this stuff seriously. Implying otherwise is just absurd.
      - acdha 2y ago
        So you’re saying that having a data loss condition 17 years ago which only affected a subset of users who lost their storage connection in the middle of a move operation tells us something about their products today? Does that also mean that I shouldn’t use Linux because ReiserFS lost data on local storage in some cases back then, or btrfs did so more recently? What policy are you saying we should use to evaluate software? In particular, what’s left if we’re saying it’s no longer good enough to have learned from mistakes? I supported a lab full of computational scientists who heavily used their Macs with external storage at that time and this caused no problems for anyone, so I also am looking for something more quantitative like whether a bug which only affected handful of users disqualifies usage for everyone.
    - lightedman 2y ago
      "“History of incompetence” really needs some citations" Former Apple tech, G3/G4 iBook/PowerBook days. Crates of logic boards shipped in - most static-killed due to sand inside the crates. These were supposed to be used for repairing units that failed fresh from the manufacturing line. NVRAM consistently killed itself. Let me get out of my date of professional work in Apple repair - Trashcan Mac Pro - That one was very incompetently-designed given how badly people wanted to upgrade it and just could not due to space and thermal constraints. One of my friends about 4 years ago bought an iMac, 24" model. FIVE RMAs due to hard drive failing. They kept replacing it with the same drive brand and type, and likely from the same manufacturing batch, because that's an INSANELY high RMA rate for a single unit for the same piece of hardware. And that's just MY horror stories, and only from the HARDWARE perspective. And Cashmere, Apple's diag software, was a total piece of crap that couldn't tell you half of what was truly wrong with the system. So there's a bit of software horror for ya. Most Apple techs were shooting blind unless it was a specific problem. And the poor OS imaging techs - it's fun having school system laptops that are LOCKED to a specific OSX version and can NOT be upgraded. Not for security, NOTHING. You have to install that specific image for that specific school district, and ship it out. The machines can not be upgraded on the OS side. What a security nightmare that must have been. Shall I keep going? I'm sure if I thought hard enough I could find more incompetence which I hated while working as an Apple repair tech.

How do you know?

misja111 2y ago

Why do you want to know?

barrkel 2y ago
Indeed, why would you want to know if the keys to your correspondence, bank accounts, investment logins, crypto fortune, backup OTP codes or whatever you might be using a password for, are sent in the clear to a third party.

gruez 2y ago

https://support.apple.com/en-us/102651 https://support.apple.com/en-us/102651 >Passwords and Keychain (6): End-to-end

leephillips 2y ago
I understand that Apple claims that this is the case. But given their history of incompetence in the past, that claim affords me little confidence that their closed source software does not contain critical bugs that might lead to recording or exposing the users’ plaintext passwords.
- acdha 2y ago
  “History of incompetence” really needs some citations, especially for the belief that open source tools are better - they had Gotofail but OpenSSL had Heartbleed, etc. One of the better questions to ask is not how the source code is managed but how it’s audited: there’s a long history of problems in both open and closed software but well audited codebases tend to have them patched before exploits are publicly available.
  - leephillips 2y ago
    > “History of incompetence” really needs some citations Here’s a big one: https://arstechnica.com/gadgets/2007/11/be-cautious-of-that-serious-data-loss-bug-in-leopard/ https://arstechnica.com/gadgets/2007/11/be-cautious-of-that-... The article contains few details. More insight is at the discussion on https://www.cableforum.uk/board/showthread.php?p=34430700 https://www.cableforum.uk/board/showthread.php?p=34430700 Briefly, when implementing file moving in (closed source) Finder code, someone at Apple who was apparently a beginner programmer or student intern made an elementary error that reliably destroyed files. The system already had a battle-tested mv command in its BSD subsystem, but they didn’t use that code. The point of this story (and, yes, there is a large handful of similar stories) is what it tells you about Apple’s culture and practices around testing, care, and concern for real soundness and quality (as opposed to appearance).
    - Klonoar 2y ago
      Something from almost 20 years ago doesn’t quite work the way you think it does. Apple does take this stuff seriously. Implying otherwise is just absurd.
    - acdha 2y ago
      So you’re saying that having a data loss condition 17 years ago which only affected a subset of users who lost their storage connection in the middle of a move operation tells us something about their products today? Does that also mean that I shouldn’t use Linux because ReiserFS lost data on local storage in some cases back then, or btrfs did so more recently? What policy are you saying we should use to evaluate software? In particular, what’s left if we’re saying it’s no longer good enough to have learned from mistakes? I supported a lab full of computational scientists who heavily used their Macs with external storage at that time and this caused no problems for anyone, so I also am looking for something more quantitative like whether a bug which only affected handful of users disqualifies usage for everyone.
  - lightedman 2y ago
    "“History of incompetence” really needs some citations" Former Apple tech, G3/G4 iBook/PowerBook days. Crates of logic boards shipped in - most static-killed due to sand inside the crates. These were supposed to be used for repairing units that failed fresh from the manufacturing line. NVRAM consistently killed itself. Let me get out of my date of professional work in Apple repair - Trashcan Mac Pro - That one was very incompetently-designed given how badly people wanted to upgrade it and just could not due to space and thermal constraints. One of my friends about 4 years ago bought an iMac, 24" model. FIVE RMAs due to hard drive failing. They kept replacing it with the same drive brand and type, and likely from the same manufacturing batch, because that's an INSANELY high RMA rate for a single unit for the same piece of hardware. And that's just MY horror stories, and only from the HARDWARE perspective. And Cashmere, Apple's diag software, was a total piece of crap that couldn't tell you half of what was truly wrong with the system. So there's a bit of software horror for ya. Most Apple techs were shooting blind unless it was a specific problem. And the poor OS imaging techs - it's fun having school system laptops that are LOCKED to a specific OSX version and can NOT be upgraded. Not for security, NOTHING. You have to install that specific image for that specific school district, and ship it out. The machines can not be upgraded on the OS side. What a security nightmare that must have been. Shall I keep going? I'm sure if I thought hard enough I could find more incompetence which I hated while working as an Apple repair tech.