| 14:05 | <wanderview> | JakeA: reading Mark's CSP+SW post... it bothers me that you can't express "allow SW to connect to <host> only when servicing a request for <destination>"... it seems like we should be able to do that |
| 14:35 | <JakeA> | wanderview: Any idea why CSP is based on requests? I know it's based on responses now too, but is the request part just an optimisation? |
| 14:36 | <wanderview> | JakeA: I'm no expert in CSP... but it seems you need some way to say what the request is for in order to pick the right CSP policy directive |
| 14:37 | <wanderview> | JakeA: so Request.destination is the fetch API thing for that... |
| 14:37 | <JakeA> | wanderview: but if the intent is "I only want to execute scripts from a particular origin", then it's the response that matters, not the requests |
| 14:37 | <wanderview> | in gecko we have nsIContentPolicyType would serves the same thing (and we map to destination): https://searchfox.org/mozilla-central/source/dom/base/nsIContentPolicy.idl#69 |
| 14:38 | <JakeA> | wanderview: but, to your original point, I guess we could look at preserving some of the properties like destination when doing `new Request(request)` |
| 14:38 | <JakeA> | I think that'd make it work |
| 14:38 | <wanderview> | JakeA: sure, and we should still have the check on the respondWith() for the response... but it seems the site should also be able to prevent XSS from calling out to evil.com, etc |
| 14:39 | <JakeA> | wanderview: yeah, I guess it stops data leaking out, as long as no part of CSP allows requests to evil.com |
| 14:39 | <wanderview> | JakeA: I guess it depends on if folks are ok with someone doing stuff like storing a destination=img request in Cache API and pulling it out later to make an "image" request via fetch again later |
| 14:39 | <JakeA> | But if you, say, allow images from anywhere, the game's up |
| 14:40 | <wanderview> | JakeA: yea... evil.com could just make an <img> element, stick whatever in the .src, then get an image destination request in the service worker |
| 14:40 | <wanderview> | I dunno |
| 14:42 | <wanderview> | JakeA: I guess I'll write a fetch spec issue to discuss it further |
| 14:43 | <wanderview> | thanks |
| 14:43 | <JakeA> | np! I guess we need a CSP expert to figure it out |
| 14:43 | <JakeA> | but from the fetch spec point of view I don't think it'd be that hard |
| 14:43 | <JakeA> | unless it opens up security issues |
| 14:44 | <wanderview> | JakeA: I think it should probably be done in step 14 of https://fetch.spec.whatwg.org/#dom-request |
| 14:44 | <wanderview> | it would also keep the destination consistent with mode=="navigate" or not |
| 14:47 | <annevk> | JakeA: you might appreciate https://github.com/w3c/web-platform-tests/commit/a8a88982335f854cf824f2f52a9088629b4db011 |
| 14:47 | annevk | is gonna do that for more tests |
| 14:48 | <annevk> | If you just have some JS to run in a service worker you can use // META global=!default,serviceworker |
| 14:48 | <annevk> | coupled with .any.js |
| 14:48 | <annevk> | it's so great |
| 15:38 | <JakeA> | annevk: Nice! So in this example the test will run in a worker, window, but not a shared worker or service worker? |
| 15:45 | <annevk> | JakeA: worker is all workers |
| 15:45 | <annevk> | JakeA: it follows the IDL syntax a bit |
| 15:46 | <JakeA> | annevk: I thought window + workers was the default for .any? |
| 15:47 | <annevk> | JakeA: default is window + dedicated worker |
| 15:47 | <JakeA> | Ohhhh! |
| 15:47 | <annevk> | JakeA: https://annevankesteren.nl/2018/04/wpt-any-js |
| 15:47 | <JakeA> | TIL. I might have to fix some of my tests |
| 15:48 | <JakeA> | Nice! |
| 15:55 | <annevk> | JakeA: https://github.com/w3c/web-platform-tests/pull/10442 could use another look |
| 16:06 | <JakeA> | LGTM |
| 16:48 | <bkardell> | hey shouldn't the examples in https://html.spec.whatwg.org/#usage-summary-2 contain headings? |
| 17:09 | <Domenic> | The ones which illustrate sectioning content do... |
| 17:09 | <Domenic> | Well, the article example has no heading, but that's OK given its content. |
| 18:46 | <Phrohdoh> | Does the W3C WebDriver spec specify data types for the return values from a `GetWindowRect` command? https://www.w3.org/TR/webdriver/#get-window-rect links to https://www.w3.org/TR/webdriver/#dfn-window-rect which leads to https://drafts.csswg.org/cssom-view/#dom-window-screenx which doesn't specify a valid range. In practice I get back `u64`s but |
| 18:46 | <Phrohdoh> | do not want to error with a 'non-w3' error type if a non-u64 isn't technically violating the spec. |
| 18:46 | <Phrohdoh> | If there is a better place to ask this question please direct me there! :) |
| 18:47 | <Phrohdoh> | u64 being Rust notation for an unsigned 64bit integer. |
| 18:49 | <Phrohdoh> | I could assume that these values are 32bit signed integers since that is what `SetWindowRect` uses but I'd rather have authoritative documentation. |
| 19:29 | <JKingWeb> | Phrohdoh: They would be JSON numbers. WebDriver appears to define JSON deserialization in terms of ECMA-262, so that would mean a 64-bit double-precision floating point number. |
| 20:18 | <Phrohdoh> | JKingWeb: Okay that makes sense. I may have to propose changes to a library I am consuming then. Thank you. |
| 20:21 | <JKingWeb> | I may be wrong (it wouldn't be the first time!), but an integer type would be unsuitable because the values are CSS pixels, and CSS pixels are not necessary integral. |
| 21:02 | <gsnedders> | Phrohdoh: I'd expect it to match the type of screenX in CSSOM View, which is a double |
| 21:02 | <gsnedders> | (And ultimately, as JKingWeb says, given everything goes over the wire as JSON, it'll become a double then) |