| 00:04 | <bga> | > SQL.js: SQLite Compiled to JavaScript via Emscripten |
| 00:04 | <bga> | facepalm |
| 00:33 | <AryehGregor> | rniwa, I filed spec feedback months ago asking that that be changed. IIRC, tantek responded favorably but never did it. |
| 00:36 | <rniwa> | AryehGregor: okay. |
| 00:39 | <rniwa> | aklein: https://bugs.webkit.org/show_bug.cgi?id=80452 |
| 01:17 | <austincheney> | can somebody help explain the necessity to HTTP+AES to me? |
| 01:17 | <austincheney> | i have been reading the emails and I am not clear on the use condition |
| 01:17 | <austincheney> | HTTP is pretty simple in that there is only a request and a response and then the connection is abandoned and forgotten |
| 01:18 | <austincheney> | and the response is already encrypted if you use https |
| 01:18 | <austincheney> | this leaves the need to protect the request from interception, is that right? |
| 01:18 | <austincheney> | as in a man in the middle attack? |
| 01:21 | <othermaciej> | my understanding is that it's supposed to protect content stored on a CDN that should be kept confidential from the CDN provider |
| 01:21 | <austincheney> | then you would need to encrypt the content opposed to encrypting the transmission |
| 01:21 | <zewt> | seems like a rather shortsighted thing to bake a particular encryption algorithm right into the name |
| 01:22 | <austincheney> | i am unclear why you would want to hide the transmission of content from a CDN? |
| 01:23 | <zewt> | austincheney: i'm not familiar with that in particular, but http does support data transforms (Transfer-Encoding) which can be precalculated |
| 01:23 | <Philip`> | Would it be any harder to move to a new http+rot13:// when the algorithm changes, than to support multiple algorithms under the same protocol name? |
| 01:23 | <zewt> | well, that part seems obvious ... |
| 01:23 | <zewt> | (if you want to be able to serve private data) |
| 01:24 | <austincheney> | a CDN is a service though, and by connecting into said service you are likely obligated to let the service know about your role in resource consumption |
| 01:25 | <zewt> | i'm certainly not obligated to give amazon access to the data i store in s3 |
| 01:25 | <austincheney> | right, that is why you encrypt the data |
| 01:25 | <zewt> | which is the point, I believe :) |
| 01:25 | <austincheney> | but Amazon has every right to be aware of the transmission though |
| 01:25 | <zewt> | the provider I use to send bits has no right to know the contents of those bits |
| 01:26 | <austincheney> | right, and they won't if the content is encrypted |
| 01:26 | <zewt> | (and if some low-rent providers claim that right in seedy TOS's, then that's between the user and the provider; it's not relevant to protocol development) |
| 01:27 | <zewt> | sorry, I really have no idea what you're saying; the entire point of http+aes is an encryption mechanism, right? |
| 01:27 | <austincheney> | no |
| 01:28 | <austincheney> | its encrypting transmission opposed to encrypting content |
| 01:28 | <Philip`> | Is this meant to be for really confidential data that would cause irreparable harm if released, or for cases where an easier solution is just to sue Amazon for violating their TOS if they publicly release the private data? |
| 01:28 | <zewt> | ssl encrypts transmission |
| 01:28 | <zewt> | (url to http+aes? generic name is ungooglable) |
| 01:28 | Philip` | hasn't read the relevant thread at all and has no idea what the context of the discussion is |
| 01:28 | <austincheney> | SSL encrypts a HTTP response |
| 01:29 | <zewt> | but the name sounds like "aes block encryption + hashes + client-side decryption key" |
| 01:29 | <zewt> | no, ssl encrypts the entire exchange |
| 01:29 | <zewt> | request and response |
| 01:31 | <zewt> | (oh, it's something already in the spec? odd, never even heard of it before) |
| 01:34 | <zewt> | Hixie: no block hashes in http+aes? |
| 01:34 | <zewt> | austincheney: and yes, it appears to be what I said |
| 01:38 | <zewt> | defining encryption without hashes to prevent corruption/tampering is odd--the two normally go together, the cost is very small, and it prevents weaknesses that typical users may not be aware of |
| 01:44 | <zewt> | holy hell what just happened |
| 01:45 | <zewt> | i deleted a big block of quoted text in gmail, and it flipped two lines of quoted text upside down |
| 01:45 | <zewt> | which happened to be two lines of javascript code--confusing as hell |
| 02:27 | <AryehGregor> | Hixie, what's the reason for using only AES for http+aes instead of doing full authenticated encryption for the response contents? Just throw in an HMAC using the same key, and then it's tamperproof as well as copy-proof. |
| 02:28 | <Hixie> | what's the use case for that? |
| 02:28 | <AryehGregor> | At basically no additional cost. |
| 02:28 | <MikeSmith> | great to finally get Apple feedback on the Notifications API |
| 02:30 | <zewt> | AryehGregor: same as what I said: <zewt> defining encryption without hashes to prevent corruption/tampering is odd--the two normally go together, the cost is very small, and it prevents weaknesses that typical users may not be aware of |
| 02:30 | <AryehGregor> | zewt, yes. |
| 02:30 | <zewt> | for example, people--not generally being encryption experts--may assume that data which is encrypted can't be modified, which isn't true if there's no validation |
| 02:30 | <AryehGregor> | Hixie, maybe you don't trust the CDN not to modify the data either. |
| 02:31 | <AryehGregor> | You need to split it into blocks somehow and HMAC each block, though, to allow streaming. |
| 02:31 | <AryehGregor> | This can probably be offloaded on some existing well-understood authenticated encryption implementation. |
| 02:31 | <zewt> | as a nice side benefit, you get verification against innocent HTTP transmission errors (not a primary use case, just a nice extra) |
| 02:32 | <Hixie> | AryehGregor: dude if you don't trust the cdn not to modify the data you have much bigger problems imho |
| 02:32 | <zewt> | Hixie: why should I trust them more than I have to? |
| 02:32 | <zewt> | (plus intermediaries, for the non-https version) |
| 02:33 | <Hixie> | realistically speaking, i've never heard of anyone who doesn't trust the cdn not to modify data |
| 02:33 | <Hixie> | i have heard of people not trusting their cdn to snoop the data |
| 02:34 | <zewt> | if the data is validated, then I don't have to trust the internet, either |
| 02:36 | <Hixie> | https already solves the internet part |
| 02:36 | <zewt> | if https could always be used, then you wouldn't have defined http+aes :) |
| 02:37 | <Hixie> | they solve unrelated problems |
| 02:37 | <Hixie> | so i don't really understand what you mean? |
| 02:37 | <zewt> | hmm? |
| 02:37 | <zewt> | why would you define http+aes, if you could always use https+aes? |
| 02:38 | <Hixie> | AryehGregor: (btw i'm not against the idea in principle. send e-mail or file a bug with concrete details and i'll take a look.) |
| 02:38 | <zewt> | it just seems like this is violating a fundamental principle of encryption: always verify the results |
| 02:38 | <Hixie> | zewt: completenes |
| 02:39 | <Hixie> | s |
| 02:40 | <zewt> | also, having a verification mechanism means you can tell if you've got a wrong password, instead of just getting random data |
| 02:45 | <Hixie> | zewt: getting noise is a pretty good indicator that you got the wrong key... |
| 02:46 | <zewt> | not an indicator that you can report programmatically |
| 02:47 | <zewt> | wrong password should be reported as "wrong password", not "mysteriously corrupt file" |
| 02:48 | <zewt> | (eg. XHR should report an error, not happily hand you a buffer filled with random-looking bytes) |
| 03:21 | <Hixie> | it's telling that for most proposals for html and other web specs, we get proposals from either browser vendor engineers or authors / web devs |
| 03:22 | <Hixie> | whereas this drm thing comes from a very different segment |
| 03:22 | <zewt> | (what's confusing is why anyone's even pretending to listen) |
| 03:40 | <ukai> | anyone who maintain Chromium Mac Release bot? svn failure: http://build.webkit.org/builders/Chromium%20Mac%20Release/builds/32798/steps/svn/logs/stdio |
| 03:40 | <ukai> | oops |
| 03:40 | <ukai> | wrong channel |
| 04:05 | <StoneCypher> | Hixie: in your experience, what parts of CSS do people tend to misunderstand the most? |
| 04:19 | <MikeSmith> | related to the Encrypted Media Extensions proposal, among the requirements that should be listed out somewhere specifically is "decrypted data must not be available to Javascript" |
| 04:19 | <MikeSmith> | if that is indeed one of the requirements behind the proposal (which it seems to be) |
| 04:39 | <zewt> | ... isn't it rather "must not be available to anything open source or not end-to-end encrypted"? heh |
| 04:56 | <Hixie> | StoneCypher: i'm not in the loop enough to say these days. used to be th inline box model, back around 2000. |
| 04:56 | <Hixie> | StoneCypher: i once had to explain it to bert and hakon (who invented it!) ;-) |
| 05:00 | <Hixie> | anyone know of a version of hexdump that displays things in binary instead of hex? |
| 05:00 | <Hixie> | ooh, xxd -b maybe |
| 05:00 | <Hixie> | sweet |
| 05:01 | <StoneCypher> | i got to talk to hakon once through michael day |
| 05:01 | <StoneCypher> | was fun. |
| 05:02 | <MikeSmith> | zewt: yeah, true |
| 05:24 | <MikeSmith> | hsivonen: https://www.w3.org/WAI/PF/Group/track/actions/413 |
| 05:24 | <MikeSmith> | "Create RelaxNG schema for ARIA" |
| 05:25 | <MikeSmith> | wow I guess that one's been open since 2009 |
| 06:23 | <hsivonen> | MikeSmith: fortunately, we already have an RNG schema for ARIA |
| 06:24 | <MikeSmith> | yeah |
| 06:24 | <MikeSmith> | I don't know why they've been keeping that action-item open |
| 06:26 | <hsivonen> | MikeSmith: https://bitbucket.org/pfalcon/validator/changeset/72665dd71762#chg-src/nu/validator/servlet/VerifierCommandLine.java looks like something that I should pull into mainline |
| 06:26 | <hsivonen> | the license header is a bit odd, though |
| 06:26 | MikeSmith | takes a look |
| 06:26 | <hsivonen> | maybe the author doesn't want a copyright line in the template |
| 06:26 | <MikeSmith> | ah, perhaps so |
| 06:27 | <MikeSmith> | it would be great to have it in mainline |
| 06:27 | <hsivonen> | also, the class should use some additional patching for generating a fake Content-Type header |
| 06:27 | <hsivonen> | after pulling it into mainline that is |
| 06:28 | hsivonen | decides to get breakfast first |
| 06:28 | <MikeSmith> | enjoy |
| 06:29 | MikeSmith | goes back to trying to write up a summary of the requirements implicit in the Encrypted Media Extensions proposal |
| 06:34 | <hsivonen> | MikeSmith: expect at least 38 replies to your summary |
| 06:34 | <MikeSmith> | heh |
| 06:35 | <MikeSmith> | maybe somebody has asked this already, but what's the point of having both http+aes and https+aes schemes if in practice anybody using this would be encrypting it with TLS? |
| 06:36 | <MikeSmith> | I do realize that you can do with Upgrade header thing with http resources to change to TLS encryption |
| 06:36 | <hsivonen> | MikeSmith: it would not be encrypted using TLS necessarily |
| 06:37 | <MikeSmith> | hsivonen: oh? |
| 06:37 | <hsivonen> | MikeSmith: Mark Watson said TLS CDNs are more expensive |
| 06:37 | <MikeSmith> | ah yeah |
| 06:38 | <hsivonen> | MikeSmith: https+aes implies you don't trust the CDN but the CDN applies TLS anyway |
| 06:38 | <MikeSmith> | I see |
| 06:38 | <hsivonen> | MikeSmith: to me, https+aes looks like it's there for completeness |
| 06:41 | <MikeSmith> | hsivonen: so are you saying there's no real use case for TLS-encrypting the connection for these resources? |
| 07:21 | <Hixie> | hsivonen: https+aes makes sense if you want to protect users from telling network snoopers what urls they're looking at |
| 07:22 | <Hixie> | in js, is there an efficient way of storing a set of objects such that they can be added and removed in O(1) ? |
| 07:23 | <Hixie> | or should i just quietly add an __id__ field to all the objects and use that as an index into an object in which i keep them? |
| 07:23 | <StoneCypher> | the last time i looked ecma didn't specify its representations well enough to make complexity guarantees |
| 07:24 | <StoneCypher> | but that was in the long ago, in the before time |
| 07:24 | <Hixie> | sure, i just mean in practice with browsers today |
| 07:24 | <StoneCypher> | in practice they're trees, not sets |
| 07:24 | <StoneCypher> | "sets are trees" sets are usually unordered hashmaps |
| 07:24 | <StoneCypher> | even though they shouldn't be |
| 07:24 | <Hixie> | i think you're missing the crux of my question |
| 07:25 | <heycam> | Hixie, the solution going forward would be to use a WeakMap |
| 07:25 | <heycam> | Hixie, but before that's widely available sticking id properties on your object is the way to do it, unfortunately |
| 07:25 | <Hixie> | heycam: weakmap lets me use an object as a key? |
| 07:25 | <heycam> | Hixie, yeah |
| 07:25 | <heycam> | https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/WeakMap |
| 07:26 | <Hixie> | yeah, was just reading that |
| 07:26 | <Hixie> | i need to be able to enumerate my list, so it wouldn't be useful for this |
| 07:27 | <StoneCypher> | notably, the ecmascript proposal they're talking about in that page is exactly to solve the issue i was discussing |
| 07:27 | <StoneCypher> | namely that javascript's fundamental datatypes for this are inadequate |
| 07:27 | <Hixie> | ok so the short answer is that today i need to add an id to all the objects |
| 07:27 | <Hixie> | ok |
| 08:24 | <zcorpan> | why is html5-diff blessed from "may object" in the cfc? |
| 08:33 | <annevk> | non-normative? |
| 08:38 | <zcorpan> | ah |
| 08:39 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1363 seems opera runs it as well |
| 08:39 | zcorpan | calls it a spec bug |
| 08:39 | <zcorpan> | unless there's a subtle security problem with running it |
| 08:42 | <annevk> | you should run that by foolip maybe |
| 08:43 | <annevk> | he did this thing with disabling javascript URLs in a bunch of places if I remember correctly |
| 08:44 | <zcorpan> | Hixie: why not make http(s)+aes never be same-origin? |
| 08:45 | <charlvn> | been toying with the java jsoup library - https://gist.github.com/1991945 |
| 08:46 | <Hixie> | zcorpan: we could do that. |
| 08:46 | <Hixie> | zcorpan: send mail/bug |
| 08:48 | <zcorpan> | filed |
| 08:49 | <Hixie> | thanks |
| 08:52 | <zcorpan> | Hixie: have you committed any new features to canvas yet or is it just shuffling things around so far? |
| 08:52 | <Hixie> | hopefully just shuffling around |
| 08:52 | <Hixie> | getting there though |
| 08:52 | <zcorpan> | k, then i don't need to read the diffs :-) |
| 08:52 | <Hixie> | (hopefully because any normative changes are bugs) |
| 08:54 | <zcorpan> | hsivonen: he also excluded HTTP, URL (from the web platform in the drm thread) |
| 08:57 | <annevk> | Hixie: so what exactly is hidden in the https+aes case? your one-liner was not entirely clear to me |
| 08:58 | <Hixie> | annevk: the url, assuming you mean "what's hidden from the network snooper" |
| 08:58 | <Hixie> | gotta go, bed time |
| 08:59 | <annevk> | so how is that hidden? oh well, later I guess |
| 08:59 | <Hixie> | it's hidden cos the stream is encrypted? same as https normally... |
| 08:59 | <annevk> | oh never mind |
| 08:59 | <Hixie> | anyway, ttyl :-) |
| 08:59 | <annevk> | g'night! |
| 09:39 | <hsivonen> | looks like chuck@jumis replied to me with something totally unrelated to what I said |
| 09:39 | <annevk> | film at 11? |
| 09:39 | <hsivonen> | reminds me of http://xkcd.com/1018/ |
| 09:40 | jgraham | thinks that re-ignote is an excellent typo combining as it does the words "re-ignite" and "ignore" |
| 09:40 | <Velmont> | Hmz. :-) |
| 09:41 | <annevk> | less time on IRC, more time editing jgraham :p |
| 09:41 | <jgraham> | Why do you want to edit me? |
| 09:41 | <crocket> | Why does firefox fail to open http://httpd.apache.org/docs/2.2/en/mod/mod_autoindex.html with ISO-8859-1 encoding. |
| 09:41 | <crocket> | firefox opens it with UTF-8. |
| 09:42 | <annevk> | punctuation... |
| 09:42 | <crocket> | annevk: ??? |
| 09:42 | <annevk> | crocket: you're not the only one having a conversation here ;) |
| 09:42 | <annevk> | crocket: see the logs |
| 09:43 | <annevk> | crocket: also, works fine here in Minefield |
| 09:43 | <hsivonen> | crocket: <?xml version="1.0" encoding="ISO-8859-1"?> is not an encoding declaration in text/html |
| 09:44 | <annevk> | confusingly called Minefield.app, but really is the latest Nightly |
| 09:44 | <jgraham> | hsivonen: I totally want to try the Dadaist approach to spec discussions |
| 09:44 | <annevk> | ooh yeah |
| 09:44 | <annevk> | so it depends on your locale |
| 09:44 | <hsivonen> | cobbler's children go barefoot also at the Apache Foundation, it seems |
| 09:44 | <annevk> | you'd think those HTTP guys know how to set something like this up |
| 09:45 | <hsivonen> | as in without real encoding declarations |
| 09:45 | <annevk> | and some fake XML |
| 09:46 | <jgraham> | Fake XML is the only way to keep it real |
| 09:47 | <annevk> | haha |
| 09:52 | <zcorpan> | annevk: time for a whatwg weekly? :-) |
| 09:54 | <Velmont> | ^^ |
| 09:54 | <annevk> | I guess I can write that real quick before I have to run to catch my flight |
| 09:55 | <zcorpan> | just don't miss your flight! |
| 09:56 | <annevk> | yeah I'll go the airport first |
| 09:56 | <annevk> | topics? |
| 09:56 | <annevk> | html5-diff |
| 09:57 | <annevk> | notifications += apple? |
| 09:57 | <annevk> | http+aes |
| 09:58 | <Velmont> | Meta referrer? Maybe? Not too much happening there though :P |
| 09:58 | <zcorpan> | mutation observers added to html |
| 09:58 | <Velmont> | crossorigin script tags, - lots of scoped talk |
| 09:58 | <zcorpan> | progress on canvas |
| 09:59 | <zcorpan> | throw in a plug with webgl on opera mobile :-P |
| 09:59 | <Velmont> | Grr. Now I see that deprecate registerProtocolHandler email again. Still, noone really wants to enter that discussion. |
| 10:06 | <annevk> | thanks guys |
| 10:06 | <crocket> | hsivonen: What is an encoding declaration in text/html? |
| 10:06 | hsivonen | wonders what's holding Opera 12 desktop considering that Mobile shipped already |
| 10:06 | <zcorpan> | crocket: <meta charset=utf-8> |
| 10:06 | <crocket> | hmm |
| 10:07 | <hsivonen> | crocket: HTTP-level Content-Type:, <meta charset> or BOM |
| 10:07 | <crocket> | Why did httpd devs forget to do it? |
| 10:07 | <hsivonen> | crocket: you need to ask them |
| 10:07 | <annevk> | it's prolly their docs team that forgot |
| 10:07 | <Velmont> | One of the universes mysteries. |
| 10:07 | <annevk> | and they prolly don't realize they're not using XML |
| 10:08 | <annevk> | anyway, running |
| 10:08 | <hsivonen> | crocket: experience suggests that fixing it will be prioritized once the bug causes Roy Fielding to lose an argument with Hixie on a standardization list because of the bug |
| 10:09 | <crocket> | hsivonen: I don't get it. |
| 10:09 | <crocket> | I don't understand the situation. |
| 10:10 | <hsivonen> | crocket: well, maybe they'll fix it without such a situation if you file a bug about the documentation site |
| 10:24 | <smaug____> | Did anyone ever give a good reply to http://lists.w3.org/Archives/Public/public-html/2012Mar/0128.html |
| 10:25 | <smaug____> | (about CDM and NPAPI) |
| 10:26 | <smaug____> | there are so many messages, that perhaps I've skipped some |
| 10:31 | <hsivonen> | smaug____: no, AFAICT |
| 10:54 | zcorpan | would like mentions to show up in the main twitter timeline |
| 10:55 | <annevk> | zcorpan: good link for the webgl stuff? |
| 10:57 | <zcorpan> | dunno, http://my.opera.com/chooseopera/blog/2012/02/27/opera-mini-7-next-and-opera-mobile-12 maybe? |
| 10:58 | <annevk> | that's the one I found too |
| 10:59 | <annevk> | is the correct English "This is March' first ..." |
| 11:00 | <annevk> | or March's |
| 11:00 | zcorpan | also finds http://www.youtube.com/watch?v=qpmYAqO2QSU |
| 11:19 | <hsivonen> | The revert request for http+aes took longer than expected |
| 11:39 | <annevk> | hsivonen: quite |
| 11:41 | <hsivonen> | "Cox, your friend in the digital age®" "We are the people" |
| 11:41 | hsivonen | tries to find out what services Cox provides that might be related to HTML5 video |
| 11:42 | <annevk> | http://blog.whatwg.org/httpaes-url-scheme |
| 11:44 | <david_carlisle> | annevk: I think it should be 's (but don't trust an Englishman to know English grammar) but better to avoid it and say .... of March |
| 11:44 | <annevk> | google agrees with you |
| 11:44 | <annevk> | well not google, but its results |
| 11:45 | <annevk> | thanks |
| 11:45 | <annevk> | time to go to the gate now |
| 11:45 | <zcorpan> | annevk: missing link to html5-diff? |
| 11:45 | <zcorpan> | missing link text, it seems |
| 11:46 | <annevk> | also fixed |
| 11:47 | <annevk> | oops, gate closing |
| 12:57 | <charlvn> | how can people think we are able to create an AI that can understand human languages if even humans have trouble in that regard :P |
| 12:59 | <Philip`> | Computers can be better than humans at lots of activities that humans invented (like arithmetic, or chess), so why not at language too? |
| 13:02 | <charlvn> | Philip`: good point! |
| 13:03 | <Philip`> | They could process vast amounts of data about the speaker (e.g. everything they've ever said before in their life) to construct a model of that person's mind and thought patterns at the present moment, and use that to statistically determine the most likely meaning that they intended to express given the utterance that they did express |
| 13:04 | <Philip`> | Humans can't do anything like that, so we have to apply lots of unreliable heuristics and are more likely to take the wrong meaning |
| 13:08 | <wilhelm> | I believe this is one of the difficult problems that will remain unsolved 20 years from now. |
| 13:08 | <Philip`> | (That's actually why this IRC channel's logs are public - it's part of a secret Google project to data-mine and learn the behaviour of WHATWG members in order to construct accurate electronic simulations of everyone's thoughts, eventually obsoleting the actual humans and allowing Google's algorithms to become entirely self-sufficient) |
| 13:10 | <jgraham> | If you read the HTML5 spec backwards, it reveals the Hixie actually died in 2006 and has been replaced with a prototype AI for spec-writing |
| 13:13 | <Philip`> | The "How to read this specification" section is not just a jocular reminder that reading specs is inherently difficult - it's actually a hidden cry for help from Hixie as his neurons were being absorbed by the machines |
| 13:13 | <charlvn> | when they remove the telencephalic inhibitor chip, mankind will become obsolete |
| 13:24 | <zcorpan> | has anyone written a script that renders the spec backwards yet? |
| 13:25 | <charlvn> | it is not the default rendering?! |
| 13:26 | <zcorpan> | inorite |
| 13:48 | <austincheney> | is the primary use case of http+aes about privacy or security? |
| 13:57 | <hsivonen> | austincheney: privacy against untrusted CDNs |
| 13:59 | <austincheney> | in that case it is likely doomed |
| 13:59 | <austincheney> | for two reasons |
| 14:00 | <austincheney> | 1) HTTP is inherently public, which is why there is no universal or consistent application of privacy laws for the web |
| 14:00 | <austincheney> | 2) privacy cannot be added with security mechanisms |
| 14:01 | <austincheney> | privacy is not security |
| 14:01 | <hsivonen> | the whole point is that it doesn't matter how public HTTP is when the payload has been encrypted and the key transfered out of band |
| 14:01 | <austincheney> | a grave fear in attempting to attach privacy to a public medium is that it potentially opens private vectors of attack |
| 14:02 | <hsivonen> | your point #2 doesn't make sense |
| 14:02 | <austincheney> | it does make sense |
| 14:02 | <austincheney> | privacy is not a security condition |
| 14:02 | <hsivonen> | it's a privacy mechanism--not a security mechanism |
| 14:04 | <austincheney> | in the US privacy is a legal classification and not an action or practice upon a work |
| 14:04 | <austincheney> | as a result, at least in the US, privacy cannot be added |
| 14:04 | <austincheney> | it can only be taken away |
| 14:04 | <hsivonen> | austincheney: it's not privacy in a legal sense |
| 14:05 | <hsivonen> | austincheney: it's privacy in a technical sense that you want to hide information from someone |
| 14:05 | <hsivonen> | austincheney: in this case, from a CDN |
| 14:05 | <austincheney> | in US law, privacy only exists in a legal sense |
| 14:06 | <charlvn> | austincheney: how is US law in any way relevant to global internet standards? |
| 14:06 | <austincheney> | its not relevant to global concerns, but it is entirely relevant to the internet as it resides in the US |
| 14:07 | <hsivonen> | austincheney: you seem to be *very* confused about the purpose of http+aes |
| 14:07 | <austincheney> | I probably am |
| 14:08 | <austincheney> | the best way to make a transmission private is to not use HTTP |
| 14:09 | <charlvn> | if HTTP has limitations that prevent its use, those limitations need to be addressed |
| 14:10 | <charlvn> | i thought that is what this whole initiative is about |
| 14:12 | <austincheney> | sometimes limitations exist for a good reason, otherwise limitations exist because of violations against a technology's intent |
| 14:13 | <austincheney> | we have been violating the intent of http for about 20 years now |
| 14:13 | <austincheney> | http was intended to be simple and sessionless, but webapps are neither |
| 14:14 | <charlvn> | technology evolves and adapts to user needs. it is not a constant. it never was a constant and will never be a constant. |
| 14:14 | <austincheney> | violating the intention of HTTP is a key factor in the rapid growth of the web's security concerns |
| 14:15 | <austincheney> | evolving the technology beyond its intention carries unexpected costs |
| 14:15 | <charlvn> | that might be true but it does not need to stagnate technological development |
| 14:16 | <charlvn> | we just need to address the issues that arrise |
| 14:27 | <zewt> | no, http is just a protocol; it doesn't care what data payloads are sent over it |
| 14:27 | <zewt> | uh okay then |
| 14:43 | <karlcow> | exactly HTTP is an application protocol, sorry for the pedantry |
| 16:03 | <annevk> | zcorpan: if you make a bitbucket account we can just add you to the repo |
| 16:03 | <annevk> | zcorpan: seems simpler |
| 16:04 | <annevk> | oh you do it seems |
| 16:04 | <annevk> | zcorpan: done |
| 16:13 | <zcorpan> | for specification-data? |
| 16:17 | <annevk> | yes |
| 16:17 | <zcorpan> | ok |
| 16:24 | <aklein> | annevk: finally got around to implementing ordering of mutation record delivery, and I'm wondering if we can do a few more tweaks to http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-mo-invoke |
| 16:25 | <annevk> | sure |
| 16:26 | <annevk> | I can probably do them now |
| 16:28 | <aklein> | annevk: the convenient thing would be to make a copy of the scripting environment's observer list, containing only those observers with non-empty queues |
| 16:28 | <aklein> | so if you do further mutations that trigger other observers during a callback, they don't get notified until the next time around the loop |
| 16:29 | <aklein> | or if a new observer is created in a callback, and observers changes during a loop, it also won't get notified until the next time around |
| 16:29 | <aklein> | s/observers chnages/observes changes/ |
| 16:29 | <aklein> | I'd also be willing to implement the algorithm as-is, but it seems a little trickier |
| 16:29 | <aklein> | (too bad smaug's not around) |
| 16:30 | <AryehGregor> | zewt, people usually use CDNs for performance, and the extra round-trips of HTTPS would tend to work against that. http+aes provides secrecy without extra latency, assuming the client isn't going to be troubled by AES decryption. (Which is very likely if it has the computing power to display video.) |
| 16:30 | <annevk> | might be best to email the list about that aklein |
| 16:30 | <aklein> | annevk: ok |
| 16:30 | <aklein> | looking forward to a firefox implementation so I can just explain these things with test cases :) |
| 16:31 | <annevk> | wow http://www.theregister.co.uk/2012/03/07/deutsche_telekom_data_record/ |
| 16:31 | <annevk> | give me! |
| 16:31 | <Ms2ger> | aklein, it's coming around... Only it's always a week or so away :) |
| 16:32 | <AryehGregor> | Anyway, http+aes seems like it solves a use-case that nobody is going to be very interested in. For DRM, you probably care about consumers pirating the content, not CDNs. CDNs can be retained under NDAs that it's not worth their while to break. |
| 16:32 | annevk | hopes Opera gets around to it soonish too |
| 16:33 | <AryehGregor> | Also, based on how CDNs generally work, you could only rarely rotate the key in this use-case, because you'd have to upload new versions to the CDN whenever you do, and that considerably mitigates the usefulness of the encryption. |
| 16:36 | <AryehGregor> | Does YouTube even use CDNs? Maybe it stores some files within ISPs' networks, but the ISP can snoop the AES key out of the page if it wants, since YouTube isn't HTTPS by default. |
| 16:36 | <AryehGregor> | Netflix seems to use a CDN (Limelight Networks), but realistically I find it hard to imagine them worrying about piracy. If the content owners are worried about Limelight pirating their media, why aren't they worried about Netflix itself? |
| 16:37 | AryehGregor | suspects this is all a smokescreen. |
| 16:37 | <Ms2ger> | Hear hear, Knol is dying |
| 16:43 | <dglazkov> | good morning, Whatwg! |
| 16:43 | <hatwg> | Good morning, dglazkov! |
| 16:44 | <dglazkov> | my favorite hatwg!!! |
| 16:44 | <dglazkov> | it's a working group where we discuss hats. |
| 16:44 | <annevk> | moar hats |
| 16:46 | <dglazkov> | also, debate serious topics, like whether helmets are hats |
| 16:47 | <annevk> | oh yes, lets redefine hat |
| 16:47 | <dglazkov> | and of course, the hot topics of Hat Rights Management |
| 16:47 | <annevk> | it will be splendid |
| 16:47 | <dglazkov> | very controversial |
| 16:47 | <annevk> | hats don't have a lot of rights |
| 16:47 | <annevk> | so shouldn't be too hard |
| 16:48 | <dglazkov> | well, unless you wear a person as a hat |
| 16:49 | <annevk> | nice try atlassian |
| 16:49 | <annevk> | sends you spam |
| 16:49 | <annevk> | puts the unsubscribe forever site in maintenance |
| 16:53 | <annevk> | heh http://i.imgur.com/HRU3z.png |
| 17:13 | <dglazkov> | sicking!!! |
| 17:14 | <AryehGregor> | annevk, well, it's sent to ayg+bitbucket, so I know where it's from. |
| 17:20 | <Ms2ger> | zcorpan, "http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html redirected to https://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html"; |
| 17:20 | <Ms2ger> | That doesn't seem to happen here |
| 17:24 | <zcorpan> | Ms2ger: it's the output of the w3c link checker |
| 17:24 | <Ms2ger> | html5-diff? |
| 17:24 | Ms2ger | checks |
| 17:24 | <zcorpan> | http://simon.html5.org/dump/refs.html |
| 17:33 | <Ms2ger> | Indeed so |
| 17:33 | <Ms2ger> | [18:34:18.346] GET http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html [HTTP/1.1 200 Script output follows 840ms] |
| 17:33 | <Ms2ger> | MikeSmith? |
| 17:38 | <annevk> | NFC API |
| 17:38 | <annevk> | first thought Unicode or near-field? |
| 17:38 | <annevk> | <- Unicode |
| 17:38 | <Ms2ger> | r- |
| 17:39 | <bga> | where to read about -webkit-texture ? |
| 17:41 | <jgraham> | Webkit source code? |
| 17:43 | <StoneCypher> | bga: http://lmgtfy.com/?q=%22-webkit-texture%22 |
| 17:49 | <AryehGregor> | Cool. |
| 17:49 | <AryehGregor> | Reproducible null pointer dereference in the kernel, triggered by 3D transforms in Chrome. |
| 17:49 | <Ms2ger> | Chrome++ |
| 17:49 | <AryehGregor> | I guess it serves me right for using the experimental Gallium3D support. |
| 17:49 | <AryehGregor> | No, (nouveau+experimental Gallium3D support)++. |
| 17:50 | <Ms2ger> | I'm going to blame Google anyway :) |
| 17:50 | <AryehGregor> | Chrome isn't even using hardware acceleration, according to about:gpu. |
| 17:57 | <zcorpan> | Ms2ger: i'm ok with calling it a bug in either the link checker or the dvcs.w3.org server and not changing the url if it doesn't redirect for normal users |
| 17:58 | <Ms2ger> | I'm happy to use https, fwiw, but I'd like to hear what's actually happening |
| 18:12 | <Hixie> | what's the easiest way, in js, of taking a string and splitting it on the first two spaces so that you get the first word, the second word, and the remainder in "first second the remainder"? |
| 18:12 | <Hixie> | .split's limit argument doesn't seem to do anything useful here |
| 18:12 | <AryehGregor> | The second parameter of String.split() doesn't behave very usefully here. |
| 18:13 | <AryehGregor> | I think Python's does what you want. :) |
| 18:13 | <Hixie> | perl too |
| 18:13 | <AryehGregor> | Lame. |
| 18:13 | <AryehGregor> | Oh well. |
| 18:13 | <Hixie> | sadly i'm in js :-) |
| 18:13 | <Hixie> | i guess a regexp would work |
| 18:13 | <jgraham> | Reimplement a python interpreter in js and use that? |
| 18:13 | <Hixie> | seems like overkill though |
| 18:13 | <Hixie> | you can take my last statement as referring either to regexps or your idea :-) |
| 18:13 | <AryehGregor> | I guess: var arr = s.split(" "); if (arr.length > 3) arr[2] = arr.slice(2).join(" "); |
| 18:14 | <annevk> | split,pop,pop,join |
| 18:14 | <Hixie> | yeah i guess join would work |
| 18:14 | <jgraham> | Yeah, I think I wouyld do what AryehGregor suggested |
| 18:14 | <Hixie> | awright |
| 18:14 | <Hixie> | thanks |
| 18:14 | <jgraham> | It is probably hideously inefficient though. Hopefully that doesn't matter |
| 18:14 | <Philip`> | That seems much uglier and less efficient than regexps |
| 18:15 | <Hixie> | the advantage over regexp is that i actually have to do this for varying values of 2 |
| 18:16 | <Hixie> | and it'll just work generically for any number of leading words that i want to strip off |
| 18:16 | <Hixie> | whereas regexps would have to be fine-turned for each case |
| 18:16 | <Ms2ger> | I guess you could generate the regexps |
| 18:16 | <zcorpan> | Hixie: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1365 |
| 18:17 | <Hixie> | zcorpan: thanks |
| 18:19 | <Philip`> | var x="a b c d"; var re = new RegExp("(.*?) ", "g"); var words = []; for (var i=0; i<2; ++i) words.push(re.exec(x)[1]); words.push(x.substr(re.lastIndex)); |
| 18:20 | <Hixie> | not sure that's less ugly :-) |
| 18:20 | <Philip`> | That's because you added the requirement that 2 is variable :-p |
| 18:20 | <Hixie> | there's probably less string copying though |
| 18:21 | <Hixie> | though with js engines, who knows |
| 18:21 | <zcorpan> | run it through jsperf |
| 18:22 | Philip` | isn't sufficiently corrupted to like generating variable-length regexp patterns with string manipulation |
| 18:22 | <Hixie> | i'll worry about perf if this turns out to be too slow. :-) |
| 18:24 | <zcorpan> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1366 alternative that doesn't construct a new string |
| 18:24 | <zcorpan> | but measures the length of two :-) |
| 18:26 | <zcorpan> | maybe some jsperf regular will read the logs and be curious enough to run a benchmark |
| 18:26 | matjas | whistles |
| 18:27 | <zcorpan> | :-) |
| 18:27 | <Hixie> | i went with just splitting the whole thing on spaces at the top and then rejoining the trailing bits when i know which i need |
| 18:28 | <zcorpan> | what's this for, btw? |
| 18:29 | <Hixie> | parsing some stuff from a server script |
| 18:32 | <Hixie> | on another note |
| 18:32 | <Hixie> | the sooner we can get the terser Element.create() syntax done and shipped the happier i'll be |
| 18:33 | <Ms2ger> | Write the spec for it? :) |
| 18:33 | <Hixie> | i've been tempted |
| 18:34 | <Hixie> | anyone got some code already written to take a string and escape it for use as a CSS identifier? |
| 18:35 | <Ms2ger> | glazou might |
| 18:35 | <Ms2ger> | Oh, you weren't asking what I thought you were |
| 18:35 | <zcorpan> | matjas probably does |
| 18:36 | <zcorpan> | http://mothereff.in/css-escapes |
| 18:36 | <matjas> | Hixie: see http://mothereff.in/css-escapes source: https://github.com/mathiasbynens/mothereff.in/blob/master/css-escapes/eff.js |
| 18:36 | <Hixie> | sweet, thanks |
| 18:37 | <matjas> | note that standard CSS character escape sequences for supplementary Unicode characters aren’t currently supported in WebKit, though: http://mothereff.in/css-escapes#1%F0%9D%8C%86 |
| 18:37 | <matjas> | so you may not want to escape those |
| 18:37 | <Hixie> | i'm targetting browsers of the future here, so that's not an issue |
| 18:40 | <Hixie> | oh this isn'ta s bad as it first looked |
| 18:40 | <Hixie> | since i don't need to escape non-ascii |
| 18:40 | <Hixie> | duh |
| 18:43 | <annevk> | is the input a DOMString? |
| 18:43 | <annevk> | might want to look out for surrogates if so |
| 18:43 | <Hixie> | why? |
| 18:43 | <Hixie> | i'm just gonna stick it in style.textContent |
| 18:43 | <annevk> | is CSS also code unit based? |
| 18:44 | <annevk> | lone surrogates might end up as U+FFFD |
| 18:44 | <Hixie> | oh i don't have lone surrogates, i'm good on that front |
| 18:44 | <Hixie> | (or rather, if i do, i don't really care) |
| 18:44 | <Hixie> | (those can fail, whatever) |
| 18:44 | <annevk> | k |
| 18:45 | <Hixie> | matjas: what's the difference between s.charAt(i) and s[i] ? |
| 18:45 | <Hixie> | (just looking at your code) |
| 18:45 | <zcorpan> | Hixie: the former works in old IE |
| 18:45 | <Hixie> | ah ok |
| 18:46 | <matjas> | what zcorpan said |
| 18:46 | <Hixie> | definitely don't care about old IE since this is parsing websocket stuff :-D |
| 18:46 | <matjas> | IE < 8 doesn’t support string indexing, and IE8 only supports it for string literals, not for string objects |
| 18:46 | zcorpan | is a bit disturbed that he still hasn't forgotten about old IE limitations |
| 18:47 | zcorpan | hasn't cared about or even used old IE for *years* |
| 18:48 | <Ms2ger> | Nice one, github |
| 18:48 | <matjas> | zcorpan: sounds like your garbage collector broke |
| 18:48 | <matjas> | free up that memory! |
| 18:48 | <zcorpan> | i guess that stuff kinda gets in to your spine when you have to work with the limitations when you first learn stuff |
| 18:49 | <zcorpan> | http://theoatmeal.com/comics/brain |
| 18:51 | <Hixie> | matjas: i derived http://junkyard.damowmow.com/503 from your code, do you mind if i assume copyright of this variant? (and immediately declare it public domain, since it's like 10 lines of code) |
| 18:52 | <matjas> | Hixie: sure, that’s cool |
| 18:52 | <Hixie> | ta |
| 19:45 | <sicking> | dglazkov: hey |
| 19:50 | jwalden | wonders if sicking is still sicking or not today |
| 19:51 | <sicking> | huh |
| 19:51 | <sicking> | i'm still wft with a cold if that's what you're asking |
| 19:52 | <jwalden> | :-( |
| 19:52 | <jwalden> | and that is what I was musing about |
| 19:52 | <jwalden> | never let an opportunity for a bad pun go to waste |
| 19:53 | <Ms2ger> | Where's Waldo when you need a bad pun... |
| 21:33 | <dglazkov> | sicking y u no answer my emails |
| 21:37 | <gsnedders> | Anyone got any opinion as to the behaviour of {get __proto__() {}} or {__proto__: 1} should do? |
| 21:37 | <AryehGregor> | So the makefile for CSS3 Transforms seems to require that either I type my username and password every time when making, or I put them in a .curlrc that will be used for *all* curl requests? |
| 21:38 | <AryehGregor> | Meaning if some random other script uses curl to access some page that happens to be authenticated, it will send my W3C username and password? |
| 22:16 | <sicking> | dglazkov: ugh, sorry, so hard to keep up with mail these days |
| 22:16 | <sicking> | dglazkov: We currently don't have anyone working on shadow DOM. Just a resource problem :( |
| 22:16 | <dglazkov> | sicking: no stress :) |
| 22:17 | <dglazkov> | sicking: ok |
| 22:17 | <sicking> | dglazkov: does that answer the questoin? |
| 22:17 | <dglazkov> | sicking: it totally does! |
| 22:19 | <annevk> | http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0021.html (via @mattur) :/ |
| 22:21 | <dglazkov> | sicking: I briefly considered hacking on mozilla myself, but then realized I need _different_ people to implement :) |
| 22:21 | <Hixie> | annevk: doesn't look like anything new? |
| 22:29 | <Hixie> | anyone know of the perf group ever ended up using the hook i added for them? |
| 22:29 | <Hixie> | i never heard back on it after adding it |
| 22:30 | <benschwarz> | Wow. Way to be a dick Janina Sajka |
| 22:31 | <Hixie> | i'm sure she's not trying to be rude |
| 22:31 | <Hixie> | she's just passionate |
| 22:32 | <Hixie> | (and for some reason thinks we don't think accessibility matters) |
| 22:32 | <smaug____> | sicking: have we even agreed to implement shadow dom |
| 22:33 | <smaug____> | I kind of understood differently when discussing with someone... |
| 22:33 | <smaug____> | (the draft is still unreviewed ) |
| 22:33 | <smaug____> | dglazkov: and sorry, I'm a bit negative person :) |
| 22:33 | <benschwarz> | "Perhaps, Silvia, you won't be surprised to hear that we are engaged in use case development and requirements gathering. Sound familiar?" |
| 22:34 | <smaug____> | dglazkov: does the shadow dom already support default handling for events |
| 22:34 | <dglazkov> | smaug____: hey, I am still waiting for those bugs to be filed :) |
| 22:34 | <smaug____> | yes! |
| 22:35 | <benschwarz> | its condescending at the very least, and "not okay" |
| 22:35 | smaug____ | kicks himself |
| 22:36 | <Hixie> | benschwarz: she's just frustrated. the problem in that e-mail isn't that, it's the part where she doesn't seem to understand why longdesc="" is bad and how we've already addressed the accessibility needs in question. |
| 22:36 | <Hixie> | benschwarz: it's quite sad |
| 22:37 | <benschwarz> | yeah I think so too |
| 22:37 | <Hixie> | benschwarz: (but as i indicated to annevk, it's hardly new) |
| 22:56 | <jgraham> | Things that are confusing: opening the wrong email and wondering how the DRM thread turned into a discussion typed arrays |
| 22:58 | <gavin> | I propose adding a new AESArray type |
| 23:29 | <Hixie> | what should i call this path interface |
| 23:29 | <Hixie> | Path? |
| 23:39 | <othermaciej> | if you are worried about collisions with other sense of Path, you could say CanvasPath, GraphicsPath, BezierPath... |
| 23:40 | <othermaciej> | SVG apparently has SVGPathSegList for this purpose |
| 23:40 | <othermaciej> | though it is a rather awful interface |
| 23:41 | <heycam> | Hixie, I'd love it if SVG and Canvas could use the same path objects. othermaciej is right that the existing SVG DOM interfaces suck. |
| 23:42 | <Hixie> | SVG's is for the d="" attribute DOM, so it's not really anything relevant here |
| 23:42 | <Hixie> | and i don't think it would make much sense to reuse this for SVG |
| 23:42 | <heycam> | I might wait until you write up your proposal and then see how it can be integrated into SVG DOM improvements |
| 23:42 | <Hixie> | but yeah, maybe |
| 23:42 | <heycam> | Hixie, they're both representing paths though |
| 23:43 | <Hixie> | i'll call it Path for now, and then you can see what you think, and if it's not generic enough we can rename it |
| 23:43 | <Hixie> | i do intend to integrate a bit with svg with the d="" syntax and the matrix objects |
| 23:43 | <Hixie> | though that might be a bit painful for implementations |
| 23:43 | <heycam> | ok cool |
| 23:43 | <othermaciej> | SVGPathSegList seems more oriented towards inspecting something created from the d="" syntax than towards creating a path programmatically in a convenient way |
| 23:44 | <Hixie> | othermaciej: that's entirely it's purpose, yes |
| 23:44 | <Hixie> | its |
| 23:44 | <heycam> | yeah that's fair |
| 23:47 | <othermaciej> | it would be kind of nice to be able to programatically build a path and set it as an SVG "d" value |
| 23:47 | <othermaciej> | and I was going to say "in other places that SVG uses a path" but it seems those are done by linking to a path element |
| 23:48 | <othermaciej> | no, I guess it is inconsistent |
| 23:48 | <othermaciej> | <glyph> has its own d attribute, but <textPath> links to a <path> |
| 23:50 | <heycam> | yeah, although I wonder if that choice was made because SVG Font attributes are not animatable, but if you link to a <path> element that's going to be animatable |
| 23:50 | <heycam> | anyway |
| 23:51 | <Hixie> | right now i'm not planning on making it possible to inspect a path |
| 23:51 | <Hixie> | but that's on the cards for next time |
| 23:51 | <Hixie> | once you can inspect a path, makes sense to have a way to export as d="" or even as a <path> element |
