I've been interested in ADsafe for a few months now as a potential way to allow
3rd parts apps to work within a safe sandbox.

However, since ADsafe fundamentally began as a sandbox for safe advertisement
(which nicely extends to apps), are there specific things that you would handle
differently if the focus was full-scale web applications?

Said differently, would it be worthwhile to create a derivative framework (for
example, APPsafe) specific for webapps? What would its main differences be?  Or
is it really all the same thing and we'd be better off just having an add-on
library that provides some additional glue for hooking up rich web apps within
ADsafe?

The reason I ask is because I have found it somewhat difficult to make simple
ADsafe apps that uses current web rendering/layout technologies (such as drawing
to a canvas or easily animating CSS properties).  I'm excited about the
potential of ADsafe, but I'm not clear about its intended scale (ads, widgets,
entire sites, an ADsafe browser OS, etc).

Keep up the great work!

Thanks,
Adam

--- In caplet@yahoogroups.com, Mike Samuel <mikesamuel@...> wrote:
>
> 2010/5/24 adam.kumpf <adam.kumpf@...>
>
> >
> >
> > I've been interested in ADsafe for a few months now as a potential way to
> > allow 3rd parts apps to work within a safe sandbox.
> >
> > However, since ADsafe fundamentally began as a sandbox for safe
> > advertisement (which nicely extends to apps), are there specific things that
> > you would handle differently if the focus was full-scale web applications?
> >
> > Said differently, would it be worthwhile to create a derivative framework
> > (for example, APPsafe) specific for webapps? What would its main differences
> > be? Or is it really all the same thing and we'd be better off just having an
> > add-on library that provides some additional glue for hooking up rich web
> > apps within ADsafe?
> >
> > The reason I ask is because I have found it somewhat difficult to make
> > simple ADsafe apps that uses current web rendering/layout technologies (such
> > as drawing to a canvas or easily animating CSS properties). I'm excited
> > about the potential of ADsafe, but I'm not clear about its intended scale
> > (ads, widgets, entire sites, an ADsafe browser OS, etc).
> >
> > Keep up the great work!
> >
> Caja ( http://code.google.com/p/google-caja/ ) is meant for larger scale
> apps.  It does not currently tame canvas, but it does deal with most of CSS
2.1 and parts of CSS 3.
>

Caja is a great idea, but it has some large fundamental limitations.  As I see
it, since the code is transformed irreversibly it is significantly harder to
debug, maintain, and verify at runtime.  ADsafe seems so straight-forward and
elegant in its simplicity; am I missing something bigger here?

ADsafe is great for integrating code without transformation, I'm just not sure
how large it can scale (I don't see any real hard limits, but I'd like to hear
some other voices on this).

Are there any large scale sites that use ADsafe for more than advertisements? 
The demo widgets (sudoku, etc) definitely show the possibility of more than ads,
but I haven't found much online with ADsafe being used explicitly.

Cheers,
Adam

I don't think the transformation has that big of a cost. Debugging isn't that
bad since you can debug before transformation, and transformation doesn't affect
line numbers (is this still true?) so thrown exceptions will have reasonable
stack traces. Maintenance is the same, running the transformation should just be
part of your makefile.

As for verification, is it possible to create a process which can certify that a
program has been cajoled? That could be a very valuable tool...

> >
> > Caja is a great idea, but it has some large fundamental limitations. As I
> > see it, since the code is transformed irreversibly it is significantly
> > harder to debug, maintain, and verify at runtime. ADsafe seems so
> > straight-forward and elegant in its simplicity; am I missing something
> > bigger here?
> >
>
> ADsafe is a beautiful piece of work and you are right about transformation
> having downsides.  Our strategy thus far has been to mitigate those upsides
> by integrating with debuggers like lavabug.
>
> There are some upsides to too though.
> Consider code like
>     x[+y]
> If you think this is safe initially but realize later that it is unsafe,
> then with a verifier approach you have to reject it, possibly requiring a
> large number of developers to rewrite their code.  With a rewriter, you can
> rewrite it to something safer.
>
> I think the reason we and Doug took different approaches was different
> design goals.  We wanted something that would support common coding
> practices and legacy code where possible.  Doug made the operating
> assumption that for certain niches, developers would be willing to learn new
> APIs and libraries.  To the degree to which a language's core libraries/APIs
> define the language, ADsafe is a new language.
>
>


Thanks for the additional clarity of the evolving ADsafe/Caja landscape.  You
and Doug are both on to a fundamental shift in how the web works, and more
specifically, how apps/functionality can be re-imagined when they can be
securely combined as never before.

I came upon some ongoing dialog about ECMAScript 5 Strict and SES as a way to
merge/rebuild the ADsafe, Caja, and FBJS approaches.  I saw at the end of the
SES page on the ECMAScript wiki that Doug suggested a competition approach to
help this happen.

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

What's the current status of it all?  I'm scouring the web in search of better
understanding how to navigate the ADsafe/Caja/SES initiatives.  Is there a
definitive place that things are being discussed and archived outside of this
forum and the ECMAScript wiki?

I ask because I'd really like to start using it toward something that could
scale and showcase some of the benefits of the POLA javascript approach.

Thanks again -- this is a very exciting space.

Cheers,
Adam

2010/5/26 adam.kumpf <adam.kumpf@...>
>
>
>
> > >
> > > Caja is a great idea, but it has some large fundamental limitations. As I
> > > see it, since the code is transformed irreversibly it is significantly
> > > harder to debug, maintain, and verify at runtime. ADsafe seems so
> > > straight-forward and elegant in its simplicity; am I missing something
> > > bigger here?
> > >
> >
> > ADsafe is a beautiful piece of work and you are right about transformation
> > having downsides. Our strategy thus far has been to mitigate those upsides
> > by integrating with debuggers like lavabug.
> >
> > There are some upsides to too though.
> > Consider code like
> > x[+y]
> > If you think this is safe initially but realize later that it is unsafe,
> > then with a verifier approach you have to reject it, possibly requiring a
> > large number of developers to rewrite their code. With a rewriter, you can
> > rewrite it to something safer.
> >
> > I think the reason we and Doug took different approaches was different
> > design goals. We wanted something that would support common coding
> > practices and legacy code where possible. Doug made the operating
> > assumption that for certain niches, developers would be willing to learn new
> > APIs and libraries. To the degree to which a language's core libraries/APIs
> > define the language, ADsafe is a new language.
> >
> >
>
> Thanks for the additional clarity of the evolving ADsafe/Caja landscape. You
and Doug are both on to a fundamental shift in how the web works, and more
specifically, how apps/functionality can be re-imagined when they can be
securely combined as never before.
>
> I came upon some ongoing dialog about ECMAScript 5 Strict and SES as a way to
merge/rebuild the ADsafe, Caja, and FBJS approaches. I saw at the end of the SES
page on the ECMAScript wiki that Doug suggested a competition approach to help
this happen.
>
> http://wiki.ecmascript.org/doku.php?id=ses:ses
>
> What's the current status of it all? I'm scouring the web in search of better
understanding how to navigate the ADsafe/Caja/SES initiatives. Is there a
definitive place that things are being discussed and archived outside of this
forum and the ECMAScript wiki?
>
> I ask because I'd really like to start using it toward something that could
scale and showcase some of the benefits of the POLA javascript approach.

Mark (CCed) can correct me if I say anything wrong.

ECMA approved EcmaScript 5 which has a strict mode removes a lot of
the problems around "this".

EcmaScript 6 is almost certain to include ephemeron tables and proxies
(http://code.google.com/p/es-lab/) that make it easy to write
membranes, and all of EcmaScript 6 will likely be built on top of the
strict mode.

Given EcmaScript 6, hopefully Caja will become much simpler gaining
much of the elegance of AdSafe while still being able to preserve API
compatibility for web applications.

Getting there from the mass of browsers running ES3 is the trick.

Mark and Mike Stay are working on ES 5 over 3 (
http://code.google.com/p/google-caja/wiki/DifferencesBetweenES5Over3AndES5
) which aims to implement ES5 strict mode on ES3.

Getting from ES5 to the as yet unstandardized ES6 is a tougher problem
since it's a moving target.  Mark, can you comment on that?


> Thanks again -- this is a very exciting space.
>
> Cheers,
> Adam
>

Mark and Mike,

This is really a great discussion -- thanks for detailing out the current state
of ECMA Script 5, SES, and the overall feel of where things are going.

I'm particularly intrigued by the SES sketch  <
http://code.google.com/p/es-lab/source/browse/trunk/src/ses/ > work going on as
it seems like a concrete step (although understandably ahead of it's needed
conforming ES5 implementation) toward what SES can be.

I think showcasing the potential of what POLA/SES ECMA Script enables is an
important step to getting more people excited (and subsequently more development
energy and development perspectives).

What would it take to get an example together that uses initSES.js to sandbox a
a couple of apps on a webpage? Could it work (at least for the most part) as ES5
Strict stands now?

For example, just having two simple text input boxes of ES5 Strict/SES code that
is then dynamically loaded into subsequent divs on a webpage.  Ideally, it would
demonstrate limited communication between the divs while keeping private
information inaccessible to the other (perhaps using the purse example, showing
POLA in use).  The viewer would then be invited to try to "scam the bank" by
hacking the script in any way that choose.

The banking example is a bit dry, but perhaps with a little finessing it (or
something like it) could be a compelling demo to get more people on-board and
involved in making SES happen.  I'm in awe of the potential of what the web can
become as sites become un-siloed via the concepts behind SES.  I think you guys
are on to something really big here...

Cheers,
Adam










--- In caplet@yahoogroups.com, "Mark S. Miller" <erights@...> wrote:
>
> Caution: I tend to err on the side of too much detail. Apologies in advance.
>
>
> On Wed, May 26, 2010 at 4:29 PM, Mike Samuel <mikesamuel@...> wrote:
>
> >
> >
> > 2010/5/26 adam.kumpf <adam.kumpf@... <adam.kumpf%40yahoo.com>>
> > > Thanks for the additional clarity of the evolving ADsafe/Caja landscape.
> > You and Doug are both on to a fundamental shift in how the web works, and
> > more specifically, how apps/functionality can be re-imagined when they can
> > be securely combined as never before.
> >
>
> We are always very happy to hear when others come think in these terms as
> well. Thanks!
>
>
>
> > >
> > > I came upon some ongoing dialog about ECMAScript 5 Strict and SES as a
> > way to merge/rebuild the ADsafe, Caja, and FBJS approaches. I saw at the end
> > of the SES page on the ECMAScript wiki that Doug suggested a competition
> > approach to help this happen.
> > >
> > > http://wiki.ecmascript.org/doku.php?id=ses:ses
> >
>
> That page has not been updated in a long time. Much of what's there is still
> accurate, but some of it is stale.
>
> A lot of the most recent material on SES is at <
> http://code.google.com/p/es-lab/>. At <
> http://code.google.com/p/es-lab/downloads/detail?name=et.pdf> is a
> presentation I did on Monday to the EcmaScript committee. It's mostly about
> Ephemeron Tables but does include a short summary of SES. At <
> http://code.google.com/p/es-lab/wiki/SecureEcmaScript> is a more complete
> statement, but is more in terms of what we can build from a "friendly" ES5
> implementation (<http://code.google.com/p/es-lab/wiki/SecureableES5>) than
> as a specification delta from ES5.
>
> Crock and I do believe this achieves the best of ADsafe (simple static
> verification rather than transformation) and Caja (purely whitelisting, not
> blacklisting. Supports full object-capability model. Supports almost the
> entire language and browser API[*].). Given the absence of controversy on
> the current proposal, we are no longer planning a competition.
>
> *Note that the browser API taming is outside the definition of SES but is of
> course part of any Caja deployment of SES.
>
>
> > >
> > > What's the current status of it all? I'm scouring the web in search of
> > better understanding how to navigate the ADsafe/Caja/SES initiatives. Is
> > there a definitive place that things are being discussed and archived
> > outside of this forum and the ECMAScript wiki?
> > >
> > > I ask because I'd really like to start using it toward something that
> > could scale and showcase some of the benefits of the POLA javascript
> > approach.
> >
>
> The implementation sketch at <
> http://code.google.com/p/es-lab/source/browse/trunk/src/ses/> is just a
> sketch. Until there's an adequately conforming ES5 implementation to try it
> on, we cannot run it and so cannot test it.
>
> The immediately exciting development effort is ES5/3 and SES5/3, that Mike
> Stay (cc'ed) is working on, that Mike Samuel comments on below.
>
>
>
>
> >
> > Mark (CCed) can correct me if I say anything wrong.
> >
> > ECMA approved EcmaScript 5 which has a strict mode removes a lot of
> > the problems around "this".
> >
> > EcmaScript 6 is almost certain to include ephemeron tables and proxies
> > (http://code.google.com/p/es-lab/) that make it easy to write
> > membranes, and all of EcmaScript 6 will likely be built on top of the
> > strict mode.
> >
>
> Yes. All of these statements reflect current committee agreements and
> consensus.
> <http://wiki.ecmascript.org/doku.php?id=harmony:proposals> lists the
> proposals which the committee has agreed to move from "strawman" to
> "proposal" status, meaning we expect this functionality in ES6, but the
> detail may differ arbitrarily. The proxy proposal (by Tom Van Cutsem, cc'ed)
> as it appears there is the official one.
>
>
> >
> > Given EcmaScript 6, hopefully Caja will become much simpler gaining
> > much of the elegance of AdSafe while still being able to preserve API
> > compatibility for web applications.
> >
>
> > Getting there from the mass of browsers running ES3 is the trick.
> >
> > Mark and Mike Stay are working on ES 5 over 3 (
> > http://code.google.com/p/google-caja/wiki/DifferencesBetweenES5Over3AndES5
> > ) which aims to implement ES5 strict mode on ES3.
> >
> > Getting from ES5 to the as yet unstandardized ES6 is a tougher problem
> > since it's a moving target. Mark, can you comment on that?
> >
>
> Sure. There is an interesting transition issue. With the restrictions listed
> on that page, ES5/3 will support proxies as well. However, a verify-only SES
> implementation on top of a friendly ES5 without proxies cannot emulate
> proxies. To preserve the proxy emulation, we may need to preserve the
> translation strategy for browsers that don't support proxies. Btw, Andreas
> Gal (cc'ed) of Mozilla has already implemented Proxies and made them
> available in the Firefox nightlies. They are currently expected to ship,
> alongside ES5, in Firefox 4. In which case, no problem going with a full
> verify-only strategy on FF4 (even without Ephemeron Tables).
>
> Cajita already emulates ephemeron tables as well as we can without having
> them be primitively provided, and we will be carrying this technique forward
> to ES5/3. This is good enough to give us identity preserving membranes, but
> does result in a storage leak: while a membrane is unrevoked, all objects
> passed through it are retained. Once the membrane is revoked, the revocation
> is as fully effective at cleaning up the objects in the compartment as it
> would be with full ephemeron tables.
>
> Of the other items *currently* listed at <
> http://wiki.ecmascript.org/doku.php?id=harmony:proposals>, all of these can
> be emulated straightforwardly by incremental improvements to the ES5/3
> translator. Should this remain the case, (ES5/3,SES5/3) will gradually
> improve into (ES6/3,SES6/3). We will upgrade the Differences page with any
> further caveats we find we need in the process.
>
>
> >
> >
> > > Thanks again -- this is a very exciting space.
> >
>
> Indeed!
>
>
>
> > > Cheers,
> > > Adam
> > >
> >
> >
> >
> --
>     Cheers,
>     --MarkM
>

--- In caplet@yahoogroups.com, "adam.kumpf" <adam.kumpf@...> wrote:
>
> I've been interested in ADsafe for a few months now as a potential way to
allow 3rd parts apps to work within a safe sandbox.
>
> However, since ADsafe fundamentally began as a sandbox for safe advertisement
(which nicely extends to apps), are there specific things that you would handle
differently if the focus was full-scale web applications?
>
> Said differently, would it be worthwhile to create a derivative framework (for
example, APPsafe) specific for webapps? What would its main differences be?  Or
is it really all the same thing and we'd be better off just having an add-on
library that provides some additional glue for hooking up rich web apps within
ADsafe?
>
> The reason I ask is because I have found it somewhat difficult to make simple
ADsafe apps that uses current web rendering/layout technologies (such as drawing
to a canvas or easily animating CSS properties).  I'm excited about the
potential of ADsafe, but I'm not clear about its intended scale (ads, widgets,
entire sites, an ADsafe browser OS, etc).


The source is out there, and you are certainly welcome to adapt it. My energies
are now focused on repairing ECMAScript and HTML/DOM, ultimately making ADsafe
completely unnecessary.

JSLint now enforces the prohibition on _ in string literals in the key position
of object literals. Thanks to Joe Politz of Brown.

On 30/08/2010 23:12, Mark S. Miller wrote:
>
>
> May crash your browser or page:
> http://es-lab.googlecode.com/svn/trunk/src/ses/index.html

FWIW, it didn't crash Chrome 5 on Windows. Hard to know if it worked
properly, tho!

>
> <http://es-lab.googlecode.com/svn/trunk/src/ses/index.html>Sources at
> http://code.google.com/p/es-lab/source/browse/trunk/src/ses/
>
> This has only been lightly tested and should */*not*/* be relied on to
> have any security properties yet.
>
> The claim I working up to is that, on a securable ES5 implementation
> (<http://code.google.com/p/es-lab/wiki/SecureableES5>), these scripts
> create an SES environment
> (<http://code.google.com/p/es-lab/wiki/SecureEcmaScript>) implementing
> the object-capability security model and solving the safe mashup problem
> (<http://code.google.com/p/es-lab/wiki/SafeMashups>).
>
> Unfortunately, since there is not yet any full browser-based
> implementations of ES5, the present state of these scripts have various
> compromises that preserves their functionality but loses security. These
> are documented in the various files under "KLUDGE SWITCHES". With these
> kludges, from *extremely* light testing, it seems to work on the latest
> * Firefox Minefield 4.0b5pre,
> * Safari WebKit Nightly Version 5.0.1 (5533.17.8, r66356), and
> * Chromium beta 6.0.490.0 (3135).
> As soon as I get my VMWare installation fixed, I'll test on the IE9
> preview as well. Opera 10.61.8429 does not yet implement
> Object.getOwnPropertyNames, so I can't even test there.
>
> This implementation of SES cannot run on ES5/3
> (<http://code.google.com/p/google-caja/wiki/DifferencesBetweenES5Over3AndES5>)
> as is because of the lack of a client side eval. The current plan is to
> support SES5/3 directly, rather than porting these scripts to run on ES5/3.
>
> Like ADsafe, this is all implemented by a lightweight client-side
> library, with no server-side support need. Minified, the total size of
> the download comes in under 5k. Because it does not parse or transform
> code, aside from calls to "eval" or the "Function" constructor, the
> untrusted code runs at full speed and with no code expansion. Due to
> various transient problems, the safe eval is currently called "eval2"
> and "eval" remains unsafe.
>
> Interestingly, this library contains a surprising faithful emulation of
> WeakMaps on ES5 browsers that don't support WeakMaps directly
>
(<http://code.google.com/p/es-lab/source/browse/trunk/src/ses/WeakMap.js#326>).
>
> --
>     Cheers,
>     --MarkM
>


--
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

ADSAFE.lib now subjects its name parameter to the same rules used generally on
properties.

Ankur Taly had discovered an attack by using a particular banned name as a
library name.

Hi all,

In the adsafe.js I found that the reject_name(name) function is used
at three location in this "procedural" form.
Ex. at line 1087 :
       getStyle: function (name) {
                 reject_global(this);
		 reject_name(name);
                 var a = [], b = this.___nodes___, i, node, s;

I wonder what is the purpose to use here, if the function returns a true or
false value what is actually not used?

> I wonder what is the purpose to use here, if the function returns a true or
false value what is actually not used?

On some browsers, accessing the constructor style would return a function, which
is not desirable, so an exception is raised instead.

--- In caplet@yahoogroups.com, Nagy Endre <forewer2000@...> wrote:
>
> I mean calling the reject_name function with a name it returns true or false.
> For instance if I call reject_name('constructor') than i will get true because
> the constructor it's on the banned list,
>  but I don't see how this throw an exception when it's called...

Quite right. Thank you very much.

I updated the ADsafe DOM interface. Previously, a method like .getValue() could
return

     undefined
     a single value
     an array of values

depending on the number of results. Now, a method like .getValue() will return
the first value that is available, or undefined if there are none. A new method,
.getValues() will always return an array, possibly an empty array.

Reminder: The submission date is March 25, two weeks from tomorrow.

On behalf of the workshop co-chairs and program chair, we would like to
invite you participate in the 5th annual workshop on Web 2.0 Security
and Privacy.  Started in 2007, this successful series of workshops has
attracted participation from both academia and industry, and participants
from around the world.

W2SP is co-located with the IEEE Security & Privacy Symposium.

Note: This year we plan to submit selected papers to a journal for publication.

_______________________________________________________________________________

Call for Papers

Web 2.0 Security and Privacy 2011 Workshop
The Claremont Resort, Oakland, California
Thursday, May 26, 2011

http://w2spconf.com/2011/cfp.html



Important Dates

Paper submission deadline: March 25, 2011 (11:59pm US-PST)
Workshop acceptance notification date: April 22, 2011
Workshop date: Thursday, May 26, 2011

W2SP brings together researchers, practitioners, web programmers, policy makers,
and others interested in the latest understanding and advances in the security
and privacy of the web, browsers and their eco-system. We have had four years
of successful W2SP workshops. This year, we will additionally invite selected
papers to a special issue of the journal.

We are seeking both short position papers (2-4 pages) and longer papers
(a maximum of 10 pages). The scope of W2SP 2011 includes, but is not limited to:

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

Workshop Co-Chairs

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

Program Chair

   * Helen J. Wang (Microsoft Research)

Program Committee

   * Dirk Balfanz (Google)
   * Adam Barth (Google)
   * Dan Boneh (Stanford)
   * Suresh Chari (IBM Research)
   * Hao Chen (UC Davis)
   * Shuo Chen (MSR)
   * Collin Jackson (CMU)
   * Martin Johns (SAP Research)
   * Larry Koved (IBM Research)
   * Christopher Kruegel (UCSB)
   * Ben Livshits (MSR)
   * John C. Mitchell (Stanford University)
   * Charlie Reis (Google)
   * Thomas Roessler (W3C)
   * V.N. Venkatakrishnan (UI Chicago)
   * Dan S. Wallach (Rice University)
   * Helen J. Wang (MSR)
   * Mary Ellen Zurko (IBM)

Final reminder!  Submissions are due next Friday.
Thanks.

On behalf of the workshop co-chairs and program chair, we would like to
invite you participate in the 5th annual workshop on Web 2.0 Security
and Privacy.  Started in 2007, this successful series of workshops has
attracted participation from both academia and industry, and participants
from around the world.

W2SP is co-located with the IEEE Security & Privacy Symposium.

Note: This year we plan to submit selected papers to a journal for publication.

_______________________________________________________________________________

Call for Papers

Web 2.0 Security and Privacy 2011 Workshop
The Claremont Resort, Oakland, California
Thursday, May 26, 2011

http://w2spconf.com/2011/cfp.html



Important Dates

Paper submission deadline: March 25, 2011 (11:59pm US-PST)
Workshop acceptance notification date: April 22, 2011
Workshop date: Thursday, May 26, 2011

W2SP brings together researchers, practitioners, web programmers, policy makers,
and others interested in the latest understanding and advances in the security
and privacy of the web, browsers and their eco-system. We have had four years
of successful W2SP workshops. This year, we will additionally invite selected
papers to a special issue of the journal.

We are seeking both short position papers (2-4 pages) and longer papers
(a maximum of 10 pages). The scope of W2SP 2011 includes, but is not limited to:

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

Workshop Co-Chairs

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

Program Chair

   * Helen J. Wang (Microsoft Research)

Program Committee

   * Dirk Balfanz (Google)
   * Adam Barth (Google)
   * Dan Boneh (Stanford)
   * Suresh Chari (IBM Research)
   * Hao Chen (UC Davis)
   * Shuo Chen (MSR)
   * Collin Jackson (CMU)
   * Martin Johns (SAP Research)
   * Larry Koved (IBM Research)
   * Christopher Kruegel (UCSB)
   * Ben Livshits (MSR)
   * John C. Mitchell (Stanford University)
   * Charlie Reis (Google)
   * Thomas Roessler (W3C)
   * V.N. Venkatakrishnan (UI Chicago)
   * Dan S. Wallach (Rice University)
   * Helen J. Wang (MSR)
   * Mary Ellen Zurko (IBM Research)

ADsafe took a big usability hit when the Firefox[-6] bug was discovered. ADsafe
took the necessary but highly undesirable step of outlawing the use of the []
subscript operator except when the subscript expression was a non-negative
number or an approved string.

Thanks to a suggestion by Jasvir Nagra, ADsafe allows [] for all number literals
as well as strings starting with '-'. It also accepts subscripts that are
expressions that can be easily determined to be strings.

adsafe.js's initialization now contains the following (which, coincidentally,
demonstrates the Principle of Correspondence):

     if (Function.__defineGetter__) {
         (function (p, f) {
             p.__defineGetter__('-1', f);
             p.__defineGetter__('-3', f);
             p.__defineGetter__('-6', f);
         }(Function.prototype, function () {
             return null;
         }));
     }

For browsers that have a __defineGetter__ method, that method will be used to
install getters for [-1], [-3], and [-6] that will return null. This is thought
to plug the Firefox leak.

JSLint will now allow subscript expressions where the outermost operator is one
of these prefix operators

     - + ~ typeof

or one of these infix operators

     - * / % & | << >> >>>

--- In caplet@yahoogroups.com, "Freeman, Tim" <tim.freeman@...> wrote:
>
> Care to post a citation for the Firefox[-6] bug?  Google doesn't do a very
good job searching for [-6].  Sounds pretty bizarre, if -1, -3, and -6 are
special.


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

http://www.thespanner.co.uk/2009/07/14/hidden-firefox-properties-revisited/

--- In caplet@yahoogroups.com, Brendan Eich <brendan@...> wrote:
>
> On Apr 19, 2011, at 9:13 AM, Douglas Crockford wrote:
>
> > --- In caplet@yahoogroups.com, "Freeman, Tim" <tim.freeman@> wrote:
> > >
> > > Care to post a citation for the Firefox[-6] bug? Google doesn't do a very
good job searching for [-6]. Sounds pretty bizarre, if -1, -3, and -6 are
special.
> >
> > https://bugzilla.mozilla.org/show_bug.cgi?id=507453
> >
>
> So, fixed in Firefox 3.5 and 3.6 patch releases. Firefox 4 is out already. Is
anyone seeing hits from downrev Firefoxes?


This is the Firefox distribution I see at Yahoo:

4.0   1.60%
3.6  21.78%
3.5   2.99%
3.0   1.93%
2.0   0.39%