The Good Soldier LMeyerov

Exciting

2009-12-17T01:19:00.000-08:00

Yesterday I finished rewriting my CSS layout grammars to be functionally pure (and restrict almost all iteration to that over nodes): with a bit more work, I think you can represent them in the language of Rep's very simple grammars (though not if you want good parallelism ;-)). This is important because, if I generate solvers based on such a grammar, it's ok to only support a restricted language. Result 1: win!

Today, I've been extending my documentation on the grammars. Part of this is the negative space. I haven't even read the specification of margins/padding/clearance/tables. I remembered that, while I also don't handle overflow (visible, auto, scroll, hidden) and exotic positioning styles (absolute, fixed, etc.), they didn't seem hard. Beyond some interactions with floats, they weren't -- haven't created new language levels with them yet, but added the informal intuition of what changes. Result 2: win!

I already have floats (well, left-floats), inlines, and boxes. Now just tables, margins, and padding, and we'll support most websites! That means there's a pure, linear time representation of CSS with clear (speculative) data parallelism and a simple language -- making it incremental and parallel might not be so bad. Still worried about the renderer..

Almost done with our extended TR, just want to add the translation from CSS to BSS. Looking good :D Worst-case scenario, I drop out of grad school and become a CSS consultant.

When should something be a language feature?

2009-12-14T02:25:00.000-08:00

Adrienne and I had been hacking on a JavaScript library for controlling capabilities (see previously posted snippets). We have some semblance of an understanding of its pros and cons, both in abstractions provided and strategy used to implement them. My suspicion is that it belongs as a language feature. That's a big claim.

I described our library to a friend who does a lot of security research. He does more systems and dynamic analysis techniques than linguistic ones so he didn't have intuition for my claim. More precisely, I think he fell under the blub paradox: he got along fine without it, and can hack together something if he really needs it, so why bother with the extra language complexity? When something should be a language feature is a tough but stimulating question, and I think some of my reasons for this project are representative:

Performance. Bill Buxton, in his "order of magnitude" principle, states changing a dimension of something by a magnitude makes it a new thing. In this case, if a security feature is cheap, you feel fine using it -- imagine how we'd write C code if processes and message passing were as threads with shared memory! Using language support, we can do some dirty tricks. Lightweight threads in functional languages is essentially this.
Conciseness. Similarly, if we struggle to write something, we won't. There's a world of a difference in writing functional code in C++ and Haskell or even O'Caml. If you have to write C++ code, it's possible to write most functional stuff with some encoding and library help, but if you want to write functional style code, you'll be more productive in other languages. This is the OOM principle all over again.
Expressiveness. At a bigger scale, abstractions like continuations and aspects are fundamentally difficult to encode locally -- shoe-horning them into legacy code is tough.
Legibility. Most of our time is spent reading, analyzing, testing, and revisiting code: removing boilerplate and standardizing idioms strengthens large and long-term projects. Data binding -- even if not at the Flapjax level -- is a crowd favorite here. SQL is probably another good example (... until it falls down).
Automation. Spread through is a notion of global or standardized idioms: manually handling them increases the risk of error. My favorite example is manual garbage collection.
Tool support. If a feature is important, we'll probably want program analysis help (verification, testing, etc.) and IDE support for it -- which are easier to do when a feature is made a language feature. Package/import handling in Eclipse for Java apps is just the tip of the iceberg here.
TCB. The trusted computing base should be as small as possible: if a security critical property requires a lot of funny code and usage assumptions... that's bad. The whole multi-process browser architecture movement is, in a sense, about this (... though it's not the only way once you think about it like this).
Finally... Understanding. The approach of making a calculus based around a feature is in part due to this: what's going on at a basic level and how necessary is it? What happens if we deeply embed it -- what's the value and impact? For a research project, making an idiom a language feature is an enlightening approach, even if it'll be watered down to a library later. I find this somewhat similar to denotational and typed approaches to coding.

