| 00:31 | <TabAtkins> | MikeSmith: Curious, what are you planning to write with Bikeshed? |
| 00:53 | <MikeSmith> | TabAtkins: reference docs for HTML elements |
| 00:53 | <TabAtkins> | ah, kk |
| 00:54 | <TabAtkins> | Note that Bikeshed does have an "elementdef" shorthand, which is... not currently documented. I'll fix that. |
| 00:54 | <MikeSmith> | oh cool |
| 06:32 | <jamesr__> | TabAtkins: mystery feature is best feature |
| 06:34 | <TabAtkins> | jamesr__: http://memegenerator.net/instance/55380835 |
| 06:45 | <jamesr__> | wow such ads |
| 06:45 | <jamesr__> | so slow load |
| 07:41 | <annevk> | http://www.dreamhoststatus.com/2014/10/16/https-web-site-owners-ssl-v-3-disablement/ |
| 07:42 | <annevk> | "(Remember, everything less than TLS 1.2 with an AEAD mode is cryptographically broken.)" https://www.imperialviolet.org/2014/10/14/poodle.html |
| 07:42 | <annevk> | Anyone know anything about that? |
| 07:44 | <annevk> | MikeSmith: I wonder how much could be solved if we had a way to indicate a tabgroup |
| 08:24 | <MikeSmith> | annevk: dunnoーI've not spent enough time looking at to have an informed view on it. But please post to that bug if you have thoughts. |
| 08:26 | <MikeSmith> | annevk: btw I'm looking into getting the w3c validator working over TLS. I'm told it should be relatively easy. I guess it's just a matter of somebody making time to do it |
| 08:29 | <annevk> | MikeSmith: hsivonen mentioned some issues, but I'm not sure what they were |
| 08:29 | <annevk> | MikeSmith: well, I don't remember |
| 08:30 | <annevk> | MikeSmith: but yeah, if you have full control over the server it should be quite easy |
| 08:39 | <MikeSmith> | annevk: yeah I don't know what issues hsivonen was thinking about but as far as I can tell, with the was W3C systems handle the TLS termination, deploying under TLS in the W3C environment doesn't require me to do anything different at all with the vnu instances. It should should work. |
| 08:41 | <MikeSmith> | annevk: in other news, do you have any opinion on what we should do about document-conformance requirements for meta@http-equiv=X-UA-Compatible |
| 08:42 | <MikeSmith> | one option is to just put it into the spec and make it valid. Another is to put it into the spec and make it required |
| 08:42 | <annevk> | MikeSmith: won't it wither and die with all older IE versions? |
| 08:42 | <MikeSmith> | one would hope. But we don't seem to be there yet |
| 08:43 | <MikeSmith> | in the mean time, most boilerplate things like bootstrap include it |
| 08:43 | <MikeSmith> | s/most/all |
| 08:44 | <MikeSmith> | so the spec is currently at odds with reality on this |
| 08:45 | <MikeSmith> | in practical terms for me, it means the validator is emitting an error for it that is just wasting developers' time, because they're not going to remove it from their documents. |
| 08:45 | <annevk> | MikeSmith: I think at the very least that the proposal to emit an error for developers that have not included it, would also be wasting time |
| 08:45 | <MikeSmith> | and sorta worse, downstream tools that embed the validator have to add code to filter out that error |
| 08:46 | <annevk> | MikeSmith: but I'm okay with making cruft conforming, we're allowing <br/> after all |
| 08:47 | <MikeSmith> | annevk: so yeah point taken and that suggests we should make it valid but optional |
| 08:47 | <MikeSmith> | annevk: ok what about meta@name=viewport |
| 08:50 | <annevk> | MikeSmith: same opinion |
| 08:51 | <MikeSmith> | hai |
| 09:34 | <MikeSmith> | annevk: fyi just filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=27091 about meta@http-equiv=X-UA-Compatible |
| 09:34 | <MikeSmith> | hsivonen: ↑ |
| 09:35 | <MikeSmith> | reading https://wiki.whatwg.org/wiki/Talk:PragmaExtensions I see that Hixie considers this to be a bug in the IANA registry and not really a bug in the spec. Given that, if I make the validator not report an error for it, that's not a wilful violation of the HTML spec, it's just resigning ourselves to the fact that the IANA registration process is broken |
| 09:37 | <MikeSmith> | hsivonen: given that, would you be OK with me going ahead and changing the vnu schema to allow meta@http-equiv=X-UA-Compatible now |
| 09:41 | <MikeSmith> | for those who appreciate irony, the page at https://wiki.whatwg.org/wiki/PragmaExtensions which says that meta@http-equiv=X-UA-Compatible is not valid itself has <meta http-equiv="X-UA-Compatible" content="IE=EDGE" /> |
| 09:41 | <MikeSmith> | view-source:https://wiki.whatwg.org/wiki/PragmaExtensions |
| 09:49 | <annevk> | MikeSmith: I find the idea that http-equiv is actually equivalent to HTTP headers somewhat absurd |
| 09:50 | <annevk> | MikeSmith: not sure why Hixie maintains that point of view |
| 09:50 | <MikeSmith> | I think he's just trying to impose some reasoning on it |
| 09:51 | <MikeSmith> | but yeah I guess it's really just a fiction |
| 10:07 | <gsnedders> | does anyone know how ePub readers parse XHTML de facto? Because AFAICT they all support non-WF content |
| 10:11 | <MikeSmith> | gsnedders: They just just use webkit and I've been told it just goes through the text/html parser in webkit not the XML parser |
| 10:13 | <gsnedders> | MikeSmith: the HTML5 parser in WebKit? Because AIUI stuff like <script /> is handled |
| 10:14 | <gsnedders> | (which IIRC the old WebKit parser handled through reparsing?) |
| 10:15 | <MikeSmith> | hmm maybe they are using the old parser then |
| 10:16 | <MikeSmith> | and if so they can't change it now I guess ,if they have ebooks out in the wild with stuff like <script /> |
| 10:16 | <gsnedders> | Calibre currently uses a patched version of html5lib (except where it's packaged in distros like arch which just use upstream html5lib and probably break stuff…) |
| 10:16 | <MikeSmith> | the epub people seem to have dug themselves into a lot of holes -- against advice from others |
| 10:16 | <gsnedders> | totally |
| 10:17 | <MikeSmith> | I think hsivonen might know something about the implementation details on particular readers -- based on research he did a couple years back |
| 10:18 | <MikeSmith> | but maybe he didn't go too deep into the details, I dunno |
| 10:18 | <gsnedders> | no JS makes testing tiresome, le sigh |
| 10:18 | <gsnedders> | (at least in most readers) |
| 10:19 | <MikeSmith> | they |
| 10:19 | <MikeSmith> | we just need to move ebooks to the web where they belong and where the rest of the world's information content is |
| 10:21 | <MikeSmith> | all of these problems they have arise for requiring users to download and install some separate "reading system" application that users don't want to install to begin with |
| 10:21 | <MikeSmith> | it's fundamentally all user-hostile |
| 10:21 | <gsnedders> | the problem is all getting content to be licensed DRM-free in the first place |
| 10:24 | <gsnedders> | Google Play gets away with doing it all in browser with a page or so of buffering |
| 10:24 | <gsnedders> | but never actually opens the whole thing |
| 10:24 | <gsnedders> | and makes it incredibly user-hostile to copy anything |
| 10:24 | <MikeSmith> | yep |
| 10:27 | <MikeSmith> | the prevent-users-from-copying user hostility just naturally follows from the fundamental flawed foundation of the whole thing |
| 10:30 | <MikeSmith> | we need a kickstarter-like thing for book authors |
| 10:30 | <gsnedders> | tbf, people were trying to prevent copying stuff frm the web 15 years ago |
| 10:30 | <MikeSmith> | oh they still are |
| 10:31 | <gsnedders> | at least the book industry isn't so hellbent on DRM as the movie industry |
| 10:31 | <gsnedders> | oh, I'm not saying that — I'm just saying it's not a new phenomom |
| 10:31 | <MikeSmith> | ok |
| 10:33 | <MikeSmith> | anyway the core problem here is publishers. The Web doesn't need "publishers", and books don't need publishers either |
| 10:33 | <jgraham> | They often do need marketing departments |
| 10:33 | <jgraham> | Which is about 90% of the function of a publisher |
| 10:33 | <MikeSmith> | books should be free but we should have a better way to be able to pay authors to write them |
| 10:34 | <MikeSmith> | the web is its own marketing department |
| 10:34 | <MikeSmith> | the web already has discoverability |
| 10:34 | <MikeSmith> | and good search engines |
| 10:35 | <MikeSmith> | and other good ways to raise visibility of quality content |
| 10:38 | <MikeSmith> | and authors can get together to create their own branded web presenses together without relying on some sugar-daddy publisher where they're just some insignificant tiny sharecropper |
| 10:46 | <jgraham> | I think when enough authors get together like that, they will hire some people to handle the parts they aren't good at. |
| 10:46 | <jgraham> | Pretty soon you have recreated a publisher |
| 10:49 | <jgraham> | c.f. http://www.antipope.org/charlie/blog-static/2013/03/why-i-dont-self-publish.html |
| 10:49 | <MikeSmith> | yeah that's the basic argument but I personally find it more of an excuse for authors to be lazy and complain |
| 10:50 | <MikeSmith> | compare this situation to indie bands |
| 10:52 | <jgraham> | Who largely self-organise into record labels and often preferentially sign with the large corporate labels? |
| 10:53 | <jgraham> | (that is: there are a non-zero number of cases where bands release their first record on some small label, have a little success and then choose to sign to a larger label) |
| 10:55 | <MikeSmith> | the vast majority of bands that sign to a larger label don't make money |
| 10:55 | <MikeSmith> | in many cases, they end up owing the record label money |
| 10:56 | <MikeSmith> | things like https://bandcamp.com/ allow them to have a chance to actually make some money off their records |
| 10:57 | <jgraham> | So I agree that the record industry is strucutred to send most of the money to the label |
| 10:57 | <MikeSmith> | yeah |
| 10:57 | <jgraham> | It isn't clear that the same is true of publishing, or that indie-ness really helps |
| 10:58 | <jgraham> | If being on an artist-run label is so much more profitable, why wouldn't everyone do it? |
| 10:58 | <MikeSmith> | anyway, I understand Charles Stross's POV but he's making a choice not just to save himself money and work. He's choosing to push costs off onto the people who want to read his books. |
| 11:00 | <MikeSmith> | jgraham: as far as "why wouldn't everyone do it", because is requires additional work |
| 11:01 | <MikeSmith> | when I was young I remember there was a time when music clubs move to a "pay to play" system where bands basically had to rent a club if they wanted to perform tehre |
| 11:04 | <MikeSmith> | but bands I knew were already doing "pay to play" in that if they wanted to have a place to perform and get people to show up, they rented some Knights of Columbus meeting hall or other odd place |
| 11:06 | <MikeSmith> | bands that were actually good got known that way and moved on to playing in bigger places. But they got known for doing good live performances first. |
| 11:09 | <MikeSmith> | other kinds of bands got known first mostly from just putting out songs on 12-inch singles that got played at live shows by DJs but never got played on any commercial radio stations. And that's how they got known |
| 11:10 | <MikeSmith> | anyway there are lots of ways to get known and eventually get money that don't involve lazily relegating all the work to some company with a marketing department |
| 11:13 | <MikeSmith> | and somebody who is known like Charles Stross could instead use a kickstarter-like service to raise money for the equivalent of the 2 months of publishing-company production work he claims is needed to complete the publishing process for one of his books |
| 11:34 | <jgraham> | Sure, but kickstarter tends to reward the already-well-known |
| 11:34 | <hsivonen> | annevk, MikeSmith: The TLS problem with Validator.nu is that the requests the validator itself makes are without SNI |
| 11:35 | <hsivonen> | annevk, MikeSmith: for hosting the validator itself, this means it's embarrassing if the validator is hosted in a SNI-requiring way and, therefore, the validator is unable to validate itself |
| 11:36 | <hsivonen> | annevk, MikeSmith: what's really blocking validator.nu being hosted behind TLS, though, is that I haven't decided how to get certs |
| 11:36 | <annevk> | hsivonen: how can it validate other SNI domains then? |
| 11:36 | <hsivonen> | annevk: it can't. and that's going to be a bigger and bigger problem! |
| 11:36 | <MikeSmith> | hsivonen: ah yeah I remember overhearing that discussion now |
| 11:36 | <hsivonen> | (that needs to be fixed) |
| 11:36 | <annevk> | hsivonen: works for whatwg and my site... |
| 11:37 | <hsivonen> | annevk: that's probably because the validator doesn't check the host name against the cert and then the HTTP Host header dispatch happens independently of SNI |
| 11:38 | <hsivonen> | annevk: good discovery |
| 11:38 | <hsivonen> | as for getting certs, first I was thinking of using SNI and getting a wildcard from sslmate. |
| 11:38 | <hsivonen> | then, I figured I'd get identity validated at StartSSL and mint a cert with all my domains |
| 11:40 | <hsivonen> | then I looked at what identity validation means and figured that it's BS that I should give someone ammo to commit identity theft against me in order to get certs |
| 11:40 | <hsivonen> | after all, having my name on a non-EV cert is pointless |
| 11:40 | <hsivonen> | what matters is DV |
| 11:41 | <hsivonen> | the StartSSL requirement to perform identity validation for DV certs seems just and excuse to do some work that justifies the business model |
| 11:41 | <annevk> | DV? |
| 11:41 | <hsivonen> | domain validation |
| 11:41 | <hsivonen> | validating that the public key belongs to validator.nu |
| 11:42 | <hsivonen> | users aren't going to care if the cert also says something about "Henri Sivonen" in the non-EV case |
| 11:42 | <hsivonen> | in the non-EV case, Firefox will say the site is "run by (unknown)" even if the cert claims it's run by "Henri Sivonen" |
| 11:42 | <hsivonen> | so having the string "Henri Sivonen" is pretty useless |
| 11:42 | <MikeSmith> | yep |
| 11:43 | <annevk> | Yeah I don't get why CAs have class1-4 and various other things as UAs just don't care |
| 11:43 | <hsivonen> | so I heard about Namecheap selling multidomain Comodo certs without such bogus paperwork |
| 11:43 | <MikeSmith> | what Firefox is doing is the right thing. Other browsers don't say that? |
| 11:43 | <hsivonen> | but it seems the advertised pricing at Namecheap is misleading and too good to be true |
| 11:44 | <hsivonen> | now I'm stuck between giving StartSSL paperwork I shouldn't have to give to a CA and researching how much the Namecheap offering would really cost me |
| 11:44 | <MikeSmith> | annevk: maybe CAs have that for some client cases other than browsers |
| 11:45 | <hsivonen> | annevk: I suppose for S/MIME, the distinction between StartSSL free and identity validated certs makes a bit of sense |
| 11:47 | <annevk> | hsivonen: why is 30 USD per year cheap? |
| 11:48 | <hsivonen> | annevk: that's the effective per-year cost of two-year identity validated StartSSL certs, right? |
| 11:49 | <annevk> | hsivonen: except with StartSSL you can mint a million of them and they offer wildcards too |
| 11:49 | <hsivonen> | MikeSmith: Chrome and IE don't expose the string "Anne Van Kesteren" for annevankesteren.nl in the doorhanger, either |
| 11:49 | <annevk> | Such a sad string, happy they don't show it |
| 11:49 | <MikeSmith> | ok good |
| 11:50 | <hsivonen> | annevk: right. I don't know how much the Namecheap option would actually cost |
| 11:50 | <annevk> | The Common Name field is also completely broken |
| 11:50 | <annevk> | But that seems not restricted to StartSSL |
| 11:50 | <hsivonen> | I will probably end up sending StartSSL paperwork I shouldn't have to send them and hope they aren't running an identity theft scam |
| 11:54 | <MikeSmith> | hsivonen: btw I notice that Nightly no longer "which is run by (unknown)" for the non-EV case. I just shows omits that part completely. You have to use the "more information" button to see "Owner: This site does not supply ownership information." |
| 11:54 | <MikeSmith> | hsivonen: The old behavior was better for users. I wonder why it was changed. |
| 11:57 | <annevk> | hsivonen: you could prolly try argue with the founder of StartSSL |
| 11:57 | MikeSmith | looks down to the actual cert and sees that the O for *.whatwg.org is "Anne Van Kesteren" |
| 11:57 | <annevk> | hsivonen: he answers support email, it's pretty cool |
| 11:57 | <annevk> | MikeSmith: sssh, don't tell anyone |
| 11:57 | <MikeSmith> | heh |
| 11:57 | <JakeA> | annevk: "run Soft Update just before you plan on booting the service worker" - why before? Are you suggesting blocking the SW running on the update completing? |
| 11:58 | <annevk> | JakeA: I don't know, you'll need to decide that. But say I visit gmail.com and get a SW. Then 48h later it sends a push message. What is the UA to do? |
| 11:59 | <annevk> | JakeA: or I visit gmail.com and get an SW. gmail.com shows a notification. I close gmail.com and 48h later I click the notification. What is the UA to do? |
| 12:00 | <JakeA> | annevk: in the first example, the push message would be handled immediately & the update happens in the background |
| 12:01 | <annevk> | JakeA: so that means you can run a SW that is older than 24h |
| 12:01 | <JakeA> | annevk: yes, you must be able to do that |
| 12:01 | <annevk> | JakeA: is that also what happens on navigation? |
| 12:01 | <JakeA> | annevk: yes |
| 12:01 | <annevk> | JakeA: okay fine, then that's what I'm proposing |
| 12:02 | <hsivonen> | annevk: also, I want to choose an option that I'm willing to pay for indefinitely from one of two CAs |
| 12:02 | <annevk> | JakeA: except instead of making it conditional on navigating, just make it conditional on booting |
| 12:02 | <JakeA> | annevk: I don't want all my apps failing because I've been abroad & no connection for 25hrs |
| 12:02 | <JakeA> | gotcha |
| 12:02 | <hsivonen> | annevk: that is, if I mint a cert at StartSSL that's insanely expensive to mint anywhere else, things will be bad if there's ever a reason to switch CAs |
| 12:03 | <annevk> | hsivonen: start deprecating your subdomains now |
| 12:03 | <annevk> | hsivonen: although it seems CloudFlare is offering wildcard certs pretty cheaply too now |
| 12:03 | <annevk> | JakeA: well they wouldn't fail, they would just be slower to boot once you have connectivity, but avoiding that would be good too |
| 12:04 | <annevk> | JakeA: that does mean you have to support the SW script URL forever theoretically speaking |
| 12:04 | <annevk> | but that makes sense |
| 12:07 | <MikeSmith> | hsivonen: so, about X-UA-Compatible, you ok with me landing https://github.com/validator/validator/commit/53d1154d6dcb18f6280e4b54d53c5ce48328072e ? Or would you prefer to wait for https://www.w3.org/Bugs/Public/show_bug.cgi?id=27091 to be resolved? |
| 12:11 | hsivonen | looks at the bug for rationale |
| 12:13 | <MikeSmith> | hsivonen: I can add more rationale in the bug but basically it comes down to, it's used all over the place and in bootstrap and the other kinds of boilerplate kits like that, and recommended in 3rd-party best-practices docs, etc. |
| 12:13 | <MikeSmith> | hsivonen: in other words we lost the fight. We lost it a long time ago, actually |
| 12:13 | <hsivonen> | MikeSmith: can we make IE=edge the only valid value? |
| 12:14 | <hsivonen> | this is product-specific markup, so in principle it should be invalid |
| 12:14 | <MikeSmith> | hsivonen: I think Hixie would like to probably. Hixie was actually wonder if we should just make the whole element required. |
| 12:14 | <hsivonen> | but then "RDFa" is, in practice, Facebook-specific markup, and we gave up on that one |
| 12:14 | <MikeSmith> | hsivonen: the reality in this case doesn't align well with the principle |
| 12:14 | <hsivonen> | MikeSmith: why should it be required now that new IE defaults to edge? |
| 12:15 | <MikeSmith> | yeah (about the Facebook RDFa stuff) |
| 12:15 | <MikeSmith> | hsivonen: for older IEs I guess |
| 12:15 | <hsivonen> | I'm inclined to opine "let's allow but IE=edge only" |
| 12:15 | <hsivonen> | (Chrome Frame is dead) |
| 12:16 | <hsivonen> | calling the lack of doctype invalid but IE=5 valid seems all wrong |
| 12:17 | <hsivonen> | MikeSmith: also, considering that new IE defaults to edge, I don't think it's a given that we "lost" |
| 12:17 | <MikeSmith> | hsivonen: I mean we've lost as far as not wasting validator user's time currently |
| 12:17 | <MikeSmith> | everyone simply ignores this error |
| 12:17 | <hsivonen> | MikeSmith: OK. I suggest allowing IE=edge only |
| 12:17 | <MikeSmith> | OK |
| 12:18 | <hsivonen> | OK. thanks |
| 12:18 | <MikeSmith> | thank you |
| 12:28 | <hsivonen> | annevk: no way around it that StartSSL is the cheapest option |
| 12:28 | <hsivonen> | but there's still the issue that doing too much TLS with StartSSL poses a problem if ever switching CAs |
| 12:29 | <hsivonen> | so even if I got identity validated, I'd have to decide which subset of my hostnames to enable TLS for |
| 12:30 | <hsivonen> | this is quite a switch that with TLS, you have to think about buying your hostnames instead of thinking about buying domains, only |
| 12:37 | <annevk> | I was hoping domain registrars could just start handing out certificates, but given the state of DNSSEC that might not be a good idea |
| 12:38 | <hsivonen> | annevk: DNSSEC is basically a CA with a 1024-bit root and unpoliced intermediate practices |
| 12:38 | <hsivonen> | annevk: regarding brokenness of everything except TLS 1.2 AEAD suites: |
| 12:38 | <hsivonen> | annevk: RC4 is the only non-AEAD stream cipher and is broken |
| 12:38 | <hsivonen> | annevk: non-AEAD block cipher modes are all CBC |
| 12:39 | <hsivonen> | CBC in SSLv3 is vulnerable to POODLE |
| 12:39 | <hsivonen> | CBC in TLS 1.0 is vulnerable to BEAST |
| 12:40 | <annevk> | And TLS 1.1? |
| 12:40 | <hsivonen> | CBC is in TLS 1.1 and TLS 1.2 is "MAC, then encrypt", which violates the "Cryptographic Doom Principle" |
| 12:40 | <hsivonen> | http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/ |
| 12:41 | <hsivonen> | so that leaves just the AEAD suites |
| 12:42 | <hsivonen> | ...whose ECDHE variants in practice are limited to NIST curves, whose design is questionable |
| 12:42 | <hsivonen> | so, yay |
| 12:42 | <annevk> | So this is why everyone is hpoeful about TLS 1.3? |
| 12:42 | <annevk> | What a clusterfuck |
| 12:43 | <annevk> | Why do we keep doing protocols at the IETF again? |
| 12:44 | <jgraham> | To be fair, cryptography is hard |
| 12:47 | <hsivonen> | annevk: regarding the NIST curves: http://safecurves.cr.yp.to/bada55/bada55-20140722.pdf |
| 12:48 | <annevk> | jgraham: but with these protocols nearly everything went wrong, not just the crypto |
| 12:48 | <annevk> | jgraham: e.g. version negotiation has been a complete disaster |
| 12:52 | <hsivonen> | annevk: to be fair, the IETF inherited backward compat requirements from Netscape |
| 12:53 | <hsivonen> | annevk: and the name TLS is Microsoft's fault (though the IETF let Microsoft impose the name) |
| 12:53 | <jgraham> | I don't doubt that things could have been done better. But "nearly everything went wrong" is evidently not true |
| 12:57 | <hsivonen> | annevk: FWIW, things would be much better if malicious JS on one origin couldn't cause requests to origin of its choice *with cookies* |
| 12:58 | <hsivonen> | annevk: so much of the blame lies in the Web Platform being unusual in terms of what capabilities the attacker is given |
| 12:58 | <annevk> | hsivonen: there's a proposal of sorts for samedocument / firstparty cookies |
| 12:58 | <annevk> | hsivonen: there's even a patch for Firefox |
| 12:59 | <hsivonen> | annevk: what's blocking it? |
| 12:59 | <annevk> | hsivonen: there's a lack of interest |
| 12:59 | <hsivonen> | :-( |
| 12:59 | <annevk> | hsivonen: https://people.mozilla.org/~mgoodwin/SameDomain/ |
| 13:00 | <annevk> | Maybe I should subscribe to dev-security and ask it to be revived |
| 13:00 | <annevk> | Adding a powerful new directive to cookies seems like a good thing |
| 13:01 | <annevk> | Let me bug Mike West |
| 13:01 | <hsivonen> | yeah, though see "cookie cutter attacks" regarding directives :-( |
| 13:07 | <annevk> | Turns out that was a good bet, he's picking up https://github.com/mikewest/cake from abarth |
| 13:08 | <annevk> | I gave him mgoodwin's contact details so they can sort out the firstparty idea |
| 13:21 | <annevk> | hsivonen: that's a hard attack to search for, http://en.wikipedia.org/wiki/Cookiecutter_shark |
| 14:11 | <gsnedders> | Interesting Chakra seemed to have followed Carakan in only having an optimizing compiler originally, given everyone else started out with a baseline JIT. |
| 14:20 | <hsivonen> | annevk: I don't have a cookie cutter reference other than Ivan Ristic's book |
| 14:20 | <hsivonen> | annevk: the idea is that the attacker forcibly forces end of stream such that the ; secure token is lost from a cookie |
| 14:20 | <hsivonen> | annevk: then it gets sent to the attacker without TLS |
| 14:21 | <hsivonen> | annevk: and this works, because even though the TLS layer detects truncation, the HTTP layer doesn't fail in browsers when the TLS layer detects that something is wrong |
| 14:21 | <annevk> | hsivonen: https://twitter.com/ivanristic/status/458689481340878848 |
| 14:22 | <hsivonen> | annevk: oh a fix. cool |
| 14:23 | <annevk> | hsivonen: https://secure-resumption.com/tlsauth.pdf perhaps |
| 14:24 | <annevk> | hsivonen: https://code.google.com/p/chromium/issues/detail?id=244260 seems like browsers might have fixed this |
| 14:25 | <annevk> | hsivonen: does seem like something not actually described by any specification though :-( |
| 14:35 | <gsnedders> | waitwhat, StartSSL *generates the private key* in the browser?!!!! |
| 14:35 | <gsnedders> | ignore me while I go and cry |
| 14:36 | <hsivonen> | gsnedders: <keygen> is OK |
| 14:36 | <hsivonen> | gsnedders: the part where they offer to generate a private key on their "HSM" is the scary part |
| 14:36 | <gsnedders> | but what do they do on IE, then? |
| 14:37 | <hsivonen> | IE has some VBScript equivalent of <keygen>, IIRC |
| 14:37 | <gsnedders> | I thought VBScript support had been dropped except on old compat modes? |
| 14:37 | <hsivonen> | maybe test it in IE? |
| 14:38 | gsnedders | doesn't have a working up-to-date IE here |
| 14:39 | <gsnedders> | hsivonen: if they're using <keygen> howe do you get your private key, though? per spec it's just stored in some undefined local keystore, so you need some per-browser way to get at it?? |
| 14:40 | <gsnedders> | because startssl seem to dump it in a <texarea>, and I can't see how you can do that with <keygen> |
| 14:41 | <gsnedders> | and if it's in a <textarea>, they could've XHR'd it up to their server so you really do need to trust it |
| 14:44 | <annevk> | gsnedders: you can allow StartSSL to generate a private key, but you can also give them an CSR |
| 14:44 | <annevk> | s/an/a/ |
| 14:45 | <gsnedders> | if it really is done in-browser then it's kinda pointless given you're pretty much doomed to be using a PRNG |
| 14:45 | <annevk> | gsnedders: given the conversation above about <keygen>, it's not entirely clear to me what part you're talking about |
| 14:45 | <annevk> | gsnedders: authentication goes through <keygen> |
| 14:46 | <annevk> | gsnedders: certificates have their own distinct UI; if you take them up on their offer to generate a private key, it will be done on their hardware |
| 14:47 | <gsnedders> | annevk: ok, what I'd seen made it sound like it was done in-browser |
| 15:15 | <Domenic> | JakeA: how often does updatefound fire? |
| 15:17 | <JakeA> | Domenic: update checks happen on navigation, and if the fetched SW is byte-different from the current version, updatefound fires |
| 15:17 | <Domenic> | JakeA: so, somewhat often then. OK cool. |
| 15:17 | <Domenic> | JakeA: was wondering if it was a candidate for http://www.w3.org/2001/tag/doc/promises-guide#one-time-events |
| 15:18 | <JakeA> | Domenic: you can limit updates using max-age on the script, but to a max of 24hr |
| 15:18 | <JakeA> | Domenic: ahh I see. No, it's possible to have that fire multiple times through the life of the doc |
| 15:18 | <JakeA> | Rare I imagine, but possible |
| 15:31 | <Domenic> | JakeA: yeah. even that's not too much of a problem, but the question is really do you want to set it and only handle the next case, or set it and handle all future cases. i'd guess the latter, so event is good. |
| 16:40 | <Hixie> | the HTML spec explicitly says that http-equiv isn't equivalent to HTTP headers, i haven't said they were equivalent for years |
| 16:42 | <tantek> | Hixie I can see it now |
| 16:43 | <tantek> | http-equiv is not equivalent. distributed extensibility is slavery. living specificiation is stability. ;) |
| 16:43 | <Ms2ger> | Stalality? |
| 16:43 | <Hixie> | not sure about that middle one |
| 16:44 | <Hixie> | (distributed extensibility is reasonable, a priori. It's the way it's usually implemented that's the problem.) |
| 16:58 | <tantek> | distributed extensibility is both an anathema to interoperability, and a reasonable source of research for standards development. |
| 17:33 | <TabAtkins> | Anyone wanting to run Bikeshed on Windows, and willing to test the new install steps that just got committed to the documentation? |
| 17:36 | <TabAtkins> | If so, https://github.com/tabatkins/bikeshed/blob/master/docs/install.md and let me know. |
| 17:43 | <Domenic> | <3 |
| 17:47 | <Hixie> | tantek: nah, you can make things extensible without losing interop. I mean, all scripting is basically "extensibility" for example. Same with the class="" attribute. |
| 17:47 | <Hixie> | tantek: microformats is an example of "distributed extensibility" and it doesn't harm interop. |
| 17:48 | <tantek> | Hixie - au contraire - the fact that microformats is a community for agreeing upon vocabularies has often been a criticism in the past (centralized). |
| 17:49 | <tantek> | and that agreement (as "centralized" as it may be) is the reason for interop |
| 17:49 | <tantek> | similarly, registries, like the rel registry |
| 17:49 | <tantek> | meta names |
| 17:49 | <tantek> | etc. |
| 17:50 | <tantek> | class attribute is a good example of distributed != interop. e.g. try re-using a style sheet from one site with the HTML with class names of another - I'd be very suprised if you found *any* interop there |
| 17:51 | <Hixie> | sure, the "implementation" of the class attribute is the style sheet or script that uses it |
| 17:51 | <tantek> | the d.e. folks aren't really interested in interop (or they don't understand interop), they appear to be mostly interested in the *freedom* to just make things up (like XML before them, etc.) |
| 17:51 | <tantek> | hence the analogy to Orwell's "freedom is slavery" 1984 quote |
| 17:51 | <Hixie> | i mean you could say that different file formats are bad for interop because if you take an HTML file and stick it in a PDF viewer, it fails, but i'm not sure that's an argument against anything useful |
| 17:51 | <Hixie> | there are many "d.e. folk" with different interests |
| 17:52 | <tantek> | my PDF viewer happens to be Firefox so maybe that works now? |
| 17:52 | <Hixie> | you know what i mean |
| 17:52 | <tantek> | Hixie, I admit I have not maintained a sourced taxonomy of "d.e. folk". could make for an interesting study. |
| 17:55 | <Hixie> | "distributed extensibility" just means "the ability to do new things (extend) without coordination with the original source (distributed)" |
| 17:55 | <Hixie> | "document.foo = 1" is "distributed extensibility" -- you're extending the Document object with a property "foo" |
| 17:56 | <Hixie> | without coordinating with Anne |
| 17:59 | <tantek> | seems we have different meanings for d.e. which I suppose is self-consistent with the term |
| 17:59 | <Hixie> | what's your meaning for it? |
| 17:59 | <TabAtkins> | Hahaha |
| 18:00 | <tantek> | that different (distributed) people/groups can extend and expect interop |
| 18:02 | <Hixie> | how is that inconsistent with my example? |
| 18:03 | <Hixie> | what do you mean by "interop"? |
| 18:04 | <Hixie> | do you mean like group A and group B both come up with technology for describing contact details, and somehow content from group A works fine in processors made by group B despite them having no coordination? |
| 18:04 | <Hixie> | because that seems like a magical pipedream that has never happened and is unlikely to happen anytime soon |
| 18:04 | <Hixie> | if you don't mean that, then it seems consistent with what i said |
| 18:07 | <boogyman> | annevk: i saw http://wingolog.org/archives/2014/10/17/ffs-ssl and thought you might get a kick out of it. |
| 18:09 | <TabAtkins> | In the phrase "javascript crypto", my eyes *insist* that "javascript" is misspelled and needs a "y" in it. |
| 18:11 | <annevk> | boogyman: I think he's wrong about StartSSL |
| 18:12 | <annevk> | boogyman: also, it seems he forgot about the HSTS part? |
| 18:12 | <boogyman> | hsts is down further in the article |
| 18:13 | <annevk> | boogyman: it's not enabled though, you gave me a http:// link |
| 18:14 | <boogyman> | "Except that doesn't work the first time you go to a web site" |
| 18:15 | <annevk> | boogyman: he has not enabled it |
| 18:15 | <annevk> | Anyway, as seen earlier today it's fairly easy to rant about TLS |
| 18:16 | <boogyman> | I just thought you may have some empathy for the author. |
| 18:17 | <annevk> | boogyman: fair |
| 18:44 | <TabAtkins> | Domenic: Dunno if you're using the {{foo!type}} syntax yet, but if so, I've changed it to use two !! to make collisions less likely. |
| 18:45 | <Domenic> | TabAtkins: don't know what that does, heh |
| 18:45 | <TabAtkins> | All right, cool. ^_^ |
| 18:45 | <TabAtkins> | It's an inline type specifier for the shorthand syntax. Identical to <a data-link-type=type>foo</a>. |
| 18:46 | <TabAtkins> | (Since {{foo}} defaults to the "idl" link type, and sometimes you need to disambiguate.) |
| 18:46 | <TabAtkins> | (I'm adding it to the other link shorthands right now.) |
| 18:53 | <annevk> | TabAtkins: can https://dom.spec.whatwg.org/ be done in Bikeshed? Note how it no longer has "This version" links or an editor field or some such |
| 18:56 | <annevk> | Hixie: I fixed the Twitter script, but the last two commits did not use it |
| 19:11 | <Domenic> | annevk: I made TabAtkins get rid of "this version"; unsure if editor is optional yet. |
| 19:23 | <Hixie> | annevk: k |
| 19:31 | <TabAtkins> | annevk: Hm, why no editor? |
| 19:32 | <Hixie> | HTML doesn't mention the editor either except in the acknowledgements |
| 19:32 | <TabAtkins> | Relaxing these kinds of constraints means error-detection is less useful. :/ But if necessary, I can add a value that lets you explicitly opt out of Editor mandatoriness. |
| 19:32 | <Hixie> | (i felt it was too braggy, personally) |
| 19:46 | <Hixie> | anyone know why the w3c hasn't published the HTML5 REC yet? I thought they said they were done. |
| 19:46 | <Hixie> | I had assumed that meant they had reached REC |
| 19:48 | <wilhelm> | Something tells me it will be published in a week and a half, from a depressing conference hotel on a parking lot in Santa Clara. |
| 19:51 | <TabAtkins> | hahaha |
| 19:51 | TabAtkins | is doing nothing but posting "hahaha" today. |
| 19:54 | <wilhelm> | Mead may be required that week. That's not so far away, right? |
| 19:57 | <TabAtkins> | wilhelm: Rather close. I'm going there today! |
| 20:28 | <annevk> | TabAtkins: I think marcosc suggested that at some point, to get the ego out of the game (in case there is any) |
| 20:31 | <TabAtkins> | annevk: Interesting. |
| 20:33 | <annevk> | And while I put a lot of time into writing and research, ultimately there's a great many people involved |
| 20:33 | <annevk> | I still have my contact details at the bottom of the document, which seems better as now people are more encouraged to use public communication mechanism |
| 20:33 | <annevk> | s |
| 20:36 | <TabAtkins> | All right, all right, I'll add a feature for it. |
| 20:36 | <TabAtkins> | Suggestions on what you should write in the `Editor:` line to indicate this? |
| 20:36 | <TabAtkins> | Editor: NOT IMPORTANT JEEZ |
| 20:37 | <astearns> | Editor: Schmeditor |
| 20:38 | <TabAtkins> | That's not a bad idea. |
| 20:39 | <annevk> | TabAtkins: leave it blank? |
| 20:39 | <annevk> | TabAtkins: or omit it? less boilerplate... |
| 20:39 | <estellevw> | Question re the autofocus attribute: https://html.spec.whatwg.org/multipage/forms.html#autofocusing-a-form-control:-the-autofocus-attribute. |
| 20:39 | <estellevw> | Only one element should have autofocus set. If more than one, implementation used to be the LAST element with the attribute would get focus. Safari still does this. |
| 20:39 | <estellevw> | All other browsers now focus on the FIRST element with autofocus. |
| 20:39 | <TabAtkins> | Omitting it means I can't log an error when you leave it out. Most of the time you do want an editor+contact info up in the header. |
| 20:40 | <estellevw> | Don’t exactly see where in the spec this is indicated as the first should get focus. |
| 20:40 | <estellevw> | I filed a bug that the first should get focus a few years back, and am glad the change was made, but not sure what it the spec makes it so. |
| 20:40 | <Hixie> | estellevw: they should all get focus, as they are inserted. |
| 20:40 | <estellevw> | so, then, it should be the last one |
| 20:40 | <estellevw> | ? |
| 20:41 | <TabAtkins> | Yeah, sounds like that's implied. |
| 20:41 | <Hixie> | right |
| 20:41 | <estellevw> | Which would mean only Safari is doing it right |
| 20:41 | <annevk> | TabAtkins: I want an error when I leave it in :p |
| 20:42 | <estellevw> | All browsers used to focus on the last one (other than some mobile that iddn’t support autofocus), but now all except Safari focus on the first one |
| 20:42 | <estellevw> | All = IE11, Chrome, Opera FF in the above sentence |
| 20:42 | <TabAtkins> | annevk: If you think it should be a general policy for WHATWG specs, okay, I can do something about that. If it's just you, you can do it yourself. ^_^ |
| 20:43 | <Hixie> | estellevw: (see "When an element with the autofocus attribute specified is inserted into a document, user agents should run the following steps") |
| 20:43 | <TabAtkins> | (Just need to put an `"Editor":"schmeditor"` line in defaults-whatwg.include .) |
| 20:43 | <Hixie> | estellevw: oh nevermind |
| 20:43 | <Hixie> | estellevw: step 7 means that you only actually move focus for the first one |
| 20:43 | <estellevw> | yeah, saw that, which is why I didn’t understand why IE, chrome, O and FF changed it to focusing on the 1st autofocus |
| 20:44 | <annevk> | TabAtkins: that sounds reasonable |
| 20:44 | <estellevw> | ah, so step 7 is what makes it the “1st” thanks Hixie |
| 20:44 | <TabAtkins> | Actually, we can add that line *now*, and if you actually specify an Editor, it'll override that. |
| 20:44 | <annevk> | TabAtkins: I guess I'll try to convert something simple like Fullscreen next week |
| 20:45 | Ms2ger | sure wouldn't mind not having to worry about anolis anymore |
| 20:45 | <annevk> | Actually, should probably start with URL as it wants Bikeshed for those syntax diagrams |
| 20:46 | TabAtkins | is eating the world. |
| 20:49 | <Domenic> | annevk: let me know if you want help getting the deploy process all set up. I really <3 my automatic generate-on-commit with /branch-snapshots/ and /commit-snapshots/ |
| 20:49 | <TabAtkins> | Domenic: Write that stuff down, yo. |
| 20:49 | <Domenic> | It's really great for PRs where you can do e.g. https://github.com/whatwg/streams/pull/233 and then once Travis finishes building you can just link to hte branch snapshot |
| 20:49 | <Domenic> | TabAtkins: good idea |
| 20:50 | <Ms2ger> | Did anyone ever do an acid3 post-mortem? |
| 20:56 | <Hixie> | Ms2ger: not quite a postmortem, but i did write a "lessons learnt" list |
| 20:56 | <Hixie> | Ms2ger: http://hixie.ch/tests/evil/acid/004/ |
| 21:01 | <annevk> | Domenic: so you edit one file and then commit? all the building happens remotely? |
| 21:01 | <annevk> | Domenic: what if you make a mistake? |
| 21:01 | <Domenic> | annevk: yep. |
| 21:01 | <Domenic> | annevk: I can also generate it locally |
| 21:01 | <Domenic> | annevk: haven't gotten a watcher up and running yet but it should be pretty easy now that there are instructions for running bikeshed on windows |
| 21:01 | <Domenic> | (i've been using curl in the meantime) |
| 21:02 | <Domenic> | more directly: I generate it locally, but i don't commit the generated content |
| 21:02 | <annevk> | "Array.prototype.values is not web compat (even with unscopables)" |
| 21:03 | <annevk> | That is some sad shit |
| 21:03 | <annevk> | Soon |
| 21:03 | <annevk> | "query() is not web compat (even with unscopables)" |
| 21:08 | <TabAtkins> | JS's extensibility comes back to bite it. :/ |
| 21:09 | <annevk> | I wonder if the polyfill crowd is taking notes |
| 21:10 | <TabAtkins> | Designing good extensibility which is lightweight but avoids extensions quashing built-ins or the other way around is hard, but necessary. |
| 21:10 | <TabAtkins> | Hopefully modules and relationships end up making this easier, though it means migrating away from own properties. |
| 21:18 | <Domenic> | annevk: that's assuming array subclassing is even web-compatible :-S |
| 21:24 | <annevk> | Domenic: good point |
| 21:25 | <annevk> | Domenic: this is why ES6 is becoming kind of a clusterfuck |
| 21:25 | <annevk> | Domenic: lots of good untested ideas |
| 21:38 | <Domenic> | wow https://html.spec.whatwg.org/multipage/embedded-content.html#timeranges |
| 21:38 | <Domenic> | what is this it has an array but no indexed getter |
| 21:38 | <Domenic> | s/an array/a length property |
| 21:39 | <Hixie> | each item has two values (a start and an end) |
| 21:39 | <Domenic> | myTimeRanges.start(3) instead of myTimeRanges[3].start |
| 21:39 | <Hixie> | using [3].start would mean that every range is a new object |
| 21:39 | <Domenic> | yes |
| 21:39 | <Domenic> | is that bad? |
| 21:39 | <Hixie> | yes? |
| 21:39 | <Hixie> | malloc() is expensive |
| 21:40 | <Domenic> | internally the implementation is presumably tracking them all anyway? |
| 21:40 | <Domenic> | as a list of { start, end } pairs? |
| 21:40 | <Hixie> | internally the data is probably deep in the media framework |
| 21:40 | <Domenic> | this seems like premature optimization |
| 21:40 | <Domenic> | if nothing else just name it .size instead of .length |
| 21:40 | Hixie | shrugs |
| 21:40 | <Domenic> | and by that i mean "it would have been nice if" |
| 21:41 | <Hixie> | i don't see much difference between "length" and "size" here |
| 21:41 | <Domenic> | length => array-like in JS, pretty universally |
| 21:41 | <Domenic> | This is the first exception I've ever found |
| 21:41 | <Hixie> | { length: 5 } |
| 21:41 | <Hixie> | second exception? |
| 21:41 | <Hixie> | :-P |
| 21:41 | <Domenic> | Yep, that's an array-like with holes |
| 21:42 | <Domenic> | Array.from({ length: 5 }) will generate [undefined, undefined, undefined, undefined, undefined] |
| 21:42 | <Hixie> | nope, it's just a dictionary with one of its fields being a length |
| 21:42 | <Hixie> | and it's a length in centimeters |
| 21:42 | <Domenic> | what i'm saying is that length is a semi-keyword |
| 21:42 | <Hixie> | [citation needed] |
| 21:42 | <Domenic> | semi- => not really but it's used that way and the language is built to assume that |
| 21:43 | <TabAtkins> | Hixie: No, .length makes something an array-like, effectively. |
| 21:43 | <Hixie> | it is true that if you have an array-like, using length means it'll fit into existing APIs more neatly |
| 21:43 | <Hixie> | it does not follow from this that if you use length, you have an array-like. |
| 21:44 | <TabAtkins> | Duck-typing, bro. |
| 21:44 | <TabAtkins> | It's not great, but it exists. |
| 21:44 | <TabAtkins> | Like having .then() makes you a promise-like. |
| 21:45 | <Hixie> | again, having a then() means you can be used in the promise APIs. It does not follow from this that having a then() means you are a promise-like. |
| 21:45 | <TabAtkins> | That's what duck-typing means. |
| 21:46 | <Hixie> | no |
| 21:46 | <Hixie> | duck typing means that an object that matches a pattern makes it valid for use in certain environments |
| 21:46 | <Hixie> | it does not mean that an object that matches a pattern is intended for use in those environments |
| 21:47 | <Domenic> | in this case it's more about expectations being broken |
| 21:47 | <Domenic> | if i see .length in an IDL I expect to be able to index into an object |
| 21:47 | <Domenic> | Or even in my REPL |
| 21:47 | <TabAtkins> | It means that the object is, duck-typely, a Foo-Like. |
| 21:54 | <Hixie> | if something quacks like a duck and looks like a duck you can use it in places where ducks would work and it'll do something well-defined. It does not mean that it is a duck or that the well-defined thing will be useful. |
| 21:55 | <TabAtkins> | It is a duck when talking duck-typely. |
| 21:55 | <TabAtkins> | Not, perhaps, when talking in reference to other ontologies. |
| 21:57 | <Hixie> | if by "is a duck" you mean "not actually a duck" then sure |
| 21:57 | <TabAtkins> | "is functionally a duck" |
| 21:57 | <Hixie> | not necessarily |
| 21:58 | <Hixie> | case in point, { length: 5 } is not "functionally an array" |
| 21:58 | <TabAtkins> | Sure it is. You can put it in Array.from() and it'll work just fine. |
| 21:58 | <Hixie> | it'll do something well-defined and useless |
| 21:58 | <TabAtkins> | Yup. It's functionally an array, though, in that it acts like an array. |
| 21:59 | <TabAtkins> | You're arguing sideways at me, by continuing to insist that there's a particularly ontology in which it's not an array, and that's the only correct ontology. |
| 21:59 | <Hixie> | "functional" means "practical and useful" |
| 21:59 | <Hixie> | it's not practically or usefully an array |
| 21:59 | <TabAtkins> | Dictionary arguments aren't very useful. ^_^ |
| 21:59 | <TabAtkins> | Especially because in this case it means "functions as if". |
| 21:59 | <Hixie> | dictionary arguments, to pardon the pun, are actually a great example of this |
| 22:00 | <Hixie> | by which i mean WebIDL Dictionary function arguments |
| 22:01 | <Hixie> | if a function is expecting an object with two fields "a" and "b", both set to integers, and you pass it an object with "b" and "c", both set to strings, it'll "work" |
| 22:01 | <Hixie> | but that doesn't mean that that it was intended for that purposes nor that it's a useful way of using that object |