| 02:06 | <AryehGregor> | hsivonen, could you just do something like: @namespace math url(http://www.w3.org/1998/Math/MathML); math { display: none } math|math { display: block } math|math + img { display: none } |
| 02:07 | <AryehGregor> | That has poor fallback if CSS is disabled, of course. Alternatively, could just use JavaScript. |
| 03:27 | <AryehGregor> | othermaciej_, I don't think pharming is a man-in-the-middle attack. MITM suggests to me that the attacker is intercepting network traffic not directed to him, rather than redirecting traffic to him. It's a network-level phenomenon. DNS poisoning seems like a different type of attack to me. |
| 03:28 | <AryehGregor> | Although I guess if you take a more abstract view, you could view it as an implementation detail that it happens to work at the DNS layer instead of the IP layer. |
| 03:28 | <othermaciej_> | AryehGregor: man-in-the-middle means each intended party to the transaction thinks it is talking directly to its corresponding party, but is really talking to someone else |
| 03:29 | <othermaciej_> | with pharming, the hostile server doesn't have to ever talk to the real server if it doesn't want to, but it could |
| 03:29 | <othermaciej_> | point being, it's a real attack that would completely defeat the proposed hashing measure |
| 03:29 | <AryehGregor> | Well, so is the "corresponding party" a physical server, or an IP address? Would you view phishing as a MITM attack too, because the user thinks he's interacting with a different site than he is? |
| 03:30 | <othermaciej_> | at first I thought the salted hash thing might be safe against passive attackers at least, but it seems to be vulnerable to replay attacks as well |
| 03:30 | <othermaciej_> | phishing is a social engineering attack |
| 03:31 | <AryehGregor> | . . . also, is pharming really that common? |
| 03:31 | <othermaciej_> | on open wireless networks, yes |
| 03:31 | <AryehGregor> | Ah, interesting. |
| 03:31 | <othermaciej_> | or with malware-installed hosts file hacks |
| 03:31 | <othermaciej_> | or at least, common enough to scare the hell out of financial institutions |
| 03:32 | <AryehGregor> | Well, anything that can alter hosts files can subvert the browser too. |
| 03:32 | <othermaciej_> | Strict Transport Security (STS) was invented in part to protect against pharming attacks on SSL sites |
| 03:32 | <othermaciej_> | since you wouldn't be able to use a fake cert or a non-SSL site on your pharming redirect |
| 03:33 | <AryehGregor> | Well, you can also do more conventional MITM attacks if you set up a free wireless network somewhere. |
| 03:33 | <othermaciej_> | sure, but subverting DNS is easier than subverting IP traffic on the fly |
| 03:33 | <AryehGregor> | Makes sense. |
| 03:33 | <othermaciej_> | DNS cache poisoning can even let you do it without physical access to the victim network link |
| 03:33 | <AryehGregor> | Now, hopefully when STS is widely deployed, browsers can be convinced to not have horribly misleading error pages for SSL failures. :) |
| 03:35 | <othermaciej_> | "horribly misleading" in what way? |
| 03:36 | <othermaciej_> | browsers are certainly leaning more towards making self-signed or expired certs look more like hard errors than click-through warnings |
| 03:36 | <othermaciej_> | STS of course requires the hard error for sites that opt in |
| 03:37 | <AryehGregor> | "Horribly misleading" in that they imply that the user is in some danger if they proceed, when with ~100% certainty it's not actually a malicious site. Since, you know, operators of malicious sites usually are smart enough not to trigger browser warnings. |
| 03:37 | <AryehGregor> | This paper says that practically no actually harmful sites use SSL at all, and the ones that do have valid certs: http://research.microsoft.com/en-us/um/people/cormac/papers/2009/solongandnothanks.pdf |
| 03:38 | <AryehGregor> | So while it might make sense to display some warning, the wording is very unrealistically harsh in all browsers I've seen. |
| 03:38 | <AryehGregor> | Especially lately. |
| 03:40 | <AryehGregor> | Good night. |
| 03:58 | <a-ja> | any particular reason opgroup isn't allow in a datalist? |
| 03:58 | <a-ja> | err....optgroup |
| 07:01 | <micheil> | Hixie: do you know anything of who wrote the websocket client library for chrome / chromium? |
| 07:02 | <micheil> | I'm noticing some odd behaviour with that specific implementation dropping the first packet after it's written |
| 07:02 | <othermaciej> | micheil: file a bug - http://bugs.webkit.org/ |
| 07:02 | <micheil> | no, I'm not sure if it's a bug or not |
| 07:02 | <micheil> | because the server I'm sending from is one I'm writing |
| 07:03 | <micheil> | I'm just doing another test, one sec. |
| 07:03 | <othermaciej> | ah |
| 07:04 | <othermaciej> | anyway - you might be able to find people who know about the implementation in #webkit - most of it is in WebKit |
| 07:04 | <micheil> | hmm.. |
| 07:04 | <micheil> | I've found the c++ source code, so I've been reading through that |
| 07:04 | <micheil> | it's a bit of an odd error that I'm seeing |
| 07:05 | <micheil> | after the first packet is sent, my server immediately echoes it back |
| 07:05 | <micheil> | rather, after a packet is sent |
| 07:05 | <micheil> | however, the first time I send it never reaches chrome |
| 07:11 | <micheil> | yeah. I think it's definitely a bug with chrome / chromium now |
| 07:12 | <micheil> | I've got the server logging each time it writes, and I'm writing out timestamps |
| 07:12 | <micheil> | down to the milisecond |
| 07:12 | <franksalim> | micheil, have you checked in wireshark? |
| 07:12 | <micheil> | actually. I haven't |
| 07:12 | <micheil> | I shall though. |
| 07:12 | <micheil> | thanks for reminding me |
| 07:14 | <micheil> | although, I'm pretty sure the data is leaving the server |
| 07:14 | <micheil> | because otherwise I wouldn't get the logging of it, nor would I be able to handshake |
| 07:14 | <annevk> | not sure if it matters, but I believe they implement some older version of the protocol |
| 07:15 | <micheil> | they do |
| 07:15 | <micheil> | and my server is currently only compliant with it |
| 07:15 | <micheil> | (I've have code in place for the next version of the protocol) |
| 07:15 | <micheil> | it just seems really odd this |
| 08:34 | <jgraham> | annevk: Murakami++ |
| 08:59 | <annevk> | argh, due to a recent upgrade of Ubuntu 10.04 my wireless drivers are borked |
| 08:59 | <annevk> | my laptop is now cabled |
| 09:01 | <annevk> | jgraham, yeah, he's great |
| 09:15 | <annevk> | "It is not expected as I said that many authors will be hand crafting caption files." is this format even in use? |
| 09:16 | <othermaciej> | which - TTML? |
| 09:16 | <annevk> | yeah |
| 09:16 | <othermaciej> | I think there is some amount of it in the wild |
| 09:16 | <othermaciej> | don't really know how much |
| 09:16 | <annevk> | I also wonder if that guy is advocating the IE Team's position on the matter or some other product inside Microsoft... |
| 09:16 | <othermaciej> | I do not know of a tool to author it |
| 09:17 | <othermaciej> | he is one of the co-authors of TTML |
| 09:17 | <annevk> | I encounter SRT files all the time |
| 09:17 | <othermaciej> | I imagine this informs his views |
| 09:17 | <annevk> | aah |
| 09:17 | <othermaciej> | am I right that what he's saying about XSL-FO and CSS is crazy? |
| 09:18 | <othermaciej> | like I don't think his reply to me answered my questions at all |
| 09:23 | <annevk> | in theory the CSS and XSL:FO have some relation but in practice they are quite different |
| 09:24 | <annevk> | and if I remember correctly CSS vertical layout will not match XSL:FO (but I could be wrong as I do not pay close attention to those discussions usually) |
| 09:30 | <micheil> | okay. bug no more, I changed nothing and chrome decided to like me. |
| 09:40 | <othermaciej> | I figure that since XSL-FO and CSS both have their own normative definitions of layout and both have been changing independently, it would be a remarkable coincidence if their definitions matched exactly |
| 09:43 | <annevk> | Even if all the rhetoric was true the format would still be too complex, imo, and completely different from existing practices |
| 09:44 | <annevk> | An XML-based subtitling format has apparently been tried in the past, and rejected by the subtitling community |
| 09:44 | <annevk> | http://en.wikipedia.org/wiki/Universal_Subtitle_Format |
| 09:45 | <annevk> | "The format has come under criticism, especially from the fansub community [1], because compared to the format it aims to replace, Advanced Substation Alpha (which is based on comma-separated values), it is more verbose and far harder for software to read, write and manipulate." |
| 09:45 | <annevk> | "It is also much harder to edit "by hand" in text editors such as notepad. For these reasons, as well as the lack of a generic cross-platform parsing/rasterizing library and mature editing programs that natively support it, the format has not gained wide acceptance." |
| 09:45 | <annevk> | I haven't seen anything that suggests why it would go down differently with TTML |
| 09:47 | <annevk> | Looking at the XML of USF it looks scarily similar to TTML: http://blog.aegisub.org/2008/07/universal-subtitle-format-post-mortem.html |
| 09:47 | <annevk> | e.g. <text style="NarratorSpeaking"> and having <styles> and <style> |
| 09:48 | <annevk> | Maybe I'll dig into this more |
| 09:50 | <othermaciej> | it can't possibly have as many namespaces as TTML |
| 09:52 | <annevk> | W3C Process ensures those were added I guess |
| 09:52 | <annevk> | USF was implemented without XML parsers and without much of its features: http://itdp.fh-biergarten.de/mplayer-dev-eng/2003-12/bin00005.bin |
| 09:53 | <annevk> | Its original specification has died :/ |
| 09:55 | <hsivonen> | AryehGregor: yes, that would work, too, if the + selector works in all legacy browsers that Wikipedia cares about |
| 09:55 | <annevk> | USF is not to be confused with http://universalsubtitles.org/ |
| 10:29 | <annevk> | Seems nigh-on impossible to find a lot of information about USF |
| 10:30 | <annevk> | ooh sweet |
| 10:30 | <annevk> | the French and Spanish versions of the Wikipedia USF entry have way more info: http://fr.wikipedia.org/wiki/Universal_Subtitle_Format |
| 10:35 | <annevk> | looks pretty close to http://www.w3.org/TR/ttaf1-dfxp/ except with less namespaces... |
| 11:01 | <karlcow> | hmmm not sure, there is little demand for 縦組, maybe it is just not visible because in Japanese community. cf roc message http://www.w3.org/mid/p2y11e306601005072153z36897033zb795cf5735f0efaf⊙mgc |
| 11:12 | <annevk> | Japanese designers I talked weren't that interested in it |
| 11:12 | <annevk> | but maybe there will be interest if it is available, who knows |
| 11:44 | <doublec> | annevk, this post lists some dfxp authoring tools: http://blogs.adobe.com/accessibility/2007/04/captioning_in_flash_cs3.html |
| 11:44 | <doublec> | I think most of the dfxp/ttml love is coming from commercial usage |
| 11:44 | <doublec> | vs srt coming from fan comminities |
| 11:44 | <doublec> | communities I mean |
| 12:30 | <MikeSmith> | hsivonen: if you're around, I wanted to ask about http://bugzilla.validator.nu/show_bug.cgi?id=438 |
| 12:57 | <karlcow> | annevk: For Web design, indeed I haven't seen a lot of interests. But with the rise of epub (which will be converted to html5 in a pragmatic fashion), I think japanese books will create a strong demand. |
| 12:57 | <MikeSmith> | true that |
| 12:57 | <MikeSmith> | karlcow: you talking about vertical text support? |
| 12:58 | <karlcow> | yes |
| 13:00 | <MikeSmith> | given that most Japanese prose books use vertical text, to reproduce the same kind of reading experience in an e-book would seem to need vertical text support |
| 13:13 | <karlcow> | MikeSmith: exactly |
| 13:23 | <Dashiva> | http://twitter.com/richardhoppes/status/13647484566 |
| 14:24 | <annevk> | karlcow, yeah, with the exception of programmer books :p |
| 14:25 | <karlcow> | hehe |
| 14:25 | <karlcow> | novels :) |
| 14:26 | <annevk> | it's unfortunate I can't read it and have to wait to 4Q11 for 1Q84 |
| 16:09 | <AryehGregor> | hsivonen, pretty sure no one's implementing MathML-in-text/html who hasn't already implemented the sibling selector. :) |
| 17:40 | <AryehGregor> | hsivonen, the example of a quadratic formula from Wikipedia's MathML article renders notably worse in MathML than in LaTeX, in Firefox 3.7. The radical is too small. |
| 17:41 | <AryehGregor> | It seems the part that hangs down on the left doesn't go down far enough, like the contents have zero height. |
| 17:41 | <AryehGregor> | http://www.mozilla.org/projects/mathml/demo/roots.xhtml looks buggy (in different ways) in both Firefox and Opera. |
| 17:42 | <AryehGregor> | (would still be great to get this working, though, to encourage everyone to improve) |
| 17:43 | <AryehGregor> | (working on Wikipedia, I mean) |
| 18:56 | <dbaron> | AryehGregor, hrm, yeah, that doesn't look very good |
| 18:57 | <dbaron> | AryehGregor, I wonder if it depends on font availability, though... |
| 18:58 | <AryehGregor> | Dunno. |
| 18:58 | <AryehGregor> | Can only report what I see. |
| 18:58 | <dbaron> | I certainly remember it looking better in the past |
| 19:00 | <dbaron> | AryehGregor, it does |
| 19:00 | <dbaron> | AryehGregor, 'sudo apt-get install otf-stix' makes a huge difference for me |
| 19:00 | <dbaron> | AryehGregor, (i.e., installing the STIX fonts) |
| 19:00 | <AryehGregor> | Hmm. |
| 19:01 | <dbaron> | AryehGregor, Downloadable fonts may be quite helpful for mathml |
| 19:01 | <dbaron> | Though I wonder if we should think about shipping math fonts (now that we have downloadable font support) |
| 19:02 | <dbaron> | I wonder if wikipedia could serve the STIX fonts via @font-face |
| 19:02 | <AryehGregor> | Yeah, much better with those fonts, although still not quite as nice as LaTeX. |
| 19:03 | <AryehGregor> | We could, but that would be undesirable from our perspective. Surely if this is necessary for good math rendering, and Firefox aims to support good math rendering, it should ship the fonts? That seems a lot more efficient than every website that uses math being forced to distribute the fonts to all viewers. |
| 19:03 | <AryehGregor> | Although I realize you have concerns about download size, etc. |
| 19:04 | <dbaron> | and potentially license compatibility |
| 19:05 | <AryehGregor> | The SIL Open Font License is very permissive, and should be compatible with the GPL since you aren't linking the fonts. |
| 19:06 | <AryehGregor> | I guess it's technically not GPL-compatible, but as long as it's used only for fonts, that's not a practical issue. |
| 19:06 | <AryehGregor> | Anyway, your call. It would be nice if I could get MathML-in-text/html working in Wikipedia at some point; we'll decide after that when we want to make it default for all browsers that support MathML-in-text/html. |
| 19:07 | <AryehGregor> | Which will be more likely the better the support is, I guess. |
| 19:07 | AryehGregor | shrugs |
| 19:07 | <dbaron> | Well, MathML tends not to be a big priority given the lack of support in other browsers |
| 19:08 | <AryehGregor> | I'm told support in WebKit is underway, and Opera already supports it in XML. So hopefully soon it will be everyone but IE, as usual. :) |
| 19:08 | <AryehGregor> | But no, not a big deal, as you say. |
| 19:09 | <AryehGregor> | Especially as long as actual LaTeX looks better anyway -- which it still seems to, for whatever reason. |
| 19:09 | <AryehGregor> | Better MathML support is hardly my top priority either, but it would be kind of nice. |
| 19:22 | <annevk> | Hixie, I figured out the zip command and can now generate a zip file of complete.html splitted |
| 19:22 | <annevk> | Hixie, I generate a special copy without --absolute enabled |
| 19:23 | <annevk> | Hixie, if you need --absolute let me know and also let me know the other details :) |
| 19:23 | <annevk> | Hixie, having said all that, I might have fallen asleep by the time you get this |
| 21:06 | <jgraham> | AryehGregor: Opera doesn't really support MathML, just some subset that can be implemented with CSS layout. So I guess it won't ever look too pretty |
| 21:06 | <AryehGregor> | Oh, interesting. |
| 21:08 | <jgraham> | (there is even a spec for that subset somewhere) |
| 21:08 | <jgraham> | Of course if there was any atual content, it might encourage us to spend time getting good support |
| 21:08 | <AryehGregor> | Yeah, that's my thought. |
| 21:10 | <AryehGregor> | I hope to fix that at some point by letting Wikipedia emit MathML, it's on my to-do list: http://www.mediawiki.org/wiki/User:Simetrical |
| 21:11 | <Dashiva> | MathML has a bad fallback story on that subset too |
| 21:12 | <Dashiva> | The OpenGL docs that use MathML for [x, y] range expressions become [x] |
| 21:18 | <AryehGregor> | Why would you use MathML for [x, y] ranges? |
| 21:24 | <Dashiva> | Why wouldn't you use it when you're already using mathml? |
| 21:25 | <AryehGregor> | Is the output even distinguishable from HTML? |
| 21:25 | <AryehGregor> | I mean, if it works. |
| 21:27 | <Dashiva> | mathml fences are fancy |
| 21:28 | <Dashiva> | The height and alignment and such |
| 21:28 | <Dashiva> | I suppose there are entities you can use, but then you have to wrangle those instead of a simple element name |
| 21:40 | <AryehGregor> | $[x, y]$ in LaTeX gets typeset pretty much identically to [<var>x</var>, <var>y</var>] in HTML. |
| 21:40 | <AryehGregor> | No funny brackets. |