The points above are about the value-added benefit of doing something at the language layer.. I think there's a sniff test that would have a bit more to it. E.g., hovering around most of these reasons is some sort of notion of global or pervasive property. Something a developer is always doing or needing to somehow maintain.

Why something should be a language feature is a subtle question -- I still don't really know. Another perspective is to ask when something should not be a language feature. Where is the line?

Getting closer to a quals topic

2009-12-04T02:34:00.001-08:00

Trying to figure out what my thesis project is going to be. The theme of my research at Berkeley has shifted, overall, from AJAX application abstractions (user level, inference, etc.) to browser design (security, performance, and specification).

I think my security work has been exciting and we're close to where I want to be with it (still want to combine our project on rich security abstractions with the one on lightweight browser security primitives for a powerful but feasible middle ground over the course of the next year). Unfortunately, I think the politics of (web) security research and web standards will limit the impact of this work in the short-term and the PL community wouldn't find it too interesting despite being driven by new linguistic abstractions (as opposed to the trend of coarse software architectures or analysis-driven approaches nobody uses). It's getting too frustrating for what I "know" is right. If I wanted a quick thesis, however, doing the unification, verifying a DOM policy language subset, and improving the language primitives / policy language with some guidance from more case studies would probably be the way to go.

The parallel browser stuff is getting more appealing in terms of popular interest, a vehicle for principled work, and a concrete set of problems. The rub is the theoretical component: what's actually new? Is it "just" engineering? I think the engineering challenge is crucial: just like we don't know how to build a multicore OS, which is recognized as a fundamental systems research question, so is building the browser, which is now essentially the 'other' stuff that's expected but not in the kernel. As I look at my Kindle and iPhone, I know I could use the speed. There's a clear problem -- but could it be solved by some guy who knows assembly, a few simple algorithms, or network-friendly compression algorithms? Luckily, answering even that is an open and crucial systems question.

However... appealing to the PLer inside, I'm finding common abstractions between my algorithms. The DOM tree is a structured model and a *lot* of computations that tax your CPU are centered around it. After writing another couple of components, I want to step back and figure out: what's an appropriate DSL for writing these browser-style algorithms? Currently, my suspicion is some sort of parallel, incremental (interactive/reactive), and continuous tree language (e.g., pipelines of attribute grammars). There is a lot of theoretical performance work in this area, but it suffers from lack of application, scaling, and unification.

Applying such a language to the variety of challenges in browser development will both make it compelling and flush out algorithmic concerns that aren't apparent when 'just' looking at traditional parsing tasks. Furthermore, hopefully I'll come out with generally useful artifacts: the next yacc and some browser components (like my layout grammars). So, "PICTL: The Parallel, Incremental, and Continuous Tree Language; or, How to Build a Parallel Browser."

We'll see. Should keep me busy for the next couple of years.

Fast and Parallel Webpage Layout

2009-11-12T00:54:00.000-08:00

Realized I haven't posted this one yet. We submitted our first full paper about some of the parallel web browser work. I'm working on cleaning up the extended TR, but the short 10 page version is a more approachable glimpse:

The web browser is a CPU-intensive program. Especially on mobile devices, loading of webpages is too slow, spending much of its time in processing a document's appearance. Due to power constraints, most hardware improvements will come in the form of parallel architectures. This is also true of mobile devices such as phones. Current browsers, however, do not yet fully exploit hardware parallelism, so we are designing a parallel mobile browser. In this paper, we introduce new algorithms for CSS selector matching, layout solving, and font rendering, which represent key components for a fast layout engine. Evaluation on popular sites shows speedups as high as 80x. We also formulate layout solving with attribute grammars, enabling us to not only parallelize our algorithm but prove that it computes in O(log) time and without reflow.

