| 01:58 | <jcranmer> | hmm, still asks for password |
| 08:17 | <hsivonen> | Validator.nu now builds on Windows but running it requires deleting the HTML 4 / XHTML 1.0 -related lines from validator/presets.txt |
| 08:53 | <hsivonen> | the EOT thread took an interesting turn... |
| 09:39 | <zcorpan> | silli's both doctypes trigger quirks in O9.6 |
| 11:45 | <zcorpan> | tthorsen: <select>TITLE</select> is what you get in ie |
| 11:58 | <tthorsen> | really? I hadn't tested IE |
| 11:58 | <tthorsen> | So that's consistent with the html 5 specification, but does it make sense? |
| 12:01 | <takkaria> | I imagine very few sites rely on its behaviour, so it doesn't matter so much what happens to it, I guess |
| 12:01 | <hsivonen> | tthorsen: compat is more important than making sense |
| 12:02 | <zcorpan> | tthorsen: see /topic :) |
| 12:03 | <tthorsen> | of course, but in this case everyone does it differently. Isn't that an opportunity to pick the behaviour that makes the most sense? |
| 12:03 | <takkaria> | tthorsen: fwiw, your latest problem with the parsing algorithm is fallout from splitting CDATA/RCDATA processing into its own insertion mode |
| 12:04 | <hsivonen> | tthorsen: of the behaviors available, I prefer just doing the IE thing here |
| 12:04 | <hsivonen> | tthorsen: with my validator developer hat on, I want to avoid non-streamable recovery where possible given compat |
| 12:05 | <zcorpan> | hsivonen: ignoring the characters is certainly streamable |
| 12:05 | <hsivonen> | zcorpan: right. but I don't want to move stuff to head any more than absolutely necessary |
| 12:06 | <zcorpan> | hsivonen: ah |
| 12:06 | <zcorpan> | i thought you were talking about select |
| 12:06 | hsivonen | thought moving to head was one of the options discussed |
| 12:06 | <hsivonen> | I guess I'm not properly in sync with what's being discussed |
| 12:07 | <tthorsen> | I only meant to suggest ignoring any cdata in select unless the current node is an option element. |
| 12:08 | <zcorpan> | which matches opera and mostly matches firefox |
| 12:09 | <takkaria> | zcorpan: are Opera implementing HTML5 parsing, do you know |
| 12:09 | <jgraham> | I would be happy with that fwiw |
| 12:09 | <takkaria> | +? |
| 12:10 | <zcorpan> | takkaria: not yet, alghough we are aligning our current parser |
| 12:10 | <zcorpan> | although |
| 12:10 | <zcorpan> | hmm.. <select><style> and <select><script> |
| 12:11 | <zcorpan> | or at least the latter |
| 12:11 | <jgraham> | hsivonen: How far have you got in making the validator.nu parser talk to gecko? |
| 12:11 | <zcorpan> | the script is inserted in all top-4 browsers |
| 12:13 | <hsivonen> | jgraham: the parser core translates to C++ and compiles against NSPR/XPCOM types. It doesn't talk to Gecko yet. Right now, I'm working on the entity table generator. |
| 12:13 | <zcorpan> | <style> works in webkit and firefox |
| 12:13 | <hsivonen> | jgraham: So no progress since the start of TPAC |
| 12:15 | <jgraham> | hsivonen: Sounds cool. I didn't know what you'd done before TPAC either |
| 12:15 | <hsivonen> | I made a detour into Jing development |
| 12:16 | <hsivonen> | James Clark made a comeback since a 5-year hiatus, so I figured I should get my changes merged upsteam now that the project is under active development |
| 12:16 | <malware> | hsivonen: cool to hear that you now have commit access to the upstream Jing sources |
| 12:17 | <hsivonen> | malware: yeah. Right now there's a validator-nu branch. the trunk isn't suitable for V.nu yet |
| 12:18 | <malware> | I see. well, regardless, I think this may be the first time in history that James has actually enabled collaborative development on any code he's currently working on |
| 12:30 | <malware> | re: messages from Tommy Thorsen indicating he's doing active development on a browser engine -- I assume for Kvaleberg -- makes me wonder how high they are aiming and what the business case is for building the engine in-house instead of just using WebKit |
| 12:30 | hsivonen | notes that thanks to all the Java eclipse goodness, it's nicer to write in Java and translate to C++ than to write in C++. |
| 12:30 | <zcorpan> | wow, tfoot, th etc break out of <select> in opera |
| 12:31 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cbody%3E%0D%0A%3Cscript%3E%0D%0Avar%20elms%20%3D%20%22a%20abbr%20acronym%20address%20area%20b%20base%20basefont%20bdo%20bgsound%20big%20blink%20blockquote%20body%20br%20button%20caption%20center%20cite%20code%20col%20colgroup%20comment%20dd%20del%20dfn%20dir%20div%20dl%20dt%20em%20embed%20fieldset%20font%20form%20frame%20head%20hr%20html%20h1%20h2%20h3%20h4%20h5%2 |
| 12:31 | <zcorpan> | 0h6%20i%20input%20iframe%20ilayer%20img%20inlineinput%20ins%20kbd%20keygen%20label%20layer%20legend%20li%20link%20listing%20map%20marquee%20menu%20meta%20multicol%20nextid%20nobr%20noembed%20noframes%20nolayer%20noscript%20object%20ol%20optgroup%20option%20p%20param%20plaintext%20pre%20q%20rt%20ruby%20s%20samp%20script%20select%20small%20sound%20spacer%20span%20spell%20strike%20strong%20style%20sub%20sup%20table%20tbody%20td%20textarea%20tfoot%20 |
| 12:31 | <zcorpan> | th%20thead%20title%20tr%20tt%20u%20ul%20var%20wbr%20xmp%22.split(%22%20%22)%3B%0D%0Avar%20div%20%3D%20document.createElement('div')%3B%0D%0Avar%20current%3B%0D%0Afor%20(var%20i%20%3D%200%3B%20i%20%3C%20elms.length%3B%20%2B%2Bi)%20%7B%0D%0A%20%20current%20%3D%20div.cloneNode(false)%3B%0D%0A%20%20current.innerHTML%20%3D%20elms%5Bi%5D%20%2B%20'%3Cselect%3E1%3C'%20%2B%20elms%5Bi%5D%20%2B%20'%3E2%3C%2F'%20%2B%20elms%5Bi%5D%20%2B%20'%3E3%3C%2Fselect%3E |
| 12:31 | <zcorpan> | '%3B%0D%0A%20%20document.body.appendChild(current)%3B%0D%0A%7D%0D%0A%3C%2Fscript%3E |
| 12:31 | <zcorpan> | oops |
| 12:32 | <zcorpan> | ie inserts unknown elements |
| 12:34 | <zcorpan> | #text: 12</plaintext>3</select> |
| 12:34 | <zcorpan> | interesting |
| 12:35 | <zcorpan> | <table> breaks out of <select> in ie |
| 12:36 | <zcorpan> | and all other table elements |
| 12:39 | <zcorpan> | <select><plaintext> is certainly funny in webkit and ie |
| 12:41 | <Philip`> | Lots of people put <script>s and <br>s inside <select> |
| 12:41 | <tthorsen> | the <script> I can understand, but what's the <br> supposed to do? |
| 12:42 | <zcorpan> | <br> doesn't do anything |
| 12:42 | <Philip`> | Don't ask me to make sense of the web :-) |
| 12:42 | <Philip`> | Also lots of comments in there |
| 12:43 | <zcorpan> | not <style>? |
| 12:43 | <zcorpan> | or <td> |
| 12:43 | <Philip`> | and an <a> (on http://www.dahmen-quilt.com/) |
| 12:44 | <Philip`> | zcorpan: None that I see, when grepping some thousands of pages and looking through the output manually |
| 12:44 | <zcorpan> | <table><td><select><td> |
| 12:45 | <zcorpan> | oh the spec has in table in select |
| 12:45 | <Philip`> | http://www.inmobiliariaportilla.com/ has a <select><font> |
| 12:45 | <Philip`> | and http://www.roommatelocator.com/ has a <select></font> |
| 12:46 | <Philip`> | http://www.rentjillshouse.com/ has a <td><select></td> |
| 12:47 | <zcorpan> | it seems the spec needs to fix <select><script> |
| 12:48 | zcorpan | files a bug |
| 12:48 | <krijnh> | Yay, more mail :) |
| 12:52 | <zcorpan> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=6216 |
| 12:53 | <Philip`> | http://www.keysmusic.co.uk - <select><ul> |
| 12:55 | <zcorpan> | <isindex> "works" in select in ie |
| 13:04 | <tthorsen> | zcorpan: fwiw, my preliminary fix for scripts in selects will be to do exactly what we do in "in body", which is: 'Process the token using the rules for the "in head" insertion mode.' |
| 13:05 | <zcorpan> | sounds reasonable |
| 13:05 | <tthorsen> | works for my simple test, too |
| 13:12 | <jgraham> | tthorsen: Are you using the html5lib test suite? |
| 13:16 | <tthorsen> | I do test markup with it from time to time, but I'm not using it very much. |
| 13:17 | <tthorsen> | Oh. I read you wrong. I've run our engine through some of the tests in the test suite, but not all |
| 13:18 | <tthorsen> | I don't have anything automated, so it would take me a long time to try them all. |
| 13:18 | <jgraham> | OK, just wondering becuase if you have new tests that yu can release under the MIT license it would be great to add them to the test suite |
| 13:20 | <zcorpan> | hmm anne and i wrote a browser runner for the html5lib tests before |
| 13:20 | <tthorsen> | ah, no I'm afraid most of our testing consists of proprietarily licensed tests and testing real-world web sites |
| 13:20 | <zcorpan> | dunno where it is |
| 13:23 | <jgraham> | http://html5.org/parsing-tests/testrunner.htm |
| 13:24 | <takkaria> | tthorsen: you should run against the html5lib test suite anyway, it's very useful |
| 13:24 | <takkaria> | picked up dozens and dozens of issues when I was hacking on hubbub (a C html5 parsing library) |
| 13:25 | <tthorsen> | yeah. I did find a bunch of bugs last time I ran a few of them |
| 13:26 | <takkaria> | actually, I have a bunch of character-encoding tests that I should contribute back to html5lib |
| 14:33 | <yecril71> | The problem of external pages sniffing the content of |
| 14:33 | <yecril71> | intranet files, or just some characteristics of it, |
| 14:33 | <yecril71> | is similar to the problem of Web sites loading |
| 14:33 | <yecril71> | local resources via the file URL scheme, |
| 14:34 | <yecril71> | only that now the URL scheme is not a distinguishing feature. |
| 14:34 | <yecril71> | Should such limitations be ever implemented, the exact behaviour |
| 14:35 | <yecril71> | should depend on the Internet zone of the embedding document, |
| 14:35 | <yecril71> | just as with XMLHTTPRequest. |
| 14:36 | <yecril71> | For example, Internet sites should not be allowed |
| 14:36 | <yecril71> | to get information about intranet content |
| 14:36 | <yecril71> | or load it. |
| 14:53 | <takkaria> | Internet zoning an IE concept, though, not a concept of the Web per se |
| 15:12 | <yecril71> | Interet zoning is a concept that is adequate to the situation of the question. |
| 15:13 | <yecril71> | Which is unintentionally leaking internal data, which is not a concept of the Web either. |
| 15:25 | <takkaria> | well, yes, but it's something best brought to the attention of browser developers and not mentioned in passing on an IRC channel :) |
| 15:29 | <Philip`> | The same-origin security restrictions are needed to avoid providing ways around any firewall restrictions, not just for the internet/intranet divide |
| 15:37 | <yecril71> | Can you describe a situation when the data leak does not sit in the Intranet? |
| 15:39 | <yecril71> | And the purpose of this channel is to formulate recommendations for all browser developers |
| 15:39 | <yecril71> | where they feel the need to act in the same way. |
| 15:57 | <Philip`> | yecril71: There are lots of internet sites where access is restricted to certain IPs, e.g. I can access various academic papers if I'm using my university's internet connection, and it would be a data leak if someone else on the internet could access those resources via my browser |
| 16:25 | Lachy | is surpised by what they call a continental breakfast over here in the US. There wasn't even any toast! |
| 16:29 | <MikeSmith> | Lachy: "continental" is this case is a euphemism for "miniscule" |
| 16:31 | <Philip`> | Where "minuscule" is a euphemism for "not all-you-can-eat pancakes"? |
| 16:34 | <MikeSmith> | eating lots of pancakes is a great way for visitors to fit in with America life, by helping them to reach the typical "American size" (euphemism for "fat") |
| 16:35 | jmb | so failed at that last week |
| 16:36 | <MikeSmith> | follow up your pancake breakfast with a stop by AM/PM to get a 32-ounce Coca-Cola, and in the evening, enjoy a great movie at the cinema while eating popcorn for a container the size of a garbage pail |
| 16:38 | <jcranmer> | continental = coffee + donuts, in my experience |
| 16:38 | <jcranmer> | often times OJ as well; if you're lucky, you'll find a waffle machine |
| 19:02 | <hsivonen> | Hixie: the single-page version of the spec links to itself instead of the multipage version |
| 19:06 | <takkaria> | Leif has high hopes for web developers |
| 19:07 | <Lachy> | there doesn't really seem to be very much interesting sessions for me to attend today at pubcon. It's all about marketing :-( |
| 19:07 | <Lachy> | I might skip some sessions today and go explore Vegas |
| 19:08 | <blooberry> | lachy: a tuesday in November should be a pretty good time to do that. How are the throngs? And the weather? |
| 19:09 | <Lachy> | the weather is good today |
| 19:09 | <Lachy> | what are "throngs"? |
| 19:09 | <blooberry> | I was there last year at the end of november and it was great weather except for a torrential downpour that the Las Vegas drainage system seemed ill-equipped to handle |
| 19:09 | <blooberry> | throngs = the crowds |
| 19:09 | <Lachy> | in what language? |
| 19:10 | <blooberry> | english 8-} http://dictionary.reference.com/browse/throng |
| 19:12 | <Lachy> | ok |
| 19:13 | <blooberry> | what parts of vegas interest you? and are you on the strip? (if so, which end) |
| 19:13 | <Lachy> | I'm at the Las Vegas Convention Center |
| 19:13 | <Lachy> | it's not too far from the strip |
| 19:15 | <Lachy> | I have to go to some of the casinos later. Where exactly is the strip? |
| 19:16 | <Lachy> | http://maps.google.com/maps?f=q&hl=en&geocode=&q=3150+Paradise+Road,+Las+Vegas,+NV+89101&sll=36.128516,-115.162833&sspn=0.01409,0.021479&ie=UTF8&z=17&g=3150+Paradise+Road,+Las+Vegas,+NV+89101&iwloc=addr |
| 19:16 | <Lachy> | that's the map of the convention centre |
| 19:17 | <blooberry> | Once you get to the strip, there's a shuttle you can take up/down the strip. It is much longer than the maps make them look |
| 19:18 | <blooberry> | that's because all the hotels are soooo damn huge. Takes forever to get from one end of one to another. |
| 19:19 | <Lachy> | I'll probably go there later in the week, if not tonight, and gamble all my life savings away |
| 19:19 | <Lachy> | this session is over. I'm going to pack up and go. CYA |
| 19:19 | <blooberry> | woohoo! 8-} |
| 19:19 | <blooberry> | k. |
| 19:41 | Philip` | guesses that "pubcon" is not a con about pubs |
| 19:43 | <Philip`> | blooberry: Is the strip longer than it looks in GTA:SA? |
| 19:44 | <gsnedders> | Touché, Philip`. |
| 19:44 | <gsnedders> | But there again, that's the best I have to go by too. |
| 19:44 | <Philip`> | ? |
| 19:44 | hsivonen | thought San Andreas was Los Angeles, not Las Vegas |
| 19:45 | <Philip`> | hsivonen: It's Los Angeles, San Francisco and Las Vegas |
| 19:45 | <gsnedders> | hsivonen: LA, SF, and LV |
| 19:45 | gsnedders | can't type quickly enough yet on this Dvorax keyboard |
| 19:45 | <gsnedders> | *Dvorak |
| 19:46 | <Philip`> | Dvorax sounds like the leader of a quite nasty alien species |
| 19:46 | <hsivonen> | ah |
| 19:46 | <gsnedders> | Philip`: Just using GTA as a reference :) |
| 19:47 | <hsivonen> | hrm. the entity table has lost line breaks since I last tried to scrape it |
| 19:47 | <gsnedders> | That has nothing to do with me. |
| 19:50 | <hsivonen> | scraping HTML with regexps is so brittle... :-( |
| 19:51 | <Philip`> | It's a shame you don't have a better way of parsing HTML |
| 20:09 | <hsivonen> | http://ejohn.org/blog/css-animations-and-javascript/#comment-322033 |
| 20:10 | <hsivonen> | an outside-HTML5 case for using the event loop definition |
| 21:13 | <roc> | othermaciej: would you mind posting to the list to explain your position on cross-origin <video> loads? |
| 21:54 | <othermaciej> | roc: what more needs explanation? |
| 21:54 | <othermaciej> | roc: I said I think they should be supported |
| 21:54 | <othermaciej> | roc: I think the reasons why are obvious (you stated some of them) |
| 21:55 | <roc> | I guess I'm curious about which pros and cons carry weight with you and which don't |
| 21:56 | <roc> | obviously you're not concerned about information leakage from intranets, and I'd like to know why that is |
| 21:57 | <othermaciej> | I think leaking the size of files is not that huge a deal, at least if it is limited only to audio or video files |
| 21:59 | <roc> | ok |
| 22:00 | <roc> | What about duration? In the future, what about cue points? Caption data? |
| 22:01 | <othermaciej> | I think media plugins mean sites are already exposed to leaking that kind of information |
| 22:01 | <othermaciej> | well maybe not cue points or caption data as text embedded in the media file |
| 22:02 | <roc> | I'm torn over how much to weigh the media plugins argument. It's strong on its face, but on the other hand, being just as secure as plugins is kind of a low bar |
| 22:02 | <othermaciej> | I know, but this also isn't an area of plugin security people complain about |
| 22:03 | <othermaciej> | much as they don't complain that you can get width and height of a cross-site embedded image |
| 22:03 | <roc> | it's possible that's just because no-one's got around to figuring out how bad it is |
| 22:03 | <roc> | like clickjacking |
| 22:05 | <roc> | FWIW, Jonas and I were in favour of same-origin restrictions plus Access Control, but others aren't, and your opinion carries a lot of weight with me so now I'm totally unsure! |
| 22:05 | <Hixie> | i don't understand why people are even giving lip service to this ridiculous idea of inventing a new DRM format for fonts |
| 22:05 | <roc> | But I'd like Hixie to chime in since he filed that W3C bug |
| 22:05 | Hixie | looks up |
| 22:05 | <Hixie> | wassup? |
| 22:06 | <roc> | the question of same-origin restrictions for media elements |
| 22:07 | <Hixie> | my concern was caption data on intranet videos being made accessible in a future version of the spec, primarily |
| 22:07 | <roc> | ok |
| 22:07 | <Hixie> | (i don't want to have to introduce a "use access control because i want caption data" flag later) |
| 22:13 | <roc> | why would that flag be needed? Does Access-Control-Allow-Origin not come back unless we asked for it? |
| 22:18 | <hsivonen> | roc: have you analyzed how bad the safe part of the API would be if the unsafe parts of the API were turned off when loading cross-site without AC? |
| 22:18 | <roc> | it's not clear what is safe, really. |
| 22:19 | <roc> | is leaking the video size safe? The format? The duration? |
| 22:19 | <roc> | it's possible to imagine scenarios where each of these reveals something the intranet owner doesn't want revealed |
| 22:20 | <hsivonen> | I wonder if it's actually a good idea that MS has an intranet zone setting |
| 22:20 | <hsivonen> | (I've always thought it was a bad idea) |
| 22:20 | <roc> | it's helpful in some ways |
| 22:20 | <roc> | I don't know we'd want to rely on it |
| 22:31 | <hsivonen> | Hixie: do you count a font-specific compression scheme without root strings as DRM? |
| 22:33 | <hsivonen> | Hixie: <devilsadvocate>Is JPEG DRM when a stock photo licenser allows distribution as JPEG but not as CMYK TIFF?</devilsadvocate> |
| 22:37 | <Philip`> | HTML5 parses "<code><pre>...</code></pre>..." badly - it puts the second piece of text inside <code>, unlike browsers, which breaks http://blogs.sun.com/bblfish/entry/rest_apis_must_be_hypertext (around the JSON example) |
| 22:38 | <Hixie> | roc: it would be needed if we allowed cross-site today and then had to disable access to captions when we introduced captions |
| 22:39 | <Hixie> | hsivonen: no, compression schemes (that can be supported by the platform) are fine |
| 22:39 | <Hixie> | hsivonen: no, that's just a license |
| 22:40 | <Hixie> | Philip`: send feedbackj |
| 22:40 | <Hixie> | back |
| 22:40 | <Hixie> | no j |
| 22:40 | <roc> | Hixie: when you say "a flag", you mean an internal flag defined in the spec that's set for cross-origin videos, or some kind of flag that has to be set by users? |
| 22:41 | <Hixie> | i meant a flag for developers to set to say "ok this video should be loaded with AC so that i can get the captions", but i see that wouldn't be the only way to do it; regardless, i'd not really want a mode in which half the API is disabled because of lack of AC |
| 22:42 | <Hixie> | so "both" |
| 22:44 | <roc> | ok |
| 22:44 | <roc> | can you fight it out with maciej and let me know the result? thanks |
| 22:44 | <Hixie> | hehe |
| 22:44 | <Hixie> | maciej doesn't want restrictions? |
| 22:45 | <roc> | he wants either "cross-origin loads allowed with no restrictions on API" or "cross-origin loads allowed but with a restricted API" |
| 22:45 | <Hixie> | ah |
| 22:45 | <Hixie> | does he have reasons? (/me pokes othermaciej) |
| 22:45 | <roc> | I probed him about that just before in the channel |
| 22:45 | <othermaciej> | I think requiring Access-Control for any cross-origin media embedding is too much a developer hardship compared to plugin-based solutions that handle this fine |
| 22:46 | <Hixie> | fair point |
| 22:46 | <Hixie> | so we'd need anne to introduce a third mode in AC |
| 22:46 | <Hixie> | that returns the content despite it failing an ac check |
| 22:47 | <Hixie> | but with a "disable dangerous apis" option |
| 22:47 | <Hixie> | though frankly i'm a little concerned about exposing intranet videos of any kind |
| 22:48 | <Hixie> | i mean, if someone tricked me into going to their site, and had prior knowledge of where we put videos of our important internal events, they could get information about how long our internal meetings were going for |
| 22:48 | <Hixie> | which is a good indication of whether things are healthy or not at the company |
| 22:48 | <Hixie> | well, dunno about good |
| 22:48 | <Hixie> | but it's an indication anyway |
| 22:49 | <Hixie> | not to mention they could determine things like what bitrate we were using, information that i wouldn't personally be comfortable leaking explicitly, so why would i want to leak it accidentally? |
| 22:50 | <othermaciej> | I also believe the perceived security risks are partially imaginary as no one even complains about the same behavior for plugins; I could see the future API risks but I think exposing some parts of the API only for same-origin or if AC check passes is a better compromise than limiting any video to same-origin/AC |
| 22:50 | gavin | can't imagine why anyone would be worried about leaking the bitrate of internal videos |
| 22:50 | <othermaciej> | I would perhaps feel differently if AC were already more widely deployed in the infrastructure so it were not seen as much of an authoring hardship relative to plugin-based solutions |
| 22:51 | <Hixie> | i certainly understand and sympathise with your position |
| 22:51 | <roc> | so do I |
| 22:52 | <roc> | I wonder if XHR will be enough to drive deployment of AC, or we'll be stuck in a chicken-and-egg situation |
| 22:55 | <hsivonen> | How common is it today with plug-in-based solutions that people have videos neither on same origin nor on a video-specializing site like youtube? |
| 22:55 | <hsivonen> | I wonder how onerous it would be to put AC on Akamai-hosted Stevenotes |
| 22:56 | <roc> | Getting this resolved is a super-high priority issue for us, by the way. We're shipping soon and if we're going to have restrictions, we need to implement them now, or we'll never be able to |
| 22:57 | <Hixie> | i don't think <video> uptake is going to be so fast that we couldn |
| 22:57 | <Hixie> | 't add restrictions in the next cycle |
| 22:57 | Hixie | looks at the API to see what is currently exposed |
| 22:58 | <Hixie> | dimensions, size, bit rate, bandwidth to hosting site |
| 22:58 | <Hixie> | and existence |
| 22:58 | <roc> | maybe you're right, we've already identified some sites that would break if we added same-origin restrictions right now, and that's only going to get bigger |
| 22:58 | <roc> | ^ but |
| 22:58 | <Hixie> | sure |
| 22:59 | <roc> | duration |
| 22:59 | <roc> | format |
| 22:59 | <Hixie> | format? |
| 22:59 | <roc> | yeah |
| 22:59 | <Hixie> | i don't think we expose format explicitly in the spec |
| 22:59 | <roc> | I think you can fake it using <source> elements and redirects |
| 22:59 | <Hixie> | true |
| 22:59 | <roc> | er |
| 22:59 | <roc> | no redirects, just use currentSrc |
| 23:00 | <doublec> | hsivonen, having media upload/download from a subdomain is quite common |
| 23:00 | <doublec> | which breaks without AC |
| 23:01 | <hsivonen> | doublec: ok |
| 23:06 | <Hixie> | i guess what we should do is not have cross-site restrictions for now, but when we add them to make it so that if there is AC metadata and it is negative, to block everything |
| 23:06 | <Hixie> | allowing opt-out of all video access, and opt-in to full metadata access |
| 23:06 | <Hixie> | defaulting to basically the current API set |
| 23:07 | <Hixie> | but we should be prepared to block that altogether if someone comes up with an unexpected attack vector |
| 23:08 | <roc> | ok |
| 23:08 | <roc> | so we'll leak all those things you mentioned, for media types? |
| 23:08 | <Hixie> | yeah |
| 23:08 | <doublec> | is it worth not exposing anything about the media until metadata loaded? |
| 23:08 | <doublec> | so progress events, etc don't get fired until after that? |
| 23:09 | <Hixie> | but if you disagree with that, or aren't comfortable with it, then implement AC, and then you'll make the de-facto decision be to have access limitations :-) |
| 23:09 | <Hixie> | and i'll spec that :-) |
| 23:09 | <Hixie> | that's the first mover advantage :-) of course the disadvantage is that you might have to change more later. |
| 23:09 | <roc> | like I said, there isn't even consensus within Mozilla |
| 23:10 | <Hixie> | doublec: what is fired so far? just loadstart and progress? |
| 23:10 | <doublec> | yes |
| 23:10 | <Hixie> | loadstart seems safe, since that'll fire regardless |
| 23:10 | <doublec> | so progress gives filesize, etc for example |
| 23:11 | <Hixie> | i could see omitting progress until you have the headers down, but you can't give the size until you have the headers anyway |
| 23:11 | <Hixie> | so you'd only be able to tell if the site was down or not |
| 23:11 | <Hixie> | which you can already tell using new Image() |
| 23:13 | <roc> | if we use a platform backend, we may not be able to tell whether it's a usable media file immediately after loading the headers |
| 23:18 | <Hixie> | i don't think exposing whether it's valid or not is a problem |
| 23:18 | <Hixie> | the concern is over not exposing that the file is not 404 until we've checked for AC headers |
| 23:37 | <roc> | we don't want to fire progress events before we know it's a media file |
| 23:37 | <roc> | and yes, we need to make sure that non-media files and 404s appear identically to the API user |