See also: IRC
<JeniT> Scribe: Jeni Tennison
<JeniT> ScribeNick: JeniT
mnot: we're 80% done on drafts for HTTP 2.0
<scribe> ... done by end of year
UNKNOWN_SPEAKER: currently discussion dominated by security issues
dka: we discussed notion of trusted proxy
mnot: still really early days, we'll talk about it in Zurich
dka: what would be useful from us at this point in the process?
mnot: HTTP 2.0 is a mechanical replacement for HTTP, avoids big issues
slightlyoff: is that hard because the people who own the networks think they own the networks?
mnot: yes, some network vendors are reacting to TLS by doing TLS man in the middle
ht: the larger question that I'm concerned about is that the framing narrative for HTTP is out of date
<slightlyoff> mnot: do we think that, in the main, those sorts of things can be prevented? E.g., if someone owns the network today, won't they simply lock out devices they don't authenticate (and usually own at a deeper level)?
ht: as you said, doing that requires us to think again about what the overall architecture is
mnot: HTTP & web arch as defined is open ended about what proxies can do
<slightlyoff> we are responsible for the predictable consequences of our actions. Do we have data?
mnot: browser vendors have security folks & UI folks with very deep knowledge & understanding for why browsers do what they do
<slightlyoff> with the implication that it's not happening in public now?
timbl: in the old days when proxy behaviour was defined, the protocol guaranteed invariants
ht: that intersects with DNS space, it intercepts DNS lookups
timbl: yes, so two questions: can we specify proxy invariants? and what are we doing about captive portals?
mnot: we're starting to talk about clients talking to the network directly
timbl: no, because that just makes you accept bad certificates
ht: just to put a marker down: yes, we should be having discussion across W3C/IETF/browser constellation, before standards phase is completely baked
mnot: we've had discussions within IETF, but we don't have the impetus
slightlyoff: whenever we have these discussions, the captive portal and the TLS proxy come up
<ht> Ownership is also at the heart of the [the problem that dare not speak its name] discussion . . .
slightlyoff: if someone owns a device, they can do what they like
<mnot> FYI: https://github.com/http2/http2-spec/wiki/Proxy-User-Stories
slightlyoff: we think that organisations own networks, people own devices, but that's false
timbl: I think we also have to imagine worlds that are different
mnot: eg BYOD, my employer tells me to install certificates, and they can man-in-the-middle all my traffic
dka: maybe that will happen through who upgrades to HTTP 2.0?
mnot: I think it's separable, it's about how the web uses PKI & TLS
plinss: what are our next steps here?
dka: any other IETF stuff to talk about?
slightlyoff: what about JSON?
mnot: there are no objections currently
slightlyoff: there was a lot of discussion between IETF & ECMA about technical issues and social issues
<mnot> you dropped
ht: there was a point where things were looking up, there was discussion about what kind of reference might be appropriate
slightlyoff: the lack of browser involvement in IETF is problematic, particularly if the ECMA documents start changing
<slightlyoff> (thanks for scribing, JeniT!)
dka: is there still opportunity to make an objection?
mnot: only area directors can make objections
timbl: who's the area director?
mnot: Pete Resnik
timbl: the TAG could talk to him
[some objections to going nuclear]
timbl: this is relevant to liaison between standards bodies, to NIH
mnot: it's really out of Pete's hands right now, it's very late in the process
dka: we could write a blog post about this
mnot: what about the London meeting?
annevk & ht aren't available
dka will be there
mnot: if anyone wants to come along, we can arrange help
dka: are there any recommendations for us for London, are there key items or decisions where we should weigh in?
mnot: the agenda should be out soon, we can flag things at that point
plinss: looping back on captive portal issue
mnot: it's surprisingly complex; we can talk about it, starting to describe the problem space would be useful
timbl: why Wifi?
mnot: because they run them
timbl: isn't it DHCP?
mnot: it touches a lot of places in the stack, which is why it's not easy
timbl: it's a broken level breaking situation
mnot: I think it's the security issue because DHCP is inherently untrustworthy
dka: would a joint task force be useful? couple of people from TAG, couple of people from HTTPbis to start working on such a document, to define the problem space?
mnot: I can ask in Zurich if anyone's interested, we can ask around browser/OS vendors too
timbl: I'm surprised you're not oozing motivation to fix this
mnot: we standardised one a year & a half ago, but we don't have the contacts with the implementers
dka: I can imagine holding a workshop with enough of the right people there
<dom> The Network Authentication Required HTTP Status Code
timbl: if you have pointers, that would be useful
<dom> 428 Network Authentication Required
<mnot> http://tools.ietf.org/search/rfc6585#section-6
mnot: the only other thing is we're meeting in Zurich, if any of you want to come along, we can arrange that
<dom> 511 Network Authentication Required
mnot: that's 22-24 January
<mnot> http://http2.github.io
<dom> http://www.w3.org/2014/Talks/dhm-tag-permissions/
<slightlyoff> details of our captive portal detection system: http://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection
dom: this is a bit of a repeat of a presentation from 2 years ago
[slide 2]
dom: I care about people choosing web over native
[slide 4]
dom: when you use an API to access a hardware feature, you create a new risk for the user
[slide 9]
dom: to protect the user, we've created some mitigations when web apps need to access something
[slide 10]
dom: there's been a preference to avoid prompts, particularly modal prompts
[slide 11]
dom: we have a sandboxed model
dka: eg "your location is being used" gives an icon on the top of the screen
[slide 12]
http://dontcallmedom.github.io/web-permissions-req/matrix.html
dom: this is a review of specs that require consent
ht: we should discuss how to get more eyes on this
dom: we should have a better way of getting a picture on this
<Zakim> timbl, you wanted to discuss the media type registration and to point ask whether the app can explain what will be done with the access, e.g. send a tweet the user has aced to
JeniT: is persistence defined in the specs?
<Zakim> timbl2, you wanted to talk about beneficent apps
dom: sometimes it's just obvious, but we don't have a structured way of thinking about it
timbl: a lot of this matrix assumes you understand what someone is going to use the data for
dom: one area of activity is about blessed applications
slightlyoff: in Boston I outlined some work that I've been doing arising from Chrome App Store & with Android
dom: I've started to create a set of screenshots
<dom> https://github.com/dontcallmedom/web-permissions-req
dom: follow-up work would be to look at other browsers and mobile devices
annevk: otherwise a malicious ad could take over the window
timbl: then you could fake something
dom: that's always an issue, and why the UA display the warning
annevk: it's good for eg YouTube in an iframe might want to go fullscreen
dom: mostly you can ask for the permission
annevk: even cross-origin?
dom: yes
<slightlyoff> sorry...wasn't getting updates via irccloud
<slightlyoff> what'd I miss?
dom: I didn't cover everything, there's Crypto
annevk: Push notifications
<slightlyoff> the model I'm suggesting is something like:
<slightlyoff> navigator.requestAlarmPermission("reason").then(
<slightlyoff> function(alarms) {
<slightlyoff> var a = new alarms.Alarm({ period: 30 });
<slightlyoff> alarms.set("name", a);
dom: Application cache has a prompt in Firefox
<slightlyoff> }, onDenied); // Everything can fail
<slightlyoff> (on one line this time)
dom: network service discovery might be another one
<slightlyoff> navigator.requestAlarmPermission("reason").then( function(alarms) { var a = new alarms.Alarm({ period: 30 }); alarms.set("name", a); }, onDenied); // Everything can fail
annevk: is that something we're exposing to web content?
<slightlyoff> annevk: I think we need to stop thinking in those terms
<slightlyoff> annevk: the question is more like "will that permission something you'd ever be able to successfully get without an install?"
dom: there are others where there aren't permissions, eg for the accelerometer, though you can detect keyboard through that
<annevk> slightlyoff: I don't know what an install is
<slightlyoff> annevk: FFOS has one of these steps = )
<slightlyoff> annevk: and you were there in boston when I outlined a system that would enable that
<annevk> slightlyoff: Firefox OS apps are not web
<slightlyoff> annevk: not sure why the pedantry....
<annevk> I'm not sure we can ever meaningfully teach people a difference between "bookmark" and "install"
<slightlyoff> would it be useful for us to talk about a combined permission API?
<dom> http://dontcallmedom.github.io/web-permissions-req/tests/all.html
dka: slightlyoff, do you have more input here?
slightlyoff: I'm continuing to work at this
annevk: we used to have it, no one wanted it
dom: it got dropped
slightlyoff: often you can't describe what you want to use the permission for
timbl: do you mean in code or in English? you can't enforce it?
slightlyoff: there are some things that we can detect and shut off
timbl: the analogy is with the car, which stops you doing a few things eg suddenly going into reverse, but can't stop you driving on the sidewalk
slightlyoff: coordinating these APIs is something the TAG should have an opinion about
dom: there's a long term problem about making permissions not suck
[demonstration of asking for all permissions]
[dka's laptop is bricked]
http://dontcallmedom.github.io/web-permissions-req/tests/all.html
dom: with the Firefox UI, you can't do a screenshot, if you click away from it the prompts disappear
[slide 13]
dom: on desktop, it's a free-for-all, once installed apps have access to everything (or gated by admins)
dka: on Mac when an app accesses the location, you are prompted by the OS & you get an indicator in the menu bar
dom: on mobile it's sandboxed, this is reasonably successful for developers, users less so
JeniT: and you just click yes, like you do for cookies
[slide 14]
dom: SysApps WGs have been exploring a model for getting access to permissions via a trust model
<annevk> I filed https://bugzilla.mozilla.org/show_bug.cgi?id=957558 based on that page
dom: not sure if they can get consensus in the group about all the systems operating with the same permissions model
annevk: those systems are clones of iOS & Android, not interesting for the web
dom: well, that's a question in the SysApps WG
annevk: I gathered they were shifting to working to things that can be exposed on the web
dom: I've been there before on DAP
annevk: the problem with packaged app is that you're designing a new ecosystem next to the web
ht: there's a bunch of stuff you get that you don't want, eg access to the file system, but why do you think that's broken?
annevk: I think the main reason they use packaged apps is to get offline to work
<dom> [I think I've heard signature as more important than offline for packaged apps]
annevk: and instead of a decentralised model of distribution you have a centralised model that isn't portable across systems
dom: I've heard that the reason packaging is important so that you can sign the app
slightlyoff: the issue is with static analysis
annevk: eg at Mozilla we want to be in charge with all the bits in a packaged app, for a trust model
dom: you could require Mozilla signing hosted apps before it's installable on Firefox OS
timbl: you don't have to zip things up to sign them, and you can refer to them through git hashes
annevk: you could have a model where you say you trust certain domains, and the domains get the permissions
timbl: Gmail isn't an email client
annevk: you can imagine that happening
timbl: a trusted app has access to my file system, knows how to send messages out in my name
slightlyoff: how do we achieve this while still having URLs, a unified model that makes sense to web developers & users
<Zakim> dka, you wanted to suggest we partition the discussion into ordinary permissions and exotic permissions
dka: I agree, we're talking about two different kinds of permissions
timbl: when you use a banking website, you go through additional permissions when you need to make a transfer from when you're checking your balance
annevk: I think we want a model where your IMAP client is imap.com rather than some binary blob
timbl: imap.com can be spoofed or DNS hacked
dom: there are short-term issues and much bigger questions, to look at gaps
<dom> http://www.w3.org/wiki/Mobile/articles#API_Permissions
ht: do we have contacts in the HCI community?
dom: the link is a starting point that summarises research
plinss: what's the role of the TAG here?
<dom> http://www.w3.org/2014/Talks/dhm-tag-permissions/#%2817%29
plinss: there's UI issues, models of how we validate permissions, how can we bring benefits to the table?
dom: you've taken a role in reviewing APIs, you should include in that review thought about permissions
annevk: we shouldn't be looking at UI
plinss: yes, we should be looking at the APIs, create a cleaner permissions model
annevk: you want to figure out the UI then figure out what API suits that
dom: I want the TAG to own the problem rather than provide the solution
annevk: none of us are UI people
dom: this is a technical architectural problem, you should pull in the people you need to address it
timbl: a lot of people here know bad UI where they see it
dom: the UI is the last piece of the puzzle, the question is how you model permissions for the user
timbl: it has to be grounded in the UI
dom: the TAG should pull in experts from the HCI field
slightlyoff: our role is to coordinate, we can coordinate coherent API within the web platform
dka: there's a grey area
slightlyoff: we need to enable UI
dka: whether or not something is intended to be modal or async informs UI
plinss: sync API dictates UI
slightlyoff: we can work on the APIs to make them coherent
plinss: we can do things like enforcing async when asking for permission
dom: the async model is fairly well accepted
plinss: we don't have to design the ultimate UI, but we can think of the implications of API on the UI
dom: my point is that people have done research on this, you should talk to them
slightlyoff: that's a meaningful & useful thing for us to do, yes
dom: if there's some research that's needed, the Mobile Interest Group is willing to help
plinss: what specific actions should we take to move this forward?
slightlyoff: we can look at specifics of the APIs in question
annevk: there might not be a common pattern
slightlyoff: that will come out of the analysis
annevk: I think that's been done
dka: we could start with what Dom's done to help understand what's out there in the wild
<annevk> E.g. http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html and associated emails
dom: that table might not be accurate & it's not exhaustive, some APIs are undergoing development
annevk: the page gets controlled over which camera you use?
dom: no, you have to ask for access to the other cameras, but you get told which are available
annevk: fingerprinting is really easy
dom: there's a difference between active & passive fingerprinting, and between detecting & preventing fingerprinting
<dom> http://w3c.github.io/fingerprinting-guidance/
annevk: who says fingerprinting is not a lost cause?
dom: the Privacy Interest Group
timbl: meanwhile in Europe, there are laws about data protection
<slightlyoff> dom: I'm not hopeful about this document. I can think of productive things to do (an <ad> tag, e.g.)
timbl: eg they say that cookies are a problem
<slightlyoff> dom: but the language here isn't useful
timbl: how should that be rephrased
annevk: the EU law about cookies is dreadful
slightlyoff: websites should only do things that you expect them to
timbl: we should avoid having a technical solution that's perverse because it's trying to achieve a mismatched social goal
annevk: I once when to the Privacy Interest Group, they were more on the policy side than the technical side
slightlyoff: can we engage with them effectively?
dom: if there was a one-line TAG finding that said fingerprinting was a lost cause, that would be helpful
slightlyoff: we shouldn't conflate current state with our agenda
dom: the question WGs are asking is whether it's something they need to take into account in their API design or not
slightlyoff: it would help to analyse the sets of scenarios people are worried about
timbl: there are different ones: the person in the street is worried about being tracked by ad companies
plinss: we've already taken a position on privacy in API design
annevk: there's a difference between fingerprinting and some of the APIs, which is more about tracking across sessions
slightlyoff: we should analyse who's doing what & in what context
timbl: who'd be responsible for doing that? the publisher?
slightlyoff: yes
plinss: a wrapper around content that you don't have control over
timbl: that would be nice
plinss: trying to tie this up into something going forward
slightlyoff: we should build on Dom's work with examples, figure out a unification
plinss: who'll pick that up?
slightlyoff: it should probably be me, let's say that
<dom> https://github.com/dontcallmedom/web-permissions-req/tree/gh-pages/tests
<dom> ACTION: alex to start documenting web permission patterns with code examples
<trackbot> Created ACTION-849 - Start documenting web permission patterns with code examples [on Alex Russell - due 2014-01-15].
<dom> ACTION: DKA to send mail to chairs to ask about APIs using permissions
<trackbot> Created ACTION-850 - Send mail to chairs to ask about apis using permissions [on Daniel Appelquist - due 2014-01-15].
<twirl> https://joindiaspora.com/posts/1653418
<bkardell> twirl: 500 error on link?
slightlyoff: Service Workers are an in-browser proxy that handle fetches
[example content of a service worker]
slightlyoff: use importScripts() to install dependencies (eventually installed through modules)
dka: does the service worker wake up & do stuff on its own?
slightlyoff: we expect in the future there will be data sync, notifications, anything that needs a background context, can be sent to the worker as an event
dom: how does the imported script get cached?
slightlyoff: on original registration, the script is imported; all the scripts & dependencies are cached independently
plinss: can you add event listeners even when there are syntax errors?
slightlyoff: event listeners don't add anything meaningful
annevk: when is there going to be a draft spec?
slightlyoff: yes it should
[pop]
slightlyoff: I'm working on the spec right now, that's my day job
dom: are you expecting to provide the draft only when the issues are solved?
slightlyoff: once it hangs together ok, not everything solved
dom: how can we spread the work?
<twirl> https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md
slightlyoff: there are some big open issues
https://github.com/slightlyoff/ServiceWorker
slightlyoff: if I go to example.com and I include a third-party thing that registers a Service Worker, that script will have to live on example.com
annevk: the WebAppSec Group decided that web apps have their own CSP
slightlyoff: the question is about documents created by the Service Worker
dom: that seems like a nice addition but possibly problematic
slightlyoff: the issue is about the CSP policy for the document created in response to the "fetch", by the Service Worker
annevk: you should let the UA deal with not duplicating content on disk
slightlyoff: we could maybe reduce the burden for third-party content
annevk: it's in the browser cache
slightlyoff: the Service Worker's caches aren't the same as the browser caches
annevk: but when fetching the document, the browser is still going to look in its cache
slightlyoff: the browser cache has additional semantics around invalidation
annevk: if it's invalid at the HTTP level, you have to refetch it
<dka> trackbot start meeting
<trackbot> Date: 08 January 2014
slightlyoff: there's a similar issue with sites like mobify
annevk: I'm worried about lazy sites that won't load anything until the Service Worker is installed, because it's easier to write the site that way
slightlyoff: people want to be able to intercept their first-load content
<dka> ok
<dka> Ok - we are going to push push until later in the agenda.
annevk: hosted apps have their own caching context
slightlyoff: that's useful though, the ability to ask for your own storage partition
dom: it should be an option
slightlyoff: the use case is that the web is horribly insecure
annevk: it's a feature
slightlyoff: you should be able to have some control over it
dka: how do Chrome Apps work?
slightlyoff: they operate in a separate partition
dka: does anyone know how Apple save-to-homescreen web apps work? do they run in a separate partition?
annevk: I don't know, I know Opera Widgets did
dka: I think they don't
slightlyoff: if I'm a bank, I'd want to turn off all the ambient authority granted to all the other things in the world
annevk: would a bank never want to allow the user to share something?
slightlyoff: in the banking scenario, I can't suggest I want to include things from third-parties
annevk: on a normal bank website, you might to have a personalised map there showing you your nearest bank
timbl: because you don't want to include third-party scripts?
annevk: yes, I'm assuming they want to have it locked down
dom: another use case: say I'm Twitter & I want to enable users to access different profiles
annevk: some browsers have that as a feature, you can have a separate session/profile
dom: it seems there are reasonable use cases
annevk: I'm having a hard time coming up with attack scenarios in the shared/ambient authority
dom: why are we talking about this?
<slightlyoff> JeniT: http://infrequently.org/14/tag_01/service_workers.html#1
annevk: hosted apps have their own context, and the question is whether other apps might want to create their own context
dka: the high-level topic was about hosted web apps and the idea that when the user saves the icon to the home screen, the web app executes in a chrome less view in a separate context
slightlyoff: this is clearly useful behaviour; it's bundled with hosted apps, but it should be possible for any web page
<slightlyoff> dom: +1!
dka: this is all over the map at the moment
annevk: it's an additional layer of security
slightlyoff: a more common case is abuse of existing tokens, cookies and so on, which should not be stored across storage partitions
dka: is there concrete TAG work on this?
slightlyoff: we should ask relevant WGs whether they've thought about this
annevk: we should ask WebAppSec ... it could be a CSP thing
dka: wouldn't Jonas have some strong views on this? shall we ask him to join a future TAG call?
annevk: sure
<slightlyoff> JeniT: can I help scribe?
<slightlyoff> Zakim: scribenick: slightlyoff
<slightlyoff> [discussion of Extensible Web Summit planning]
<slightlyoff> [ trying to find a venue ]
<bkardell> Any discussion of format for summit?
<slightlyoff> bkardell: some discussion of unconference style...annevk is the keeper of the plan, it seems
<slightlyoff> [ discussion of f2f planning ]
<bkardell> I think it would be important to actively work on getting folks from all the browser vendors there
<slightlyoff> bkardell: agree
<bkardell> public-nextweb@w3.org has folks who might help organize invitations like that if asked
<annevk> bkardell: slightlyoff: the plan is to get those folks to attend
<annevk> bkardell: I don't just want folks from browser vendors, I'd like the implementers and standards people, not necessarily devrel
<bkardell> Yes
<annevk> and framework web devs
<slightlyoff> [ more discussion of f2f dates and locations ]
<annevk> and then not too many of them so it all still fits :)
<bkardell> annevk: that is just what i meant too
<annevk> I'd like to figure out if we can do the F2F bit of standards in this way rather than in these three-day meeting settings
<annevk> bkardell: cool cool, I guess we need to confirm a venue first
<annevk> bkardell: we can discuss registration then
<annevk> or maybe we should do both at the same time, have a critical mass and then do some kind of occupy movement :p
<bkardell> :)
<slightlyoff> [ short break ]
<scribe> ScribeNick: JeniT
old minutes: http://www.w3.org/2001/tag/2013/10/01-minutes.html#item06
annevk: what's new?
slightlyoff: nothing, and that's the problem
annevk: no one on the browser side seems interested in it
slightlyoff: we're interested in a solution but we don't have a design
JeniT: in what way is that easy for users?
slightlyoff: the thought was that you would have a tool to do the packaging up into the relevant package
annevk: the problem with multi-part mime was the need to reconfigure the server
JeniT: why not just have a zip file + manifest, if a tool has to do it anyway
slightlyoff: in a zip file, the contents are listed at the end of the file
twirl: to create the package, you have to make HTTP requests for the files
<annevk> Notes from last time: https://gist.github.com/wycats/220039304b053b3eedd0
JeniT: the reason I'm interested is because of the CSV packaging
<dka> scribenick: DKA
<JeniT> ... where we want more metadata anyway
anne: data on the web use case - you have a file and bunch of csv files - youw ant to package them together...
<JeniT> see eg http://dataprotocols.org/simple-data-format/
AR: let's assume that there is demand and figure out what it looks like. There are open questions about the delimiter and the format.
<JeniT> see also https://developers.google.com/public-data/
avk: that requires research.
AR: Henry you had views about whether it should be server assisted...
JT: I'm motivated to engage with it. Maybe I should review where we got to...
HT: If the kind of static options- -if that space has been explored and come up dry, then i won't stand in the way.
JT: what way are you advocating?
<annevk> http://wiki.whatwg.org/wiki/Zip#URLs
HT: the alternative paths we were looking at...
AR: One of the desires yehuda was expressing - you can take a file and put on a server without requiring exotic server configuration...
HT: I would like URIs to work - http URIs - either they give 404 or something stable or useful...
AR: The questions around the delimiters were: it must support fragments, should work in a backwards compatible way, not break in the face of ../,
AVK: Don't know what new there is to discuss here...
JT: What are the objections?
AVK: The objections are that it will be slower.
<annevk> http://esdiscuss.org/topic/generic-bundling#content-62
<Yves> looks a lot like WAR format for servlets
AR: I think there are people who are keen to get this done...
tbl: one could add an http herder instead but to give a 200 but to return something not what the URL identifies breaks the web.
<twirl> BTW, zip format allows to store metadata assoiciated with files http://en.wikipedia.org/wiki/Zip_%28file_format%29#Extra_field
tbl: some metadata - whenever you have a URI that starts with (this) within your package then it's equivalent to (this) URL on the Web.
<slightlyoff> twirl: interesting
tbl: at that point it would use a 209.
HT: Why would you do that if you know enough to know it's a package? why not give them what they asked for?
tbl: because what they asked for is too little.
ht: [argues dumb clients might trip up on this]
tbl: if it's a dumb client it'll just download it.
AR: We don't want to trigger the download UI...
<Yves> dump clients will always be unable to process directly a package, you need either a capable client, or a server serving flat the package
AR: Content negotiation is fraught....
tbl: It's orthogonal to signing.
AR: Agree.
HT: general points accumulating here: (1) nobody is going to start sending hashes (fragments) across the wire - we're not going to change http 1.1. Hashes don't get sent across the wire. that limits the ways we can use hashes for these purposes.
AR: Don't they get sent?
[consensus no]
HT: (2) if some servers will give different responses to the key requests because they don't recognize server or delimiter then the servers can't use 200 [response]
PL: the reason we had the delimiter in the URL was so that the client aware of this format would only sent the URL up to the delimiter. Then a 200 request would be appropriate because you requested the package.
<slightlyoff> Yves: we noted last time that we can't use "naked zips" because of the x-domain security consideratins
<slightlyoff> Yves: the idea is that we need some way to distinguish zips that are meant to be requested-into from those that expect to be "inert"
<JeniT> ScribeNick: JeniT
Yves: in Java Server world there are zips with specific instructions on how to process those zips
JeniT: what's the motivation for Chrome people interested in this?
slightlyoff: it's about how soon we can expect HTTP 2.0 pervasively
<Yves> and http2 would good for the zip case, as youcan expect that those URIs sill be served form the same URI subtree as the zip itself
<Yves> ie: taking benefit of its advantages
annevk: but URL parsing will only change long term
slightlyoff: we can change that rapidly
timbl: there's lots of implementations of URL parsing, you're not going to update all of them
annevk: you can say that there's a second level of parsing on the normal URL parsing
slightlyoff: I agree, that's why backwards compatibility is important
timbl: a micro syntax of the path is a good story
slightlyoff: browsers that support the syntax would request something different
annevk: it's like someone taking JSON and saying it now allows comments
slightlyoff: many clients could choose to start to interpret particular JSON properties in particular ways, that's fine
timbl: would you expect curl to change?
slightlyoff: it's only different processing for URLs that contain that particular delimiter
annevk: the core syntax of URLs includes all characters, and some URLs may include particular characters, which you're now interpreting differently
<Yves> talking about URI delimiter syntax and a-priori processing of it... a good read is https://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn-00
[discussion about whether this would just be http: URLs]
[annevk raises blob and data URLs]
dka: there's been discussion about this vs HTTP 2.0, can you explain how this is addressing the same problems?
annevk: in HTTP 2.0, if you fetch one file the server can respond with other files as well
dka: ah, I see
slightlyoff: this wouldn't be as efficient as HTTP 2.0, where you can have multiple fetches etc
dka: you also talked about using this for packaging up a web application
slightlyoff: HTTP 2.0 doesn't accommodate that natively, but it could be done in another way
<Yves> HTTP2 can also push you content
ht: the concern is that it might change meaning
annevk: you can ask whether . parsing changes the model of the URL
ht: my third piece of guidance to Jeni is that the backwards compatibility is very important
timbl: adding a magic string that would have to be detected in every URL necessitates changes everywhere
ht: did we start out saying this would work for arbitrary schemes?
annevk: I thought so
slightlyoff: I'd be happy for it to be only HTTP
annevk: because blobs, and a bunch of other custom schemes that Mozilla have
timbl: you want a good backwards compatibility story, that's important, but you also have to make sure that the changes that people have to make are limited to those doing HTTP GETs
slightlyoff: agreed
annevk: if you introduce new URL syntax then it's going to be generic and significant
[discussion about polyfilling]
annevk: the killer is relative URL parsing
ht: yes, the standard response to simple solutions was about knowing where to split the path
annevk: so if you have a!b where a is a package, b is an HTML document
slightlyoff: that's why Yehuda was talking about HTML being separated somehow
annevk: Jonas and Yehuda definitely want this to work
[adjourn]
Attendees
Contents
HTTP2 (and general IETF topics)
HTTP 2.0 & IETF stuff
... we have a few meetings, including one in London
... I suspect we'll then see public implementations
... technical work done by middle of year
... we're probably not going to require use of TLS
... market will choose
... we're on GitHub http://http2.github.io/
... how's that work going?
... there's a lot of interest, less clear that every browser will support new kinds of proxies
... we're not going to require an enterprise-friendly proxy model, for example
... it would be nice to have clarity for the model for user interaction on the web
... and the role of intermediaries
... architectural guidance about the model for the web would be useful
... proxies are a marginal issue as we move to TLS, until we rethink how they work
... we can go ahead with the technology without doing that
... your group is focused on the technology, TAG is focused on web platform at the moment, who is thinking about the web architecture level?
... they can do lots, the network can do lots, the infrastructure has grown up implicitly
... with TLS, things change, people are talking about do we need a policy language about what you can do with content?
... if we make fundamental changes to how HTTP can be used and that gets implemented, we upset a delicate balance and I'm concerned about second-order effects
... without that knowledge, it looks like they're not doing much because it's very subtle
... we should be having that discussion in public
... eg what to do with Expiry dates etc
... I think that's important; even if you can't specify proxy behaviour, can you specify invariants?
... eg that your content will never get rewritten, that you can depend on certain headers
... the airport Wifi problem: the proxies completely mess up my machine
... but the answers to a lot of this is "use TLS"
... I want the captive portal to add something at the HTTP level to say "you have to go here to log in to access this page"
... you need to involve browser, OS vendors, proxy vendors, Wifi alliance
... it needs concentrated effort
... I don't think we know whether trusted proxies are important or not: do we have data about this?
... when you're thinking about an architecture, considering different use cases is useful and you might not get that from data
... you can imagine social situations where a trusted proxy is reasonable
... we might have to imagine them, think outside the box, not just measure what's in the box
... because the current web is broken in so many ways
... we could mitigate that with certificate packages plus a better UI
... that feels to me like the best type of solution
... it doesn't solve issues when the employer owns the computer
... a separate certificate store, and if websites could opt out, refuse service if you're man-in-the-middled
... proxies would work on harmless pages, but not into banks
... difference for HTTP 1.0 to HTTP 2.0 should be invisible to end users and mostly invisible to sites
... technical issues are resolved, social issues aren't
... IETF draft doesn't include normative reference to anything else
... because eg there's no ABNF version in the ECMA version
... because eg semantics are important, and ECMA doesn't include semantics
... we have a situation where TC39 has expressed strong frustration
... TAG has asked for coordination
... IETF has resolved to do nothing
... is that accurate?
... or this is something we could mention at the I* meeting
... classic ways in which standards work messes up
... and there's the STRINT workshop the week before
... though I'm not sure I'll be there
... there's a mess here, but beyond W3C & TAG to fix
... how could we address it?
... we can start that in HTTPbis and loop you in, engage the folks in the Wifi world
... Wifi roaming and stuff like that
... breaking level at HTTP level would be clean
... I guess it's because it's a web level thing? shouldn't we fix it with HTTP?
... we could do an HTTP return code tomorrow afternoon
... I think it's useful to write down the problem, and I can put time into that
... but I agree it starts with articulating the problem, as you say
... we can raise awareness at TPAC for example
Permissions for Web Applications
... summary is that there are lots of things on the web that require user consent
... and lots of ways in which that requirement is addressed, and it's a mess, and I'd like the TAG to help with the mess
... one thing that people complain that you can't access device features from web apps
... a hole in the sandbox
... privacy risk and security risk
... we need to get the consent and indicate that consent has been given
... to highlight that your location is being tracked, your camera is being used
... how do we keep these decisions meaningful to the end user?
... the recommendation is to integrate consent into interaction with the user
... but this is the exception rather than the rule, most APIs use prompting
... this is good, but creates challenges
... five permissions involves prompting five times, you can't combine them
... this is horrible user experience, hard for testing, but too many choices are a bad thing
... using UI is particularly difficult, with indicators for permissions given, on small screens
... I'm not sure this is all the specs
... the first part of the mess is we don't know how big the mess is
... there's lots of commonalities in what you want to achieve when asking for consent, but there's no coordination
... I've chosen a few parameters, based on the issues I'm most concerned about
... there are different ways to request permission
... different times at which you ask for permission, two do so upfront
... difference in how persistent the permission is, where I've documented what happens in Firefox & Chrome
... on the iPhone, apps can ask for Calendar access for example just to put a particular event into my calendar
... a student analysed use of permissions in Google Play, found that free apps use the Calendar for personal profiling
... it's important to know the details about how the permission is going to be used
... a massive difference between sending messages to my friends when I click a button, to when the app feels like it
... some applications are built to serve the user, beneficent applications
... and others that aren't
... it would be good for app stores to have beneficent flags against particular apps
... we could define what a beneficent app is
... but also when you ask for a permission, you should say what you're doing with it
... on the 'tell me why' question, the model in web APIs so far is that the chrome of the browser will not relay that information
... because it needs to be trusted
... but the content of the page can provide that information
... tell the user why the permission is being asked for
... that's a good practice for application design
... bundling requests for permissions is useful
... enabling developers to rely on some permissions being there is broken
... we should preserve user agency
... the pattern I suggest people use is that in order to access eg the Calendar, you have to use a Promise, so it's always async
... the key enabler is that the APIs are async
... the insulation model is interesting because it grants more authority
... with regular web content the closest thing we have for authority is CSP
... eg the timeliness of the geolocation prompt is up to the UA, and browsers differ
... some of this is UA dependent and should remain so
... but there's a cost of making all of this UA dependent, because it's costly for developers
... it's useful to align where there's an emerging good practice
... going quickly through the other parameters
... next is whether there is an indicator about the permission having been granted
... also how you can change the given permission, whether you can revoke it or not, which is UA dependent
... how the permissions work with embedding, eg asking permission from an iframe, this is fairly consistent
... in Chrome & Firefox you can request permissions from within an iframe, the only exception being with fullscreen
... I'm not sure whether it's good that an ad can request a permission
... I also looked at what happens when permission is denied
... there's lots of variation
... finally, in the comments, sometimes the permission requests do get merged
... bundling permissions has no API
... do we have enough data to go on? what should that opinion look like?
... but also one about managing the existing system so it doesn't get even messier
... particularly for new APIs
... this is clearly something that the TAG should look at
... back to slides
... they're not quite sure where they're going at the moment
... the group is starting to get stuck on this problem as well
... reusing the technology from the web in a completely different context
... when we tried it with widgets, we found you can make it work but there's a ton of problems
... and what you really want is the web
... the web has portability built in
... you're back to having an app store for each device
... we want to go to facebook.com and get Facebook rather than downloading a new app on each device
... hosted apps are a pain to sign
... but those domains can get XSS'd or CSRF'd and then the attacker has access
... I'm just wondering whether those permissions are needed on the web
... eg do we need access to TCP sockets (we already have email clients on the web)
... a web app ought to be able to be a browsers & email clients
... it's very powerful; being able to make programs like that is really important
... I think signing is a red herring, I don't think it provides the model we think it provides
... we should revisit the packaging conversation
... until we have a web-based solution for packaging, we only talk about them as things that are signed
... we should unbundle the concerns, we shouldn't talk about these in the context of permissions
... eg exotic permissions like telephony
... I think there's work to be done here, based on Dom's presentation, just on the normal permissions that he's outlined
... there's some more fundamental things that we might want to look at, rather than bundling it into one conversation
... exotic permissions involve more complex arguments that involve packaging and signing
... this could apply to apps too, there are permissions you can give an app based on where it came from
... but if you're giving it a lot of power then the OS could make a hash of the fixed part of the app, record that it has permissions for that hash
... or you might check that it's signed
... that's where I see that going
... I want to have more guarantees about the code that's running on my computer
... there's an enormous community that cares about UI
... just done on my copious spare time, but a more systematic approach would be really useful
... taking on the larger review that I've started would be good
... the Web & Mobile Interest Group is having a task force which should help
... to coordinate the WGs, research etc
... the problem has been lingering for 5-6 years, and no one has taken ownership of it
... the TAG is the natural owner
... we need a more systematic approach
... from academia & within browser vendors
... but we can't control UI within browsers
... doesn't dictate
... but it's an implementation decision about merging those prompts
... we should create a unified API but it should facilitate the creation of the UI
... you have to understand the UI you want to enable to know what the API needs to capture
... eg the additional explanation about why the permission is being requested
... but even convergence onto something less messy would be great
... there's only so much anyone can do
... if the pattern is flexible enough it might address other problems
... those resources are there
... come up with a best practice
... evangelise it, ask them to adopt a common pattern
... it would be good for the TAG to ask the WGs which APIs they have that request permissions
... I also didn't mention is that for getUserMedia permission is that if you request access to the camera you get not just access to it, but information about the other cameras on the device
... there might be other cases like that
... you don't usually have that access, to avoid fingerprinting, but once you have access to a camera you can get a list
... there's no consensus about this, and the WGs are paying the price
... the direction is towards making fingerprinting detectable
... look for JSs that looks at all your fonts etc
... not static analysis, but monitoring the actual access
... they could say fingerprinting was a bad idea instead
... a secure program is one that only does what you expect it to and nothing more
... a trustable website or browser is one that only does things on your behalf, and only what you expect it to do
... we provide the ambient authority to fingerprint to all content all the time
... if I go to malicious.com then I expect it to be able to do stuff, but not things that are embedded
... a technical solution would be to give different permissions/scopes to different actors
... and a social solution (a law) that's chasing a technical solution that isn't a good match
... fingerprinting may be a lost cause at the moment, but that doesn't mean we shouldn't want to improve the current state
... from that point of view it might be a lost cause
... a different scenario is the malicious operative trying to track a particular individual using a lot of computer power and additional information about that individual
... and targeting them for a phishing scheme
... one makes it easy to track across sessions, and the other one you have to do a bunch of work
... eg handing out a unique identifier for a given user seems like a bad idea
... having varying bits across users, similar to what we have for Accept-Language, the User-Agent header, that's OK
... but the Device-ID is not OK
... because then if the site has other information about the user they can do way more than they can before
... you can determine on a bits-by-bits basis whether it's OK to expose the bits
... we're concerned about going to example.com and google.com knowing what I'm doing
... different actors are being composed together with the same permissions and we should look at that
... imagine we had a sandboxing element you could put around content
... I'd like to see people take specific actions
... do we want to write a document?
Service Workers
... they're origin-centric, installed on your origin, proxying all your requests from that origin to anywhere
... they're installed the first time you go to the site, but they don't start working right away
... this is to avoid loading spinners
... this is progressive enhancement from the network perspective
... gives programmatic control over requests, responses & caches, but doesn't change how you write your links
... but scripts can access them
... they're shared Web Workers, possibly across multiple tabs
... it can be killed at any time
... to avoid possibly memory leaky code from running from a long time
... the process is install then upgrade
... you should be able to recover from installing a Service Worker
... you register with navigator.registerServiceWorker("/*", "sw.js", "...");
... third argument is CSP stuff
... returns a Promise
... "install" event to set up
... "fetch" event for all requests from the page or other pages within the scope of the glob of the registerServiceWorker first arg
... "fetch" events only issued after installation is all done
... so yes, not yet, but that's coming
... this is an extensibility point: provide a new type of event
... user agent will re-request the second arg on the register service worker on a frequent basis
... import scripts are cached with the original script
... we expect listeners to be added through libraries
... eg URL shouldn't be an object here
... we're trying to send a draft spec to WebApps WG in the next month
... they are expecting it
... we're working through issues on GitHub
... implementations are coming, we've been prepping in Chrome
... Firefox has begun an implementation
... Twitter has been working on a node.js-based polyfil
... which will have API compatibility
... we just want to cover enough of the ground
... cache objects were in debate for a long time, but we're keeping them rather than using IndexDB
... because IndexDB doesn't handle serialisation of an opaque object
... same-origin restriction wrt where the service worker script can be hosted
... it's CDN hostile because we do a byte-by-byte comparison
... a compromised third-party server would be able to intercept all fetches
... it's also possible for the CSP behaviour to cause astonishing things to happen
... for instance, what happens when I serve the Service Worker script with a CSP header
... and the document has another CSP header
... and another navigation goes to the Service Worker and comes back with a CSP header set by the Service Worker
... these might have different policies, and it's possible to weaken the policies through the Service Workers
... so should there be policy inheritance?
... we currently think no
... the CSP policy for the script can be set in the register*() function rather than through HTTP
... we have it in the function because it's hard to set HTTP headers
... there's also things like Like buttons & Twitter etc
... composition we thought about was to allow people to use importScript() to embed in handling from third-parties
... as there's only one Service Worker running at one time
... eg Font hosting
... there are lots of third-party services
... you can't delegate to other origins
... this is an open question
... if we have big things like fonts, we want a way of having it pervasively available to avoid redownload of something the browser already has
... the Quota API is kind of a mess right now
... we think people are going to hit limits of storage
... and we don't have a way of notifying them & asking permissions
... and we can't just invalidate objects in the cache
... that's current state: we're implementing, spec out for discussion by end of month
PushAPI
Packaged Apps / Hosted Apps
... and all the iframes underneath me
... don't let other tabs poison my experience
... on the banking bit, where you transact money & stuff, I don't want to do that
... but maybe it would be better to delegate that to sites, I don't know how that would work
... if I'm logged in to Facebook and the bank, who suffers
... maybe you want to have an asymmetric relationship
... the bank can get stuff from others, but others can't get stuff from the bank
... with its own storage / cookies etc
... that seems to be something we ought to think about
... it would be more desirable to have control over it
... codifying it explicitly, sorting out the questions
... I think the goal was to prevent normal web to get access to hosted app API/access
... it would at least be defence in depth
... or should we let things develop?
Zip URLs & Packaging
... we looked at zips, and they have no method of providing the content types and the URLs of the items in the package
... which means you can't just use zips for packaging up
... the easy solution was multi-part mime
... the two related problems were about what the format would be
... and how to address into it
... and what the origin of the content is
... you can't indicate within the multipart message what the boundary is for the parts
... which is painful when streaming off the network
... the multi-part mime would mean you wouldn't have a manifest
... server-assisted solution might be more elegant but elegant does not mean deployable.
... the dual nature of the fragment identifiers is intentioned with that goal.
... Question was how you differentiate frag ids in a component of the collection from he frag ids you use to distinguish those components themselves...
... I care about the URLs.
... this is an invasive change to URL parsers in browsers... for this to happen I suggest it will take a long time...
... a lot of people seem skeptical of the benefits over http2.
... I haven't really seen many people keen on working on this...
... one way to do it is to say here's a zip file and within the zip file (you have a base address within he package) and everything within the package are equivalent to things on the web starting with this space...
... that gets around the uri problem.
... I'd like to use 209 for that because you shouldn't give a 200 and not return what the browser asked for.
... The client asked for something that is the main html page of the package, and the server returns a package.
... you put it in a package because you didn't want to have to think about it...
... that's why we were discussing the delimiter format...
... do we require that only people with new versions of apache can serve?
... one potential answer is - we don't need this with http2.
... there are others who think it would be nice to be able to publish one file.
... you package something up and then you can hand it around as one thing and that enables things like signing.
... this is new. We can allow something to come back without using 200 or 30x then that's different.
... the header was so that the client could say "i'm interested in this bit inside."
... also parallel with packaged apps
... something may be processed by the server, maybe processed by the client
... may have to look at that rather than talking about HTTP codes etc
... these involve a manifest format
... and deploying without rsync
... to have advantages like you have from chrome extensions
... it needs to be backwards compatible
... we need the backwards compatibility from exploding the file on the server
... like that not all query strings have the param=value microformat
... it's suddenly turning around and changing the definition of URLs
... this would occupy a space that could shrink with the deployment by HTTP 2.0
... which is different, with that package being signed, which I guess HTTP 2.0 wouldn't accommodate
... not those who are using URLs in XML namespaces etc
... but if you just do it at the fetch layer, then you can limit it to HTTP
... URLs already have a problem where different schemes require different parsing
... generic syntax never really works out
... and URLs are in that space
... and in b you have a link like ./c
... you want it to resolve to a!c and it won't
... without affecting URL parsing
... and for that you must change the URL parser
Summary of Action Items
[NEW] ACTION: alex to start documenting web permission patterns with code examples
[NEW] ACTION: DKA to send mail to chairs to ask about APIs using permissions
[End of minutes]
Minutes formatted by David Booth's
scribe.perl version 1.138 (CVS log)
$Date: 2014/01/15 15:27:31 $
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/packaging is important/I've heard that the reason packaging is important/
Succeeded: s/signing/signing hosted apps/
Succeeded: s/[something]/Interest/
Succeeded: s/EU law/EU law about cookies/
Succeeded: s/word/work/
Succeeded: s/HR/HT/
Succeeded: s/AR/AVK/
Succeeded: s/compatibility/compatible/
Found Scribe: Jeni Tennison
WARNING: No scribe lines found matching ScribeNick pattern: <Jeni\ Tennison> ...
Found ScribeNick: JeniT
Found ScribeNick: JeniT
Found ScribeNick: DKA
Found ScribeNick: JeniT
ScribeNicks: JeniT, DKA
Default Present: DKA
Present: Anne_van_Kesteren Dan_Appelquist Jeni_Tennison Peter_Linss Tim_Berners-Lee Alex Sergey Dom
Found Date: 08 Jan 2014
People with action items: alex dka
WARNING: IRC log location not specified! (You can ignore this
warning if you do not want the generated minutes to contain
a link to the original IRC log.)
[End of scribe.perl diagnostic output]