| 08:04 | <annevk> | MikeSmith: perhaps close WebAppsWG / DOM as a thing on Bugzilla? |
| 08:26 | <annevk> | "A confirmation email has been sent to you." - lies from Twitter |
| 10:20 | <MikeSmith> | annevk: does it not have any open bugs? |
| 10:21 | <mkwst> | annevk: When you have a minute*, I've reworked most of the bits in https://w3c.github.io/webappsec-credential-management/#opaque-data. I'd appreciate feedback about the things I've certainly missed. |
| 10:22 | <mkwst> | And now I need to figure out how much work this is going to be to implement in Chrome. :/ Do you happen to know if anyone other than Firefox implements URLSearchParams? Edge, for instance? |
| 10:43 | <annevk> | MikeSmith: I meant close to new bugs |
| 10:44 | <MikeSmith> | ah OK |
| 10:44 | <annevk> | mkwst: just Firefox |
| 10:44 | <MikeSmith> | annevk: yeah can do that now |
| 10:45 | <annevk> | mkwst: I wonder now, what you created seems a lot like COWL |
| 10:46 | <mkwst> | kinda, I guess? |
| 10:47 | <annevk> | mkwst: yeah, not entirely |
| 10:47 | <mkwst> | I'd rather just not expose the data. Exposing it with an associated label would be pretty restrictive. |
| 10:49 | <annevk> | I guess the thing is that you only get the restrictions if you try to get to the data |
| 10:49 | <mkwst> | Right. So let's just not give you the data. :) |
| 10:49 | <mkwst> | The use case, I suppose, is a site that wants to munge the password data before sending it up to the server. |
| 10:49 | <annevk> | mkwst: 3.3 should mention the data gets given to service workers |
| 10:50 | <annevk> | mkwst: you also need to patch the Response interface somehow so this doesn't get leaked through .body |
| 10:50 | <mkwst> | Doesn't Response just copy the body from the request? I assumed the flag would carry over. |
| 10:53 | <mkwst> | Hrm. Regarding service workers, I was thinking about setting the skip flag. There are probably edge cases that would break (apps doing some sort of local authentication...?), but it seems generally safe. |
| 10:54 | <mkwst> | (Why is "skip-service-worker flag" referenced by `skip-service-worker` and not something like `concept-request-skip-service-worker-flag`?) |
| 10:55 | <annevk> | mkwst: Response has some custom logic at the moment since only Response handles streams |
| 10:56 | <annevk> | mkwst: (flag was a unique enough suffix to not have to bother) |
| 10:56 | <mkwst> | but, but... consistency! :) |
| 10:56 | <annevk> | mkwst: wait if you pass in an opaque FormData that flag gets set? |
| 10:56 | <annevk> | mkwst: how much magic are we introducing? |
| 10:57 | <annevk> | mkwst: I'll accept PRs that consistify |
| 10:57 | <mkwst> | Lots of magic! |
| 10:57 | <mkwst> | Like, 3 magics. |
| 10:57 | <annevk> | mkwst: though I'll note that the flags are consistent |
| 10:57 | <annevk> | mkwst: hmm |
| 10:57 | <mkwst> | https://w3c.github.io/webappsec-credential-management/#monkey-patching-fetch-2 <-- magic! |
| 10:58 | <mkwst> | same-origin request, no redirects, and skip SW. |
| 11:00 | <mkwst> | re: Response. Where does it expose the body of the request? It doesn't look like it does? |
| 11:01 | <annevk> | mkwst: I'm not sure why request has anything to do with it |
| 11:01 | <annevk> | mkwst: (new Response(opaqueData)).body |
| 11:02 | <mkwst> | Ah, I see. Synthetic response from a FormData object. Got it, thanks. |
| 11:02 | <annevk> | mkwst: you'll need to patch sendBeacon() too I think |
| 11:03 | <annevk> | mkwst: and XMLHttpRequest's send() |
| 11:03 | <annevk> | mkwst: otherwise you can just leak this cross-origin there or via the service worker... |
| 11:03 | <annevk> | mkwst: it seems like a rather fragile setup where you have to patch each place that might take these things |
| 11:04 | <mkwst> | annevk: This is why I had my own everything. |
| 11:05 | <annevk> | mkwst: perhaps a better way is to have CredentialData and let that have a pointer to a FormData and/or URLSearchParams object |
| 11:05 | <annevk> | mkwst: for the additional public fields |
| 11:06 | <annevk> | mkwst: and then make Fetch's Body deal with this new CredentialData thingie |
| 11:06 | <mkwst> | `sendBeacon()` returns a boolean; where is the data exposed? |
| 11:06 | <annevk> | mkwst: the cross-origin server? |
| 11:06 | <annevk> | mkwst: or the service worker? |
| 11:07 | <mkwst> | I see, sorry. I thought we were still talking about JavaScript access. Thanks. |
| 11:07 | <annevk> | Service worker is JavaScript :-P |
| 11:08 | <mkwst> | Regarding the "better way": I don't understand the suggestion. You're saying `[credential].toCredentialData()` is this new thing? And we pass that to `fetch()`? |
| 11:08 | <annevk> | Maybe just [credential]? |
| 11:09 | <annevk> | And give [credential] an additionalData member that can be either a FormData or URLSearchParams object |
| 11:09 | <mkwst> | How does that make any of this simpler? :) |
| 11:10 | <annevk> | 1) We don't have to make FormData or URLSearchParams special |
| 11:10 | <annevk> | 2) The special casing in Fetch with respect to same-origin and such is clearly derived from credentials rather than opaque data |
| 11:11 | <annevk> | 3) Any new API that accepts FormData and/or URLSearchParams does not have to worry |
| 11:11 | <annevk> | 4) Any existing API that accepts FormData and/or URLSearchParams does not require branching |
| 11:11 | <annevk> | (or updating) |
| 11:12 | <mkwst> | So, the developer would do something like `fetch([url], { body: [credential], ... })`? |
| 11:12 | <annevk> | Yes |
| 11:14 | <mkwst> | And they'd configure the credential somehow to produce the right body for the fetch operation? |
| 11:14 | <annevk> | mkwst: probably by assigning .additionalData to either a FormData or URLSearchParams object (which can be empty) |
| 11:14 | <annevk> | mkwst: and we'd just default to that being FormData if it's undefined |
| 11:15 | <annevk> | mkwst: and if there's clashes between the FormData/URLSearchParams and credential keys we'd probably drop those of the former |
| 11:16 | <mkwst> | Ok. I have a feeling that that's just as invasive/weird, but I'll see what spelling it out looks like. I'm certainly happy to have the functionality tied to the credential object and not the opaqueness flag. |
| 11:17 | <annevk> | mkwst: you don't think that not having to touch FormData and URLSearchParams and any of the APIs they interact with alone is worth it? |
| 11:18 | <mkwst> | I do think that's worth it. I'm just not sure I understand how it actually prevents the data from leaking, since it all boils down to a FormData/URLSearchParams under the hood. |
| 11:18 | <mkwst> | Let me walk through the steps before I argue about it, as I think I'm just misunderstanding the proposal. :) |
| 11:19 | <annevk> | mkwst: yeah, there's no FormData or URLSearchParams under the hood, they're just there for the additional fields and determining serialization |
| 11:21 | <annevk> | I feel somewhat silly for not having thought of this solution to the additional fields problem earlier |
| 11:23 | <mkwst> | Ok. I'll spell it out after lunch to see if I can make it make sense to myself. :) Thanks! |
| 13:16 | <mkwst> | annevk: Ok. I think I've wrapped my head around your suggestion. Assuming I've understood it, I like it! |
| 13:16 | <mkwst> | annevk: I'm confused a bit about how to differentiate between the places where we want the body to be available and those where we don't, however. |
| 13:17 | <mkwst> | When you have a minute*, let me know. :) |
| 13:19 | <frewsxcv> | is there any reason why the spec here doesn't just specify CharacterData instead of those three structures specifically? https://dom.spec.whatwg.org/#dom-node-nodevalue |
| 13:21 | <jungkees> | annevk: |
| 13:22 | <jungkees> | annevk: JakeA I have a question about FetchEvent.clientId |
| 13:23 | <jungkees> | annevk: JakeA for a navigation request event.clientId should be the id for the client of the source browsing context, right? |
| 13:25 | <JakeA> | jungkees: I'm happy with that, if it matches fetch's definition of client (I think it does) |
| 13:27 | <jungkees> | annevk: JakeA: I think request's client in fetch is also the environment where the request is initiated |
| 13:28 | <jungkees> | annevk: JakeA: One thing I was confused is.. when the browsing context is navigated, a new client is created which is different from the one the request was initiated.. |
| 13:29 | <JakeA> | jungkees: in fetch, or in service worker? |
| 13:30 | <jungkees> | JakeA: new client here is in Navigate algorithm.. when a new Window object is created |
| 13:30 | <annevk> | mkwst: I was assuming we'd expose the body to "fetch" only and since passing a Credential sets the skip service worker flag and same-origin flag we don't really have to consider anything else |
| 13:30 | <jungkees> | JakeA: so clients.get(e.clientId) for a navigation request will not return any result |
| 13:30 | <mkwst> | annevk: Well, we expose it to fetch by adding it to `BodyInit`, right? Which means we still need to poke at Beacon. |
| 13:31 | <annevk> | frewsxcv: I would probably accept a PR that simplifies that |
| 13:31 | <JakeA> | jungkees: is new window object always created in navigate? Even with content-disposition responses? |
| 13:31 | <jungkees> | JakeA: as the client for that id should be gone by that time.. Is it an expected behavior? |
| 13:31 | <annevk> | mkwst: we could also do (BodyInit or Credential) in Fetch |
| 13:32 | <jungkees> | I don't think with content-disposition case |
| 13:32 | <annevk> | mkwst: to avoid adding it elsewhere |
| 13:32 | <mkwst> | annevk: Yeah. I was thinking that too. |
| 13:32 | <annevk> | mkwst: I like that better since it avoids XMLHttpRequest too |
| 13:32 | <mkwst> | annevk: But put that to the side for the moment. |
| 13:33 | <jungkees> | JakeA: but in general in Navigate (https://html.spec.whatwg.org/multipage/browsers.html#navigate) step 24, it create a new Window object |
| 13:33 | <mkwst> | It's not clear to me what pieces I need to define in order to ensure that `Body`'s various methods won't leak data, while at the same time allowing the Fetch mechanisms to actually submit something. |
| 13:33 | <mkwst> | That is, if I override `extract` or `consume body`, I break various things. |
| 13:35 | <JakeA> | jungkees: since the window isn't always created, I guess a client isn't always created. The clientId should reference the initiating client, or be undefined |
| 13:35 | <annevk> | mkwst: yeah, I see what you mean |
| 13:37 | <jungkees> | JakeA: yeah, I agree event.clientId should reference the *initiating client*. |
| 13:37 | <annevk> | mkwst: it seems like adding an opaque flag to request and setting/checking that would be the way to go |
| 13:38 | <jungkees> | JakeA: then in which occasion would it be undefined? when the document/window was discarded before the UA fires fetch event? |
| 13:38 | <mkwst> | annevk: Doing that in "consume body", you mean? |
| 13:38 | <mkwst> | (That is, throwing in "consume body" iff the flag is set) |
| 13:39 | <JakeA> | jungkees: if the initiator was another origin |
| 13:39 | <annevk> | mkwst: yeah, similar to the disturbed flag |
| 13:39 | <mkwst> | ok. i'll try that out. |
| 13:39 | <jungkees> | JakeA: yeah that shouldn't be exposed |
| 13:40 | <jungkees> | JakeA: so by saying "a client for a navigation request could be null" in our previous discussion meant that case basically? |
| 13:41 | <JakeA> | jungkees: yep! |
| 13:41 | <jungkees> | JakeA: alright! |
| 13:41 | <annevk> | I think for navigation the client would be pretty much always null |
| 13:41 | <annevk> | Since the client is what's being requested |
| 13:42 | <jungkees> | annevk: I don't think it is the case for FetchEvent.clientId? |
| 13:43 | <jungkees> | annevk: Shouldn't it be *initiating* client's id? |
| 13:43 | <annevk> | Define initiating? |
| 13:43 | <jungkees> | annevk: I mean request's client |
| 13:44 | <jungkees> | annevk: a fetch event abstracts a request basically |
| 13:45 | <annevk> | Hmm, I wonder if the specification is correct for all this |
| 13:45 | <annevk> | Navigation is really poorly defined |
| 13:45 | <jungkees> | annevk: the client for a fetch event being a client for a destination of the requested resource seems odd though |
| 13:46 | <jungkees> | annevk: in the current Navigate algorithm, request's client is set to the source browsing context's Window object's environment settings object always |
| 13:47 | <annevk> | Sure |
| 13:48 | <annevk> | jungkees: you want to store clientID on document btw |
| 13:49 | <annevk> | Anyway, I think it's unlikely we'll find good answers here until navigation is more flushed out |
| 13:49 | <jungkees> | annevk: I didn't look that bit yet |
| 13:51 | <jungkees> | annevk: but I see places in Handle Fetch that I should update.. basically need to move some steps that update the service worker client's state to HTML I guess |
| 13:53 | <mkwst> | annevk: When my next minute* comes around, I'd appreciate it if you could skim https://w3c.github.io/webappsec-credential-management/#monkey-patching-fetch. |
| 13:59 | <annevk> | mkwst: you also need to propagate the flag when you create a new Request object from an existing Request object |
| 14:00 | <annevk> | mkwst: and some of the stuff needs to use internal algorithms rather than set() directly, and we probably want to structured clone or equivalent FormData/URLSearchParams first as otherwise the password would still be exposed to those holding a reference |
| 14:03 | <mkwst> | annevk: Good points, all. Thanks. |
| 14:07 | <annevk> | mkwst: ah, no structured clone defined yet, so you want to do something equivalent to that |
| 14:07 | <mkwst> | Yeah. I wrote "a copy of" and will actually define things if we decide to go this route. |
| 14:10 | <mkwst> | can I write something like "Execute the initial value of `set(name, value)` on x and y"? Or do I really need to copy/paste the algorithm out of XHR>? |
| 14:15 | <annevk> | mkwst: I think it would be easier to update https://fetch.spec.whatwg.org/#concept-bodyinit-extract with something specific for credentials |
| 14:16 | <mkwst> | That's what I'm doing? |
| 14:16 | <annevk> | mkwst: "copy" the form data or object's list, mangle that with the password stuff, serialize |
| 14:16 | <mkwst> | Or you mean, don't recurse into extract again? |
| 14:16 | <annevk> | mkwst: yeah, perhaps do abstract out some bits from extract so you can reuse them |
| 14:17 | <mkwst> | It seems like that would be harder than just adjusting the FormData or URLSearchParams object. |
| 14:19 | <mkwst> | Well, maybe not. You're suggesting that I take out the internal list, operate on it, and then feed it into the appropriate encoding algorithm? |
| 14:19 | <mkwst> | I guess that would let me avoid defining structured clone on those objects. |
| 14:20 | <annevk> | mkwst: yeah |
| 14:32 | <frewsxcv> | what does this mean? https://github.com/whatwg/dom/blob/master/dom.bs#L3227 |
| 14:41 | <wanderview> | JakeA: jungkees: you guys are saying if I follow a link from searchengine.com that is not controlled, and navigate to a controlled page, the clientid will point at the cross-origin, non-controlled searchengine.com? |
| 14:42 | <wanderview> | or maybe you guys moved past that |
| 14:42 | <wanderview> | I think I agree with annevk the clientId should be null for navigate |
| 14:43 | <JakeA> | wanderview: we said it'd be undefined if the client was cross origin. Although I'm happy for always null, no strong feelings |
| 14:43 | <wanderview> | I've just been dealing with a lot of this stuff for getting console reports back to the right window for a navigation... its a major pain |
| 14:43 | <wanderview> | JakeA: undefined is fine... but it feels weird to me to point to the initiating client for a navigation |
| 14:43 | <annevk> | frewsxcv: {{Text}}? |
| 14:44 | <frewsxcv> | annevk: sorry, line above that https://github.com/whatwg/dom/blob/master/dom.bs#L3226 |
| 14:44 | <annevk> | frewsxcv: it's a bikeshed shortcut for referencing an object |
| 14:44 | <JakeA> | wanderview: why does it feel weird? (I don't disagree, just curious) |
| 14:44 | <annevk> | frewsxcv: ah, AttrExodus is basically https://github.com/whatwg/dom/issues/102 |
| 14:44 | <wanderview> | JakeA: I mean, what if the SW wants to postMessage() the client its controlling... I think it would be natural to assume that is FetchEvent.clientId |
| 14:45 | <wanderview> | but in this case it would not be... it would some other random page |
| 14:45 | <JakeA> | wanderview: that would work fine in the content-disposition case |
| 14:45 | <JakeA> | Since the previous client remains |
| 14:46 | <wanderview> | JakeA: I'm really thinking about non-controlled navigates to controlled case |
| 14:46 | <wanderview> | doesn't have to be cross-origin... ctrl-shift-reload and you have a non-controlled window |
| 14:46 | <JakeA> | But I agree it's not useful in a navigate case. Might be useful in a "open in new tab" case as the client stays around |
| 14:46 | <JakeA> | Ohh I see |
| 14:47 | <JakeA> | Yeah, this would be the one case where the request's client isn't controlled |
| 14:47 | <wanderview> | JakeA: well, it could also be across scope boundaries on same origin... from ~alice home dir to ~bob home dir |
| 14:49 | <wanderview> | JakeA: I guess it would be nice if we had some definition of FetchEvent.clientId that was consistent... "always the client that initiated even if its not-controlled"... or "the client being controlled by this service worker related to this network event" |
| 14:49 | <wanderview> | I think that latter is more likely to be what people expect |
| 14:49 | <wanderview> | but I'm a terrible judge of these things |
| 14:53 | <JakeA> | wanderview: well, I think the definition we were going for is "the client that initiated the request, unless it's cross-origin" |
| 14:53 | <JakeA> | wanderview: but I'm happy to make an exception for navigations |
| 14:54 | <wanderview> | JakeA: hmm, ok... my confusion then... I don't think we should make an exception for navigation |
| 14:55 | <JakeA> | wanderview: I'm not too bothered because I don't think client is useful for navigations |
| 14:55 | <JakeA> | wanderview: in future, we might want something like fetchEvent.getDestinationClient() that returns a promise for the client that processes the response |
| 14:56 | <JakeA> | which, in a navigation's case, would be the new client |
| 14:56 | <wanderview> | JakeA: I'm more worried about a service worker that tries to use it and doesn't distinguish between navigations and non-navigations... and gets unexpected behavior |
| 14:56 | <JakeA> | not sure what would happen in the content-disposition case though… I guess that's still a new client |
| 14:57 | <JakeA> | wanderview: I can see people expecting clientId to be referencing the *new* client for navigations |
| 14:57 | <JakeA> | but it seems too early to have that, maybe I'm wrong |
| 14:58 | <wanderview> | yea, it would be very different from a client is today I think... the window/worker/etc always exists before the Client object today AFAICT |
| 14:58 | <JakeA> | I guess we know there will be a new client, it's only <object> where it isn't deterministic |
| 14:58 | <JakeA> | wanderview: agreed |
| 14:58 | <wanderview> | JakeA: is there a client if the SW ends up rejecting the respondWith()? is the error page considered a client? |
| 14:59 | <JakeA> | wanderview: I suppose it's other-origin so no |
| 14:59 | <wanderview> | JakeA: not sure chrome considers it other-origin based on some wpt tests we saw |
| 15:00 | <wanderview> | JakeA: another condition that would be tricky... provide the Client object, but then the SW returns an opaqueredirect that goes... somewhere |
| 15:00 | <wanderview> | you could end up same-origin or cross-origin |
| 15:00 | <JakeA> | wanderview: ohhh, so if I window.open a page, get a network failure, I can get at the DOM of the error page? That seems weird |
| 15:00 | <JakeA> | wanderview: ah yes, that's a perfect reason not to expose eventual client |
| 15:00 | <wanderview> | JakeA: some of the blink wpt tests assumed the frame.contentwindow was available to top level window, yes... we don't expose frame.contentwindow if the frame is an error page in gecko |
| 15:01 | <wanderview> | maybe blink hides the contents of frame.contentwindow... I think error pages are basically unspec'd... |
| 15:01 | <wanderview> | or loosely spec'd |
| 15:02 | <JakeA> | interesting |
| 15:05 | <wanderview> | JakeA: might be interesting if we pass the initiating client in FetchEvent.clientId for a navigation... and then the SW uses it to call Client.navigate() |
| 15:06 | <JakeA> | wanderview: heh, I wonder when pages stop listening to further navigation attempts. I guess they don't until they're gone? |
| 15:07 | <wanderview> | JakeA: I suppose navigate() could throw InvalidState or something... but its a bit wonky |
| 15:08 | <wanderview> | annevk: does the spec say when a window is destroyed? |
| 15:09 | <wanderview> | I seem to recall bz telling me window destruction was basically not defined and everything leaks as far as the spec is concerned |
| 15:14 | <wanderview> | JakeA: I guess the ability to navigate something thats already navigating suggests to me maybe we shoudl just set clientId undefined for navigations |
| 15:15 | <wanderview> | to start anyway |
| 15:31 | <annevk> | wanderview: some of it is defined afaik |
| 15:32 | <annevk> | wanderview: see stuff around "discard a Document" |
| 15:36 | <wanderview> | annevk: doesn't seem to define clearly when thats invoked "User agents may discard top-level browsing contexts at any time (typically, in response to user requests, e.g. when a user force-closes a window containing one or more top-level browsing contexts). " |
| 15:37 | <wanderview> | JakeA: another problematic issue might be... with a navigation the initiating document might end up in the bfcache... if client means document, then allowing SW to postMessage a document in the bfcache seems weird to me... I guess thats impl issue, but its complexity |
| 15:38 | <JakeA> | wanderview: yeah, it seems like undefined is a good answer until we work it out |
| 15:39 | <wanderview> | thanks |
| 15:39 | <wanderview> | jungkees: ^^^ |
| 16:48 | <wanderview> | annevk: JakeA: what was the outcome for this issue at the f2f? its hard to tell from the issue text https://github.com/slightlyoff/ServiceWorker/issues/719 |
| 16:56 | <JakeA> | wanderview: it's for annevk and sicking to fight it out still |
| 16:57 | <sicking> | JakeA: no opinion from the Google sec team? |
| 16:58 | <JakeA> | sicking: I'll try and drag one of them into it |
| 16:58 | <sicking> | cool, thanks |
| 16:59 | <wanderview> | JakeA: sicking: does this pending cage match also include the same issue for Performance API? |
| 16:59 | <wanderview> | I assume so |
| 16:59 | <JakeA> | yep |
| 16:59 | <wanderview> | ok, thanks |
| 16:59 | <sicking> | i don't know what the issue is for Performance API |
| 17:00 | <wanderview> | sicking: it has the same problem where it provides information about subresources via timing markers and whatnot |
| 17:00 | <sicking> | but I think my opinion about 719 is pretty specific to stylesheets |
| 17:00 | <wanderview> | sicking: right... its performance API + stylesheets issue |
| 17:00 | <sicking> | wanderview: does it affect only stylesheets? Or other things as well? |
| 17:01 | <JakeA> | sicking: just stylesheets. The resource timing API will tell you about imports and bg images, as serviceworker does/did |
| 17:01 | <sicking> | ok, then yeah, it'll probably be the same outcome |
| 17:01 | <wanderview> | sicking: see the private message I sent you |
| 17:04 | <annevk> | JakeA: I thought that was resolved to not introduce more SOP holes |
| 17:05 | <JakeA> | annevk: that's certainly what we're doing for v1, but it's backwards compatible to change to the other thing should sicking defeat you in the battle of the century |
| 17:06 | <JakeA> | If your CSS is on a static host it can make things tougher, but I get the SOP thing so I'm not fighting it |
| 17:07 | <sicking> | JakeA: this is a crazy idea, but do you think it would be web compatible to load cross-site stylesheets without cookies? |
| 17:08 | <wanderview> | wait, we want to implement this in v1 and then maybe remove it in v2? its not really trivial to implement correctly |
| 17:08 | <annevk> | wanderview: so far nobody from the security team has actually agreed with sicking so I doubt we'd remove it in v2 |
| 17:09 | <wanderview> | annevk: sicking: I'm thoroughly confused about what I should be implementing or not |
| 17:09 | <sicking> | JakeA: unless you do something like <link rel=stylesheet crossorigin="use-credentials"> |
| 17:10 | <annevk> | wanderview: the version without the new SOP hole |
| 17:10 | <sicking> | wanderview: my opinion is certainly that you shouldn't spend time on it. But clearly Anne disagrees |
| 17:10 | <annevk> | sicking: I'm not sure why we'd want to try that, let alone couple it with this |
| 17:10 | <wanderview> | annevk: I feel this is 180 degrees from the first response I got from JakeA |
| 17:11 | <sicking> | annevk: *shrug*. we don't have to couple it |
| 17:11 | <annevk> | wanderview: see above, I recalled something different from him |
| 17:11 | <JakeA> | sicking: if that was a good answer we'd allow access to the response of any non-credentialed request |
| 17:11 | <JakeA> | but then there's the intranet & local server issue |
| 17:12 | <sicking> | JakeA: i'm not saying that it makes it 100% safe. But it makes it *a lot* less likely that the response contains sensitive data |
| 17:12 | <wanderview> | JakeA: is chrome putting in this block? and how is it implementing the corner cases I ask about here? https://github.com/slightlyoff/ServiceWorker/issues/719#issuecomment-149908726 |
| 17:13 | <sicking> | JakeA: keep in mind that we're already leaking a lot of data from text/css resources on intranet/local servers |
| 17:13 | <JakeA> | sicking: I agree, but it seems weird to do a special thing for CSS here. Personally I'm happy with exposing background img requests & @import, but I can't deny it's exposing more info than we do now |
| 17:14 | <sicking> | JakeA: i'm not saying it's a perfect solution. There definitely aren't any here. |
| 17:16 | <JakeA> | sicking: it's annevk you have to convince. I think it's safe to say that request triggered by resolved styles are already exposed through getComputedStyle, but font urls and @import are not. It's whether we care |
| 17:16 | <JakeA> | I don't particularly care… buuuuut I don't have a good argument aside from "c'moooooon" |
| 17:17 | <sicking> | JakeA: my question is just if you think it's web-compatible |
| 17:17 | <JakeA> | wanderview: those are good edge cases. I think the rule annevk wants is "if the CSSOM doesn't expose it, the SW shouldn't hear about the requests it triggers" |
| 17:18 | <JakeA> | sicking: to drop cookies from CSS requests? That sounds like a big change. I worry about font providers |
| 17:18 | <wanderview> | JakeA: does CSSOM have the same issue? can it bypass an intermediate cross-origin stylesheet and see stuff in a same-origin @import further down the tree? |
| 17:18 | <JakeA> | But I don't have any failure cases to show off-hand |
| 17:18 | <JakeA> | wanderview: I don't know :( |
| 17:19 | <annevk> | wanderview: nope |
| 17:19 | <sicking> | it can see background-image further down the tree |
| 17:19 | <JakeA> | Actually, I think you'd need to go through the cross origin CSSOM to get to the import |
| 17:19 | <sicking> | and other uris that are part of style |
| 17:19 | <JakeA> | so even if b.com's css @imports back to a.com, you won't be able to get the CSSOM for it |
| 17:21 | <sicking> | a rule like ".error { background-image: url(...)" exposes the url no matter how deep in the import chain the rule lives |
| 17:21 | <annevk> | right, that's not the interesting case |
| 17:22 | <annevk> | although even there exposing the URL directly is very different from having to recreate all possible selectors |
| 17:22 | <JakeA> | sicking: font urls and @import aren't exposed through computed styles |
| 17:22 | <sicking> | JakeA: right |
| 17:23 | <sicking> | annevk: i don't agree that it's very different |
| 17:23 | <annevk> | having to create all possible trees, really |
| 17:23 | <sicking> | try to explain to anyone what is and is not safe |
| 17:24 | <sicking> | I think the only reasonable thing you would say is "that url is exposed" |
| 17:24 | <sicking> | you don't have to enumerate all possible trees or all possible selectors |
| 17:24 | <annevk> | we still made :visited attacks harder |
| 17:24 | <sicking> | that is very different |
| 17:25 | <annevk> | Why don't you have to enumerate trees and classes, etc.? |
| 17:25 | <sicking> | that wasn't about exposing information in stylesheets |
| 17:25 | <sicking> | you don't have to enumerate *all* trees/classes |
| 17:25 | <sicking> | you just have to enumerate enough of them |
| 17:25 | <sicking> | good luck explaining which ones can or can't be enumerated |
| 17:26 | <sicking> | if i saw a rule like the above, i would definitely tell the developer that that rule could be read |
| 17:27 | <annevk> | For that example, sure |
| 17:29 | <sicking> | JakeA: so what is google implementing in this area? |
| 17:30 | <annevk> | But I think there is a difference between handing the attacker all URLs and making them work for a subset of URLs |
| 17:31 | <JakeA> | sicking: I haven't heard any objections to "fixing" this, but I haven't talked directly to the team about it |
| 17:31 | <sicking> | JakeA: ok |
| 17:31 | <sicking> | annevk: the difference is fairly small, and comes at a high cost |
| 17:32 | <wanderview> | I'm inclined not to block our release of SW on this issue |
| 17:32 | <annevk> | *shrug* |
| 17:32 | <JakeA> | wanderview: we've shipped with it, resource timing has the same issue |
| 17:32 | <sicking> | annevk: as an author, i would effectively have to assume that any rules can be guessed and not put sensitive information in URLs other than @import ones and fonts |
| 17:33 | <wanderview> | JakeA: yea, and I think we should try to define some of the details before implementing... because there is enough nuance here we could end up with incompatible implementations |
| 17:33 | <JakeA> | I'm less worried about breaking the security of the web with this, more concerned about breaking sites that come to rely on current Chrome (and soon Firefox) behaviour |
| 17:34 | <sicking> | same here |
| 17:37 | <wanderview> | JakeA: also, the spec has been changed for resource timing, but in a way which does not really address @import at all as far as I can tell |
| 17:37 | <wanderview> | doesn't address the corner cases from @import, I mean |
| 17:40 | <wanderview> | annevk: JakeA: did you guys talk about the storage API v2 stuff at all at the f2f? |
| 17:41 | <wanderview> | storage pressure events vs boxes, etc |
| 17:41 | <JakeA> | wanderview: nah, we only dealt with v1 stuff |
| 17:41 | <wanderview> | ok |
| 17:41 | <JakeA> | we'll have more fun at the next f2f with v2 stuff, which will be in the US |
| 17:41 | <wanderview> | JakeA: is there a date for it? |
| 17:42 | <JakeA> | wanderview: there's rumblings of a web components f2f… if that comes together in early December we'll try and sync with that. Otherwise it'll be mid-late Feb |
| 17:42 | <JakeA> | Then April in SF for the extensible web summit |
| 17:44 | <wanderview> | ok, thanks |
| 18:53 | <wanderview> | does anyone here have a link to that research that showed interstitials prompting to install apps reduced engagement? |
| 18:54 | <wanderview> | JakeA: I seem to recall you mentioning it before... |
| 18:56 | <wanderview> | nevermind, I finally found it: http://googlewebmastercentral.blogspot.com/2015/07/google-case-study-on-app-download-interstitials.html |
| 19:39 | <wanderview> | Domenic: has ReadableStream constructor shipped in chrome yet? |
| 19:44 | <wanderview> | I guess not... I get "Illegal constructor" in canary devtools |
| 19:45 | <wanderview> | and it still thinks ReadableByteStream is a thing |
| 19:55 | <Domenic> | Yeah still trying to land the patch but vacation plus BlinkOn plus TC39... |
| 19:59 | <annevk> | JakeA: FWIW, early December won't have any Mozillians attending most likely |
| 23:28 | <JakeA> | annevk: sorry, I meant if the plan comes together *by* December I'll sync with that, rather than organise something independent for February |