https://github.com/w3c/resource-timing/issues/70

<scribe> scribe: falken

https://github.com/w3c/resource-timing/issues/70

yoav: for no-cors css fetches, the subresource urls are exposed in resource timing and sevrice workers because they get intercepted
... there is a claim that this violates the SOP
... counter claim: this info is already readily available to attackers through getComputedStyle and seeing what the CSS does to the page
... explicitly true for background images, implicitly true for fonts and imports
... but we can't observe the font URL but we can guess them if we know what the css looks like. in all reasonable attack scenarios i'm aware of you can guess.
... enforcing that restriction would break content today for sw because it'd stop getting requests for those resources
... my opinion for Resource Timing and Service Workers the specs should respect reality and implementors are not willing to take the backward compatibility hit
... other people argue we should keep the spec as-is and impls take the hit
... interested in opinions of people in the room esp browser implementors

youenn: i would tend to try to not expose these URLs
... in SW and RT
... think we should try to go there
... if you have a SW you probably know what you're doing...

yoav: the attack scenario: I'm malicious.com. convince user to come to my site. i load css of socialmedia.com.
... infer the user gender etc from that...

youenn: if user is not logged in, i.e., if you partition cookies, you might not have this issue
... solution is to do double-keying

yoav: double-keyed cache perspective, is this an issue?

youenn: we prefer to not expose
... site might still trick the user...

EricL: same-site cookies

JakeA: are there sites that store private data in CSS? or sites that think they should do

EricL: it's not common but there are examples in the history where this happened
... ca 2011
... exposed user data in a style sheet

youenn: general principle: we want to go to cors, not no-cors here

yoav: moving the sites to cors would help....
... it will make the problem go away

JakeA: we already punish such sites due to bucketing in the cache

yoav: are you willing to break backwards compat for SW in favor of blocking certain scenarios

youenn: we want to fix the sec issue
... sw impl is pretty new anyway. some adoption... don't believe it will break the web

yoav: it will break offline scenarios for everyone using css no-cors in terms of bg images, imports, etc...

JakeA: it's difficult to explain to developers as well
... developers expect the subressources to go to sw
... getComputedStyle already exposes the info...

youenn: if redesiging from scratch...?

JakeA: then cors everywhere

youenn: we want to go there, we should try to fix

JakeA: good idea is making features like SAB available only if you go cors everywhere
... talking about protecting urls in-process.. already vulnerable
... bring up SW issue

https://github.com/w3c/ServiceWorker/issues/719

https://github.com/w3c/ServiceWorker/issues/719#issuecomment-415713603

scribe: which is exposed and which is not is hard to explain to developers...
... would rather tell them it's not

falken: would we fix getComputedStyle() also

rune: doable...

JakeA: if we do the change, wouldn't get bg image, imports, etc from sw. already exposed in getComputedStyle

youenn: still have the browser cache to fallback to

rune: blocking getComputedStyle() would break quite a bit

[discussion about breaking content]

yoav: if introducing a new thing, it'd be different. but we're talking about breaking three well-established specs/behavior.

youenn: do we have numbers

JakeA: we can get numbers

yoav: see how things that do getComputedStyle would break. implement the thing to measure

JakeA: measure the times a request that came into the service worker and got a match from the cache...

wanderview: can't capture all the cases
... numbers on how often we fire a fetch event for this would be useful

yoav: if numbers for getComputedStyle are prohibitive...

JakeA: we can't block this entirely because the styles affect geometry

wanderview: would the examples of private data leaking also be exposed by getComputedStyle

EricL: [missed it]
... is no-cors transitive?

JakeA: css is no-cors unless you specifiy otherwise...
... except fonts... maybe
... cors request made from no-cors context...

wanderview: i tried implemented the blocking in firefox...
... complications with nested imports/stylesheets...
... would not be simple to implement/spec

yhirano_: similar issue for cors. once tainted, it stays tainted

wanderview: once you redirect cross-origins in fetch it remains cross origin even if it comes back

yhirano_: there is a issue in the fetch spec
... in the Fetch API it does one thing, but the fetch algorithm it does a different thing

wanderview: that complexity is here also

<yhirano_> https://github.com/whatwg/fetch/issues/737

yoav: given that getComputedStyle exposure is here to stay...

wanderview: concerns me that microsoft has seen real instances

https://bugs.webkit.org/show_bug.cgi?id=29820

<wanderview> yhirano_: that issue is about no-cors, correct? I think cors is spec'd to always taint once it redirects cross-origin

EricL: explains the issue... the problem was browsers were treating things as css that weren't
... fixed by strict mime typing
... js can do things that have observable side effects, and js doesn't have the strict mime typing
... to what extent should we worry about css

<yhirano_> wanderview: ah right, i was confused, sorry

JakeA: any request triggered by no-cors js we send through resource timing/service worker

EricL: strange for css to be different

yoav: fixing getboundingrect problem is probably not possible

falken: is css the last such feature that makes subresource requests from no-cors context

[svg, js, css]

JakeA: webvtt... no it doesn't make requests...

wanderview: why do we intercept requests from no-cors js

JakeA: it's impossible to track that it came from that script
... we do things like stack traces, function bodies, are hidden

wanderview: impl resources could be better sent doing other things

yoav: double-keying makes most of the problem go away

cameron: i reviewed the patch that blocked the request from resource timing
... seemed like a reasonable thing to do
... although i understand that getComputedStyle/geometry is not easy to solvable
... yet don't really like the approach to give up on this because getComputedStlye/geometry is already exposed

youenn: there are cases where we shipped things, and then found better solution. wouldn't give up

wanderview: suppose we don't agree. doesn't stop a browser from taking the first step toward doing this

youenn: i wasn't aware of this issue until now. i can take the action to talk with people and get a decision

wanderview: we could gather data, to a reasonable extent.

youenn: if we do it, we'd implement it in Safari Tech Preview
... and get reports there

cameron: firefox is now blocking resource timing
... the resource timing entries just disappear

yoav: may be more useful to have a placeholder

EricL: but that comes with issues too

JakeA: can put cross origin attribute on a link tag but not an import... not sure how specd

wanderview: separately from this problem, just that web devs can't do cors requests on these is a problem

[agreement that's the main problem]

yoav: so we are done here with the AI that implementors will look into this
... timebox the decision?

youenn: we can't give a schedule for implementation, but by mid-Nov should have a decision

[end]

<heycam> RRSAgent: make minutes

<heycam> RRSAgent: make logs public

<heycam> RRSAgent: make minutes

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/victim.com/socialmedia.com/
Succeeded: s/??/EricL/
Succeeded: s/last such feature/last such feature that makes subresource requests from no-cors context/

WARNING: No "Present: ... " found!
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy
        <amy> Present+

Found Scribe: falken
Inferring ScribeNick: falken

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)