| 00:07 | AryehGregor | thinks he had a clever idea, but isn't sure |
| 00:07 | <AryehGregor> | The last time I thought I had a clever idea was onlyreplace, and that turned out to be fairly pointless. |
| 00:08 | AryehGregor | lets the list decide |
| 06:26 | <MikeSmith> | anybody know of any ABNF testing tools? |
| 06:27 | <MikeSmith> | I want to take a string and check it against an ABNF production to see it matches |
| 06:35 | <othermaciej> | you could try writing it as a yacc grammar |
| 06:35 | <othermaciej> | or as a regexp if it's a regular language |
| 06:38 | <MikeSmith> | I guess I could just generate a parser from it |
| 06:38 | <MikeSmith> | but that would kind of seem like overkill |
| 06:39 | <MikeSmith> | or I suppose I could even just read the ABNF spec to figure out what the production means |
| 11:42 | <zcorpan_> | text/x-html |
| 11:42 | <zcorpan_> | so that's where they got the name from |
| 11:44 | <virtuelv> | whatwg spec is quite an achievement |
| 11:44 | <virtuelv> | we have it freezing four browsers |
| 11:46 | <nessy> | lol |
| 11:46 | <nessy> | that's why I use the multipage version |
| 11:49 | <zcorpan_> | browsers suck |
| 11:50 | <Philip`> | virtuelv: Browser developers just need to implement better support for the HTML5 spec |
| 11:51 | <virtuelv> | Philip`: somehow I don't think that would've made the spec less freezy :-) |
| 11:52 | jgraham | wonders which browsers and how low a "freeze" threshold is for virtualv |
| 11:53 | <Philip`> | virtuelv: Supporting the spec involves not freezing on it, by (my) definition :-) |
| 12:13 | <gsnedders> | Hixie: Can you look at http://lists.w3.org/Archives/Public/public-html/2009Nov/0351.html ASAP? |
| 12:29 | <zcorpan_> | hmm... is it intended that this won't throw? window.postMessage('foo', '/'); |
| 12:30 | <zcorpan_> | and whether window.postMessage('foo', ''); throws depends on the first script's base url |
| 12:49 | <zcorpan_> | Philip`: i guess the multipage script shouldn't use "HTML5" for current-work |
| 12:50 | <zcorpan_> | Philip`: can it use the original title instead of hard-coding the title? |
| 12:59 | <Hixie> | gsnedders: assume i'll do what you suggested |
| 13:00 | <Hixie> | zcorpan_: why would '/' not throw but '' throw? |
| 13:01 | <zcorpan_> | Hixie: because resolving it relative to the first script's base URL ... results in a URL with a <host-specific> component that is neither empty nor a single U+002F SOLIDUS character (/) |
| 13:02 | <zcorpan_> | Hixie: ...for '' when the first script's base URL has a host-specific part other than '/' |
| 13:03 | <Hixie> | oh it's an origin? i forget. |
| 13:03 | <Hixie> | i thought it was the target url for some reason. |
| 13:03 | <zcorpan_> | yeah, the argument is targetOrigin |
| 13:03 | <gsnedders> | Hixie: k, thx |
| 13:06 | <zcorpan_> | Hixie: i filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=8490 about that |
| 13:13 | <Hixie> | k |
| 13:16 | <zcorpan_> | step 4 of postMessage is broken because of the above-mentioned bug (since it passes an unresolved string to "same origin", which assumes a resolved url, if i understand things correctly) |
| 13:17 | <Hixie> | k |
| 14:56 | <Hixie> | any opera people here? |
| 14:56 | <zcorpan_> | yep |
| 15:05 | <jgraham> | +1 |
| 15:10 | <gsnedders> | yep |
| 15:10 | gsnedders | is blatantly slow |
| 15:10 | <gsnedders> | But not as slow as payman. |
| 15:15 | <payman> | ok u proved ur point! |
| 15:15 | <payman> | +1 |
| 15:15 | <payman> | :p |
| 15:16 | <Hixie> | zcorpan_ won the prize |
| 15:16 | <Hixie> | since he replied first |
| 15:16 | <jgraham> | What, he quit first |
| 15:16 | <jgraham> | Oh |
| 15:16 | <jgraham> | Well he quit first too |
| 15:21 | <gsnedders> | Hixie: So, now you've established there are Opera people here… |
| 15:21 | zcorpan_ | has established that Hixie causes zcorpan's opera build to crash :P |
| 15:26 | <zcorpan_> | test |
| 15:26 | <zcorpan_> | yay, survived |
| 16:00 | <Dashiva> | AryehGregor: <span sandbox> seems like it would be foiled by the attacker just starting his content with '</span>', am I missing something? |
| 16:00 | <Philip`> | zcorpan_: Fixed <title> |
| 16:01 | <Philip`> | Dashiva: I thought the idea was you'd escape the user's text before outputting it |
| 16:01 | <Philip`> | so you'd get <span sandbox></span>... |
| 16:02 | <Dashiva> | That's the idea, but then that's the idea without @sandbox as well |
| 16:02 | <Dashiva> | And we all know how well that works |
| 16:03 | <Philip`> | Without @sandbox the browser wouldn't interpret the tag's content as (restricted) HTML that it should parse and render |
| 16:04 | <Dashiva> | Assume an author who doesn't actually understand sandbox, he's just heard about it and wants to use it |
| 16:05 | <Philip`> | If the author wants to display 'safe' HTML from users, today they'd have to find a large complex library that they don't understand, like html5lib's sanitizer or a zillion other libraries, and then pass the content through it and print it out |
| 16:06 | <Philip`> | With <span sandbox>, it'd be basically the same except they don't need a sanitizer library, they just need a good old plain HTML escape function, and the browser is responsible for proper sanitization |
| 16:09 | <Philip`> | (Most XSS holes seem to come from people forgetting about escaping entirely, and letting unrestricted user-generated content leak out, and we can't stop that; but the idea is to make it easier when people do want to properly display content safely) |
| 16:09 | <Dashiva> | I'm wondering if the apparently simplicity will lead to more people trying to do it (and thus more people doing it incorrectly, instead of not doing it at all) |
| 16:10 | <Dashiva> | The idea here seems to be "Author tests with markup, notices nothing renderering, goes to figure out how to do it properly, does it properly" |
| 16:11 | <Philip`> | I think someone suggested making the browser delete the content if it sees an unescaped " or ', so they should very quickly discover that they need to escape the content |
| 16:11 | <Dashiva> | That looks very similar to how well-formed XHTML is supposed to work, yet we get YSODs |
| 16:11 | <Philip`> | and the escaping is easy |
| 16:15 | <Philip`> | YSODs triggered by user-generated content are usually not due to the author forgetting to use their serialize-to-well-formed-XML function, they're due to the serialize-to-well-formed-XML function being really really hard to implement perfectly correctly |
| 16:16 | <Philip`> | Correctly escaping 5 ASCII characters is far easier |
| 16:17 | <Hixie> | doc="" only requires you to escape one (two for correctness, three (four?) for XML), which is why i kinda like that idea |
| 16:18 | <Philip`> | (I think I don't really mind XML draconianness as a concept, I just mind it when it's coupled with very complex rules (like forbidden ranges of characters and forbidden attribute values and forbidden strings of characters that are otherwise plain text etc)) |
| 16:19 | <Philip`> | <span sandbox> only requires you to escape one (<) too, I think |
| 16:19 | <Philip`> | (...in order to avoid attacks) |
| 16:39 | <Dashiva> | "omg interwebs collapsed" is an interesting bug tag |
| 17:08 | <hsivonen> | hmm. 3 Adobe reps have responded to the ISSUE 76 poll even though the chairs said they'd discount multiple replies from a single W3C Member |
| 17:10 | <Hixie> | they didn't say they'd discount multiple replies, they said they'd discount multiple identical replies. I haven't checked, but I assume the three reps each had different novel points that hadn't been raised before. |
| 17:10 | <hsivonen> | good point |
| 17:14 | <othermaciej> | what we said was if we count, all the reps from one company count as one vote, but we will also endeavor not to count that way at all |
| 17:15 | <jgraham> | othermaciej: Should we take Sam's statement that you should only vote if you intend to raise a FO should the vote not go your way seriously? |
| 17:19 | <jgraham> | (the specific quote is "What we are looking for is input from people within the group who seriously intend to take raise a formal objection, and the content of such objections.") |
| 17:26 | jgraham | guesses that later emails in that thread suggest that is not really the policy |
| 17:30 | <Dashiva> | It's an ideal |
| 17:34 | <jgraham> | It seems like the total opposite of an ideal |
| 17:34 | <jgraham> | Whatever that is. |
| 17:35 | <jgraham> | (because decisions should be made on the basis of the weight of evidence, not the willingness of people to flight through Process to get their way) |
| 17:36 | <jgraham> | *fight |
| 17:36 | <Dashiva> | Well, that's just according to your personal ideals |
| 17:39 | <Hixie> | what i find interesting so far is that the poll seems to suggest manu's change proposal didn't do a good job of conveying why people felt it should be split out, while tab's did convey why people felt it should not be split out |
| 17:39 | <Hixie> | it's not clear to me what this means about the process per se |
| 17:39 | <gsnedders> | It's a writing competition! |
| 17:40 | <jgraham> | Dashiva: Well it doesn't seem hard to make an argument that using weight-of-evidence will tend to lead to a good specification whereas basing decisions on the degree to which various people have sociopathic tendencies will typically not |
| 17:41 | <othermaciej> | jgraham: it would be good for those *would* raise a Formal Objection to state their intent, but per the rules of the poll itself, if you have any objection you feel is strong, you can state it even if you would not raise a Formal Objection after but instead would choose to move on |
| 17:41 | <jgraham> | (note: I am not suggesting any real people have sociopathic tendencies. I am just using the term to indicate a willingness to continue to escalate their objections in the face of overwhelming evidence to the contrary. I don't think it is quite the right term to use but there we go) |
| 17:42 | <jgraham> | s/their// |
| 17:43 | <Hixie> | othermaciej: wait so if we _di_ want |
| 17:43 | <Hixie> | er |
| 17:43 | <Hixie> | othermaciej: wait so if we _would_ raise an FO we _should_ comment even if our argument has already been made? |
| 17:45 | <othermaciej> | it hurts my brain a little to explain this, because the chairs did not see 100% eye-to-eye on this so we ended up with a slightly squishy policy |
| 17:45 | <jgraham> | (and s/evidence to the contrary/evidence that their viewpoint failed to be convincing to others/) |
| 17:46 | <Philip`> | othermaciej: The chairs should have had a poll to decide on a non-squishy policy |
| 17:46 | <othermaciej> | it's not forbidden to make repeat arguments, just not (generally) necessary; however, intent to raise a formal objection can be useful info |
| 17:46 | <othermaciej> | Philip`: turtles all the way down, eh? |
| 17:47 | <jgraham> | We should have a squishy chair. Then we could all sit on it and be comfortable |
| 17:47 | <Philip`> | It's fewer and fewer turtles as you go down, and it's less painful to get agreement between a handful of turtles than between several hundred turtles |
| 17:48 | <Philip`> | and that's less painful that getting agreement between ten million turtles |
| 17:48 | <Philip`> | *than |
| 17:48 | <Hixie> | personally i imagine that whether or not google would raise a formal objection would depend on the reasoning behind the resulting decision, whichever way it goes, as with everything else |
| 17:48 | <Hixie> | so it's hard to say ahead of time |
| 17:48 | <Philip`> | So, to cause maximum pain, we should avoid making a decision and let authors choose between RDFa and microdata |
| 18:01 | Hixie | wonders how to (or whether to) do <device> |
| 18:02 | <jgraham> | How would it work? |
| 18:02 | jgraham | doesn't follow DAP |
| 18:03 | <Hixie> | that's the question |
| 18:03 | <Hixie> | <device type=camera oncamera="myVideo.src = event.stream.URL"> is one option |
| 18:03 | <Hixie> | it shows a well |
| 18:03 | <Hixie> | that you click to get a window that lets you select a device |
| 18:04 | <jgraham> | So the point of <device> would be to give you browser-native UI? |
| 18:04 | <Hixie> | effectively "plugging" that device into the well |
| 18:04 | <Hixie> | a point, yes |
| 18:04 | <Hixie> | btu not click-jackable |
| 18:04 | <Hixie> | similar to <input type=file> |
| 18:05 | <Hixie> | (but not submittable) |
| 18:08 | <daedb> | Would <device> be able to handle joysticks/joypads? For web-based games and such... |
| 18:08 | <Hixie> | seems like those should just work, no? |
| 18:08 | <Hixie> | there's no security reason to make them not work as far as i can tell |
| 18:09 | <jgraham> | Hmm. I guess I would expect to have a device activated by an author-supplied UI element and a one of those dropdown bars that are fashionable these days |
| 18:09 | <Hixie> | doesn't scale |
| 18:09 | <jgraham> | Why? |
| 18:09 | <Hixie> | see public-device-apis for more discussion on that |
| 18:10 | <daedb> | I'm just curious because I don't know of any way to handle joypad input on a web page (unless you remap the buttons to keyboard buttons using Joytokey or other programs). |
| 18:10 | <jgraham> | Do you have a one irc message summary? |
| 18:10 | <Hixie> | http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0149.html |
| 18:10 | <othermaciej> | Hixie: how persistent is the permission grant? |
| 18:10 | <Hixie> | othermaciej: one of many questions |
| 18:10 | <othermaciej> | Hixie: also what types of devices are you imagining besides camera and microphone (if any)? wondering how much this generalizes |
| 18:10 | <Hixie> | further good questions :-) |
| 18:11 | <othermaciej> | if it was only camera and microphone I might just have <avinput> or <mediainput> or <videoinput>/<audioinput> instead of an apparently wildly general element |
| 18:11 | <Hixie> | jgraham: (also http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0194.html) |
| 18:11 | <othermaciej> | but that depends on whether there are other kinds of devices and if they offer similar semantics, API and user experience |
| 18:11 | <Hixie> | indeed |
| 18:12 | <othermaciej> | for example - does <device type=disk> make sense? probably not |
| 18:12 | <othermaciej> | nor <device type=ethernet> |
| 18:16 | <Hixie> | <device type=media-player> might make sense, to enable syncing-like apps |
| 18:16 | <othermaciej> | what would that offer access to? |
| 18:17 | <Hixie> | e.g. to enable an iTunes-like app to sync music to a music player |
| 18:17 | <Hixie> | maybe it would expose a file system |
| 18:17 | <othermaciej> | I see, so it would expose an attached external media player? |
| 18:17 | <Hixie> | or maybe it would expose a websocket-like interface |
| 18:18 | <Hixie> | <device type=rs232> would enable many legacy apps to be ported to the web, too |
| 18:18 | <othermaciej> | it seems like by the time this is popular, your most likely media player choice would be something capable enough that you could sync through The Cloud(tm) |
| 18:19 | <othermaciej> | but I'm not sure Apple would fully expose iPhone/iPod media collections either to the browser on the device or to the browser on a machine tethered to the device |
| 18:19 | <Hixie> | no, indeed |
| 18:20 | <othermaciej> | (though the cloud syncing approach could work just by running your web app on both your computer and your phone/ipod/media player thingie) |
| 18:50 | <Hixie> | ms2ger is awesome |
| 18:50 | <Hixie> | if we do go with this <Device> idea |
| 18:51 | <Hixie> | i wonder whether to use a different event for each type |
| 18:51 | <Hixie> | or the same event with a complex event interface |
| 18:51 | <bumblebird> | hey Hixie, I wrote the post about WebSocket vs xhr last wk. |
| 18:51 | <Hixie> | hi |
| 18:51 | <bumblebird> | just saw your reply. Cool to know compression will be looked at later on, and sorry if the 'spec is insane' comment grated :) |
| 18:52 | <Hixie> | no worries :-) several people have said that, you're not alone. it's just annoying that most people who say that point to specs that i think are insane as examples of the right way to do things :-) |
| 18:53 | <bumblebird> | sure. I can't really remember a spec that I didn't think was overly verbose etc TBH, |
| 18:54 | <bumblebird> | do you happen to know of any other browsers with WebSocket support? I've seen some references to it being in firefox trunk, but can't quite find it yet |
| 18:54 | <Hixie> | firefox devs are working on it, don't think it's ready yet though |
| 18:54 | <Hixie> | webkit trunk has it |
| 18:54 | <bumblebird> | ah ok, cool |
| 18:54 | <bumblebird> | so it should make it into safari etc in due course I expect? |
| 18:54 | <Hixie> | depends on what happens to the spec, probably |
| 18:55 | <bumblebird> | there was a load of discussion on hackernews+irc about it. People complaining that it should just provide raw socket support |
| 18:56 | <bumblebird> | FWIW I think the spec is pretty solid. Compression is the only thing missing for me |
| 18:56 | <Hixie> | i think this is as close to raw sockets we'll ever get |
| 18:56 | <Hixie> | given the security issues |
| 18:56 | <bumblebird> | sure. I don't think raw sockets would be good. You'd end up with 50 js libs to do data framing etc |
| 18:57 | <bumblebird> | and this solves the use case of having a bidirectional pipe to a webserver just fine |
| 18:57 | <bumblebird> | some people complain whatever :) |
| 18:57 | <Hixie> | hah |
| 18:57 | <bumblebird> | and agreed @ security concerns |
| 19:04 | <Philip`> | Hmm... Possible <canvas> information leakage: Find a browser with optimised alpha=255 drawing routines. Draw a one-pixel section of a different-origin image lots of times and time it. Then you can work out which pixels are transparent and which are solid. |
| 19:05 | <Philip`> | and if the image is the text "Today's intranet password is: PAfqGK3Rc0PwhApe" encoded as a PNG with black text on a transparent background then that could be bad |
| 19:15 | <gsnedders> | Philip`: Man, you come up with some obscure edge cases |
| 19:19 | <Philip`> | It's probably less obscure with WebGL, where you could (I think) write a shader that runs an expensive loop iff the texture pixel is black |
| 19:31 | <Hixie> | can't you get data out of a shader other than timing effects? |
| 20:22 | <Philip`> | Hixie: No, as far as I'm aware |
| 20:23 | <Philip`> | The ability to extract data (other than via the output buffers) would be incompatible with the notion of automatic highly-parallel execution |
| 20:25 | <Philip`> | (I think things like CUDA let you write to something like system memory directly from the GPU, but normal shaders are just side-effect-free functions from input pixels and textures and constants to output pixels, I think) |
| 20:25 | <Philip`> | (I could think wrongly, of course) |