| 01:21 | <nog_lorp> | hello |
| 02:05 | <MikeSmith> | Hixie: OK, thanks |
| 02:05 | <MikeSmith> | I did already commit it that way yesterday |
| 02:06 | <MikeSmith> | the main reason I was asking was that the behavior's not totally consistent in that we don't currently do the same for some other cases where the spec provides some additional guidance |
| 02:07 | <MikeSmith> | for example, for Set-Cookie |
| 02:08 | <MikeSmith> | where we could emit "To set cookies, use HTTP headers instead." or whatever |
| 02:11 | <MikeSmith> | but anyway, it's a bigger priority to implement checks for all the actual document-conformance requirements in the spec |
| 04:35 | <Hixie> | abarth: yt? |
| 04:47 | <Hixie> | anyone got a webkit build handy? |
| 04:48 | <Hixie> | does http://software.hixie.ch/utilities/js/live-dom-viewer/saved/970 fail in safari/webkit too, or is it a chrome bug? |
| 04:50 | <heycam> | Hixie, nothing changed colour for me in a semi-recent WebKit |
| 04:50 | <Hixie> | k thx |
| 06:05 | <othermaciej> | Hixie: nothing changes in a fresh WebKit build - what's the bug in Chrome? |
| 06:06 | othermaciej | is surprised that a Chrome-specific bug would even be possible here |
| 06:06 | <Hixie> | it focuses the <output> |
| 06:06 | <Hixie> | yeah, me too |
| 06:06 | <othermaciej> | hmm, let me try in full keyboard access mode in Safari |
| 06:06 | <Hixie> | (only happens if the output is display:block) |
| 06:07 | <othermaciej> | it happens in Safari in Full Keyboard Access mode |
| 06:07 | <othermaciej> | so it's just a bug in WebKit focusability rules |
| 06:08 | <othermaciej> | it's hell weird that display: block on the <output> matters |
| 15:04 | <AryehGregor> | <Hixie> AryehGregor: are you going to mention the things that were discussed in #whatwg earlier? <-- Which things that we discussed in #whatwg earlier? |
| 15:04 | <AryehGregor> | I plan to come up with as many specific examples of spec or spec organization forks that I can. |
| 15:05 | <AryehGregor> | The two that I know of offhand are the WHATWG splitting from the W3C, and the W3C being created because TBL had too many problems in the IETF, which are both excellent support for forking. |
| 15:05 | <AryehGregor> | Other people have mentioned an IETF fork of some version of HTML, what's the story on that? |
| 15:05 | <AryehGregor> | And does anyone know of other examples? |
| 15:05 | <Dashiva> | <othermaciej> One thing I wonder about is whether the W3C intends to take action against the ISO HTML, XHTML-MP, CHTML, XHTML Basic, XHTML 2, WML, WTVML, XHTML-Print, WHATWG HTML, or HDML forks of HTML |
| 15:06 | <AryehGregor> | Oh, it was ISO that forked it, not the IETF. |
| 15:06 | <AryehGregor> | Right. |
| 15:06 | <AryehGregor> | Surely XHTML 2 doesn't count, since that's a W3C-sponsored fork? |
| 15:08 | <Dashiva> | I guess that depends on what the purpose of the ban on forks is |
| 15:08 | <MikeSmith> | CE-HTML |
| 15:09 | <MikeSmith> | and Open IPTV Forum "Declarative Application Environment V2.0" |
| 15:09 | <MikeSmith> | http://www.openiptvforum.org/specifications.html |
| 15:09 | <MikeSmith> | take a look a that spec some time - |
| 15:09 | <MikeSmith> | http://www.openiptvforum.org/docs/Release2/OIPF-T1-R2-Specification-Volume-5-Declarative-Application-Environment-v2_0-2010-09-07.pdf |
| 15:10 | <Dashiva> | Heh, it references HTML5 |
| 15:10 | <AryehGregor> | Is anyone interested in helping with a wiki page to outline all the arguments for why forking is either harmless or good? |
| 15:11 | <Dashiva> | That sounds like trying to prove a negative... |
| 15:11 | <AryehGregor> | No, you can cite all the existing forks and point out that they were all either harmless or good. |
| 15:11 | <AryehGregor> | That's evidence. |
| 15:12 | <Dashiva> | Anecdotal evidence |
| 15:12 | <wilhelm_> | *-MP was not good. :P |
| 15:12 | <AryehGregor> | As opposed to no evidence, which is what the forking-is-bad crowd has. |
| 15:12 | <AryehGregor> | You can't expect randomized controlled double-blind trials for questions like "Is allowing spec forks a good idea?" You've got to work with what you have. |
| 15:13 | <AryehGregor> | I'll have only limited time to work on a real response to the survey unless Hixie decides it's part of my contract. |
| 15:13 | <AryehGregor> | (Why can't contracts just say stuff like "Do something useful and web standards-related"?) |
| 15:13 | <Dashiva> | It's a mystery |
| 15:13 | <AryehGregor> | That seems to be the job description of some full-time employees. |
| 15:14 | <Dashiva> | But really, several of the ones othermaciej listed are non-harmless in my opinion |
| 15:14 | <AryehGregor> | Interesting. Which ones? |
| 15:14 | <Dashiva> | The ones building on XHTML, because they fragment the ecosystem and lead to a waste of time and effort when they fail |
| 15:14 | <AryehGregor> | They still probably don't strongly support the case of restrictive copyright licensing, given that a) they might not actually infringe copyright, and b) the W3C doesn't appear interested in suing even if they do. |
| 15:15 | <othermaciej> | some I'm not sure totally count as forks |
| 15:15 | <AryehGregor> | So, like, XHTML 2? |
| 15:15 | <othermaciej> | but XHTML-MP is pretty bad, as it sends content purporting to be XHTML but with different processing rules |
| 15:15 | <othermaciej> | (really weird stuff too) |
| 15:15 | <othermaciej> | CHTML is bad for similar reasons |
| 15:16 | <othermaciej> | these are bad not only for browsers that implement them but also, when such content is posted, it creates non-interoperable worlds and makes it hard to successfully display all content |
| 15:16 | <othermaciej> | WML is less bad in that regard since it has a distinct content type but I'm not totally sure if it is fair to call it a fork |
| 15:17 | <othermaciej> | it certainly copies many of the elements in HTML |
| 15:17 | <AryehGregor> | But these are all basically unsuccessful, aren't they? |
| 15:17 | <AryehGregor> | They're only really harmful if they cause real problems, not if they would have caused problems had they been successful. |
| 15:17 | <othermaciej> | there is a huge amount of XHTML-MP, CHTML and WML content out there |
| 15:17 | <AryehGregor> | Interesting. |
| 15:17 | <othermaciej> | in east asia, there is huge market pressure for any mobile browser that gets released to support one or more of them |
| 15:17 | <AryehGregor> | I've never heard of any of them, I don't think. |
| 15:17 | <AryehGregor> | Oh, they're mobile things. |
| 15:18 | <AryehGregor> | Well, I'll briefly look at some of them, I guess. |
| 15:18 | <othermaciej> | yes, mobile web stuff |
| 15:18 | <wilhelm_> | A lot of operators push for *-MP compliance, too. |
| 15:18 | <wilhelm_> | (Which sucks.) |
| 15:18 | <othermaciej> | many of the forks from my list are W3C-sponsored but are nonetheless incompatible fors |
| 15:18 | <othermaciej> | XHTML2 is much less damaging than the things I listed since no one uses it |
| 15:18 | <AryehGregor> | I don't think W3C forks are germane to the licensing question at hand. |
| 15:19 | <AryehGregor> | Since they'd be allowed under any license, presumably. |
| 15:19 | <othermaciej> | none of these are germane to the licensing issue at hand |
| 15:19 | <AryehGregor> | Why not? |
| 15:19 | <othermaciej> | none of them were prevented by the W3C Document License |
| 15:19 | <othermaciej> | which does not allow forking |
| 15:19 | <AryehGregor> | That's evidence that the restrictive license is ineffective, which is germane. |
| 15:20 | <othermaciej> | or to look at it another way, all of them are germane, since they show that anti-forking license provisions are not effective at preventing forking |
| 15:20 | <AryehGregor> | Right, exactly. |
| 15:20 | AryehGregor | has to go now, more later . . . if he can find the time |
| 15:20 | <othermaciej> | the fact that the W3C itself forks is even more germane, since no license you could imagine could prevent that |
| 15:21 | <AryehGregor> | I'm glad we got those extra two licensing options up. I wonder how the results of the survey will be considered by the people whose business it is to consider them. |
| 17:54 | <abarth> | Hixie: pong |
| 17:54 | <MikeSmith> | hmm, Canonical XML 2.0 |
| 17:54 | <MikeSmith> | dare I look |
| 18:18 | <Hixie> | AryehGregor: feel free to use a few of google's hours to work on a response that once and for all explains all the relevant issues here, but if you do then send me regular updates so i can give you more direct feedback |
| 18:21 | <Hixie> | abarth: if you are trying to hash passwords in a login db, then presumably you want to use MHAC with some algorithm like SHA-256 or whatever. but what key do you use? can you use the username as a key, or is that a Bad Idea? |
| 18:22 | <abarth> | i bet there's some canonical explanation for how to do this |
| 18:22 | <abarth> | but the general approach is to use a hash, not an HMAC |
| 18:23 | <abarth> | with a public and a private salt |
| 18:23 | <Hixie> | k |
| 18:23 | <Hixie> | so there's no good way to avoid a private salt? |
| 18:24 | <Hixie> | i was hoping to be able to do a "SELECT ... WHERE ... AND password=?" instead of selecting the row then comparing the password |
| 18:24 | <Hixie> | so that if the password is wrong, the code never even gets the userid |
| 18:24 | <Hixie> | it's not a huge deal if it's not possible |
| 18:24 | <abarth> | the private salt is just there to slow down the hash function |
| 18:25 | <abarth> | so you can avoid it if you pick a slow hash function |
| 18:25 | <abarth> | the public salt is technically supposed to be per-password though |
| 18:25 | <abarth> | to prevent the attack from attacking all the passwords at once |
| 18:25 | <abarth> | with a dictionary |
| 18:25 | <abarth> | s/attack/attacker/ |
| 18:26 | <AryehGregor> | Hixie, if your DBMS supports the relevant functions, you can do something like "WHERE ... password = SHA256(salt + 'password')", if the user table has a salt column that contains the per-user salt. |
| 18:27 | <AryehGregor> | Of course, that's not indexable, so it won't scale to many users. |
| 18:28 | <AryehGregor> | Why would you want to look up users by their password anyway, though? |
| 18:28 | <AryehGregor> | Other than to detect weak passwords, maybe, in which case it's obviously going to be O(N) and indexing doesn't make much of a difference one way or the other. |
| 18:29 | <Philip`> | (It'd be indexable in Postgres, I think) |
| 18:29 | <AryehGregor> | Philip`, how? |
| 18:29 | <AryehGregor> | Postgres supports indexes on expressions, but what expression could you index here? |
| 18:29 | <Philip`> | (unless I'm missing understanding, which I probably am) |
| 18:29 | <AryehGregor> | In "WHERE ... password = SHA256(salt + 'password')", password and salt are both DB columns. |
| 18:30 | <AryehGregor> | And the string 'password' is provided literally by the application for the specific query. |
| 18:31 | <Philip`> | I think I was reading the literal and column the other way around |
| 18:31 | <Philip`> | (which would be silly) |
| 18:39 | <Hixie> | abarth: yeah, hence my question about using the username as the public salt |
| 18:41 | <Hixie> | AryehGregor: the actual query would be WHERE username=? AND password=? |
| 18:41 | <Hixie> | AryehGregor: so that it returns nothing when the password is wrong |
| 18:41 | <AryehGregor> | Hixie, oh, I see. |
| 18:41 | <abarth> | that seems fine |
| 18:41 | <Hixie> | AryehGregor: let me see if i can use a SHA256() function |
| 18:42 | <abarth> | but this isn't my area of expertise |
| 18:42 | <Hixie> | abarth: k |
| 18:42 | <AryehGregor> | Ideally your public salt should be long enough that you foil rainbow table attacks. |
| 18:42 | <AryehGregor> | For that purpose, it's probably best to make it a not-too-short randomish string. |
| 18:42 | <Hixie> | looks like sqlite3 doesn't have hash-related functions |
| 18:43 | <Hixie> | wonder if i can add custom functions from perl... |
| 18:43 | <AryehGregor> | Is this a WebSQL use-case? |
| 18:43 | <Hixie> | no it's just a toy i'm playing with at home |
| 18:44 | <AryehGregor> | I don't actually get the use-case at all, though. If the attacker can query the DB, why don't they just do "SELECT * FROM user"? Because they only have the right to execute prepared statements? |
| 18:44 | <Hixie> | ho ho ho, you _can_ add functions in perl |
| 18:44 | <Hixie> | that will make my life easier |
| 18:44 | <AryehGregor> | How does that even make sense with SQLite, though? If you can query an SQLite database, surely you have read access to the database file? |
| 18:45 | <Hixie> | AryehGregor: the concern is highly theoretical and mare an issue of having clear boundaries in code, but to the extent that it is a concern, the theoretical attack is someone who can cause the perl code to leak data from its environment |
| 18:46 | <Hixie> | AryehGregor: if someone is running their own arbitrary code, then yeah, they can read the db, at which point it's why we're hashing it |
| 18:47 | <AryehGregor> | So like someone who can read the contents of your Perl program's memory, but can't control it, and you're worried about them reading the userid in the brief window before it's garbage-collected or something . . . ? |
| 18:47 | <AryehGregor> | If so, why don't you first retrieve the hash and check if it matches, and only then query the id? |
| 18:48 | <Philip`> | Given that SQLite doesn't run in a separate process, if they can read the Perl program's memory then they can read the raw database data, probably |
| 18:49 | <AryehGregor> | That too. |
| 18:49 | <Hixie> | AryehGregor: my desire does not a priori stem from a security concern |
| 18:50 | <Hixie> | AryehGregor: it's about keeping clear boundaries in the code about what code gets to see what |
| 18:50 | <Hixie> | for readability |
| 18:51 | <AryehGregor> | k. |
| 18:52 | <Hixie> | and it gives me an opportunity to play with this function creation thing :-) |
| 18:54 | <Philip`> | Injecting custom Perl functions into SQLite so they can run inside SQL queries is meant to *increase* readability? :-) |
| 18:55 | <Hixie> | hehe |
| 18:55 | <Hixie> | actually in this case i think it will |
| 18:55 | <Hixie> | though i agree with your skepticism :-) |
| 18:57 | Philip` | wonders if there's a Perl module equivalent to http://apidoc.apsw.googlecode.com/hg/vtable.html (where you can redefine the whole table storage mechanism in a scripting language) |
| 19:29 | <AryehGregor> | Hixie et al., I started a page on forking on the WHATWG wiki: http://wiki.whatwg.org/wiki/Forking |
| 19:29 | <AryehGregor> | If anyone wants to fill it out some more, please do. |
| 19:29 | <AryehGregor> | I don't know if I'll work on it further. |
| 19:30 | <AryehGregor> | (I'll probably work on improving my personal survey response later on my own time) |
| 20:07 | <zewt> | how long until someone forks the page on forking |
| 23:52 | <Hixie> | can someone explain why Lawrence Rosen keeps talking about patents when we're trying to discuss the copyright license? |
| 23:52 | <Hixie> | isn't he a lawyer? you'd think he'd know better that to try to confuse these unrelated matters. |