- From: timeless <timeless@gmail.com>
- Date: Tue, 11 Nov 2014 03:02:52 -0500
- To: public-webappsec@w3.org
http://www.w3.org/TR/mixed-content/#intro > 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. Tense disagreement: receiving / sent => received / sent || receiving / sending http://www.w3.org/TR/mixed-content/#terms-defined-here > private URL > An origin is considered a private origin if any of the following conditions holds: > • The origin’s scheme component is file. > • The origin’s host component is localhost, or matches one of the CIDR notations 127.0.0.0/8 or ::1/128 [RFC4632] This sentence is missing its period. > • 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]. > deprecated TLS-protection > 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. "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" > 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] Please move [CAB] before the period to match "[RFC1918]." above. Note: the document is inconsistent, you need to pick and enforce a style -- my preference is as I'm recommending here, however consistency trumps. > An origin can be called authenticated when it either refers to a source which is impossible not to trust (e.g. localhost), File:///localhost/Users/untrusted/Public/index.html File:///localhost/Volumes/downloaded-disk-image/index.html Http://localhost:9234/ Perhaps some notes about objects not owned / owned by the current user, and lacking any "taint" bits? > or to a source which can be adequately verified as authentic. http://www.w3.org/TR/mixed-content/#terms-defined-by-reference > Weakly TLS-protected refers to a subset of those resources delivered over a channel that doesn’t offer strong protection of the content. the => their > These terms are defined in Section 6.1.3.1 of the HTML5 specification. [[!!HTML5]] Markup? http://www.w3.org/TR/mixed-content/#categories Unfortunately, that is impractical on today’s internet. The Internet is still a proper noun today. http://www.w3.org/TR/mixed-content/#category-optionally-blockable > If an attacker reversed the "Delete email" and "Reply" icons, there would be real impact on users. on => to > The working group intends to find more blockable subsets of an otherwise optionally-blockable request context. working group => Working Group http://www.w3.org/TR/mixed-content/#category-blockable > Scripts (loaded, for example, via script elements, as well as scripts loaded as Workers and SharedWorkers [WORKERS], or ServiceWorkers [SERVICEWORKERS]) [ECMA-262] or => and http://www.w3.org/TR/mixed-content/#categories-unknown-content > To that end, any request context which is not explicitly listed in the preceeding content categories MUST be considered a blockable request context. any => each || if a request context is not... http://www.w3.org/TR/mixed-content/#requirements-fetching > User agents SHOULD reject weakly TLS-protected resources entirely by failing the TLS handshake, or by requiring explicit user acceptance of the risk. Drop the comma before "or", the list only has two items... > If a global environment restricts mixed content, then user agents MUST adhere to the following requirements when fetching resources in response to its requests Most documents talk to a single UA at a time, why plural here? I think "its" is ambiguous, or at least potentially confused. Try "the global environment's". > 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. all content => all such content http://www.w3.org/TR/mixed-content/#requirements-ux > 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). The parenthetical here is confusing. 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. > This requirement explicitly includes any visible indication of the top-level browsing context’s EV status. [CAB] This doesn't make sense. Please reword. > User agents MAY offer users the ability to override its decision to block blockable mixed content on a particular page. Agreement: UAs / its. Use singular (article +) UA to solve. http://www.w3.org/TR/mixed-content/#categorize-environment > 1. Let ancestorEnvironment be the JavaScript global environment associated with ancestorContext Missing period > 2. If ancestorEnvironment is TLS-protected, and that TLS-protection is neither weak nor deprecated, then return true. http://www.w3.org/TR/mixed-content/#should-block-fetch > Given a request request, a user agent determines whether the Request request should proceed or not via the following algorithm: Why only capitalize the second Request request? http://www.w3.org/TR/mixed-content/#should-block-response > (e.g. because the response is for blockable content, but the server is insecure). server => connection http://www.w3.org/TR/mixed-content/#conformance-classes > A conformant user agent must implement all the requirements listed in this specification that are applicable to user agents. Clearly this implies that the document should refer to UA and not UAs. > A conformant server must implement all the requirements listed in this specification that are applicable to servers. I can't find any such requirements. -- This review was sent in response to: http://lists.w3.org/Archives/Public/public-review-announce/2014Nov/0001.html
Received on Tuesday, 11 November 2014 08:03:18 UTC