Conversation
Write down the security mitigations in Chrome for other implementers to be aware.
| <li>If the security properties of <var>newContext</var> are | ||
| unsatisfactory (e.g., invalid certificate), then: | ||
| <ol> | ||
| <li>Reject <var>promise</var> with <a>SecurityError</a>.. |
There was a problem hiding this comment.
editorial: two periods after SecurityError.
| </li> | ||
| <li>If the SSL certificate of the payment handler page is not valid | ||
| (e.g., self-signed), the user agent may cancel the payment. | ||
| </li> |
There was a problem hiding this comment.
I think that is inconsistent with the algorithm definition, which forces abort. I suggest changing this to MUST.
| <li>If the security properties of <var>newContext</var> are | ||
| unsatisfactory (e.g., invalid certificate), then: | ||
| <ol> | ||
| <li>Reject <var>promise</var> with <a>SecurityError</a>.. |
There was a problem hiding this comment.
| <li>Reject <var>promise</var> with <a>SecurityError</a>.. | |
| <li>Reject <var>promise</var> with <a>SecurityError</a>. |
| </li> | ||
| </ol> | ||
| </li> | ||
| <li>If the security properties of <var>newContext</var> are |
There was a problem hiding this comment.
This seems overly vague. Maybe @domenic can suggest better wording for this? It might be a simple as saying "not a secure context" or something link that.
There was a problem hiding this comment.
It's unclear from @rsolomakhin's text whether insecure HTTP pages are rejected or not. Invalid certificates will fail a navigation, so that would happen before this step.
If the intent is to disallow insecure HTTP, then the wording would be newContext's active document's relevant settings object is contextually secure.
| </li> | ||
| </ul> | ||
| </section> | ||
| <section> |
There was a problem hiding this comment.
This whole section doesn't feel right in this spec.
|
Thank you for the review, @domenic , @ianbjacobs , and @marcoscaceres ! My intention here is to block both HTTP (non-secure) pages and HTTPS pages where certificates are self-signed, expired, revoked, and so on. I would encourage user agent implementers to clamp this down as much as possible. For example, take a look at https://badssl.com. Many of the red-color links there lead to pages with questionable security. Chrome will display an interstitial, but users can sometimes bypass this interstisial by clicking on [Advanced]->"Proceed (unsafe)". After the user has bypassed the interstitial, Chrome treats the page as secure, but I am proposing to make an exception for payments-related API. Payment Handler and Payment Request should not work with questionable HTTPS states. What is the best phrasing to use in this pull request to achieve this goal? |
4 participants
Write down the security mitigations in Chrome for other implementers to
be aware.
The following tasks have been completed:
Implementation commitment:
Preview | Diff