7 ms·

I see a lot of complaints about closed code. That is the first thing that people bring up with Apple and security. But how is open source changing things here?

I see a lot of complaints about closed code. That is the first thing that people bring up with Apple and security. But how is open source changing things here? No company open sources their server side components. Even if Google released their server code we have no confirmation that they deploying the same code on their servers. They are not vouching for that. We have a company here that really seems to want to do good on security and privacy. Immediately going to the closed source argument is just lazy and not helping. Of course the good part about a crowd is all views come out and so th closed source thing has its place but we should atleast give them their due and some kudos. We know people will try to evaluate the implementation and see what happens. In this case it's just a PR article. Let's wait for them to release detail and see if it stands out. May be the protocol is enough to give us confidence that their claim is true. We don't know yet.

jchw 9y ago
In a system that tries to be secure against server attacks, nobody cares about the server-side code, because we can't trust that it's the same exact code (i.e. without backdoors) anyways. Therefore, it would be possible to make assertions about how secure iMessage is with only client code.
- jpalomaki 9y ago
  To some extend the same problem applies to application code. As long as the hardware and platform are closed, we don't really know what is going on when the application is executed. Despite this, opening the application would be of course a step to the right direction. Not because it would guarantee that Apple is not doing bad things, but because it would help others spot problems that may be there by accident.
  - jchw 9y ago
    Yes, I agree with all of that.
- cle 9y ago
  Still, the other problems the parent mentioned still apply. Can you verify the build against the source? Can you verify the binary on your phone against the build?
  - jchw 9y ago
    No, of course not. I also can't build an iPhone from scratch or look at the hardware design or firmware. It's especially bad when you consider that Qualcomm baseband and the problems it has. Hell, I can't even trust that with my desktop computer. Further, how do I know the light in front of me isn't fabricated and that I'm not a brain floating in fluids connected to a simulation? Realistically, I believe Apple's intentions are in the right place. And I believe that, for the most part, iPhone backdoors are not a thing yet. Being able to look at the client code is not something I believe will happen, but I believe it would be good if it did because then the security of iMessage could be independently verified much easier. It is true that Apple could just lie about it and put different code up, but assuming their intentions are in the right place, it seems like a win-win for everyone.
    - mbilker 9y ago
      You can't build an iPhone from scratch, but you can build one from parts. Of course, it would need the magic signature from Apple in order to make Touch ID work unless the home button and system board were bought together.
- balabaster 9y ago
  Even if the server code is good, frequently they're hosted on servers that have other vulnerabilities anyway. Because we're not the sysop, we have no idea what they're running on and if it's patched properly and up to date. The only way to be safe is to become an expert in digital security, an expert in systems management, an expert in reading and mitigating security problems in open source code, an expert in securely deploying secure communications systems and host it yourself. For the rest of us, even those of us reasonably well versed in systems and application security, we kind of have to put our trust in someone and hope they don't fuck it up.
  - benchaney 9y ago
    > Even if the server code is good, frequently they're hosted on servers that have other vulnerabilities anyway. Because we're not the sysop, we have no idea what they're running on and if it's patched properly and up to date. The only way to be safe is to become an expert in digital security, an expert in systems management, an expert in reading and mitigating security problems in open source code, an expert in securely deploying secure communications systems and host it yourself. If the server is assumed to be compromised by the threat model, then none of this matters. > For the rest of us, even those of us reasonably well versed in systems and application security, we kind of have to put our trust in someone and hope they don't fuck it up. It is better to have to put your trust in any number of independent auditors than to have to put your trust in a single corporation.
zanny 9y ago
Signal has open source clients and server. Matrix has crypto support now (needs more auditing, but you can turn it on and nobody has cracked it yet to my knowledge) and thats fully open source. No, open source does not guarantee they are using the secure algorithms advertised on their servers. But open source does is let you run your own server, that you can put much more trust in. People spin up their own signal and matrix servers all the time now for just that reason.
- asadlionpk 9y ago
  But Apple isn't in that business, they are trying to make common user's comm private. Open sourcing only helps the power user (audit, run their own), as you described. Signal and iMessage both don't guarantee true privacy as we can't see the servers.
  - zanny 9y ago
    No service that uses a third party server can guarantee privacy unless they let you see the servers. For common users the question is if you trust the server operator, and if not, to consider your communications insecure. What they do about that is up to them. And it is up to these providers to earn trust.
    - asadlionpk 9y ago
      > No service that uses a third party server can guarantee privacy unless they let you see the servers. And there are no services that do that. Since that doesn't seem to be possible. Open sourcing the backend doesn't help here since you still have to blindly trust the server operators.
    - dsacco 9y ago
      The problem with this is that it eliminates the value proposition of E2EE, which is designed specifically to protect you when you don't trust the server operator. If you already trust the server operator, you've obviated the issue that E2EE ostensibly solves.
    - 9y ago
