Changes between Initial Version and Version 1 of Ticket #25658, comment 34


Ignore:
Timestamp:
Oct 26, 2018, 1:11:14 PM (12 months ago)
Author:
gk
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #25658, comment 34

    initial v1  
    4040> OFF: HTTP protected, HTTPS unprotected
    4141
    42 The security risks don't map the the underlying transport ot its security being used. The security risks we try to tackle are to a large part due to the *content* that gets transferred. Someone injecting this content on the path from server to user is an important risk but just one of those we need to defend against. This binding the security state to HTTP/HTTPS is not sufficient. Moreover, the strongest security we want to provide is something like the current "safest" option we have. We won't be able to enable this by default probably forever as the breakage is too high, irrespective of the transport being used.
     42The security risks don't map the the underlying transport (or its security) being used. The security risks we try to tackle are to a large part due to the *content* that gets transferred. Someone injecting this content on the path from server to user is an important risk but just one of those we need to defend against. Thus, binding the security state to HTTP/HTTPS is not sufficient. Moreover, the strongest security we want to provide is something like the current "safest" option we have. We won't be able to enable this by default probably forever as the breakage is too high, irrespective of the transport being used.
    4343
    4444Additionally, see section 3.3 of the design proposal linked to above.