00:00:12 timbl: the whole thing is a combination of software and law 00:00:48 dherman: but if they're moving toward these trusted execution environment models with secure bits where they control the computer... 00:01:19 dherman: I don't understand how that model is compatible with a browser that the user installs on their system 00:03:00 timbl: there are extreme positions 00:04:26 dherman: isn't this direction more than is necessary to protect their content? 00:05:43 (discussion of measures that still leave you in control of your machine but also help make content creation economically viable) 00:06:41 timbl: content providers will let different quality versions of content be protected by different levels of CRM strength 00:08:26 wycats: a solution that stops browser UI from allowing easy downloading would get us pretty far... 00:10:48 One more suggested reading: http://en.wikipedia.org/wiki/Hdcp 00:13:28 dherman: a good analogy is the H.264 situation with Mozilla and Cisco---an open source plugin 00:14:45 twirl/wycats: there's still the possibility of "Exclusive to IE" content 00:14:59 twirl: there's nothing we can do about that 00:15:15 wycats: that doesn't seem to be the goal of e.g. Netflix 00:15:30 timbl: you could imagine Sony films making things available only on Sony computers and TVs... 00:15:45 wycats: that is interesting but not necessarily what we're most worried about... 00:17:02 twirl: I think the content owners will not stop until they have even more control... 00:17:20 dka has joined #tagmem 00:20:10 JeniT has joined #tagmem 00:21:23 (discussion of how bad it can get; Sony rootkit etc.) 00:21:51 CF: http://www.copyrightreform.eu 00:23:20 dherman has joined #tagmem 00:23:21 dka: https://wiki.mozilla.org/EU_Copyright_Consultation 00:24:33 this is what's happening in the UK: http://blogs.ch.cam.ac.uk/pmr/2014/03/30/uk-copyright-reforms-set-to-become-law/ 00:25:57 (various idle dreams of a better world...) 00:27:16 In my view we should strive for changing basics of copyright law, i.e. Article 2.6 of Berne Convention. It now states that "This protection shall operate for the benefit of the author and his successors in title." [1] Proper formula should state that: (a) intellectual property right is legal, not natural[2]; (b) copyright protection shall operate for the benefit of both authors and the Society; (c) digital millenium had made traditional forms of per-copy pa[CUT] 00:28:10 bsolete. So new law should: (a) find a balnce between authors and society rights; (b) strongly support new forms of payment (subscription services, crowdfunding, etc); (c) protect public interests, such as filling up public domain, ensuring availability of content for educational purposes, simplifying content publishing and making easier to publish content abroad -- and protecting right of linking, of course. 00:29:01 dka: how would we design a system from scratch to give these guarantees? 00:29:38 dherman: what matters is the actual state of who's pushing what, and right now the question is about Netflix and Google 00:30:22 dka: is the current design of EME feasible for smaller content providers to use, or would the cost be prohibitive? 00:30:33 plinss: the cost would not be prohibitive but it would be high 00:33:05 plinss: one alternative is something good enough for most people via crypto + streams + a "secure worker" 00:33:15 wycats: on the list Henri said this would not go far enough 00:33:24 plinss: I agree it wouldn't. But I. don't. Care. 00:33:39 plinss: So let Google build their own nonstandard DRM system that goes farther 00:34:02 plinss: we'll build our own standard DRM system that runs on top of the web platform and see which one wins on the web. 00:34:13 dherman: wouldn't Google easily win? 00:34:35 annevk: remember it's Google + Microsoft + Netflix. It seems like a nonstarter to compete with that. 00:34:55 plinss: I think providers will recognize they're leaving money on the table by restricting themselves to only those. 00:36:06 wycats/Domenic: Netflix will just tell you to use a browser that has the nonstandard thing. Whether it be Silverlight or EME. 00:37:33 dka: the missing part of plinss's plan is some high value content that would drive adoption of such a standard DRM system 00:38:28 https://plus.google.com/+IanHickson/posts/iPmatxBYuj2 00:38:52 dka has joined #tagmem 00:38:58 rrsagent, draft minutes 00:38:58 I have made the request to generate http://www.w3.org/2014/04/03-tagmem-minutes.html dka 00:39:03 rrsagent, make logs public 00:39:54 plinss: we shouldn't keep EME in the W3C 00:40:06 wycats: is it a good world if EME get standardized elsewhere and everyone else ships anyway 00:40:22 plinss: I think it would be good if we gave an alternative within the W3C instead 00:41:21 plinss: SecureWorker is in a stronger sandbox than most but gives the promise that the browser will not be able to look into or debug the code 00:42:00 plinss: so e.g. it can go fetch the keys ... or something ... and its code doesn't even need to be obfuscated 00:42:12 dherman: Henri was trying to explain to me why this was very bad... 00:42:21 wycats: because it doesn't help against the threat model problem? 00:43:11 dherman: the general idea of a worker that is isolated to be able to touch data that we don't want to leak to another part of the platform is possibly impossible to make work from a security perspective on the network layer. I'm not sure but a coworker told me. 00:48:50 twirl: there is a devil hiding in EME. It's this license request thing. 00:49:03 wycats: so they're mandating a rootkit on your computer? 00:49:15 timbl: could we have the browser do that license request instead of the root-access secret thing? 00:49:26 twirl: yes but Netflix would not allow this 01:22:56 JeniT has joined #tagmem 03:29:28 timbl has joined #tagmem 16:10:15 RRSAgent has joined #tagmem 16:10:15 logging to http://www.w3.org/2014/04/03-tagmem-irc 16:10:17 RRSAgent, make logs public 16:10:17 Zakim has joined #tagmem 16:10:19 Zakim, this will be TAG 16:10:19 ok, trackbot; I see TAG_Weekly()1:00PM scheduled to start in 50 minutes 16:10:20 Meeting: Technical Architecture Group Teleconference 16:10:20 Date: 03 April 2014 16:12:13 Scribe: Yves 16:12:33 dka, http://www.huffingtonpost.co.uk/2014/04/02/saharan-dust-smog-london_n_5075994.html 16:12:55 Topic: Quota API 16:14:22 https://github.com/w3ctag/spec-reviews/blob/master/2014/02/quota-management-api.md 16:15:13 https://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html - 2014-02-04 version 16:16:04 dherman has joined #tagmem 16:16:49 ... temporary vs persistent storage underspecified 16:23:09 http://www.w3.org/TR/file-system-api/ 16:23:17 http://w3c.github.io/filesystem-api/Overview.html 16:24:42 (discussion about different File APIs) 16:26:56 (going through the review) 16:28:04 got good response from the editor 16:29:52 Domenic: few comments about javascript issues (more nitpicking than strong comments) 16:31:07 wycats: the time issue depends on the precision you mean, you may need ms, or even something with a higher precision 16:34:18 (discussion about number size) 16:37:08 anne: we need to check what should be cleaned in webidl 16:39:09 wycats: I don't really believe in Object.freeze() (re: supported types) 16:39:20 domenic: perhaps we need another kind of array 16:41:40 anne: the main reason to have something readonly is when you have multiple consumer 16:45:04 dave: I don't see the use of freeze here really motivated 16:47:50 dherman has joined #tagmem 16:50:59 annevk has joined #tagmem 16:51:04 Domenic: maybe project https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682 16:55:19 dka: sounds like more a JS feedback that feedback on quota API 17:02:56 domenic: I may remove the 'freeze' comment as there is no real consensus 17:04:20 hey all 17:04:38 Dimitri and I will be there sometime after 10:15...apologies for the delay 17:04:46 Dimitry, even 17:07:04 ooof...looking like 10:25. 17:07:33 dglazkov__ has joined #tagmem 17:10:50 dherman_ has joined #tagmem 17:13:46 Also note that Wonsuk and Jungkee will join us at 11:00. 17:25:55 twirl: you're in the US now ;) 17:26:23 hahaha 17:27:10 Here 17:27:17 Yes! 17:31:46 +Wonsuk Lee, Jungkee Song, Dimitri Glazkof 17:32:36 Presetnt+ Wonsuk Lee, Jungkee Song, Dimitri Glazkof 17:32:43 Topic: Web Components 17:33:15 Topic: Web Components 17:34:44 Dimitri introducing Web components 17:35:22 DG: shadow dom, imports, templates... decorators (this one postponed) 17:35:58 goal was to make as little change as possible 17:36:17 like templates that "only" change the HTML parser 17:39:47 alex: the DOM Object is problematic as all implementations are surfacing at the js level the underlying implementation that is highly tuned for speed in almost all implementation 17:40:34 ...and so we're trying to iterate towards a better world from a place that isn't compatible with it at a deep level today 17:40:47 the world with @@create will help, but we don't have it yet 17:40:54 and a self-hosted world would also be better 17:40:57 but we don't have that either 17:41:15 DG: shadow DOM is a trouble maker, some trade-off were needed, like for rendering 17:41:31 need to expose more hooks 17:55:04 who is scribe? 17:56:26 dka has joined #tagmem 17:56:52 alex: there is some tension about the possibility of creating new elements (fragmentation, etc...) 17:57:42 dg: inventing your own HTML tags is a useful thing, doing 'div class' everywhere is also bad 17:59:32 see alex's blog post 17:59:52 yes, that one 18:00:00 http://infrequently.org/2013/11/long-term-web-semantics/ 18:01:24 OH: "XML is not that bad in term of expressiveness" 18:01:42 [scribe protecting wycat's anonymity] 18:02:10 (was discussion about dwelling into microsyntax) 18:05:16 domenic: there is encapsulation issue, like chrome's video tag implemented using shadow dom, but not really like other shadow dom things 18:05:49 also what are the hooks that the shadow dom can't access, wycats raised the preload-scanner issue 18:07:33 DG: instead of saying "there is magic here" we should say "there are things you won't have access to" (like control if a window will be inside or outside the browser window 18:07:33 timbl has joined #tagmem 18:11:56 anne: the fact that form control was not completely described helped implementing them in a different way for different platforms 18:12:48 FYI I moderated a panel on web components at Edgeconf 3 2 weeks ago: https://www.youtube.com/watch?v=e29D1daRYrQ 18:12:54 (for future viewing) 18:15:24 domenic: underspecifying is not the answer, you may describe alternate models instead 18:17:13 alex: when you implement your own control, nothing is for free (accessibility, i18n, everything) 18:17:32 expect that things will be of lower quality than the default 18:18:37 dka: how about having best practice for those aspects? 18:23:49 (discussion about responsive design - the need to send an app that address both desktop and mobile - missing primitive to fix that issue) 18:24:07 cf http://alistapart.com/column/what-we-mean-when-we-say-responsive 18:25:01 domenic: there are different things, changing the window size, or do we change device... 18:26:36 plinss: where the TAG can help... encapsulation and other controversial topics? 18:31:57 Topic: sysapps 18:32:55 Q! 18:33:00 S/Q!// 18:33:08 Zakim has left #tagmem 18:33:23 Zakim has joined #tagmem 18:33:55 dka has joined #tagmem 18:38:25 scribenick: slightlyoff 18:38:42 topic: Sysapps working group 18:38:44 Topic: SysApps Working Group 18:38:57 http://www.w3.org/2012/sysapps/ 18:39:04 work has included packaging formats based on a manifest 18:39:22 tizen and FFOS have used this approach because there's no way to use many of the critical APIs in hosted webapps 18:39:57 wonsuk: we are worried that we don't have links into these packaged apps 18:40:07 wonsuk: we're thinking about how to do better by hosted apps now 18:40:18 http://www.w3.org/2012/sysapps/ 18:40:30 wonsuk: we have a long list of APIs -- bluetooth, task scheduling, etc. 18:40:42 https://github.com/sysapps 18:40:54 wonsuk: we should be basing these APIs on a coherent security mechanism. The packaged apps system had such a mechanism. 18:41:23 wonsuk: we'd like the TAG to help advise about security model and discuss the overall platform evolution about these capabilities 18:41:41 wonsuk: in the short term we can make good progress on task schedule, container messaging, and a few others 18:41:55 wonsuk: but a technical issue is that we need to align many of the APIs with the Service Worker dsign 18:42:07 wonsuk: we need some sort of system event from the underlying system 18:42:32 wonsuk: the SW is trying to support this sort of thing, e.g. the PUsh API and Task Scheduling should align 18:42:59 wonsuk: in general we divide work into 2 phases (1 & 2). Most of the important work is the security and permission model. 18:43:23 wonsuk: if we don't have such a model, it's difficult to deploy these capabilties in the web platform 18:43:48 wonsuk: with the phase1 specs, we're trying to align between the specs and the security model. If we have a good security model, we can make other specs based on that model 18:44:09 wonsuk: we are struggling to come up with a complete security model 18:44:18 http://www.w3.org/2012/sysapps/runtime/ :) 18:45:29 slightlyoff: the TAG is looking at packaging. How does signing relate to your security model and packaging? 18:45:41 wonsuk: FF and Google and Tizen all ahve their own signing systems 18:45:58 wonsuk: we try to honor the approach that doesn't need a signing system 18:46:14 wonsuk: however, a packaging format is similar to issues we're working through 18:46:29 wonsuk: Google uses crz, FF uses zip as does tizen 18:46:50 wycats: is there a specific reason that we specify priviledged APIs needs to be specific to packaged apps? 18:47:15 wycats: I've noted that there are specs which tie priviledge to the trusted computing environment 18:47:43 wycats: the assumption is pervasive in these specs 18:48:06 Eg: http://www.w3.org/TR/2013/WD-telephony-20130620/#security-and-privacy-considerations 18:48:07 wycats: I'm hearing that there's a desire for a tizen-like environment 18:48:22 wycats: and I'd like to break these things out to the normal web 18:49:27 dka: one of the things we've previously talk about at a TAG meeting is the idea that, e.g., the telephony API (which can do a lot of damage), could we enable that in a hosted app if we apply other restrictions to it? 18:49:40 dka: e.g., a negotiation about what the app can and can't do? 18:51:14 slightlyoff: 3 tools on the board: signing, trade-for-capability, and the ability to split out your storage 18:51:35 Domenic: there's some idea that you might always have a request for permission and it's up to the UA to decide how/when to grant it 18:53:50 slightlyoff: there's an important pattern about vending promises from permission-request APIs, it buys you a lot of flexibility 18:54:14 Updated link to the latest editor’s draft of telephony API with slightly more expanded seucrity and privacy consideration section: http://www.w3.org/2012/sysapps/telephony/#security-and-privacy-considerations 18:54:18 slightlyoff: that can give us the ablity to have the API be universally available but not univerisally succeed 18:54:30 wycats: it'd be great if the specs started to be built with web content in mind 18:55:04 junkees: it wasn't intentional for the sysapps WG to go to packaged apps; we were backed into it, but now we're looking at more hosted-apps solutions 18:56:34 wycats: it might be good for these permission to be proposed in the web context and the permission grants to be UA specific 18:56:55 slightlyoff: it seems good for developers if they can build something once and have it run in multiple environments 18:57:23 slightlyoff: does the current packaging/manifest system eanble that? 18:57:37 junkees: the TPAC demo was mostly just that, it didn't define interoperable packaging 18:57:51 junkees: 2 deployed platforms are using different packaging formats 18:59:05 slightlyoff: can you help us understand what the constraints on a packaging format would need to be to be acceptable for the write-once world? 18:59:29 wonsuk: as you know, the widget packaging format is a standard and we can use that for packaged web apps, but the problem is the key management. 19:00:37 wonsuk: as you know, the PKI system that underlies the signing in each store, we need to synchronize them. If I make a Tizen app with the Tizen tools, I need to get a key from the Tizen site and use it for the packaging 19:02:12 slightlyoff: is it possible to sign the same bag of bits in 2 places and have it be hosted on your own web server? 19:02:21 junkees: it isn't a technical problem 19:02:52 junkees: there's already some fragmentation and we're trying to work back to an interoperable situation 19:03:04 junkees: so for v1 we're focusing on a way to enable hosted apps 19:03:08 slightlyoff: that sounds great 19:04:06 (discussion about stores, trust, etc.) 19:04:57 wycats: one argument is that if you give us a bag of bits, we can analyize it. but I think you'll get to the limits of that approach very quickly 19:05:17 timbl: suppose a store where everyone has a legally binding contract. That can provide something better. 19:05:42 wycats: the other argument is trying to understand user intent about wanting to have a relationship with some bit of content 19:06:22 wycats: and I've thought that something like a "keep" UI is a compelling way to think about that trust 19:06:59 wycats: arguments about the need for app stores seem to mostly be subsumed by "keep" UI 19:07:27 timbl: something I've talked about before is a bar that apps need to pass about being "beneficent" 19:07:34 wycats: app stores need to scale 19:07:40 timbl: it'd be a brand of some sort 19:08:11 wycats: revocation is an issue 19:09:55 slightlyoff: you can imagine the UA being smart about revocation on a URL basis, like the safe browsing list 19:10:42 (discussion of app stores) 19:11:39 wycats: I think it's important not to think that we're going to solve major security permissions on the back of appstores and I don't think it's going to scale 19:13:16 wonsuk: I think it's important that we provide most capabilities to most sites. A reputation system might allow us to provide more exotic permissions to certain sites 19:19:27 slightlyoff: (describes Aaron Boodman's model, appification, etc.) 19:23:23 Topic: lunch 19:23:25 (braek) 19:23:27 break 19:24:49 dka has joined #tagmem 19:38:39 dherman has joined #tagmem 19:56:37 tx 20:07:10 ical URL: https://cal.w3ctag.org/public.php/tag/calendar.ics 20:32:53 Topic: Web Magna Carta 20:33:17 timbl: use 25th anniversary of web as a lever to make people more aware of the web 20:33:28 timbl: got together with some ngo's with a "what's the web you want?" message 20:33:36 timbl: got webyouwant.org 20:33:43 timbl: PR campaign, bringing it up at confs where we could 20:33:49 timbl: SxSW, TED, etc 20:33:55 https://webwewant.org/ 20:34:11 Zakim has left #tagmem 20:35:17 timbl: typical response has been: 20:35:28 timbl: first half of year, think about problems 20:35:47 timbl: second half of year, get folks in different jurisdictions to think about how to fix their countries legally 20:35:58 timbl: sort of loose coalition with people throwing in their energy where they're excited about it 20:36:08 timbl: seems like something reasonable for TAG to have input 20:36:22 timbl: good to get developers to talk about the "web you want" 20:36:49 timbl: good to get input on the technical side 20:36:58 timbl: in the past we've talked about political issues like net neutrality, right to link 20:37:06 timbl: produced a document defining things for lawyers 20:38:15 JeniT: particularly thinking about stuff we discussed yesterday around EME, 20:38:21 JeniT: technical principles around platform independence, 20:38:37 JeniT: being open and constrained about what information is being shared by our computers back to others 20:38:42 JeniT: may be something in a blog post or something 20:38:48 dka: brings to mind: 20:38:54 dka: in STRINT workshop I hosted, 20:39:04 dka: about protecting internet against pervasive monitoring 20:39:13 dka: question came up: are standards moral? 20:39:31 dka: somebody did put forward argument that standards are amoral 20:40:44 dka: even at IETF they have moral principals such as "no back doors" 20:40:55 s/principals/principles/ 20:41:45 timbl: when email was designed, nobody took spam into account 20:41:55 timbl: there was an assumption that everyone in the system was benign 20:42:29 timbl: there are implicit assumptions about social constraints in the platform 20:43:18 wycats: DRM is only a politics question 20:44:39 dherman: "politics" is a loaded word, but all of this examples come down when there's some sort of adversarial relationship 20:45:04 timbl: advertisers 20:45:12 dherman: so maybe "conflict of interests" is more general than "adversarial" 20:46:09 dherman: I do believe standards are moral, but feel a little unqualified to state general principles of ethical standards 20:46:21 timbl: the concepts are already out there 20:46:29 dka: we don't need to invent new things 20:47:46 dka: when we mentioned right to link, I kept rattling on about declaration of human rights, 20:47:49 http://www.un.org/en/documents/udhr/ 20:48:01 dka: we could derive idea of right-to-link from freedom of expression 20:48:14 dka: writing a link is expression, it's not embedding a thing, it's talking about a thing 20:48:36 dka: there was a court case in europe relating to human rights, 20:48:42 made this equation of linking to speech 20:48:48 dka: made this equation of linking to speech 20:49:06 dka: all I'm saying is you can come up with technical guidelines that are derived from fairly universal statements about rights 20:49:26 dka: rather than trying to come up with a new set of rights 20:49:37 wycats: if you read HN threads, there's usually an undercurrent of people: 20:50:04 wycats: their position is "we have large monopolies of companies that have right to ship bits to your house, which is a market failure, so that's why we need net neutrality" 20:50:12 wycats: there's zero people who don't think we have a problem 20:50:27 wycats: but the libertarian cohort believes we need net neutrality because of a broken market 20:50:42 timbl: in america, having more than one ISP is probably way down the list 20:50:45 the libertarian cohort would prefer to fix the market 20:51:17 wycats: IOW trying to declare net neutrality as universal is surprisingly divisive 20:51:28 dka: I'm saying we ought to be talking things more web-centric 20:51:36 JeniT: platform independence, for example 20:52:11 timbl: net neturality means not discriminating packets for any reason, even commercial 20:52:45 timbl: when you build a DRM system you've got to have separate markets (dherman didn't quite get this point) 20:52:51 wycats: so this is platform independence? 20:53:13 wycats: broader point is we don't want a thing called "web content" that is tied to a particular platform 20:53:22 timbl: that's between a "rights" statement and "economic" statement 20:53:42 dka: that comes into conflict with regional rights thing 20:53:55 wycats: it's a violation if sergey purchases content in the US and goes home he can't get it 20:54:04 dka: I think we agree it's not ideal 20:54:10 wycats: I think that violates what we call fundamental rights 20:54:15 twirl: we're discussing EME again?? 20:54:18 wycats: geocoding is enough 20:54:23 dka: take BBC for example 20:55:42 wycats: (walked through an example) 20:56:01 dka: fact that you can't pay for it is what created bittorrent etc 20:56:12 dka: there's so much pressure b/c people can't -- even if they wanted to -- pay for it 20:56:20 wycats: people would pay $10/mo for Game of Thrones but they can't get it 20:56:25 dka: there's a biz issue 20:56:28 wycats: not even saying that 20:56:33 wycats: that's outside scope 20:56:47 wycats: but if you're able to pay for it and it's on the web, you should be able to get access to it from any device and location in the world 20:57:04 dka: many rights providers have a different deal 20:57:13 dka: they say I'll license this content for laptops but not tablets 20:57:20 wycats: but we should say the *web* does not work like that 20:57:58 wycats: the web is not amenable to "am I on a tablet?" 20:58:20 https://github.com/w3ctag/eme#principles-for-web-technologies 21:00:04 dherman: are these principles going to bump up against laws we have no control over 21:00:24 timbl: yes, this is what I keep saying about our technical designs connecting to social designs 21:00:36 JeniT: people talk about bittorrent as if it's a criminal thing but it's a protocol 21:00:40 timbl: exactly 21:00:49 timbl: what you need to do is look at what the social expectations are as well 21:01:45 timbl: reasonable to say "all 'green' branded apps written so they won't violate privacy" 21:02:09 timbl: then technical system could be easier by showing up "evil" authors 21:02:21 timbl: works by crowd-sourcing, people branding them 21:03:14 timbl: given a social protocol there are other technical protocols that will work 21:03:30 wycats: if people are using a web browser it should be a generally platform-independent thing, but 21:03:39 wycats: why do people use UA strings? sometimes there's a reason for it 21:03:46 wycats: sometimes there's content that's not platform independent 21:03:54 dka has joined #tagmem 21:03:59 wycats: we will always leak enough information into Turing-complete JS for people to try to figure it out 21:04:46 wycats: independent of hardware, OS, who you got connectivity from, language, country... 21:04:49 oops 21:04:56 timbl: independent of hardware, OS, who you got connectivity from, language, country... 21:05:06 wycats: well we were just talking about exposing "am I on wifi?" 21:05:15 timbl: luckily everything got fast enough to avoid that, 21:05:27 timbl: but! FCC made deal that net neutrality was restricted to land lines 21:05:47 dka: seems to me that it could be useful for platform-independence to explain tension between platform independence and responsive design 21:05:58 dka: a lot of flak we got in early days of mobile on web, 21:06:07 dka: "why do you need special things on a phone? phone is just a small computer?" 21:06:11 wycats: my finger is very big! 21:06:18 dka: "no! that breaks the web!" 21:06:26 dka: now that's come into mainstream, but there's a tension there 21:06:54 wycats: a sad thing about responsive design is, every new browser comes with "request desktop site" but it doesn't work 21:07:02 dherman: why? 21:07:20 wycats: list of things it changes when you press checkbox is UA string and stuff like that 21:07:35 wycats: I think they think you know what you're doing when you do responsive design which hasn't historically been correct 21:07:44 wycats: but anyway I think platform independence isn't a "basic right" 21:08:05 JeniT: there's platform independence of API's and technologies 21:08:23 twirl: there are technical differences 21:08:27 wycats: this is what I'm getting at 21:08:33 twirl: some people try to imply non-technical differences 21:08:57 Domenic: what about fact that airlines show higher prices to mac users? is this related? 21:10:07 wycats: there's technical details like "I can't show geolocation" and contract issues like "I didn't make a biz arrangement to show this content" and to a Hollywood type those are both technical issues 21:10:21 timbl: whole mobile web issue was teach devs how to make stuff work on phone 21:10:26 timbl: that's all the win-win model 21:10:34 wycats: I don't know how to draw the technical line 21:11:02 s/issue/Initiative/ 21:11:41 dherman: let's go from particular to general (inductive method) 21:11:44 dherman: This is about, in gneral, going fromthe particular to the general 21:11:58 dka: then we can see if these fit into this "web we want" initiative 21:12:08 dka: I added a thing about social principles to the principles page 21:12:18 dka: one more thing I wanted to add: empowering user is a big thing with the web 21:12:35 dka: erring on side of asking user for permission rather than assuming authority 21:12:50 wycats: seems like teh incentives aren't there for empowering the user 21:13:04 wycats: users don't make choices based on empowerment, browsers make choices based on what users want 21:13:13 JeniT: we talked about this the other day at dinner 21:13:20 JeniT: constantly asking user for what they want doesn't help 21:13:31 dka: that's only one example of how to go about empowering user 21:13:38 wycats: we've talked about making it better with SSL 21:13:45 wycats: but I don't know how to make browser vendors care about it 21:13:58 wycats: users don't care, and if they do, they already know what padlock means 21:14:14 dka: at strint many people thought padlock in page was more important than padlock in chrome 21:14:18 wycats: totally believe that 21:14:33 wycats: point is difficult to make users value features that help them understand their security 21:14:40 wycats: this has to be done benevolently 21:14:55 JeniT: I think dka is right about the principle, it's just complicated to put into place 21:15:10 wycats: moz has been trying very hard to sell this principle as a feature of their browser and have not succeeded 21:15:39 Domenic: mozilla's "don't go to this insecure page" performs better than chromes 21:15:48 Domenic: fewer users click through 21:16:11 dka: idea of flag day where all browsers would agree that on this day they'd stop allowing users to go to those sites 21:16:17 dherman: prisoner's dilemma... 21:16:30 timbl: I like "this web site sucks, share this on twitter!" 21:17:24 wycats: initially I think we actually are measuring to how close to zero we can get with these pages 21:17:36 dka: I think we're done 21:17:39 dka: with that topic 21:21:37 dom 21:21:41 s/dom// 21:25:30 s/sucks/has an out of date certificate/ 21:27:52 dka has joined #tagmem 21:31:48 Topic: Streams 21:31:54 Domenic: (presents slides, will link later) 21:32:24 http://www.slideshare.net/domenicdenicola/streams-for-the-web-31205146 21:35:25 wycats: there are things you can do with object streams that you've decided aren't important 21:35:28 Domenic: they're less important 21:35:34 wycats: I don't want to lose Node.bind working well 21:35:42 NOOOOOOOOOOOOOOOOOOO 21:44:18 wycats: I don't agree with basically any of this presentation but probably don't have time to work on it 21:44:28 wycats: I do agree with the motivation, but don't agree with any of how you're doing it 21:44:38 JeniT: what's the objection? 21:44:46 wycats: there's another set of things which are streams of objects or events 21:44:51 wycats: different constraints 21:46:04 Domenic: the minority of people who like observables is loud and worth listening to 21:46:10 Domenic: but you can build those on top of these streams 21:46:14 wycats: they want push and not pull 21:46:19 Domenic: you can build push on pull 21:46:24 Domenic: you can build either on top of other 21:46:26 Domenic: it's trivial 21:46:29 Domenic: four lines 21:46:38 wycats: trivial in same way you can convert any callbacky API to a promises API 21:46:42 wycats: and people will do that 21:46:48 wycats: but we have to decide what platform does with MessageChannel 21:46:53 wycats: and if it does this I'll be sad 21:46:57 Domenic: it already does buffering so that's done 21:47:08 wycats: whole point of reactive/observable is small primitive and put together pieces as you need 21:47:11 wycats: want buffering, add buffering 21:47:13 wycats: etc 21:49:12 Yves: would something like piping into an empty stream be all right? 21:49:20 wycats: basically this approach forces you to pull 21:49:37 wycats: it's gonna sound like my argument is niche 21:49:41 wycats: I get that 21:49:51 wycats: it also happens to be how people are writing data-bound templates 21:49:55 wycats: happens to be how polymer's doing it 21:50:12 wycats: I'd like us to have a coherent story for both things 21:50:17 wycats: if Node.bind is gonna take an observable, 21:50:22 wycats: then we should do the legwork 21:50:29 Domenic: I don't see why we can't do that 21:50:33 wycats: we should do the work 21:50:44 Domenic: ok, I await your pull request... 21:50:56 Domenic: I don't see it as clunky 21:51:08 Domenic: in Rx observables you do all the map/filter/etc first, 21:51:16 Domenic: and those don't matter whether it's push or pull 21:51:26 wycats: I think that's true in the same sense that promises are isomorphic to callbacks 21:51:30 wycats: you could write an adapter 21:51:38 wycats: doesn't necessarily mean primitives should always be one or the other 21:51:53 wycats: this is like Node stream-ism, over-using a primitive for the wrong things 21:52:02 Domenic: seems fair, but obvious use cases will be addressed first 21:52:18 wycats: we're splitting the baby in half 21:52:23 Domenic: one half of the baby is doing all the work! 21:52:27 wycats: tell me how I can help 21:52:38 Domenic: work on an observables spec that makes a lot of sense for Rx and those use cases 21:52:41 wycats: specifically Node.bind 21:52:58 dherman: why not use ebryn for this? 21:53:10 http://www.polymer-project.org/docs/polymer/node_bind.html 21:53:30 Domenic: I think you need to do a very good job addressing why it's hard/awkward to use these streams for your use cases 21:53:37 wycats: not any harder than denodeify 21:53:41 Domenic: you need to draw out that analogy 21:53:45 Domenic: show it concretely 21:53:49 wycats: ok, I'm happy to do that 22:03:10 wycats: I think the difference between this and Rx is that Rx is trying not to be imperative and this is very imperative 22:03:52 Domenic: it's a low-level primitive 22:06:46 annevk: could we envision syntax being built on things like observables or streams? by analogy to async/await for promises 22:06:52 wycats: for* for observables 22:07:27 Domenic: historical object stream position has been "we'll just add buffering" 22:07:30 wycats: that's a dumb position 22:07:36 wycats: that's not what they should be saying 22:07:40 Domenic: not sure how it's possible with push 22:07:43 wycats: you need unsubscribe 22:08:15 dka has joined #tagmem 22:09:59 Domenic: pipe is a nice primitive that connects to the OS 22:10:32 wycats: problem with composable primitives is the composed pieces don't know they were talking to an OS socket 22:15:55 Domenic: with pipe you can tell eg the XHR is connected to a