<trackbot> Date: 03 April 2014
<scribe> Scribe: Yves
<timbl> dka, http://www.huffingtonpost.co.uk/2014/04/02/saharan-dust-smog-london_n_5075994.html
https://github.com/w3ctag/spec-reviews/blob/master/2014/02/quota-management-api.md
https://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html - 2014-02-04 version
scribe: temporary vs persistent storage underspecified
<Domenic> http://www.w3.org/TR/file-system-api/
<Domenic> http://w3c.github.io/filesystem-api/Overview.html
(discussion about different File APIs)
(going through the review)
got good response from the editor
Domenic: few comments about javascript issues (more nitpicking than strong comments)
wycats: the time issue depends on the precision you mean, you may need ms, or even something with a higher precision
(discussion about number size)
anne: we need to check what should be cleaned in webidl
wycats: I don't really believe in Object.freeze() (re: supported types)
domenic: perhaps we need another kind of array
anne: the main reason to have something readonly is when you have multiple consumer
dave: I don't see the use of freeze here really motivated
<annevk> Domenic: maybe project https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682
dka: sounds like more a JS feedback that feedback on quota API
domenic: I may remove the 'freeze' comment as there is no real consensus
<slightlyoff> hey all
<slightlyoff> Dimitri and I will be there sometime after 10:15...apologies for the delay
<slightlyoff> Dimitry, even
<slightlyoff> ooof...looking like 10:25.
<dka> Also note that Wonsuk and Jungkee will join us at 11:00.
<wycats> twirl: you're in the US now ;)
<wycats> hahaha
<slightlyoff> Here
<dka> Yes!
<dka> +Wonsuk Lee, Jungkee Song, Dimitri Glazkof
<dka> Presetnt+ Wonsuk Lee, Jungkee Song, Dimitri Glazkof
Dimitri introducing Web components
DG: shadow dom, imports, templates... decorators (this one postponed)
goal was to make as little change as possible
like templates that "only" change the HTML parser
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
<slightlyoff> ...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
<slightlyoff> the world with @@create will help, but we don't have it yet
<slightlyoff> and a self-hosted world would also be better
<slightlyoff> but we don't have that either
DG: shadow DOM is a trouble maker, some trade-off were needed, like for rendering
need to expose more hooks
<slightlyoff> who is scribe?
alex: there is some tension about the possibility of creating new elements (fragmentation, etc...)
dg: inventing your own HTML tags is a useful thing, doing 'div class' everywhere is also bad
see alex's blog post
<slightlyoff> yes, that one
http://infrequently.org/2013/11/long-term-web-semantics/
OH: "XML is not that bad in term of expressiveness"
[scribe protecting wycat's anonymity]
(was discussion about dwelling into microsyntax)
domenic: there is encapsulation issue, like chrome's video tag implemented using shadow dom, but not really like other shadow dom things
also what are the hooks that the shadow dom can't access, wycats raised the preload-scanner issue
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
anne: the fact that form control was not completely described helped implementing them in a different way for different platforms
<dka> FYI I moderated a panel on web components at Edgeconf 3 2 weeks ago: https://www.youtube.com/watch?v=e29D1daRYrQ
<dka> (for future viewing)
domenic: underspecifying is not the answer, you may describe alternate models instead
alex: when you implement your own control, nothing is for free (accessibility, i18n, everything)
expect that things will be of lower quality than the default
dka: how about having best practice for those aspects?
(discussion about responsive design - the need to send an app that address both desktop and mobile - missing primitive to fix that issue)
<dka> cf http://alistapart.com/column/what-we-mean-when-we-say-responsive
domenic: there are different things, changing the window size, or do we change device...
plinss: where the TAG can help... encapsulation and other controversial topics?
<dka> http://www.w3.org/2012/sysapps/
work has included packaging formats based on a manifest
tizen and FFOS have used this approach because there's no way to use many of the critical APIs in hosted webapps
wonsuk: we are worried that we don't have links into these packaged apps
... we're thinking about how to do better by hosted apps now
<Domenic> http://www.w3.org/2012/sysapps/
wonsuk: we have a long list of APIs -- bluetooth, task scheduling, etc.
<Domenic> https://github.com/sysapps
wonsuk: we should be basing these APIs on a coherent security mechanism. The packaged apps system had such a mechanism.
... we'd like the TAG to help advise about security model and discuss the overall platform evolution about these capabilities
... in the short term we can make good progress on task schedule, container messaging, and a few others
... but a technical issue is that we need to align many of the APIs with the Service Worker dsign
... we need some sort of system event from the underlying system
... the SW is trying to support this sort of thing, e.g. the PUsh API and Task Scheduling should align
... in general we divide work into 2 phases (1 & 2). Most of the important work is the security and permission model.
... if we don't have such a model, it's difficult to deploy these capabilties in the web platform
... 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
... we are struggling to come up with a complete security model
<Domenic> http://www.w3.org/2012/sysapps/runtime/ :)
slightlyoff: the TAG is looking at packaging. How does signing relate to your security model and packaging?
wonsuk: FF and Google and Tizen all ahve their own signing systems
... we try to honor the approach that doesn't need a signing system
... however, a packaging format is similar to issues we're working through
... Google uses crz, FF uses zip as does tizen
wycats: is there a specific reason that we specify priviledged APIs needs to be specific to packaged apps?
... I've noted that there are specs which tie priviledge to the trusted computing environment
... the assumption is pervasive in these specs
<dka> Eg: http://www.w3.org/TR/2013/WD-telephony-20130620/#security-and-privacy-considerations
wycats: I'm hearing that there's a desire for a tizen-like environment
... and I'd like to break these things out to the normal web
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?
... e.g., a negotiation about what the app can and can't do?
slightlyoff: 3 tools on the board: signing, trade-for-capability, and the ability to split out your storage
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
slightlyoff: there's an important pattern about vending promises from permission-request APIs, it buys you a lot of flexibility
<dka> 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
slightlyoff: that can give us the ablity to have the API be universally available but not univerisally succeed
wycats: it'd be great if the specs started to be built with web content in mind
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
wycats: it might be good for these permission to be proposed in the web context and the permission grants to be UA specific
slightlyoff: it seems good for developers if they can build something once and have it run in multiple environments
... does the current packaging/manifest system eanble that?
junkees: the TPAC demo was mostly just that, it didn't define interoperable packaging
... 2 deployed platforms are using different packaging formats
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?
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.
... 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
slightlyoff: is it possible to sign the same bag of bits in 2 places and have it be hosted on your own web server?
junkees: it isn't a technical problem
... there's already some fragmentation and we're trying to work back to an interoperable situation
... so for v1 we're focusing on a way to enable hosted apps
slightlyoff: that sounds great
(discussion about stores, trust, etc.)
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
timbl: suppose a store where everyone has a legally binding contract. That can provide something better.
wycats: the other argument is trying to understand user intent about wanting to have a relationship with some bit of content
... and I've thought that something like a "keep" UI is a compelling way to think about that trust
... arguments about the need for app stores seem to mostly be subsumed by "keep" UI
timbl: something I've talked about before is a bar that apps need to pass about being "beneficent"
wycats: app stores need to scale
timbl: it'd be a brand of some sort
wycats: revocation is an issue
slightlyoff: you can imagine the UA being smart about revocation on a URL basis, like the safe browsing list
(discussion of app stores)
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
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
slightlyoff: (describes Aaron Boodman's model, appification, etc.)
[lunch break]
<dka> Scribenick: dherman
timbl: use 25th anniversary of web as a lever to make people more aware of the web
... got together with some ngo's with a "what's the web you want?" message
... got webyouwant.org
... PR campaign, bringing it up at confs where we could
... SxSW, TED, etc
<JeniT> https://webwewant.org/
timbl: typical response has been:
... first half of year, think about problems
... second half of year, get folks in different jurisdictions to think about how to fix their countries legally
... sort of loose coalition with people throwing in their energy where they're excited about it
... seems like something reasonable for TAG to have input
... good to get developers to talk about the "web you want"
... good to get input on the technical side
... in the past we've talked about political issues like net neutrality, right to link
... produced a document defining things for lawyers
JeniT: particularly thinking about stuff we discussed yesterday around EME,
... technical principles around platform independence,
... being open and constrained about what information is being shared by our computers back to others
... may be something in a blog post or something
dka: brings to mind:
... in STRINT workshop I hosted,
... about protecting internet against pervasive monitoring
... question came up: are standards moral?
... somebody did put forward argument that standards are amoral
... even at IETF they have moral principles such as "no back doors"
timbl: when email was designed, nobody took spam into account
... there was an assumption that everyone in the system was benign
... there are implicit assumptions about social constraints in the platform
wycats: DRM is only a politics question
dherman: "politics" is a loaded word, but all of this examples come down when there's some sort of adversarial relationship
timbl: advertisers
dherman: so maybe "conflict of interests" is more general than "adversarial"
... I do believe standards are moral, but feel a little unqualified to state general principles of ethical standards
timbl: the concepts are already out there
dka: we don't need to invent new things
... when we mentioned right to link, I kept rattling on about declaration of human rights,
<dka> http://www.un.org/en/documents/udhr/
dka: we could derive idea of right-to-link from freedom of expression
... writing a link is expression, it's not embedding a thing, it's talking about a thing
... there was a court case in europe relating to human rights,
made this equation of linking to speech
dka: made this equation of linking to speech
... all I'm saying is you can come up with technical guidelines that are derived from fairly universal statements about rights
... rather than trying to come up with a new set of rights
wycats: if you read HN threads, there's usually an undercurrent of people:
... 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"
... there's zero people who don't think we have a problem
... but the libertarian cohort believes we need net neutrality because of a broken market
timbl: in america, having more than one ISP is probably way down the list
<wycats> the libertarian cohort would prefer to fix the market
wycats: IOW trying to declare net neutrality as universal is surprisingly divisive
dka: I'm saying we ought to be talking things more web-centric
JeniT: platform independence, for example
timbl: net neturality means not discriminating packets for any reason, even commercial
... when you build a DRM system you've got to have separate markets (dherman didn't quite get this point)
wycats: so this is platform independence?
... broader point is we don't want a thing called "web content" that is tied to a particular platform
timbl: that's between a "rights" statement and "economic" statement
dka: that comes into conflict with regional rights thing
wycats: it's a violation if sergey purchases content in the US and goes home he can't get it
dka: I think we agree it's not ideal
wycats: I think that violates what we call fundamental rights
twirl: we're discussing EME again??
wycats: geocoding is enough
dka: take BBC for example
wycats: (walked through an example)
dka: fact that you can't pay for it is what created bittorrent etc
... there's so much pressure b/c people can't -- even if they wanted to -- pay for it
wycats: people would pay $10/mo for Game of Thrones but they can't get it
dka: there's a biz issue
wycats: not even saying that
... that's outside scope
... 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
dka: many rights providers have a different deal
... they say I'll license this content for laptops but not tablets
wycats: but we should say the *web* does not work like that
... the web is not amenable to "am I on a tablet?"
<JeniT> https://github.com/w3ctag/eme#principles-for-web-technologies
dherman: are these principles going to bump up against laws we have no control over
timbl: yes, this is what I keep saying about our technical designs connecting to social designs
JeniT: people talk about bittorrent as if it's a criminal thing but it's a protocol
timbl: exactly
... what you need to do is look at what the social expectations are as well
... reasonable to say "all 'green' branded apps written so they won't violate privacy"
... then technical system could be easier by showing up "evil" authors
... works by crowd-sourcing, people branding them
... given a social protocol there are other technical protocols that will work
wycats: if people are using a web browser it should be a generally platform-independent thing, but
... why do people use UA strings? sometimes there's a reason for it
... sometimes there's content that's not platform independent
... we will always leak enough information into Turing-complete JS for people to try to figure it out
... independent of hardware, OS, who you got connectivity from, language, country...
oops
timbl: independent of hardware, OS, who you got connectivity from, language, country...
wycats: well we were just talking about exposing "am I on wifi?"
timbl: luckily everything got fast enough to avoid that,
... but! FCC made deal that net neutrality was restricted to land lines
dka: seems to me that it could be useful for platform-independence to explain tension between platform independence and responsive design
... a lot of flak we got in early days of mobile on web,
... "why do you need special things on a phone? phone is just a small computer?"
wycats: my finger is very big!
dka: "no! that breaks the web!"
... now that's come into mainstream, but there's a tension there
wycats: a sad thing about responsive design is, every new browser comes with "request desktop site" but it doesn't work
dherman: why?
wycats: list of things it changes when you press checkbox is UA string and stuff like that
... I think they think you know what you're doing when you do responsive design which hasn't historically been correct
... but anyway I think platform independence isn't a "basic right"
JeniT: there's platform independence of API's and technologies
twirl: there are technical differences
wycats: this is what I'm getting at
twirl: some people try to imply non-technical differences
Domenic: what about fact that airlines show higher prices to mac users? is this related?
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
timbl: whole mobile web Initiative was teach devs how to make stuff work on phone
... that's all the win-win model
wycats: I don't know how to draw the technical line
dherman: let's go from particular to general (inductive method)
<timbl> dherman: This is about, in gneral, going fromthe particular to the general
dka: then we can see if these fit into this "web we want" initiative
... I added a thing about social principles to the principles page
... one more thing I wanted to add: empowering user is a big thing with the web
... erring on side of asking user for permission rather than assuming authority
wycats: seems like teh incentives aren't there for empowering the user
... users don't make choices based on empowerment, browsers make choices based on what users want
JeniT: we talked about this the other day at dinner
... constantly asking user for what they want doesn't help
dka: that's only one example of how to go about empowering user
wycats: we've talked about making it better with SSL
... but I don't know how to make browser vendors care about it
... users don't care, and if they do, they already know what padlock means
dka: at strint many people thought padlock in page was more important than padlock in chrome
wycats: totally believe that
... point is difficult to make users value features that help them understand their security
... this has to be done benevolently
JeniT: I think dka is right about the principle, it's just complicated to put into place
wycats: moz has been trying very hard to sell this principle as a feature of their browser and have not succeeded
Domenic: mozilla's "don't go to this insecure page" performs better than chromes
... fewer users click through
dka: idea of flag day where all browsers would agree that on this day they'd stop allowing users to go to those sites
dherman: prisoner's dilemma...
timbl: I like "this web site has an out of date certificate, share this on twitter!"
wycats: initially I think we actually are measuring to how close to zero we can get with these pages
dka: I think we're done
... with that topic
Domenic: (presents slides, will link later)
<JeniT> http://www.slideshare.net/domenicdenicola/streams-for-the-web-31205146
wycats: there are things you can do with object streams that you've decided aren't important
Domenic: they're less important
wycats: I don't want to lose Node.bind working well
<wycats> NOOOOOOOOOOOOOOOOOOO
wycats: I don't agree with basically any of this presentation but probably don't have time to work on it
... I do agree with the motivation, but don't agree with any of how you're doing it
JeniT: what's the objection?
wycats: there's another set of things which are streams of objects or events
... different constraints
Domenic: the minority of people who like observables is loud and worth listening to
... but you can build those on top of these streams
wycats: they want push and not pull
Domenic: you can build push on pull
... you can build either on top of other
... it's trivial
... four lines
wycats: trivial in same way you can convert any callbacky API to a promises API
... and people will do that
... but we have to decide what platform does with MessageChannel
... and if it does this I'll be sad
Domenic: it already does buffering so that's done
wycats: whole point of reactive/observable is small primitive and put together pieces as you need
... want buffering, add buffering
... etc
Yves: would something like piping into an empty stream be all right?
wycats: basically this approach forces you to pull
... it's gonna sound like my argument is niche
... I get that
... it also happens to be how people are writing data-bound templates
... happens to be how polymer's doing it
... I'd like us to have a coherent story for both things
... if Node.bind is gonna take an observable,
... then we should do the legwork
Domenic: I don't see why we can't do that
wycats: we should do the work
Domenic: ok, I await your pull request...
... I don't see it as clunky
... in Rx observables you do all the map/filter/etc first,
... and those don't matter whether it's push or pull
wycats: I think that's true in the same sense that promises are isomorphic to callbacks
... you could write an adapter
... doesn't necessarily mean primitives should always be one or the other
... this is like Node stream-ism, over-using a primitive for the wrong things
Domenic: seems fair, but obvious use cases will be addressed first
wycats: we're splitting the baby in half
Domenic: one half of the baby is doing all the work!
wycats: tell me how I can help
Domenic: work on an observables spec that makes a lot of sense for Rx and those use cases
wycats: specifically Node.bind
dherman: why not use ebryn for this?
<JeniT> http://www.polymer-project.org/docs/polymer/node_bind.html
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
wycats: not any harder than denodeify
Domenic: you need to draw out that analogy
... show it concretely
wycats: ok, I'm happy to do that
... I think the difference between this and Rx is that Rx is trying not to be imperative and this is very imperative
Domenic: it's a low-level primitive
annevk: could we envision syntax being built on things like observables or streams? by analogy to async/await for promises
wycats: for* for observables
Domenic: historical object stream position has been "we'll just add buffering"
wycats: that's a dumb position
... that's not what they should be saying
Domenic: not sure how it's possible with push
wycats: you need unsubscribe
Domenic: pipe is a nice primitive that connects to the OS
wycats: problem with composable primitives is the composed pieces don't know they were talking to an OS socket
Domenic: with pipe you can tell eg the XHR is connected to a <video> tag
<wycats> I suspect there is a simple and clear solution that we will arrive at eventually ;)
<JeniT> http://dev.w3.org/2006/webapi/FileAPI/#dfn-createObjectURL
<JeniT> http://dev.w3.org/2006/webapi/FileAPI/#DefinitionOfScheme
<JeniT> hmm, http://fetch.spec.whatwg.org/#concept-basic-fetch doesn't define how to fetch a blob url
<Domenic> annevk ^
<annevk> JeniT: yeah, there's an open bug somewhere
<annevk> JeniT: still waiting for someone to define how to read a blob...
<annevk> JeniT: specs are sad
<JeniT> :)
<Domenic> http://gigaom.com/2013/01/17/microsoft-cu-webrtc-prototype/
<annevk> https://github.com/openpeer/ortc/blob/master/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-02.md
<annevk> https://github.com/openpeer/ortc
<Domenic> "Introduction {#problems}"
<Domenic> dherman: we should talk about ES6 module integration!
<Domenic> Wait, we already did that on day 1
<Domenic> annevk you must have missed it
<annevk> Domenic: was it high-level or in detail?
<dka> Just to note - there is disagreement on the point of whether HDCP is effective or ineffective…
<dka> Also - interesting point from Sergey on the poossibility of some party making pieces of hardware potentially obsolete through certificate revocation…
<dka> side note: DRM can have the impact of making purchased content obsolete / unplayable when the systems that can process the DRM (or DRM system) become inoperable. E.g. (the original) divx system.
slightlyoff: (presenting SW)
... current controversies over cache API