Technical Architecture Group Teleconference -- 08 Jan 2014

<JeniT> Scribe: Jeni Tennison

<JeniT> ScribeNick: JeniT

HTTP2 (and general IETF topics)

HTTP 2.0 & IETF stuff

mnot: we're 80% done on drafts for HTTP 2.0
... we have a few meetings, including one in London
... I suspect we'll then see public implementations
... technical work done by middle of year

<scribe> ... done by end of year

UNKNOWN_SPEAKER: currently discussion dominated by security issues
... we're probably not going to require use of TLS
... market will choose
... we're on GitHub http://http2.github.io/

dka: we discussed notion of trusted proxy
... how's that work going?

mnot: still really early days, we'll talk about it in Zurich
... 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

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
... it would be nice to have clarity for the model for user interaction on the web
... and the role of intermediaries

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
... architectural guidance about the model for the web would be useful

ht: the larger question that I'm concerned about is that the framing narrative for HTTP is out of date
... proxies are a marginal issue as we move to TLS, until we rethink how they work

<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
... 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?

mnot: HTTP & web arch as defined is open ended about what proxies can do
... 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

<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
... without that knowledge, it looks like they're not doing much because it's very subtle
... we should be having that discussion in public

<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
... 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

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
... but the answers to a lot of this is "use TLS"

timbl: no, because that just makes you accept bad certificates
... 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"

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
... you need to involve browser, OS vendors, proxy vendors, Wifi alliance
... it needs concentrated effort

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
... I don't think we know whether trusted proxies are important or not: do we have data about this?

timbl: I think we also have to imagine worlds that are different
... 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

mnot: eg BYOD, my employer tells me to install certificates, and they can man-in-the-middle all my traffic
... 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

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
... difference for HTTP 1.0 to HTTP 2.0 should be invisible to end users and mostly invisible to sites

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
... 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?

<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
... or this is something we could mention at the I* meeting

[some objections to going nuclear]

timbl: this is relevant to liaison between standards bodies, to NIH
... classic ways in which standards work messes up

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
... and there's the STRINT workshop the week before
... though I'm not sure I'll be there

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
... there's a mess here, but beyond W3C & TAG to fix
... how could we address it?

mnot: it's surprisingly complex; we can talk about it, starting to describe the problem space would be useful
... we can start that in HTTPbis and loop you in, engage the folks in the Wifi world

timbl: why Wifi?

mnot: because they run them
... Wifi roaming and stuff like that

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
... breaking level at HTTP level would be clean

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
... 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

mnot: we standardised one a year & a half ago, but we don't have the contacts with the implementers
... I think it's useful to write down the problem, and I can put time into that

dka: I can imagine holding a workshop with enough of the right people there
... but I agree it starts with articulating the problem, as you say

<dom> The Network Authentication Required HTTP Status Code

timbl: if you have pointers, that would be useful
... we can raise awareness at TPAC for example

<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

http://http2.github.io/

<mnot> http://http2.github.io

<dom> http://www.w3.org/2014/Talks/dhm-tag-permissions/

Permissions for Web Applications

<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
... 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

[slide 2]

dom: I care about people choosing web over native
... one thing that people complain that you can't access device features from web apps

[slide 4]

dom: when you use an API to access a hardware feature, you create a new risk for the user
... a hole in the sandbox
... privacy risk and security risk

[slide 9]

dom: to protect the user, we've created some mitigations when web apps need to access something
... 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?

[slide 10]

dom: there's been a preference to avoid prompts, particularly modal prompts
... the recommendation is to integrate consent into interaction with the user
... but this is the exception rather than the rule, most APIs use prompting

[slide 11]

dom: we have a sandboxed model
... 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

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
... 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

ht: we should discuss how to get more eyes on this

dom: we should have a better way of getting a picture on this
... 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

<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
... 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

dom: one area of activity is about blessed applications
... 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

slightlyoff: in Boston I outlined some work that I've been doing arising from Chrome App Store & with Android
... 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

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
... 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

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
... I'm not sure whether it's good that an ad can request a permission

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
... I also looked at what happens when permission is denied
... there's lots of variation

<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
... finally, in the comments, sometimes the permission requests do get merged

<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
... bundling permissions has no API

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
... do we have enough data to go on? what should that opinion look like?

dom: there's a long term problem about making permissions not suck
... 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

[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
... back to slides

[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
... they're not quite sure where they're going at the moment

<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
... the group is starting to get stuck on this problem as well

annevk: the problem with packaged app is that you're designing a new ecosystem next to the web
... 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

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
... 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

dom: I've heard that the reason packaging is important so that you can sign the app
... hosted apps are a pain to sign

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
... 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)

timbl: Gmail isn't an email client
... a web app ought to be able to be a browsers & email clients

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
... it's very powerful; being able to make programs like that is really important

slightlyoff: how do we achieve this while still having URLs, a unified model that makes sense to web developers & users
... 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

<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
... 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

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
... 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

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
... I want to have more guarantees about the code that's running on my computer

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?
... there's an enormous community that cares about UI

dom: the link is a starting point that summarises research
... just done on my copious spare time, but a more systematic approach would be really useful

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
... 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

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
... 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

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
... we need a more systematic approach

timbl: it has to be grounded in the UI

dom: the TAG should pull in experts from the HCI field
... from academia & within browser vendors

slightlyoff: our role is to coordinate, we can coordinate coherent API within the web platform
... but we can't control UI within browsers

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
... doesn't dictate

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
... 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

dom: the async model is fairly well accepted
... 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

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
... but even convergence onto something less messy would be great
... there's only so much anyone can do

slightlyoff: that's a meaningful & useful thing for us to do, yes
... if the pattern is flexible enough it might address other problems

dom: if there's some research that's needed, the Mobile Interest Group is willing to help
... those resources are there

plinss: what specific actions should we take to move this forward?

slightlyoff: we can look at specifics of the APIs in question
... come up with a best practice
... evangelise it, ask them to adopt a common pattern

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
... 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

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
... you don't usually have that access, to avoid fingerprinting, but once you have access to a camera you can get a list

annevk: fingerprinting is really easy

dom: there's a difference between active & passive fingerprinting, and between detecting & preventing fingerprinting
... there's no consensus about this, and the WGs are paying the price

<dom> http://w3c.github.io/fingerprinting-guidance/

annevk: who says fingerprinting is not a lost cause?

dom: the Privacy Interest Group
... 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

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
... they could say fingerprinting was a bad idea instead

annevk: the EU law about cookies is dreadful

slightlyoff: websites should only do things that you expect them to
... 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

timbl: we should avoid having a technical solution that's perverse because it's trying to achieve a mismatched social goal
... and a social solution (a law) that's chasing a technical solution that isn't a good match

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
... fingerprinting may be a lost cause at the moment, but that doesn't mean we shouldn't want to improve the current state

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
... 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

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
... 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

slightlyoff: we should analyse who's doing what & in what context
... 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

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
... I'd like to see people take specific actions
... do we want to write a document?

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].

