There is another ADsafe demonstration widget at
http://adsafe.org/sudoku.html

Douglas Crockford wrote:
>
>
> There is another ADsafe demonstration widget at
> http://adsafe.org/sudoku.html <http://adsafe.org/sudoku.html>

Doesn't seem to work correctly in Chrome (for example, no play button).

--
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Works for me in Chrome.

--
Alan Karp

douglas@... (Douglas Crockford) on Wednesday, October 8, 2008 wrote:

>There is another ADsafe demonstration widget at
>http://adsafe.org/sudoku.html

Seems to work on Safari.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        |"We used to quip that "password" is the most common
408-356-8506       | password. Now it's 'password1.' Who said users haven't
www.periwinkle.com | learned anything about security?" -- Bruce Schneier

Alan Karp wrote:
>
>
> Works for me in Chrome.

Hmm. On second attempt it worked for me, too. Odd.

--
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

I've noticed that Chrome gets addled if it's been open for many days.
This morning mine lost its ability to talk to the network, but I've
seen other symptoms.  Closing and restarting has always resolved any
problems.

--
Alan Karp

I implemented PPK's focus hack
(http://www.quirksmode.org/blog/archives/2008/04/delegating_the.html)
in ADsafe, so focus and blur events may now be delegated.

Live Labs has released a public preview of their Javascript sandbox.

http://websandbox.livelabs.com/

See the clock sample:
http://websandbox-code.org/Samples/ClockSample.aspx

There's also a delightful Breakout clone working in the sandbox and you can
visit the same
page in your browser with no virtualization and it still works:
http://LiveLabs.com/BlockBash.html

I added another sample page. This one shows two simple widgets that
coexist.

http://adsafe.org/roman.html

The w3c Technical Architecture Group (TAG) discuss ocaps for the web starting at
http://www.w3.org/2001/tag/2008/12/10-minutes#item03

teaser sample:
'DO: SW and I got invloved in this spec a while ago.... We tried to
push them to Tyler approach. We got pushback. Then they decided to do
usecases and reqmnts. Stuart and I looked at their docs and asked
"what does the algorithm do"? If we got enough people in WG that
wanted something different we could get something done. Need to muster
support for a coherent position.'

--
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM

erights@... (Mark Miller) on Monday, January 5, 2009 wrote:

>The w3c Technical Architecture Group (TAG) discuss ocaps for the web starting
at
>http://www.w3.org/2001/tag/2008/12/10-minutes#item03

For me, the highlight was, "Crockford says add a switch in Firefox to
disable non-adSafe ads". If this feature gets adopted, and used, we'll see
an overnight change in Javascript style. :-)

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | When it comes to the world     | Periwinkle
(408)356-8506      | around us, is there any choice | 16345 Englewood Ave
www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032

At the end of the minutes, it looks like the TAG is casting about for
a next step. One useful step would be to consider amending the
web-arch document's discussion of access-control:

http://www.w3.org/TR/webarch/#id-access

The access-control section is at odds with the core architectural
principles set forth in the web-arch document. These contradictions
are the main topic of my web-key paper:

http://waterken.sourceforge.net/web-key/

Resolving the inconsistencies in the TAG's current public stance on
access-control might make it easier to adopt alternate solutions like
the web-key.

--Tyler

On Mon, Jan 5, 2009 at 1:14 PM, Mark Miller <erights@...> wrote:
>
> The w3c Technical Architecture Group (TAG) discuss ocaps for the web starting
at
> http://www.w3.org/2001/tag/2008/12/10-minutes#item03
>
> teaser sample:
> 'DO: SW and I got invloved in this spec a while ago.... We tried to
> push them to Tyler approach. We got pushback. Then they decided to do
> usecases and reqmnts. Stuart and I looked at their docs and asked
> "what does the algorithm do"? If we got enough people in WG that
> wanted something different we could get something done. Need to muster
> support for a coherent position.'
>
> --
> Text by me above is hereby placed in the public domain
>
>    Cheers,
>    --MarkM
>

Previous W2SP Workshops: 2008, 2007