CiPHPerCoder 9y ago
Client software (anything that runs on the user's device) should be open source for two reasons: 1. It's easier to audit, although binary analysis is still useful (and reverse engineers are often better at finding security holes than someone doing a source code review). 2. Reproducible builds. Server software doesn't need to be open source. If you have E2E in your open source software, you don't need to trust the servers at all: https://paragonie.com/blog/2016/03/client-authenticity-is-not-server-s-problem https://paragonie.com/blog/2016/03/client-authenticity-is-no...
- pvg 9y ago
  That seems like a very weak "should" and more of a "nice when it happens"
  - CiPHPerCoder 9y ago
    My previous comment is RFC 2119 compliant.
    - pvg 9y ago
      That's 90's RFC technology! WOULD BE NICE is an unfortunate omission.

jchw 9y ago

In a system that tries to be secure against server attacks, nobody cares about the server-side code, because we can't trust that it's the same exact code (i.e. without backdoors) anyways. Therefore, it would be possible to make assertions about how secure iMessage is with only client code.

jpalomaki 9y ago
To some extend the same problem applies to application code. As long as the hardware and platform are closed, we don't really know what is going on when the application is executed. Despite this, opening the application would be of course a step to the right direction. Not because it would guarantee that Apple is not doing bad things, but because it would help others spot problems that may be there by accident.
- jchw 9y ago
  Yes, I agree with all of that.
cle 9y ago
Still, the other problems the parent mentioned still apply. Can you verify the build against the source? Can you verify the binary on your phone against the build?
- jchw 9y ago
  No, of course not. I also can't build an iPhone from scratch or look at the hardware design or firmware. It's especially bad when you consider that Qualcomm baseband and the problems it has. Hell, I can't even trust that with my desktop computer. Further, how do I know the light in front of me isn't fabricated and that I'm not a brain floating in fluids connected to a simulation? Realistically, I believe Apple's intentions are in the right place. And I believe that, for the most part, iPhone backdoors are not a thing yet. Being able to look at the client code is not something I believe will happen, but I believe it would be good if it did because then the security of iMessage could be independently verified much easier. It is true that Apple could just lie about it and put different code up, but assuming their intentions are in the right place, it seems like a win-win for everyone.
  - mbilker 9y ago
    You can't build an iPhone from scratch, but you can build one from parts. Of course, it would need the magic signature from Apple in order to make Touch ID work unless the home button and system board were bought together.
balabaster 9y ago
Even if the server code is good, frequently they're hosted on servers that have other vulnerabilities anyway. Because we're not the sysop, we have no idea what they're running on and if it's patched properly and up to date. The only way to be safe is to become an expert in digital security, an expert in systems management, an expert in reading and mitigating security problems in open source code, an expert in securely deploying secure communications systems and host it yourself. For the rest of us, even those of us reasonably well versed in systems and application security, we kind of have to put our trust in someone and hope they don't fuck it up.
- benchaney 9y ago
  > Even if the server code is good, frequently they're hosted on servers that have other vulnerabilities anyway. Because we're not the sysop, we have no idea what they're running on and if it's patched properly and up to date. The only way to be safe is to become an expert in digital security, an expert in systems management, an expert in reading and mitigating security problems in open source code, an expert in securely deploying secure communications systems and host it yourself. If the server is assumed to be compromised by the threat model, then none of this matters. > For the rest of us, even those of us reasonably well versed in systems and application security, we kind of have to put our trust in someone and hope they don't fuck it up. It is better to have to put your trust in any number of independent auditors than to have to put your trust in a single corporation.

zanny 9y ago

Signal has open source clients and server. Matrix has crypto support now (needs more auditing, but you can turn it on and nobody has cracked it yet to my knowledge) and thats fully open source. No, open source does not guarantee they are using the secure algorithms advertised on their servers. But open source does is let you run your own server, that you can put much more trust in. People spin up their own signal and matrix servers all the time now for just that reason.

asadlionpk 9y ago
But Apple isn't in that business, they are trying to make common user's comm private. Open sourcing only helps the power user (audit, run their own), as you described. Signal and iMessage both don't guarantee true privacy as we can't see the servers.
- zanny 9y ago
  No service that uses a third party server can guarantee privacy unless they let you see the servers. For common users the question is if you trust the server operator, and if not, to consider your communications insecure. What they do about that is up to them. And it is up to these providers to earn trust.
  - asadlionpk 9y ago
    > No service that uses a third party server can guarantee privacy unless they let you see the servers. And there are no services that do that. Since that doesn't seem to be possible. Open sourcing the backend doesn't help here since you still have to blindly trust the server operators.
  - dsacco 9y ago
    The problem with this is that it eliminates the value proposition of E2EE, which is designed specifically to protect you when you don't trust the server operator. If you already trust the server operator, you've obviated the issue that E2EE ostensibly solves.
  - 9y ago

CiPHPerCoder 9y ago

Client software (anything that runs on the user's device) should be open source for two reasons: 1. It's easier to audit, although binary analysis is still useful (and reverse engineers are often better at finding security holes than someone doing a source code review). 2. Reproducible builds. Server software doesn't need to be open source. If you have E2E in your open source software, you don't need to trust the servers at all: https://paragonie.com/blog/2016/03/client-authenticity-is-not-server-s-problem https://paragonie.com/blog/2016/03/client-authenticity-is-no...

pvg 9y ago
That seems like a very weak "should" and more of a "nice when it happens"
- CiPHPerCoder 9y ago
  My previous comment is RFC 2119 compliant.
  - pvg 9y ago
    That's 90's RFC technology! WOULD BE NICE is an unfortunate omission.