Mixed Content ED Comments

The following comments apply to the 02 July 2014 ED.

   1. Suggest changing "JavaScript" to "ECMAScript" throughout, or making
   it a more generic "Script", though an exception may be necessary for
   "JavaScript global environment" since that is the term used in HTML5.
   Alternatively, provide a note somewhere indicating that references to
   "JavaScript" refer to "ECMAScript" as defined by [ECMA-262].
   2. Under 2.1, suggest changing the first bullet under "mixed content" to
   read "... and the origin of the JavaScript global environment into which
   it is loaded is a secure context." This way, both definitions of mixed
   content are defined in terms of comparing properties of two origins.
   3. Under 2.1, link to CA/Browser Forum's Baseline Requirements should be
   redirected through Normative References section, as the referenced
   definition of the host component is used normatively by this spec.
   4. Under 2.1, definition of potentially secure origin, the Note has
   language "will take place" that sounds rather normative (even though it
   doesn't use an RFC2119 keyword). Suggest changing "will take place" to "
   takes place" or consider making this language a normative requirement.
   5. Under 2.1, definition of potentially secure origin, suggest changing
   in Note from "should simplify assumptions of" to "simplifies assumptions
   about".
   6. Under 2.1, definition of deprecated TLS-protection, the language
   "resources from that origin" is ambiguous with respect to how many (or the
   nature of the) resources that satisfy a condition for labeling that origin
   as insecure due to being weakly TLS-protected or using deprecated
   TLS-protection. For example, if 1 out of a 1,000 resources returned by that
   origin satisfy this condition, then should it be labeled as insecure for
   this cause? 1 out of 1,000,000? Can an origin previously labeled as
   insecure for this cause be later upgraded to secure, e.g., because the next
   1,000 or 1,000,000 etc. resources do not trigger this condition?
   7. Under 2.2, change label "plugin" to "plugin document".
   8. Under 2.2, definition of "TLS-protected", the link *Section 5.2 of
   "Web Security Context: User Interface Guidelines"*, should have the link
   to [WSC-UI] placed immediately after this reference instead of at the end
   of the paragraph.
   9. Under 2.2, definition of "TLS-protected", 1st paragraph, suggest
   removing the informal "In short".
   10. Under 2.2, definition of "TLS-protected", the phrases "strong
   protection", "self-signed certificate", "weakly authenticates", and "weak
   cipher suite" are not well defined nor refer to an external definition
   (even though one might expect readers to infer definitions).
   11. Under 2.2, definition of "TLS-protected", the Note containing the
   language "*strongly recommended*" is problematic because it is
   attempting to make what would normally be considered a normative
   recommendation, i.e., a normative SHOULD, but is doing so in the context of
   an informative note. If there is going to be a recommendation as such, then
   suggest it should be made a normative recommendation and use SHOULD.
   12. Under 2.2, definition of "TLS-protected", the Note uses the term
   *interstitial*, which does not refer to a definition nor is it a
   commonly understood English language term as used in this special fashion.
   13. Under 2.2, definition of globally unique identifier, suggest
   changing "Section 4 of the Origin specification" to read "RFC6454 §4" to
   better correspond with the reference "[RFC6454]" at the end of the
   definition.
   14. Under 2.2, definition of globally unique identifier, suggest moving
   "Note that URLs ..." into an actual Note.
   15. Under 2.2, definitions of fetch, request, response, suggest changing
   "Fetch living standard" to "Fetch specification". Also, a plan will be
   needed to move this work to a W3C REC track specification.
   16. Under 2.2, definition of "JavaScript global environment", the link
   "Section 2.2.2" does not point at the HTML5 specification, but at this
   definition itself.
   17. Sections entitled Conformance, References, Index, and Issues Index
   need to be labeled as numbered or lettered appendices.
   18. Under Normative References, the reference to HTML5 is out of date,
   and needs to be updated to at least the current "latest" edition, namely
   http://www.w3.org/TR/html5/ or http://www.w3.org/html/wg/drafts/html/CR/.
   19. Under 3, Categories of Content, this entire section reads like a
   back-of-napkin draft of a white paper; it is clearly couched in
   non-specification language of a non-normative nature; suggest it be labeled
   non-normative until it is completely rewritten.
   20. Under 3, Categories of Content, the term *navigational request
   context* is not defined.
   21. Under 3.1, Active Content, the characterization of "active content"
   is highly questionable; in particular, style sheets, SVG documents that
   don't contain script, XSL transformations, and HTML Manifests definitely *do
   not* satisfy the common understanding of active content as being
   executable code, e.g., see NIST's Guidelines on Active Content and
   Mobile Code
   <http://csrc.nist.gov/publications/nistpubs/800-28-ver2/SP800-28v2.pdf>,
   as well as the earlier definition of *active object content* in DASE
   Part 1 §3.3 <http://www.atsc.org/cms/standards/a100/a_100_1.pdf>, and
   prior use with ActiveX <http://en.wikipedia.org/wiki/ActiveX>;
   furthermore, the claim at the top of "completely control the activity on a
   webpage and exfiltrate data at will" is not true for many of these types.
   If these types are desired to be associated with the same category as
   Scripts, then the category needs to be renamed and given a new, more
   accurate description. I would also note the absence of WebGL, i.e.,
   OpenGL, Shader Language
   <http://en.wikipedia.org/wiki/OpenGL_Shading_Language> in this list,
   which is executable code, though processed in a special sandbox. Perhaps
   "Content Mapped to Fetch Request Contexts" is a better name here than
   "Active Content" since it seems that is where this list is being obtained.
   I notice that Section 3.3 is labeled Future Contexts, so the term "Context"
   here appears more appropriate than "Content Category.
   22. Under 3.2.2, please explain the risk presented by subtitles and
   captions loaded via <track> elements. I would question categorizing this
   content as blockable as opposed to optionally blockable.
   23. Under 4.1, step 2, change "Requests for" to "Responses to requests
   for".
   24. Under 4.1, step 4, the language "MAY be modified" is entirely too
   vague with respect to what modifications are permitted or recommended.
   25. Under 4.1, in the second step 1 (about private/public origins), the
   restraint on generating network traffic may be insufficient to handle file:
   and localhost origins.
   26. Under 4.2, items 1 through 3 need citations to specific sections of
   XHR, SSE, and WEBSOCK.
   27. Under 4.2, item 2, typo s/provessing/processing/.
   28. Under 4.3, 1st paragraph, combine first paragraph and second
   paragraph to use a single MUST NOT instead of combining "MUST adhere to"
   followed by "MUST NOT".
   29. Under 4.3, need citation and reference for "EV status" link.
   30. Under 4.4, the first Note should be removed. W3C specs don't make
   recommendations to end users.
   31. Under 4.4, the second Note must not use the RFC2119 keyword phrase
   SHOULD NOT. Further, the language of this note if overly informal.
   32. Under 5.1, the use of the term *environment* is problematic because
   in the algorithm steps, the environment is said to be TLS-protected or not,
   however the definition of TLS-protected applies to a resource (from an
   origin) and not an environment. It feels like this algorithm should be
   called "Is *origin* secure?". See also comment 2 above.
   33. Under 5.1, 1st paragraph, change "can determine if" to "determines
   if".
   34. Under 5.1, 1st paragraph, remove the logically redundant ", which
   returns true if environment is a secure context, and false otherwise".
   It is redundant since the following steps say as much.
   35. Under 5.1, the phrase "If a document is framed" is not well defined,
   i.e., what is meant by "is framed"? Further, this paragraph seems overly
   informal: is it intended to be non-normative? If so, then perhaps it should
   go into a Note.
   36. Under 5.1, Example 4, the term "frames" needs a definition.
   37. Under 5.1, Example 5, the term "framed data URL" needs a definition.
   38. Under 5.2, 1st paragraph, the term "should" appears. Is it intended
   that this be a RFC2119 "SHOULD"?
   39. Under 5.2, 1st paragraph, what is meant by "entirely"? Does it imply
   that it may instead "partially block requests"?
   40. Under 5.2, 1st paragraph, it seems unusual to say what the Fetch
   specification will do with this algorithm. Overall, this 1st paragraph is
   overly informal and sounds like non-normative content.
   41. Under 5.2, 2nd paragraph, change "can determine whether" to "
   determines whether".
   42. Under 5.2, 2nd paragraph, the fragment "whether the should proceed"
   seems to want to be read as "whether the request should proceed". Also
   need to add a COLON at end of this paragraph.
   43. Under 5.2, step 6 may need tweaking regarding the term *environment*;
   i.e., is it the *environment* that is secure or the origin associated
   with the environment that is secure? See also step 7 which talks about the
   *origin* being *a priori insecure*. There seems to be a general
   confusion around environment or origin when making statements about secure
   or insecure. See also step 8 which talks about *origin* being
   potentially secure.
   44. Under 5.3, 1st paragraph is overly informal "we still might want
   to", etc. Needs rewriting and potentially labeling as non-normative.
   45. Under 5.3, 2nd paragraph, change "can determine what" to "determines
   what".
   46. Under 5.3, step 3, same comment about *environment* vs *origin* secure
   confusion as described in comment 43 above.
   47. Under 6, change "The Fetch algorithm MUST be updated as follows" to
   read "The Fetch algorithm is modified as follows". W3C specs don't place
   requirements on other spec writers, but on interpretations or
   implementations.
   48. Under 6, the phrase "current Fetch algorithm" is problematic,
   particularly since it is a moving target by definition (a so-called "living
   standard").
   49. Under 7, 1st paragraph, rewrite to read simply as follows "The
   WebSocket() constructor algorithm [WEBSOCKETS] is modified as follows:"
   followed by the first bullet "Replace Step 2 ...", then introduce a new
   paragraph "The WebSocket Connection algorithm [WSP] is modified as
   follows:" followed by the second bullet "After step 5 ...".
   50. Under 8, Acknowledgements, this material is background material and
   not the usual acknowledgements of individuals contributing to the
   specification. Suggest moving it into the introduction and adding a list of
   individual contributors to this work.
   51. Under unnumbered "Conformance", suggest moving this material to a
   numbered section before Section 4 User Agent Requirements, or to be the
   first sub-heading under Section 4.
   52. Under unnumbered "Conformance", what requirements listed in this
   specifications apply to servers? If none, then remove "conformant server".
   53. Under Normative References, there may be a better citation than
   [CSS-2010] to refer to stylesheets, particularly since that document is
   rather out of date.
   54. Under Normative References, no reference is (yet) made to ECMA-262
   (but see comment 1 above).