Return to Answer

Standards are not a reason to design insecure systems. While Apple has no control over the standard, they do have control over their systems.

Apple already gives security alerts when SSL-CERTS do not match the domain used. There's no reason why Apple could not give an alert if the display and response number for a SMS differ.

Further, their response that iMessage fixes this issue appears to show they knew of the issue, but decided not to design a solution for the iPhone's SMS system without breaking the SMS standards; which is possible, see the example below.

Here's an example of what an alert might look like that does not break the SMS standard, but warns the user via a security alert message:

UPDATE: The following is a summary of comments by Everett, and my response:

- Everett said, "Apple doesn't control the device that created the SMS message. Apple doesn't control the carriers device that relays the message. The only portion of the SMS chain that Apple controls, is the receiving device.", and I agree.

- Everett said, "With that being Apple's only point of control, it is unlikely they are willing to take on the liability of correcting someone else's bad implementation.", I disagree. Apple already gives end-users of SSL-CERTS that don't match the domain they are used on a warning message.

- Everett said, "By providing something that Apple controls end to end that doesn't have this issue, Apple has done exactly what it should for the customer AND not put themselves at risk.", and I disagree. Not giving an alert has nothing to do with correcting a system, nor does creating a system that does not work with SMS. Further, it appears Apple's statement points to the fact they were aware of the issue and failed to inform customers of the risk.

- Everett said, "By Apple FIXING an issue, they are accepting liability for the issue. Apple fixing it is saying, "we are aware of the problem that SMS presents, and we are willing to fix it, and are now liable for any problems with the fix!" That has cost companies in the past. Car companies did not install seat belts in cars until it was mandated. Why? Because it would appear to be an admission the car was unsafe, and therefore the company would be liable. Ask an attorney that specializes in business if I'm wrong.", and I disagree. As I've said before, Apple already gives end-users of SSL-CERTS that don't match the domain they are used on a warning message.

- Everett said, "To answer the ecosystem question, this is simple, Apple is only liable for their ecosystem, which they have designed end to end.", and I agree in part, but also disagree too. Apple is only liable for their ecosystem, though that also means consumers now know that Apple was aware of a security threat, decided not to create a solution, or warn customers. Saying you have to have end-to-end control of a system to attempt to address security threats within your system is not a view I believe helps consumers, or for that matter any company that provides a solution to them.

It's worth noting that it is possible to fix the issue without breaking the standard. Here's an example of what an alert might look like that does not break the SMS standard, but warns the user via a security alert message:

Standards are not a reason to design insecure systems. While Apple has no control over the standard, they do have control over their systems.

Apple already gives security alerts when SSL-CERTS do not match the domain used. There's no reason why Apple could not give an alert if the display and response number for a SMS differ.

Further, their response that iMessage fixes this issue appears to show they knew of the issue, but decided not to design a solution for the iPhone's SMS system without breaking the SMS standards; which is possible, see the example below.

Here's an example of what an alert might look like that does not break the SMS standard, but warns the user via a security alert message:

UPDATE: The following is a summary of comments by Everett, and my response:

- Everett said, "Apple doesn't control the device that created the SMS message. Apple doesn't control the carriers device that relays the message. The only portion of the SMS chain that Apple controls, is the receiving device.", and I agree.

- Everett said, "With that being Apple's only point of control, it is unlikely they are willing to take on the liability of correcting someone else's bad implementation.", I disagree. Apple already gives end-users of SSL-CERTS that don't match the domain they are used on a warning message.**

- Everett said, "By providing something that Apple controls end to end that doesn't have this issue, Apple has done exactly what it should for the customer AND not put themselves at risk.", and I disagree. Not giving an alert has nothing to do with correcting a system, nor does creating a system that does not work with SMS. Further, it appears Apple's statement point to the fact the were aware of the issue and flawed to inform customers of the risk.

- Everett said, "By Apple FIXING an issue, they are accepting liability for the issue. Apple fixing it is saying, "we are aware of the problem that SMS presents, and we are willing to fix it, and are now liable for any problems with the fix!" That has cost companies in the past. Car companies did not install seat belts in cars until it was mandated. Why? Because it would appear to be an admission the car was unsafe, and therefore the company would be liable. Ask an attorney that specializes in business if I'm wrong.", and I disagree. As I've said before, Apple already gives end-users of SSL-CERTS that don't match the domain they are used on a warning message.**

- Everett said, "To answer the ecosystem question, this is simple, Apple is only liable for their ecosystem, which they have designed end to end.", I agree Apple is only liable for their ecosystem, though that also means consumers now know that Apple was aware of a security threat, decided not to create a solution, or warn customers. Saying you have to have end-to-end control of a system to attempt to address security threats within your system is not a view I believe servers consumers, or for that matter any company that provides a solution to them.

Standards are not a reason to design insecure systems. While Apple has no control over the standard, they do have control over their systems.