The goal of this one day workshop is to bring together researchers and practitioners from academia and industry to focus on understanding Web 2.0 security and privacy issues, and establishing new collaborations in these areas.

Web 2.0 is about connecting people and amplifying the power of working together. Enabled by a wave of new technology, these social and business interactions rely on composition of content and services from multiple sources, commonly called mash-ups, leading to systems with complex trust boundaries. This trend is likely to continue because individuals and businesses desire the efficiency and simplicity these technologies offer.

Together with their virtues, these technologies raise issues about management of identities, reputation, privacy, anonymity, transient and long term relationships, and composition of function and content, both on the server and on the client (web browser). Although the underlying security and privacy issues are not new, the use of these technologies on a wide scale and by a broad audience raises new questions. This workshop is intended to discuss the limitations of current technologies and explore alternatives.

The scope of W2SP 2009 includes, but is not limited to:

• Trustworthy cloud-based services
• Privacy and reputation in social networks
• Usable security and privacy
• Security for the mobile web
• Identity management and psuedonymity
• Advertisement and affiliate fraud
• Provenance and governance
• Security and privacy as a service
• Web services/feeds/mashups
• Security and privacy policies for composible content
• Next-generation browser technology

Workshop Co-Chairs

• Larry Koved (IBM Research)
• Dan S. Wallach (Rice University)

• Adam Barth (UC Berkeley)

• Ben Adida (Harvard University)
• Dirk Balfanz (PARC)
• Adam Barth (UC Berkeley)
• Konstantin (Kosta) Beznosov
• Suresh Chari (IBM Research)
• Hao Chen (UC Davis)
• Douglas Crockford (Yahoo)
• Chris Karlof (UC Berkeley)
• Larry Koved (IBM Research)
• Shriram Krishnamurthi (Brown University)
• Collin Jackson (Stanford University)
• Rob Johnson (Stony Brook University)
• John C. Mitchell (Stanford University)
• Sean W. Smith (Dartmouth University)
• Helen Wang (Microsoft Research)
• Dan S. Wallach (Rice University)

Paper submission deadline: March 6, 2009, (11:59pm US-Eastern)
Workshop acceptance notification date: March 31, 2009
Workshop date: Thursday, May 21, 2009

Workshop paper submission web site: To be announced.

At

   http://wiki.ecmascript.org/doku.php?id=ses:ses_proposal_working_draft

is posted a very rough first draft for a "Secure ECMAScript" standard,
derived from the "Mountain View draft" of ES3.1
<http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft>
and from Cajita. I hope and believe that we can resolve differences
between this and other contenders for the Cajita-like layer: ADsafe,
Jacaranda, and Dojo Secure. (As for the Valija-like layer, both Valija
and MS WebSandbox intend to emulate at least ES3.1-strict, so there's
no need for a separate standard for that layer.)

Further discussion of SES specifically should proceed on the "caplet
group" list.

--
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Do you have an overview of the differences between SES and ES3.1 (or
maybe it is easier to define the differences between SES and Cajita)?
I see a lot of [[Prototype]] -> [[Parent]] changes, but maybe you
could summarize the important differences?
Kris

