On May 25, 2009, at 2:56 PM, Tyler Close wrote:
> On Sun, May 24, 2009 at 7:49 AM, Douglas Crockford
> <douglas@...> wrote:
> >> So, I suggest that you consider adding 'stack', and possibly
> >> 'message', 'stacktrace' and 'toSource', to the banned list.
> >
> > I do not understand the value in preventing information leaks here.
> > What is the hazard?
>
I'd like to know too -- you can throw an object that you could return,
so that's not it.

Is it the ES3 spec bug, not implemented by many browsers, where the
scope of the catch variable is a new Object (and so can be attacked by
Object.prototype setters or throwing a function that's called to
capture |this|)? What browsers still do that?

> > I am considering the blocking of try/catch in ADsafe. I am
> concerned about the
> > potential of using exceptions to deliver capabilities between
> isolated widgets.
>
> Javascript's catch is also problematic since it enables catching of
> stack overflow and out of memory errors.
>

Out of memory is not catchable in SpiderMonkey.

What browsers did you test?

> A widget could use this
> ability to put another object, or perhaps even the browser, in an
> inconsistent state. For example, the widget could use up all but one
> stack frame and then make a call to a browser object which mutates
> part of its state and then attempts a function call before making
> additional mutations. The victim object would make the first mutation,
> but suffer a stack overflow error before being able to complete the
> rest of the mutations. The widget code could catch the Error, leaving
> the victim object in the inconsistent state.
>

Sounds like a bug in the victim object. Why didn't it catch and clean
up?

Really, there are lots of potential bugs where an inconsistent state
could result from errors. Making the errors fatal to the currently
exeucting script only increases consistency in that particular script
or event handler's control flow. The next script or event can still
the inconsistency.

If you poison the whole well, meaning both fail-stop the script and
make the entire reachable object graph inaccessible or error-tainted,
then you can limit the leak. But there's still a termination channel.

/be

On Mon, May 25, 2009 at 3:37 PM, Brendan Eich <brendan@...> wrote:
> On May 25, 2009, at 2:56 PM, Tyler Close wrote:
>> On Sun, May 24, 2009 at 7:49 AM, Douglas Crockford
>> > I am considering the blocking of try/catch in ADsafe. I am
>> concerned about the
>> > potential of using exceptions to deliver capabilities between
>> isolated widgets.
>>
>> Javascript's catch is also problematic since it enables catching of
>> stack overflow and out of memory errors.
>>
>
> Out of memory is not catchable in SpiderMonkey.

What about stack overflow?

> What browsers did you test?

I did the testing during the caja security review and I believe I got
an exploit working in both IE 6 and Firefox 2 on Windows using the
stack overflow Error. The stack overflow Error was easier to work with
than the out of memory Error, since it's more predictable.

>> A widget could use this
>> ability to put another object, or perhaps even the browser, in an
>> inconsistent state. For example, the widget could use up all but one
>> stack frame and then make a call to a browser object which mutates
>> part of its state and then attempts a function call before making
>> additional mutations. The victim object would make the first mutation,
>> but suffer a stack overflow error before being able to complete the
>> rest of the mutations. The widget code could catch the Error, leaving
>> the victim object in the inconsistent state.
>>
>
> Sounds like a bug in the victim object. Why didn't it catch and clean
> up?

Because it wasn't expecting the function to throw. For example, the
called function may have been one implemented in the same block of
code as the calling function. Seeing that the called function didn't
throw, the programmer of the victim object didn't write a try catch
block. In general, protecting yourself against this kind of attack by
defensively writing try catch blocks is too cumbersome and error prone
to be feasible.

> Really, there are lots of potential bugs where an inconsistent state
> could result from errors. Making the errors fatal to the currently
> exeucting script only increases consistency in that particular script
> or event handler's control flow. The next script or event can still
> the inconsistency.

Sounds like an excellent argument for making errors fail-stop. ADsafe
is in a good position to implement this, since it can wrap all event
handlers created by a widget.

> If you poison the whole well, meaning both fail-stop the script and
> make the entire reachable object graph inaccessible or error-tainted,
> then you can limit the leak. But there's still a termination channel.

Allowing the widget to explicitly terminate the page is fine, since it
implicitly has this authority anyways, since it could always just
enter an infinite loop, or use other DOS techniques.

--Tyler

--
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Hi folks,

Joel was playing around with ADsafe today and noticed that the
verifier seems to be broken at the moment.  For example, this widget
passes the verifier but seems to cause problems:

http://webblaze.org/jww/adsafe-broken.html