<ht> http://xkcd.com/1314/

<twirl> https://joindiaspora.com/posts/1653418

<bkardell> twirl: 500 error on link?

Service Workers

slightlyoff: Service Workers are an in-browser proxy that handle fetches
... 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

[example content of a service worker]

slightlyoff: use importScripts() to install dependencies (eventually installed through modules)
... "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

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
... so yes, not yet, but that's coming
... this is an extensibility point: provide a new type of event

dom: how does the imported script get cached?

slightlyoff: on original registration, the script is imported; all the scripts & dependencies are cached independently
... 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

plinss: can you add event listeners even when there are syntax errors?

slightlyoff: event listeners don't add anything meaningful
... we expect listeners to be added through libraries

annevk: when is there going to be a draft spec?
... eg URL shouldn't be an object here

slightlyoff: yes it should

[pop]

slightlyoff: I'm working on the spec right now, that's my day job
... 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

dom: are you expecting to provide the draft only when the issues are solved?

slightlyoff: once it hangs together ok, not everything solved
... 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

dom: how can we spread the work?

<twirl> https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md

slightlyoff: there are some big open issues
... same-origin restriction wrt where the service worker script can be hosted
... it's CDN hostile because we do a byte-by-byte comparison

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
... 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

annevk: the WebAppSec Group decided that web apps have their own CSP

slightlyoff: the question is about documents created by the Service Worker
... 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

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
... 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

annevk: you should let the UA deal with not duplicating content on disk

slightlyoff: we could maybe reduce the burden for third-party content
... 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

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
... 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

<dka> ok

<dka> Ok - we are going to push push until later in the agenda.

Packaged Apps / Hosted Apps

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
... and all the iframes underneath me
... don't let other tabs poison my experience

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
... on the banking bit, where you transact money & stuff, I don't want to do that

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
... but maybe it would be better to delegate that to sites, I don't know how that would work

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
... if I'm logged in to Facebook and the bank, who suffers

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
... maybe you want to have an asymmetric relationship
... the bank can get stuff from others, but others can't get stuff from the bank

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
... with its own storage / cookies etc
... that seems to be something we ought to think about

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
... 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

annevk: it's an additional layer of security
... it would at least be defence in depth

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?
... or should we let things develop?

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

Zip URLs & Packaging

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
... 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

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
... 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

annevk: the problem with multi-part mime was the need to reconfigure the server
... you can't indicate within the multipart message what the boundary is for the parts

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
... which is painful when streaming off the network
... the multi-part mime would mean you wouldn't have a manifest

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.

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...
... server-assisted solution might be more elegant but elegant does not mean deployable.

HT: I would like URIs to work - http URIs - either they give 404 or something stable or useful...
... 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.

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...
... 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.

JT: What are the objections?

AVK: The objections are that it will be slower.
... I haven't really seen many people keen on working on this...

<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.
... 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.

<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.
... 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.

<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.
... you put it in a package because you didn't want to have to think about it...

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...
... that's why we were discussing the delimiter format...

<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....
... 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.

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]
... this is new. We can allow something to come back without using 200 or 30x then that's different.

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.
... the header was so that the client could say "i'm interested in this bit inside."

<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
... 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

JeniT: what's the motivation for Chrome people interested in this?

slightlyoff: it's about how soon we can expect HTTP 2.0 pervasively
... and deploying without rsync
... to have advantages like you have from chrome extensions

<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
... it needs to be backwards compatible
... we need the backwards compatibility from exploding the file on the server

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
... like that not all query strings have the param=value microformat

slightlyoff: browsers that support the syntax would request something different

annevk: it's like someone taking JSON and saying it now allows comments
... it's suddenly turning around and changing the definition of URLs

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
... this would occupy a space that could shrink with the deployment by HTTP 2.0

dka: you also talked about using this for packaging up a web application
... which is different, with that package being signed, which I guess HTTP 2.0 wouldn't accommodate

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
... not those who are using URLs in XML namespaces etc

slightlyoff: agreed

annevk: if you introduce new URL syntax then it's going to be generic and significant
... 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

[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
... and URLs are in that space

annevk: so if you have a!b where a is a package, b is an HTML document
... 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

slightlyoff: that's why Yehuda was talking about HTML being separated somehow

annevk: Jonas and Yehuda definitely want this to work
... and for that you must change the URL parser

[adjourn]

- DRAFT -

Technical Architecture Group Teleconference

08 Jan 2014

Attendees

Contents