Mark Miller wrote:
>
> At
>
> http://wiki.ecmascript.org/doku.php?id=ses:ses_proposal_working_draft
> <http://wiki.ecmascript.org/doku.php?id=ses:ses_proposal_working_draft>
>
> is posted a very rough first draft for a "Secure ECMAScript" standard,
> derived from the "Mountain View draft" of ES3.1
> <http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft
> <http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft>>
> and from Cajita. I hope and believe that we can resolve differences
> between this and other contenders for the Cajita-like layer: ADsafe,
> Jacaranda, and Dojo Secure. (As for the Valija-like layer, both Valija
> and MS WebSandbox intend to emulate at least ES3.1-strict, so there's
> no need for a separate standard for that layer.)
>
> Further discussion of SES specifically should proceed on the "caplet
> group" list.
>
> --
> Text by me above is hereby placed in the public domain
>
> Cheers,
> --MarkM
>
>  <!-- #ygrp-mkp{ border: 1px solid #d8d8d8; font-family:
> Arial; margin: 14px 0px; padding: 0px 14px; } #ygrp-mkp hr{ border:
> 1px solid #d8d8d8; } #ygrp-mkp #hd{ color: #628c2a; font-size: 85%;
> font-weight: bold; line-height: 122%; margin: 10px 0px; } #ygrp-mkp
> #ads{ margin-bottom: 10px; } #ygrp-mkp .ad{ padding: 0 0; }
> #ygrp-mkp .ad a{ color: #0000ff; text-decoration: none; } --> <!--
> #ygrp-sponsor #ygrp-lc{ font-family: Arial; } #ygrp-sponsor #ygrp-lc
> #hd{ margin: 10px 0px; font-weight: bold; font-size: 78%;
> line-height: 122%; } #ygrp-sponsor #ygrp-lc .ad{ margin-bottom:
> 10px; padding: 0 0; } --> <!-- #ygrp-mlmsg {font-size:13px;
> font-family:
> arial,helvetica,clean,sans-serif;*font-size:small;*font:x-small;}
> #ygrp-mlmsg table {font-size:inherit;font:100%;} #ygrp-mlmsg select,
> input, textarea {font:99% arial,helvetica,clean,sans-serif;}
> #ygrp-mlmsg pre, code {font:115% monospace;*font-size:100%;}
> #ygrp-mlmsg * {line-height:1.22em;} #ygrp-text{ font-family:
> Georgia; } #ygrp-text p{ margin: 0 0 1em 0; } #ygrp-tpmsgs{
> font-family: Arial; clear: both; } #ygrp-vitnav{ padding-top: 10px;
> font-family: Verdana; font-size: 77%; margin: 0; } #ygrp-vitnav a{
> padding: 0 1px; } #ygrp-actbar{ clear: both; margin: 25px 0;
> white-space:nowrap; color: #666; text-align: right; } #ygrp-actbar
> .left{ float: left; white-space:nowrap; } .bld{font-weight:bold;}
> #ygrp-grft{ font-family: Verdana; font-size: 77%; padding: 15px 0; }
> #ygrp-ft{ font-family: verdana; font-size: 77%; border-top: 1px
> solid #666; padding: 5px 0; } #ygrp-mlmsg #logo{ padding-bottom:
> 10px; } #ygrp-reco { margin-bottom: 20px; padding: 0px; } #ygrp-reco
> #reco-head { font-weight: bold; color: #ff7900; } #reco-grpname{
> font-weight: bold; margin-top: 10px; } #reco-category{ font-size:
> 77%; } #reco-desc{ font-size: 77%; } #ygrp-vital{ background-color:
> #e0ecee; margin-bottom: 20px; padding: 2px 0 8px 8px; } #ygrp-vital
> #vithd{ font-size: 77%; font-family: Verdana; font-weight: bold;
> color: #333; text-transform: uppercase; } #ygrp-vital ul{ padding:
> 0; margin: 2px 0; } #ygrp-vital ul li{ list-style-type: none; clear:
> both; border: 1px solid #e0ecee; } #ygrp-vital ul li .ct{
> font-weight: bold; color: #ff7900; float: right; width: 2em;
> text-align:right; padding-right: .5em; } #ygrp-vital ul li .cat{
> font-weight: bold; } #ygrp-vital a{ text-decoration: none; }
> #ygrp-vital a:hover{ text-decoration: underline; } #ygrp-sponsor
> #hd{ color: #999; font-size: 77%; } #ygrp-sponsor #ov{ padding: 6px
> 13px; background-color: #e0ecee; margin-bottom: 20px; }
> #ygrp-sponsor #ov ul{ padding: 0 0 0 8px; margin: 0; } #ygrp-sponsor
> #ov li{ list-style-type: square; padding: 6px 0; font-size: 77%; }
> #ygrp-sponsor #ov li a{ text-decoration: none; font-size: 130%; }
> #ygrp-sponsor #nc{ background-color: #eee; margin-bottom: 20px;
> padding: 0 8px; } #ygrp-sponsor .ad{ padding: 8px 0; } #ygrp-sponsor
> .ad #hd1{ font-family: Arial; font-weight: bold; color: #628c2a;
> font-size: 100%; line-height: 122%; } #ygrp-sponsor .ad a{
> text-decoration: none; } #ygrp-sponsor .ad a:hover{ text-decoration:
> underline; } #ygrp-sponsor .ad p{ margin: 0; } o{font-size: 0; }
> .MsoNormal{ margin: 0 0 0 0; } #ygrp-text tt{ font-size: 120%; }
> blockquote{margin: 0 0 0 4px;} .replbq{margin:4} -->

