| 04:36 | <zcorpan> | <http://www.w3.org/mid/9B2DE9094C827E44988F5ADAA6A2C5DA01B93A59⊙Hppc>; |
| 05:37 | <zcorpan> | i wonder what http://lists.w3.org/Archives/Public/public-html-xml/2010Dec/0029.html would be if hsivonen wasn't on the call |
| 07:19 | <boblet> | amusing that in the MS “HTML5 site ready” article links to brucel’s snarky piece on IE’s testing center as evidence of “strong developer support” |
| 07:19 | <boblet> | British wit is indeed tricksy for the beginner |
| 07:31 | <zcorpan> | so according to timj he was the only one to think that exposing endianness in ArrayBuffer was a problem, everyone else thought it would work out fine. and now it's too late to change it |
| 07:32 | <zcorpan> | i guess we'll see how it goes |
| 08:11 | <hsivonen> | TabAtkins: if >> truncates to 32 bits, does it truncate first? that is, if you've overflown 32 bits, can you actually shift the overflown part with >> ? |
| 08:17 | <Ms2ger> | "I also completely disagree that one has to be constrained by what existing browsers do." |
| 08:50 | <erlehmann> | zcorpan, „how it goes“? you mean: one endianness becomes de facto standard, right? |
| 08:52 | <zcorpan> | erlehmann: seems like one possible outcome |
| 08:54 | <Dashiva> | TabAtkins: Yes, it truncates first |
| 08:54 | <zcorpan> | erlehmann: another is that people sniff for stuff unrelated to the endianness to decide which endianness to use, and we get stuck with that for compat |
| 08:56 | <Dashiva> | You'd think if you were exposing endian-specific behavior you'd also expose a property indicating the endianness |
| 08:56 | <erlehmann> | zcorpan, so opera and firefox may use one endianness, that, of course, microsoft, apple and nokia will deride as “proprietary” while implement their own, for which royalties will have to be paid to ENDIAN-LA. |
| 08:57 | <zcorpan> | lol |
| 08:57 | <erlehmann> | ZING! :D |
| 09:15 | <hsivonen> | Will Apple ship WebGL for PowerPC? Or will Opera be the only one of the top 5 vendors left shipping WebGL-relevant code for big-endian hardware? |
| 09:23 | <smaug____> | are all the major mobile platforms little-endian? |
| 10:01 | <hsivonen> | smaug____: Arm is little-endian and Intel Atom is too. |
| 11:31 | <hsivonen> | "Since it’s unlikely that Opera or Firefox would change their script loading/blocking behavior, this actually works just fine." http://www.nczonline.net/blog/2009/12/29/feature-detection-is-not-browser-detection/ |
| 11:33 | <bga_> | Netscape alive! |
| 11:36 | <hsivonen> | bga_: ? |
| 11:37 | <bga_> | } else if (document.layers){ //Netscape < 6 |
| 11:37 | <bga_> | element = document.layers[id]; |
| 11:40 | <hsivonen> | ah |
| 11:42 | <hsivonen> | I saw code for Netscape 4 in a lib released this month |
| 11:44 | <bga_> | cool stuff http://www.useragentman.com/shared/js/helpers.js :) |
| 11:54 | <hsivonen> | this I hadn't seen before: https://twitter.com/#!/getify/status/26109887817 |
| 11:58 | <bga_> | __parent__ too |
| 11:58 | <bga_> | __magics__ must die imho |
| 12:01 | <hsivonen> | http://labs.opera.com/news/2010/12/22/ reveals who is implementing the WAC stuff |
| 13:34 | MikeSmith | didn't know getify had a twitter account |
| 13:46 | <MikeSmith> | hsivonen: got some patches awaiting your review |
| 13:46 | <MikeSmith> | https://bitbucket.org/validator/syntax-patches/qseries?apply=t&qs_apply=spaces-around-url |
| 13:46 | <MikeSmith> | above is for allowing spaces around attribute values that expect IRIs |
| 13:46 | <MikeSmith> | that currently has the non-conforming side effect of allowing, e.g., content="5; url= http://example.com " in meta/@http-equiv=refresh |
| 13:47 | <MikeSmith> | so I think I'll also need either to add some checking for that in the assertions-checking code |
| 13:47 | <MikeSmith> | or I'll need to convince Hixie to make it conformant |
| 13:55 | <MikeSmith> | hsivonen: the other patch is this: |
| 13:55 | <MikeSmith> | https://bitbucket.org/validator/validator-patches/qseries?apply=t&qs_apply=mathml2-update |
| 13:56 | <MikeSmith> | which is for updating the MathML schema to the one that David Carlisle has made available at http://www.w3.org/Math/RelaxNG/mathml3-restricted/ |
| 13:57 | <MikeSmith> | which is essentially a MathML2-compatiable subset of MathML3 |
| 13:58 | <MikeSmith> | "with all element and attribute names introduced at MathML3 removed" but with more useful constraints on microsyntax/datatypes of MathML2 attribute values |
| 14:35 | <karlcow> | http://www.debeterevormgever.nl/html5-ie-without-javascript/ |
| 15:20 | <Rik`> | karlcow: six years ago http://dean.edwards.name/my/abbr-cadabra.html |
| 15:21 | <karlcow> | ah cool Rik` |
| 15:21 | <Rik`> | every time someone finds a new cool technique on the web, there is a good chance Dean Edwards did it first :) |
| 15:22 | <karlcow> | is that part of the 3 laws of Internetics? |
| 15:22 | <karlcow> | :p |
| 15:25 | <bga_> | hehe |
| 15:25 | <bga_> | Dean is our god |
| 15:52 | <yod> | karlcow - the other two being that there is always someone wrong on the internet, and that any of us may or may not be a dog? |
| 15:57 | <pesla> | Does anyone know why Firefox returns a floating point number when getting the computed style for fe. the height of an element (=> 101.2px)? |
| 16:43 | <TabAtkins> | Because that's the computed style? (Actually, it's the "used value", in CSS parlance.) |
| 16:44 | <TabAtkins> | pesla: ^^^ |
| 16:48 | <pesla> | TabAtkins: Why does Gecko, unlike WebKit and Trident, not round it to the pixel? I didn't know about the existance of sub-pixels actually ;) |
| 16:48 | <TabAtkins> | Gecko does round to the pixel for the "actual value", which is what is used to actually render. |
| 16:50 | <bga_> | pesla parseInt('101.2px') :P |
| 16:50 | <pesla> | bga_: Yea, i know. I'm just interested in the concept of subpixels. |
| 16:50 | <pesla> | I'm not sure why they'r usefull |
| 16:50 | <bga_> | ok |
| 16:56 | <karlcow> | yod, what about cows? :p |
| 16:57 | <yod> | whatever rocks your arch |
| 16:58 | <karlcow> | now you are talking… |
| 17:08 | <amphibi> | My group at http://www.myefact.com/ embraces open web technologies. |
| 17:09 | <TabAtkins> | Okay? |
| 17:09 | <paul_irish> | TabAtkins: correct response is: "cool story, bro." |
| 17:09 | <TabAtkins> | Damn, you're right. I fail at memes. |
| 17:10 | <paul_irish> | ;) |
| 17:10 | <TabAtkins> | Yo, Paul, what song should I download at the bing music store? |
| 17:12 | <paul_irish> | TabAtkins: MOVITS! - Fel del av gården |
| 17:12 | <TabAtkins> | Will do. |
| 17:14 | <paul_irish> | TabAtkins: only because i doubt http://youtu.be/SPbijgSYe_4 is on their store. |
| 17:14 | <TabAtkins> | <3 Pogo |
| 17:16 | <TabAtkins> | Ah, this is just a Pogo tribute. |
| 17:18 | <bga_> | animated flash captchas >_< |
| 17:18 | <TabAtkins> | lolwut |
| 17:22 | <bga_> | TabAtkins http://diplodocs.ru/flash2/lecteurC_EMFSIIFRTH12215QNAUORITGDE244144HXLDDIWLYOY.swf |
| 17:22 | <TabAtkins> | Wow. |
| 17:36 | <TabAtkins> | Huh. I've reached the point where 80% of my spam is in Chinese. That's just bizarre. |
| 17:37 | <TabAtkins> | Though I suppose machine-generated broken chinese is better than machine-generated broken english, because I can't distinguish it from normal chinese. |
| 17:58 | <karlcow> | TabAtkins: if you are reading chinese fluently it is easier to hit delete key |
| 17:58 | <karlcow> | oops |
| 17:58 | <karlcow> | you are not |
| 17:59 | <TabAtkins> | I can't read *any* chinese, so it's all the same to me. ^_^ |
| 18:29 | <karlcow> | david_carlisle: text/mathml is to be banished (or it is accepted) (putting aside application/mathml+xml) |
| 18:30 | <david_carlisle> | banished? |
| 18:31 | <amphibi> | Don't banish things. :( |
| 18:31 | <david_carlisle> | do you mean the mime type or mathml itself? (text/mathml was never used/registered as far as I know?) |
| 18:35 | <karlcow> | text/mathml mimetype. Some people are using online it seems |
| 18:38 | <david_carlisle> | shrug, perhaps. The interesting case for mathml on the web is anyway mathml in a document so without a mathml specific mime type. I don't think i )or the math wg) would have a view. Of course individual implementations, if they are currently checking for that and doing something, will need to take a decision about whether to carry on supporting that going forwards. |
| 18:49 | <jwalden> | dear lazyirc: is anyone still pushing shared workers? and if anyone is, are any of those entities thinking about implementing content security policies? |
| 18:51 | <TabAtkins> | Shared workers are indeed being implemented. I don't know if anyone's caring about CSP. |
| 18:52 | <jwalden> | Gecko has CSP these days |
| 18:52 | <jwalden> | pretty sure we don't have shared workers |
| 18:52 | <jwalden> | I am curious whether anyone has thought through the interaction of CSP's forbid-calls-to-eval-like-stuff with shared workers and the same prohibition in them |
| 18:53 | <jwalden> | this occurred to me just now on reading the proposed solution to https://bugzilla.mozilla.org/show_bug.cgi?id=609748 |
| 18:53 | <jwalden> | it is also possible I have been entirely misled as to what shared workers are by the name, but I hadn't gotten that impression from ancient threads on it I dimly remember reading |
| 18:55 | <TabAtkins> | Shared Workers are just workers that can respond to messages from multiple pages, not just the one channel like normal workers. |
| 18:55 | <jwalden> | yes |
| 18:56 | <jwalden> | so, does that mean a shared worker should be able to eval/Function, or no? |
| 18:56 | <jwalden> | by default the answer's obviously yes |
| 18:56 | <TabAtkins> | I have no idea. ^_^ CSP stuff isnt' on my radar. |
| 18:56 | <jwalden> | guess I'll poke people on the Mozilla side, or something |
| 18:59 | <Hixie> | that's not quite an accurate description of the difference |
| 18:59 | <Hixie> | a shared worker is a worker to which one can open a channel by name after it is created |
| 19:00 | <Hixie> | both shared workers and dedicated workers can respond to messages from multiple pages and can have multiple channels, etc |
| 19:01 | <jwalden> | this seems...potentially problematic if the worker can eval, but the page accessing the worker shouldn't be able to |
| 19:01 | <Hixie> | (shared workers also have a different lifetime definition) |
| 19:01 | <Hixie> | jwalden: well it's all same-origin currently |
| 19:01 | <jwalden> | sure |
| 19:01 | <jwalden> | CSP is same-origin paranoia |
| 19:01 | <Hixie> | but sure, CSP should apply to workers too |
| 19:01 | <Hixie> | shared or not shared |
| 19:02 | <Hixie> | doesn't really matter |
| 19:02 | <jwalden> | CSP is a per-page thing, though, not a per-origin thing |
| 19:02 | <jwalden> | comes in HTTP headers |
| 19:03 | <jwalden> | I suppose one could argue this is undesirable complexity, for this case and conceivably others |
| 19:03 | <AryehGregor> | TabAtkins, comments on latest blog post: 1) Hash functions do not use "advanced math". In most cases, they just mess around with the values a lot, and then they get publicized in crypto circles for a few years, and people figure they're safe if no one finds a break. Actually, few cryptographic primitives are provably reducible to hard mathematical problems. 2) 30-character salts are just silly. Twenty random ASCII characters is already wa |
| 19:03 | <AryehGregor> | y overkill. 3) You don't need an industrial supercomputer to crack short passwords. I just wrote a program (http://aryeh.name/gitweb.cgi?p=hpc-final;a=tree;f=single) that can do 220 million SHA1 hashes a second on a $200 GPU. That gives you all 6-character ASCII passwords in about an hour if you don't make the hash slower. 4) For slow hashes, PBKDF works fine (see RFC 2898). Basically just iterate a standard hash function a large number |
| 19:03 | <AryehGregor> | of times, it's about two lines of code. |
| 19:03 | <AryehGregor> | (It would be nice if XChat used a multiline input for long messages so I had some idea how long it was before I pasted.) |
| 19:04 | <jwalden> | heh |
| 19:04 | <TabAtkins> | AryehGregor: Huh. I was sure that hashing was closely related to crypto. Oh well. |
| 19:04 | <AryehGregor> | (It would also be nice if I could find a better client than XChat.) |
| 19:04 | <AryehGregor> | TabAtkins, hashing is part of crypto, sure. |
| 19:05 | <AryehGregor> | It doesn't involve advanced math, though. The math is pretty basic. |
| 19:06 | <AryehGregor> | (at least for the hash functions I'm familiar with, which currently consists of SHA1) |
| 19:06 | <TabAtkins> | I'll make a correction. My point is just that people shouldn't screw around with trying to create their own hash. |
| 19:06 | <AryehGregor> | No, obviously not. |
| 19:07 | <AryehGregor> | But it's not math, it's cryptanalysis, and in particular being studied by lots of crypto people for a few years. |
| 19:07 | <TabAtkins> | (2) 20 vs 30 char salt doesn't really matter. I just chose 30 arbitrarily because it produced a pleasingly large number. |
| 19:07 | <AryehGregor> | Which is why you have things like the SHA3 competition. The idea is that cryptographers have a lot of incentive to break the finalists, because they've already seen a lot of scrutiny, and if you can find a break that no one else did, that's a pretty good publication. |
| 19:08 | <TabAtkins> | And because I often use 30char strings to inject entropy when I'm hashing something for verification purposes. |
| 19:10 | <AryehGregor> | Actually, regarding (4), PBKDF is not optimal for slowing down GPUs, which is what that HPC final link I gave is about. But I didn't come up with a superior system that's easy to deploy in a typical web app. |
| 19:11 | <TabAtkins> | (3) I didn't say you needed one. I said that you could use one to get sub-second cracking times, which is an impressively small number. |
| 19:11 | <AryehGregor> | I can get sub-second cracking times for four-letter passwords. |
| 19:11 | <AryehGregor> | With arbitrary ASCII. |
| 19:11 | <TabAtkins> | I don't doubt it. |
| 19:13 | <AryehGregor> | It's a lot more impressive to say it can be cracked on a $200 GPU, even if the timespan is a bit longer. |
| 19:13 | <AryehGregor> | An 8-character password selected completely at random can be done in less than a week. |
| 19:14 | <AryehGregor> | (if it's ASCII) |
| 19:14 | <TabAtkins> | I'll amend it. |
| 19:18 | jwalden | sees "pretty good publication" and immediately mentally abbreviates it, to hilarity |
| 19:19 | <TabAtkins> | AryehGregor: So no recommendations on slow hashes? |
| 19:19 | <AryehGregor> | TabAtkins, PBKDF, as I said. |
| 19:19 | <AryehGregor> | Go look at the RFC. |
| 19:19 | <AryehGregor> | Just take any hash function and run it lots of times. |
| 19:19 | <TabAtkins> | Oh, I thought you just said it wasn't optimal for slowing down GPUs. |
| 19:19 | <AryehGregor> | $hash = $pass; for ($i = 0; $i < 10000; $i++) { $hash = sha1($hash); } |
| 19:20 | <AryehGregor> | Well, it's not, but that's hard to avoid. The GPU will still be probably 100 times faster than the CPU of comparable cost, certainly tens of times faster. |
| 19:20 | <AryehGregor> | The problem is that GPUs just have vastly more compute units than CPUs. The way to slow it down a bit would be to throw in uncacheable memory access, but that's hard to conveniently arrange. |
| 19:20 | <AryehGregor> | PBKDF will still make the problem orders of magnitude better. |
| 19:21 | <AryehGregor> | Like, say, four orders of magnitude better, which buys you two arbitrary ASCII characters. |
| 19:21 | <TabAtkins> | Gotcha. Reading the RFC now, then will push an update. |
| 19:29 | <TabAtkins> | AryehGregor: Made the edits. |
| 19:30 | <TabAtkins> | Also, at some point over the xmas weekend I should finally add comment functionality, so you can just leave the comments on the blog itself. ^_^ |
| 19:30 | <AryehGregor> | You still say "hash functions use advanced math closely related to cryptography". |
| 19:31 | <TabAtkins> | s/advanced math/techniques/ |
| 19:32 | <AryehGregor> | Well, that paragraph is no longer technically incorrect, I don't think. |
| 19:33 | <TabAtkins> | Heh. |
| 19:33 | <AryehGregor> | Still a bit confused, but good enough. |
| 19:34 | <TabAtkins> | I'm confused about what's confused. |
| 19:37 | <AryehGregor> | Well, you know how sometimes you read something about a subject you're an expert in and go "Okay, the author of this clearly only has a vague grasp of what they're talking about"? It's like that. |
| 19:37 | <AryehGregor> | I mean, no offense. |
| 19:37 | <TabAtkins> | Hmm. You shouldn't be getting that impression at all. Perhaps it's because I'm purposely speaking in low-level terms? |
| 19:38 | <AryehGregor> | You can speak in low-level terms and still make it clear that you know what you're talking about. |
| 19:38 | <TabAtkins> | I mean, aside from the fact that I was pretty sure cryptography was strong math rather than just screwing around with stuff, I *do* know what I'm talking about here. |
| 19:38 | <AryehGregor> | Like, "it's impossible to make a transformation actually one-way" -- whether one-way functions exist is one of the major open problems in cryptography. |
| 19:38 | <AryehGregor> | "hash functions use techniques closely related to cryptography" -- no idea what that's even supposed to mean, really. |
| 19:38 | <TabAtkins> | If it's a deterministic transformation it's reversible in principle. |
| 19:39 | <AryehGregor> | Not necessarily computationally reversible. |
| 19:39 | <TabAtkins> | Sure, but I'm not saying that. |
| 19:39 | <AryehGregor> | That's what "one-way function" means. |
| 19:39 | <AryehGregor> | http://en.wikipedia.org/wiki/One-way_function |
| 19:39 | <TabAtkins> | I didn't use that term. |
| 19:39 | <AryehGregor> | You used the term "one-way". |
| 19:39 | <TabAtkins> | Yes? |
| 19:40 | <AryehGregor> | Together with "transformation". |
| 19:40 | <AryehGregor> | Well, whatever. |
| 19:40 | <TabAtkins> | Yes? |
| 19:40 | <AryehGregor> | And "transformation" means the same thing as "function". |
| 19:40 | <TabAtkins> | Sure, but you're still talking about a different domain. Something being computationally infeasible is different than something being impossible. |
| 19:41 | <AryehGregor> | Yes, but the language you use is still confusing to someone who knows what a one-way function is, because you're using jargon to mean something from its standard meaning. Even if that fits its colloquial meaning. |
| 19:41 | <AryehGregor> | So it makes it sound like you don't know what a one-way function is. |
| 19:42 | <TabAtkins> | I'm not talking to people who already know what a one-way function is. I'm saying that it's technically impossible to make a transformation unreversible, and then stating that it's possible to make it *very difficult* to reverse. |
| 19:42 | <AryehGregor> | Likewise, saying that "hash functions use techniques closely related to cryptography" makes it sound very much like you don't know how major hash functions were actually developed. |
| 19:42 | <AryehGregor> | Okay, well, anyway. |
| 19:43 | <AryehGregor> | Doesn't matter, the explanation is good enough for its target audience. |
| 19:43 | <TabAtkins> | That latter sentence is still really clumsy. Let me tweak it. |
| 19:45 | <TabAtkins> | Okay, tweaked. |
| 19:46 | <TabAtkins> | Argh, though, I'm still bothered by your other nitpick. In the immediately preceding sentence I explicitly call hashes "one-way transformations". The sentence in question, then, is just a clarification of the term. |
| 19:46 | <Hixie> | jwalden: sure. i meant that it should apply to the workers, e.g. via the http headers used for loading the script. |
| 19:47 | <paul_irish> | Hixie: know of anything in the spec about iframe recursion? |
| 19:47 | <AryehGregor> | Of course, a one-way function need not be a useful cryptographic hash function. One-wayness is really too weak for passwords, because it only cares about random inputs, and passwords are not close to random. |
| 19:47 | <jwalden> | Hixie: yes; the issue here would be a non-CSP'd page creating that shared worker (with eval enabled), then a CSP'd page with eval forbidden connecting to that shared worker and getting working eval |
| 19:47 | <paul_irish> | http://jsfiddle.net/TFvev/1/show/ recurses forever and ever in webkit but cuts off in Op and FF at some point. |
| 19:47 | <Hixie> | paul_irish: there are various things, do you have a more specific question? |
| 19:48 | <AryehGregor> | I wonder if there are definitions that better capture what's needed in a good password hash function. |
| 19:48 | <TabAtkins> | Sure. By the time people get into the subject enough to know that I'm being overly-simplistic, they should know enough to understand the full import. |
| 19:48 | <Hixie> | paul_irish: hm |
| 19:48 | <jwalden> | whereas with a normal worker it's straightforward: CSP blocks eval in page, it blocks it in workers |
| 19:48 | <paul_irish> | Hixie: just noticing some deliberate differences. |
| 19:48 | <paul_irish> | not a big deal |
| 19:48 | <AryehGregor> | An obvious modification is to allow the attacker to determine the probability distribution of inputs, and then require that they should be able to do only negligibly better than guessing the mode. |
| 19:48 | <Hixie> | paul_irish: i don't recall there being anything about a depth per se |
| 19:49 | <AryehGregor> | (for any arbitrary input distribution of the attacker's choice) |
| 19:49 | <Hixie> | paul_irish: but it's probably reasonable for the UA to have a "hardware-implementation clause" limit |
| 19:49 | <Hixie> | er |
| 19:49 | <Hixie> | hardware-limitation |
| 19:49 | <TabAtkins> | paul_irish: Change the example so that, after a short timeout, a script walks down the iframes and puts INCEPTION in the bottommost one. |
| 19:50 | <paul_irish> | lol |
| 19:50 | paul_irish | *applause*. |
| 19:51 | AryehGregor | observes that he also once reported an iframe nesting incompatibility between browsers and Hixie also brushed it off as hardware limitations |
| 19:52 | <TabAtkins> | 32 nested iframes should be enough for anyone. |
| 19:52 | <TabAtkins> | Urgh, s/32/64/ |
| 19:52 | <AryehGregor> | It's good to spec hardware limitations within reason, the way you can have a max nesting level of 53 or whatever Unicode bidi algorithm. |
| 23:24 | <AryehGregor> | What's up with Wordpress replacing all hyphens with en dashes, when most hyphens are actually more correctly hyphens? |
| 23:36 | <gsnedders> | It depends what you're writing, and upon style, etc. — in my case, most probably are en/em dashes. |
| 23:42 | <AryehGregor> | But it's better to leave things the way the user typed them than change them, if you have a substantial possibility of mis-changing them. Even if it's under 50%. Because if you leave it alone you've done nothing wrong, you just repeated what the user wrote. But if you change it incorrectly, you make it impossible for the user to write correctly. |
| 23:42 | <gsnedders> | Indeed. I'm absolutely against screwing stuff. |
| 23:42 | <AryehGregor> | Changing hyphens to en dashes really only makes sense if you use appropriately narrow heuristics. |
| 23:43 | <AryehGregor> | For instance, if the hyphen is both preceded and followed by a space, or if it's in between two digits. |
| 23:43 | <AryehGregor> | Then it's almost certainly meant to be an en dash (I can't think of any legitimate hyphen use there). |
| 23:44 | <AryehGregor> | On a totally different note, searching for my name online gives almost exclusively computing-related things. |
| 23:44 | <AryehGregor> | This is sad, because it makes it look like I have no interests other than computers. When in fact, I just don't do them online much. |
| 23:46 | <gsnedders> | The internet makes me look like a mixture of an emo and a computer geek. |
| 23:54 | <MrOpposite> | Good night |
| 23:56 | <AryehGregor> | Are you, in point of fact, a mixture of an emo and a computer geek? |
| 23:57 | <gsnedders> | No. I was never as emo as I overtly appeared, and nor am I solely a computer geek. |
| 23:58 | <gsnedders> | (And I certainly don't appear emo now) |