| 01:55 | <JonathanNeal> | So, the <header> element isn't necessary for the root <body> element, but can exist within <section> elements, is that right? |
| 01:56 | <MikeSmith> | JonathanNeal: yeah, it can be a child of a section |
| 01:56 | <MikeSmith> | and it's not required anywhere |
| 01:57 | <JonathanNeal> | Groovy, in the company-home demo, I noticed that the page's main navigation existed within the <header> element, is that recommended that the "global"-like navigation for a site exist within the <header> ? |
| 02:25 | <JonathanNeal> | Did that make sense. Maybe I asked the question poorly? |
| 02:42 | <JonathanNeal> | Either the question sucked, or MikeSmith took off. |
| 02:43 | <MikeSmith> | JonathanNeal: I'm still here |
| 02:44 | <MikeSmith> | just in a meeting at the moement |
| 02:44 | <MikeSmith> | moment |
| 02:44 | <MikeSmith> | what you describe sounds perfectly fine |
| 02:45 | <MikeSmith> | as far as the intended use of header and nav goes |
| 02:45 | <MikeSmith> | I think one of the examples in the spec actually does what you describe |
| 02:46 | <MikeSmith> | JonathanNeal: have you looked at the HTML5 spec itself? or are you working from one of the tutorials or articles? |
| 02:46 | <MikeSmith> | it's worth looking through the spec and the examples in it |
| 02:46 | <JonathanNeal> | I did, and I noticed a consistancy of the main <nav> being placed inside the <header> along with the <hgroup>/<h1>/etc |
| 02:53 | <MikeSmith> | JonathanNeal: that sounds the same as what you described above |
| 02:56 | <JonathanNeal> | Yes, basically ... the header inevitably contains my global heading, and I'm trying to intelligently group my outline, but the header element isn't part of the "outline algorithm", but navs do, but those navs don't have their own headers <h1> |
| 02:56 | <MikeSmith> | I see |
| 02:58 | <JonathanNeal> | <header><h1>My Site</h1><nav><ul><li>Page 1</li><li>Page 2</li></ul></header> ... trying to follow the spec, I don't feel sure whether or not I'm saying that the <nav> a piece of the <header> but has no outline itself, even an example with a <header> and <nav> @ http://www.whatwg.org/specs/web-apps/current-work/multipage/sections.html#the-header-element produces a headerless "section", per the description of a sectio |
| 02:58 | <JonathanNeal> | n. |
| 03:01 | <JonathanNeal> | Well, not to mention that the example doesn't have any closing </li>'s |
| 03:03 | <JonathanNeal> | Unless they're not required. I swear I'm American and educated, even though my sentences would indicate otherwise :-( |
| 03:04 | <MikeSmith> | JonathanNeal: the closing tags for <li> are not required in the HTML syntax |
| 03:05 | <MikeSmith> | they have never been required in the HTML syntax, since the very begining of HTML |
| 03:05 | <MikeSmith> | they are only required in XHTML |
| 03:07 | <JonathanNeal> | Oh, brilliant. I never knew that. Maybe this helps explain my problem @ http://gsnedders.html5.org/outliner/process.py?url=http%3A%2F%2Fsandbox.thewikies.com%2Fhtml5-outline-question |
| 03:07 | <JonathanNeal> | With the source @ http://sandbox.thewikies.com/html5-outline-question/ |
| 03:09 | <MikeSmith> | JonathanNeal: I have to drop off |
| 03:09 | <MikeSmith> | but you are asking in the right place |
| 03:09 | <JonathanNeal> | Okay, thanks for your time though. |
| 03:09 | <MikeSmith> | cheers |
| 03:20 | <JonathanNeal> | Hey, anybody else about? |
| 03:24 | <jcranmer> | nope, we're all dead |
| 03:26 | <JonathanNeal> | jcranmer, I'm sorry for your losses. |
| 03:27 | <jcranmer> | I'm not sorry for my loss |
| 03:29 | <JonathanNeal> | well, everyone else who died, apparently :-) |
| 05:01 | <oojacoboo> | so, are all you guys coding in strictly HTML5 now? |
| 05:20 | <JonathanNeal> | In an outline, is it okay to have untitled sections? Like in a <nav> ? |
| 07:11 | <TabAtkins> | JonathanNeal: Yeah, it is. You should generally try to avoid it, but there's nothing *wrong* with it. |
| 07:29 | <TabAtkins> | Can anyone point me to the quirks-mode flowchart? |
| 07:49 | <jgraham> | TabAtkins: Which quirks mode flowchart? There is an IE8-pecific one: http://hsivonen.iki.fi/doctype/ie8-mode.png |
| 07:49 | <jgraham> | *specific |
| 07:50 | <TabAtkins> | That's the one I was looking for, thanks. |
| 08:32 | <erlehmann> | jgraham, that thing makes me unhappy |
| 08:43 | <hsivonen> | erlehmann: and I haven't even added Chrome Frame to the flowchart yet |
| 08:44 | <erlehmann> | hsivonen, DONT |
| 08:44 | <erlehmann> | just dont |
| 08:44 | <erlehmann> | nuke redmond from orbit |
| 08:45 | <erlehmann> | its the only way to be sure |
| 09:21 | <jgraham> | erlehmann: It seems unfair to blame me :) |
| 09:21 | <erlehmann> | shoot the messenger :D |
| 09:22 | <erlehmann> | it worked in ye olde timeth |
| 10:05 | jgraham | is disappointed that no one has yet pointed out how close the <h1 src=""> proposal is to the <include> and <a include> proposals from 1993 that mpilgrim recently blogged |
| 10:40 | <zcorpan_> | hsivonen: the spoon feed bug is about the xml parser |
| 10:40 | <zcorpan_> | hsivonen: innerHTML says to feed the xml parser the string of a start tag and an end tag, iirc |
| 10:51 | <hsivonen> | zcorpan_: ok. oops. |
| 10:54 | <zcorpan_> | wow validator.w3.org seems to say that anything is valid html5 |
| 10:54 | <zcorpan_> | way to go |
| 10:58 | <jgraham> | def validate(document): return True |
| 10:59 | <jgraham> | why did that take hsivonen so long? |
| 10:59 | <jgraham> | I mean I know java is verbose, but even so... |
| 10:59 | <jgraham> | ;) |
| 11:02 | <zcorpan_> | now it's confirmed that html5 makes tag soup legal |
| 11:02 | <zcorpan_> | and D.E, too |
| 11:03 | <jgraham> | Hmm seems to wfm in that I get errors reported |
| 11:03 | <jgraham> | (using Text Field) |
| 11:04 | <zcorpan_> | you need detect automatically |
| 11:05 | <zcorpan_> | and a doctype that triggers html5 validation |
| 11:06 | <jgraham> | Erm, I may have been using validator.nu rahter than validator.w3.org. I lose. |
| 11:08 | <krisives> | hi all! |
| 11:08 | <zcorpan_> | hi krisives |
| 11:08 | <krisives> | Has anyone ever talked about private/public hashing for INPUT tags for HTML5 ? |
| 11:09 | <krisives> | I'm about to write out my idea into a blog post, but wanted to know if anyone else had started work or proposal on this type of thing |
| 11:09 | <webben> | krisives: Maybe ... what sort of hashing? for what? |
| 11:09 | <zcorpan_> | <input value=#> |
| 11:10 | <krisives> | Most people use Javascript right now to do client-side hashing of things like passwords |
| 11:10 | <krisives> | Like sending some salt and then doing MD5 in Javascript |
| 11:10 | <krisives> | To avoid sending the password over the wire |
| 11:10 | <webben> | right like this: http://drupal.org/node/36793 ? |
| 11:11 | <krisives> | I haven't seen that, but from scanning it sounds like what I'm talking about |
| 11:11 | <krisives> | I see it re-created all the time and thought it deserves a non-scripting solution |
| 11:12 | <webben> | I remember various discussion of hashing like http://www.blooberry.com/indexdot/html/tagpages/k/keygen.htm but I don't recall a discussion of singling out a field and converting it to a hash before sendng. |
| 11:12 | <webben> | ah ha |
| 11:12 | <webben> | krisives: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-August/012385.html |
| 11:12 | <webben> | so yes, it has been discussed |
| 11:13 | <krisives> | one important thing is that it should be capable of doing salt |
| 11:13 | <webben> | so I guess search the archives for related discussion :) |
| 11:13 | Philip` | guesses that the conclusion of the discussion was "if you care about security at all, use HTTPS" |
| 11:14 | <krisives> | Thanks I'm reading the mailing list now |
| 11:14 | <krisives> | HTTPS is broken |
| 11:14 | <Philip`> | Less broken than HTTP :-) |
| 11:14 | <krisives> | I can sign PayPals cert... |
| 11:14 | <krisives> | Its obfustication now IMO |
| 11:15 | <webben> | HTTPS does mean you aren't sending unencrypted traffic over the wire. |
| 11:15 | <webben> | It just doesn't guarantee you aren't sending unencrypted traffic to the wrong destination. |
| 11:15 | <webben> | (in practice) |
| 11:16 | <webben> | so ... wouldn't one have the same problem with a salted password? |
| 11:16 | webben | is not a security expert, I should hasten to add. |
| 11:19 | Philip` | vaguely remembers the issues with fake cert signing simply being about MD5, which is easily solved by using better hashing algorithms (which already work perfectly well in HTTPS) |
| 11:19 | <krisives> | The failures aren't the same |
| 11:20 | <krisives> | When SSL fails you get the plain text password |
| 11:20 | <krisives> | (Because it was transmitted) |
| 11:20 | <krisives> | If this is broken you at best get a subset of what the password could have been, if you wasted enough FLOPS to break the hash |
| 11:20 | <krisives> | Which also assumes you busted the salting technique |
| 11:21 | <Philip`> | With HTTP, an attacker can easily intercept the response and send you a version of the HTML page that doesn't have the hashing enabled on the password input |
| 11:21 | <Philip`> | and so you type your password in and the attacker gets it in plain text |
| 11:21 | <webben> | krisives: But, if the endpoint is using (say) an MD5 hash to authenticate, and a middleman grabs your MD5 hash, can't the middleman use that to authenticate? |
| 11:21 | <krisives> | Philip`: You can't use old technology to justify not creating new technology |
| 11:22 | <webben> | krisives: You can if the proposed new technology doesn't solve problems the old one doesn't. |
| 11:22 | <webben> | *old one does. |
| 11:22 | <webben> | or doesn't solve any new problems. |
| 11:22 | <krisives> | webben: In my proposal the salt would actually not be transmitted over the wire but would be a truely private key, such as when the user registered |
| 11:23 | <webben> | krisives: what would be sent over the wire? what would prevent a middleman sending the same thing over the wire? |
| 11:23 | <krisives> | Philip`'s scenario would keep the new technology from being created because the old technology can enable a flaw. The old (unsecure) tech should be deprecated |
| 11:24 | <krisives> | webben: All that would be sent over the wire is a hash of the INPUT data and a salt |
| 11:33 | <Philip`> | krisives: It would keep new technology from being created when its purpose is undermined by flaws in the current technology that it relies on and that hasn't been replaced yet |
| 11:35 | <krisives> | I think you're on a logically slippery slope there |
| 11:36 | gsnedders|work | falls flat on his face |
| 11:37 | <krisives> | A neat solution for that attack would be to force the salt to be based on the content delivered |
| 11:37 | <krisives> | (or part of a composite salt) |
| 11:38 | <krisives> | So the server delivers you content and saves the salt of the content delivered in server session for later verification |
| 11:41 | <Philip`> | What is "the content"? |
| 11:42 | <krisives> | the document |
| 11:42 | <Philip`> | If you're using an insecure protocol like HTTP, the attacker could just replace the content of an external script that your page includes, to make it send the user's password to them |
| 11:42 | <Philip`> | even if the page itself can't change |
| 11:43 | <krisives> | By "replace the content of an external script", do you mean change a script on my host? |
| 11:44 | <Philip`> | I mean change the content delivered to the user in response to their request for the script |
| 11:45 | <Philip`> | (as a MITM attack) |
| 11:46 | <krisives> | The hashing wouldn't be done in a script |
| 11:46 | <krisives> | Thats the point of this "proposal" |
| 11:47 | <Philip`> | I mean change the script to do "onload = function () { document.getElementById('hashed-password').removeAttribute('hash'); }" or similar |
| 11:48 | <Philip`> | so that the user's browser won't hash the password |
| 11:49 | <krisives> | And instead submit to the attacker |
| 11:49 | <Philip`> | Yes, or send it unencrypted to the original server so the attacker can read it, or whatever |
| 11:50 | <Philip`> | (I'm assuming the attacker can read and modify all unencrypted content passing between the client and server) |
| 11:51 | <Dashiva> | If the attacker can control the content, you've already lost |
| 11:53 | <Philip`> | Not really, because you can use encryption to know that you're talking to the server and not the attacker |
| 11:53 | <Philip`> | but it seems unlikely to work unless the entire session is encrypted |
| 11:54 | <Philip`> | (and also you need some way to verify identities of servers, which doesn't work so well nowadays) |
| 11:55 | <krisives> | If something like this was adopted I would expect browsers to warn when sending unencrypted passwords more violently |
| 11:55 | <zcorpan_> | if you care about security, you should hand over the password in person |
| 11:55 | <krisives> | Or deprecated/remove the behaviour |
| 11:56 | <Dashiva> | Philip`: How can you verify anything when the attacker can just MITM anything? |
| 11:56 | <Philip`> | Dashiva: The attacker can't MITM anything, unless they put your brain in a vat and control all your sensory inputs |
| 11:56 | <Dashiva> | Any client-side code is provided by the attacker |
| 11:56 | <krisives> | Either way I find it hard to justify keeping the behaviour of sending the password as (obfusticated) text |
| 11:57 | <Dashiva> | Philip`: They can MITM anything on the client end of the browsing session |
| 12:00 | <Philip`> | Dashiva: They can MITM your internet connections for some period of time, but it's reasonable to assume that e.g. they didn't alter your installation of CD of Windows, and that means they didn't alter your OS's root certificate store, and you assume they didn't get Microsoft to install fake certificates, etc |
| 12:00 | <Philip`> | s/of CD/CD/ |
| 12:00 | <Dashiva> | Philip`: Unsecure connection was a premise here, wasn't it? |
| 12:00 | <Philip`> | and you assume certificate authorities are perfect |
| 12:01 | <krisives> | I understand where everyone is going with this, but does it really justify continuing to send passwords as obfuscated plain text ? |
| 12:02 | <Philip`> | Dashiva: I think the premise was a combination of insecure and secure parts of the connection (e.g. sending the password 'securely') |
| 12:02 | <Dashiva> | I thought the premise was trying to do secure communication on an insecure connection |
| 12:03 | <Philip`> | TCP is an insecure connection but you can do secure communication over it using SSL |
| 12:03 | <Dashiva> | Because you control the code on your endpoint |
| 12:03 | <krisives> | Dashiva: Philip` believes that a more secure password authentication that doesn't send the password over the wire, and instead sends a hash, is not worth having because the MITM can just rely on deprecated behaviour |
| 12:03 | <Dashiva> | With a webpage, you're using code provided by an unknown party |
| 12:04 | <krisives> | Philip`: I remind you again that SSL is broken |
| 12:04 | <Philip`> | krisives: I don't think it justifies that, but I think the point is it doesn't justify spending effort on a solution that doesn't actually solve the problem in practice (due to flaws in the underlying technology) - the effort would be better spent on a solution that has a much better chance of working and isn't fundamentally broken, like SSL |
| 12:05 | <krisives> | I disagree, because we'll be putting faith once again in another technology like SSL, that when/if broken will give access to plaintext passwords again. |
| 12:05 | <Philip`> | (Uh, I mean that something like SSL isn't fundamentally broken) |
| 12:05 | <Philip`> | (and didn't mean to imply the opposite) |
| 12:06 | <Philip`> | Dashiva: You're using code provided by your favourite browser vendor, who might be able to implement features that ensure communication is secure |
| 12:06 | <Philip`> | in theory |
| 12:07 | <Philip`> | (though in practice there's so much flexibility allowed to scripts that the only solution that seems feasible is to encrypt the entire session) |
| 12:08 | <zcorpan_> | maybe the attacker could modify the browser and push it onto the user with autoupdate |
| 12:08 | <krisives> | Again though, "doesn't actually solve the problem in practice" only because of deprecated old technology |
| 12:09 | <Philip`> | "deprecated old technology" is what exists in practice so we have to deal with it :-) |
| 12:09 | <Philip`> | zcorpan_: Autoupdates are signed |
| 12:09 | <Philip`> | or at least I hope they are, because browser developers can't be idiots |
| 12:10 | <Philip`> | so they're guaranteed to be safe by the person who you originally trusted to download the browser from |
| 12:11 | <gsnedders|work> | Philip`: I'm an idiot. |
| 12:11 | <Philip`> | gsnedders|work: I mean collectively, not each individual |
| 12:12 | krisives | is probably dumber |
| 12:12 | <krisives> | STUPID WAR! |
| 12:15 | <zcorpan_> | gsnedders|work: you're not a browser developer |
| 12:15 | <gsnedders|work> | zcorpan_: True. |
| 12:15 | <gsnedders|work> | zcorpan_: I just find their mistakes. |
| 12:17 | <zcorpan_> | have you found any autoupdate mistakes? |
| 12:17 | <gsnedders|work> | YEs |
| 12:17 | <gsnedders|work> | *Yes |
| 12:19 | <Philip`> | Were you responsible for finding the mistake that autoupdate didn't exist? |
| 12:21 | <gsnedders|work> | No |
| 12:21 | <Philip`> | I suppose that was a subtle one and easy to miss |
| 12:30 | <jgraham> | Philip`: He didn't say he missed it just that he didn't have responsibility for noticing it |
| 14:47 | gsnedders|work | decides on domain for his new website |
| 14:48 | <Rik`> | gsnedders|work: someone told me that your outliner should give hints about where are "Untitled sections" |
| 14:49 | <gsnedders|work> | Rik`: I have plans to deal with a lot of the ambiguity. It just so happens that it also involves rewriting the entire thing :) |
| 14:51 | <gsnedders|work> | Rik`: And it also means being careful in IE about infinite loops :( |
| 14:51 | <Rik`> | in IE ? |
| 14:52 | <gsnedders|work> | Rik`: New impl will be JS based |
| 14:52 | <Rik`> | oh |
| 14:52 | <gsnedders|work> | Rik`: IE can create circular DOMs. |
| 14:52 | <Rik`> | why JS based ? |
| 14:53 | <gsnedders|work> | Rik`: A lot of the features people have been asking for are very hard to do without modifying the source document in some way, or are only possible with scripting that can touch that document |
| 14:54 | <Rik`> | I can has a textarea to copy/paste ? |
| 14:54 | <gsnedders|work> | Rik`: Yeah, I guess I'll allow that |
| 14:56 | <zcorpan_> | gsnedders|work: there's a js implementation already |
| 14:56 | <Rik`> | thanks ! :) |
| 14:57 | <gsnedders|work> | zcorpan_: But does it have an über-cool UI? |
| 14:57 | <zcorpan_> | gsnedders|work: no |
| 14:57 | <zcorpan_> | but you can implement your own ui for it |
| 14:58 | <gsnedders|work> | zcorpan_: Where is the impl? |
| 15:00 | <zcorpan_> | gsnedders|work: http://d.hatena.ne.jp/amachang/20090915/1252999677 |
| 15:02 | <jgraham> | zcorpan_: No licensing information that I can see |
| 15:03 | <gsnedders|work> | zcorpan_: Also, IRC logs from before have me concluding that doesn't protect itself from IE |
| 15:04 | <gsnedders|work> | Also: I want decent blog software |
| 15:04 | <zcorpan_> | who cares about ie |
| 15:04 | <zcorpan_> | gsnedders|work: me too, and a pony |
| 15:05 | <gsnedders|work> | Habari claims to include a pony, but it still isn't decent. |
| 15:05 | jgraham | doesn't want a pony |
| 15:05 | <gsnedders|work> | (but is nevertheless used on gsnedders.com) |
| 15:05 | <gsnedders|work> | (but is PHP and so is evil) |
| 15:05 | <jgraham> | They seem like a lot of effort to look after and in any case I am probably too tall to ride one |
| 15:05 | <gsnedders|work> | (w00t for languages without Unicode support) |
| 15:06 | <jgraham> | So it seems like it would mostly be a drag |
| 15:06 | <jgraham> | After the initial cuteness wore off |
| 15:06 | gsnedders|work | thinks, then realizes it was a horse he rode a couple of years back |
| 15:34 | hsivonen | reads Noah Mendelsohn's slides |
| 15:34 | <hsivonen> | no 'con' about proprietary lock-in |
| 15:35 | <hsivonen> | also, is the implied assumption that HTML, SVG and Math WGs shouldn't have to coordinate? |
| 15:36 | <annevk2> | not sure |
| 15:36 | <annevk2> | I wonder how that panel will go |
| 15:36 | <annevk2> | starts in an hour |
| 15:38 | <hsivonen> | not many people on #tpac |
| 15:38 | <hsivonen> | is the session going to be IRC-minuted |
| 15:40 | <annevk2> | there's #tpac, #tp, and #tpac09 |
| 15:40 | <annevk2> | #tpac seems most popular but only #tp has a topic |
| 15:41 | <annevk2> | not sure about minutes, but given how things went last year I'd assume so |
| 15:41 | <annevk2> | last year there was a live video channel as well I think |
| 15:41 | <Dashiva> | There were some sessions minuted in #webapps |
| 15:44 | <hsivonen> | I'm always puzzled when W3C specs like SVG and MathML are put forward as decentralized extensions without coordination |
| 15:44 | <hsivonen> | surely they are centralized at the W3C and should be coordinated |
| 15:45 | <hsivonen> | annevk2: thanks. I joined all those channel |
| 15:45 | <hsivonen> | s |
| 15:45 | <hsivonen> | I didn't find a link to a video or audio feed |
| 15:46 | <annevk2> | me neither |
| 15:46 | <annevk2> | I'm sure some more W3C staff will be around on IRC later |
| 15:46 | <annevk2> | they can prolly help out |
| 15:46 | <gsnedders|work> | I don't think there was any video last year |
| 15:47 | <gsnedders|work> | (And if there was, I guess it was incomplete due to losing power during the keynote) |
| 15:47 | <hsivonen> | I've been to a TPAC where there was audio and the captioner couldn't keep up with TimBL |
| 15:48 | <gsnedders|work> | 07, no? |
| 15:49 | <hsivonen> | maybe |
| 22:20 | <gsnedders> | Hmm, debit card failing, yet bank says it is still active. |
| 22:38 | <dglazkov> | have we pulled datagrid from html5? |
| 22:38 | <dglazkov> | is it gone-gone or just moved to another spec? |
| 22:38 | <annevk2> | it was commented out |
| 22:38 | <annevk2> | it was not stable enough |
| 22:38 | <annevk2> | I believe dhyatt is toying with an alternate design for it |
| 22:39 | <dglazkov> | annevk2: good to know. |
| 22:40 | <dglazkov> | thanks |
| 22:41 | <JonathanNeal> | So it's commented out of the html5 spec? |
| 22:43 | <annevk2> | yes |
| 22:43 | <annevk2> | maybe it is no longer in the source either; I forgot |
| 22:44 | <annevk2> | it's still there |
| 22:44 | <annevk2> | v2datagrid |