Irrespective of how you feel about our solution, the intro benchmark section surprises most people I talk to about what's actually slow in browsers. Below are basic CPU times and then (not included in the paper) JavaScript times when loading some popular pages. You might suspect that these are not representative of running pages; I found that harder to benchmark, but at least in cases of animations (e.g., loading emails), it's actually still true. Finally, keep in mind handhelds are and will be ~10x+ slower than laptops: 200ms on the laptop used below is 2s+ on a handheld.

Overall CPU task time (ms) when loading a page.

JavaScript CPU task time (ms) when loading a page.

As a disclaimer (and solicitation for input!) the paper is still in draft form. Enjoy!

Back from OOPSLA

2009-11-02T11:40:00.000-08:00

... and now am in a very long email thread about the semantics of synchronous postMessage ('sendMessage') if different origin frames are allowed to run in different processes. Do we model it with yield? To who? Or can there be a deadlock? Will post once I have a semblance of understanding.

Good times. Big ups to the WebDSL and Angular teams for great demos.

As much as I like smart phones

2009-10-01T10:53:00.000-07:00

Closed devices still feel like an Orwellian fantasy-land. It's hard to imagine these absurd licensing distinctions between handhelds and laptops will exist in say, 5 years. Feels just like when I was doing radio and everyone was trying to deal with the whole internet thing. Maybe that means some folks won't ever get it.

POPL program is out

2009-09-30T00:30:00.000-07:00

I'm steadily more and more of a PLDI and ICSE guy, but a few POPL papers look fun this time around:

programming with angelic non-determinism (berkeley bias ;-))
coarse-grained transactions (... brown bias ;-))
verified JIT
integrating typed and untyped code in a scripting language (... what happened to Arjun's paper about it? and will anything happen with the es4 effort beyond cutting down trees?)
monads in action
paralocks

Only one paper looked like it has a chance of blowing my mind about how we write programs. I must be getting old.

In contrast, Wes Weimer gave a great talk today about applying random program edits to fixing bugs. There's been a lot of work in the area -- my favorite was on doing it for programs with illegible type errors -- Wes' trick of reusing existing program fragments was neat, but more interesting was the evaluation on non-toy programs. It works, and even though I suspect it only succeeds for bugs that are already simple to fix, it suggests we're getting close to realistically rethinking the triage process.

Finally, there was surprise about a suggestion to farm out testing to EC2: the current examples of scaling were 4-8 core machines, not 16-20,000 ones I'm used to -- our group's interest in so little cores for mobiles should be the exception, not rule. I'm seeing a lot of that in the community; e.g., there was an otherwise great talk about optimizing points-to analysis recently that I felt also missed the boat here. If there's an age old algorithm that we need to speed up by a few magnitudes, chances are, you can put it on EC2. Scientists have been doing it for years; now it's open for the masses.

Securing the web with continuations!

2009-08-28T23:50:00.000-07:00

The payoff from the previous posts:

Say Alice is an iframe inside Bob and wants to start a shared library with Bob.

alice.html:

library = {y: {x: "call me Ishmael"}};

bob.html:

var library = makePostMembrane(document.getElementById('alice').contentWindow).getRoot("library");
alert(library.y().x())

Technical aside: unfortunately, Strands etc. do not support continuations captured in redefined field accessors (setters/getters), so I didn't quite achieve the transparency goal of "library.y.x", but close :) Maybe try hacking in support if I have time.

The architecture is somewhat interesting:

One cross-frame 'networking' library for using the string-passing abilities of postMessage to make sharing closures and objects between frames no different from passing to them to functions/actors in the same context: no more JSON and strange asynchronous protocols.
Optionally, our membrane library
More optionally, one of our view/policy libraries

Digging deeper..

To build 1), transparent sharing, we load libraries to CPS the page and construct proxy objects that proxy shared-object interactions between frames viz. the asynchronous postMessage primitive for passing strings between frames. Pretty quickly, it's clear there are distributed object usage concerns like deadlock. Our library helps a bit (e.g., handshaking for initialization and caching), but the push for process-per-origin/process-per-frame has created serious usability problems. The pickling support doesn't help you with the concurrency, and my tactic of using continuations hides the ugliness in the typical case, but, in reality (and, arguably, in the normal code without the library), there are yields in the middle of event handling! Invariants might not be held when control is resumed if folks aren't careful. Perhaps flapjax to the rescue? :) A transactional approach might make sense... but then again... I suspect it'd be horrendous in this domain: transparency is the goal.

