>> Jitu Padhye: It's a great pleasure to welcome Brad Karp. He's an old friend of mine and
many of you know him. He has done a bunch of work on many different things. The most
famous work he has done was geographical routing. Now he has ventured into other areas;
one of these is JavaScript security work. It's gotten a lot of attraction. People in Google and
Firefox, as you can see, are interested and he's going to talk about that.
>> Brad Karp: Thanks, Jitu. Well, thank you all for coming, and thank you to whoever is out
there watching online for coming. As Jitu says, I'm Brad Karp, and I'm going to talk to you about
privacy for web applications today; and I’m going to mostly talk to you about it, privacy is a
huge problem and there are many, many layers of the sort of software and hardware stack for
the typical browser user so I'm not going to be talking about something that is comprehensive
about all the layers of the stack. For example, I will not be telling you what to do about bad
USB today even though while you're using a browser a bad USB could own you. I'll be focusing
on the web architecture and the browser architecture in JavaScript in particular for today.
So what is this thing they call the web? Well, it used to be in the good old days that the web
was just a way of putting documents online. If you really wanted to get fancy maybe you would
have some links to a few things. It was hypertext; it was very cool. One of the things I find
amusing personally is that some of the most hard-core kernel hacker kind of people you can
think of in the systems area have the most basic webpages possible. There's almost an inverse
correlation, not to pick on anybody in particular.
So the web has evolved from being just simple pages of static content to sort of pretty
complicated and feature-ful applications that we sort of rely on on a daily basis. And so of
course as you all well know webpages contain JavaScript code and when you visit a webpage
containing JavaScript code the browser just download it and executes it. So I'd like to claim, it's
not really a contentious claim I hope, that one of the reasons that web applications have been
such a great success is that it's really easy to build web applications. That's because you can
sort of say that web applications are the apotheosis of open source. Like the code has to be
downloaded to the browser, at least the JavaScript code for the client side, so that means
anybody out there who that runs that web app can totally see what the JavaScript code is for
implementing that browser side functionality and they can steal it, borrow it, repurpose it, and
reuse it. And this is exactly what people do. It's really easy to reuse code from existing web
applications because of the way the web works. So you wind up with these web apps that are
sort of pastiches. You sort of cobble together little fragments of JavaScript and libraries, some
more modular than others from other sites, but interestingly they’re written by other parties.
Even if you're developing a web app yourself you often cobble together code written by other
parties.
So once you say that you're going to be running web applications and that you're going to be
using code written by other parties maybe we should pause a moment just to think about
privacy. So obviously a lot of these applications you use handle data that you consider
sensitive, maybe your bank statements, your location, your e-mail, and of course, yeah.
>>: Is this something, the fact that you use a bunch of libraries potentially [inaudible]?
>> Brad Karp: No, it's not. Absolutely not. So there's open source software and so there are
third-party libraries that people use all the time in open-source software. So I'm not claiming
that this is the first time there have been open source libraries. I'm simply claiming that in
every web application it is sort of the norm almost required that there is a bunch of open
source on the browser side which is not true for other applications.
>>: Well, in the web though you’d be sourcing those libraries from a third party host which has
the ability to change those things. That's different from [inaudible].
>> Brad Karp: Also correct. And that will come up later in the talk as well, in fact. Actually,
although you don't have to source from a third-party you also host it on your own site. So this
JavaScript developer of course could be malicious. So the user doesn't know any of these
developers who wrote the third-party code, and if you asked a computer science
undergraduate is it advisable to run programs presented to you by parties you don’t trust
they’d probably say no. Of course your browser does it without asking you every time you visit
a website. And of course, even in a single running browser, you visit multiple sites in different
tabs. This is commonplace in one binary that you're running. So many of you are web
architecture experts already and so this is a broad audience talk so I apologize for boring you
for a couple of slides as we sort of work up to where we want to get.
So here's a quick example that's very relevant in London where I live which I call bad weather
and it goes like this: you’re running a browser, you have a couple of tabs open, you visit your
bank account, it looks like things aren't looking so good long term there and you visit a weather
website, this was obviously not for London, and you are browsing these two tabs at the same
time, and one thing you might ask yourself is if the developer of a weather.com is not a nice
person. So no third-party, at least with respect to weather.com itself, just the first party who
wrote weather.com put some bad JavaScript in the weather.com page. So what's to stop
weather.com from just reading your bank statement and from chase.com and leaking it and
sending it to the guy who wrote the code for weather.com and runs the server?
So of course as you all presumably already know in the beginning there was the same origin
policy, and what this said was that we'll have a rule, a policy baked into the browser, that if
there's code inside weather.com and it was retrieved from the origin or you might just think of
it as a domain name, weather.com, we’ll say that that code is not allowed to read from the data
from other origins either inside the browser or from other servers in fact from other origins.
Same origin policy. So not from the server chase.com and in fact chase.com is not allowed to
read from weather.com either. So the same origin policy in brief just says that you disallow
cross origin reads between contexts. What a context? It's a tab, but contexts are also
hierarchical inside of a tab. You could have an iframe or other constructs in the browser
architecture that are contexts for browsing.
And so of course this is a form of discretionary access control. You have a decision about yes or
no. You can either read something in which case it's yours and you can do whatever you want
with it thereafter, or you can't read something and that's it. You just can't read it ever. So
what's interesting about the same origin policy is that you can quickly show that at least the
way browsers use it it sort of fails at opposite ways at the same time. It’s both too permissive
and too restrictive. Some of the time it lets things happen that shouldn't happen and some of
the time it keeps you from doing things that you would really like to do that would be very
useful.
So, for example, it’s too permissive. If you have third-party codes, we are not saying first party
JavaScript in a site now, third-party that you took from somewhere else. If there's malicious
third-party code that the Barclays Bank didn't know was malicious and they included it in their
site say in a script tag then if you enclose JavaScript code in a page that third-party code runs
with the page’s authority. This means that actually that malicious JavaScript could read bank
statement data from inside the page and leak it to say evil.com. There's nothing disallowing
that in the SOP.
So it's too permissive, but it's also too restrictive. Sometimes it would be really nice if you want
to build mashup applications to be able to read data cross origins. So, for example, you might
have a third-party who under their own domain name wants to publish a useful web application
like something like Quicken, the web version of this exists; it's called Mint, recently acquired by
Intuit. So what you'd like to do is be able to render in the browser graphs of sort of all of your
expenses and how you’ve been spending your money integrated from all of your bank
statements from the different credit cards and bank accounts that you have. So this is what
Quicken used to do on the client side as a binary application. Mint.com does it on the web.
And it turns out that when mint.com, if they wanted to write this in JavaScript and why
shouldn’t they be able to, they just can't because the same origin policy, we’ll get to more
complicated things than the SOP in just a moment, doesn’t let code from mint.com read from
origins chase.com or hsbc.com so we just can't write the application and have it run. Yeah.
>>: But fundamentally I don’t want to [inaudible] too much, but it’s not obvious the client-side
composition is what they desire because of the lack of any sort of integrity enforcement on the
client in the first place and so typically-
>> Brad Karp: Who desires?
>>: Mint.com. So these days all of this composition happens server-side and the client gets>> Brad Karp: I'm going to talk about what happens today in just a moment, but yeah. So
sorry. I don't follow. What is the thing that Mint doesn't want? They're worried about
integrity?
>>: Client-side integrity is not something that is supported by these browsers. So not it's not
obvious.
>> Brad Karp: So it's supported by the system I'm going to be telling you about today that's our
work in addition to secrecy.
>>: Okay. But it's not obvious that that kind of data have burning desire to have everything
come to client in terms of composition.
>> Brad Karp: Okay. So I'm going to be talking about some of the downsides of the way Mint,
from the user’s perspective, is implemented today which I'm sure you already know. So it's not
just what Mint wants but it's what users may want too. So I'll be talking about that in just a few
more moments. Yeah.
>>: So I guess I was going to ask the same question, literally the same question because the way
mint.com works is that I will give it all my passwords [inaudible]. They put the data on the
server, script the pages or something, maybe [inaudible]>> Brad Karp: So this is part of my talk actually, but yes, that’s what they do. And I would say,
sorry?
>>: And you say there's something wrong with it?
>> Brad Karp: I say that my releasing my credentials to my bank accounts to a third-party sucks.
Of course people saw that the same origin policy failed in a variety of ways early on and so they
keep making these Band-Aid fixes to the same origin policy one after another as the browser
evolves over time. So these that are most commonly used are CORS and CSP. I’ll talk about CSP
first. CSP is Content Security Policy, and it's a way of tightening the SOP and making it more
restrictive than it would be by default. And the way that this works, roughly speaking, is in one
bullet that a server can whitelist origins to which a page can send requests. So you can
explicitly whitelist some origins, so wait, I’m whitelisting but that's why is that tightening? Well,
because the things that you don't whitelist by default will now not be able to be contacted by
the page. So if there's malicious JavaScript in chase.com and chase.com does not explicitly
whitelist evil.biz then even if chase.com included malicious JavaScript and a script tag the script
would be prohibited from leaking to evil.biz.
Then there's CORS, Cross Origin Resource Sharing, which is sort of the complement in a way to
CSP. It lets the server say that it wants to loosen the same origin policy by whitelisting different
origins in the server’s origin that can read from the page. So, for example, if you wanted to
implement Mint maybe for some reason hsbc.com would whitelist mint.cc because they
wanted their bank customers to be able to use Mint on the bank statements from HSBC and
maybe Chase would say no way, I'm not up for that. In fact, most banks would say no way, I'm
not up for it because banks are worried about liability of what happens to data that they send
over the Internet to a customer. In fact, banks are worried about fraud and all kinds of other
things that could hurt the bank, at least in the model where banks bear the cost of fraud which
may or may not continue I'm told. So all of this is still discretionary access control, right? Yeah.
>>: So can you tell us a little bit about how these extensions came about? Like did somebody
design these and then go argue for them in ITF or did they go convinced Chrome or IE or
somebody?
>> Brad Karp: Sure. So it’s just what you would expect which is not very pretty. So we had a
browsing architecture, we had the same origin policy, people found that web developers found
and browser designers found that there were certain kinds of applications or certain kinds of
vulnerabilities that they didn't like. The W3C had working groups that started talking about
some of these things with browser vendors and then there's a standards process at W3C. W3C
can't force browser vendors to do things, but there’s some decision process just as if the ITF
creates a standard. W3C proposes a standard and then browser vendors decide if they're going
to implement it based on whether they feel like it really matters enough, whether it's worth
their resources, and so on. That’s my understanding of how we got here basically.
>>: I think in some cases it was more organic, like for instance the fact that images can be
sourced from the main [inaudible]. That's just kind of something that came up in the 90s
because that's how people want it. [inaudible] was relatively huge at that point.
>> Brad Karp: Right. So the question you are asking was about these things. What I described
was how these things came about. Other things are completely ad hoc and just sort of came
about because somebody thought it was a good idea at some point.
So the question is, so this is all still discretionary access control, though. So is this good
enough? We have more flexible discretionary access control. Well, I would argue no, it's still
not good enough. So let me try to give you a couple examples of why this is. The first example
is one I've already alluded to which is third party matchups. So consider mint.com. This is what
you guys were already talking about just a moment ago. How does mint.com work today and
what might be some of the reasons why it works that way today?
So mint.com makes you pretty graphs of how much money you're spending, and today the
browser can't support a secure third-party mashup version of mint.com. Why? Well, let's talk
about why. So if you have a choice basically, what discretionary access control gives you is a
choice between functionality and privacy. It literally forces you to choose only one in some
situations like this. So in the case of privacy if the banks decided that they were not going to
allow CORS’ overrides to let mint.com read data from Chase and HSBC well, that’s strong
privacy but no mint.com app for the user on the browser side. So no functionality, yes, privacy.
Or if CORS allowed mint.com’s JavaScript to read from the banks then you’d wind up with
functionality. You'd be able to run mint.com in the browser, but of course the horse has left
the barn. Now the JavaScript hosted by mint.com has your data from your banks and there's
nothing stopping it from sending that data elsewhere or to mint.com server. Yeah.
>>: So isn’t there a middle ground where you put each origin’s content in frames and then you
allow each origin to control the contents out of its own frame and then if two frames want to
communicate you have to use Post Message. So it seems like there's like this third ground
which allows, for example, chase.com to control what graphs it shows in its own frame but then
mint.com can't directly poke at it and say give me your sensitive JavaScript [inaudible].
>> Brad Karp: I see. So which code is Mint contributing to this in this model that you're talking
about? Like what script is Mint running?
>>: Yeah. So it's unclear. So this is why it's kind of middle ground because in this case Mint, for
example, can query each one of those frames. What are you willing to disclose? Could you
display this? But Mint doesn't actually get to mandate that and so that’s just one thing to think
about because in part people already try to use frames as these sort of isolation [inaudible]
region. But you're exactly right that it's sort of, the aggregator has this very weak control of
what the app does and asking for favors, basically.
>> Brad Karp: Right. So if Mint wants to make sure that its app works they sort of supplicate to
the frames owned by Chase and HSBC in your model. Another interesting question is who's in
control of the data? Whose data is it? Is it Chase or is it me if I'm Chase’s customer? If I decide
that I want to run the Mint app.
So in reality, as Jitu already described, what Mint does is it just asks all its users for their bank
login credentials and it pulls them to Mint’s servers. You might say nobody would ever do that,
what a terrible idea. Well, Mint has over 10 million users which is why Intuit just bought them.
So I believe, and I think many people should believe, that this is an abysmal model for privacy.
So this was actually a somewhat more complicated example of why discretionary access control
might not be sufficient. Let's just give them a simpler example that was one that comes up a
fair bit. Lots of people incorporate third-party libraries into their web apps and so a big thing
that people want to do since passwords suck so much is have password strength checker on
their website when you sort of create a password. It gives you a green icon if the password is
considered good and a red one if it's considered weak. So if Chase wants to integrate a script
from sketchy.ru, which does password strength checking today, Chase has the password that
you typed into a form in there and if it were willing to say using Post Message send the
password to a script run by sketchy.ru well then sketchy.ru has the password, and it's all over at
this point. So that's what would happen today pretty much.
>>: But are there real cases of large companies using untrusted services of this [inaudible]? I
mean previous example>> Brad Karp: There's jQuery, for example. jQuery is used by 77 percent of the quant cast top
10,000 sites actually.
>>: [inaudible] on their websites.
>>: Or rather use the Google CPS.
>> Brad Karp: Wait. Stop. Why does it matter? I don't understand why one is better than the
other. If it's pulled from jQuery.org somebody could own jQuery.org. If it's hosted in their
website do they like audit all of jQuery?
>>: [inaudible] enough people are using>> Brad Karp: Wait a minute. That doesn't mean it's not a problem.
>>: Enough people are using jQuery that if jQuery starts sending random stuff to random
places>> Brad Karp: So we shouldn't worry about it.
>>: No. That's not what he's saying.
>>: I'm saying with any untrusted code there is, part of the safety you get with jQuery is safety
in numbers. Lots of people are using it which means lots of people are also debugging with it
trying figure out what the heck's going on when they’re using it. And enough people have
problems with it that they have to go in and look at the code to figure out what the heck's going
on sometimes. So if you do download, if you run it off the site yes, if the site is compromised
tomorrow you’re vulnerable tomorrow. If you got a copy from a month ago you’ve got a pretty
good sense that of the libraries you could be using this is something where the code is public,
everyone>> Brad Karp: So I think we could have an interesting debate that I don't know if I have time for
right now about this. There have been backdoors found in all kinds of software, not necessarily
JavaScript software, that have been deeply embedded and lying there and nobody spotted
them and then they became active at a particular time. I agree with you that if you use a library
a lot of people use that's a lot of eyes and that's that traditional open source argument coming
from a Microsoft employee, I love it, but is that a strong guarantee? No.
>>: No, but you wouldn’t [inaudible] same argument, right? I would argue that [inaudible] have
left the [inaudible] already, use that laptop to access the website and laptop runs [inaudible].
The fact that it’s open source is irrelevant because you never actually probably read the
[inaudible].
>> Brad Karp: Sorry, no. What we're talking about here is there's going to be, it’s just like in
any secure system, there are going to be components that you trust and components that you
don't trust. So you are making a reductio ad absurdum argument and what I'm saying is I'm not
talking about whether I trust the operating system code or not, I'm not talking about even
whether I trust the browser binary or not. I do. I am talking about it. You do trust those things.
What I'm talking about is scripts that are malicious and how to confine scripts that may be
malicious. So you’ve got to trust something.
Well, we are done. Even if the library looks like it does the right thing it says yeah, that's a weak
password. It’s already gone. So this was just two quick examples, but discretionary access
control actually fails any lot of situations. I talked to you about third-party mashups and I
talked to you about libraries with narrow APIs like a password strength checker.
There are other kinds of situations where untrusted code JavaScript could be dangerous. One
of them is you could actually have mutually distrusting services. So imagine that you had an
online document editor and it provided code for document editing and then you wanted to
have an encrypted online document editor that actually made sure that when your document
was stored in the cloud it was always encrypted. And so you might decide that there was some
organization you really trusted to write the crypto code for some reason and maybe you
trusted Google to write the document editor code but not the crypto code. How would the
trust work out? Maybe Google's editor code doesn't trust EFF, maybe EFF doesn't trust Google.
You would need some kind of architecture to sort of let you compose this code together and
still build a working application. You could also have libraries. The password strength checker
is an easy case. The harder case is a library with no API, or almost no API, which is jQuery.
jQuery sort of requires you to include it in the page in order to work and so it has unfettered
access to everything in your page. And that's just what jQuery is. You can't use jQuery unless
you're willing to that.
So if we step back for a moment maybe part of the problem is just that discretionary access
control is too brittle as a design. So all of these things, SOP, Content Security Policy, Cross
Origin Resource Sharing, they all either deny access or just give up control of the data utterly to
the reader once they allow reading. So even in the case where you used frames, like James was
saying, you still completely give up control of the data. If the bank makes a bad call and says,
oh yes, I trust this domain and the script it turns out to be malicious then the script can do
whatever it wants with the data after that because the bank made the wrong call with
discretionary access control.
So I would say that this all or nothing behavior of discretionary access control is a bad fit for the
web because the web is a scenario where applications routinely integrate untrusted code and
we have this unpalatable choice I described of privacy versus functionality. Will my app work or
can I have privacy, but not both. So the challenge I'd like to try to address in this talk is how can
we achieve both privacy and functionality in web applications? So making sure that sensitive
data is not leaked by untrusted code but letting people build feature-ful web applications on
the browser side.
So the germ of a solution is a very old idea. Computer science is really starting to have some
gray hair as a field I realized when I put this citation in this slide, but you've all heard of
confinement. Butler Lampson articulated the idea in 1973 although it's been fairly allusive in
real systems that people use every day. And the idea in confinement is very easy to state as a
goal which is let’s just let untrusted code read sensitive data but preventing the untrusted code
from leaking the data. So in the mint.com third-party mashup example the fantasy version of
this is yeah, so you let the JavaScript from mint.com read all the bank statement data and then
something, maybe it's the browser or COR, after those reads happen somehow prevents Mint
from getting outside of this brick wall and sending anything anywhere even to the mint.com
origin anywhere.
You could say oh, well confinement, there's been 1 million papers on confinement. Isn't this a
solved problem? We have confinement for Haskell, confinement for Java, everybody knows Jif,
right, or you could change JavaScript itself to enforce information flow control. There's been a
bunch of papers on adding fine-grained IFC to JavaScript, JSFlow and so forth and what the
semantics, the changed semantics of JavaScript are after you make that addition. But if you
want to practically deploy confinement in the web browser there's some designs constraints
that are pretty harsh. One of them is that it's possible web developers may not be willing to
learn a new language or at least many of them. They like JavaScript. Also, you can't really
touch the JavaScript runtime or it’s very, very hard to do so.
So, as you probably know, the v8 JavaScript engine, for example, or SpiderMonkey are just in
time compiled and they're very, very highly optimized and in the browser performance wars
people behave somewhat irrationally. There's sort of zero tolerance for adding one instruction
on the hot path for running JavaScript code because it’s going to make some table of numbers
go up by a millisecond and then you're not the fastest browser anymore in some ridiculous the
valuation. So people are very hostile to adding anything at all in functionality if it's on the hot
path in the JavaScript runtime.
Also, you’ve got to keep JavaScript, but there are also concepts in place that web devs are used
to like the idea of origins as principles which started with the same origin policy. It would be
nice if we could keep that. Ideally you would keep the same in page constructs of the kinds of
things that James was mentioning, new iframes, pages and so on, as security boundaries which
is what people already are familiar with.
So the good news is if you look at the web right but by accident the web is a pretty good fit for
confinement. You just have to look at it right. So why might I say the browser is hospitable to
confinement? Well, browsers already have execution contexts, things like frames and iframes
and isolation is enforced by the browser across these boundaries, in these execution contexts
already with discretionary access control. So maybe we could enforce mandatory access
control but at a context granularity, so at a frame, an iframe and tab granularity not at a
JavaScript object granularity. So what that would mean is if we didn't have to mess with the
implementation of individual objects we wouldn’t need to change the JavaScript runtime at all.
We could actually bake mandatory access control into the same places in the browser that
enforce discretionary access control between frames today. It's pretty easy to add new APIs to
the browser that manipulate the content of context, the so-called DOM, the Document Object
Model. You can attach policies to messages; there's a very rich substrate in place for making
enhancement to the browser there.
So our system is called COWL. It's Confinement with Origin Web Labels, and it draws on in
some sense mostly known concepts but we put a lot of work in trying to express the concepts in
the form of practical primitives for the web. And the primitives are actually very few. We have
a primitive of labels which are based on web origins which are used to specify mandatory
access control policies, I'll say more about all of these in just a moment; we have labeled
communication which is what lets us enforce mandatory access control between contexts,
separate browsing contexts and we do this in a way that lets you not have to change the
existing Post Message API that people are already familiar with; and finally, there are privileges,
and privileges are primitive in our system that let you express trust; and in particular where this
arises is sometimes mandatory access control you might want to declassify data and decide
that you can release data without limiting its propagation anymore but you would want only
trusted code to do that. So a privilege is a concept in our system, a primitive in our system that
it makes explicit the right to declassify any mandatory access control system. A context can
have a privilege with respect to a label or not. Yeah, James.
>>: So what happens when these labels and what not get into the DOM and into the render? It
seems like the render is like this just seething morass of evil. So, for example, can I leak things
via CSS animation timing?
>> Brad Karp: Are you talking about covert channels in the browser?
>>: Well, I mean in the render size of the DOM itself. So, yeah. It seems like, because one thing
you mentioned earlier is that you want to try to not modify the JavaScript engine if possible,
you want to try to leverage with these pre-existing show points exist in the browser. But if
there are sort of these side channels or covert things that happen inside the DOM I mean that's
exactly where attackers are going to go, right?
>> Brad Karp: That's where they'll go next.
>>: I think that those are two separate questions on some level. So what happens when the
labels go into the DOM how much your [inaudible] and that kind of stuff. I don't mean
performance or limitation [inaudible]. And secondly, of course there's always the question
about side channels which are numerous and exotic and [inaudible].
>> Brad Karp: Sure. So there are a lot of side channels, and I've got a slide talking about side
channels later in the talk. The short answer is we've not advanced to dealing with side channels
yet in this work. We are looking at closing the enormous overt channels that are already there.
>>: But you'll speak about the DOM like how labels can live in the DOM and what that means?
>> Brad Karp: We've not really progressed there either yet. So we don't have>>: But you can [inaudible] a message through Post Message as a label which is fine at the time
of [inaudible] it's all good. And it goes and gets it out of the DOM [inaudible] and the DOM>> Brad Karp: So the context will have the label. This will become more clear maybe when I
talk about how we implement labels in just a moment.
>>: [inaudible].
>> Brad Karp: So let's talk about how we do this since that's what you're curious to know are
labels. Every piece of data in our system is protected by a label and what the label specifies in
terms of origins is basically who cares about the data. You can think of it loosely that way. So,
for example, if there's data that's sensitive to Chase it would just be labeled with the origin
chase.com. Or if there’s data sensitive to both Chase and HSBC it would be labeled with the
conjunction of chase.com and hsbc.com. You'd say why would there be data sensitive to both?
Well, for example, if you were running that third-party mashup from Mint and you synthesize
something out of data from both that's the label you'd wind up with notionally.
So what does this look like? Servers on their responses can set labels in an HTTP header and in
the browser, a browsing context, whatever it is. A tab, a frame, can have a label associated
with it. How do we track labels? As I've already said, COWL tracks labels at the server and
context, browsing context granularity, so pages, iframes, workers, servers. And one thing is
that you can label for convenience for the developer. We let you label a message that you send
with Post Message differently from the context in which you sent the message. Yeah.
>>: [inaudible] what primitive password would've been labeled as being sensitive to evil.com?
Because doesn't it depend on who set up the password box? So the password box itself is let’s
say a jQuery vendor box. jQuery could potentially label it [inaudible] as evil and password box
itself would be set up so that anything under there is tagged as evil.com, right? And J is
[inaudible]. What is the root of integrity?
>> Brad Karp: So the authority to set a label in our system comes from what the origin is,
where the content was retrieved from.
>>: But the password is also retrieved from, was rendered by a vendor even by jQuery. jQuery
renders like a [inaudible] or something.
>> Brad Karp: jQuery is actually, I don't know if what you're asking is specific to jQuery. We
have a whole different schema, there's a different way of dealing with jQuery in our system
that I did not describe here because it would make my talk too long. It is in the paper. So is this
something about jQuery in particular that you're asking about?
>>: Yeah. [inaudible]. So, for example, the way [inaudible]. But the way I would do it is I would
set an element with ID and I would [inaudible] essentially replace that with a box whatever. So
at that time who labels [inaudible]? That's what I'm asking.
>> Brad Karp: So what you're pointing out is that the usage model for jQuery is that it runs with
the authority of the enclosing page, right? That is specific to jQuery. Password checker
libraries that we are talking about are a different use model where they are not enclosed in a
script tag in the page and they do not run with the authority of the enclosing page. They're in a
separate context. This is another model that people use JavaScript in. So I now understand
your question. I have a backup slide that I'll be happy, I can jump to it now if you want on how
we handle jQuery.
Basically the answer to your question is this: if you want to enclose untrusted code with a script
tag we have a way to do it. But what it involves, it almost looks like open SSH privilege
separation. What you wind up doing is you have two compartments, you drop privilege on the
one that has jQuery, and then you have a small trusted code base running in a separate
browsing context and that's sort of a firewall between the jQuery context and the rest of the
network. That's the sort of high level idea. But that is specific to jQuery and libraries like
jQuery that only work if you include them with a script tag because they want to touch the
DOM directly.
Great questions. So label tracking is where I was. So for convenience we let's programmers
label a message that they send with Post Message with a different label than the browsing
context. It has to be at least as restrictive as the browsing context label but you can set a
different label. So this turns out to be a convenient way to share sensitive data. So, for
example, if chase.com downloads a page to your browser, if your browser downloads a page
from chase.com, the initial label is what we call public which means no restriction. Think of it as
the null label. Then if Chase wants to send that password to a third-party library with a narrow
API unlike jQuery then it will use Post Message to send the password to that library and it's free
to, in the COWL System, set a label more restrictive than the one of the base page. But of
course browser server communication had better respect labels. That's very important. So we
need somehow to make sure that there's no way the browser would enforce, that there's no
way for code contained in chase.com, with a browsing context with the label chase.com to send
that password from that browsing context to some other origin. That's not desired in this
model.
And communication across browser context should respect labels too. So in addition, why is
that important? Well, if sketchy.ru is running its library in a separate context that has label
public and then chase.com's context sent the password to sketchy.ru then you wouldn't want, it
has to be transitive. You wouldn't want sketchy.ru to then be able to go ahead and send that
password to the origin that it was downloaded from.
>>: So this stuff is not possible using CSP? It seems like CSP is designed to stop a lot of these
types, like specifically these types of flows.
>> Brad Karp: So CSP is designed for this kind of flow. It doesn't help you at all with third party
mashups. So we have two papers on this work. The first paper was a hot OS paper where what
we did is we described how using mandatory access control lets you do things that you can't do
with CORS and CP and it also subsumes them. So it's strictly more general. So you are correct
that some of the examples I'm getting are things that you could do with CSP. The third-party
mashup is one that you cannot; a mutually distrusting document editor is one that you cannot.
>>: So [inaudible]. So presumably HSBC and Chase would both set their context so that nobody
[inaudible]. So any processing that mint.com has whatever we've now done on [inaudible].
>> Brad Karp: Correct.
>>: Now mint.com provides, this is purely functional [inaudible]. Mint.com provides a number
of competitors which requires it to transmit some data back to the server otherwise it's kind
useless actually.
>> Brad Karp: Wait a minute.
>>: For example, [inaudible]. I'm just making up an example. So that door is closed unless
Chase and HSBC both allow pretty much any data [inaudible].
>> Brad Karp: Or unless you know you're going to try using some of Google's new differential
privacy stuff for setting stuff privately back from the browser to the server, I don't know.
>>: Presumably with SMS the Mint computes any mashup it would be labeled as>> Brad Karp: That's absolutely correct. You’ll have the secrecy label of HSBC and Chase which
means no one in the universe at that point. So if you have an application, so there is an answer
to this, if you have an application, for the example you gave where there is data that is derived
directly from the data that is sensitive to the user the presumption in this design is that the user
doesn't want data derived from the data to be computed by a third-party and leaked anywhere.
>>: I don't want mint.com to have my password. I don't care so much if mint.com has my bank
balance.
>> Brad Karp: Okay. Well there are a lot of people who would disagree with that statement.
>>: 10 million users?
>> Brad Karp: Wait a minute. You can't just say that it's obvious that nobody would care that
mint.com has their bank balance.
>>: [inaudible] example. Of course some people might care. I'm just saying that my password
is more sensitive.
>>: It's a complex negotiation because mint.com is going to know what stocks I own otherwise
it can't go out and get quotes for them, and if it can’t go out and get quotes for them then I lose
functionality.
>> Brad Karp: The browser could get quotes. It's not like Mint needs to know what stocks you
have. There are plenty of open quote services that the browser could directly pull together to
get those quotes.
>>: But if I visiting mint.com on a slow 3G connection on my phone now all of a sudden there
are a lot of run trips that my browser is doing; it’s so much slower than if Mint actually had
access to everything and went and did all the work and sent me back a single HTML page with
all the content.
>> Brad Karp: I accept that.
>>: These are all complex negotiations, but I think the question you're asking is what's called
declassification [inaudible]. It's almost like you don't have a mechanism.
>> Brad Karp: We do have a mechanism for declassification. There’s support for
declassification, but the question is who has the authority to exercise that?
>>: That's always the question.
>> Brad Karp: Exactly right.
>>: [inaudible] because of that as well.
>> Brad Karp: Very briefly.
>>: So mint.com is just like [inaudible]. There's no way to go back.
>> Brad Karp: That's right. All right. So we went through this already. So in order for this
example to work of the third-party password strength checker we’re going to need some way
for the script provided by sketchy.ru to see the data and compute over it. So the way that we
are going to do this, as you do in information flow control systems, is by having a context adopt
a more restrictive label by giving up its ability to communicate with places that should not be
able to see the sensitive data it will then be allowed to read the sensitive data. So, for example,
sketchy.ru could receive a Post Message from chase.com with the password in it labeled, it’s a
labeled Post Message with a label chase.com. It then possesses the labeled message but the
browser will prohibit it from seeing the content of the message. So it knows that it received a
message but it doesn't know what's inside. Then it is free to, this is important for, it would be
inconvenient if when you received a message your label was forced by the browser to be raised
immediately because you just suddenly would find you couldn't talk to the world anymore. So
instead we let you have the message labeled but you can't read it before the browser will let
you read the content. What will happen is you will need to choose to raise your label which will
mean you'll lose the ability to communicate with other origins than the origin of the label
question.
>>: And that communication codes anything, gets posts, puts>> Brad Karp: Anything. Yes.
>>: But the presence of a label or the presence of a message, I should say, is a channel source as
well.
>> Brad Karp: The presence of a message is a channel. We don't even let you inspect the label
until you have raised your label accordingly.
>>: [inaudible] number of messages [inaudible].
>> Brad Karp: Yes you could. Absolutely right. It's a covert channel.
>>: So would I be able to use this to do the stock picking example where I’m mint.com, I go
access chase.com, I get the list of stocks that you have, and then I want to use some other
third-party service to go pull down stock information for each one of those?
>> Brad Karp: Yes. It will work.
<<: Okay. And you'll tell us how?
>> Brad Karp: Yes. The answer is partly privilege separation which I'm not going to get into that
much in this talk unfortunately. To conclude my example, finally the password checker can
reply with weak. It did its work, it was confined, it could not leak the password to sketchy.ru,
and then it returns its result back to Chase. So the sort of summary of the design sketch is that
origins are a natural way to specify labels for the web. You can leverage the contexts that are
already there as security boundaries and origins can be used to express privileges. And this has
to do with declassification, and for time reasons I'm not going to go into detail on
declassification in the talk. Basically this is how we handle things like a jQuery. You need
declassification. It turns out to handle things like jQuery.
>>: [inaudible] host?
>> Brad Karp: No. Incorrect.
>>: Because let's say you're using .text in jQuery, you're relying on jQuery to make sure that a
string doesn't contain any data [inaudible] HTML. jQuery is part of your trusted computing
base.
>> Brad Karp: So let me show you my slide on jQuery since we are going to go there it appears,
and I'm then I’m really going to need to continue with my talk or I won't complete my talk. So
I'm not going to walk you through absolutely all of this. The high-level of this is you know how
privilege separation works in open SSH, right? Great. So what we're going to do is we're going
to have a site a.com that wants to use jQuery. What it’s going to do is it's going to drop its
privilege and not have the privilege to declassify label a.com and it's going to set its label to be
a unique label so that it’s not allowed to talk to any network anywhere. No one on the
Internet.
What we're going to do is have a separate compartment that's where the trusted code base is.
This is not where jQuery is. jQuery is going to be executing in the low privilege compartment
just like in open SSH. The trusted code, untrusted code. And then what we're going to have is,
basically the trusted code is going to download jQuery and inject it into the DOM of the
untrusted compartment, and then after that all communication that the page with the possibly
malicious jQuery wants to make to the outside world has to be mediated by the trusted
compartment because there's no communication allowed to the Internet by force of the label.
So how does the .text thing break through this?
>>: Because when I'm using .text what I’m doing is I'm telling jQuery this is something that
could have dangerous, this is a string that could have dangerous stuff in it. I want you to HTML
encode it so that it's safe to put in the webpage. So I am using jQuery as part of my TCB to say
take this string from something that's not safe to put in HTML into something that is safe to put
in HTML.
>> Brad Karp: Okay. But the only place jQuery can>>: [inaudible] HTML tag which is a function that's supposed to let me put the dangerous stuff>> Brad Karp: But jQuery is going to inject this potentially malicious HTML into its own frame,
right?
>>: So the entire page is a different frame?
>> Brad Karp: Sorry. I think what you just said is .text is sanitizing, right?
>>: Right.
>> Brad Karp: So there could be a malicious sanitizer is what you're postulating that does not
properly sanitize?
>>: Correct.
>> Brad Karp: Excellent. So that's running here in this low privilege compartment. So now
what can it do? It can inject more content inside of this compartment, right?
>>: So the whole, but that's where the whole webpage is, is it not? Using jQuery?
>> Brad Karp: Yes, but the page is confined. It’s not allowed to talk to the Internet.
>>: Is anyone allowed to talk to the Internet? Is there any [inaudible] of jQuery, can anyone
get, even if that thing on the left is Sandbox, if it’s a pipe it then allows sort of the stuff that
Sandbox to get to anywhere else in the network, then I think what Stuart is saying is that if the
content on left is Sandbox, fine, it itself can't do anything [inaudible].
>> Brad Karp: What it can it do is, the only thing it will be able to do is go through the trusted
compartment and send messages to the trusted compartment.
<<: At the moment you open up the possibility of an [inaudible] tag this is exactly what's going
to happen. It will just follow the pipe.
>>: That's right.
>>: That's Stuart’s point.
>> Brad Karp: Sorry. But you can put whatever code you want in the trusted compartment to
mitigate.
>>: The point is that if you have some access that’s also malicious in a position on the left it can
trigger undesirable or unexpected what have you messages to the compartment overwrite.
>> Brad Karp: Yes. That's absolutely correct. Just like in open SSH when you have a monitor
process somebody can own the untrusted compartment and sent whatever RPCs they would
like over IPC to the monitor, but yet we don't seem to think that open SSH privilege separation
is useless. What you do is you>>: It's a very thin connect there. You've got a very thin, well-defined set of>> Brad Karp: Why could I not have a thin, well-defined thing here for the serialized
communication between that context and this context since I designed what this code is?
>>: Because the level of skill for somebody working within the code of open SSL is probably
different from that working on web applications.
>> Brad Karp: Okay. I understand the argument that you're making, but that is not an
impossibility argument. That is a skill level argument.
>>: Just observation.
>> Brad Karp: Right. I agree. So, yes. You could craft malicious messages and send them here.
I would say that that is better than being able to send whatever you want directly to the
Internet because there is code that a potentially smart person could have written and had
audited that it's going to inspect what those messages are, and on some level privilege
separation is one of the only things we have in our arsenal against compromise of code in
compartments and systems. I'd be happy to continue this conversation off-line.
Back to the talk. So I'll just breeze through this since I think you all completely understood how
the system worked already from the questions that you've been asking. We can use the
primitives I've described to implement Mint as a third-party mashup. Chase uses Post Message,
labeled Post Message to send, sorry. Mint.com can read labeled data from Chase’s context and
it can read labeled data from HSBC, however in order to get actually see the data in the
messages it needs to raise its label to chase.com first which would mean it could not talk to
hsbc.com any longer. It would then raise its label to add the conjunction of hsbc.com and
would no longer be able to talk to chase.com or anyone else at that point, and then it can make
you pretty graphs of how you're spending your money. So this means that you could now
implement this mashup in the browser with privacy without giving your login credentials to the
operator of mint.com.
Example too that I used a motivator at the beginning of the talk is the third-party password
strength checker. I already showed you what that looked like actually. I should you labeled
communication with sketchy.ru. I actually have a demo of a Chromium browser running the
password strength structure checker example, and I'm going to skip it because you’ve all had
such great questions so far and it’s not much to look at really.
So we built it. We built implementations both for Firefox and Chromium. We made no changes
whatsoever to the JavaScript engines. The implementations for Gecko and Blink were about
4000 lines of C Plus Plus each. Implementing a label system takes a little bit of work. We've
released the Firefox implementation open source. They’re also ready to run binaries that are
there. You can give it a try at cowl.ws.
We tried very hard to emphasize deployability in our design. So I'm just going to keep
repeating myself. There have been no changes to the JavaScript engine. In our discussions with
that the V8 team at Google it became clear to us that at least at Google, to get mandatory
access control in the browser, it was not going to happen in V8. So it's just really three new
JavaScript primitives so we think it ought to be fairly familiar because it uses origins to express
policies. It’s fast. In our performance evaluation, which the details of are in the paper, the
worst page load overhead we experienced using a case that we thought was pretty punishing
was just 16 milliseconds for increased page load time. Why is it fast? Why is it this fast? Well,
because when you're in the inner loop of executing the JavaScript code we didn't touch the
JavaScript engine. So if you have got some hairy script that's doing a lot of compute it runs at
full speed and it's only when you cross contexts that our code to do label checks gets invoked.
And it's backward compatible with legacy pages. We only start using confinement mode when
you encounter a COWL primitive in the page.
So you've already brought up several of these things already. There are a few things worth
discussing that are interesting. One of them is covert channels. What COWL does is it closes
the gaping overt channels that the SOP and discretionary access control leave in some cases.
So the stock browser, as you’ve pointed out, is rife with covert channels. COWL doesn't add
covert channels but it doesn't close them either. So this means malicious code could covertly
leak data through covert or side channels. COWL does enforce MAC in addition to the existing
DAC however. So if you had some application where you really felt like this was military grade
and you were worried about covert channels you could still deny with DAC in that application.
We don't break the things you might like about DAC if you want them for an application, for
one application.
One point you could make is that nobody knows what code mint.com is running on their
servers or what quality it is or how vulnerable it is. One consequence, there's lots of things you
guys seem not to like about running it in the browser from crappy 3G connections to all kinds of
other things, one thing good thing might be that if you forced people to use covert channels in
JavaScript they'd actually have to put the code out there for the bad things that they were
doing which is actually a little bit more like Stuart's argument before that because so many
people are using the code and everybody can see it you might find out that there's something
nasty in there.
>>: I want to find the good covert channels so I can put them in my code.
>>: But is there demand for that? Like I could go build secure mint.com today where I do as
much as I possibly can in JavaScript and I [inaudible] the users hey, I'm not using third-party
JavaScript, you can go look at my JavaScript code, it’s there, but yet your mint.com today has so
many users.
>> Brad Karp: Right. So I'll talk about this in just a couple of slides. It’s the very last point I
want to make. Another thing is that for the jQuery example which was more complicated than
the other ones you would actually only need, you can't just for something like jQuery label and
run the legacy code. You would actually need to compartmentalize into multiple contexts that
have different privileges and different labels and that requires thought or, to put it the way you
did, maybe the average web developer would find this a little bit daunting. There's some
modes of use that we think are fairly simple; there are other modes of use that are not as
simple.
Almost done here. So for discussion who should have the last word on policy in the browser?
Is it the user or is it the site operator? So, as I already said, the COWL enforces DAC alongside
MAC. So Chase still might or might not set the CORS header letting Mint look at Chase’s data.
Given what bank IT departments are like they probably wouldn't set the CORS header allowing
it. So in our implementation, as I’ve described it so far, that means we still can't do the third
party mashup because we are upholding the DAC alongside the MAC.
Our view is that it's the user’s data so the user’s decisions should be uppermost not the site
operators. If you want functionality with your data you should be able to have that
functionality. So what COWL, in our current implementation lets users do, is lets users, not in
the CORS’ syntax, but let users specify what are effectively CORS rules that enable cross origin
sharing. So, for example, a user could configure the browser to say no, Mint can read Chase’s
data and what COWL will do is force all of that communication to be labeled to make sure that
Mint’s scripts are confined.
Now coming back to the question, come on, is malicious JavaScript really, yeah.
>>: I was curious whether this COWL introduces any problems for debugging. An example
[inaudible] if you want to debug that thing you probably want to send some data back to
mint.com that according to COWL should not>> Brad Karp: Sure. So after the label gets raised it would be very, very hard to send data back
to mint.com.
>>: So what's the debugging story? How does mint.com debug their code on the [inaudible]? I
mean something happens>> Brad Karp: In real deployments with real users.
>>: If something happens and users complain you need to start [inaudible] see what the heck is
going on.
>> Brad Karp: So that is an excellent question and I don't have a very satisfactory answer to it
right now. It could be that this sort of crash dump kind of feedback is just at odds with privacy
to some extent or that we need clever new technical means. So for binaries running on the
client side if the user really cares about privacy they say don't send back, so same thing.
Okay. So why are we really wasting our time with malicious JavaScript? Come on. So attackers
are so successful with phishing already and installing malware on browsers just because users
click okay and run binaries, so isn't this just another computer security researcher going after a
problem that nobody has? Well, jQuery was hacked on September 18 and September 24. It's
used by a lot of very popular websites. Now as far as anybody knows there wasn't any
adulteration of the jQuery library when these hacks happened. There was other defacing that
happened but not of the library. There easily could have been, and it's obviously a very
attractive target because so many people source it from jQuery.org and jQuery CDN.
Here's another one that's more interesting that is my current favorite of the moment. So how
many of you have heard of the Baidu incident? All of you I hope. So just to review for a
moment, in the Baidu attack what happened is Baidu was hosting analytics JavaScript and lots
of people outside of China sites, outside of China and inside of China, were using those analytics
scripts, including them in their page and it appears, at least from Vern Paxson and Nick Weaver
and all those people's report analyzing the Baidu attack that was going on with the Great
Firewall, the same infrastructure that inspects network traffic at the periphery of China, they
found another application for the infrastructure which is instead of seeing if there's a request
for banned content and sending in a reset or a bogus DNS response you could also have a new
application which the authors of this report I mentioned called Great Canyon which is if there's
something that comes in from the global Internet through the same chokepoint and there's a
some criterium that is this a Baidu analytics script that's being requested, then just respond
immediately with a malicious script.
So in the Baidu attack what they used this for was to DDoS GitHub because it has a software
project on it to circumvent the Great Firewall of China. Ha, ha, ha. So the good news is it was
easy to spot the Baidu DDoS because DDoS they’re kind of noticeable when they happen. But it
appears that we now have a nation that has an infrastructure in place that it was willing to use
at least once to send malicious JavaScript to people. It happened to be for DDoS in this case but
it could've been for something else. It could have been to steal secrets from web application
users, not your password from mint.com probably, but there's all kinds of interesting data in
web applications these days.
>>: Was this malicious JavaScript colligated in something else?
>> Brad Karp: People were including Baidu analytics scripts. They used the Great Firewall to
see the request and just reply with a malicious script that was apparently>>: [inaudible]?
>> Brad Karp: Yes. The requests were going to Baidu, in fact.
>>: If it was an American website the request goes to China for-
>> Brad Karp: For the analytics script, yeah. And then the browser user could be anywhere of
course. Of course also TLS you could say well, this is because you’re stupid to include scripts
using HTTP and not HTTPS. TLS is not historically the most convincing defense against state
actors either. There's a lot of [indiscernible] certificates that your browser, a lot of CAs that
your browser trusts. There have been instances of certificates of being compromised.
So to wrap up, discretionary access control is what browsers use today, and in many situations
it can force a choice between privacy and functionality. Users, at least if you believe Mint’s
users, choose functionality rather than privacy. Modern web applications will need to have
untrusted code to compute over sensitive data if people keep building them the way they do
now.
So what I described to you is a system called COWL which was in OSDI 2014 and we think it's a
deployable confinement system for JavaScript. It introduces little performance cost and
achieves both privacy and flexibility. You can check out our open source release and we
actually are now chartered at the W3C for COWL. They're starting to look at standardizing
COWL for the browser architecture as standardized. And I'd be happy to take questions.
>>: I want to follow up on your previous slide you said about state actors. This whole
mechanism relies on DNS origins to begin with. It’s so fundamentally baked into everything
that you talked about that at that point that if your attacker is strong enough we are done. If
the whole mechanism relies on you just have to make sure it goes to the same DNS, how
broken is that?
>> Brad Karp: So>>: In some sense if your threat model is China we should stop. We should go back to square
zero. That’s I guess my whole argument. TLS here I think it’s a little unfair to say that it's not
convincing [inaudible] against these actors. I think the same origin policy is not a convincing
defense against the actors.
>> Brad Karp: I want to narrow down to very specific attack because the attack>>: The cost of mounting attacks on the DNS infrastructure is so low.
>> Brad Karp: And what’s this specific DNS-based attack that you're interested in?
>>: I don’t know. I'm sure that>> Brad Karp: Sorry. You’re going to have to come up with one.
>>: Re-directional attacks, for example.
>> Brad Karp: Okay. So, like for example, you're going to cause me not to go to chase.com or
I’m think I'm going to chase.com but I'm going to download content from some other party and
you're going to be able to convince me that the TLS is valid.
>>: Or yeah, like I get the jQuery from sketchy.ru. DNS makes me get sketchy.ru’s JavaScript
and the same origin policy doesn't know about that. It just knows that yes>> Brad Karp: So what you're saying is that once TLS doesn't work nothing works anymore
basically.
>>: Or in general if you have a system that binds security tokens to names where forging names
is fairly easy for China then what are people going to do? We can't stop that.
>> Brad Karp: I see. Maybe this is not the best example.
>>: [inaudible].
>>: It’s not your fault.
>> Brad Karp: It's my fault for choosing the example.
>>: Just in general I think this is a big problem for web security in general because the same
origin policy is based on these easily [inaudible] origin names so as a result it becomes very
careful to say like, and this is like a problem with all the anticensorship stuff and so on and so
forth on the web because they're saying if I trust this comes from this origin but if that name
becomes [inaudible].
>>: Exactly.
>>: I wanted to ask you about strong time enforcement mechanisms. You didn't really talk
about those. So [inaudible] and the different [inaudible] between the two. Maybe you can>> Brad Karp: Okay.
>>: Like where do you fit in your thinking?
>> Brad Karp: So if I remember correctly, Caja a subset of JavaScript. Is that correct?
>>: You’re rewriting for the subset; you’re right. That’s kind of the trade-off.
>> Brad Karp: I see. But it works for fully general ECMA, whatever.
>>: -Ish.
>> Brad Karp: I'm just trying to get, so my understanding from the JavaScript nerds I work with
because I'm not a core JavaScript nerd, I'm more a system security person, is that Caja is not
fully general to JavaScript. Maybe that's not correct.
>>: I mean the overhead is [inaudible] and to my mind that would [inaudible].
>> Brad Karp: Okay. So if Caja is fully general then I think the performance point would be the
significant difference. To be honest, I personally have not looked at Caja very, very carefully.
I've looked at JSFlow, looked at BFlow, so I've looked at other IFC-based systems in the
browsers carefully. Sorry?
>>: What about Conscript?
>> Brad Karp: Conscript. I don't know that one. Where's that from?
>>: I wrote a paper.
>> Brad Karp: I'd be delighted to look at it.
>>: Legit script.
>>: One of our favorite students here. Oakland 2012.
>> Brad Karp: 2012? I'll take a look. I mean, what we talk about in the system design that I
didn't get into in the talk is that there are these design criteria that we had which were that we
wanted hierarchical confinement so that you could have libraries that didn't trust libraries that
didn't trust libraries potentially. So that's one aspect of the system that we did not see
elsewhere. BFlow, for example, does not have that property. The trust zones in BFlow mean
that you can't do third-party mashups either, but yeah.
>>: So I don't know of many privilege separated apps and I find it interesting that the one that
does exist is written where the trusted part and the untrusted part are written by the same
people who simply didn't trust themselves to write everything securely enough. There's an
incentive problem in that if you're writing your stuff not to get any information out you're
getting less out of it and so how do you envision this ecosystem working?
>> Brad Karp: So I guess what I'm trying to figure out is the implication of the start of your
question was because open SSH, the privileged and unprivileged compartments, the code is
written by the same person you're implying that in our system the privileged and unprivilaged
are written by different people. Is that correct?
>>: Well, one’s going to contain code that’s written, part of both is written by the trusted and
untrusted.
>> Brad Karp: Okay. So hang on.
>>: The part that's written by the untrusted has to be written so that it works in this context,
right? You can't plug say a system that needs to send the password to the server into
something that's going to confine it.
>> Brad Karp: Well, people can always choose not to use libraries that are not, it is the choice
of a developer. If they have a choice between a library that offers some security properties and
one that does not that is a choice that the developer makes. They might make bad choices.
>>: But that wasn't my point. My point was someone has to have the incentive to develop the
analytics library that doesn't actually send stuff to the server. In the desktop we haven't seen it
a lot of people go out and write privilege separation because it's a very specialized context
where you have to write not trust part of your code and you're willing to make things a lot
more complicated.
>> Brad Karp: So just to be clear, I talked about four use cases. Only one of them requires
privilege separation and that's the jQuery case where you include a library in a page and script
tag that has direct access to the DOM. It's not privilege separation in the conventional sense
for the other use cases.
>>: So for the mint.com you have to have, who is incentivized to change the way mint.com
works, to create one that is different? So how is that going to take place?
>> Brad Karp: So presumably there could be a company or an open source a developer who felt
that there was demand from users to not give their login credentials to banks and they would
be motivated>>: I think credentials are a red herring.
>> Brad Karp: They’re not a red herring.
>>: They are a red herring because what's private is the information in the account. If>> Brad Karp: Fair enough. So login credentials and the information in the account. Fine. Even
better. Yes. So the information in the account they don't want to have a third-party know the
information in their account. So a developer could just decide that there's a market for this
that some users might prefer to use an application that does not to share the contents of their
bank statements and then they would write an application just like when what was the market
for Mint saying oh, I bet people wanted to be able to look at this information in an integrated
way? Now you can say that you think that no users care.
>>: So the user is trusting, so the party they're testing to write the code not to reveal the
information in that case is the code that gets access to the information?
>> Brad Karp: No, because the browser confines Mint’s code. We wrote the browser. They're
trusting us, not the people who wrote Mint.
>>: Someone has to write the part that takes in the password and then doesn't reveal any
information.
>> Brad Karp: No. So you would log into Chase the normal way in Chase’s frame and then
there would be a cookie in your browser just like there always is and then we would allow the
cross origin requests from Mint but Mint is confined by our system. You did not to type your
password for Chase into Mint ever and it does not have access to that password.
>>: Again, the password is the>> Brad Karp: You used the word password so I'm replying, you just said it has to get the
password from somewhere, did you not? I was replying to that narrow point. So Mint>>: I understood that much, but then you're saying that the code, we'll call it Mint 2.0. Mint 2.0
rates this, it then can go and do any requests for chase.com and get it back because it’s>>: I think the point is that the user can inspect the code or the page and see that on top>> Brad Karp: No.
>>: [inaudible].
>> Brad Karp: Right. That’s the point.
>>: But the question is [inaudible]?
>>: [inaudible] password, right? The user is typing in the password into a text box.
>> Brad Karp: That’s Chase.
>>: But it could be on my mint.com.
>> Brad Karp: What?
>>: The user already knows if they look at the source for that page it says oh, this box actually
is in the frame from chase.com.
>> Brad Karp: Is this a usability argument you're making?
>>: I don't understand who’s providing the API at chase.com. When it's scripting there’s an API
there but presumably someone at chase.com has to provide an API.
>> Brad Karp: Chase.com just sees that it's getting normal requests for downloading data to a
browser because you can send the cross origin request.
>>: So this is an XML HTTP request?
>> Brad Karp: Yes. Sent by Mint.
>>: Sent by Mint? So first you have to [inaudible], the user has to then go log into the>> Brad Karp: If they’re previously logged in, yeah.
>>: That actually is [inaudible]. Right now I just go to Mint. I type in one username and
password. Everything is in the back of the server. [inaudible].
>> Brad Karp: It’s poetry in motion.
>>: Exactly.
>>: Otherwise I wouldn’t if I have to log into six different sites. Mint [inaudible] user option. I
don't know whether to trust it.
>> Brad Karp: Do you ever log into your actual bank?
>>: What?
>> Brad Karp: Do you ever log into your bank? Or you only like into Mint?
>>: No, I do both.
>> Brad Karp: So you're already logging in.
>>: So Mint today, I don't know how secure [inaudible] option but then do not store your
password. You have to basically go and type in whatever number of bank accounts and
[inaudible] accounts you have. You [inaudible] type in every password separately each time
you use Mint and from what I've heard just based on [inaudible], right? And so>> Brad Karp: And so we are offering something easier than that.
>>: But you still would have to type all 16 password each time, no?
>> Brad Karp: No.
>>: This is a security question. It’s like do you see your image and stuff like that. So even if it's
cash>> Brad Karp: So you don’t have a live session at the moment.
>>: [inaudible] context of that. [inaudible]. So there’s this constant server site presence.
>> Brad Karp: I see. So yes it's true. If Chase’s server says that you don't have a fresh session
even if you have a cookie that’s valid then there’ll be some steps.
>>: I have a question about your argument about the users should be in charge of their data
and [inaudible] policies. So if that's the model then the next thing I would think about is if I’m
mint.com or [inaudible] or sketchy.ru just kind of basically say pop up a window that says sorry,
if you really want to get access to your craft you have to press this declassifying button because
otherwise it's not working properly for you. It's shown that a lot of users would click that.
>> Brad Karp: They just click okay. Users love to click okay.
>>: Why is that model the right model [inaudible]? If users are in charge>> Brad Karp: So users can make mistakes. In our system what we are doing is letting users
whitelist but then enforcing confinement on the code that gets the sensitive data.
>>: I see. So users are partial>> Brad Karp: There's no button that lets you turn off mandatory access control when you click
okay in our system. So if you're worried about covert channels then maybe yeah.
>>: Covert channels [inaudible]. So users can only actually make things more restrictive but not
less restrictive.
>> Brad Karp: No. They make things less restrictive in the following sense: they turn off the
discretionary access control on Chase to let Chase’s data be seen by the script from mint.com.
But, in our browser, make sure that the code for mint.com is confined. And there's no way the
user can turn that off.
>>: But if you the user did this in mint.com without telling mint.com wouldn’t mint.com start to
get really confused? It's getting this response to a message that’s got this label on it, the code
doesn't understand about labels, it wasn't expecting to be confined.
>> Brad Karp: No. Just a moment. So your question is when Mint sends a message to Chase is
there a label on the message from Mint?
>>: No. In this other scenario the user says I'm not going to give my password to Mint but I'm
just going to go to COWL and say just let Mint send things to Chase and it will use MAC to
confine it. But in this scenario wouldn’t Mint send something to Chase, Chase would say yeah,
here's the data but it’s okay until you play this game where you lower your privilege in order to
read>> Brad Karp: You raise your label.
>>: Raise your label. Mint.com's code isn't going to know what to do with that. If the user says,
if mint.com didn't change its code to deal with these labeled messages>> Brad Karp: Mint is written its application to deal with labeled messages. That is on the
system. They know about COWL when they write Mint to>>: I thought you had a new scenario where the user says oh, even if the code didn’t decide to
use COWL I can make it use COWL.
>> Brad Karp: No, no, no.
>>: This is Mint 2.0.
>> Brad Karp: Right. It's what that banks, it’s disabling the discretionary access control of the
banks. The banks can be fully legacy or maybe not if you're worried about the live session
problem.
>>: Okay. I misunderstood. But usability, like how do we assess the usability of this in a more>> Brad Karp: Scientific way?
>>: Well, let’s not even go that far. So here's [inaudible] back and forth the last couple of
months. And they say that they've been monitoring scams to see how from CSP is getting
queues. And outside of extension model which works in Chrome and Firefox in almost the
same way and CSP is used very well [inaudible] everything is great it's actually not being used
almost at all. So then the banks, a whole number of questions one of which is well, is it because
there are not enough good scenarios to use it to them or is it because the usability is not
entirely there? The developer as I was pointing out earlier, is not sophisticated enough. It just
doesn't come together. Because it’s one thing to propose a mechanism, another thing to get it
deployed>> Brad Karp: Absolutely correct. I don't disagree.
>>: How would we even go about assessing the usability of this?
>> Brad Karp: So by releasing it as open source and talking to web developers and trying>>: [inaudible]?
>> Brad Karp: jQuery, actually the privilege separated jQuery is the most complicated of them.
>>: [inaudible].
>> Brad Karp: Yeah. We’ve got it. All four of those things we have running implementations.
>>: [inaudible].
>> Brad Karp: No.
>>: We are not third-floor Marxists. We don't go around with user studies and bowls of candy.
>>: There is something there in terms of the level of complexity [inaudible] expense and the
level of complexity one brings. Now let's say this exclusively about your proposal, saying this
about a whole number proposals.
>> Brad Karp: A whole number of simpler proposals is what you're saying.
>>: Simpler, more complex, depends on your point of view. But I think there is a certain degree
of mismatch because the same origin policy can hate it or not hate it as much, but it's kind of
like one of those things you grow up with as a developer.
>> Brad Karp: There's plenty of people who hate things they grow up with, but yeah.
>>: And it seems like there's a bit of cliff kind of thing after that. I mean not like, so it doesn't,
adoption is difficult.
>>: You're assuming that developers understand the same origin policy?
>>: I’m not assuming anything. I’m just saying>> Brad Karp: They understand when it makes the code not work. They keep trying random
things until it does work.
>>: And that's [inaudible], and I’m not sure there is a debugging sort of start approach to your
proposal, for instance, work the same way. And again, it's not the perfect outcome one gets
from this approach. It’s something. [inaudible], right? So there was kind of a thing for
[inaudible] you get a little bit of functionality, you get [inaudible] and that’s the way it would
go. Now, of course, you have things that are infinitely more complex but the question is well,
can we use this?
>> Brad Karp: I think it's a good question. I do think that if you look at the example on that the
website, not that you would take the time necessarily, but if you did you would see that the
password strength checker is actually not that complicated at all. Like the source is quite
simple. So we spent a bunch of time talking about the privilege separated jQuery one. That's
the hairy one. A lot of the use cases, just a second, for third party libraries that have a narrow
well-defined API that's the sweet spot for this definitely.
>>: Which password checker do you use?
>> Brad Karp: We wrote our own.