See also: IRC log
<trackbot> Date: 29 October 2015
<scribe> scribe: bhill2
deian: SOP/CSP/CORS are discretionary access control
<wseltzer> [Deian will share slides after]
deian: mashup use cases and data
sharing cases are difficult with DAC
... libraries are over-permissioned, credentials are
over-delegated and there are mashup scenarios we can't easily
build between mutually distrusting services
<annevk> (window.location.origin should be document.origin)
dveditz: what stops a context from stringifying the data and postMessaging a string with no label
deian: there should be no definition for stringifying a labeled object
dveditz: would have to be opaque?
deian: there is a definition for
how to structurally clone, which is to clone the label and then
the opaque object
... have to use a getter to open the opaque object, which
taints your context when used
... and who you can communicate with is then restricted
bhill2: what about navigating other contexts you have a handle to?
deian: you can't do that because of information flow policies
annevk: do you taint all the children?
deian: no.. mods to html5
bhill2: what about workers?
deian: only talk to workers through postMessage, so tainted
annevk: do you block push?
@@: how does this work with message ports? no concept of origins
deian: only allow sending messages when you know the origin at the other end
@@: but you can't know until too late
annevk: mostly have message ports for shared workers, apple just removed them, msft has no plans to support, and mostly never used - maybe they can go away
Mek: used to queue tasks quickly or structured clone things
deian: maybe can look and decide when receiving message, not sure where to specify that
thx wseltzer
deian: prototype was done in terms of CSP hooks
annevk: for navigation you need to hook directly into navigation to avoid traversing history
deian: maybe navigation source directive into CSP would make it a natural place to work
annevk: once you are confined you no longer have an active server connection
deian: yes, but it gets revoked once your confidentiality label changes
annevk: once you're confined, then things drop
dveditz: what happens to service worker? do you skip or drop if it's not an appropriate service worker?
annevk: might have to disable notifications, too, to avoid waking up service worker
deian: also, server-supplied labels for XHR
annevk: look at fetch since we've stopped adding features to XHR
deian: wanted to do this, but fetch made it awkward to look at response type to deal with labeled JSON
annevk: you can't extract an origin from a cowl:// URL, it is null / unique because that's not on the whitelist of schemes that have hierarchical authority
dveditz: we could add that....
some discussion w/dveditz and annevk about suborigins, not yet defined
dveditz: some way of making a suborigin look like a url would be useful
annevk: you could just compare literals
dveditz: if literals, don't make it look like an origin, maybe even reject anything with a colon
annevk: CORS just uses string literal
deian: was a reason to extract
origin, to send servers you're communicating with your context
information
... so for cross-origin requests, that is useful
dveditz: so this creates a
leakage if you've blocked referrer
... like idea of signaling, because tells server more about how
to answer a request
... but it also leaks information you may not want to leak
across origins, need to think about it and get wide review
annevk: use of commas in header may be a problem
dveditz: doesn't need to be json,
could just be WSP delimited
... what do brackets do for you? difference between AND and
OR?
deian: yes, conjunction vs.
disjunction
... header and js api has some mismatch- js api lets you
specify in any format, but representation is always canonical
ndis format
... firefox patch in the works
... also a subset we could do with a polyfill + CSP + 3rd party
server
<mkwst> bhill2: It seems to me that suborigins overlaps.
<mkwst> ... Where does this fit in relation to that spec?
<mkwst> ... Suborigins are not about confinement, they want a public label for postmessage, normal cross-origin communication.
<mkwst> ... They need to be able to live as a top-level application.
<mkwst> ... Splitting out applications that happen to be deployed on the same domain without a synthetic domain.
<mkwst> deian: Disjunction does that.
<mkwst> ... No labeled cookies, etc.
<mkwst> bhill2: Seems like an explicit goal of suborigins that you could have localstorage and cookies and etc. Looks like a regular origin label.
<mkwst> ... Could have origin-labeled access to standard platform features.
<mkwst> deian: We could probably have some sort of labeled storage?
<mkwst> bhill2: Maybe suborigins are just the privilege part of this.
<mkwst> ... Privileges you expect. Reaching into other document contexts being considered cross-origin, etc. Doesn't imply navigation.
<mkwst> ... Would like to separate these concerns.
<mkwst> deian: Labels would do confinement, suborigins could do privileges.
<mkwst> bhill2: Header is the only way to enter suborigins, doesn't change state dynamically.
<mkwst> ... Forces isolation for the page from other things on the "same" origin.
annevk: what about permissions?
mkwst: "parent" origin
permissions might cascade into suborigins, or it might be
distinct - JoelW needs to decide this
... might need to ask users more often and store it internally
- can't put any more info into URL bar, probably not putting
suborigin there
... user would be confused why "google.com" keeps asking for
permissions because the suborigin abstraction is not
exposed
<mkwst> bhill2: Do I have to ask for permission every time for new disjunction states?
<mkwst> deian: Yes.
<mkwst> annevk: Since you're sandboxed, maybe the permissions are gone?
<mkwst> bhill2: You couldn't keep that up to date unless you were continually receiving messages from someone.
<mkwst> deian: But you couldn't receive messages unless you accepted the label.
<mkwst> annevk: Sensor API? Maybe you couldn't leak information that way.
<mkwst> deian: Open question!
<JeffH> http://www.chromium.org/developers/design-documents/per-page-suborigins
<mkwst> deian: If I have an iframe, I read something from somewhere else, I get tainted. But I still might have a handle to objects in the iframe.
<mkwst> ... Need to wipe out those references somehow.
<mkwst> ... Easy to do in Firefox.
<mkwst> ... Harder in Chrome.
<mkwst> ... Can we lock this to secure contexts?
<mkwst> dveditz: Yes. That's the whole point of that spec.
<mkwst> ... Browsers are generally moving towards locking things to secure contexts.
<mkwst> ... Only makes sense to talk about tainting if you know who you are to begin with.
<mkwst> ... So should require secure contexts.
<mkwst> deian: Future directions:
<mkwst> ... (More important to get v1 hammered out)
<mkwst> ... (Should talk to Joel to see what the overlap with suborigins might be)
<mkwst> bhill2: Yes. Would be nice if these were built on the same primitives.
https://wiki.mozilla.org/Security/Contextual_Identity_Project/Containers
rbarnes: additional labels applied to contexts, local storage, etc. to prevent sharing state between e.g. two logins to Twitter with different accounts
dveditz: are these created by user or site?
rbarnes: user in current
implementation
... when you load something in a container, everything is in
that container
... effectively lightweight profiles
... in chrome each profile gets its own history, bookmarks,
etc.
... containers only are for page created state, share
user-created state
mkwst: interested in extracting
some of the features out and giving them to sites, not just to
users
... some projects in google are using chrome apps to get these
properties
dveditz: firefox apps used to have that property and now they share cookies, etc.
annevk: because you don't want to have to login to Facebook 100 times
mkwst: but you do
... a site might not want to share by default that a facebook
user is at the bank without that user's choice
... boils down to double-keying for all storage in a secure
origins context
... tor browser has proven this is doable; breaks some things -
if you opt-in, we can probably guarantee that it doesn't break
things for those who opt-in
... loaded in separate process, subframes in separate process,
separate cookie jar and all things I load use that new cookie
jar, and identity is distinct in different embedding contexts
even if same-origin
... only works in top-level contexts as a straw-man
dveditz: would this be site-wide?
mkwst: yes like hsts, with maybe
a mandatory includessubdomain-like effect and locked to the
topmost registerable domain
... like first-party only cookies. If you're embedded your
embeddor has no power over you, no ambient authority associated
with the origin in another origin's context
dvetditz: e.g. a womans' shelter might use this so embedded trackers can't know the user's been there
mkwst: private mode is different about not leaving traces locally....
rbarnes: this includes aspects of private browsing mode in terms of trackers, sharing, etc.
francois: primarily about preventing CSRF.
mkwst: primarily, but also if you
know it is isolated it can be in a separate process, renderer
can be hardened.
... might be a different way of solving some of the problems
that EPR is trying to tackle
... example use case is to build as a web application,
delivered through a browser, very sensitive things that are
by-design not meant to be connected with the open web
... say, to manage virtual machines
deian: what if the browser tells the user about this...
dveditz: then we would be triple keyed
mkwst: in my use cases I care
about there is no need to tell the user
... mozilla implementation requires user to know and decide
what is sensitive
... different properties if a site can opt in
wseltzer: how does a user do something with isolated bank?
mkwst: if isolated bank gives you
a means of logging in outside the isolated context, you can do
what you want normally
... it might choose not to interact with you in those
contexts
dveditz: firefox apps had this, chrome has this, tor browser is adding this
wseltzer: yes, but I think it is interesting and useful for the user to be able to interact with a site that declares itself this way
mkwst: interesting paper by
Charlie Reis, et al. about multiple browsers
... epr is one implementation of an idea in there, this is
another
dveditz: I like what david is trying to do with EPR but manifest seems icky
<wseltzer> http://www.collinjackson.com/research/papers/appisolation.pdf
mkwst: I suspect he will still want EPR
rbarnes: if we have a way for
sites to opt out of containers, change or refresh container,
overlaps nicely with clear site data ideas
... if all site data is containerized and you can throw it
away...
dveditz: label containers?
rbarnes: hsts like semantics with max-age would create auto-expiring state
mkwst: would not want subresources to opt you in, maybe only from the root of the registerable domain
bhill2: can you tie this to a manifested web app
mkwst: easier to do at domain level because cookies are broken
annevk: you need a cache for this to persist the state
rbarnes: having a label might let different origins 'hold hands' in their own universe
bhill2: you can use a public key like android apps
mkwst: would like to think about it with regard to syntax
deian: I'd help write it up
wseltzer: can a user opt a site into this for themselves?
rbarnes: yes, it's already doing
that, or could inject a header, or configure an origin by
name...
... tor browser already doing this
deian: aware of researchers that
can do these kinds of leaks exfiltrating data with SVG by
blurring an iframe
... would be good to have guidance for spec authors on side
channels and info leaks
... even implementations-wise, e.g. a cache is likely to result
in attacks if it is shared cross-origin
deian: maybe namespaces?
... only thing that can mint privileges is the browser
... mint a.com and give it to a.com page
... but if we had something labeled geolocation: and we knew
that only the browser could do that
... only kinds are unique or delegated privileges
dveditz: could have a colon if it had, e.g. a character illegal in scheme names to disambiguate it from scheme names, or a fixed name like cowl:, but would have to register it
annevk: need to be serialized to
go over the network
... on network you could have a disambiguator when serialized,
but object model would have different flags for origin vs.
name
<rbarnes> annevk: filed Fetch issue: https://github.com/whatwg/fetch/issues/150
origin label; suborigin label - can't be minted by page; application label - can be created by any JS; "permission" label (result of an API call, unforgable); fresh
annevk: could we start out a lot
simpler if we only had a separate instance of a service worker
that we can give some labeled object it can compute on and
return the result to its caller
... don't have to think about the interaction with as many
things as browsing contexts
... for service workers we're also considering cross-origin
cases, haven't explored that for normal workers
... thinking: a.com gives some data to b.com's service worker,
b.com can't communicate back to b.com once it opens the labeled
object
... could make the draft much simpler
deian: but today you have UI
bhill2: UI seems like most interesting case to me, provide experience to user of composite information but not leak that back to remote servers
deian: what to do when label
provided by server doesn't match what it is allowed to
provide?
... taking approach of not warning user about this
dveditz: should fail closed to
the extent we can
... what if we just drop it, call it a network error
<scribe> ... new stuff nobody is using, we can check and be strict
mkwst: if we're going to be parsing, maybe extract this out to someplace where parsing happens
annevk: order matters, COWL before cookies
mkwst: have at least two blocks parsing CSP
annevk: that's because of service
workers, but COWL is only right from the network
... can a service worker add these labels....does it do the
right thing
deian: service worker would have to abide by confinement
mkwst: would that mean you can
find where redirects go?
... if not-example.com returns labeled responses, I can read
that cross-origin?
annevk: labeled data has to be
CORS accessible
... there is a problem with confining service workers because
they are shared
... to instances of b.com sharing a service worker, then a.com
communicates with one in a way that introduces confinement, the
other tabs stop working
... if you want fetching to work offline, going to involve
service workers, and foreign fetch is coming
... so you'd have to have multiple instances of service
workers
deian: may be able to think of service worker as extending the authority of the server and may not need to confine it
annevk: sw also has access to storage and other stuff
annevk thinks that chrome doesn't have wrappers, so existing references to a node in a different document that depended on being same origin won't be broken by setting the sandboxing flag
mkwst: true today, but not forever, eventually we will implement something like membranes...
annevk: maybe we should standardize membranes then...
<wseltzer> Melinda: We presented some work on DNS API previously; we've continued work and have Firefox and Chrome extensions
<wseltzer> ... work going into TLS after 1.3
<wseltzer> [discussion of uses of DNSSEC, additional information, isolation modes, supplementing CA info]
<wseltzer> bhill2: DNSSEC as a transport for policy
<wseltzer> rbarnes: also cache priming
<wseltzer> Melinda: Paul Wouters work
<wseltzer> ... establishing authority
<wseltzer> ... OpenSSL 1.2 implementation
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/what/dveditz: what/ Succeeded: s/@@:/Mek:/ Succeeded: s/htis/this/ Found Scribe: bhill2 Inferring ScribeNick: bhill2 Present: bhill2 francois BarryLeiba dveditz wseltzer mek Melinda WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 29 Oct 2015 Guessing minutes URL: http://www.w3.org/2015/10/29-webappsec-minutes.html People with action items:[End of scribe.perl diagnostic output]