Are we using the site wrong?

Thanks,
Adam

--- In caplet@yahoogroups.com, Adam Barth <hk9565@...> wrote:
> Joel was playing around with ADsafe today and noticed that the
> verifier seems to be broken at the moment.  For example, this widget
> passes the verifier but seems to cause problems:
>
> http://webblaze.org/jww/adsafe-broken.html
>
> Are we using the site wrong?

The fault was mine. Please ask Joel to try it again.

Hey I wanted to let you guys know that for now I'm discontinuing research on
FBJS2. Basically at this time instead we're focusing on Facebook Connect
(external sites, not embedded on Facebook) and the overall stability of Facebook
Platform (that is, not introducing wild new technologies that will break
everything). Meanwhile I'm moving on to some other projects at Facebook. It's
probably for the best since I never did get to commit as much time to FBJS2 as I
had wanted to; it was always kind of a rogue project I was working on in my
spare time.

The good news is that we're open sourcing everything we made along the way
[Apache license]...
http://developers.facebook.com/fbopen/fbjs2-0.1.tar.gz

I know some of you were interested in seeing our rewrite rules, so they're there
for everyone. Also included is a hastily-written JS runtime, which is nothing
special and also very slow. The parser \ rewrite engine is probably the most
reusable software in the package. We ended up using it internally for a few
different projects that need to wrangle Javascript.

I repaired some leakage in the ADsafe Ajax library. Grateful thanks to John
Mitchell, Sergio Maffeis, and Ankur Taly. http://www.doc.ic.ac.uk/~maffeis/

I also changed the restrictions on ADSAFE.get and ADSAFE.put. They now reject
negative numbers and strings starting with '-'.

The ADsafe verifier now rejects programs that use the arguments pseudo array.

The ADsafe verifier now rejects programs that use expressions with the subscript
operator, even when the + prefix is used. The ADSAFE.get and ADSAFE.set methods
must be used instead. The subscript operator may be used with positive number
literals and string literals that do not begin with - or _.

I added a new query pattern:

     :trim

         This produces a bunch from which all
         text nodes containing only whitespace
         are removed

I added these bunch methods:

     .each(func)

         The function is called for each node in
         the bunch.

     .title(value)

         Set the title attribute of each node.

     .getTitle()

         Get the title attribute of each node.

I changed the way ADSAFE._intercept(func) works.
It is now called as a method, passing a function
that will be called when a new widget is started.

http://www.JSLint.com/ is now an ADsafe widget.

What's the recommended idiom for iterating over the elements of an
array? I had been using:

for (var i = 0; i !== v.length; i += 1) {
     var element = v[+i];
     ...
}

Are you expecting array iteration to be done as:

for (var i = 0; i !== v.length; i += 1) {
     var element = ADSAFE.get(v, i);
     ...
}

This is a little cumbersome.

I'm looking for something that will work reliably across browsers,
including IE6.

Could JSLint be made smart enough to realize that the variable "i" in
the above loop is always a positive number?

--Tyler

On Fri, Jul 31, 2009 at 9:20 AM, Douglas Crockford<douglas@...> wrote:
> The ADsafe verifier now rejects programs that use the arguments pseudo array.
>
> The ADsafe verifier now rejects programs that use expressions with the
subscript operator, even when the + prefix is used. The ADSAFE.get and
ADSAFE.set methods must be used instead. The subscript operator may be used with
positive number literals and string literals that do not begin with - or _.
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>



--
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

This is announcement of the call for papers for the fourth in a series
of successful workshops on topics related to security and privacy for
Web 2.0.

This workshop may be of interest to readers of this mailing list.

If you would, please pass this information on to your colleagues who
may be interested in this workshop.

http://w2spconf.com/2010/

Workshop Call for Papers
W2SP 2010: Web 2.0 Security and Privacy 2010
Thursday, May 20
The Claremont Resort, Oakland, California

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. An ongoing explosion of new technology is powering
increasingly complex social and business interactions as well as
enabling an unprecedented level of unmediated information exchange and
horizontal organization. These 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, businesses, and other organizations
desire the simplicity, efficiency, and utility these technologies
offer.

Though these technologies have had many positive effects, they raise
issues about management of identities, personal safety, reputation,
privacy, anonymity, transient and long-term relationships, and
composition of function and content, both on the server and on the
client side (web browsers and mobile platforms). Although many of the
underlying security and privacy issues are not new, the use of these
technologies by very large and disparate populations raises new
questions. This workshop is intended to discuss the limitations of
current technologies and explore alternatives.

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

