W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2012

Re: New full Unicode for ES6 idea

From: David Bruant <bruant.d@gmail.com>
Date: Sun, 19 Feb 2012 21:29:48 +0100
Message-ID: <4F415BBC.1040002@gmail.com>
To: Brendan Eich <brendan@mozilla.com>
CC: es-discuss <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, mranney@voxer.com
Le 19/02/2012 09:33, Brendan Eich a écrit :
> (...)
>
> How is the BRS configured? Again, not via a pragma, and not by
> imperative state update inside the language (mutating hidden BRS state
> at a given program point could leave strings created before mutation
> observably different from those created after, unless the
> implementation in effect scanned the local heap and wrapped or copied
> any non-BMP-char-bearing ones creatd before).
>
> The obvious way to express the BRS in HTML is a <meta> tag in document
> <head>, but I don't want to get hung up on this point. I do welcome
> expert guidance. Here is another W3C/WHATWG interaction point. For
> this reason I'm cc'ing public-script-coord.
I'm not sure a <meta> is that obvious of a choice.

A bit of related experience about <meta>s:
At the end of 2011, I started a thread [1] about the meta referrer [2].
One use case for it would be to set the value to "never" so that you
declare that document-wise, no HTTP "referer" header should be sent when
downloading a script/stylesheet/image or clicking a link/posting a form.
An intervention by Simon Pieters [3] mentionned speculative parsing and
the fact that resources may be fetched *before* the meta is read, hence
leaking the referer while the intention of the author might have been
that there should be no leak.
Since there seems to be no satisfying HTML-based solution for this, I
suggested [4] that it's when the document is delivered by the server
that the server should express how the document should behave regarding
sending referer headers.
The discussion ended by Adam Barth agreeing [5] and planning to propose
this for CSP 1.1 (That's how I learned about CSP [6]).

Unless I'm missing something, I think the same discussion can be had
about the BRS being declared as a <meta>. Consider:

    <script>
    // some code that can observe the difference between BRS mode and
non-BRS
    </script>
    <meta BRS>

Should the browser read all <meta>s before executing any script? Worse:
what if an inline script does "document.write('<meta BRS>')"?

I think a CSP-like solution should be explored.

As a side note, after some time studying the Content Security Policy
(CSP), I came to realize that it doesn't have to be related security
(though that's what motivated it in the first place) and could be
considered as a "Content Delivery Policy", offering space to break
semantics and repair things that would be worth the cost of the opt-in
(like the script execution rules or when the referer header is sent).

Worth exploring for the BRS or certainly a lot of other things.

David

[1]
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-December/034275.html
[2] http://wiki.whatwg.org/index.php?title=Meta_referrer
[3]
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-January/034283.html
[4]
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-January/034522.html
[5]
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-January/034523.html
[6]
https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html
Received on Sunday, 19 February 2012 20:30:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:05 UTC