07:08
<annevk>
Hall of Web IDL shame (includes Web IDL due to a fault in Cookie Store): https://github.com/w3c/webref/tree/main/ed/idlpatches
07:47
<Marcos Casagrande>

Hello annevk I've been working on Deno MIME sniffing tests, but noticed that if we pass all mimesniff tests, FileAPI tests begin to fail. Could you take a look at: https://github.com/web-platform-tests/wpt/issues/36377

It seems Blob (FileAPI) and mimesniff spec/tests conflict with each other.

07:48
<Andreu Botella>
that might be related to https://github.com/w3c/FileAPI/issues/170
07:49
<Marcos Casagrande>
Known issue it seems then, thanks for the link Andreu Botella
07:52
<annevk>
Marcos Casagrande: I wouldn't mind seeing the File API tests updated with some kind of pointer to issue 43
07:52
<annevk>
There was agreement this was going to be fixed, but File API isn't really maintained by anyone at the moment
07:53
<Andreu Botella>
you'd think the Chrome folks would be maintaining it, since it interacts with the OPFS and file system APIs
08:10
<Marcos Casagrande>
There was agreement this was going to be fixed, but File API isn't really maintained by anyone at the moment
So making Deno's Blob compliant with MIME sniffing spec would be the best path forward given that File API isn't being maintained?
08:34
<annevk>
Marcos Casagrande: I think so, ideally we do the same in browsers and perhaps find a maintainer for File API...
08:41
<Marcos Casagrande>
Thanks annevk
08:42
<Marcos Casagrande>
By updated, you mean remove the broken ones in favour of mimesniff tests?
09:44
<Ms2ger 💉💉💉>
So Marcos Casagrande, how do you feel about becoming an editor for File API?
10:33
<sideshowbarker>

If somebody familiar with cache partitioning in current engines could weigh in on https://github.com/mdn/content/issues/21469 that would be much appreciated.

It would be nice to have some sources to cite that clearly show:

  1. Major browser engines have all implemented cache partitioning.
  2. Cache partitioning prevents Etag-based tracking.
11:04
<annevk>
sideshowbarker: I'm familiar, but don't have good sources other than https://privacycg.github.io/storage-partitioning/
11:09
<Marcos Casagrande>
I'm flattered but to be honest writing specs is not my thing. I prefer to implement them. And I'll barely have any time to do it as well.
11:35
sideshowbarker
looks
11:36
<Ms2ger 💉💉💉>
It was worth a try :)
11:41
<sideshowbarker>

annevk: MDN has https://developer.mozilla.org/en-US/docs/Web/Privacy/State_Partitioning#network_partitioning already too — but that document is Firefox-specific

However, it seems like that doesn’t need to be Firefox-specific and could be re-worked to also cover what’s implemented in other UAs too.

But making that so still depends on having info on exactly what’s implemented in the various engines (and ideally also on having more-specific info about how it affects Etag-based tracking in particular)

12:14
<annevk>
sideshowbarker: I can tell you that the reporter is correct (they're a security researcher if I'm not mistaken)
12:14
<sideshowbarker>
yeah I don’t doubt that — would just be useful to have something to reference
12:16
<annevk>
sideshowbarker: etag-tracking relies on putting something in the cache and then looking if it's there at a different point in time; if the key is only the URL of the thing you put in, that's easy; if the key includes the top-level site, it won't work across cross-site "tabs". These days the key includes the top-level site in all browsers. More keys are only a reality in some browsers and still a topic of discussion.
12:16
<sideshowbarker>
I see
12:18
<sideshowbarker>

Well I guess for now I should just delete that “Etags are therefore similar to fingerprints, and might also be used for tracking purposes by some servers” sentence from the docs

Would be nicer to have something suitable to update/replace with it, but not really essential I guess

12:22
<sideshowbarker>
https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching is a great doc but doesn’t currently describe any details about how engines construct cache keys now how it relates to Etags. It seems like it’d be helpful if it did (or at least enlightening)
12:29
<annevk>
Yeah agreed. Perhaps if you start with linking https://privacycg.github.io/storage-partitioning/ here and there someone will eventually expand on it a bit.
18:01
<TabAtkins>
I think maybe &gt; could be needed if you're doing unquoted attributes? software.hixie.ch/utilities/js/live-dom-viewer/saved/10864

Right, my personal strat in full is:

  1. If writing by hand, use unquoted attrs when I can do so safely. Otherwise, use quoted (and escape the quote char.). Always escape <; escape & if it's not surrounded by whitespace.
  2. If writing HTML content with user-submitted content, always escape < and & in text, and always quote attributes and escape the quote character and & in attr values.
  3. If in a live webpage, always use the DOM APIs to insert user-submitted text, so no escaping is needed whatsoever. Exposing user content to the parser is a landmine.
18:09
<Andreu Botella>
TabAtkins: could you look at this? https://github.com/w3c/csswg-drafts/issues/7865
18:09
<Andreu Botella>
the w3c.github.io build is failing after a recent change
18:09
<TabAtkins>
ah, thanks, will fix shortly.
18:10
<TabAtkins>
(and I should indeed change it to not fail on a fatal error)
18:10
<TabAtkins>
i was wondering why they started failing yesterday afternoon