Trustworthy cloud-based services
Usable security and privacy
Security and privacy as a service
Security for the mobile web
Identity management and psuedonymity
Web services/feeds/mashups
Security and privacy policies for composible content
Next-generation browser technology
Secure extensions and plug-ins
Advertisement and affiliate fraud

Potential workshop participants should submit a paper on topics
relevant to Web 2.0 security and privacy issues. We are seeking both
short position papers (2 - 4 pages) and refereed papers (a maximum of
8 pages, including references and appendices). Papers longer than 8
pages may be automatically rejected by the chair or workshop
committee. From the submissions, the program committee will strive to
balance participation between academia and industry and across topics.
Selected papers will appear on the workshop web site; W2SP has no
formal published proceedings.

For papers that focus primarily on the security and privacy of social
networks, we encourage authors to submit their paper to the Social
Network Security and Privacy (SNSP) workshop, which is concurrent and
co-located with W2SP. Submitted papers may be referred to the SNSP
program committee for consideration.

Workshop Co-Chairs
Larry Koved (IBM Research)
Dan S. Wallach (Rice University)

Program Chair
Collin Jackson (Carnegie Mellon University)

Program Committee
Ben Adida (Harvard University)
Dirk Balfanz (Google)
Adam Barth (UC Berkeley)
Konstantin (Kosta) Beznosov (University of British Columbia)
Suresh Chari (IBM Research)
Hao Chen (UC Davis)
Collin Jackson (Carnegie Mellon University)
Martin Johns (University of Passau)
Rob Johnson (Stony Brook University)
Engin Kirda (Institute Eurecom)
Larry Koved (IBM Research)
Shriram Krishnamurthi (Brown University)
John C. Mitchell (Stanford University)
Dawn Song (UC Berkeley)
Dan S. Wallach (Rice University)
Helen Wang (Microsoft Research)

Important Dates

Paper submission deadline: Tuesday, March 23, 2010 (11:59pm US-Eastern)
Workshop acceptance notification date: April 11, 2010
Workshop date: Thursday, May 20, 2010
Workshop paper submission web site: http://submissions.w2spconf.com/

Registration: Workshop registration will be available via the 2010
IEEE Symposium on Security and Privacy conference web site.

This is announcement of the call for papers for the fourth in a series
of successful workshops on topics related to security and privacy for
Web 2.0.

This workshop may be of interest to readers of this mailing list.

If you would, please pass this information on to your colleagues who
may be interested in this workshop.

http://w2spconf.com/2010/

Workshop Call for Papers
W2SP 2010: Web 2.0 Security and Privacy 2010
Thursday, May 20
The Claremont Resort, Oakland, California

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. An ongoing explosion of new technology is powering
increasingly complex social and business interactions as well as
enabling an unprecedented level of unmediated information exchange and
horizontal organization. These 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, businesses, and other organizations
desire the simplicity, efficiency, and utility these technologies
offer.

Though these technologies have had many positive effects, they raise
issues about management of identities, personal safety, reputation,
privacy, anonymity, transient and long-term relationships, and
composition of function and content, both on the server and on the
client side (web browsers and mobile platforms). Although many of the
underlying security and privacy issues are not new, the use of these
technologies by very large and disparate populations raises new
questions. This workshop is intended to discuss the limitations of
current technologies and explore alternatives.

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

Trustworthy cloud-based services
Usable security and privacy
Security and privacy as a service
Security for the mobile web
Identity management and psuedonymity
Web services/feeds/mashups
Security and privacy policies for composible content
Next-generation browser technology
Secure extensions and plug-ins
Advertisement and affiliate fraud

Potential workshop participants should submit a paper on topics
relevant to Web 2.0 security and privacy issues. We are seeking both
short position papers (2 - 4 pages) and refereed papers (a maximum of
8 pages, including references and appendices). Papers longer than 8
pages may be automatically rejected by the chair or workshop
committee. From the submissions, the program committee will strive to
balance participation between academia and industry and across topics.
Selected papers will appear on the workshop web site; W2SP has no
formal published proceedings.

For papers that focus primarily on the security and privacy of social
networks, we encourage authors to submit their paper to the Social
Network Security and Privacy (SNSP) workshop, which is concurrent and
co-located with W2SP. Submitted papers may be referred to the SNSP
program committee for consideration.

Workshop Co-Chairs
Larry Koved (IBM Research)
Dan S. Wallach (Rice University)

Program Chair
Collin Jackson (Carnegie Mellon University)

