| 03:38 | <domfarolino> | Why exactly are module scripts requested with CORS? This comment https://github.com/whatwg/html/pull/443#r48677306 indicates it's necessary for security but I don't quite get "introduce new ways to leak data from existing file types" /cc annevk |
| 03:41 | <not-an-aardvark> | There was additional discussion about it at https://github.com/whatwg/html/issues/1888 |
| 03:42 | <domfarolino> | not-an-aardvark: thank you, will read |
| 11:31 | <annevk> | domfarolino: that has all my points in it too |
| 17:18 | <domfarolino> | HTML standard (among other places) indicates a benefit to loading classic scripts via CORS is so that rich error information can be exposed to the client. I'm having trouble simulating this though... |
| 17:19 | <domfarolino> | The document I'm running locally can be found here https://gist.github.com/domfarolino/62ad3d9ccdcc160c62ec99b0b52d033b and basically I don't see a difference in logged errors with either script tag in that gist..am I doing something wrong? |
| 17:39 | <domfarolino> | Ah ok. It seems that it's the error information specifically exposed to window.onerror (like message, url, line, column, error) that is obfuscated..not the uncaught error's stacktrace which still shows up in console |
| 17:47 | <domfarolino> | Hmm however it doesn't seem that Firefox's window.onerror has this same obfuscation...is this not standardized behavior? |
| 22:23 | <MikeSmith> | domfarolino: not exposing it to frontend JavaScript code is required by the Fetch spec, right? |
| 22:24 | <domfarolino> | MikeSmith: not sure I can check when I get home. If so then I guess that's an FF bug unless I'm missing something, bc iirc I got all the info passed to window.onerror |
| 22:25 | <MikeSmith> | if https://demo1426415.mockable.io/errorjs is served with no Access-Control-Allow-Origin then Fetch requires that no part of the response be accessible to frontend JavaScript |
| 22:26 | <MikeSmith> | the detailed error information is part of the response |
| 22:26 | <domfarolino> | I wasn't fetching it, was using it as the src attr on script tag |
| 22:26 | <MikeSmith> | ah yeah |
| 22:27 | <MikeSmith> | but in that case the Fetch is done with no-cors I think |
| 22:27 | <MikeSmith> | which means the response is not exposed to frontend JS no matter what |
| 22:28 | <MikeSmith> | opaque response |
| 22:29 | <MikeSmith> | anyway annevk would be the best person to ask and get an explanation from, when he’s not away |
| 23:25 | <domfarolino> | MikeSmith hmm, using <script src="//example.com/script.js"></script>;, the response should still be avail in developer tools right? Either way, Issue with this is people say the data passed to window.onerror is obfuscated when window.onerror gets an error from script.js |
| 23:28 | <domfarolino> | This gist: https://gist.github.com/domfarolino/28725582270679b9e17fa74922cbfd65 produces this output in Chrome: https://image.ibb.co/gSgWyF/Screen_Shot_2017_05_21_at_4_27_06_PM.png |
| 23:28 | <domfarolino> | However in FF we don't get the "Script error" 0 0 thing...we just straight up get the real data |
| 23:47 | <MikeSmith> | domfarolino: yeah the response will always be available in devtools |
| 23:47 | <domfarolino> | right, wanted to make sure we were on the same page |
| 23:48 | <MikeSmith> | as far as why there’s a difference between Firefox and Chrome in what you get from window.onerror I dunno |
| 23:48 | <MikeSmith> | it could be a bug in Firefox that it’s not conforming to the Fetch spec on this |
| 23:49 | <MikeSmith> | or I could just not be understanding |
| 23:49 | <MikeSmith> | but annevk will be able to give you a clear answer |
| 23:53 | <domfarolino> | MikeSmith could you help find the section in the fetch spec you are referring to? I know that HTML refers to the `crossorigin` attribute and how it helps expose more specific error data (https://html.spec.whatwg.org/multipage/scripting.html#attr-script-crossorigin) but don't know where this sort of thing is in fetch |