Now 2) If, instead of exporting say "window" to be shared, we exported a fresh "membrane(window)" for every iframe, we can, at any time, turn on/off or even modify access to shared objects and even be selective about for which principal. Again, for free. Sort of like flying with Python, but safer. Complete mediation ftw! Also happens to be the first true aspect system for JavaScript and introduces a new notion of secure advice.

Writing behavior for 2) from scratch and per-field/object/method/etc. is cool at first, but quickly, you hit repetitive abstractions. Enter 3): a binary yes/no policy language (the 'who' is whoever has the object reference; the action is 'invoke', so all that is left is the yes/no choice on the resource). That's not quite true: introducing exceptions on DOM access might break programs, so we might want to semantically hide elements. Generalizing, we see we just want to create a secure bidirectional view , which we do for a useful case. Would be fun to create more combinators :)

... and now... benchmarking and updating the writeup :(

JavaScript Continuation Support? 2: Strands

2009-08-19T03:58:00.000-07:00

Strands did what I expected (though still need to write my actual app using it :)):

Yields "123". Requiring "new Future(go2)" isn't that wonky to work with in terms of my transparency goals: just wrap the entire program in a thunk and call it as a future.

Setting up the library took a bit of editing: line 344 of strand.js had a strange eval statement that wasn't parsing so I removed it (Firefox 3.5.2). Depending on how you invoke it, you might need to change some hardcoded default paths. I couldn't get the compiler mode working, unfortunately. We'll see if it can handle big APIs :)

JavaScript Continuation Support? 1: NarrativeJS

2009-08-19T01:37:00.000-07:00

Narrative JS enables you to define a sleep function in JavaScript:

function sleep (ms) {
var n = new EventReceiver();
setTimeout(n, ms);
n.wait->(); //block until n called
}

Now, we can sleep between printing without manual CPSing:

function writer() {
document.write("1");
sleep->(1000);
document.write("2");
}
writer();

This is close to what I wanted.. but not enough. Consider the following:

writer();
document.write("3");

I expected to see "1", and then, a second later, "123". Unfortunately, I saw "132"! The magic incantation would have been:

writer->();
document.write("3");

Essentially, the extension broke function encapsulation with respect to control. I can see merit to it -- rewriting becomes a local process. I want to truly and transparently write my asynchronous code in a synchronous manner (for a reason to be disclosed later): NarrativeJS helps clean up callback code while maintaining basic callback-style code structure (so you don't worry differently about a UI event handling mucking with state between callbacks), but it doesn't restore the synchronous semantics.

This is great... but I want the transformation to be global: sleep(), not sleep->(). Hopefully Strands fares better.

JavaScript Continuation Support?

2009-08-19T00:17:00.000-07:00

Any recommendations for a JavaScript extension to support continuations?

I want to straighten some callbacks for Google Maps (and, yeah, I know Flapjax is another way to do that!). The important part is that I'll be wrapping their API: user code should look like "x = map.getZip(...)" and my wrapper will add in the continuations behind the scenes.

NarrativeJS was early on continuation support, but I don't think it supports dynamic code loading (and I have to trust it wraps gmaps correctly!). More recent approaches (jwacs, strands) seem to build upon it and somehow use JS 1.7 generators for more native support and dynamic code loading, but they seem to add wrapping obligations to callsites that I'm explicitly trying to avoid.

The pay off will be insanely cool :)

Back on the mainland

2009-08-18T00:20:00.000-07:00

Crazy vacation #2: Hawaii! AKA, Leo learns how to surf.

