| 02:33 | <Jasper> | Yikes, the URL spec blew up today, didn't it :( |
| 12:45 | <hallvors> | annevk: around? |
| 12:54 | <hallvors> | In the HTML spec - User Interaction - Drag'n'drop, the DataTransfer stuff doesn't say anything about security risks associated with the *data* or the *type string* - not that I can see anyway |
| 12:55 | <hallvors> | e.g. the risk that a rogue page can launch an exploit at a native application by making the user drop a data payload that will trigger a security problem on that app |
| 12:55 | <hallvors> | or place something on the clipboard that, when pasted, will trigger some security issue in the target |
| 12:56 | <hallvors> | In the context of clipboard API work, I was told in no uncertain terms that allowing a random script to place for example JPG binary data on the clipboard is a no-go since it might target exploitable bugs in some local application's JPG support with a malicious payload |
| 12:59 | <hallvors> | shouldn't the DataTransfer API handle such stuff? For example whitelist safe types? Transcode image files for safety? |
| 12:59 | hallvors | should perhaps mail the whatwg-list |
| 13:06 | <annevk> | hallvors: filing an issue on GitHub might be better, but yeah, it seems like it should |
| 13:06 | <annevk> | hallvors: fancy improving that? |
| 13:11 | <hallvors> | annevk: well, some of those limitations are already implemented .. so it should be possible to figure out what it needs to say :-o |
| 13:12 | <hallvors> | If it's not done in DataTransfer I'll need to add something to Clipboard API - but then DnD would still be vulnerable so that seems silly |
| 13:12 | <annevk> | hallvors: even better |
| 13:12 | <annevk> | hallvors: another thing we should improve is make it an object that both drag & drop and copy & paste can use, right? Or does copy & paste use a different object these days? Haven't really followed that much |
| 13:13 | <hallvors> | it is used in both DnD and Clipb apis |
| 13:13 | <annevk> | Hixie wanted them to share the model entirely so there'd be no distinction and users that can't drag wouldn't be disadvantaged, but it seems like that is hard to do at this point |
| 13:23 | <hallvors> | I'll need some handhelding by developers though, if I'm going to write some security thingies ;) |
| 13:29 | <hallvors> | annevk: regarding the DnD and Clipboard convergence Hixie wanted, I think it's a good goal, and I think if pages make sure they listen to both drop and paste events it should most just work as he intended |
| 13:29 | <annevk> | hallvors: yeah, I guess he was hoping to avoid that pages had to do both |
| 13:33 | <hallvors> | We could do that if we spec'ed that pasting should fire drop events.. but it would be sort of odd |
| 13:33 | <hallvors> | and go against the legacy paste events |
| 13:35 | <annevk> | Yeah, probably not possible |
| 13:35 | <hallvors> | but it's easy to listen to both and use basically the same code for processing both pastes and drops |
| 13:35 | <hallvors> | that seems reasonable to me.. |
| 15:36 | <wanderview> | annevk: should same-origin-data-url flag be set for either <script> or <link rel=stylesheet>? |
| 15:37 | <wanderview> | I have to run, but will check back later... |
| 15:37 | <wanderview> | I can't tell if these are intentionally not there if those specs have not been updated to use fetch |
| 16:26 | jwalden | bemuses himself quasi-trolling the latest WHATWG blog post |
| 16:59 | <annevk> | wanderview: I'm not sure |
| 16:59 | <annevk> | wanderview: maybe for the latter, depends on whether user agents require the MIME type to be correct I suppose |
| 17:00 | <annevk> | jwalden: heh |
| 17:28 | <zokier`> | hi, is a plain text version of dom idl available somewhere? |
| 17:32 | <zcorpan> | zokier`: don't think so. there's https://dom.spec.whatwg.org/#idl-index or you can maybe scrape it from the source https://github.com/whatwg/dom/blob/master/dom.bs |
| 17:34 | <annevk> | Copying the index seems most straightforward |
| 17:36 | <zokier`> | sure, thanks. kinda odd imho though |
| 17:38 | <TabAtkins> | zokier`: Odd how? |
| 17:39 | <wanderview> | TabAtkins: do you know if the spec says anywhere if <link rel="stylesheet'> data URLs should be treated same-origin or cross-origin? |
| 17:39 | <TabAtkins> | P sure it does *not* say anywhere. |
| 17:40 | <wanderview> | thanks |
| 17:40 | <zokier`> | TabAtkins, its just something i would have expected to be easily downloadable |
| 17:42 | <Mek> | what is same-origin/cross-origin used for in link rel="stylesheet"? |
| 17:45 | <wanderview> | Mek: SRI in my particular case... we don't support SRI on no-cors cross-origin... we have a test case that uses SRI for a data URL |
| 17:47 | <annevk> | Mek: CSSOM access, and whether you can omit the MIME type |
| 17:48 | <Mek> | wanderview: doesn't the SRI spec explicitly say "Since the response type for data URLs will always be “opaque” for script and link elements, such URLs are never eligible for integrity checks." |
| 17:49 | <Mek> | (okay, as non-normative text. But that's also how I would interpret the way css/html/fetch specify fetching stylesheets...) |
| 17:50 | <wanderview> | Mek: yes, and I think thats bogus :-) https://github.com/w3c/webappsec-subresource-integrity/issues/35 |
| 17:50 | <Mek> | well, the way I read the css and fetch specs, it leaves the request which its default mode=no-cors and with the same-origin data-URL flag unset, which would indeed result in an opaque response |
| 17:51 | <wanderview> | Mek: css spec uses fetch spec? can you send me the link to that? |
| 17:51 | <Mek> | wanderview: https://drafts.csswg.org/cssom/#fetch-a-css-style-sheet |
| 17:51 | <wanderview> | sorry, I have to go to a meeting now |
| 17:51 | <wanderview> | thanks |
| 18:04 | <smaug____> | annevk: I don't understand the blob part of https://url.spec.whatwg.org/#origin |
| 18:04 | <smaug____> | what does "Let url be the result of parsing the first string in URL’s path. " mean? |
| 18:07 | <Mek> | the url spec defines a path as a list of zero or more ascii strings, and that then parses the first string in that list as if it was a url? |
| 18:10 | <smaug____> | I see |
| 18:11 | <smaug____> | and (new URL("blob:blob:http://foo.com/bar")).origin should be "http://foo.com";, not blob:// what blink gives |
| 18:11 | <Mek> | seems like that to me, yes... |
| 18:42 | <zcorpan> | i'm behind with github notifications. if there's something i should look at, let me know here pls :-) |
| 18:55 | <Domenic> | zcorpan: https://github.com/whatwg/html/pull/1236 is the other PR assigned to you. Seems reasonably small. |
| 19:06 | <wanderview> | Mek: bz wrote an issue for the data URL thing as well: https://github.com/whatwg/html/issues/1243 |
| 19:07 | <Mek> | yeah, I (uninformed) agree that it seems like this might just be an accidental result of how the specs ended up rather than intentional... |
| 19:25 | <zcorpan> | annevk: do you want to review https://github.com/w3c/web-platform-tests/pull/2926 ? since you LGTMed the spec change 🙂 |
| 19:27 | <annevk> | zcorpan: tomorrow I suppose |
| 19:27 | <zcorpan> | ok thanks |
| 23:16 | <sicking> | jsbell: ping |
| 23:16 | <jsbell> | sicking: what's up? |
| 23:17 | <sicking> | jsbell: does Chrome support getting a DirectoryEntry from <input type=file>/<input type=directory> or some such? |
| 23:17 | <jsbell> | sicking: yes. Edge is not planning to implement that though. |
| 23:17 | <sicking> | jsbell: What's the syntax? |
| 23:18 | <jsbell> | sicking: https://docs.google.com/document/d/14fCaoRf5GtdhMwJOVjcQSMDm_varTluyMq8RYyHR8vw/edit |
| 23:18 | <jsbell> | HTMLInputElement has webkitEntries |
| 23:18 | <jsbell> | But only populated by D&D onto an input, not via clicking |
| 23:19 | <sicking> | jsbell: oh, "but only populated via drag&drop"?? |
| 23:19 | <jsbell> | Yeah, we're awesome apparently. |
| 23:19 | <sicking> | why does that restriction exist? |
| 23:20 | <sicking> | jsbell: that sounds like just a bug? Or is it intentional? |
| 23:21 | <jsbell> | sicking: predates me, so I don't know for certain. probably just never implemented, since D&D is a very different code path than selection via dialog |
| 23:21 | <sicking> | i suspect that if we go down the DirectoryEntry route, that we'll go all the way and implement it on <input type=file> as well. But fully through click as well |
| 23:21 | <sicking> | jsbell: i see |
| 23:21 | <jsbell> | sicking: I added use counters to try and see if it's used |
| 23:21 | <jsbell> | But data isn't in yet |
| 23:21 | <sicking> | ok |
| 23:22 | <jsbell> | sicking: if Edge doesn't implement and it isn't used maybe we can remove. Don't know yet |
| 23:22 | <sicking> | jsbell: remove what part? input.webkitEntries? |
| 23:22 | <jsbell> | yes |
| 23:22 | <sicking> | why remove that? If we're going down the DirectoryEntry path, shouldn't we make it work well? |
| 23:24 | <jsbell> | just reducing surface area overall; restrict the Entry stuff to D&D, keep input restricted to Files w/ webkitRelativePath and implied structure |
| 23:24 | <jsbell> | But I'm not firmly against, just trying to figure out what is *necessary* |
| 23:25 | <jsbell> | I'm also just starting on a spec (like, created index.bs yesterday) for the Entry stuff, i.e. a subset of [[file-system-api]] |
| 23:27 | <jsbell> | sicking: not pushed anywhere yet, I'll ping when it's more than a skeleton. |
| 23:28 | <sicking> | jsbell: i think both microsoft and mozilla want to have an API that doesn't require sync IO and which enables directory picking |
| 23:28 | <sicking> | jsbell: i feel like if we go with DirectoryEntry for d'n'd, we should do the same for directory picking as well |
| 23:29 | <jsbell> | that's entirely reasonable, and no objection from me |
| 23:29 | <sicking> | cool |
| 23:30 | <Domenic> | jsbell: does that mean we can assign https://github.com/whatwg/html/issues/217 to you? :) |
| 23:33 | <jsbell> | Wheee. :) |