| 05:20 | <babita> | Hi annevk, I am an OPW applicant and would like to work on the project "Contribute to the HTML Standard!". Where should I start? |
| 05:40 | <annevk> | hey babita, I haven't completely read up on the application process yet, but I believe the idea is that you fix one or more bugs/issues |
| 05:40 | <annevk> | babita: the wiki page has some pointers to those that are easy to start with |
| 05:42 | <annevk> | babita: the specification itself is hosted at https://github.com/whatwg/html |
| 05:42 | <annevk> | babita: and you can build it using the scripts here: https://github.com/whatwg/html-build |
| 05:45 | <annevk> | babita: if you haven't read it yet, https://wiki.gnome.org/Outreachy#Make_a_Small_Contribution has some tips on this front from Outreachy |
| 05:46 | <annevk> | babita: back later today |
| 06:15 | <babita> | annevk: thank you so much for the pointers, will go through them now. |
| 07:15 | <annevk> | babita: cool! |
| 07:23 | annevk | updated https://wiki.mozilla.org/Outreachy/2016/December_to_March#Contribute_to_the_HTML_Standard.21 to make the initial set of steps clearer |
| 07:28 | <MikeSmith> | annevk: thanks for updating that; there we somebody else on here this weekend also asking how to get started |
| 08:20 | <annevk> | MikeSmith: yeah saw that, it happening again made me realize the instructions should probably be there |
| 09:28 | <annevk> | Domenic: you have a WindowProxy rewrite somewhere, correct? |
| 09:28 | <annevk> | Domenic: I guess for the cross-origin stuff, we want to have special instances of that object? |
| 11:43 | <annevk> | smaug____: what are the contents of a history entry? |
| 11:44 | smaug____ | tries to interpret that |
| 11:45 | <annevk> | smaug____: from reading the specification it seems it contains a "request", a "Document object", a "browsing context name", ... |
| 11:46 | <annevk> | smaug____: but it's never really made explicit or enumerated |
| 11:46 | <smaug____> | hmm, request |
| 11:46 | <annevk> | I guess it says "Each session history entry consists, at a minimum, of a URL, and each entry may in addition have a state object, a title, a Document object, form data, a scroll position, and other information associated with it." |
| 11:46 | <smaug____> | or even document object? |
| 11:47 | <smaug____> | why document object |
| 11:47 | <annevk> | But although it says URL, it seems to manipulate the request method at times so that's clearly more complicated |
| 11:47 | <smaug____> | only bfcache hentry contains document object |
| 11:47 | <annevk> | smaug____: right, it's for bfcache |
| 11:47 | <annevk> | smaug____: the Document object is optional |
| 11:48 | <smaug____> | http://mxr.mozilla.org/mozilla-central/source/docshell/shistory/nsISHEntry.idl |
| 11:49 | <smaug____> | title, formstate, scroll info, url are there |
| 11:49 | <smaug____> | it is not clear to me what "request" is about |
| 11:50 | <annevk> | smaug____: in the spec it accounts for the entry initially being requested using the GET method |
| 11:53 | <annevk> | smaug____: from that it seems we also store referrer and referrer policy, all of which would be part of request |
| 11:53 | <annevk> | smaug____: so maybe there's something to that idea |
| 11:56 | <smaug____> | ah, yes, those might be part of request in spec |
| 11:58 | <mkwst> | annevk: CSPish things are starting to come together at https://w3c.github.io/webappsec-csp/#integrations. It's nowhere near done, but probably worth your time to skim that section now so I don't continue off in directions you wouldn't like for either Fetch or HTML. |
| 11:58 | <mkwst> | annevk: I think it should take care of the things you noted last time around as being undesirable. |
| 13:10 | <annevk> | mkwst: is the CSP header recognized for all resources or only those that create global objects? |
| 13:10 | <annevk> | mkwst: if the latter, shouldn't the parsing be hooked into HTML someplace? |
| 13:14 | <mkwst> | annevk: If we want to do something like http://w3c.github.io/webappsec-csp/cookies/, we need the policy before we process `set-cookies` (which is the next step after the monkey-patch point). |
| 13:14 | <mkwst> | annevk: And if we want to do referrers, we need to do something in fetch. |
| 13:15 | <mkwst> | annevk: There are a few things like that which effect the way Fetch works, outside the context of a global object. For that reason, it seemed simplest to do the parsing in Fetch. |
| 13:37 | <annevk> | mkwst: I see |
| 13:37 | <annevk> | mkwst: did you figure out when it happens relative to service workers? |
| 13:37 | <annevk> | mkwst: it seems you decided service workers do not get to set policy |
| 13:37 | <annevk> | mkwst: whereas JakeA and slightlyoff I believe think they will |
| 13:38 | JakeA | awakens |
| 13:38 | <annevk> | mkwst: of course, letting CSP control set-cookie and letting CSP be set from SW are potentially somewhat contradictory goals |
| 13:40 | <JakeA> | I'll pop this onto my todo list, need to process it a bit to work out how it interacts with SW |
| 13:40 | <JakeA> | I'm not dead set on SW being able to set CSP, I just couldn't think of another way of doing it at the time |
| 14:23 | <JakeA> | annevk: mkwst: since the response's policy can only be set from an http fetch, it cannot be set manually - am I reading that right? Does that mean `new Response` always has no policy? |
| 14:37 | <jochen__> | annevk: a more detailed response to your email... |
| 14:37 | <jochen__> | annevk: nothing else is updated for css requests either (in blink) |
| 14:38 | <jochen__> | annevk: i'm not saying that this is great, but I can hardly define for css how it should fetch resources in the referrer spec |
| 14:40 | <annevk> | jochen__: no, but we can all agree on what the model is |
| 14:42 | <jochen__> | not sure I understand? |
| 14:43 | <jochen__> | the model should be fetch, no? |
| 14:43 | <annevk> | jochen__: the model for how CSS should work |
| 14:43 | <jochen__> | it should use fetch, right? |
| 14:44 | <annevk> | jochen__: sure, but we're discussing how it uses fetch |
| 14:44 | <jochen__> | hum |
| 14:44 | <jochen__> | i'm not really discussing that |
| 14:44 | <mkwst> | annevk: I don't recall the problem with allowing service workers to control a page's policy. The model in this document allows the service worker to replace/mody a request/response, but forces the response back through the page's policy. That's the agreement that I recall. |
| 14:44 | <annevk> | jochen__: you're saying that it shouldn't have a referrer policy, whereas others have been saying it should have one, that of the document |
| 14:44 | <mkwst> | JakeA: ^^ |
| 14:44 | <jochen__> | no |
| 14:45 | <jochen__> | i'm saying whatever has a referrer should have a policy |
| 14:45 | <jochen__> | and it should take the one from whereever it got the referrer |
| 14:45 | <jochen__> | and I understood what you said as "but I don't like where the referrer came from" |
| 14:46 | <annevk> | jochen__: I guess I'm disagreeing with that notion |
| 14:47 | <annevk> | jochen__: I think it's fine for the referrer to come from the stylesheet, whereas the referrer policy comes from the stylesheet's document |
| 14:48 | <jochen__> | mhm |
| 14:48 | <jochen__> | and it should use the policy from the document whenever the network request actually hits the wire? |
| 14:49 | <jochen__> | or from when the stylesheet is loaded? |
| 14:50 | <JakeA> | mkwst: but if the policy is only applied through http fetch, doesn't that mean CSP is always empty via new Response() (even if headers are set manually) |
| 14:52 | <annevk> | jochen__: well, that's an open question for any request |
| 14:53 | <annevk> | jochen__: if we allow the referrer policy to change in general, we should also allow it to change for stylesheets |
| 14:53 | <jochen__> | i agree that this sounds good in general |
| 14:54 | <jochen__> | however, if the referrer comes from the document, it's odd to only propagate referrer policy changes but not referrer changes |
| 14:55 | <annevk> | the referrer comes from the stylesheet, it cannot really change |
| 14:55 | <annevk> | CSSOM allows changes a bit, but none that would affect the referrer |
| 14:56 | <jochen__> | so if the referer cannot really change, the policy shouldn't change either imo |
| 14:57 | <jochen__> | i mean, a referrer can't change all that much anyway |
| 14:57 | <jochen__> | basically, anything that you can do via history.pushState |
| 14:59 | <annevk> | right, for documents it can change |
| 15:00 | <annevk> | given that you have <meta name=referrer> you're going to allow some kind of change to the referrer policy either way |
| 15:01 | <annevk> | the main question is whether that is bounded somehow to the first occurrence and whether that makes sense |
| 15:01 | <annevk> | I guess I don't really care strongly about that |
| 15:02 | <annevk> | I'd go for whatever is easy to implement, but I don't think you can say "no modifications" since clearly <script src=...> <meta name=referrer ...> would be one of the tests |
| 15:42 | <jochen__> | annevk: indeed, we have such a test in blink |
| 15:42 | <jochen__> | annevk: and currently, it tests that the policy is not updated for the stylesheet |
| 15:43 | <jochen__> | annevk: the thing is, i'd rather not fix one behavior for css in the referrer policy |
| 15:43 | <jochen__> | annevk: i'd rather have css to make up its mind how to integrate with fetch |
| 15:44 | <annevk> | jochen__: euhm, you didn't let HTML make up its mind either |
| 15:44 | <annevk> | jochen__: I don't see what is so hard about deciding on something here |
| 15:44 | <annevk> | jochen__: clearly it needs to be specified elsewhere, but for now we can have a note in the specification about what it's going to be |
| 15:45 | <annevk> | jochen__: but I guess you could email www-style⊙wo and let them chime in, but I'm pretty sure they'd just defer back |
| 15:45 | <jochen__> | mhm |
| 15:45 | <jochen__> | i'll just run the layout test on firefox and see what happens |
| 15:46 | <jochen__> | in the best case, it just passes, then we have a decision |
| 15:47 | <annevk> | jochen__: that still doesn't make a lot of sense to me |
| 15:48 | <annevk> | jochen__: anyway, what happens for <script src=...> <meta name=referrer ...> <script src=...> <meta name=referrer ...> <link rel=stylesheet> etc. |
| 15:48 | <annevk> | jochen__: does the policy keep changing? |
| 15:49 | <jochen__> | yes |
| 15:49 | <jochen__> | <meta> is pretty random anyway |
| 15:49 | <jochen__> | as the preload scanner does some funky stuff with it |
| 15:49 | <jochen__> | i'd rather only of CSP delivery |
| 15:50 | <jochen__> | anyway, off for today |
| 15:51 | <annevk> | jochen__: so the question for stylesheets is whether we copy the policy in or whether it's a reference |
| 15:51 | <annevk> | jochen__: given CSSOM I'd say it should by reference |
| 15:52 | <annevk> | be by* |
| 16:49 | <Domenic> | annevk: WindowProxy at https://github.com/domenic/window-proxy-spec but it has no knowledge of cross-origin complications, yeah. |
| 16:51 | <annevk> | Domenic: for cross-origin we basically want to consolidate the object creation to a single point |
| 16:52 | <annevk> | Domenic: and that then branches to create the correct objects |
| 16:52 | <Domenic> | annevk: I don't really have enough context to know what that means. What objects are you even talking about. |
| 16:52 | <annevk> | Domenic: same for returning objects, obviously |
| 16:52 | <annevk> | Domenic: WindowProxy and Location objects have their own cross-origin objects per the etherpad draft |
| 16:53 | <Domenic> | annevk: hmm OK, makes sense I guess. |
| 16:53 | <wanderview> | annevk: JakeA: I asked in issue, but do you think a document in SW scope should still be considered "controlled" if `disableFetch()` has been called? |
| 16:54 | <beverloo> | fwiw, from a push messaging perspective, I quite dislike the disableFetch() method (while I understand the reasoning of not wanting listening to events to have side-effects) |
| 16:55 | <beverloo> | there's major performance improvements a UA can make if it's known whether an event will be handled by a SW or not |
| 16:55 | <beverloo> | making features opt-out doesn't scale very well (disablePush()? disableSync()?) |
| 16:56 | <JakeA> | Yeah, I'd still rather listening was just observable |
| 16:57 | <JakeA> | wanderview: …but is we had disableFetch() my hunch would be that the pages are still controlled. |
| 16:57 | <wanderview> | beverloo: push and sync are explicitly opt-in, so not sure why we would need to add disable calls for those... I think many people would prefer fetch was opt-in as well |
| 16:57 | <beverloo> | wanderview, for now, but onpushsubscriptionchange/onpusherror/hypothetical onnotificationclose wouldn't be |
| 16:58 | <JakeA> | It allows you to defer idb upgrades to an activate event of a sw, avoiding multiple tabs with different versions. Also makes sense with clients.matchAll |
| 16:59 | <wanderview> | JakeA: the controlled status does those things? or is that a different topic? |
| 17:00 | <wanderview> | I'm fine with it being controlled... I just suddenly wasn't sure if the definition of "controlled" implied fetch events or not |
| 17:00 | <JakeA> | wanderview: a new SW will wait behind the active one while controlled pages exist using the active one |
| 17:00 | <JakeA> | wanderview: clients.matchAll() will return only controlled clients by default |
| 17:00 | <wanderview> | right, ok... its more a lifecycle thing |
| 17:01 | <wanderview> | my mental model was wrong... I was thinking of it as being "controlled" in the sense the fetch interception lets the service worker have its way with the page |
| 17:04 | <wanderview> | thanks |