Other news..

MSR work is going well.
Flapjax paper for OOPSLA won a best paper award -- and it actually left out a lot of the good stuff. E.g., talking about how to interface FRP code with imperative APIs without destroying performance, experiences at Berkeley getting undergrads to use and implement an FRP system, and, as Mike noted, his integration of a more relational (lense) layer was relegated to a couple of paragraphs that probably don't make any sense for newcomers.
I think I want to take our web application paper out of the dustbin, extend it a bit, and try for ICSE in a few weeks. I love that there was an FSE position paper suggesting someone should do work like ours yet the conference rejected ours that actually did it ;-) This paper has been a frustrating process, yet I think it's as exciting as our parallel browser work.
For this week, I want to add a cool postmessage layer to our membrane work (our main usage was for Caja, but it helps even in MashupOS style isolation approaches). Reviewers for the paper would be appreciated -- not sure if we're going for NDSS or WWW.
Talk @ Adobe on the parallel web browser soon, finishing font benchmarks, and cleaning up prose for the parallel CSS paper (IPDPS? PLDI? already several pages over..)

August/September will be nuts with paper polishing. But, luckily, back to research after that.

Finally... there's talk of a half-marathon in Napa for Halloween. I did ~5 miles on somewhat hilly terrain a few times last week in Hawaii (going around diamond head), but never have tried longer. Have started working on my 5k (~26min or 8.5min miles), which seems to have led to my bumping up normal pace mileage. Might need to be more methodical about this if I want to enjoy Napa after the marathon :)

Go Lester!

2009-07-26T12:06:00.000-07:00

There's a reason our house is called the NerdFrat: Lester's team is on top of the Netflix leader board again! This time, they passed the threshold for the $1,000,000 prize. Go Lester!

Progress

2009-07-16T22:28:00.001-07:00

Finished my edits for the Flapjax paper... now to keep ploughing through the backlog of other papers from the past 2 years. Ben seems to have seen through me: he's making me start the new browser security one already. Yikes. Academia is weird.

Summer Research

2009-07-15T02:06:00.000-07:00

The sausage factory sure is ugly. Dealing with ~15 years of backwards-compatible interpreter source code is making my summer hacking much slower than normal =/ Starting to get the hang of it..

The point of semantics

2009-06-29T00:17:00.000-07:00

There are essentially three purposes for language semantics. Overall, as a smell test to guide language design: if you can't define a feature, it's probably bad. Second, to help other implementers of our language and programmers for the language -- unfortunately, I'd claim we generally fail on this point. Third, to help structure proofs about our language.

As part of the preparation for a paper submission, I'm finishing up my formalization of a subset of CSS 2.1 (blocks, inlines, inline-blocks, and floats) from last year. My first two, direct formalization approaches failed the smell test so Ras and I created a more orthogonal kernel language. It's small, and as the CSS spec is a scattered hodge-podge of prose and visual examples riddled with ambiguities, we phrase it as a total and deterministic attribute grammar that is easy to evaluate in parallel. Finally, to prove that it can be implemented efficiently (e.g., linear in the number of elements on a page, meaning no reflows), the grammar without floats leads to a syntactic proof, and the version with floats then only has to explain away some edge cases (using a single-assignment invariant, which can probably also be made syntactic).

All of this should have happened 10 years ago. However, the academic language design community, as per the norm, seems to have been late to the party. Instead, we have huge, slow interpreters that don't give the same answers and a generation of abused and confused artists and designers.

An evil test case

2009-06-26T23:23:00.000-07:00

Opera, WebKit, and Firefox are supposed to conform to CSS 2.1 standards, at least, right?

A fun test:


<div style="width: 30px; height: 30px; background-color: blue; padding: 1px">
  <div style="display: block; background-color: red; padding: 1px">
  <div style="opacity: .1; float: left; width: 100px; height: 40px; background-color: green">a</div>
  <div style="opacity: .2; float: left; width: 100px; height: 40px; background-color: green">b</div>
  <div style="opacity: .3; float: left; width: 100px; height: 40px; background-color: green">c</div>
  <div style="width: 50px; height: 10px; background-color: green">d</div>
  </div>