Program Committee
Ben Adida (Harvard University)
Dirk Balfanz (Google)
Adam Barth (UC Berkeley)
Konstantin (Kosta) Beznosov (University of British Columbia)
Suresh Chari (IBM Research)
Hao Chen (UC Davis)
Collin Jackson (Carnegie Mellon University)
Martin Johns (SAP Research)
Rob Johnson (Stony Brook University)
Engin Kirda (Institute Eurecom)
Larry Koved (IBM Research)
Shriram Krishnamurthi (Brown University)
John C. Mitchell (Stanford University)
Dawn Song (UC Berkeley)
Dan S. Wallach (Rice University)
Helen Wang (Microsoft Research)

Important Dates

Paper submission deadline: Tuesday, March 23, 2010 (11:59pm US-Eastern)
Workshop acceptance notification date: April 11, 2010
Workshop date: Thursday, May 20, 2010
Workshop paper submission web site: http://submissions.w2spconf.com/

Registration: Workshop registration will be available via the 2010
IEEE Symposium on Security and Privacy conference web site.

This is announcement of the call for papers for the fourth in a series
of successful workshops on topics related to security and privacy for
Web 2.0.

This workshop may be of interest to readers of this mailing list.

If you would, please pass this information on to your colleagues who
may be interested in this workshop.

http://w2spconf.com/2010/

Workshop Call for Papers
W2SP 2010: Web 2.0 Security and Privacy 2010
Thursday, May 20
The Claremont Resort, Oakland, California

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. An ongoing explosion of new technology is powering
increasingly complex social and business interactions as well as
enabling an unprecedented level of unmediated information exchange and
horizontal organization. These 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, businesses, and other organizations
desire the simplicity, efficiency, and utility these technologies
offer.

Though these technologies have had many positive effects, they raise
issues about management of identities, personal safety, reputation,
privacy, anonymity, transient and long-term relationships, and
composition of function and content, both on the server and on the
client side (web browsers and mobile platforms). Although many of the
underlying security and privacy issues are not new, the use of these
technologies by very large and disparate populations raises new
questions. This workshop is intended to discuss the limitations of
current technologies and explore alternatives.

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

Trustworthy cloud-based services
Usable security and privacy
Security and privacy as a service
Security for the mobile web
Identity management and psuedonymity
Web services/feeds/mashups
Security and privacy policies for composible content
Next-generation browser technology
Secure extensions and plug-ins
Advertisement and affiliate fraud

Potential workshop participants should submit a paper on topics
relevant to Web 2.0 security and privacy issues. We are seeking both
short position papers (2 - 4 pages) and refereed papers (a maximum of
8 pages, including references and appendices). Papers longer than 8
pages may be automatically rejected by the chair or workshop
committee. From the submissions, the program committee will strive to
balance participation between academia and industry and across topics.
Selected papers will appear on the workshop web site; W2SP has no
formal published proceedings.

For papers that focus primarily on the security and privacy of social
networks, we encourage authors to submit their paper to the Social
Network Security and Privacy (SNSP) workshop, which is concurrent and
co-located with W2SP. Submitted papers may be referred to the SNSP
program committee for consideration.

Workshop Co-Chairs
Larry Koved (IBM Research)
Dan S. Wallach (Rice University)

Program Chair
Collin Jackson (Carnegie Mellon University)

Program Committee
Ben Adida (Harvard University)
Dirk Balfanz (Google)
Adam Barth (UC Berkeley)
Konstantin (Kosta) Beznosov (University of British Columbia)
Suresh Chari (IBM Research)
Hao Chen (UC Davis)
Collin Jackson (Carnegie Mellon University)
Martin Johns (SAP Research)
Rob Johnson (Stony Brook University)
Engin Kirda (Institute Eurecom)
Larry Koved (IBM Research)
Shriram Krishnamurthi (Brown University)
John C. Mitchell (Stanford University)
Dawn Song (UC Berkeley)
Dan S. Wallach (Rice University)
Helen Wang (Microsoft Research)

Important Dates

Paper submission deadline: Tuesday, March 23, 2010 (11:59pm US-Eastern)
Workshop acceptance notification date: April 11, 2010
Workshop date: Thursday, May 20, 2010
Workshop paper submission web site: http://submissions.w2spconf.com/

Registration: Workshop registration will be available via the 2010
IEEE Symposium on Security and Privacy conference web site.

I added a getContext method. It makes it possible to draw on a <canvas>.

I am now logging all errors to ADSAFE.log as a convenience for developers.

---------------------------------------

