| 06:20 | <ondras> | can anyone please point me to a RFC where the SameSite attribute is defined? |
| 06:20 | <ondras> | the recent Chrome cookie treatment recommends putting SameSite=None on cookies that are to be used as 3rd party, but MDN says that None is not a valid value |
| 06:23 | <TimothyGu> | ondras: https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-5.3.7 |
| 06:24 | <ondras> | TimothyGu: thanks! this is only a draft, right? how does one find what draft is the proper draft? :) |
| 06:25 | <TimothyGu> | ondras: that's the most current one. If you click on "Tracker" at the top of the draft then you can find the history/status |
| 06:26 | <TimothyGu> | In particular, it's been there in some form since 2014 though the first document to call it SameSite is draft-west-first-party-cookies-05 in 2016 |
| 06:26 | <ondras> | TimothyGu: nice, thanks. still a bit overwhelming, but I will try to understand the timeline at the top :) |
| 06:26 | <ondras> | my current issue is the 'None' value |
| 06:27 | <ondras> | that is recommended by Google |
| 06:27 | <ondras> | (but rejected by Chrome up to 66) |
| 06:28 | <TimothyGu> | ondras: https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-4.1.2.7 defines the meaning of None |
| 06:29 | <TimothyGu> | ondras: it was only implemented in Chrome in https://chromium-review.googlesource.com/c/chromium/src/+/1573081 |
| 06:29 | <TimothyGu> | ondras: which per https://chromiumdash.appspot.com/commits?commit=324657c38b04e13532d952c90674bc453b634706&platform=Linux is only in 76 |
| 06:29 | <ondras> | yes |
| 06:29 | <TimothyGu> | to be released in July |
| 06:30 | <ondras> | but support for non-{lax,strict} values was added in https://chromium.googlesource.com/chromium/src/+/5fbb75e93162093522879e707a13295b7452ef06%5E%21/#F2 |
| 06:30 | <ondras> | so if I start sending samesite=none, chrome66 and older will reject those |
| 06:31 | <TimothyGu> | ondras: do you have any idea how much market share Chrome <66 has? |
| 06:31 | <ondras> | no |
| 06:32 | <ondras> | but i suppose that might include older android devices/browsers |
| 06:32 | <ondras> | that are extremely popular here in Czech Republic :/ |
| 06:32 | <TimothyGu> | ah… |
| 06:33 | <ondras> | my initial plan was to start adding somesite=none to our cookies that are to be used in a 3rd party manner |
| 06:33 | <ondras> | but I will have to re-consider |
| 06:35 | <TimothyGu> | ondras: I suppose some telemetry would be useful for your case |
| 06:40 | <ondras> | perhaps |
| 06:41 | <ondras> | or, well, not forcing the None value when it even is not yet accepted as a RFC? :) |
| 06:43 | <TimothyGu> | ondras: I would strongly encourage looking at implementation status rather than RFC approval as if a feature is ready |
| 06:43 | <ondras> | :/ okay |
| 06:44 | <TimothyGu> | it's pretty common for a standardized feature to get hung up on approval due to bureaucratic matters |
| 06:46 | <ondras> | is this the case? |
| 06:46 | <TimothyGu> | that, I don't know :) |
| 06:50 | <ondras> | the draft we are talking about, https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-5.4, it defines a storage model |
| 06:50 | <ondras> | I might not be good at reading RFCs |
| 06:50 | <ondras> | but it looks to me like the model says "samesite=none" equals to no samesite attribute |
| 06:51 | <ondras> | (step 13) |
| 06:51 | <ondras> | do I interpret this correctly? |
| 06:51 | <TimothyGu> | I think so |
| 06:51 | <ondras> | okay. so this is the behavior chrome76 is not going to follow? |
| 06:52 | <TimothyGu> | ondras: Why do you say Chrome 76 isn't going to follow that behavior? |
| 06:53 | <ondras> | TimothyGu: because they are going to implement "no samesite attribute equals to samesite=lax" |
| 06:53 | <ondras> | or that is what I understood |
| 06:56 | <TimothyGu> | ondras: implementing ≠ enabling by default |
| 06:56 | <TimothyGu> | ondras: from https://web.dev/samesite-cookies-explained/ it just seems like 76 adds a flag. there's probably going to be a bit of time before Lax is made the default |
| 06:58 | <TimothyGu> | ondras: also, the proposed change to make lax default is captured in https://tools.ietf.org/html/draft-west-cookie-incrementalism-00#section-3.1 |
| 06:59 | <TimothyGu> | I expect it to be quite a while before these changes to the default are implemented |
| 07:01 | <ondras> | TimothyGu: okay, thanks for explanation |
| 10:21 | <oliverdunk> | @ondras What do you mean by rejected? From the article: "any clients that do not recognize SameSite=None as of yet should ignore it and carry on as if the attribute was not set." - by which it means, the browser hasn't been updated so still uses the less secure default, which will work third party. |
| 10:24 | <ondras> | oliverdunk: well Chrome up to 66 ignores (does not store) cookies with SameSite=xyz (or None or any other non-Lax non-Strict value) |
| 10:26 | <ondras> | https://medium.com/compass-security/samesite-cookie-attribute-33b3bfeaeb95 |
| 10:26 | <ondras> | this article describes the behavior; probably with chrome 62 or 63 |
| 10:26 | <ondras> | my further testing on browserstack confirmed the said behavior up to 66 |
| 10:37 | <oliverdunk> | ondras: Gotcha, so Chrome didn't have that behaviour until the patch you linked. You should get in touch with the article's authors as it seems like an important thing to note :) |
| 10:51 | <ondras> | oliverdunk: okay, why not |
| 12:05 | <annevk> | oliverdunk: please ping me once the agreement thing is sorted and I'll get back to the DOM PR, leaving it for now |
| 14:36 | <oliverdunk> | No worries, will do! |
| 14:49 | <bkardell> | he did anyone see this q -> https://freenode.logbot.info/whatwg/20190511#c2171308 - maybe @annevk or @Domenic knows? |
| 14:49 | <Domenic> | bkardell: I had a really hard time understanding that... could you try something more brief? |
| 14:50 | <bkardell> | sure... so, back in original proposals Dimiti and team worked out complex multi-shadow root ideas |
| 14:50 | <bkardell> | then at some point the decision was 'nah, let's just have one and it would throw if you did another' |
| 14:51 | <bkardell> | but there's also no way to remove it and native ones can look like they have none but throw (iirc) |
| 14:53 | <bkardell> | there was some discussion about how you would go about trying several things and the question was asked 'why is it that way' and.. I honestly couldn't recall beyond what I just said. Why can you not delete or remove a shadow root? |
| 14:55 | <bkardell> | I looked, but I couldn't find anything beyond those early discussions which never asked _this_ question, but were based on you can only have one, not many |
| 14:55 | <bkardell> | any better? |
| 15:02 | <Domenic> | "why can you not delete or remove a shadow root", is the question? |
| 15:03 | <Domenic> | Are you asking about your own shadow root, or someone else's? |
| 15:09 | <bkardell> | can you help me understand the distinction? |
| 15:10 | <bkardell> | how do I know about ownership? unless you mean author defined (any author) vs native? |
| 15:27 | <Domenic> | I mean custom element author vs. custom element user. |
| 15:29 | <annevk> | bkardell: a lot of this boils down to more choices meaning more complexity |
| 15:30 | <annevk> | bkardell: and cutting down on complexity that wasn't justified to the extent people needed it to be |
| 15:31 | <annevk> | bkardell: it's not really "nah", it's that doing it requires answering "how" and that not necessarily being straightforward |
| 15:34 | <bkardell> | no I just meant 'nah' was the decision on multi-root designs for the time being - those discussions I recall - but I don't recall why there is no corresponding way to detach/remove one |
| 15:34 | <annevk> | bkardell: that was not a "nah" decision, there were a lot of complexity arguments put forward |
| 15:35 | <bkardell> | I think maybe something is getting lost/overread... 'nah' is just intended as 'we decided not to for now' and nothing more |
| 15:35 | <annevk> | "nah" makes it sound like it wasn't duly considered |
| 15:35 | <bkardell> | I see |
| 15:35 | <bkardell> | ok, sorry, didn't intend to give that impression, was trying to be brief |
| 15:35 | <annevk> | Whereas there are good reasons not to go there |
| 15:36 | <bkardell> | yeah, no I agree - there was a lot of complexity in those proposals |
| 15:36 | <bkardell> | but I don't recall one about whether you could remove the one we decided to have - but you can't |
| 15:37 | <bkardell> | that is what I am asking about - do you recall discussions on that? I can't find any |
| 15:37 | <bkardell> | and I can't recall |
| 15:38 | <annevk> | I can see issues, e.g., it's no longer clear how ShadowRoot.prototype.innerHTML works |
| 15:38 | <annevk> | A ShadowRoot not having a host would likely complicate other algorithms too |
| 15:39 | <bkardell> | but wouldn't removing it just cause it to be freed? |
| 15:39 | <annevk> | bkardell: that doesn't sound like JavaScript |
| 15:40 | <bkardell> | hmm... I am confused by the appropriate level of detail I should be providing to be clear possibly |
| 15:42 | <bkardell> | like element.removeShadowRoot() (or better name) could return no ref to the removed root - are you saying that doesn't sound like JavaScript? |
| 15:46 | <annevk> | Yes, because it already has a ref |
| 15:49 | <bkardell> | got it |
| 15:49 | <bkardell> | sorry, I see what you mean now |
| 15:53 | <Ms2ger> | Domenic, hey, did you end up working on IDL/kv-storage? |
| 16:11 | <Domenic> | Ms2ger: no, after seeing you'd already done most of the work, it felt less urgent... I guess it'd still be worthwhile for one of us to factor out the module pieces that could land sooner, leaving the rest in prose? I dunno. |
| 16:11 | <Domenic> | bkardell: I wasn't around for early discussions, so if the question is "do you recall such discussions" I don't. (What I meant by brevity is mostly stating concrete questions.) |
| 16:12 | <Domenic> | bkardell: if the question is "why can you not delete or remove a shadow root", it depends on you. A custom element user removing a shadow root is an encapsulation violation. A custom element author removing a shadow root doesn't seem to add much over allowing them to just replace the contents with whatever they want. |
| 16:13 | <bkardell> | "A custom element author removing a shadow root doesn't seem to add much over allowing them to just replace the contents with whatever they want." - yeah, I agree |
| 16:13 | <bkardell> | thanks |
| 16:23 | <bkardell> | @Domenic on asking concrete questions, will try to do so in the future :) |
| 16:41 | <Domenic> | TabAtkins: $ bikeshed update / Updating via manifest... / Local data is already up-to-date (2019-05-06 04:51:06.668829). Done! |
| 16:41 | <Domenic> | Where are my updated dfns :(( |
| 16:41 | <TabAtkins> | Oh jeez, my computer just have fallen over at work. |
| 16:42 | <TabAtkins> | And between vacation, IO, and sick wife, I haven't been to the office since then |
| 16:43 | <TabAtkins> | I need to figure out how to put this on something external. 😑 |
| 16:46 | <TabAtkins> | I should be able to run it manually from my laptop tho, I'll check on that in a sec |
| 16:53 | <Domenic> | haha I see |
| 16:55 | <TabAtkins> | Domenic: Okay, data should be pushed up now. |
| 16:57 | <TabAtkins> | (Remember that you can always run `bikeshed update --skip-manifest`, if you want to force a full update manually without relying on the manifest data.) |
| 16:57 | <TabAtkins> | (But thank you for the ping anyway.) |
| 16:58 | <Domenic> | Ah, I did not know that, although I suppose I could have checked the docs |
| 17:01 | <TabAtkins> | Or `bikeshed update -h` ^_^ |
| 21:16 | <ecobos> | TabAtkins: btw, the more I touch specs, the more I appreciate bikeshed, it's really nice :) |
| 21:16 | <TabAtkins> | <3 |
| 23:05 | <domfarolino> | Is there a way in spec land to determine whether an image was created/inserted by the parser as opposed to by script etc? I know <script>a have a parser inserted flag, but seems images do not. |
| 23:09 | <domfarolino> | <script>s* |
| 23:38 | <zcorpan> | domfarolino: no |
| 23:52 | <domfarolino> | zcorpan: One thing with Chromium’s LazyLoad impl is that scripts created in any way that’s not by the parser naturally (i.e., by some script) will never be lazy loaded when loading=auto. I’m wondering if it is reasonable to express this in spec by saying something to the effect of “if the image was not created by the parser, set loading attr to eager”. |
| 23:53 | <domfarolino> | This may help address some of JakeA’s concerns, but would introduce the concept of being able to determine how the img was created |
| 23:53 | <zcorpan> | domfarolino: would it be good enough to make new Image() set the loading attribute? |
| 23:54 | <zcorpan> | similar to new Audio() |
| 23:55 | <zcorpan> | but if web compat needs document.createElement('img') to be eager, but parsed <img> not, then sure |