W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2014

[MIX] RfC: WebAppSec's Last Call Working Draft of Mixed Content; deadline December 11

From: <timeless@gmail.com>
Date: Tue, 11 Nov 2014 02:33:24 -0500
Message-ID: <20141111073324.36163670.93179.5591@gmail.com>
To: public-webappsec@w3.org
http://www.w3.org/TR/mixed-content/#intro<br/><br/>&gt; 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 =&gt; received / sent || receiving / sending <br/><br/>http://www.w3.org/TR/mixed-content/#terms-defined-here<br/><br/>&gt; private URL<br/>&gt; An origin is considered a private origin if any of the following conditions holds:<br/>&gt; • The origin’s scheme component is file.<br/>&gt; • 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/>&gt; • 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/>&gt; deprecated TLS-protection<br/>&gt; 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/>&quot;Not&quot; here is ambiguous. I can read this as &quot;A resource’s TLS-protection is said to be deprecated if it is strongly TLS-protected&quot;<br/><br/>&gt; 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 ‎&quot;[RFC1918].‎&quot; above. <br/><br/>Note: the document is inconsistent, you need to pick and enforce a style -- my preference is as I&apos;m recommending here, however consistency trumps. <br/><br/>&gt; 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 &quot;taint&quot; bits?<br/><br/>&gt; 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/>&gt; 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 =&gt; their<br/><br/>&gt; 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/>&gt; If an attacker reversed the &quot;Delete email&quot; and &quot;Reply&quot; icons, there would be real impact on users. <br/><br/>on =&gt; to<br/><br/>&gt; The working group intends to find more blockable subsets of an otherwise optionally-blockable request context.<br/><br/>working group =&gt; Working Group <br/><br/>http://www.w3.org/TR/mixed-content/#category-blockable<br/><br/>&gt; 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 =&gt; and<br/><br/>http://www.w3.org/TR/mixed-content/#categories-unknown-content<br/><br/>&gt; 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 =&gt; each || if a request context is not...<br/><br/>http://www.w3.org/TR/mixed-content/#requirements-fetching<br/><br/>&gt; 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 &quot;or&quot;, the list only has two items...<br/><br/>&gt; 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 &quot;its&quot; is ambiguous, or at least potentially confused. Try &quot;the global environment&apos;s&quot;. <br/><br/>&gt; 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 =&gt; all such content <br/><br/>http://www.w3.org/TR/mixed-content/#requirements-ux<br/><br/>&gt; 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/>&gt; This requirement explicitly includes any visible indication of the top-level browsing context’s EV status. [CAB]<br/><br/>This doesn&apos;t make sense. Please reword. <br/><br/>&gt; 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/>&gt; 1. Let ancestorEnvironment be the JavaScript global environment associated with ancestorContext<br/><br/>Missing period <br/>‎<br/>&gt; 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/>&gt; 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/>&gt; (e.g. because the response is for blockable content, but the server is insecure).<br/><br/>server =&gt; connection <br/><br/>http://www.w3.org/TR/mixed-content/#conformance-classes<br/><br/>&gt; 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/>&gt; A conformant server must implement all the requirements listed in this specification that are applicable to servers.<br/><br/>I can&apos;t find any such requirements. <br/><br/><br/><br/>
Received on Tuesday, 11 November 2014 07:33:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:07 UTC