| 00:13 | <Hixie> | any |
| 00:13 | <Hixie> | er |
| 00:13 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#the-img is the starting point for my <img>/alt="" redesign |
| 00:13 | <Hixie> | work in progress |
| 00:35 | <jruderman> | interesting, the alt attribute is no longer required and having no alt now has a specific meaning |
| 00:37 | <jruderman> | "The download of the image must delay the load event." might put one variant of the intranet-port-scanning attack into spec, but i'm not sure if you want to be trying to prevent that attack |
| 00:37 | <jruderman> | speaking of specs and security |
| 00:38 | <jruderman> | are you interested in possible changes to the same-origin policy? |
| 00:38 | <jruderman> | some people think IP addresses should become part of origin (along with hostname, protocol, and port) |
| 00:40 | <h3h> | my guess is that would break sites (mostly intranet) and Microsoft would be reluctant at best |
| 00:40 | <h3h> | but that's just a guess |
| 00:42 | <jruderman> | won't TCPConnection allow malicious web pages to get around the "servers should check the Host header" solution to DNS rebinding attacks? |
| 00:42 | <othermaciej> | the TCPConnection from HTML5? |
| 00:43 | <othermaciej> | I think it would be hard to use it to connect to an http server |
| 00:43 | <Hixie> | jruderman: (i'm not really here but if you could mail me your feedback ian⊙hc -- or to one of the lists -- that'd be great) |
| 00:43 | <jruderman> | oh, it's not allowed to connect to port 80? i guess that helps a little |
| 00:43 | <othermaciej> | but yes, the protocol itself would itself be vulnerable to DNS rebinding |
| 00:43 | <othermaciej> | jruderman: no, it uses a wacky custom protocol and requires a particular handshake |
| 00:44 | <othermaciej> | jruderman: you're not supposed to be able to actually use it to connect to any existing network service |
| 00:44 | <jruderman> | oh, neat |
| 00:44 | <othermaciej> | although the way it enforces this is pretty weak |
| 00:44 | <othermaciej> | the protocol itself could be subject to DNS rebinding, like I said |
| 00:46 | <jruderman> | it looks like it tries not to be, by making both sides send the hostname(?) |
| 00:48 | <Hixie> | that's the source domain, but yes, that's intended to mitigate the problem partly |
| 00:48 | <Hixie> | the idea of having the IP in the origin might work |
| 00:48 | <Hixie> | though it would cause all kinds of issues in multi-homed sites like, say, google |
| 00:50 | <jruderman> | why are ports below 1024 and ports >= 1024 treated differently? |
| 00:50 | <Hixie> | i recommend starting a thread on whatwg⊙wo about the origin idea |
| 00:50 | Hixie | looks at the spec |
| 00:51 | <Hixie> | oh it's to try and avoid people abusing services by connecting to services and faking the protocol |
| 00:51 | <Hixie> | in case the handshake isn't good enough |
| 00:51 | <Hixie> | to stop that |
| 00:52 | <jruderman> | i think it would be good to specify wraparound behavior for port numbers (or lack of wraparound behavior), since many apps have wraparound behavior without intending to have it |
| 00:52 | <Hixie> | what is "wraparound behaviour"? |
| 00:52 | <jruderman> | port 65616 = port 80 |
| 00:52 | <jruderman> | wouldn't want someone to be able to get around the "no port 80 connections" rule that way |
| 00:53 | <Hixie> | the spec already defines that |
| 00:53 | <Hixie> | it says to raise an exception |
| 00:54 | <jruderman> | oh, i read the whole "the port argument is neither equal to 80, nor equal to 443, nor greater than or equal to 1024 and less than or equal to 65535," sentence backwards |
| 00:55 | <jruderman> | it *only* allows connections on port 80, 443, and 1024..65535? |
| 00:55 | <jruderman> | why allow ports 80 and 443? the TCPConnection protocol isn't http or https... |
| 00:56 | <Hixie> | to tunnel out of fascist regimes |
| 00:56 | <Hixie> | basically |
| 00:56 | <jruderman> | hehe, ok |
| 00:56 | <Hixie> | (many sites proxy port 80, and block everything else, so the only way out is 443) |
| 00:57 | <Hixie> | note that othermaciej and others have quite low opinions of this section |
| 00:57 | <jruderman> | ok |
| 00:57 | <Hixie> | personally i'm not sure what to replace it with if we remove it -- the usual suggestion (embedding the whole http stack into this) is not one i feel is plausible |
| 00:58 | <Hixie> | but i guess i need to draw up the requirements/problem space to see what else could address it (and to show if/why http doesn't handle it) |
| 00:58 | <Hixie> | i think notwithstanding the abuse of ports 80 and 443, and not withstanding the fact that it's Yet Another custom protocol, it actually is pretty neat |
| 00:59 | <Hixie> | but those two things are the main things people have against it, and i don't have good answers to those concerns |
| 01:02 | <Hixie> | i've added notes about the two security attacks you mentioned -- rebinding and ip in origin, and port scanning through load events -- to the spec and will look at them in due course. |
| 01:03 | <Hixie> | now i'm really going offline -- bbl. feel free to e-mail the list on things you see, especially security issues. |
| 13:27 | <Philip`> | HTML5 parsing is incompatible with IE and Opera on http://www.gerv.net/security/content-restrictions/ - it doesn't think half the page is blue |
| 13:31 | <Dashiva> | Philip`: A little bit more detailed? |
| 13:33 | <Dashiva> | Do you mean the unclosed span causing long runs of blue text? |
| 13:33 | <Philip`> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20HTML%3E%3Cp%3E%3Cspan%20style%3D%22color%3Ablue%22%3EA%3C/p%3E%3Cp%3EB is about what that page does |
| 13:33 | <Philip`> | Yes |
| 13:36 | <Philip`> | Firefox/Safari/HTML5 put the B outside the span, Opera/IE put it inside |
| 13:36 | <Dashiva> | I'm more concerned about P being a descendant of another P |
| 14:29 | <hendry> | does anything use <link rel='archives' title='July 2007' type html? googlebot? |
| 15:35 | zcorpan | is now back in sweden |
| 15:58 | <zcorpan> | anyone who has written an html parser: is it faster to parse quoted attributes or unquoted attributes, or indifferent? |
| 15:59 | <zcorpan> | Hixie: ^ |
| 15:59 | <zcorpan> | hsivonen: ^ |
| 16:30 | <mpt> | hendry, iCab? :-) |
| 16:40 | <Philip`> | zcorpan: Quoted should be theoretically a tiny bit faster for long attribute values, since you don't need to keep checking for whitespace, but maybe a tiny bit slower for short values since the quotes mean there are more characters to process, but I think that's all trivial and irrelevant compared to all the other costs (of getting input characters in the first place, of constructing attribute value strings, etc) |
| 16:45 | <Philip`> | The extra 2 bytes for a quoted attribute, if you're downloading a web page at 100KB/sec, would take about 20 microseconds, which is about 40,000 CPU cycles, so a few extra comparison instructions won't be at all significant |
| 16:45 | <Philip`> | ((unless you're writing in Python or something where a comparison might be closer to being that expensive)) |
| 17:56 | <zcorpan> | Philip`: what's the difference between checking for whitespace and checking for the closing quote character? whitespace can be several different characters? |
| 17:58 | <Philip`> | It's just a few more values to check for - unquoted needs to detect 9/10/11/12/32/38/62/EOF, double-quoted only needs to look for 34/38/EOF, so you'd usually need a few more comparisons in the unquoted case |
| 17:59 | <zcorpan> | yeah, ok |
| 18:02 | <Philip`> | I don't think it's an especially compelling reason to use HTML instead of XHTML :-) |
| 18:16 | <zcorpan> | Philip`: oh, i was just surprised that mskinner's implementation experience suggested that parsing quoted attributes would be "MUST faster" than unquoted |
| 18:16 | <zcorpan> | http://forums.whatwg.org/viewtopic.php?t=93#395 |
| 18:36 | annevk | is in Spain without luggage |
| 18:44 | annevk | looks at <img> redesign |
| 18:45 | annevk | notes that <audio> prolly needs a note about its constructor too |
| 18:48 | annevk | reads molly's rant |
| 18:48 | annevk | notes that #whatwg is the new twitter |
| 18:50 | annevk | reads the comments about people being frustrated by the WHATWG now it's suddenly in the W3C |
| 18:51 | annevk | thinks the comments at http://www.molly.com/2007/08/11/dear-w3c-dear-wasp/ are quite hilarious given what has been said so far about headers= etc. on the public-html list |
| 18:52 | tantek | reads about annevk reading molly's rant and goes to read molly's rant. |
| 18:52 | takkaria | wonders what all the fuss is about |
| 18:53 | <tantek> | takkaria, a disconnect between those that hold meetings, their topics/agendas, and those that work in the field day-to-day, their real-world challenges and desired solutions. |
| 18:56 | <takkaria> | heh |
| 18:57 | <takkaria> | since when has WHATWG been a semi-secret society? |
| 18:59 | <tantek> | takkaria, it is a general trolling technique |
| 19:01 | <tantek> | often used by bureaucracy trolls: http://tantek.pbwiki.com/TrollTaxonomy#Bureaucraytroll |
| 19:02 | <takkaria> | semi-secret in the sense of "public". :) |
| 19:02 | <takkaria> | I wonder when MS will send feedback on the current spec |
| 19:05 | <takkaria> | nice taxomony, there |
| 19:23 | <Philip`> | zcorpan: Maybe quoted vs unquoted matters more if you're writing an actual SGML-like HTML4 parser, since that's much more particular than HTML5 about what characters are allowed in unquoted values |
| 19:24 | <zcorpan> | Philip`: so what would you do when you hit a character that is not allowed? |
| 19:27 | <Philip`> | Given what the W3C validator does, you sometimes start reading a new attribute name that begins with the non-allowed character |
| 19:27 | <Philip`> | (at least for <div class=foo'bar></div> - but it seems different for <div class=foo#bar></div> since that just complains about an invalid character inside the value) |
| 19:28 | <zcorpan> | crazy |
| 19:28 | zcorpan | assumes that sgml doesn't define what to do |
| 19:28 | <hasather_> | zcorpan: SGML has no defined error handling |
| 19:29 | <zcorpan> | hasather_: it has some |
| 19:29 | <hasather_> | like? |
| 19:29 | <zcorpan> | hasather_: e.g., </foo in a cdata element closes the element but is an error if the end tag doesn't match the start tag |
| 19:30 | <zcorpan> | not sure if there are others |
| 19:45 | <hasather_> | zcorpan: yes, so the error there is that is that the end tag doesn't match the start tag. But SGML doesn't define what to do in that case |
| 19:50 | <zcorpan> | hasather_: i thought it did (namely close the element anyway) |
| 19:54 | <hasather_> | zcorpan: it says that the first end-tag delimiter-in-context (i.e. ETAGO followed by a name start character) closes the element. |
| 19:55 | <zcorpan> | hasather_: yes, exactly |
| 19:58 | <zcorpan> | but yeah, i guess you could argue that it doesn't say if you should do something different in case it is an error |
| 20:12 | <tantek> | takkaria, thanks. Also, I have attempted to add a rational response to the comments on molly's post: http://www.molly.com/2007/08/11/dear-w3c-dear-wasp/#comment-610009 |
| 20:15 | <takkaria> | tantek: I tried that a while ago. never seems to do much, but I suppose one has to try |
| 20:16 | <tantek> | rationality is worth persistence |
| 20:18 | <tantek> | i'm actually optimistic that accessibility "advocates" can and will adopt more purely rational/scientific approaches to their advocacy, thus build stronger, more appealing cases for accessibility, which more will then listen to, which will hopefully result in more accessibility in technologies, tools, etc. |
| 20:21 | <tantek> | here is an example of such a rational/scientific approach in progress, thanks largely to James Craig and a few other accessibility advocates: http://microformats.org/wiki/assistive-technology-abbr-results |
| 20:21 | takkaria | takes a look |
| 20:21 | <takkaria> | I was optimistic for a while, maybe it'll return now public-html has calmed down a little |
| 20:21 | <tantek> | it's not perfect, but it's a huge step in the right direction in terms of approach etc. |
| 20:24 | <takkaria> | yeah, that looks pretty good |
| 20:25 | <tantek> | we have to work on reducing the use of negative/personal rhetoric as a method of discourse - it doesn't help anybody |
| 23:39 | <othermaciej> | Molly's post is confusing |
| 23:39 | <othermaciej> | I'm not sure which things she thinks are a problem or why |
| 23:40 | <takkaria> | it seemed a bit of an undirected rant to me |
| 23:43 | <othermaciej> | actually it sounds like a Microsoft enemies ist |
| 23:43 | <othermaciej> | *list |
| 23:43 | <othermaciej> | this might be an accident |
| 23:44 | <othermaciej> | but I know that Microsoft is against many advanced features in HTML5, against the new ECMAScript standards process, and against AIR |
| 23:44 | <takkaria> | AIR? |
| 23:44 | takkaria | is new around these parts |
| 23:45 | <othermaciej> | it's the Adobe Flash+HTML for local apps thing |
| 23:45 | <mgdm> | http://en.wikipedia.org/wiki/Adobe_AIR |
| 23:47 | <takkaria> | ah, right. last I heard, it was still Apollo |
| 23:48 | <takkaria> | is that MS as a company that's against them, or the IE team against them? |
| 23:48 | mgdm | is very new around these parts, hello everyone |
| 23:52 | <webben> | I think folks would benefit from waiting for Molly to clarify her post (or asking her too) rather than trying to guess what she means. |
| 23:53 | <webben> | othermaciej: Is there some document somewhere that explains how the standards process has changed? I wasn't aware it had. |
| 23:53 | <othermaciej> | takkaria: MS is against them because it encroaches on (a) native windows app development with win32 or .NET and (b) Silverlight |
| 23:54 | takkaria | nods |
| 23:54 | <takkaria> | that's pretty much why they're being added, so I'm not suprised, really |