00:30
<tobie>
Domenic: if there's ever a time where you want to have a look at the Generic Sensor API and comment, now (i.e. within the next 2 weeks or so) we would be about right.
00:31
<tobie>
https://w3c.github.io/sensors/ for the Generic Sensor ED and https://w3c.github.io/ambient-light/ for a first concrete sensor building on top of it.
05:05
<annevk>
slightlyoff: ta
05:05
<annevk>
Domenic: no review?
05:14
<gwicke>
hi, after reading https://github.com/whatwg/fetch/issues/66 I'm wondering if fetch responses with redirect: 'manual' might expose the response body some time in the future?
05:16
<annevk>
Hmm, https://github.com/heycam/webidl/issues/101
05:17
<annevk>
gwicke: only if we design a protocol for the server to opt into
05:17
<annevk>
gwicke: something like CORS, but for redirects
05:19
<gwicke>
even for same-origin requests?
05:22
<gwicke>
background: we have some REST API use cases in which the option to let the client opt out of redirects & access the response body instead would simplify caching
05:26
<annevk>
gwicke: yes
05:27
<annevk>
gwicke: https://fetch.spec.whatwg.org/#atomic-http-redirect-handling
05:28
<gwicke>
the example cited there is a cross-origin redirect; I have trouble seeing the issue if it's all within the same origin
05:30
<annevk>
gwicke: could be similar for same-origin with it redirecting to some token URL that you didn't expect would be exposed
05:31
<gwicke>
hm, okay
05:34
<gwicke>
using redirects to hide such information from XSS feels a bit odd, but the restriction makes sense with that goal as a background
05:34
<gwicke>
thanks!
05:38
<annevk>
gwicke: it's because we never exposed redirects that exposing them now would cause problems, that kind of design was really the goal I think
05:38
<annevk>
gwicke: we just didn't expose redirects quickly enough
05:38
<annevk>
gwicke: but maybe it's kind of nice that we didn't
05:41
<gwicke>
it's too late in any case if we assume that sites rely on this quirk for XSS protection
05:54
<annevk>
right, that's what I meant
11:37
<Guest45222>
hello #whatwg
11:40
<Guest45222>
looking at the spec around location interface and wondering the root cause of location's properties being unforgeable. I've seen lots of comments saying that it's for security purposes but no clear evidence to me.
11:42
<march__>
some evidence on google books but not mush http://bit.ly/1RD3PsH
11:42
<march__>
*much
11:56
<annevk>
march__: that's the reason
11:56
<annevk>
march__: plugins would read those properties and expect them to be accurate
11:57
<annevk>
march__: [Unforgeable] also makes them own properties, which is important for all the security checks in Location object's internal methods
13:01
<annevk>
How do you set something permanently on your PATH?
13:08
<annevk>
Anyone still familiar with the HTML parser that knows how to fix https://www.w3.org/Bugs/Public/show_bug.cgi?id=28433?
13:22
<march__>
thanks annevk for answer, this is exactly what i want to do : fool a script so it thinks that it's running somewhere else.
13:22
<march__>
my last hope is https://github.com/hackvertor/MentalJS/blob/master/javascript/Mental.js
13:27
<march__>
but it's quite ugly, too bad we can't sandbox properly third party scripts
14:02
<Domenic>
annevk: I nominate zcorpan for becoming the parser person :P
14:32
<MikeSmith>
nice to see the bugzilla count down as much as it’s gone down
14:39
<SimonSapin>
annevk: https://html.spec.whatwg.org/multipage/semantics.html#htmlhyperlinkelementutils seems to duplicate https://url.spec.whatwg.org/#api
14:39
<SimonSapin>
Is that intended?
14:39
<SimonSapin>
Are there differences?
14:48
<Ms2ger>
SimonSapin, https://github.com/whatwg/url/issues/62
23:59
<jyasskin>
TabAtkins: Feature request: add https://tc39.github.io/ecma262/ to Shepherd.