</div>

Do three versions of it: set the red box to be display block, inline-block, and inline. A little subtle to why this breaks is that, while these browsers might conform to the CSS specification for these (I'm still not sure about this), it exercises ambiguously defined parts of the spec.

For the few folks actually implementing this stuff, it exercises ambiguity in the definition of preferred widths, preferred minimum widths, and shrink-to-fit in the presence of floats.

Formalizing one fully-defined interpretation of the spec is... interesting. Thought I was done, but realized I wasn't =/

First weekend in Seattle

2009-06-12T22:25:00.001-07:00

Still looking for a place, but Capitol Hill successfully captured my heart:

Lunch: jamon serrano crepe @ joe bar cafe
Snack: picked up a copy of Pride and Prejudice and Zombies and headed off to another cafe
Discovered Dilletante, a chocolate cafe and chocolate martini bar -- opens at 4pm, so on my TODO list

I also somehow came across two free passes to the Seattle International Film Festival that is ending this weekend. Viable candidates (will see one each on both remaining days; haven't found anyone else who is interested yet):

Saturday:

~~In Your Absence~~
Breathless (it was great!)
~~Fifty Dead Men~~
~~Flame & Citron~~
~~Forever Enthralled~~

Sunday:

~~Marcello Marcello~~
The Shaft (done well)
~~Involuntary~~
~~OSS 117: Lost in Rio (+ closing gala)~~
~~The Overbrook Brothers~~
~~A Pain in the Ass~~

300+ movies over one month... that's an intense festival. Despite the lack of an apartment and a slowdown on my research, summer is going well (and I apparently had a subletter for my place in Berkeley without realizing it!)

RazorFish

2009-06-11T08:35:00.000-07:00

I think the most significant demonstration was somewhere between 5:00 and 5:30. Would have loved to have hacked on this in high school :)

Security as a Disease

2009-06-07T09:10:00.000-07:00

Lovely post by Rob Meijer on the capability list about how to write a useful Wikipedia article (in particular, for cleaning up the entry on ambient authority):

A good way for me personally to think about the audience for infosec related subjects, is to think about myself on medical related subjects.

...

In this case, the main things you would want to know would be:

* How do I know if I have ambientitus?

If I know I don't have ambientitus, I'm out, off to find other possible sources of my symptom. If it is likely that I have ambientitus, I would want to know:

* How bad is it? Is it fatal?

...

That totally made my morning. Worth reading.

updateable secure views

2009-06-05T20:17:00.000-07:00

Was looking at what the bidirectional programming folks at UPenn were up to, and got excited: the paper we had rejected last year about secure browser programming through views was, in another form, accepted for these guys: Updateable Security Views. Our take on it (a tentative title was "membranes, views, and browsers") was of capabilities and flexibility; this clearly has different principles (static checking, information flow, etc.). The important thing is that the idea is gaining traction!

Assembly Language of the Web

2009-06-04T20:48:00.000-07:00

What should be the assembly language of the web? JavaScript has risen as the pragmatic choice, with the Flash VM trailing far behind. Some elements of Google think x86 is the way to go.

With Flapjax, JS was a fine choice: we were interested in rewiring existing AJAX-style apps and could do it. Sometimes, with both Flapjax and the membrane work, it wasn't enough (weak references, reflection / interpositioning woes, no good separability). Other notions, like parallelism and DB transactions, are just missing entirely (e.g., workers were not enough when I did some Firefox extension work).

Given a void, what's the way forward? CLR? DLR? JS? x86? VMs? Folks like Erik Meijer and Gilad Bracha seem comfortable with JS is the new assembly, but I'm not. At best, it would then need an overhaul that it isn't getting, and, at worst, we're slowing the web down by maybe 5-10 years.

Exciting times!

2009-05-27T00:36:00.001-07:00

Thought I'd post a quick status update. I will not actually be here this summer!

1. Browser stuff. Over the next month, I'll be bouncing around and hopefully finishing the initial version of my parallel web page layout algorithms. In the fall, I want to make sure it's all stitched together and then might switch into thinking about adaptivity or, even more general, parallel scripting.

2. Webpage model extraction / exploration stuff. After the browser work reaches a good state (PPoPP?), I'll be rewriting and scaling out our blackbox analyzer and will make it directed. If collaboration works out, there'll be some interesting twists (either a new type of analysis or integrating and expanding some earlier whitebox ideas)

3. Summer! Something mysterious at Microsoft Research about browser security. I'm guessing/hoping a principled clean-slate approach or some program analysis.

One of many flights start tomorrow.

mixing thread-aware and thread-agnostic code

2009-05-25T00:46:00.000-07:00

For almost all of the algorithms I've been playing with for the parallel browser, Cilk-style parallelism matches. My development pattern is to do a sequential version, do a Cilk++ sketch, and then, for final tweaking, convert to TBB. (... and a lot of iteration involving hawkish monitoring of KCacheGrind statistics). However, invariably, something always goes wrong.

This week, it's using task-parallelism with a multi-threaded library. Task parallelism gets you away from the notion of a thread: whenever you have a unit of work, you just spawn it off, and thus may have many tasks for only a few processors. With threads, assuming you're CPU bound, you have as many threads as processors. FreeType2 is written for threaded use: each thread gets its own Library. However, task parallel usage (I'm rendering a bunch of glyphs: turning one character into a pixel can be thought of as a task) doesn't map nicely -- if I were to create a Library per task, I'd have to create thousands of Libraries instead of, say, 8.

The naive solution is to set up a resource pool: a task asks the pool for a Library when it starts, and returns it when it finishes. If there is no Library available, it gets created. If tasks are really small (e.g., individual characters, as opposed to, say, words), there'll be a lot of chatter when trying to get these Libraries (and, even if not, locks waste cycles, which is still a penalty proportional to task size).

TBB, because it is a library level solution, has actual task objects (Cilk should just puts some sort of continuation mark on the stack) and therefore faces the same problem all the time. It provides conveniences for reusing task objects (think of it like a manual TCO or trampoline). When reusing a task, a good habit can be to reuse data within it. In this case, when a task completes, it passes off its Library object to the next one that gets/becomes the reified task object.

Unfortunately, I don't think the code will work out that well. In reality, there's a hierarchy of resources (Library -> {Font}, Font -> {Glyph}). It'll work, but the impedance mismatch will cause some slowdowns.

collaborative security

2009-05-20T21:42:00.000-07:00

Was watching a video of Aza Raskin and, around 18:00, I got excited. Can we treat security as a people problem?

I've been mulling about this both in my work in overcoming data silos and in extracting models of applications. In the former, the user might want to add extra security to an app like google calendar, say by doing special permissions on for a particular event or even encrypting data before Google sees it, and, in the model extraction, I'd like users to pool their models together to collaboratively get bigger ones -- but I don't want stuff like bank account info to leak over. This latter problem occurs slightly differently in some of my work in mashup security: can we trust an extension to translate a webpage, but not, say, leak a bank account number?

Everyone, including Aza, bashed on the UAC: we can't just pepper users with dialog boxes. We really want things like blacklists That Just Work. Aza asks, just as we might trust a smart nephew to buy us a computer, might we trust one to figure out security for us? In the absence of a smart nephew, can we learn the security policy? What do cautious people normally say to a dialog box? Is there a bit of information on a page that users generally mark as privileged?

In three of my projects so far, I've found cases where I didn't think the application writer could a priori determine the appropriate action, yet doubt that the casual web user can either. What would it mean to build a browser or application extension that outsources security?