Apple already gives security alerts when SSL-CERTS do not match the domain used. There's no reason why Apple could not give an alert if the display and response number for a SMS differ.

Further, their response that iMessage fixes this issue appears to show they knew of the issue, but decided not to design a solution for the iPhone's SMS system without breaking the SMS standards; which is possible, see the example below.

Here's an example of what an alert might look like that does not break the SMS standard, but warns the user via a security alert message:

UPDATE: The following is a summary of comments by Everett, and my response:

- Everett said, "Apple doesn't control the device that created the SMS message. Apple doesn't control the carriers device that relays the message. The only portion of the SMS chain that Apple controls, is the receiving device.", and I agree.

- Everett said, "With that being Apple's only point of control, it is unlikely they are willing to take on the liability of correcting someone else's bad implementation.", I disagree. Apple already gives end-users of SSL-CERTS that don't match the domain they are used on a warning message.

- Everett said, "By providing something that Apple controls end to end that doesn't have this issue, Apple has done exactly what it should for the customer AND not put themselves at risk.", and I disagree. Not giving an alert has nothing to do with correcting a system, nor does creating a system that does not work with SMS. Further, it appears Apple's statement points to the fact they were aware of the issue and failed to inform customers of the risk.

- Everett said, "By Apple FIXING an issue, they are accepting liability for the issue. Apple fixing it is saying, "we are aware of the problem that SMS presents, and we are willing to fix it, and are now liable for any problems with the fix!" That has cost companies in the past. Car companies did not install seat belts in cars until it was mandated. Why? Because it would appear to be an admission the car was unsafe, and therefore the company would be liable. Ask an attorney that specializes in business if I'm wrong.", and I disagree. As I've said before, Apple already gives end-users of SSL-CERTS that don't match the domain they are used on a warning message.

- Everett said, "To answer the ecosystem question, this is simple, Apple is only liable for their ecosystem, which they have designed end to end.", and I agree in part, but also disagree too. Apple is only liable for their ecosystem, though that also means consumers now know that Apple was aware of a security threat, decided not to create a solution, or warn customers. Saying you have to have end-to-end control of a system to attempt to address security threats within your system is not a view I believe helps consumers, or for that matter any company that provides a solution to them.

Standards are not a reason to design insecure systems. While Apple has no control over the standard, they do have control over their systems.

Apple already gives security alerts when SSL-CERTS do not match the domain used. There's no reason why Apple could not give an alert if the display and response number for a SMS differ.

Further, their response that iMessage fixes this issue appears to show they knew of the issue, but decided not to design a solution for the iPhone's SMS system without breaking the SMS standards; which is possible, see the example below.

Here's an example of what an alert might look like that does not break the SMS standard, but warns the user via a security alert message:

Standards are not a reason to design insecure systems. While Apple has no control over the standard, they do have control over their systems.

Apple already gives security alerts when SSL-CERTS do not match the domain used. There's no reason why Apple could not give an alert if the display and response number for a SMS differ.

Further, their response that iMessage fixes this issue appears to show they knew of the issue, but decided not to design a solution for the iPhone's SMS system without breaking the SMS standards; which is possible, see the example below.

Here's an example of what an alert might look like that does not break the SMS standard, but warns the user via a security alert message:

UPDATE: The following is a summary of comments by Everett, and my response:

- Everett said, "Apple doesn't control the device that created the SMS message. Apple doesn't control the carriers device that relays the message. The only portion of the SMS chain that Apple controls, is the receiving device.", and I agree.

- Everett said, "With that being Apple's only point of control, it is unlikely they are willing to take on the liability of correcting someone else's bad implementation.", I disagree. Apple already gives end-users of SSL-CERTS that don't match the domain they are used on a warning message.**

- Everett said, "By providing something that Apple controls end to end that doesn't have this issue, Apple has done exactly what it should for the customer AND not put themselves at risk.", and I disagree. Not giving an alert has nothing to do with correcting a system, nor does creating a system that does not work with SMS. Further, it appears Apple's statement point to the fact the were aware of the issue and flawed to inform customers of the risk.

- Everett said, "By Apple FIXING an issue, they are accepting liability for the issue. Apple fixing it is saying, "we are aware of the problem that SMS presents, and we are willing to fix it, and are now liable for any problems with the fix!" That has cost companies in the past. Car companies did not install seat belts in cars until it was mandated. Why? Because it would appear to be an admission the car was unsafe, and therefore the company would be liable. Ask an attorney that specializes in business if I'm wrong.", and I disagree. As I've said before, Apple already gives end-users of SSL-CERTS that don't match the domain they are used on a warning message.**

- Everett said, "To answer the ecosystem question, this is simple, Apple is only liable for their ecosystem, which they have designed end to end.", I agree Apple is only liable for their ecosystem, though that also means consumers now know that Apple was aware of a security threat, decided not to create a solution, or warn customers. Saying you have to have end-to-end control of a system to attempt to address security threats within your system is not a view I believe servers consumers, or for that matter any company that provides a solution to them.