05:00
<snek>
Seems like another case of people trying to use CSP for exfiltration prevention, which it isn't designed for?
out of curiosity do you have any ideas on alternatives? it seemed to me that CSP was intended for this (among other things) so if there's something else i should be looking at instead i'd be very interested
05:04
<Domenic>
Don't run untrusted code on your page?
05:04
<snek>
lol
05:04
<Domenic>
CSP is designed to prevent XSS, so that you can achieve that goal
05:04
<snek>
thats generally my philosophy as well
05:05
<Domenic>
Once there's untrusted code on your page though through XSS (including self-XSS), there's no good technology to prevent it from doing various network requests
05:05
<snek>
looks like they added a connect-src check to chromium's webtransport code
05:05
<snek>
so that's nice
05:06
<snek>
guess its just down to webrtc
05:07
<Domenic>
Some discussion on https://blog.compass-security.com/2016/10/bypassing-content-security-policy-with-dns-prefetching/ , not a primary source though
05:07
<snek>
i guess i'm sort of being the person i always hate, some random guy from a company trying to do something that is probably a dumb idea :)
05:07
<Domenic>
https://www.cse.chalmers.se/~andrei/asiaccs16.pdf is better
05:09
<Domenic>
That paper gives quite a good overview actually, in section 2.2
05:11
<snek>
discord has an interesting feature called activities which is basically little games and stuff you can play with your friends. the problem is that these games are written as web apps, so currently we can't really open them up to random third party developers. i'm exploring some ways to make things better, and i really don't want my endpoint to be "full wasm sandbox that draws to a canvas" cuz that sucks in many many ways
05:42
<Domenic>
Sandboxed iframes?
05:42
<Domenic>
I guess that doesn't really have exfiltration controls either, sorry, forgot the threat model
05:42
<Domenic>
If you ensure no interesting information gets into the sandboxed iframe to exfiltrate, maybe
05:45
<snek>
yeah the iframes are already pretty locked down. the interesting thing i discovered is that you can work around it slightly by creating an iframe (inside the sandbox iframe) with no src, which gives you a fresh window instance somehow? so none of our safety scripts have run yet
06:22
<snek>
lol this makes me sad https://csplite.com/csp/test368
06:24
<snek>
i have no idea who runs this site
06:25
<snek>
hah same thing https://github.com/web-platform-tests/wpt/blob/master/content-security-policy/frame-src/frame-src-about-blank-allowed-by-default.sub.html
07:47
<sideshowbarker>
annevk: https://github.com/mdn/content/issues/22333
08:00
<annevk>
sideshowbarker: the spec is pretty clear, the getter invokes https://url.spec.whatwg.org/#url-path-serializer
08:02
<sideshowbarker>
Yeah the MDN wording just needs to be fixed
08:03
<sideshowbarker>
I hope some contributor picks up the issue so that I don't have to
08:03
<sideshowbarker>
It should be a quick fix
09:05
<annevk>
Domenic: I think you're right that it'll be awkward at best to define content attributes for ElementInternals... One problem with doing [Reflect] is that ARIA really needs enumerated attributes and we don't have a thing for that as of yet. But maybe a structured table in prose could be sufficient.
11:34
<Domenic>
Right... ideally ARIA would define its various content attributes as enumerated attributes, and the ElementInternals part could delegate to those definitions?
11:35
<Domenic>
But so far ARIA doesn't really have that level of rigor anyway
22:49
<sideshowbarker>

Why does new URL("https://developer.mozilla.org").pathname give "/" ?

Based on https://url.spec.whatwg.org/#url-path-serializer, I would expect it to be the empty string instead.

…in that, if the URL has no path segments, the pathname value should be the empty string.

What path segments does https://developer.mozilla.org have?