<!-- BEGIN ADSAFE WIDGET FRAGMENT -->
<div id="TEMPLATE_">
	<canvas id="TEMPLATE_CANVAS">
	    Default canvas content if browser doesn't support it.
	</canvas>
        other html markup required by the widget goes here
<script>
"use strict";
ADSAFE.id("TEMPLATE_");
</script>
<!-- LIBS HERE-->
<script>
"use strict";
ADSAFE.go("TEMPLATE_", function (dom, lib) {
	// This is where the code for the widget is placed. 
	var tc = dom.q("#TEMPLATE_CANVAS");
	var context = tc.getContext('2d');
	ADSAFE.log(context);
	var docsBody = context.canvas.offsetParent; // potentially dangerous!!
	ADSAFE.log(docsBody);
});
</script>
</div>
<!-- END ADSAFE WIDGET FRAGMENT -->

---------------------------------------

--- In caplet@yahoogroups.com, "adam.kumpf" <adam.kumpf@...> wrote:
>
>
> --- In caplet@yahoogroups.com, "Douglas Crockford" <douglas@> wrote:
> >
> > I added a getContext method. It makes it possible to draw on a
> <canvas>.
> >
> > I am now logging all errors to ADSAFE.log as a convenience for
> developers.
> >
>
>
> Thanks Doug -- it's great that you are so responsive!
>
> One word of caution, though.  From the returned CanvasRenderingContext2D
> it is possible to access the raw HTML Canvas element, which in turn
> allow access up the DOM (ahhh!).
>
> Is there a way to override the canvas variable within the
> CanvasRenderingContext2D such that it cannot be accessed?
>
> Here's the code I was running that allowed me to get up the DOM:
>
> ---------------------------------------
>
> <!-- BEGIN ADSAFE WIDGET FRAGMENT -->
> <div id="TEMPLATE_">
> <canvas id="TEMPLATE_CANVAS">
> Default canvas content if browser doesn't support it.
> </canvas>
> other html markup required by the widget goes here
> <script>
> "use strict";
> ADSAFE.id("TEMPLATE_");
> </script>
> <!-- LIBS HERE-->
> <script>
> "use strict";
> ADSAFE.go("TEMPLATE_", function (dom, lib) {
> // This is where the code for the widget is placed.
> var tc = dom.q("#TEMPLATE_CANVAS");
> var context = tc.getContext('2d');
> ADSAFE.log(context);
> var docsBody = context.canvas.offsetParent; // potentially dangerous!!
> ADSAFE.log(docsBody);
> });
> </script>
> </div>
> <!-- END ADSAFE WIDGET FRAGMENT -->
>
> ---------------------------------------
> Cheers,
> Adam
>


Something like this seems to do it (i.e., copy the context, but don't include
the canvas element).  Although the returned type is no longer a
CanvasRenderingContext2D.  Trying to overwrite the canvas property doesn't seem
to work (since it is a getter only).

Thoughts?  Can this be done more directly instead of copying everything?

--------------------------

getContext: function (contextId) {
     var a = [], b = this.___nodes___, i, tempCtx, attr;
     for (i = 0; i < b.length; i += 1) {
         if (typeof b[i].getContext === 'function') {
             tempCtx = b[i].getContext(contextId);
             a[i] = [];
             for (att in tempCtx) {
                 if (att !== "canvas") {
                     a[i][att] = tempCtx[att];
                 }
             }
         }
     }
     return a.length === 1 ? a[0] : a;
},

--------------------------


Cheers,
Adam

---------------------------

getContext: function (contextId) {
	var a = [], b = this.___nodes___, i, fn;
	for (i = 0; i < b.length; i += 1) {
		if (typeof b[i].getContext === 'function') {  
			fn = function () {
				var ctx = b[i].getContext(contextId);
				ADSAFE.log(ctx); 
				return {
				  // properties (need both Setters and Getters for each)
				  setFillStyle: function(f){
				    ctx.fillStyle = f;
				  },
				  getFillStyle: function(){
				    return ctx.fillStyle;
				  },
				  // functions (need to have the right number of arguments)
				  fillRect: function(a, b, c, d){
				    ctx.fillRect(a, b, c, d);
				  },
				  getImageData: function(l, t, w, h){
				    return ctx.getImageData(l, t, w, h);
				  },
				  putImageData: function(imgD, l, t){
			            ctx.putImageData(imgD, l, t);
				  }
			        }
			}
		        a[i] = fn();
	        }
	}
	return a.length === 1 ? a[0] : a;
},


---------------------------

I have removed the getContext method.

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.