10:02
<annevk>
TIL: Chrome/Safari block style sheets without an ok status...
10:55
<MikeSmith>
annevk: non-2xx status you mean?
10:55
<MikeSmith>
they won’t follow 3xx’s?
10:56
<annevk>
MikeSmith: at the point where the relevant algorithm gets a response, redirects have been handled
13:51
<croraf>
When rendering an <object> element I would need to set the Authorization header to be used for fetching its data. Is this possible to do "directly"?
13:52
<annevk>
I'm not sure I understand the question, but I'm pretty sure the answer is no
13:54
<croraf>
What is not clear in the question? annevk
13:54
<croraf>
I have <object data='https://my.url.com/path'; />
13:55
<croraf>
This will make a request for the object (a pdf) to this url. But the url won't allow unauthorized requests.
13:55
<croraf>
So in the request additional headers should be specified.
13:56
<croraf>
The <image src='...' > is a similar example that I saw people are struggling with.
13:56
<croraf>
Is this possible? If it is not possible why not add this capability to the standard?
13:58
<annevk>
I think everyone removed that (you could use the username/password fields of a URL) because it would allow for dictionary attacks
14:01
<MikeSmith>
annevk: so what does “without an ok status” mean? what other status is there that would not also cause all browsers to not load the stylesheet either?
14:02
<annevk>
MikeSmith: Firefox applies a style sheet whose status is 600
14:02
<annevk>
MikeSmith: can I rename the default branch on whatwg/misc-server?
14:10
<croraf>
annevk, what do you mean by "everyone removed that", you mean every browser? does this mean some browsers supported something like that?
14:13
<annevk>
yes
14:50
<croraf>
Why not add to the standard to add some header fields to the img or object elements?
14:50
<croraf>
would really come handy in situations like this, and a lot of people are wondering this over the internet
14:55
<andreubotella>
As annevk said, letting some script on some random website manipulate the Authentication header would be a big security risk
14:55
<gsnedders>
annevk: IIRC Opera blocked everything !ok as part of the cross-origin stylesheet snooping fixes, IIRC
14:55
<annevk>
gsnedders: well, they didn't standardize it
14:55
<gsnedders>
annevk: hence WebKit/Blink (quite possibly pre-fork) blocking them doesn't seem super surprising?
14:56
<gsnedders>
annevk: none of that cross-origin protection stuff was standardised for a long time after, AFAIK :|
14:58
<gsnedders>
and wasn't there some quirks mode scoping of some of it, at least the text/css check, originally?
14:58
<annevk>
The main things about being strict on text/css has been standardized for a long time
14:58
<gsnedders>
(this is CVE-2010-0654 I'm referring to)
14:58
<annevk>
So if !ok was part of that I would have expected that to have come up, but it hasn't and Firefox doesn't implement it
15:04
<croraf>
andreubotella, annevk how would it be a security risk, and what does it have to do with dictionary attacks?
15:05
<croraf>
What does allowing Authentication header have anything to do with a dictionary attack?
15:07
<andreubotella>
croraf: https://gist.github.com/andreubotella/04e617f15af88125597d842c40e2edba
15:08
<andreubotella>
I'm not actually sure that img.decode works that way – this is an example, not a proof of concept
15:13
<croraf>
And what possible workaround offers protection by such attacks?
15:13
<andreubotella>
I always confuse atob and btoa
15:14
<croraf>
This is silly I think. Why is having Authorization header in the image making site less secure than not having.
15:14
<andreubotella>
croraf: the point is not having the header, it's letting scripts from other sites modify it
15:14
<croraf>
An attacker can try dictionary attacks on everything, it can try to access the same resource using fetch and with dictionary attack.
15:15
<andreubotella>
huh, right
15:15
<andreubotella>
with fetch probably not because of cors
15:15
<andreubotella>
but an attacker could use any non-browser http client
15:16
<Domenic>
This is the usual problem
15:16
<Domenic>
You cannot use fetch to access internal (e.g. intranet) resources, because of CORS
15:16
<Domenic>
You can use <img> to do so
15:16
<croraf>
I see.
15:16
<Domenic>
So <img> with arbitrary headers can be used for attacks on intranets
15:17
<croraf>
Why is cors not applied to images?
15:17
<Domenic>
Because it wasn't in Netscape 1.0 :(
15:17
<andreubotella>
"don't break the web" is an important principle, and that means if something used to work, it must keep working unless the risks would be huge
15:18
<Domenic>
Arguably the risks are pretty bad these days, but we've gone with less strict mitigations than full CORS. E.g. CORB is such a mitigation.
15:18
<gsnedders>
annevk: oh, https://trac.webkit.org/changeset/72743/webkit might be the change that made this happen in WebKit, which makes it look accidental?
15:20
<annevk>
gsnedders: isn't that for images? Pretty sure that it's important to ignore status there
15:21
<gsnedders>
annevk: it changes WebCore/loader/cache/CachedResource.h and WebCore/loader/loader.cpp to make < 400 a failure by default, except where things opt-in to it being okay (like images)
15:22
<andreubotella>
Domenic: with "these days" you mean because of Spectre, right?
15:22
<gsnedders>
annevk: basically anywhere that didn't explicitly check "has an error occured" started being strict about this
15:23
<annevk>
gsnedders: I guess that means I should check media as well, at least for ORB purposes
15:23
<Domenic>
andreubotella: indeed
15:23
<annevk>
gsnedders: there's a bunch of other things like text tracks that might then also need to be checked, but I care less about those
15:25
<croraf>
I still need slight clarification. So scripts on website A loaded from any origin can access the <image>. Or the issue is that scripts from any origin can create the <image> element with some URL and access that data?
15:26
<andreubotella>
croraf: some of the CORS-related restrictions that were put on the <img> element means you can't access the contents of the image from a website in a different origin, because those capabilities were only added after CORS, but you can see if the image loads or not
15:27
<andreubotella>
so if you can change the Authorization header, just create an <img> element in any origin that points to a resource in the intranet, and see if it loads
15:28
<annevk>
Domenic: are there server aspects that depend on the default branch name? Or would that all be documented in misc-server in which case I should find it shortly?
15:28
<Domenic>
annevk: my guess is if you do a full-text search on misc-server for "master" you'll find all such dependencies.
15:29
<annevk>
great
15:29
<Domenic>
(assuming you are only talking about renaming misc-server)
15:29
<annevk>
Domenic: I'm talking about renaming all repos, but I'm also grepping all repos
15:29
<annevk>
Domenic: so the main question is if we have stuff that's outside repos I suppose
15:29
<croraf>
andreubotella, how can you see that it loads?
15:30
<Domenic>
annevk: OK, I can't think of anything outside repos then. We'll see...
15:30
<andreubotella>
croraf: my example was using the img.decode() method, that I believe returns a promise that rejects if the image doesn't load. but you can also listen for an "error" event
15:30
<annevk>
If anything breaks down it should be easy to fix, not planning on switching today though
15:31
<annevk>
Maybe Tuesday would be a good day after we get the RDs out
15:32
<croraf>
andreubotella, I see
15:33
<croraf>
I'm also confused now with this <object> element, it loads a document in my example, but I cannot apply Network latency in Chome devtools to it.
15:35
<croraf>
<object type='application/pdf' data={url} />
15:36
<croraf>
I'm so confused with this <object_
15:38
<andreubotella>
croraf: <object> and <embed> used to be elements that allowed you to integrate plugins like flash into a page
15:38
<croraf>
So I should use Iframe for pdf's?
15:38
<andreubotella>
yeah
15:39
<croraf>
:thumbs-up:
15:39
<croraf>
I mean I know there are subtle differences between the three.
15:39
<andreubotella>
see https://github.com/whatwg/html/issues/6003, which will make object and embed more similar to iframe now that flash is deprecated
15:40
<croraf>
I'm wondering if the latency will be applied on the iframe
15:40
<croraf>
it is not :(
15:41
<andreubotella>
that sounds like a chrome devtools issue, rather than something the spec would require
15:41
<croraf>
yes
15:41
<croraf>
Can I apply custom headers to Iframe, I guess not :( ?
15:43
<croraf>
https://bugs.chromium.org/p/chromium/issues/detail?id=1113722&q=devtools%20latency%20iframe&can=2 I guess that's the bug
15:46
<croraf>
Damn, thats from 2012, and still open
15:48
<croraf>
But even on FF it is not throttled
15:59
<andreubotella>
annevk: I think I'll file a PR for https://github.com/whatwg/html/issues/6247 and see what the folks from the different browsers think
16:00
<annevk>
andreubotella: sounds reasonable, unfortunate that people are not more proactive, but that's pretty common I'm afraid
16:01
annevk
hits that all the time
16:23
<annevk>
Domenic: if you're okay with it I think I'm also happy to switch tomorrow
16:24
<annevk>
Domenic: it doesn't seem like we have many dependencies on the default branch name so all the PRs have been rather straightforward
16:24
<annevk>
Domenic: misc-server doesn't need updating at all; participate.whatwg.org does though
16:25
<annevk>
And whatwg.org of course
16:32
<Domenic>
annevk: sounds good to me
16:34
<annevk>
Domenic: cool, I think I'll do it around this time and then watch the fireworks for a one or two hours, assuming you don't find anything problematic
16:50
<croraf>
Is there any way to put <iframe> into loading state?