- From: <timeless@gmail.com>
- Date: Tue, 11 Nov 2014 02:33:24 -0500
- To: public-webappsec@w3.org
http://www.w3.org/TR/mixed-content/#intro<br/><br/>> Together, these assertions give the user some assurance that example.com is the only entity that can read and respond to her requests (caveat: without shocking amounts of work) and that the bits she’s receiving are indeed those that example.com actually sent.<br/><br/>Tense disagreement: receiving / sent => received / sent || receiving / sending <br/><br/>http://www.w3.org/TR/mixed-content/#terms-defined-here<br/><br/>> private URL<br/>> An origin is considered a private origin if any of the following conditions holds:<br/>> • The origin’s scheme component is file.<br/>> • The origin’s host component is localhost, or matches one of the CIDR notations 127.0.0.0/8 or ::1/128 [RFC4632]<br/><br/>This sentence is missing its period. <br/><br/>> • The origin’s host component matches one of the private address space patterns defined in Section 3 of RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) [RFC1918].<br/><br/><br/>> deprecated TLS-protection<br/>> A resource’s TLS-protection is said to be deprecated if it is not weakly TLS-protected, but the user agent chooses to refuse it anyway. <br/><br/>"Not" here is ambiguous. I can read this as "A resource’s TLS-protection is said to be deprecated if it is strongly TLS-protected"<br/><br/>> For example, a user agent may choose to reject resources for which the server presented a publicly-trusted certificate for an Internal Name (e.g. https://intranet/), a certificate with an overly-long validity period, a certificate signed with SHA-1, or a certificate which otherwise fails to meet the CA/Browser Forum’s Baseline Requirements. [CAB]<br/><br/>Please move [CAB] before the period to match "[RFC1918]." above. <br/><br/>Note: the document is inconsistent, you need to pick and enforce a style -- my preference is as I'm recommending here, however consistency trumps. <br/><br/>> An origin can be called authenticated when it either refers to a source which is impossible not to trust (e.g. localhost), <br/><br/>File:///localhost/Users/untrusted/Public/index.html<br/>File:///localhost/Volumes/downloaded-disk-image/index.html<br/>Http://localhost:9234/<br/><br/>Perhaps some notes about objects not owned / owned by the current user, and lacking any "taint" bits?<br/><br/>> or to a source which can be adequately verified as authentic.<br/><br/>http://www.w3.org/TR/mixed-content/#terms-defined-by-reference<br/>> Weakly TLS-protected refers to a subset of those resources delivered over a channel that doesn’t offer strong protection of the content.<br/><br/>the => their<br/><br/>> These terms are defined in Section 6.1.3.1 of the HTML5 specification. [[!!HTML5]]<br/><br/>Markup?<br/><br/>http://www.w3.org/TR/mixed-content/#categories<br/><br/>Unfortunately, that is impractical on today’s internet. <br/><br/>The Internet is still a proper noun today. <br/><br/>http://www.w3.org/TR/mixed-content/#category-optionally-blockable<br/><br/>> If an attacker reversed the "Delete email" and "Reply" icons, there would be real impact on users. <br/><br/>on => to<br/><br/>> The working group intends to find more blockable subsets of an otherwise optionally-blockable request context.<br/><br/>working group => Working Group <br/><br/>http://www.w3.org/TR/mixed-content/#category-blockable<br/><br/>> Scripts (loaded, for example, via script elements, as well as scripts loaded as Workers and SharedWorkers [WORKERS], or ServiceWorkers [SERVICEWORKERS]) [ECMA-262]<br/><br/>or => and<br/><br/>http://www.w3.org/TR/mixed-content/#categories-unknown-content<br/><br/>> To that end, any request context which is not explicitly listed in the preceeding content categories MUST be considered a blockable request context.<br/><br/>any => each || if a request context is not...<br/><br/>http://www.w3.org/TR/mixed-content/#requirements-fetching<br/><br/>> User agents SHOULD reject weakly TLS-protected resources entirely by failing the TLS handshake, or by requiring explicit user acceptance of the risk. <br/><br/>Drop the comma before "or", the list only has two items...<br/><br/>> If a global environment restricts mixed content, then user agents MUST adhere to the following requirements when fetching resources in response to its requests<br/><br/>Most documents talk to a single UA at a time, why plural here? <br/><br/>I think "its" is ambiguous, or at least potentially confused. Try "the global environment's". <br/><br/>> Note: For instance, a user agent could interpret the presence of a Strict-Transport-Security header field as forcing all content into the blockable category.<br/><br/>all content => all such content <br/><br/>http://www.w3.org/TR/mixed-content/#requirements-ux<br/><br/>> If a request for an optionally-blockable resource which is mixed content is not treated as blockable, then the user agent MUST NOT provide the user with a visible indication that the top-level browsing context which loaded that resource is secure (for instance, via a green lock icon).<br/><br/>The parenthetical here is confusing. <br/><br/>If a UA would normally show a visible indication that the top-level browsing context which loaded that resource is secure (for instance, via a green lock icon), then when the UA encounters a request for an optionally-blockable resource which is mixed content is not treated as blockable, then the user agent MUST NOT provide the user with that same visible indication. <br/><br/>> This requirement explicitly includes any visible indication of the top-level browsing context’s EV status. [CAB]<br/><br/>This doesn't make sense. Please reword. <br/><br/>> User agents MAY offer users the ability to override its decision to block blockable mixed content on a particular page.<br/><br/>Agreement: UAs / its. Use singular (article +) UA to solve. <br/><br/>http://www.w3.org/TR/mixed-content/#categorize-environment<br/><br/><br/>> 1. Let ancestorEnvironment be the JavaScript global environment associated with ancestorContext<br/><br/>Missing period <br/><br/>> 2. If ancestorEnvironment is TLS-protected, and that TLS-protection is neither weak nor deprecated, then return true.<br/><br/>http://www.w3.org/TR/mixed-content/#should-block-fetch<br/><br/>> Given a request request, a user agent determines whether the Request request should proceed or not via the following algorithm:<br/><br/>Why only capitalize the second Request request? <br/><br/>http://www.w3.org/TR/mixed-content/#should-block-response<br/><br/>> (e.g. because the response is for blockable content, but the server is insecure).<br/><br/>server => connection <br/><br/>http://www.w3.org/TR/mixed-content/#conformance-classes<br/><br/>> A conformant user agent must implement all the requirements listed in this specification that are applicable to user agents.<br/><br/>Clearly this implies that the document should refer to UA and not UAs. <br/><br/>> A conformant server must implement all the requirements listed in this specification that are applicable to servers.<br/><br/>I can't find any such requirements. <br/><br/><br/><br/>
Received on Tuesday, 11 November 2014 07:33:53 UTC