- --
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkl3OrQACgkQ9VpNnHc4zAxUrQCgsxAlxVfj/52zM1hTXGVXTHQA
D2gAoLK5u2/l7pHEv/Kcbyc6WnPpQTj7
=fLQe
-----END PGP SIGNATURE-----

Consider the following JavaScript source:

    [ /[/]/ /foo]/ + bar

According to the ES3 spec, this is interpreted as:

    [ new RegExp("[") ] / new RegExp("foo]") + bar

According to the ES3.1 draft spec, it is interpreted as:

    [ new RegExp("[\/]") / foo ] / +bar

Apparently, Firefox and IE7 were lexing regexp literals in the way
ES3.1 specifies. I had considered re-allowing regexp literals in
Jacaranda 0.4, but this has scared me off doing so -- the potential
for lexical confusion attacks is just too great.

--
David-Sarah Hopwood ⚥

On Feb 9, 2009, at 9:42 AM, Marcel Laverdet wrote:

> From what I remember this started out as a bug in IE and then
> Firefox followed suit for compatibility which left the other
> browsers with no choice.

No, other browsers followed suit first.


> I can't find the original bug but `/[/]/` only started parsing in
> FF1.5, in FF1.0 it would throw a syntax error.

https://bugzilla.mozilla.org/show_bug.cgi?id=309840

Quoting from comment 0:

Description From  Jesse Ruderman   2005-09-23 19:33:25 PST   (-)
[reply]     Private

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/
20050923
Firefox/1.4

Firefox gives an "unterminated character class" error on the regular
expression
/[/]/.  Safari and Opera 8.5 accept it.

I noticed this because a regular expression containing [/] appears in
http://msdn.microsoft.com/workshop/code/browdata.js, which was
mentioned in
bug 309695 comment 9.

/be

David-Sarah Hopwood wrote:
> Consider the following JavaScript source:
>
>    [ /[/]/ /foo]/ + bar
>
> According to the ES3 spec, this is interpreted as:
>
>    [ new RegExp("[") ] / new RegExp("foo]") + bar
>
> According to the ES3.1 draft spec, it is interpreted as:
>
>    [ new RegExp("[\/]") / foo ] / +bar
>
> Apparently, Firefox and IE7 were lexing regexp literals in the way
> ES3.1 specifies. I had considered re-allowing regexp literals in
> Jacaranda 0.4, but this has scared me off doing so -- the potential
> for lexical confusion attacks is just too great.

ADsafe rejects [ /[/]/ /foo]/ + bar. Just because ECMAScript says its ok doesn't
mean that ADsafe must. ADsafe insists that all internal / must have \.

2009/2/9 Douglas Crockford <douglas@...>
>
> David-Sarah Hopwood wrote:
> > Consider the following JavaScript source:
> >
> > [ /[/]/ /foo]/ + bar
> >
> > According to the ES3 spec, this is interpreted as:
> >
> > [ new RegExp("[") ] / new RegExp("foo]") + bar
> >
> > According to the ES3.1 draft spec, it is interpreted as:
> >
> > [ new RegExp("[\/]") / foo ] / +bar
> >
> > Apparently, Firefox and IE7 were lexing regexp literals in the way
> > ES3.1 specifies. I had considered re-allowing regexp literals in
> > Jacaranda 0.4, but this has scared me off doing so -- the potential
> > for lexical confusion attacks is just too great.
>
> ADsafe rejects [ /[/]/ /foo]/ + bar. Just because ECMAScript says its ok
doesn't
> mean that ADsafe must. ADsafe insists that all internal / must have \.

