| 06:40 | annevk | goes to bed early too |
| 07:06 | <annevk> | hayato: does the change to DOM to go from scoped to composed look okay? |
| 07:09 | <hayato> | annevk: Let me take a look.. |
| 07:10 | <hayato> | annevk: LGTM-ed in https://github.com/whatwg/dom/pull/244 :) |
| 07:13 | <annevk> | ta |
| 09:09 | <smaug____> | annevk: I don't quite understand what https://github.com/w3c/webcomponents/issues/432 is about, but aren't we still mixing Nodes and other event targets since Window object is in the path |
| 09:12 | <annevk> | smaug____: the problem is only when we start with a non-node event target I think |
| 09:35 | <annevk> | hayato: https://github.com/whatwg/dom/pull/247 |
| 09:35 | <annevk> | smaug____: I tried to explain the reasoning why we can revert it in https://github.com/whatwg/dom/pull/247 |
| 09:53 | <smaug____> | has anyone reviewed PerformanceObserver API? |
| 09:55 | <annevk> | Small aspects of it |
| 09:55 | <annevk> | iirc |
| 10:05 | <jgraham> | smaug____: Want to review https://github.com/w3c/web-platform-tests/pull/2920 ? |
| 10:05 | <jgraham> | (should be v quick I think, and you made the other test changes in the gecko repo) |
| 10:38 | <Munter> | annevk: I'm trying to understand the vulnerability in content addressable caching (https://github.com/whatwg/fetch/issues/301#event-654674683). So, I can do a timing attack by measuring the response time of an asset based on it's integrity hash to check if this asset is already in the cache. First of all, timing attacks usually require multiple roundtrips, and after the first try the asset would ba cached, so the attack only gets one reliable data point. |
| 10:39 | <Munter> | And is it really a problem at all? With content addressable caching the asset could come from anywhere. It's not nessesarily possible to relate that back to a specific domain. Or am I wrong here? |
| 10:39 | <annevk> | Munter: that might be enough |
| 10:40 | <annevk> | Munter: if the content is widespread it's not necessarily possible, but if it's not it is |
| 10:43 | <annevk> | Munter: and I think you could do multiple attempts if your version ends up erroring somehow or doesn't permit itself being cached |
| 10:43 | <Munter> | But I'm not really getting a lot of information from this. It this much different that checking Element.matches(':visited') for an anchor to the same asset? |
| 10:44 | <annevk> | Munter: some browsers go out of their way to protect the :visited leak |
| 10:46 | <Munter> | annevk: So content addresable caching could potentially be used to detect users browsing habits? |
| 10:46 | <annevk> | Munter: yeah |
| 10:46 | <Munter> | :( |
| 10:55 | <annevk> | Munter: https://lists.w3.org/Archives/Public/public-webappsec/2014Oct/thread.html#msg0 has a bit of past ramblings, not all coherent |
| 11:10 | <Munter> | Thanks |
| 15:33 | <wanderview> | JakeA: ping |
| 15:34 | <JakeA> | hey! |
| 15:34 | <wanderview> | JakeA: hi! so how strongly do you feel about throwing in the fetch event handler not triggering a network error? |
| 15:34 | <wanderview> | was that a carefully planned spec detail? |
| 15:37 | <JakeA> | wanderview: I can't remember how carefully planned it was, but it feels platform consistent. If an error is thrown in a click listener, it doesn't prevent the default click action |
| 15:37 | <wanderview> | JakeA: but we do fail the sw install if the install event handler throws |
| 15:38 | <wanderview> | I guess I don't have strong feeling... just trying to figure out if I should fix gecko to not fail the network request while we figure out our long term navigation handling questions |
| 15:39 | <JakeA> | wanderview: good point. I'm leaning towards not breaking navigations that error (unless say, devtools are open), so I think it's worth fixing |
| 15:40 | <wanderview> | JakeA: ok... what about if evt.respondWith() is called and then it throws? |
| 15:40 | <JakeA> | wanderview: then it's down to whatever respondWith resolves with I think |
| 15:41 | <wanderview> | JakeA: but if the throwing code results in the respondWith() promise never resolving (maybe its IDB code or something), then you hang the network request for a long time |
| 15:42 | <wanderview> | I guess I can just make it ignore thrown exceptions in fetch event for now |
| 15:43 | <JakeA> | wanderview: my hunch is that'd be rare. respondWith seems to be the last thing called in fetch listeners |
| 15:43 | <wanderview> | well, it might do some waitUntil() background caching... but that would not break the respondWith() I guess |
| 15:45 | <wanderview> | JakeA: I'll do that... and write a spec issue since I think spec currently says to fail the network request if you respondWith() is called and the handler throws |
| 15:46 | <TabAtkins> | Munter: imo (I've discussed this with others in security), the history leak from content-hashes is minimal and ignorable. As you say, it's a *destructive* timing leak; after the first attempt (by *anyone*), it's ruined for everyone until it drops from cache. And anyone conducting a history attack pollutes the cache for any subsequent history attacks. |
| 15:46 | <JakeA> | Cheers! |
| 15:47 | <wanderview> | thanks for clarifying for me... sometimes I can't tell whats intentional or not in the spec :-) |
| 15:47 | <TabAtkins> | And a single-attempt timing attack is mostly useless anyway; timing attacks are rarely reliable in a single hit; you have to repeat the attack to minimize noise. |
| 15:52 | <halindrome> | botie, ask heycam|away to ping me about webidl and sequences |
| 15:52 | <botie> | will do |
| 15:53 | <Ms2ger> | halindrome, what's up? |
| 15:54 | <halindrome> | Ms2ger: Tab asked me to ping about expressing sdequences in WebIDL |
| 15:54 | <halindrome> | 'cause I dont know how and someone here does |
| 15:54 | <Ms2ger> | Ask away |
| 15:55 | <halindrome> | lets say I have an attribute foo. and foo is a sequence of DOMStrings... |
| 15:55 | <halindrome> | an array |
| 15:56 | <halindrome> | what is the proper WebIDL syntax for that, and will ReSpec grok it |
| 15:56 | <Ms2ger> | No |
| 15:56 | <Ms2ger> | Attributes can't be sequences |
| 15:56 | <halindrome> | yeah... read that in the WebIDL spec. |
| 15:57 | <Ms2ger> | More likely, you want https://heycam.github.io/webidl/#idl-frozen-array |
| 15:57 | <halindrome> | but.... the data structure in question works that way. I think the real answer is "dont use webidl" for this |
| 15:57 | <Ms2ger> | That's not the answer |
| 15:57 | <Ms2ger> | If you have a data structure where you have to return a new array object on every access, you should make it a method, not an attribute |
| 15:59 | <halindrome> | I appreciate that if there were any interface. This is literally a data structure. There will never be any "API" to it. At least, thats what I think. |
| 16:00 | <Ms2ger> | I don't know what that means |
| 16:00 | <halindrome> | Think JS. It's just an Object. |
| 16:01 | <halindrome> | part of a message that gets passed around between methods. also in JS. Sometimes among different systems, but if so via JSON. |
| 16:02 | <halindrome> | anywya - thansk for the FrozenArray pointer. I will see about adding FrozenArray to respec |
| 16:09 | <wanderview> | JakeA: https://github.com/slightlyoff/ServiceWorker/issues/896 |
| 16:10 | <JakeA> | ohh, good detail, cheers |
| 16:12 | <TabAtkins> | halindrome: I strongly suggest you run this stuff thru implementors. We describe everything on the platform in WebIDL. Something being passed between methods means it's a data structure that can get checked. |
| 16:13 | <TabAtkins> | At the bare minimum you can just WebIDL it as an "object" and do every operation in prose, but that's fragile and silly and you'll get things wrong. |
| 16:14 | <halindrome> | TabAtkins: thanks. |
| 16:19 | <halindrome> | also, fwiw, this is nothing I would ever envision a browser implementor putting in an api. but I digress. |
| 16:35 | Ms2ger | wonders why service workers uses [Unforgeable] so much |
| 16:38 | <Domenic> | Woah, that is bizarre |
| 16:40 | <Domenic> | Ms2ger: filed https://github.com/slightlyoff/ServiceWorker/issues/897 |
| 17:06 | <annevk> | TabAtkins: Google's security team said something else last time around |
| 17:06 | <TabAtkins> | We disagree internally. |
| 17:07 | <annevk> | TabAtkins: I see |
| 17:52 | <TabAtkins> | Domenic: How are you managing to get such weird markup in your PR messages? |
| 17:52 | <Domenic> | ? |
| 17:52 | <Domenic> | Oh |
| 17:52 | <Domenic> | I forgot to edit the commit message |
| 17:53 | <Domenic> | GitHub gets confused by <style> elements |
| 17:53 | <TabAtkins> | how bizarre |
| 19:30 | <smaug____> | any hints where tests for table.rows might be in https://github.com/w3c/web-platform-tests/tree/master/html |
| 19:31 | <smaug____> | nm, https://github.com/w3c/web-platform-tests/blob/master/html/semantics/tabular-data/the-table-element/table-rows.html |
| 19:52 | <smaug____> | jgraham: I lost the link how to run wpt tests easily |
| 19:54 | <smaug____> | hmm, but now I found another way. http://w3c-test.org/* |
| 19:57 | <Domenic> | there's some magic runner in a subdirectory there |
| 19:59 | <Domenic> | can't find it |
| 19:59 | <smaug____> | yeah, there was some web app -like runner somewhere |
| 20:41 | <jgraham> | smaug____: tools/runner/index.html |
| 20:41 | <jgraham> | smaug____: But also |mach web-platform-tests| if you just want to run ones that are in a gecko tree |
| 20:41 | <smaug____> | sure, but I was comparing different browsers |
| 20:42 | <smaug____> | and thanks |
| 20:42 | <jgraham> | Yeah, unfortunately other browsers aren't quite sophisicated enough ;) |
| 20:49 | <wanderview> | Domenic: thanks... sorry for messing those script references up |
| 20:50 | <Domenic> | wanderview: no problem. running the real web platform tests against the reference impl now so should be able to catch things :) |