| 00:08 | <bradee-oh> | other oral traditions are also "works", though a bit more loosely... |
| 00:09 | <mpt> | Hixie, "creative work"? |
| 00:10 | <othermaciej> | has Microsoft announced anything in particular about better DOM/JS support in IE8? |
| 00:10 | <Philip`> | Papers aren't really creative works |
| 00:10 | <othermaciej> | Zeldman keeps mentioning it but I don't see an official announcement or anything |
| 00:10 | <Hixie> | mpt: hm, that might work |
| 00:10 | <Hixie> | oh yeah, creative fails for things like research papers |
| 00:10 | <Hixie> | (cue jokes) |
| 00:11 | <mpt> | Why does it? |
| 00:11 | <Hixie> | but seriously, i think creative would help as much as it hurts here |
| 00:11 | <Hixie> | because people associate "creative" with art |
| 00:11 | <Hixie> | rather than research |
| 00:11 | <jgraham> | Seriously, papers are creative works |
| 00:11 | <mpt> | A more awkward example might be the telephone directory |
| 00:12 | <jgraham> | (although I agree that many people wouldn't use the term in that context, I would strongly disagree with them) |
| 00:16 | <Hixie> | i'll just stick to "work" with a long list of examples |
| 00:16 | <Hixie> | and an explicit ban on names of people or ships |
| 00:16 | <jgraham> | This is for the <cite> element, right? |
| 00:16 | <Hixie> | yep |
| 00:17 | jgraham | still doesn't think it's very useful |
| 00:17 | <Hixie> | me either |
| 00:17 | <Hixie> | but it's used more than <dfn> |
| 00:17 | <Hixie> | and you should have seen the hell that the xhtml2 wg received for trying to drop it |
| 00:18 | <jgraham> | Yeah, I accept that people want to use it even though doing so has no obvious benefits |
| 00:19 | <annevk> | that was because Mark Pilgrim actually used it for something |
| 00:19 | <annevk> | that's no longer the case |
| 00:20 | <Hixie> | i've already spoken to mark about this |
| 00:20 | <Hixie> | (and i'm not saying that the aforementioned wrath is a reason to keep it, i'm just mentioning it) |
| 00:21 | <annevk> | <cite> for ship names though? |
| 00:21 | <jgraham> | I guess doing something interesting with citations will have to be left to the microformats people |
| 00:22 | <annevk> | i guess since it renders in italic it's ok :) |
| 00:22 | <Hixie> | i said ship names were explicitly banned :-P |
| 00:22 | <Hixie> | use <i> |
| 00:22 | <annevk> | (which is btw one of the reasons why <cite>Anne</cite> said: <q>...</q> doesn't make much sense; "Anne" there typically wouldn't be italicized) |
| 00:22 | <annevk> | oops |
| 00:23 | <annevk> | ah, people too |
| 00:31 | <Hixie> | wow, i didn't realise that the first REC the w3c ever did was PNG |
| 00:33 | <Hixie> | i love the comment on libpng.org: |
| 00:33 | <Hixie> | "(By the way, despite the implications in some of CompuServe's old press releases and in occasional trade-press articles, PNG's development was not instigated by either CompuServe or the World Wide Web Consortium, nor was it led by them. Individuals from both organizations contributed to the effort, but the PNG development group exists as a separate, Internet-based entity.)" |
| 00:33 | <Hixie> | i wonder if we should publish something like that on the whatwg page :-P |
| 00:50 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#the-cite |
| 00:53 | <annevk> | "even if people call that person a piece of work" :p |
| 00:56 | <annevk> | i'd like HTML5 to define this: "window.name = '1'; name = '2'; w(name); w(window.name)" |
| 00:57 | <annevk> | there's some magic going on there |
| 00:57 | <Hixie> | is that the replaceable stuff? |
| 00:57 | <annevk> | well, it seems that some browsers are able to distinguish between window.name and name (both in the global scope) |
| 00:58 | <annevk> | i think that's different from replaceable, but I'm not sure |
| 00:59 | <Hixie> | odd |
| 00:59 | <annevk> | what's not odd is that sites rely on this |
| 00:59 | <Hixie> | when you say "browsers" |
| 00:59 | <Hixie> | which browsers? |
| 00:59 | <Hixie> | firefox doesn't seem to distinguish them |
| 00:59 | <annevk> | Firefox and Internet Explorer |
| 01:00 | <annevk> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3Cscript%3Ewindow.name%20%3D%20%271%27%3B%20name%20%3D%20%272%27%3B%20w(name)%3B%20w(window.name)%3C%2Fscript%3E |
| 01:00 | <Hixie> | window.name = 'a'; name = 'b'; name + ' ' + window.name; on http://software.hixie.ch/utilities/js/js-eval-window/ evaluates to "b b" |
| 01:00 | <annevk> | I get 2, 1 in the log |
| 01:00 | <Hixie> | i get 2,2 |
| 01:01 | <Hixie> | Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b2pre) Gecko/2007112904 Minefield/3.0b2pre |
| 01:01 | <annevk> | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008021204 Minefield/3.0b4pre |
| 01:01 | <Hixie> | wow, mine is old |
| 01:01 | <annevk> | get "b a" for yours |
| 01:03 | <Hixie> | ff2 gives b b/2 2 too |
| 01:04 | <annevk> | yeah |
| 01:04 | <Hixie> | ff3 nightly crashes on startup |
| 01:04 | Hixie | nukes his profile |
| 01:05 | <annevk> | heh, I even get 2 2 in IE7 |
| 01:05 | <annevk> | maybe I'm testing this wrongly |
| 01:05 | <annevk> | could be that it only applies to nested browsing contexts or so, I guess :( |
| 01:07 | <annevk> | Hixie, btw, could you add "html" and "css" as resources to the live dom viewer? |
| 01:08 | <annevk> | maybe even script that does w('run') or something like that |
| 01:11 | annevk | -> bed |
| 01:12 | <Hixie> | adbded |
| 01:12 | <Hixie> | added even |
| 02:37 | <Hixie> | othermaciej: the workers idea i proposed included a DOMImplementation object, from which you can create a Document |
| 02:37 | <Hixie> | afk bbiab |
| 02:38 | <othermaciej> | Hixie: I haven't read over all the proposals closely yet, but that would indeed raise the same issue as the X part of XHR being present |
| 02:39 | <othermaciej> | I can see how it could be useful but at least in WebKit I think it would significantly increase the implementation complexity |
| 03:18 | <roc> | eek yes that would be real pain |
| 03:43 | <Hixie> | really? |
| 03:43 | <Hixie> | huh |
| 03:44 | <Hixie> | i would have thought you could run a DOM on a different thread without problems, what of the DOM implementation is not thread safe? |
| 03:49 | <roc> | depends on the implementation, but it's easy to imagine that the DOM uses global internal caches |
| 03:50 | <roc> | and it's not just the DOM but everything the DOM touches |
| 03:50 | <roc> | canvas, video, you name it |
| 03:51 | <Hixie> | true |
| 03:52 | <Hixie> | it would be sad if it was not available |
| 03:52 | <Hixie> | creating markup is one of the things i'd expect to happen in a worker |
| 03:52 | <Hixie> | even if it's not manipulating forms, videos, audio, etc. |
| 03:53 | <roc> | strings and innerHTML baby |
| 03:53 | <roc> | gotta save something for HTML6 |
| 03:53 | <Hixie> | creating markup with strings is sub-optimal |
| 03:53 | <Hixie> | but maybe e4x can find a use finally :-) |
| 03:53 | <roc> | The JS library writers say it's actually optimal in practice :-) |
| 03:53 | <Hixie> | i didn't mean performance-wise |
| 03:53 | <Hixie> | :-) |
| 03:56 | <Hixie> | bbl |
| 09:02 | <Philip`> | http://blog.mozilla.com/rob-sayre/2008/02/19/bloaty-parts-of-the-whatwg-html5-specification-that-should-be-removed/ |
| 09:05 | <annevk> | http://diveintomark.org/archives/2008/02/19/all-these-years |
| 09:06 | <krijn> | Does he know there's a <mark> element as well now? :) |
| 09:37 | <Dashiva> | "they’re taking away my right to cite a person" |
| 09:52 | <jgraham__> | Dashiva: Yeah. I managed to restrain myself from asking which set of laws guaranteed that particular right |
| 09:53 | jgraham__ | doesn't remember it being part of the EU convention on human rights |
| 09:56 | <Philip`> | A right to life, a right to liberty and security, a right to freedom of thought, conscience and religion, a right to use <cite> for people's names? |
| 09:56 | <Philip`> | Doesn't quite fit, I think |
| 09:56 | <Dashiva> | Maybe it fits into the religion part |
| 10:07 | <annevk> | here's some more from that stuff yesterday: http://wiki.mozilla.org/Gecko:SplitWindow |
| 10:08 | <annevk> | i guess it's unlikely to affect the topmost browsing context |
| 12:05 | <Lachy> | damn, <cite> should be allowed for people's names. How else is one expected to markup something like: <p><cite>John Smith<cite> said <q>Hello World!</q></p> ? |
| 12:05 | <Lachy> | I use it all the time for people's names when I quote from blog entries. I usually use it for both the author and the article title. |
| 12:06 | <Philip`> | What benefit do people get from you using it like that? |
| 12:07 | <Lachy> | I don't know, it's what I do |
| 12:08 | <Lachy> | maybe I've been using it wrongly all these years. I don't know |
| 12:08 | <Philip`> | So it's superstition? :-) |
| 12:09 | <annevk> | i did that too, but it recently learned that the convention is that those names should not be in italic and other than that there was no apparent benefit |
| 12:10 | <Lachy> | ok. If there's no typographical convention for people's names, then I guess I'm wrong |
| 12:12 | <annevk> | s/but it/but I/ ... |
| 12:13 | <hsivonen> | Lachy: in Finland, there's a convention in newspapers and magazines (not books) to bold the first instance of each personal name in an article |
| 12:13 | <hsivonen> | Lachy: clearly, not what <cite> is good for |
| 12:14 | <annevk> | <b> |
| 12:15 | <hsivonen> | yes |
| 12:27 | <annevk> | lol, someone wants to put advertisements on a few of my pages for inifinite time for a one-time 200 USD |
| 12:28 | <Lachy> | annevk, I get spam like that occasionally (though usually caught by my spam filter) |
| 12:28 | <annevk> | it's a serious offer |
| 12:28 | <hsivonen> | annevk: was the price disclosed in the initial offer? the people who want to advertise on my site never disclose the money figures up front but promise to make it worthwhile for me |
| 12:28 | <Lachy> | yeah, I even had some serious offers once |
| 12:29 | <Lachy> | It prompted me to publish my advertising policy on my site |
| 12:29 | <annevk> | hsivonen, oh no, I replied |
| 12:29 | <Lachy> | http://lachy.id.au/about/advertising |
| 12:29 | <annevk> | i do run advertising |
| 12:30 | <annevk> | but it's finite time, has limited impact on my software, has zero maintenance cost, and gives me a share that i think is acceptable |
| 12:30 | <Lachy> | on annevankesteren.nl? |
| 12:30 | <Lachy> | I've never seen any ads |
| 12:30 | <annevk> | it's hardly noticable |
| 12:31 | <annevk> | search for "beslist.nl" |
| 12:31 | <annevk> | (inline search) |
| 12:31 | <Lachy> | oh |
| 12:31 | <Lachy> | that's the best advertising I've seen. all sites should do that! :-) |
| 12:32 | <hsivonen> | hmm. seems like they are partly paying for the google juice |
| 12:33 | <Camaban> | google would say those links should have nofollow on them :) |
| 12:33 | <hsivonen> | these advertisers seem to think they are paying for google juice but aren't getting any: http://www.w3.org/Consortium/sup |
| 12:35 | <annevk> | hsivonen, true |
| 12:36 | <Camaban> | could be debated |
| 12:37 | <annevk> | hsivonen, heh, probably the only w3.org page with "Generic Viagra" |
| 12:38 | <annevk> | or maybe not, check this out: http://www.google.com/search?q=site:w3.org+viagra |
| 12:38 | <Camaban> | have Google stated that links on pages like that pass no link pop? |
| 12:38 | <Camaban> | just ebcause they are told not to follow them, doens't mean they can't take them into account for link pop |
| 12:39 | <hsivonen> | Camaban: IIRC, nofollow is a misnomer and means nopagerank |
| 12:40 | <Camaban> | well, when I first mentioned nofollow, I was on about rel=nofollow, and yes, google suggested using that to combat spam, and have since recommended it for marking up ads as well |
| 12:40 | <Camaban> | because they don't feel those links should pass PR |
| 12:41 | <Camaban> | but the robots meta tag is a bit different |
| 12:41 | <hsivonen> | oh |
| 12:41 | <hsivonen> | the W3C seems to think they aren't selling google juice, though |
| 12:42 | <Camaban> | heh, well it's come up in SEO circles a few timesa about the 'paid links' the W3C has on that page |
| 12:42 | <hsivonen> | but it's pretty obvious that those who buy placement on that page think they are buying it |
| 12:42 | <Camaban> | especially as it's a high authority domain |
| 12:43 | <annevk> | now and then i read something or hear something from these so-called SEO's and i often doubt they know what they're talking about |
| 12:43 | <Camaban> | toolbar suggest that particular page has a PR of 8, a link from like that is worth a fair bit :) |
| 12:44 | <Camaban> | annevk: there are lots of people who call themselves SEO guru's who think meta keywords still make a difference in ranking |
| 12:44 | <Camaban> | on the other hand, there are numerous people who do have a clue :) |
| 12:55 | <Camaban> | ok, having checked, it seems Matt Cutts has stated that meta nofollow does the same as rel=nofollow, so those links should indeed NOT be passing google juice |
| 12:56 | <Camaban> | the page is indexed, so the links can be found as part of the page, but they aren't benefiting the recipients in terms of link popularity :) |
| 15:59 | <zcorpan> | Philip`: ping |
| 16:01 | <Philip`> | http://philip.html5.org/data/cite.txt in case anyone is interested |
| 16:01 | <Philip`> | zcorpan: Hello |
| 16:02 | <Philip`> | (Is there some WYSIWYG editor that encourages people to use <cite> when they want presentational italics?) |
| 16:03 | <webben> | knowing the general quality of WYSIWYG editors, probably |
| 16:03 | <webben> | that's a lot of support for CITE meaning citation not just title of work. |
| 16:06 | <gsnedders> | Philip`: (nothing widely used, at least) |
| 16:07 | Philip` | is just wondering how <cite><font size="4"> No.. No....please, no electric shocks.</cite></font> comes about |
| 16:08 | <Philip`> | Actually, I guess a WYSIWYG editor usually wouldn't generate misnested tags |
| 16:08 | <webben> | from http://achristiancounselor.com/witness.html ? |
| 16:09 | <Philip`> | Yes |
| 16:13 | <hsivonen> | Philip`: OpenOffice.org and derivatives produce <cite> for what is labeled as Quotation in the English UI |
| 16:14 | <webben> | and that matches the use on that page |
| 16:14 | <webben> | that's not an uncommon confusion |
| 16:14 | webben | wonders if that's been filed as a bug |
| 16:14 | <Philip`> | Hmm, that doesn't match the other uses on that page |
| 16:15 | <hsivonen> | Quotation is Zitat is German and OOo was originally developed by a German team |
| 16:15 | <Philip`> | (<FONT color="#FF0000" size=4>Jesus is the same, yesterday, today and forever</FONT>. He healed then, so He heals now. <cite><b> That was as clear as a bell and simple as pie.</b></cite>) |
| 16:15 | <zcorpan> | Philip`: it seems that two tests in the canvas test suite have no reference image, yet. when you have compared the results, have you skipped them or set them to pass or fail? |
| 16:16 | <webben> | Philip`: It's possible that having inserted a quotation the author then copied and pasted to get the same formatting or something. |
| 16:17 | <Philip`> | zcorpan: I thought there were more than that with no reference image, but only in cases where the result is determined automatically by script and there's no need to manually compare against a reference image |
| 16:18 | <zcorpan> | Philip`: ok, two that i can't determinate if it's a pass or a fail, and they are missing reference images (commented as #TODO) |
| 16:19 | <zcorpan> | Philip`: and they never complete in the runner |
| 16:19 | <Philip`> | 2d.imageData.put.{clamp,round}? |
| 16:19 | <zcorpan> | yes |
| 16:19 | <Philip`> | (I can't see any other TODO-commented ones) |
| 16:20 | <Philip`> | Those really ought to be determined pass/fail by the script |
| 16:20 | <zcorpan> | seems they aren't |
| 16:23 | <Philip`> | In any particular browser/version? |
| 16:23 | <Philip`> | I've not seen it fail anywhere before, and don't see why it would start |
| 16:25 | <zcorpan> | i'm testing with an opera build |
| 16:25 | <Philip`> | Oh, uh... |
| 16:26 | <Philip`> | Does the page's script have the "# TODO ..." line at the bottom? |
| 16:26 | <Philip`> | like, in JavaScript? |
| 16:26 | <Philip`> | where it's a syntax error |
| 16:26 | <Philip`> | because I had mis-indented my YAML |
| 16:26 | <Philip`> | and I fixed the online HTML files but not uploaded the updated source data |
| 16:27 | <zcorpan> | aha |
| 16:27 | <zcorpan> | yeah, they have # TODO |
| 16:28 | <Philip`> | If you're building from the YAML source, just remove two spaces before the "# TODO: c" lines and it should be happier |
| 16:28 | <Philip`> | I really should upload a fixed version at some point, but it takes a non-zero amount of effort... |
| 18:04 | <zcorpan> | i think <blockquote>...<credit>-- <a href>Ian</a></credit></blockquote> should replace <blockquote cite> |
| 18:05 | <zcorpan> | and <q cite> just be dropped |
| 18:06 | <zcorpan> | (or maybe even drop <q> completely) |
| 18:08 | <Lachy> | <blockquote>... <cite>Ian</cite></blockquote> is commonly used for that purpose |
| 18:08 | <Lachy> | though, now that's disallowed |
| 18:09 | <krijn> | Wasn't that <blockquote>..</blockquote><p><cite>Ian</cite></p> recently ? |
| 18:09 | <zcorpan> | yeah, but cite doesn't really give you the desired styling, and makes styling a bit more difficult than having a separate element |
| 18:09 | <zcorpan> | krijn: yeah, that also has problems with styling |
| 18:09 | <krijn> | Yeah |
| 18:12 | <krijn> | So that's what you get when you try to work with the draft now :) |
| 18:13 | <zcorpan> | what? |
| 18:13 | <krijn> | http://fronteers.nl/blog/2008/01/commissie-diplomering-zoekt-vragen - I tried following the HTML5 examples there |
| 18:13 | <krijn> | Almost a month ago that was how you should use <blockquote> and <cite> :) |
| 18:14 | <krijn> | Ow, it still is |
| 18:14 | <krijn> | Even though the name there isn't |
| 18:14 | <krijn> | Oh well |
| 18:39 | <zcorpan> | http://krijnhoetmer.nl/irc-logs/xhtml/20080220#l-423 |
| 18:42 | <hsivonen> | zcorpan: what's "there"? |
| 19:33 | <hsivonen> | http://www.tbray.org/ongoing/When/200x/2008/02/19/Odd-Partnerships#c1203530343.647028 |
| 20:25 | <gsnedders> | dbaron: did the table implement HTML 4.0 or HTML 4.01? |
| 21:34 | <Hixie> | annevk: see my mail to csswg before you change the reference :-) |
| 21:39 | <annevk> | thanks |
| 21:39 | <annevk> | I thought Mark Baker was more pragmatic |
| 21:39 | <annevk> | :( |
| 21:41 | <annevk> | and Mozilla dropping credentials in requests is also beyond me |
| 21:44 | <hsivonen> | annevk: dropping credentials? |
| 21:45 | <annevk> | they suddenly want to do what some people have been advocating, not sending cookies or authentication info |
| 21:45 | <annevk> | no reason has been given |
| 21:46 | <gavin> | where was this announced? |
| 21:47 | Hixie | decides not to reply to some e-mails from hsivonen and annevk about <section> where they're just responding to other e-mails on the subject without really making suggestions for the spec |
| 21:47 | <Hixie> | (e-mails from 2004/2005) |
| 21:47 | <annevk> | gavin, http://lists.w3.org/Archives/Public/public-appformats/2008Feb/0203.html |
| 21:47 | <annevk> | Hixie, if I don't raise questions but just give answers there's no need to either quote or reply to me |
| 21:48 | <Hixie> | :-) |
| 21:48 | <Hixie> | yeah, you and henri have both said that before iirc |
| 21:48 | <gavin> | annevk: http://wiki.mozilla.org/User:Sicking/Cross_Site_XHR_Review provides some rationale |
| 21:49 | <gavin> | the reasons appear to mostly be "it's safer in case something goes wrong" |
| 21:49 | <annevk> | it defeats most use cases |
| 21:50 | <gavin> | I'm not really familiar enough with the usecases to comment |
| 21:50 | <annevk> | gavin, but yeah, that's not a new reason |
| 21:50 | <annevk> | gavin, k |
| 21:50 | <Hixie> | you can already send cookies cross-site using <form> |
| 21:50 | <annevk> | (I read that page earlier fwiw.) |
| 21:50 | <Hixie> | anything that's going to go wrong is already going wrong |
| 21:51 | <Hixie> | the problem is only reading the data back |
| 21:51 | <Hixie> | under anne's fascist "no fancy headers" scheme, you can't even control the content-type! |
| 21:51 | <Hixie> | :-P |
| 21:51 | <annevk> | yeah, lets blame me :p |
| 21:51 | <gavin> | these would be good points to bring up with sicking, I guess |
| 21:51 | <gavin> | maybe you already have |
| 21:52 | <annevk> | Hixie, I have since made a new proposal for headers based on suggestions from Henri, but maybe I should do that again in a separate thread |
| 21:52 | <Hixie> | sicking doesn't sound very convinced based on that wiki page |
| 21:52 | <Hixie> | he even himself raises issues with not sending cookies |
| 21:53 | <annevk> | probably comes from someone else |
| 21:53 | annevk | looks at jruderman |
| 21:55 | <jruderman> | last tuesday, sicking and i were the only ones arguing for sending cookies. most of the others in the meeting were arguing for not sending cookies. |
| 21:56 | <annevk> | wow |
| 21:56 | <jruderman> | it's not very frequent for dan veditz and me to disagree. that was strange. |
| 21:56 | <jruderman> | we spent a whole hour arguing about whether cookies should be sent |
| 21:56 | <Hixie> | if you don't send cookies, it's basicalyl useluss |
| 21:56 | <Hixie> | less |
| 21:56 | <Hixie> | lly |
| 21:57 | <jruderman> | it still works for "public data" without cookies, but yeah |
| 21:57 | <Hixie> | cross-site xhr is not for public data |
| 21:57 | <Hixie> | we can already do that with <script> and json |
| 21:57 | <Hixie> | it's for submitting data (post, etc) |
| 21:58 | <hsivonen> | it seems to me that not sending cookies will lead to site having to exchange tokens and then encoding the tokens in the request URI |
| 21:58 | <annevk> | yeah, and all the non-GET stuff is protected by a preflight request... |
| 21:58 | <jruderman> | <script> and json is less safe |
| 21:58 | <annevk> | hsivonen, the problem with that is that the origin server shouldn't have to know the credentials |
| 21:58 | <Hixie> | jruderman: that _really_ isn't a concern |
| 21:58 | <hsivonen> | at which point the other site has the token and can use it without further participation from the user |
| 21:58 | <Hixie> | jruderman: to most people |
| 21:59 | <jruderman> | hsivonen: or worse, linkedin asking for your gmail password instead of going through the trouble of getting users to send tokens over |
| 21:59 | <hsivonen> | annevk: right, but that seems to be what not sending cookies will lead to |
| 21:59 | <Hixie> | yup |
| 21:59 | <annevk> | hsivonen, true, but that's what we have now |
| 21:59 | <annevk> | hsivonen, so not sending credentials will not give improvements basically |
| 22:00 | <jruderman> | there was also a bunch of discussion of getting users to opt-in to sending cookies for specific (requesting site, target site) pairs |
| 22:00 | <Hixie> | oh lord |
| 22:00 | <annevk> | i saw that |
| 22:00 | <Hixie> | please don't involve the user... |
| 22:01 | annevk | was also scared about the UI stuff he saw on the wiki |
| 22:01 | <jruderman> | that was the strangest part: dveditz was the one arguing for involving the user |
| 22:01 | <jruderman> | he's usually against asking the user questions |
| 22:01 | <jruderman> | and this question would be especially nonsensical |
| 22:01 | <jruderman> | "may firefox send your cookies for gmail to gmail when linkedin wants something?" |
| 22:01 | <jruderman> | "huh?" |
| 22:02 | <annevk> | heh |
| 22:02 | <Hixie> | "would you like to use another browser instead?" |
| 22:02 | <jruderman> | we're having the third part of the cross-site xmlhttprequest security review at 3pm california time (53 minutes from now). you guys are welcome to join. |
| 22:03 | <annevk> | mpt would make a funny blog post out of that one at least :) |
| 22:03 | <jruderman> | oh man i miss mpt |
| 22:04 | <jruderman> | i don't really remember what the arguments against sending cookies were, unfortunately |
| 22:04 | <jruderman> | i should have taken better notes |
| 22:04 | <jruderman> | i'm about to walk from my apartment to the mozilla office, which takes about 22 minutes |
| 22:05 | jruderman | peers out the window to make sure the thunderstorm from last night is gone |
| 22:06 | <annevk> | is there an IRC channel for the meeting? |
| 22:06 | <annevk> | sicking didn't mention any... |
| 22:10 | <jruderman> | it's an in-person / telephone conference meeting |
| 22:10 | <jruderman> | sometimes such meetings have irc "back-channels" for pasting URLs and complaining when you get disconnected |
| 22:10 | <Hixie> | anyone know of a good web page that can take a URL to a csv file and chart one of the columns as a line chart? |
| 22:11 | <jruderman> | there's also debate about whether <iframe> should send cookies, btw |
| 22:12 | <Hixie> | i'm not worried about that one |
| 22:12 | <Hixie> | since if you stop sending cookies with iframes, all of google will break |
| 22:12 | <Hixie> | and so that change would never ship |
| 22:12 | <jruderman> | lol k |
| 22:12 | <annevk> | thank god for Google |
| 22:13 | <annevk> | :twisted: |
| 22:13 | Hixie | fails to find good csv->chart webware |
| 22:13 | <Hixie> | i guess i'll have to do my own |
| 22:14 | <jruderman> | Hixie: knowing that we can never turn off third-party cookies for <iframe> might affect the XHR cookie discussion |
| 22:14 | <jruderman> | so thanks |
| 22:14 | <Hixie> | np |
| 22:14 | <annevk> | Hixie, you could prolly use piechart or something |
| 22:15 | <Hixie> | jruderman: fwiw, google basically also couldn't use cross-domain xhr ("xxx") without cookies either |
| 22:15 | <annevk> | though you'd still have to pull the data through XHR, parse it, and feed it |
| 22:16 | <Hixie> | rendering the chart isn't hard |
| 22:16 | <jruderman> | how does "cross-domain xhr" become "xxx"? |
| 22:16 | <Hixie> | i just hoped someone had done it for me |
| 22:16 | <Hixie> | jruderman: "CROSS-domain eXtensions to Xmlhttprequest" |
| 22:17 | <jruderman> | that's cheating, the second x is 'extensions' and the third is really 'extensible' |
| 22:18 | <Hixie> | bacronyms are all about cheating |
| 22:18 | <jruderman> | hehe |
| 22:18 | <jruderman> | bbiab |
| 22:28 | <annevk> | ok, put a non-fascist header proposal up |
| 22:28 | <annevk> | (i did it before, but this one has its own subject line) |
| 22:30 | <annevk> | > What about Titanic? How should I mark that up? |
| 22:30 | <annevk> | <xhtml2> |
| 22:32 | <annevk> | By the way, the Mozilla discussion jesse outlines above (especially with the <iframe> remark) reminds of the discussion we had at Opera on this very subject |
| 22:52 | <jruderman> | turns out the meeting in 3 minutes is about cross-site XHR issues other than cookies. dveditz and sicking might join this channel at some point today to discuss cookies. |
| 22:52 | <annevk> | ok |
| 22:53 | <annevk> | i probably will be asleep but I guess Hixie will be around |
| 22:53 | <sicking> | well, you're awake now :) |
| 22:53 | <sicking> | so lets shoot the shit :) |
| 22:53 | <annevk> | hehe, sure |
| 22:54 | <annevk> | is the challenger here yet? :) |
| 22:54 | <sicking> | who? |
| 22:54 | <annevk> | jruderman said that dveditz was the guy who was against |
| 22:55 | <annevk> | or do you need convincing too now? |
| 22:55 | <sicking> | and window and tyler |
| 22:56 | <Hixie> | the reasons to include cookies are simple -- if we don't have them, we (google) basically can't use xhr. |
| 22:56 | <Hixie> | and would have to continue using our existing hacks. |
| 22:56 | <sicking> | the reason is simple and everyone agrees it has value |
| 22:56 | <annevk> | there's also plenty of precedent for cookies in safe and unsafe (just POST though) requests |
| 22:57 | <sicking> | so here's the worry: |
| 22:57 | <annevk> | <img>, <iframe>, <script>, <form>, 'background', 'list-style-image', 'content' |
| 22:57 | <annevk> | <link> |
| 22:57 | <sicking> | people are worried basically about misconfigured servers |
| 22:58 | <jruderman> | annevk: we have disabled cookies for <img> and most of those things, except for <iframe> |
| 22:58 | <jruderman> | annevk: dveditz believes safari has disabled cookies for third-party iframes too |
| 22:59 | <Hixie> | jruderman: third-party ones are a different matter, though that would still suck |
| 22:59 | <roc> | now you can confirm that belief! |
| 22:59 | <Hixie> | if we don't include the cookie headers, we have to ask ourselves, why bother with the api at all |
| 23:00 | <sicking> | so a site admin will enable AC (by replying to OPTIONS and/or include the appropriate headers/PIs for GETs). But they would think that because a user makes a request, that the user also has authorized the request |
| 23:00 | <annevk> | (third-party iframe versus cross-document iframe; is there a difference?) |
| 23:00 | <Hixie> | then they'd be wrong |
| 23:01 | <sicking> | whereas in reality the user might simply have visited another site and the site made the request |
| 23:01 | <sicking> | exactly, they'd be wrong, but the worry is that it's an easy mistake to make |
| 23:01 | <Hixie> | easy mistake to fix, too |
| 23:01 | <sicking> | it happens with CSRF all the time now |
| 23:01 | <Hixie> | yup |
| 23:01 | <jruderman> | dveditz! |
| 23:01 | <annevk> | (oh, is third-party iframe the cross-domain case where document.domain doesn't match?) |
| 23:02 | <annevk> | (actually, never mind, you don't know that upfront... duh) |
| 23:03 | <annevk> | jruderman, just cookies or also HTTP authentication? |
| 23:03 | <sicking> | whereas if we didn't send auth/cookies then the user would have to give the thirdparty site their username/passwd which means that the AC site can in fact rely on that the user has allowed the site to use his credentials |
| 23:04 | <Hixie> | giving the third party site their credentials intentionally is worse than anything else that has been suggested as a problem so far |
| 23:04 | <Hixie> | by many many orders of magnitude |
| 23:04 | <sicking> | so it's not about if this opens new vectors or not. It's worry about that web admins realize what these request actually means |
| 23:04 | <Hixie> | we're desperately trying to teach people NOT to give their credentials to anyone |
| 23:04 | <Hixie> | and here you're saying go ahead, give them |
| 23:04 | <sicking> | i agree |
| 23:05 | <Hixie> | that would be a disaster of epic proportions |
| 23:05 | <sicking> | it's how things work today |
| 23:05 | <Hixie> | operas would be written to describe how bad this is |
| 23:05 | <sicking> | haha |
| 23:05 | <sicking> | i can't do anything but agree |
| 23:06 | <sicking> | the example we used was linkedin.com wanting to pull down my address book from gmail |
| 23:06 | <sicking> | they have that feature today |
| 23:07 | <sicking> | and require that you give them your google user/passwd |
| 23:07 | <Hixie> | yes, which is horrific |
| 23:07 | <Hixie> | and probably violates our ToS |
| 23:07 | <Hixie> | five ways from sunday |
| 23:07 | <dveditz> | yes |
| 23:07 | <dveditz> | but the alternative, sending cookies, potentially enables CSRF |
| 23:08 | <annevk> | only if the app opts in to it |
| 23:08 | <Hixie> | i'd take the potential for CSRF, avoidable relatively easily, over asking people to give away their credentials |
| 23:08 | <dveditz> | (lumping http auth in with cookies for now) |
| 23:08 | <dveditz> | annevk: what do you mean by "opts in" |
| 23:08 | <jruderman> | does it enable CSRF that isn't already possible today? |
| 23:09 | <dveditz> | use the "block 3rd party cookies" options to control it? |
| 23:09 | <jruderman> | or does it encourage site authors to build more things that might be vulnerable to CSRF? |
| 23:09 | <annevk> | cross-site DELETE is not possible today |
| 23:09 | <annevk> | but in order for that to work the server first has to reply positively to a preflight OPTIONS request |
| 23:09 | <jruderman> | dveditz: i'm sorry, i don't really remember the objections to sending cookies you and others brought up last week |
| 23:10 | <annevk> | cross-site GET is possible today already, so there are no new CSRF issues there afaict |
| 23:10 | <jruderman> | only a small number of sites will respond to OPTIONS requests, and hopefully those sites are run by people who have their shit together and know how to avoid CSRF |
| 23:10 | <dveditz> | My objection was to giving XSXHR an exemption from the "block 3rd party cookies" pref |
| 23:11 | <dveditz> | if the user says "allow 3rd party cookies" then fine, send them |
| 23:11 | <jruderman> | iframes are already exempt, so that pref doesn't really mean much as is |
| 23:11 | <sicking> | so the thing is that CSRF today is kind of a catastrophy. There are lots and lots and lots of sites that are susceptible to it. If we had a world where cookies weren't sent for thirdparty requests we'd be in a much safer web |
| 23:11 | <Hixie> | well, imho the "block 3rd party cookies" pref should be dropped, so... |
| 23:11 | <dveditz> | iframes are exempt in Mozilla because we're broken |
| 23:11 | <sicking> | so creating another technology like it is a bad idea |
| 23:11 | <Hixie> | sicking: not if we cause people to send credentials to other sites |
| 23:11 | <dveditz> | but Safari, IE7 and Opera appear to apply the option correctly |
| 23:11 | <Hixie> | sicking: then we'd be in a horrendously worse place |
| 23:12 | <Hixie> | (as noted, this is already starting) |
| 23:12 | <jruderman> | sicking: i don't see how you could avoid "sending cookies for third-party requests" if you include top-level loads... |
| 23:12 | <sicking> | jruderman, yes, that is a problem |
| 23:12 | <Hixie> | dveditz: sites like paypal.com already work around the third-party cookie restrictions |
| 23:13 | <Hixie> | dveditz: (by redirecting all traffic through the third-party) |
| 23:13 | <Hixie> | dveditz: all that this pref is doing is making the user's experience slower |
| 23:13 | <Hixie> | dveditz: it's not actually helping anything |
| 23:13 | <sicking> | jruderman, my point is that clearly the technologies we have today are too complex, so the argument "it's no more complex than what we have today" is a bad argument |
| 23:13 | <dveditz> | Hixie: apparently public opinion is against you -- IE7 and Safari block them by default |
| 23:14 | <dveditz> | and people are upset that Firefox hid the pref option |
| 23:14 | <Hixie> | dveditz: public opinion is often against me. that doesn't make them right. |
| 23:14 | <sicking> | Hixie, the third-party cookie pref is mostly to prevent tracking. It does help with that. It also breaks a lot of other things |
| 23:14 | <Hixie> | sicking: it doesn't help with that to any significant degree |
| 23:14 | <Hixie> | sicking: as noted, sites that want to do tracking (e.g. paypal) just redirect all clicks through the third party directly |
| 23:15 | <sicking> | Hixie, it does prevent ad servers from tracking me across the web |
| 23:15 | <Hixie> | sicking: doubleclick disagrees |
| 23:15 | <Hixie> | sicking: they are tracking you quite happily without it |
| 23:15 | <Hixie> | sicking: it just slows down your browsing |
| 23:15 | <sicking> | Hixie, how? The thing is that they have no concept of identity across sites |
| 23:16 | <Hixie> | sicking: paypal redirects most of its links through doubleclick, so that it's a first-party cookie. |
| 23:16 | <sicking> | other than possibly using my IP, which is unreliable because of NAT |
| 23:16 | <Hixie> | sicking: and paypal knows who you are, they have your bank account number / credit card number / e-mail / name / etc. |
| 23:16 | <sicking> | Hixie, the thing is that if nytimes.com, google.com, paypal.com all use ads from doubleclick, doubleclick can know i'm the same guy on all three sites |
| 23:16 | <Hixie> | sicking: google similarly redirects all ad clicks through its servers (though in this case not for user tracking purposes, but that's only because we avoid that kind of behaviour) |
| 23:17 | <Hixie> | sicking: and doubleclick can know that _anyway_, just by having those sites redirect all links through them |
| 23:17 | <Hixie> | sicking: which they are doing, at least with paypal, and probably many other sites |
| 23:18 | <Hixie> | sicking: all you are doing by having the third-party cookie pref is making the user's life harder (can't copy links easily, browsing is slower, user has a false sense of security), without actually reducing any actual privacy leak |
| 23:18 | <sicking> | Hixie, once I click they can know it's me, but not otherwise (assuming good 3rd party cookie blocking was there) |
| 23:19 | <Hixie> | sicking: so you never click on anything? that would make you an irrelevant case, since you'd be the only user to fall into that behaviour pattern. |
| 23:19 | <sicking> | Hixie, ok, so i guess if nytimes directed all clicks on the whole site through doubleclick they could track me. Are they? |
| 23:19 | <Hixie> | sicking: paypal is. |
| 23:19 | <Hixie> | as i keep saying :-) |
| 23:19 | <sicking> | Hixie, even clicks on articles |
| 23:20 | <Hixie> | i don't know what nyt is doing, but paypal certainly is doing this, and i doubt very much that they're the only doubleclick customer doing it |
| 23:21 | <sicking> | paypal points all their internal links at doubleclick? That sounds horrible security wise |
| 23:21 | <sicking> | they're a bank! |
| 23:21 | <Hixie> | i've been saying this for the entire conversation, yes |
| 23:21 | <sicking> | sorry, there were too many conversations and topics at the start |
| 23:22 | <sicking> | well, so it's still doably but require horrible sacrifices. And it gets really complicated if you have multiple things wanting to track you |
| 23:22 | <sicking> | anyway, this is the reason that people want 3rd party cookies disabled |
| 23:22 | <gavin> | I don't see any links that point to doubleclick when I use paypal |
| 23:22 | <sicking> | personally i don't care about being tracked |
| 23:23 | <jruderman> | oh, i thought that when you said "paypal does this" you meant paypal uses redirects through the site they're processing a payment for, not through doubleclick |
| 23:23 | <gavin> | oh, there are some that point to https://paypalssl.doubleclick.net/ |
| 23:23 | <annevk> | is 3rd party cookies disabled by default? |
| 23:24 | <Hixie> | gavin: my understanding is that they do it for a sample of their users, but i honestly have no idea what the details are. it's pretty well documented though, e.g. http://www.grc.com/securitynow.htm#119 |
| 23:25 | <dveditz> | annevk: we have blocked them in FF3b3 |
| 23:25 | <dveditz> | but a couple of sites did break |
| 23:25 | <sicking> | annevk, 3rd party cookies is disabled by default in FF3b3, in safari and in IE7 (sort of) |
| 23:26 | <dveditz> | blocking appears to be the default in Safari and IE7 (though with the right p3p policy IE7 will send you 3rd party cookies, and quite possibly the adservers use policies) |
| 23:26 | <Hixie> | anyone who wants to track people across the web can trivially do so at this point, even without cookies |
| 23:26 | <Hixie> | i think the idea of blocking third party cookies is archaic and paranoid, and makes people feel safe when they should be realising that they are being tracked |
| 23:26 | <sicking> | Hixie, how? The issue of identity is really hard without cookies, and globalStorage i guess |
| 23:27 | <dveditz> | ... says the guy who though <a ping> was a good idea... |
| 23:27 | <othermaciej> | Safari blocks receiving third-party cookies but not sending |
| 23:27 | <sicking> | Hixie, cookies gives your browser an identity. Without it you can have whatever identity you choose anywhere |
| 23:27 | <othermaciej> | our control over cookies is solely on the accepting side |
| 23:27 | <Hixie> | sicking: you can pretty easily "fingerprint" people through things like their user-agent string, ip address, screen size, other js- and http- accessible prefs, etc |
| 23:28 | <Hixie> | sicking: and then with a simple set of analysis scripts you can easily work out who is who |
| 23:28 | <Hixie> | just look at the "anonymised" search query string data aol released |
| 23:28 | <Hixie> | people were about to track down individual users from that |
| 23:28 | <dveditz> | othermaciej: how does that help anything? |
| 23:28 | <annevk> | othermaciej, how does receiving matter for cross-site currently possible? |
| 23:29 | <Hixie> | if a bunch of sites cooperate, you can trivially be tracked across the web |
| 23:29 | <othermaciej> | dveditz: keeps an ad server from tracking you (unless you visit the site it is serving from directly) |
| 23:29 | <dveditz> | but once you've been there (ever in your life) they can track you |
| 23:29 | <sicking> | othermaciej, it's easy to direct a user through doubleclick once though |
| 23:29 | <dveditz> | if you're sending 3rd party |
| 23:29 | <sicking> | othermaciej, and once the cookie is set you're hosed |
| 23:29 | <othermaciej> | yes, but most people don't go to http://doubleclick.net |
| 23:29 | <dveditz> | unless I'm misunderstanding |
| 23:29 | <annevk> | othermaciej, I, I see now |
| 23:29 | <Hixie> | sicking: it's easier to redirect a user through doubleclick every time |
| 23:30 | <Hixie> | sicking: than to do it once |
| 23:30 | <sicking> | othermaciej, so you block on links too? |
| 23:30 | <dveditz> | sicking: you can't block on links, those turn into "first party" pages |
| 23:30 | <othermaciej> | sicking: we don't, so you could use that to work around it |
| 23:30 | <dveditz> | (unless a target is set) |
| 23:30 | <othermaciej> | I'm just explaining what the policy actually is |
| 23:30 | <Hixie> | (also, all this assumes that cookies are particularly reliable as a tracking method, which, frankly, they're not. there's a huge amount of "cookie churn" which makes tracking users quite difficult in practice.) |
| 23:30 | <othermaciej> | not necessarily claiming that it is perfect or even good |
| 23:30 | <sicking> | othermaciej, right, that seems trivial |
| 23:30 | <othermaciej> | since dveditz seemed to misunderstand it |
| 23:30 | <sicking> | othermaciej, heh :) |
| 23:31 | <sicking> | othermaciej, yeah, that helps a lot |
| 23:31 | <sicking> | (you explaining that is) |
| 23:31 | <sicking> | personally i think the whole issue is sort of silly and doomed to fail |
| 23:31 | <sicking> | othermaciej, do you block for <iframe>s too? |
| 23:32 | <Hixie> | sicking: that's what i've been saying :-) |
| 23:33 | <Hixie> | dump the pref, move on, tell the people who complain that they are being tracked whether they send cookies or not, and that they should find better ways to anonymise themselves (e.g. block cookies to all sites except those they enable, and use tor as their network) |
| 23:33 | <sicking> | well, i'm not in charge :) |
| 23:34 | <othermaciej> | sicking: block accepting? yes |
| 23:34 | <sicking> | othermaciej, cool |
| 23:34 | <othermaciej> | as far as I know our policy doesn't break any sites |
| 23:34 | <othermaciej> | we block accepting on third-party redirects too |
| 23:34 | <sicking> | yeah, seems much less likely to break anything. But also seems less likely to stop tracking |
| 23:34 | <jruderman> | Hixie++ |
| 23:34 | annevk | hopes that this crap either goes away or that someone documents it |
| 23:35 | <annevk> | so i guess i tend to agree with Hixie and sicking since i don't have much hope in the latter |
| 23:35 | <dveditz> | othermaciej: what do you mean by 3rd party redirect? paypal.com -> doubleclick.com -> paypal.com wouldn't accept cookies from doubleclick? |
| 23:35 | sicking | hands annevk a cookie |
| 23:35 | <othermaciej> | dveditz: that's right |
| 23:36 | <dveditz> | but what if you end up on a 3rd party site? |
| 23:36 | <dveditz> | legitimately, like "getfirefox.com -> mozilla.com" |
| 23:37 | <dveditz> | or google.com -> google.de based on geolocation |
| 23:37 | <sicking> | so anyhow, back to Access-Control and cross site xmlhttprequest |
| 23:37 | <othermaciej> | then mozilla.com can't set a cookie |
| 23:37 | <Hixie> | interesting, that means dreamhost referrals don't work on safari |
| 23:37 | <dveditz> | I guess users could reload on the new site if something wasn't working |
| 23:38 | <dveditz> | Hixie: they would once you had the cookie |
| 23:38 | <Hixie> | you can't get the cookie |
| 23:38 | <sicking> | uh, so you don't allow setting cookies even on links? |
| 23:38 | <Hixie> | you get it on a redirect |
| 23:39 | <othermaciej> | we allow setting cookies on links (obviously, or you'd never get any cookies) |
| 23:39 | <Hixie> | oh, then it'll work |
| 23:39 | <Hixie> | nevermind |
| 23:39 | <sicking> | so anyhow, back to Access-Control and cross site xmlhttprequest. So the worry was that we'd end up with a bunch of sites having CSRF issues because they don't understand that cookie!=authorization |
| 23:39 | <annevk> | what about <a>.click() then? |
| 23:41 | <annevk> | sicking, sites would first have to become aware of Access Control for that to happen in which case they're informed |
| 23:42 | <othermaciej> | I don't know if anyone has thought of using <a>.click() as a redirect but I suppose that would be a hole in the policy (though we could treat it as a client-side redirect) |
| 23:42 | <sicking> | annevk, the argument is that enabling != being informed |
| 23:42 | <sicking> | annevk, which i think is true |
| 23:42 | <sicking> | to some extent |
| 23:43 | <othermaciej> | would it create CSRF issues for sites that don't change to support Access Control, besides ones they have already? |
| 23:43 | <dveditz> | and maybe now would be a good time to unlump http auth -- AFAIK no one has a "block 3rd-party auth" pref |
| 23:43 | <Hixie> | gosh, whatever will we do, we can never enable <form>s, what if people don't expect a third-party form submission? |
| 23:43 | <othermaciej> | it seems like not |
| 23:44 | <sicking> | if you don't explicitly enable access-control it doesn't matter either way |
| 23:44 | <sicking> | right |
| 23:44 | <sicking> | Hixie, well, you can make a good case for that <form>s should not have been allowed to be cross-site. Ideally <form>s should use AC imo |
| 23:44 | <othermaciej> | in which case it seems safe |
| 23:45 | <othermaciej> | (I don't think "content authors could make mistakes" is a reason to defang the feature, that risk exists with any opening of cross-site access, but we nontheless accept it is useful) |
| 23:45 | <sicking> | i'd say the only reason we allow cross-site <form>s today is that not doing so would break the web |
| 23:45 | <Hixie> | sicking: there's healthy paranoia, and then there's paralysing paranoia that stifles progress |
| 23:46 | <Hixie> | sicking: i'm arguing you're in the second camp right now |
| 23:46 | <sicking> | Hixie, yup, i agree |
| 23:48 | <dveditz> | I think XS-XHR should be treated as any other 3rd party load wrt cookies -- block them if you block them, allow them if allowed |
| 23:48 | <dveditz> | treating them in a special way will confuse users |
| 23:48 | <sicking> | well |
| 23:49 | <sicking> | users are already confused i'd say |
| 23:49 | <othermaciej> | most users do not have conscious awareness of cookies and how they work |
| 23:49 | <sicking> | even we didn't understand the safari policy |
| 23:49 | <sicking> | exactly |
| 23:49 | <dveditz> | sicking: true, but we're also not Safari users |
| 23:49 | <sicking> | if you say confuse servers then i could buy that |
| 23:49 | <annevk> | i didn't know shit about this crazy cookie policies |
| 23:49 | <othermaciej> | cookie preferences and restrictions are only useful for experts who are at the extreme of caring about privacy |
| 23:49 | annevk | thought cookies just worked |
| 23:49 | <annevk> | s/this/these/ |
| 23:49 | <sicking> | but we know a whole lot more about cookies than the average safari user |
| 23:49 | <dveditz> | if I'm a <foo> user and I tell <foo> to block 3rd party cookies, I'd expect it to do whatever it does the same |
| 23:50 | <dveditz> | whether <foo> is slightly different from <bar> doesn't really matter if i don't use browser <bar> |
| 23:50 | <sicking> | we already behave differently for <iframe> though |
| 23:50 | <sicking> | if you block it there too then i agree |
| 23:51 | <dveditz> | yes, treating <iframe> differently is a bug in Mozilla |
| 23:51 | <dveditz> | on the same principle |
| 23:52 | <sicking> | how about we default to what safari does and have a pref for what we're doing now? |
| 23:52 | <Hixie> | oh lord |
| 23:52 | <Hixie> | more prefs would not help matters |
| 23:53 | <sicking> | prefs *always* helps |
| 23:53 | <sicking> | it makes people happy |
| 23:53 | <dveditz> | prefs, prefs, prefs, prefs, wonderful prefs! |
| 23:53 | <Hixie> | i can't tell if you're being sarcastic or not |
| 23:53 | <dveditz> | I'm humming the monty python spam song |
| 23:53 | <dveditz> | if that helps any |
| 23:53 | <sicking> | :) |
| 23:53 | <Hixie> | how about just always allowing cookies (default) or always blocking them, with a white/black list to override the default based on user preference? |
| 23:53 | <annevk> | it does tell you guys are not in QA :p |
| 23:54 | <annevk> | what Hixie says does make a lot more sense imo, at least for users |
| 23:54 | annevk | -> the wire |
| 23:54 | <sicking> | yeah, i agree with that |
| 23:54 | <dveditz> | Hixie: we have that too |
| 23:55 | <Hixie> | dveditz: remove the rest |
| 23:55 | <sicking> | with the QA thing that is |
| 23:55 | sicking | heads to talk cookies |
| 23:55 | <othermaciej> | Safari has 3 options with the middle-ground default |
| 23:56 | <othermaciej> | people rarely have to change it |
| 23:56 | <othermaciej> | not accepting any cookies makes it pretty painful to use the browser |
| 23:56 | <othermaciej> | but at this point I'm not sure if our default policy helps all that much over accepting all cookies |