Cajita disallows regex literals, but Valija uses the ES3.1 rule for
lexing regexs and rewrites
     [ /[/]/ /foo]/ + bar
to
   [ (new RegExp('[\\/]', '')) / foo ] / +bar
though I think we do something to make sure it will always use the
builtin RegExp ctor, again using the ES3.1 semantics.

We rely on the builtin RegExp ctor to be callable with string
arguments without introducing a breach, / after a close bracket token
to always be interpreted as a div operator, and our normalization for
string escapes to produce a string literal where the browser agrees
with us where the string ends.

Marcel Laverdet wrote:
>
> From what I remember this started out as a bug in IE and then Firefox
> followed suit for compatibility which left the other browsers with no
> choice. I can't find the original bug but `/[/]/` only started parsing
> in FF1.5, in FF1.0 it would throw a syntax error.
>
> You could throw out any malformed regexp literals (any that differ
> between ES3 \ ES3.1) which is a fairly small subset and you would be ok.

I could, if I knew that there were no more bugs like this. Note that
lexical confusion attacks of this kind can easily be turned into complete
breaks of a subset implementation:

   [ /[/]/ /alert('toast')]/ + 1

Verifier sees valid, harmless code:
   [ new RegExp("[") ] / new RegExp("alert('toast')]") + 1

Browser runs exploit code:
   [ new RegExp("[\/]") / alert('toast') ] / +1

Since there's no way that I could reliably have known about the IE lexer
bug, it's just too risky.

Anyone know of other bugs where common JS implementations lex or parse
valid ES3 code with a different meaning than specified? (The only one
I can think of right now is \v in IE, but at least that doesn't result
in a parse with a different structure.)

--
David-Sarah Hopwood ⚥

Brendan Eich wrote:
> On Feb 9, 2009, at 9:42 AM, Marcel Laverdet wrote:
>
>> From what I remember this started out as a bug in IE and then
>> Firefox followed suit for compatibility which left the other
>> browsers with no choice.
>
> No, other browsers followed suit first.
>
>> I can't find the original bug but `/[/]/` only started parsing in
>> FF1.5, in FF1.0 it would throw a syntax error.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=309840

<https://bugzilla.mozilla.org/show_bug.cgi?id=309840#c12>

# This fixes a highly dup'ed IE compatibility bug.  It's an extension
# to ECMA syntax that's allowed by Section 16.  I'm approving it so
# that we can get it into 1.8b5 / Firefox 1.5b2.

As the example in my first post demonstrated, it is absolutely not
correct that this was an allowed Section 16 extension. That section
allows lexical extensions only if a program does not match the lexical
grammar in the spec (in this case using the ES3 definition of
RegularExpressionLiteral), and allows regexp syntax extensions only
if the resulting RegularExpressionBody does not match Pattern.

In fact this just makes me even more worried: it seems that Section 16
is being misinterpreted in a way that prevents independently developed
parsers, implemented strictly from the spec, from being able to match the
parsing behaviour of browsers on syntactically valid ES3 code. Is this
just a one-off mistake, or is Section 16 consistently being interpreted
too loosely?

--
David-Sarah Hopwood ⚥

Douglas Crockford wrote:
> David-Sarah Hopwood wrote:
>> Consider the following JavaScript source:
>>
>>    [ /[/]/ /foo]/ + bar
>>
>> According to the ES3 spec, this is interpreted as:
>>
>>    [ new RegExp("[") ] / new RegExp("foo]") + bar
>>
>> According to the ES3.1 draft spec, it is interpreted as:
>>
>>    [ new RegExp("[\/]") / foo ] / +bar
>>
>> Apparently, Firefox and IE7 were lexing regexp literals in the way
>> ES3.1 specifies. I had considered re-allowing regexp literals in
>> Jacaranda 0.4, but this has scared me off doing so -- the potential
>> for lexical confusion attacks is just too great.
>
> ADsafe rejects [ /[/]/ /foo]/ + bar. Just because ECMAScript says its ok
doesn't
> mean that ADsafe must. ADsafe insists that all internal / must have \.

