Web Application Security Working Group Teleconference -- 15 Jun 2015

<trackbot> Date: 15 June 2015

<bhill2> Meeting: WebAppSec WG Teleconference, 15-Jun-2015

<jww> For the record, Emily Stark is also in the room with me here.

<dveditz> Zakim: IPcaller is me

<JonathanKingston> I'm on the phone via Skype

<francois> Mozilla.a is me

<wseltzer> [next call we'll be on webex]

<mkwst> JonathanKingston: Did you call in early?

<bhill2> zakim P0 is jonathanKingston

<JonathanKingston> mkwest: yup

<bhill2> scribenick: mkwst

bhill: Welcome!
... Welcome JonathanKingston, joining the group as an invited expert.

<JonathanKingston> Hello all, sorry

JonathanKingston: [hard to hear]

bhill: Try something other than Skype?

bhill2: mounir?

mounir: Hi.

Agenda bashing

bhill: Anything to add to the agenda today?
... No additions.

Minutes approval

<bhill2> http://www.w3.org/2011/webappsec/draft-minutes/2015-05-18-webappsec-minutes.html

bhill2: Objections?

News

bhill2: No objections.
... Berlin F2F.
... STREWS workshop. European research. Security arch. of the web. TAG wanted to discuss similar issues.
... Rigo has had difficulty securing a venue.
... Plan at the moment (won't shift by more than a day) is to have webappsec meet on 13th and 14th of July.
... Monday/Tuesday @ Mozilla Berlin office.
... TAG meeting on 15th and 16th.
... Inviting TAG on the 14th.
... Will dive in on HTTPS-related specs.
... Discuss the broader picture (all HTTPS) with the TAG on Tuesday.
... Possibly a STREWS meeting on the weekend prior.
... Talk to TAG folks if you'd like to join their meeting (limited space).

dveditz: Need to book travel. Hard to be too flexible.

<wseltzer> [let's say 13-14, and not wait on STREWS]

bhill2: Month out, can't count on STREWS.

<francois> we have monday to wednesday booked at the mozilla office, just in case

bhill2: Plan on Monday and Tuesday.

<dveditz> francois: hi! I thought you were PTO today

<dveditz> guess that was NZ monday (yesterday)

<francois> dveditz: yes, timezones ;)

bhill2: Permissions API.

The Permissions API

bhill: Editor will introduce the spec. Field questions, point out questions. Discuss moving towards next step.

mounir: Idea of the API is to have one place where developers can check permissions before using APIS.
... Many APIs don't provide permission entry point right now.
... bad UX.
... Go to google.com on the mobile, always asks for location.
... want to add value, don't know whether they have access without prompt.
... if they can't, they might change UI to ask in a reasonable way.
... A few issues in Chrome. How granular should permission descriptions be?
... "requestAndCheck" in the API?
... Add a "request and revoke call"?
... Today, it's simple for developers to mimic a request method.
... would be better for browser UI to request permissions through a request method.
... could combine permissions that way.
... app can say "I'd like to use X and Y" in one step
... had experiments in Chrome to do that.
... if permissions requested before pageload, we'd show them in one permision request
... felt@ is working on that kind of UI exploration.

bhill2: I have questions... anyone want to go first?
... In the initial enumeration of permissions, getUserMedia isn't there.

mounir: getUserMedia should be in that list. Only not added because gUM was talking about a permission status method in their own API. Didn't want to force them to move to our way.
... API at that point was really new. We could probably go back to them now to see what they'd like the API to look like.
... on GitHub there's a document describing the APIs that aren't in the API right now. Talks about getUserMedia

<mounir> https://github.com/w3c/permissions/blob/gh-pages/extensibility.md

bhill2: localStorage quota as an argument, not as per
... Worth creating a registry for the names rather than an enum?

<rbarnes> +1 to a registry

bhill2: Could update without revising the specification directly.

mounir: Simple to use the API, have a catch that says "This permission isn't supported".
... A registry adds a little bit of fingerprinting for no good use case.
... compared to "try to use it, if it fails do something else."

bhill2: API discussion point: multiple permissions at once, good for UX.
... But bundles permissions together. What about selectively declining permissions?
... Sounds all-or-nothing, which is bad for users.
... If we extend in that direction, the shape of the Promise resolution shouldn't prohibit users from granting permissions selectively.

mounir: Permission-wall in front of websites?

bhill2: Asked for 10 permissions, have to accept/deny all of them?

mounir: User-agent issue. That [no granularity] would be a terrible implementation.
... In Chrome today, you can answer each request individually.
... Even Android is moving out of that system.

dveditz: If a page wants to insist on permissions, they can. There's nothing the API can do to prevent that.
... Big wall with a single answer, then sites will expect they get everything.
... As long a sites know that they have to check everything they requested, then that will keep reasonable sites from making unreasonable assumptions.

<JonathanKingston> bhill2: There seems to be an open related issue for this - https://github.com/w3c/permissions/issues/8

mounir: Vision is pass in an array of requests, get back an array of grants/denials.

terri: Related question: is there any intention to include permission management in this?
... Seems like that's going to be necessary.

mounir: What do you mean?

terri: Any way to build things that allow users to change their permissions later on if they change their minds?
... Right now that's locked into the browser.
... Apps with no browser (just a webview), no mechanism by which permissions could be dropped.

dveditz: This API is content-facing. User managing the API wouldn't do so through the API, but some other mechainsm.

terri: Would need to be a matching API. Is that out of scope? We're going to need that for work I'm doing.

mkwst: Would dropping via the API be enough?

terri: Would need to regain as well as dropping.

mounir: Dropping is something we can add. Good citizens could revoke the permission themselves.
... One big problem is that users will say "No", but will come back to the website .. Happening with Hangouts. Some users will deny usage of the microphone.
... But they'll come back, and have no way of reverting their decision.
... API to make that easier sounds scary/annoying.

terri: Yes. That would be obnoxious. Might be better as a parallel API that isn't public-facing.

mounir: Discussed at TPAC with Microsoft.
... Browser could be smart in that situation.
... If I go to that website often, maybe the UA should ask again. "6 months ago you said no, would you like to revisit that decision?"
... Shouldn't be triggered by the content.

jww: Issues are UA design decisions. Space for exploration, but seems like a feature to leave those decisions open.

dveditz: as terri was saying, she expects browsers to do the right thing, but other non-browser things don't always give users control.
... Perhaps "SHOULD allow users to manage these permissions"?

terri: I'm at Intel, working on crosswalk, IoT teams.
... Browser isn't always an option.

dveditz: On devices like that, we have an API, but the device may choose the permission for the user.

terri: Sometimes. IoT is pretty broad. Sometimes there's an interface. Sometimes the manufacture will make the decision.
... Would be nice to be able to build apps against an API.
... Will need to do something in this space.

gmaone: Would it be a good idea to give user a chance to define permission as temporary?

mounir: I think the UA can decide. The API doesn't make any assumption about the permission being persistent.
... expected that the website checks the permission before using it.
... should be possible to make the permission temporary.

bhill: Are these changes v2 or v1?

mounir: planning to add these features to v1.
... keeping as WD, adding new permissions.

bhill2: Great, keep it open. Looking forward to future work.

Referrer Policy

<bhill2> scribenick: bhill2

jochen: summarizes the purpose of the Referrer Policy spec
... open questions: how to interact with fetch, e.g. as a service worker for an individual request, change hostname
... another issue is to differentiate between subresource loads and navigation in general

dveditz: not all those issues are in webappsec github

jochen: discussion on fetch integration is happening with fetch spec

<mkwst> bhill2: Any questions? I have a few.

dveditz: question from implementation: ability to put referrer attribute on individual elements?
... once something is in cache, can we use the cached copy?
... should we load as many times as we have different attributes?

jochen: regular implementation of the cache does not take this into account
... think we should not mandate behavior that makes performance worse
... related to interaction with preload scanner, which might trigger loads before a meta referrer header is processes
... I think the preload scanner should to a best effort, if site really cares should send referrer policy by CSP
... should not require discarding of an already loaded network response

mkwst: if a site explicitly wants different content based on referrer it should also send a "Vary: Referer" header to indicate this

bhill2: Dan, this looks like issue #2 here: https://lists.w3.org/Archives/Public/public-webappsec/2015Jun/0043.html
... issue #1 here? is it ok to modify the policy with script that sets attributes that seem to take precedence over a header/meta

mkwest, your audio is gone

<dveditz> mkwst: come back to us!

mkwst: we have stats on this in chrome, looks like 11.3% of sites use referrer policy

<mkwst> https://www.chromestatus.com/metrics/feature/popularity#SetReferrerPolicy

mkwst: around 0.1% of pages change referrer policy on the fly to a different value

<dveditz> 11% !

<mkwst> https://www.chromestatus.com/metrics/feature/popularity#ResetReferrerPolicy

mkwst: about 1% of pages that use referrer policy rely in some way on current chrome behavior
... 0.1% of page views is above the threshold where we are comfortable deprecating so we may want to revisit the CSP interaction to be less draconian

jochen: for CSP we usually say you can go to a more strict setting, but not clear what is more strict in this context
... some policies send less information in some ways, more in others (e.g. with downgrade in origin-when-crossorigin)
... would rather stay with allowing it to change on the fly

<mkwst> bhill2: Can control injection risk via CSP.

bhill2: can also use CSP script controls to mitigate risk of injected inline scripts

jochen: can also measure how referrer policy is being changed

mkwst: our numbers don't split out CSP vs. meta tag
... suspect most use meta tag
... know that google, facebook, some others do

<mkwst> bhill2: 2 related questions.

<mkwst> ... Currently link rel=noreferrer has side-effects for `window.opener` property.

<mkwst> ... Disowns `window.opener`. Should we preserve that behavior?

<mkwst> ... Should include functionality as part of the spec?

<mkwst> ... Of interest to Facebook, because of phishing and other types of attacks.

dveditz: someone was proposing a separate rel, maybe not in our group, maybe in webapps
... rel=noopener, nocontext or something similar
... don't fell comfortable changing the behavior of rel=noreferrer, because people rely on that already

jochen: also one of the signals used to decide if a new process is needed

mkwst: conflating these going forward is a recipe for confusion, rather have a separate attribute
... whether referrer policy is the right place, we should mention it
... but would be good to define a new attribute and to define it somewhere other than referrer policy spec

dveditz: not supporting conflation originally, but support continuing it, but not propagating it further

bhill2: is it worth having the ABNF support multiple tokens for future extensibility?

mkwst: we have a bug for this in CSP3 already, on a page-wide
... for referrer we want to change the syntax to allow multiple tokens to be set

jochen: meta delivery has lots of drawbacks, would rather extend other means we have like CSP than dumping more into meta referrer spec

bhill2: reporting on sandbox?

mkwst: its already there

dveditz: so this works as expected for e.g. about:blank that has content written to it, has origin of script that opened it

mkwst: some differences in chrome and firefox behavior for something other than a document, e.g. a stylesheet loading an image
... ff sends stylesheet's URL, chrome sends docuennt's

dveditz: maybe css or html people should figure how that should work

jochen: do you use referrer policy at time stylesheet was loaded or at time subresource referred to by stylesheet is loaded?

<mkwst> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24613 is the stylesheet question.

- DRAFT -

Web Application Security Working Group Teleconference

15 Jun 2015

Attendees

Contents

Agenda bashing

Minutes approval

News

The Permissions API

Referrer Policy

Summary of Action Items

Scribe.perl diagnostic output