I'm confused -- how does it know that the middle '/' in "/[/]/" is
"internal"? Is it lexing according to the intersection of Pattern
from section 15.10.1, and RegularExpressionBody?

--
David-Sarah Hopwood ⚥

On Feb 10, 2009, at 6:34 AM, David-Sarah Hopwood wrote:
> Brendan Eich wrote:
> > On Feb 9, 2009, at 9:42 AM, Marcel Laverdet wrote:
> >
> >> From what I remember this started out as a bug in IE and then
> >> Firefox followed suit for compatibility which left the other
> >> browsers with no choice.
> >
> > No, other browsers followed suit first.
> >
> >> I can't find the original bug but `/[/]/` only started parsing in
> >> FF1.5, in FF1.0 it would throw a syntax error.
> >
> > https://bugzilla.mozilla.org/show_bug.cgi?id=309840
>
> <https://bugzilla.mozilla.org/show_bug.cgi?id=309840#c12>
>
> # This fixes a highly dup'ed IE compatibility bug. It's an extension
> # to ECMA syntax that's allowed by Section 16. I'm approving it so
> # that we can get it into 1.8b5 / Firefox 1.5b2.
>
> As the example in my first post demonstrated, it is absolutely not
> correct that this was an allowed Section 16 extension.
>
You're right, but so what? The IE bug and monopoly combined to create
a de-facto standard. Appealing to the de-jure standard does you no
good, and correcting my 2005-ear misunderstanding (you've corrected it
more recently in es-discuss) does not change the de-facto standard
trumping the de-jure one.

> In fact this just makes me even more worried: it seems that Section 16
> is being misinterpreted in a way that prevents independently developed
> parsers, implemented strictly from the spec, from being able to
> match the
> parsing behaviour of browsers on syntactically valid ES3 code. Is this
> just a one-off mistake, or is Section 16 consistently being
> interpreted
> too loosely?
>

This has nothing to do with Section 16 or my former misunderstanding
of it, and everything to do with IE forcing a de-facto standard. As
far as I know, no one at Microsoft added the bug allowing unescaped /
in a character class by arguing based on a misinterpretation of
Section 16. I think you are barking up the wrong tree.

/be
>
>
> --
> David-Sarah Hopwood ⚥
>
>
>

2009/2/10 David-Sarah Hopwood <david.hopwood@...>:
> Marcel Laverdet wrote:
>>
>> From what I remember this started out as a bug in IE and then Firefox
>> followed suit for compatibility which left the other browsers with no
>> choice. I can't find the original bug but `/[/]/` only started parsing
>> in FF1.5, in FF1.0 it would throw a syntax error.
>>
>> You could throw out any malformed regexp literals (any that differ
>> between ES3 \ ES3.1) which is a fairly small subset and you would be ok.
>
> I could, if I knew that there were no more bugs like this. Note that
> lexical confusion attacks of this kind can easily be turned into complete
> breaks of a subset implementation:
>
> [ /[/]/ /alert('toast')]/ + 1
>
> Verifier sees valid, harmless code:
> [ new RegExp("[") ] / new RegExp("alert('toast')]") + 1
>
> Browser runs exploit code:
> [ new RegExp("[\/]") / alert('toast') ] / +1
>
> Since there's no way that I could reliably have known about the IE lexer
> bug, it's just too risky.
>
> Anyone know of other bugs where common JS implementations lex or parse
> valid ES3 code with a different meaning than specified? (The only one
> I can think of right now is \v in IE, but at least that doesn't result
> in a parse with a different structure.)

Plenty.  But I suspect you know of them.  There's conditional
compilation comments /* @cc_on */,
  and there's the newlines in block comments thing return /*
*/ foo();
and there's format control characters between pairs like */ and \".
There's other tricks you can do with \u escapes in identifiers and NUL
and BOM characters in source.



> --
> David-Sarah Hopwood ⚥