See also: IRC log
<trackbot> Date: 02 November 2009
<dom> Scribe: Bryan
<drogersuk> BONDI 1.1 Candidate Release today: http://bondi.omtp.org
drogersuk: announcementof BONDI 1.1 candidate release is pending
<fhirsch> david notes seeking feedback on this public candidate release
<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/att-0240/minutes-2009-10-28.html
<darobin> (direct link to BONDI 1.1 CR: http://bondi.omtp.org/Documents/CR1.1/BONDI%20Candidate%20Release%201.1.zip)
Resolution: minutes of 28t Oct are approved
<fhirsch> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0261.html
<drogersuk> http://bondi.omtp.org/1.1/CR/
richt: been working on baseline, last update is on multiple address book report, error handling, etc. expect interesting stuff this week
fhirsch: mark actions as pending when work has been done, to assist tracking
... any need to discuss File API or notifications in advance of joint meeting?
darobin: not sure we have a lot to discuss yet in advance
fhirsch: suggest to talk about policy requirements: sent out a draft for discussion
<darobin> live updated agenda, together with scribe slots: http://www.w3.org/2009/dap/wiki/F2F_Agenda_2-3_November_2009%2C_TPAC/
<scribe> new topic: policy requirements draft
<dom> Device API Policy Requirements draft
fhirsch: current draft displayed, with input from BONDI etc
... need a general discussion about features, capabilities etc
... one issue, we need to address javascript dependency but are there any other language independency requirements?
darobin: must support ecmascript and other languages as nice to have
drogersuk: rationale on language independence is the policy language is not directly connected to the implementation, e.g. as javascript API's
marcin: 2 comments, 1 is all of BONDI policy language independent as an XML document, 2 is all interfaces are expressed in webidl, which is intended to be implementation independent
fhirsch: so it seems language independence is given if you look at the policy elements themselves, but is there a language dependency on the strings, e.g. features
<drogersuk> @JereK - yes that's right
marcin: no the strings should be language independent
<AnssiK> my minor nit was that normative statements should use ECMAScript over JavaScript for consistency
<darobin> Paddy’s comments on policy requirements
laura: new email from paddy received on comments to policy requirements
<darobin> ^-- link to Paddy's email
<Laura_Arribas> http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0004.html
<Laura_Arribas> Laura’s comments on policy requirements
fhirsch: discuss first the feature requirement, as a set of capabilities provided by the API, as a policy resource aspect
... understanding is that mechanism is defined in terms of features, access controls are defined re features, and capabilities are things concerned about but related to features first. the API is related to features and capabilities
drogersuk: believe that is correct
slewontin: see two models, abtract capability model related to operations e.g. send - with that model specs need non-normative description of semantics, with baseline description of normative capabilities
... 2nd option is the API's define the semantics, in that model the API;s define the capabilities, and we don't need a generic capability approach
... the 2nd is the feature model
... the policy model itself does not have to define the semantics and can work in either case
... if we adopt the abstract model, we need to give guidance on what to use to comply with the semantics
... a feature based model is easier to specify - we don't have to worry about extensions or give overt guidance
drogersuk: agree, need to keep abstraction level low
Nick: features to be capability-centric, and provide a way of insulating the API from the underlying implementation
slewontin: question is when new features are added within an API, e.g. to add geolocation tag, the policy implications are easier to address in a feature model
... feature-based approach also simplify the access to data where the data type implies semantics, e.g. media access vs direct file access
fhirsch: don't we still have to define the semantics for the feature name?
marcin: device capabilities vs feature model is still being debated in BONDI
Suresh: when a widget is defined, so you declare the feature or capabilities?
Marcin: we declare the feature only
<fhirsch> stephen notes that capability can be treated as only string - e.g name + parameter
marcin: there are three parameters in enforcement, the feature, context, and parameters. some decisions thus are not possible until runtime
fhirsch: so how is interoperability of capabilities semantics ensured?
marcin: the mapping is often 1-to-1, there is also an n-to-m mapping but there is not an enforcement point to mandate that mapping
bryan: isn't the mapping defined in the webidl specification?
marcin: when we allow extensions there may be unclear mappings
bryan: but properly specified API's should define the capabilities if done correctly
marcin: there is the possibility of inconsistency if a vendor does not make the mapping clear
slewontin: if we open up the spec to say this needs to apply to any API outside our set, we have dependency to clarify how the mapping is ensured in those extensions
fhirsch: so for our chartered API's we can define the policy elements normatively and informatively for API's outside our set
... the abstract approach seems more involved
Nick: 3 reasons for the way that BONDI approache this: 1 is extensibililty, 2 is versioning, 3 is way of expressing in a simple rule a risk that may be orthogonal over 12 API
<fhirsch> exensible apis, enable api versioning,
Nick: an example of 3 is that file API and gallery, the io.file capability can address a risk over the two
... we need to define the semantics clearly
drogersuk: is extensibility in scope here?
dom: extensibility is not in scope - but the orthogonal risks should be manageable through the policy framework
marcin: we should focus on those capabilities that are expressed in the charter, the device capabilities as definition of what we plan to do, and the API's as how - the implications on versioning are important to consider in this
fhirsch: so we should be able to concretely define the semantics of the chartered capabilities - but for versioning, don't we have plan (by resolution) to not address versioning
dom: we are not trying to create API's with versioning information
fhirsch: what are the implications for policy versioning?
marcin: we solved that in BONDI we want to keep compatibility, but if there are changes that break compatibility we change the API IRI
<fhirsch> suggestion -define capabilities and their semantics for the specific cases listed in the charter, define associated features concretely
marcin: example is file API, IRI is filesystem. We will add seek capability, and if that is security related, we may have a related device capability e.g. file.seek, and thus the feature IRI will need to change
<paddy> No, I'm not on the phone
<fhirsch> richard notes separate spec versioning from detailed versioning of content
richt: the BONDI n-to-m model is very good, the problem is when bad user agents don't comply to what the user and policy expects
... if the implementation is incorrect, where does the blame lie?
<paddy> I can only pay full attention later today
dom: with the runtime vendor
drogersuk: are you asking if the runtime should be verified to ensure compliance?
<paddy> ok, thanks
richt: the vendors need to ensure compliance
bryan: web runtime application installation/update controls should address the compliance issue
drogersuk: the policy is itself also an issue if malformed
fhirsch: enter an issue in the chat, but non-conforming implementations or data are a secondary issue at this point
<drogersuk> ISSUE: How to handle malformed policies, policy validity and intentional abuse of policy? How is policy deadlock handled? e.g. Only dial +39 numbers + Never dial +39 numbers
<trackbot> Created ISSUE-35 - How to handle malformed policies, policy validity and intentional abuse of policy? How is policy deadlock handled? e.g. Only dial +39 numbers + Never dial +39 numbers ; please complete additional details at http://www.w3.org/2009/dap/track/issues/35/edit .
fhirsch: we need some resoutions, e.g. "we will have features", and how general we will be with capabilities etc
... we all seem to be in agreement on the features, and will formalize that later - not sure how to address capabililties
<dom> dom: note that our policy framework shouldn't be limited to the scope of our own charter — it needs to work for APIs defined in other W3C groups (e.g. Geolocation, WebApps)
slewontin: think need to define capability semantics is unavoiable
<paddy> I would support defining device capabilities for those specific capabilities listed in the charter
<paddy> but at the same time set out the framework by which additional capabilities get defined
slewontin: policy processing model should be orthogonal to this discussion
<fhirsch> believe we have agreement to have "features" and standardize that, also will need to define capabilities for APIs of this WG and some related W3C work
Suresh: it depends upon how the policy document is to be defined
<fhirsch> also will need some semantics discussion of cababilities
slewontin: would propose a requirement that the policy expression and processing model be orthogonal
fhirsch: e.g. a URI or string that allows loose coupling
dom: we have said we plan to let the user make decisions which is a UI-related objective, and feature dependent, but will the processing model etc affect those presentation requirements?
<fhirsch> general agreement to treat feature/capabilities separeate from general policy model
<fhirsch> with linkage of URIs/strings etc
<fhirsch> ?
dom: take a widget accessing the camera, don't we need ability to express requirements on when/how the user is informed?
slewontin: if we do need to present something, it needs to be presented in a useful way and semantically meaningful to the user
<darobin> arve?
<darobin> Oslo this is Santa Clara please come in
bryan: prompts should influence the processing model
slewontin: we can have an API that implies user consent in the way is provided
<fhirsch> user consent can be implicit in API definition, e.g. if API requires camera user to press camera button, essentially giving consent
fhirsch: it was an important point that we want to ensure user consent but avoid prompts where possible
slewontin: it is possible to have implicit consent because the applicaiton was signed
<fhirsch> anssiK asks about domain based trust
AnssiK: is a domain based model included ?
<fhirsch> see http://www.w3.org/2008/security-ws/papers/SecurityPolicyNokia.pdf
slewontin: yes, in the access policy model and trust policy model should include domain based approach
bryan: in BONDI we have flexibilty to use multiple models
thomas: as we talk about getting high assurance about identity of web applications, we need to mind the HTML model which is limited to the domain model
... thus we need to be clear on where we are limited to the model provided by HTML5
fhirsch: if the origin is HTTPS, doesn't that provide equivalence to HTML5?
thomas: the information in the certificate is not addressed in HTML5
suresh: how to the feature and access element play into this discussion?
fhirsch: access is expected to be a short-term solution to an immediate problem, to keep it limited in scope
darobin: also not to constrain DAP
<AnssiK> here's a thesis related to the domain-based trust model I talked about http://lib.tkk.fi/Dipl/2009/urn100073.pdf
slewontin: want to address the issue brought up, in a certain way we said we will just have to live with the HTML5 sandboxing model - for widgets this is OK, but for browser-based webapps this is a serious issue
<fhirsch> stephen notes that contstraints of html5 and javascript sandboxing too limiting
slewontin: it is an issue we are going to have to address separately from the policy model
... we may not implement domain-based access since the javascript same-domain based security needs to be rethought from the ground up
drogersuk: it depends upon the use case, and the assurance that you can trust the DNS system
<fhirsch> issue: how far can we go with domain based trust model given constraints of HTML5 security model
<trackbot> Created ISSUE-36 - How far can we go with domain based trust model given constraints of HTML5 security model ; please complete additional details at http://www.w3.org/2009/dap/track/issues/36/edit .
drogersuk: what we need is guidance to warn people of the risks of domain-based models
slewontin: the limitations of the user-agent need to be taken into account
<fhirsch> bryan notes roaming can impact trust model
<fhirsch> bryan notes we need framework that goes browser
<fhirsch> richard notes variants of session, one shot etc for domain based trust
<fhirsch> ansii notes trust applicatoin versus application instance
<dom> TTL's of policy decisions
bryan: we need to address network roaming, e.g. 3G-WiFi, and trust in the DNS system as a requirement - if we need additional feature support e.g. reliance upon certificate data and HTML5 does not provide that, DAP should be able to create new requirements ala what BONDI supports for this
slewontin: the issue with sandboxing was discussed last year, we can find the discussion details to refresh the group
<Zakim> tlr, you wanted to suggest that we keep our layers straight
<richt> note to JereK: the concept was that different trust models may denote more or less opt-in requirements for users. One-shot as an option for domain-based opt-in due to the inherent security concerns...
<fhirsch> tlr clarifies we cannot trust network because of layering
thomas: re different networks and assurance, we need to think of the web as an end-to-end environment in which the network layer is not trusted
... we are focusing on the level of properties exposed through HTTP
<tlr> proposed requirement: we only use information that's visible on the HTTP level, not security properties of lower level network protocols
drogersuk: in the real world, there is an assumption of trust in the service provider and is an additional source of information to use in policies -
... 2nd point is re abuse cases, it doesn't matter if we trust a site and have recorded a user consent through, since a spoofing attack is possible
<fhirsch> issue: domain spoofing
<trackbot> Created ISSUE-37 - Domain spoofing ; please complete additional details at http://www.w3.org/2009/dap/track/issues/37/edit .
<scribe> ACTION: claes should issue recommendation on the granularity of the security system [recorded in http://www.w3.org/2009/11/02-dap-minutes.html#action01]
<trackbot> Created ACTION-38 - Should issue recommendation on the granularity of the security system [on Claes Nilsson - due 2009-11-09].
<fhirsch> tlr notes can rely on http and ssl
bryan: we need to rely upon what HTTP relies upon also
thomas: we should also rely upon SSL as a source of information, but DNSSEC, e.g., isn't directly linked to what we interact with
fhirsch: we have at least 6 different areas we should get concrete proposals on: access control, trust model, capabilities, features, API security considerations, security threats & privacy risks
<richt> Scribe: richt
Scribe_Nick: richt
<scribe> ScribeNick: richt
work started in 2006. merged work to webapps.
darobin: DAP defining file system API
... this meeting is to get everyone up to date with File API progress
... and how we can coordinate
<darobin> Scribe: Richard
<darobin> ScribeNick: richt
<darobin> File API: http://dev.w3.org/2006/webapi/FileAPI/
Arun: any features device API wants to introduce should layer elegantly with File API
... synchronous access to the file although this was a non-starter for specs.
<darobin> File System API requirements: http://www.w3.org/TR/dap-api-reqs/#file-system
Arun: second incarnation was asynchronous with callback functions.
... however, rather than callbacks we went with an Event model. This is the 3rd incarnation of File API
<dom> ->
<dom> FileAPI Editor’s Draft
Arun: discusses the individual components of the File API spec.
<darobin> the Blob API: http://1416andcounting.files.wordpress.com/2009/03/theblobremakebox.jpg
<arve> Is having someone pose the question OK?
Arun: use of URNs to identify a file
<anne> arve, you could type it in and see if somebody picks up on it
Arun: File API allows you to receive progress events as file is being read
... one of the drawbacks of call based model was that it did not elegantly account for progress events
... hence the 3rd incarnation based on the Event model
... In discussions it was also useful to preview files. In 2nd incarnation we had a scheme. in 3rd incarnation we have URNs
... URNs have a lifetime of the document
... not general concensus about how to identify files (in editor's comments in spec)
Bryan: how do we address writing to a file?
Arun: there are no write methods. This is subject to security considerations and needs to be discussed further
... There is a security error placeholder in the File API spec
<fhirsch> arun notes security considerations more limited for read than write
Arun: but not clear how this is used currently
<shepazu> sandbox++
<ifette> me
<ifette> Maciej
<ifette> is talking
mjs: if you have a single API. read access to any file a user can access. that has serious security risks to ensure that other files aren't exposed
... so files in a webapp should be treated in a seperate way
ian: if the user passes in a file reference and let the app upload is a user writing to that more dangerous?
<dom> DAP Requirements for filesystems API
mjs: the write handle should be different to the read handle for the file dialog
Bryan: how do we access local files in particular locations and discover particular locations?
... how are those locations represented in URN?
... what are the available mount points that I can access?
Arun: file API has not worked on this issue
... with the existing file picker. you can poke in to the system. no hook but file picker mitigates this
Bryan: writing to a file and determining read locations: the use cases are different between DAP and File API?
Arun: has some concerns on the requirements in BONDI and DAP File System APIs
drogersuk: issues have been addressed in BONDI 1.1
<drogersuk> correction - BONDI 1.01
speaker?
sicking: anything that allows read or write access beyond what we have already is going to be extremely hard.
<darobin> http://www.w3.org/TR/dap-api-reqs/#file-system
<dom> BONDI Filesystem API
<anne> youwant http://dev.w3.org/2009/dap/file-system/
sicking: keep security and the API orthogonal
<anne> (remove cvsweb if you want the actual files and not the CVS crap)
<drogersuk> BONDI 1.01 version here: http://bondi.omtp.org/1.01/apis/filesystem.html (current approved)
hixie: not sure if this can be orthogonal
Arun: there is clearly a wish list for write capability. There are some good use cases that we should discuss
... if version 1 of File API has any observations from DAP WG this is useful input. Would like to progress to TR
drogersuk: would be good to have leadership from the chairs on how to resolve the differences
Arun: lots of discussions around what the security hangs off. lots of considerations based on what we choose
... File API hangs off the global object
... There could be a file writer object?
drogersuk: We have to make these decisions quickly to avoid fragmenting and going in difficult directions between groups
<shepazu> (WebApps File API: http://dev.w3.org/cvsweb/~checkout~/2006/webapi/FileAPI/Overview.html?rev=1.9 )
drogersuk: the implementors of BONDI are browsers and widget user agents
... many company initiatives in progress
<Zakim> chaals, you wanted to say Opera implements
chaals: we implement a full filesystem api in the browser. we have it running in widgets. based on significant security considerations. runs in opera unite
... doesn't see fundamental disconnect between widgets and web apps
... it makes sense to be the same system and same API in these environments
marcin2: thinks concepts introduced in BONDI are relevant to web apps. lots of reuse may be possible.
... would like to rename File API to File Upload API
<dom> FileReader API rather than FileUpload, at the very most
marcin2: in BONDI/DAP we want to manipulate the file system. Different with a URN abstraction?
<chaals> [agree with Dom that this is now a fileReader API]
<fhirsch> Chair: Robin Berjon, Frederick Hirsch
Arun: 'upload' may be interpreted differently. File API may work with some form of 'upload' but this a file read spec not file upload spec
... it is lacking write metaphors. any way to write to a file
<anne> Web File API vs System File API?
shepazu: when we talk about evolution do we mean this version or next?
Arun: we should ship an evolution soon. agree on it, ship it then create version 2 addressing other issues
shepazu: a File API that doesn't let me write is not as useful to me
sicking: its useful but there are other use cases
Arun: what we have in version 1 is the current level. there are use cases for writing.
<Zakim> darobin, you wanted to talk about Blobs, defining writing
<darobin> ack
<arun> I am willing to look at use cases, generate requirements, and edit draft of write capabilities.
darobin: 2 things. 1.) clarify status of blob interface - is it generic for handling binary data
sicking: yes and no. it is synchronous. may have need for byte array. Intent is for it to be generic
darobin: hasn't seen discussion on linking bytearray and blob
sicking: agree
darobin: it's a question that needs to be addressed
mjs: this would be a good topic for friday's meeting
<tlr> when is the joint meeting?
<tlr> ECMA TC39 / HTML5 / webApps
<mjs> tlr, it's Friday morning
fhirsch: CRUD of file system in Device API charter
... do we need to think about ACLs or other forms and levels of permissions
chaals: File API plans to coordinate with DAP group. We want something that layers smoothly between the two.
... do we want to add ACLs. not something we have considered yet. It gets complicated and not something to ship right now.
... may be something for the future.
fhirsch: not just the chairs working. the WG should assist on this topic
drogersuk: chairs should liase - own the master doc and have some discussions in WGs and publicly
<dom> [I don't think it needs to be owned by the Chairs; I don't see why it would, in any case]
<Zakim> arun, you wanted to discuss use cases
<Hixie> darobin, can you repeat the actual item for which you want volunteers? it didn't get minuted
<darobin> RB: looking for volunteers to look at how the layering of File API, Writer, FS browsing can be layered
The action on the table is: someone to ask questions via mailing lists on how these two initiatives can layer together. Collate use cases - what are the exact write API use cases for the web?
<scribe> ACTION: chaals to Collate use cases - what are the exact write API use cases for the web. Hoe the two initiatives can layer. [recorded in http://www.w3.org/2009/11/02-dap-minutes.html#action02]
<trackbot> Sorry, couldn't find user - chaals
<darobin> ACTION: chaals to shepperd the discussion on File API, Reader, Writer, FS Browser layers; collecting use cases [recorded in http://www.w3.org/2009/11/02-dap-minutes.html#action03]
<trackbot> Sorry, couldn't find user - chaals
<darobin> Volunteers to help: Arun, Hixie
<dom> ACTION: Robin to check that Chaals shepperds the discussion on file API, Reader, Writer, FS Browser layers; collecting use cases [recorded in http://www.w3.org/2009/11/02-dap-minutes.html#action04]
<trackbot> Created ACTION-39 - Check that Chaals shepperds the discussion on file API, Reader, Writer, FS Browser layers; collecting use cases [on Robin Berjon - due 2009-11-09].
<darobin> ack
<fhirsch> chaals noted that policy for File API can be someone simple as first cut, not addressing ACLs but file system access itself
Bryan: looking at File API, DAP charter, BONDI: the file system API in DAP charter is focused on providing native resource access similar to any other (non-web) device API
<fhirsch> he notes later effort could be more detailed
Bryan: File System API and File API have different use cases? Valid in their own domains?
<dom> [but clearly a FileSystem API should be able to re use the File Interface defined in FileUpload/Reader/ ...]
shepazu: we want the UX to be consistent across usage
<Bryan> Bryan: The DAP FileSystem API is focused clearly in the DAP charter and as already implemented in products based upon BONDI, as a "device API" specifically on the functionality expected of an applications accessing the device filesystem directly. The Webapps FileAPI is clearly focused on the role of a web API using web semantics, and is different in objective than device API's, e.g. accessing a device native client functionality such as a messaging client.
<chaals> [I pretty much diametrically disagree with you Bryan...]
Eric Uhrhane: generating a set of use cases for a web file system. readable/writable files/directories. There will be a lot of overlapping use cases between File API and DAP WG
<shepazu> [I don't want to have a situation where some spec is developed for writing files, but it's not implemented by desktop browsers, just on mobiles]
Eric Uhrhane: see requirements in DAP but not use cases
darobin: use same use cases. requirements extracted from inputs from other groups
<fhirsch> issue: use cases and threat model for security requirements
<trackbot> Created ISSUE-38 - Use cases and threat model for security requirements ; please complete additional details at http://www.w3.org/2009/dap/track/issues/38/edit .
<fhirsch> issue: use cases for API requirements where needed
<trackbot> Created ISSUE-39 - Use cases for API requirements where needed ; please complete additional details at http://www.w3.org/2009/dap/track/issues/39/edit .
darobin: if for some APIs we don't need use cases then we'll skip otherwise they will be added
... quickly listed requirements. if there is any doubts we will go to use cases
mjs: thinks there is a fundamental disconnect between widgets and web pages
<ifette> +1 othermaciej
mjs: installing widgets involves a user trust decision
... following a link does not denote a trust decision.
<chaals> *cou*phishing
mjs: this has an impact on web api design. In File API, file is chosen by the user, when they initiate the process.
... throwing up permissions dialogs is not acceptable in the web domain. makes a difference to the API design
... important when designing the API - is it only for widgets with explicit trust decisions or the web where we don't have and don't want to create those trust decisions
... perhaps the widget trust decisions are a superset of web decisions
<chaals> ["the public web" isn't "the web"]
<shepazu> [I wonder if Maciej is saying that Web pages shouldn't be able to say they want to write to a file?]
hixie: the best api for a file system on a device may not be a perfect superset of a web based file system api
... they have different security architectures.
mjs: they may end up not as supersets if there are different security constraints
<chaals> nikunj meht
<sicking> Nikunj from Oracle
<chaals> mehta
Nikunj: a web application could write to its own sandboxed area. Read and write may not be a disjoint set as opposed to widgets
<dom> [I think the use cases will also help identifying what features we need in priority for a write/filesystems API]
<chaals> [Dom, agree]
<shepazu> [which mailing list(s) should this coordination happen on?]
let's get through the queue....
<Zakim> ArtB, you wanted to get clarification on when DAP plans to publish the FPWD of their File System API
ArtB: we will go round in circles until we have solid use cases
... when will File API be available for FPWD
Arun: believe we could go out now
<mjs> shepazu, what I'm saying is, it's ok to let the user choose a file to let a Web app write to it in an active way (like a "Save As" dialog) but it would not be ok for a Web App to choose a place in the filesystem to write to and throw up an OK/Cancel dialog to the user
<mjs> shepazu, (at least, that's my judgment of the balance between usability and security for the browsable Web)
darobin: DAP rule for FPWD: is it reasonable feature complete for patent exclusion process. We don't have a timeline for our release.
... we will have a better idea when we've had the layering discussion with File API
<shepazu> [ mjs : okay, yes, that seems totally sensible... thanks for the clarification]
darobin: FPWD *could* be in Dec/Jan but no commitment to that
<michaeln> sorry for talking out of q order... didn't realize there was such a thing
slewontin: discussed earlier that it's sensible to distiguish between implicit and explicit permissions declaration in APIs
<shepazu> [mjs: in fact, maybe it should be explicitly handled by the browser's file save handler]
slewontin: makes sense as a good place to start
... However, File API has no security considerations in it. Would be helpful to take security aspects and create a Security Considerations section in File API
<shepazu> [... as opposed to allowing "cool" custom file dialogs]
<mjs> shepazu, right, the file save dialog would have to be trusted UI provided by the browser
<Zakim> ifette, you wanted to say that we need simplicity, but we don't want two totally separate APIs depending on where i want to store a file
<arun> ACTION: Arun to write up security considerations section of existing File API spec. in preparation for FPWD [recorded in http://www.w3.org/2009/11/02-dap-minutes.html#action05]
<trackbot> Created ACTION-40 - Write up security considerations section of existing File API spec. in preparation for FPWD [on Arun Ranganathan - due 2009-11-09].
Ian: e.g. would like to delegate trust to a page/domain such as facebook. May require different APIs. If they have to be different we should have good reasons why.
<dom> WebApp’s WG coordination wiki
sicking: you can trust a page to read file system. would be hard to delegate trust.
<darobin> ACTION: ifette to start drafting a unitarian file API [recorded in http://www.w3.org/2009/11/02-dap-minutes.html#action06]
<trackbot> Created ACTION-41 - Start drafting a unitarian file API [on Ian Fette - due 2009-11-09].
<shepazu> [I think maybe it would be good for the webapp to be able to provide a filename and default file extension/mimetype, then based on user prefs, the browser may pop up its native file dialog (a black box to the webapp), then passes back an opaque abstract hook that the webapp to write to (within some filesize limits)]
<dom> [browsers already have "downloaders" UIs]
<Zakim> chaals, you wanted to note that we have *browsers* that ask if we want to follow a link, specifically for trust reasons.
chaals: there is an industry intiative around safe browsing. e.g. this site is safe/ this site is not safe
<weinig> [I think that any specification that defines how one can write to a File object, needs to be dependent on another spec which allows for File objects to be saved to the file system]
<mjs> weinig, I assume you mean a mechanism for the user to choose a file to write to
<weinig> mjs, I do
sicking: we have warnings that things are unsafe....not any safe guarantee
<mjs> and yeah, I agree, the File API for reading can free-ride on <input type="file">, but there's nothing predefined for writing
hixie: we do have opt-in to trust in widgets. i.e. do you trust this site?
<shepazu> mjs: yes, users would "get" that they can select a save location with a file dialog, but we should also allow the API to be used outside that model as well
drogersuk: disagrees. If I've sideloaded a widget. no idea where it's from therefore no implicit trust
... widgets not fundamentally different to web sites
<chaals> [this isn't a case of one side is trusted and one is not - there are levels of (dis)trust, which are different, but in amount of distrust not fundamentally based on a difference of nature]
drogersuk: contents of a widget are effectively a web site.
<shepazu> [agree... we need more than a CYA for "trust decisions"]
hixie: web security model doesn't work in this case. it's an uninformed decision for the user
tlr: difference is when that decision is made.
drogersuk: for consistency we should only have 1 API.
<JereK> [might be useful to distinguish a 'simple file reader API for just browsers' from a 'more elaborate file system API that allows a widget to provide file open / save dialogs and read / write files as in a desktop app' - the latter has more extensive security implications]
Arun: web has an API in at least 2 browsers: geolocation. raises user facing message
... suggested before that these messages may want to be implemented async / non-blocking
<chaals> [I wonder how Hixie imagines the UI for selecting a filesystem, as compared to that for selecting a particular file to read. That might be a bigger issue than it seems in resolving this deadlock (since as far as I can say we are saying a lot of the same things, which lead us along the same lines to the opposite conclusions :( ) ]
<mjs> chaals, there should be no UI for selecting a filesystem
Arun: other APIs on the web should be async / non-blocking. Even then, it's very hard for users to make informed desicions on the messages presented
<JereK> [the extent of the security implications depends on the origin of the (web)app]
slewontin: APIs don't say anything about Policies. API and Policies are orthogonal
<chaals> [mjs why not?]
darobin: would like to get people to discuss on the mailing list(s)
<mjs> chaals, a user can make a reasonably informed decision to open/upload a file or save to a file, but realistically a user can't make an informed decision to give a webapp the run of a whole section of the filesystem - and the potential consequences are really terrible
hixie: until there is a UI for providing informed trust decisions, not interested in a policy model.
<Hixie> IH: until we have a UI for the security policy layer that results in users making informed trust decisions, i do no think we use that on the web
<Hixie> do not think we can use that, even
<tlr> hixie's earlier note: http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0133.html
Bryan: agree consistent user experience. policy author can choose level of permissions required. Avoid user needing to make explicit decisions
... we have an equivalent capability in BONDI. would like discussion on where that is weak.
<fhirsch> I think Hixie's earlier message is a different discussion, it was argument against blocking dialogs. Isn't the question now about enabling policy in general and why isn't that possible with approaches suggested in that email?
<Bryan> bryan: I agree there should be a consistent user experience, and one that does not depend upon explicit opt-in on every filesystem access, e.g. by selecting a file through a file selector (even though this appears to be implicit). The policy framework should enable equivalent security of filesystem access via native methods, in both browser and widget contexts. As currently supported in BONDI, the policy author can choose the level of permissions based upon sensi
<Bryan> tivity of filesystem access in the different contexts. This can prevent the user from needing to make adhoc security decisions as the evidence supporting trust is specific and reliable in both browser and widget contexts, and is expressable in the policy.
marcin2: in a layered model. we can have some APIs not covered by any security policy. File System API could be secured by security policy
speaker?
<marcin2> richt: sure
<chaals> rob, intel
<Marcos> darobin: webnotifiwhhhat? :P
<marcin2> We have at least 2 architectures to handle API and security policy.
rob: perhaps we don't want a file system API at all considering the inherent security issues
<fhirsch> suggestion made not to have File API at all, rather just have shared data API etc
<sicking> i sort of agree
<marcin2> The first one is to have on set of APIs and related security policy.
<slewontin> Whether you have a policy mechanism or not you still have policy, its just implicit rather than explicit
<fhirsch> issue: is File API appropriate abstraction/interface
<trackbot> Created ISSUE-40 - Is File API appropriate abstraction/interface ; please complete additional details at http://www.w3.org/2009/dap/track/issues/40/edit .
marcos: HTML5 originally had web notifications framework but not much interest so removed
<marcin2> The second architecture is to have an API (e.g. FileAPI as it is now) not to be governed by the security policy at all together with the complementary API that is governed by the security policy.
<dom> right, but the debate is whether you want to allow for an explicit policy mechanism
marcos: tried to revive it.
... from opera, we've explored soft notifications (non modal) - accumulative notifications
... took notifications out of widgets interface spec. want it to be seperate and make it work with the wider web
... clean slate...where do we go from here?
<chaals> [/me notes that ARIA also has a concept of notifications, although within a web app - aria-liveregion and friends]
John, Google: draft proposal submitted on how we could move forward on the spec
John Gregg, Google: do we want to look at it
marcos: sure
<marcin2> arun: "policy file" is just representation of the policy, specifically for its exchange
<AnssiK> I listed related prior art in this mail http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0172.html
John_Gregg presents his proposal on moving forward on web notifications
darobin: will this proposal be in Chrome?
<tlr> http://dev.chromium.org/developers/design-documents/desktop-notifications/api-specification
johnnyg: yes. it's in Chrome
marcos: removed from widgets because it has a wider context
darobin: this shows interest from browser vendors. comfortable going ahead with the work
... where? put it in DAP?
Ian, Google: where can it move quickly and gain adoption?
<johnnyg> this is John, btw
s/John Gregg:/johnnyg:/
fhirsch: question on Google proposal: what's the security proposal
johnnyg: noone can show notifications unless you've allowed it. If you show a notification there must be a way of revoking permission from the UI itself
<tlr> johnnyg, have you thought of security considerations around rate limiting this piece?
ArtB: would be good to have a show of hands of proposed participation in this work
a few hands in the air. there is interest in particpation in this
dom: this is not currently part of DAP charter.
... DAP may need rechartering
Ian, Google: perhaps it doesn't need to be a Device API
chaals: is it in the webapps charter?
shepazu: could be interpreted to be in webapps charter
<anne> http://www.w3.org/2008/webapps/charter/ search for "platform"
chaals: who's going to edit the spec?
johnnyg: us. webapps makes sense to me.
chaals: let's do this in webapps then
<slewontin> ScribeNick: slewontin
<fhirsch3> jim outlined architecture on white board - interaction manager and modal itnerfaces
Jim Barnett: presents MMI architecture
Frederick: asks where the architecture lives. Components can live wherever they are most efficiently implemented: on the device, in the net, etc.
Robin: asks how multimodal interaction is choreographed. Answer is that this is the job of the Interaction Manager
Frederick: asks how related to XProc(?) Answer could be used as interaction manager
Jim Barnett: events are very generic, not mode specific
Frederick: the topic of interest here is how this relates to Device APIs. Answer is that modality components may use device APIs
... seems that device API not directly related to MMI
Debbie: Do we need a tutorial on Device APIs? Robin describes DAP work at a high level: security policy and set of APIs
Frederick: DAP will produce APIs which MMI might want to use.
Debbie: Need to make sure that there is nothing in DAP that conflicts with the MMI model. One important issue is that MMI is entirely async. Another is that APIs need XML representation.
Robin: Async should not be an issue. In terms of XML, we are mostly thinking at API level, but in most cases not data formats.
... we would typically use DOM 3 events.
We are still at the point of deciding whether we need policy and how policies would be processed. We are not at the level of specifying, for example, security related events that could be fit into the MMI model.
Raj(?): Security is an issue for MMI, but MMI does not define security policies.
?: main security issue in MMI is security of events between modalities rather than within modalities. Since the architecture is distributed and may be distributed over more than one document, we can't just use DOM3 events.
Previous comment from Micheal B(?) of MMI wg.
Frederick: seems like XML security is a more appropriate place for this.
Michael: from device API perspective mainly interested in things like what device features are available for input.
<darobin> System Info: http://dev.w3.org/2009/dap/system-info/
Debbie: presents use case
<fhirsch3> example - use camera api to take picture as a modality component
Robin: asks if there are implementation that would allow you to write an MMC in JavaScript. This would be most relevant to DAP
Raj: Yes this could be done. Michael: but of course the app might not all be in a single JS context.
Robin: the use case is for developers to define an MC in content
Michael et al: context and language independent.
Frederick: DAP model assumes that APIs are invoked in a known context (e.g. widget with known credentials)
<fhirsch3> note that DAP apis assume invocation environment in web applications or widgets, so may not fit arbitrary invocation environment
<fhirsch3> potential issue might be security enforcement mechanism
Robin: so this might be an issue for security and user granting of permissions
<fhirsch3> robin notes user interaction model may also have impact, e.g. ui to take picture
<fhirsch3> example use case - see webcam at home, take picture of intruder in house
Frederick: MC could be any arbitrary code, could run anywhere. This won't work with a security model that makes certain assumptions about the environment in which caller runs.
<AnssiK> JereK, what about the user interaction API mentioned in the policy, we had discussion earlier on alignment with the HTML5 menu element
<AnssiK> JereK, here's a link to the discussion http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0207.html
Frederick: use of DAP APIs in another context than Web is a new topic.
<fhirsch3> dom notes that only web security context is is dap scope
<fhirsch3> stephen notes that any application can write javascript binding to use dap api
dom: Its not that we won't take into consideration the MMI model, but we won't take this actively into account. If MMI finds issues with our model, they should provide input about this.
Frederick: we need to get input on requirements for DAP apis from MMI
<fhirsch3> issue: include MMI in DAP specification reviews, including APIs and security
<trackbot> Created ISSUE-41 - Include MMI in DAP specification reviews, including APIs and security ; please complete additional details at http://www.w3.org/2009/dap/track/issues/41/edit .
<fhirsch3> issue: able to use of MMI for user interactions
<trackbot> Created ISSUE-42 - Able to use of MMI for user interactions ; please complete additional details at http://www.w3.org/2009/dap/track/issues/42/edit .
<dom> close ISSUE-41
<trackbot> ISSUE-41 Include MMI in DAP specification reviews, including APIs and security closed
Robin: one important conclusion is that MMI should review DAP specs.
<darobin> ACTION: Robin to make sure that MMI is kept abreast of our work [recorded in http://www.w3.org/2009/11/02-dap-minutes.html#action07]
<trackbot> Created ACTION-42 - Make sure that MMI is kept abreast of our work [on Robin Berjon - due 2009-11-09].
<scribe> ACTION: Robin to forward specs to MMI [recorded in http://www.w3.org/2009/11/02-dap-minutes.html#action08]
<trackbot> Created ACTION-43 - Forward specs to MMI [on Robin Berjon - due 2009-11-09].
<darobin> MMI's work: http://www.w3.org/2002/mmi/Group/#Specs
<fhirsch3> issue was calling DAP API from non web application , e.g. native code Multimedial component
<fhirsch3> deborah - another example on non-web context might be calendar running on a server
<fhirsch3> robin notes that web page doing access makes it in web context
<drogersuk> Food: http://westfield.com/valleyfair/dining/
<timeless> ScribeNick: timeless
<scribe> Scribe: timeless
AB: highlights agenda
FH: we might drop the second item into the next time slot (pending Hixie)
AB: some of these warp spec items might be already resolved
... status?
RB: I believe i've addressed all the comments i've received ...
... we will probably need a round of review
... the big issue that remains is UPnP
... LAN
Suresh: asking about last calls
RB: we'll need another LC, so yes, we're taking comments
AB: Quick review/summary...
... this is the only section of widgets which relates to policy and thus DAP
RB: the goal of widget access is to create the simplest policy, to avoid conflicting with DAP
... the goal is to enable widgets to specify resources they need to access
... the policy is fairly straightforward. basically there are features that can be enabled in a widget
... There's a widget execution scope: APIs available to the widget's code
... There's an external execution scope: This doesn't have access to granted APIs
... there is a concern. Code loaded off the network can be loaded in the widget's running scope.
... Finally, things which are external to a widget need to be enabled by the <access> element.
AB summarizes Widget Access 5.1
MC: when did pattern change to origin?
(s/AB summarizes/RB summarizes/)
RB: there was discussion on the list, it was made to match CORS
... I'm open to changes, I don't care
MC: I'm surprised, because it wasn't something we were thinking of when we originally wrote it out.
... I don't have an opinion at this time.
RB: before we go to another LC, i'd like to ask the WG to review it
I created an action against ArtB
Suresh: thanks Robin. In general, I think we're supportive
... I heard it mentioned as linked to "feature", but i didn't see it mentioned in the document
... Currently Feature and Access are not tied together
MC: This reminds me of what RIM did ...
Suresh: Based on a per domain basis, you want to be able to load modules or not
... for all the access elements, I would just load all the features or not
... in terms of linking them, I think we have the bits to do it
MC: it was mentioned that network access could probably be a feature
RB: The goal of the spec was to stay very simple
... everything that will add will have a high cost
Suresh: What are you asking for?
RB: It would need to be shown to be very important
Suresh: I would have to provide use cases explaining how it would make sense?
AB: and the best scenario is that the feedback would be before the 19th
RichT: what about redirects?
<Suresh> To clarify - we think there is a value to link the <access> and <feature> elements
RB: If you grant access to a.com; a.com redirects to b.com
... it depends on whether redirects are allowed from a.com to b.com
RichT: I'm afraid that the domain owner might change
Benoit: Another way to put this is that a.com is an umbrella
<dom> [I'm not sure we should discuss these details now in the joint meeting; but it seems at least that this ought to be clarified in the spec]
Benoit: behind a.com is redirects to b/c/d.com
RB: my pushback on that is that you're asking for extra complexity in the spec
... there are already ways to do that with dns, server side proxying, etc...
Benoit: So we specify that in the spec
[by example?]
RB: we're not going to list for every single protocol everything that you must not do
<fhirsch3> +1 to keeping complexity low
DOM: It's not clear what are the limits for a network request
... I assume that HTML5 has origins already defined
RB: the same thing applies with XHR
... If you ask for something from your domain and it redirects you. You're in trouble.
... Please file a comment to the mailing list before Nov 19
Marcin: I'm not sure where the changes are
RB: everywhere
AB: everywhere
Marcin: What is the main change?
[substantive change]
RB: pretty much everything has been rewritten
--- we lost power in the room ---
<dom> XmlHTTPRequest defines what is to be done with HTTP Redirects: http://www.w3.org/TR/XMLHttpRequest/#infrastructure-for-the-send-method
<dom> (importing presumably the "same-orgins rules" from HTML5)
RB: the entire processing system was changed
... the rules for matching were changed
... the rules for origin ....
Marcin: I ranged a concern about mailto: / sms:
... in DAP we're going to work on APIs that access mails...
RB: that's completely outside the scope of WARP
[RB points to the explicit exclusion in the spec]
RB: if there's a scheme that lets me load an SMS into an iframe.. fine.. why should it be forbidden?
Marcin: We are thinking about retrievable resources
<timeless_scribe> [ mailto: isn't a retrievable resource]
<marcin> is "retrievable resource" defined somewhere?
Bryan: If I need to grant access, i need to grant once for http, and once for https?
RB: yes
<marcin> Is 200 OK + Content-Lenght: 0 a resource?
Bryan: If I want to access everything over http and only some things over https, there's no easy way to do it?
RB: correct
<dom> [a spec always define arbitrary semantics, doesn't it?]
RB: We're trying not to create a technically complex spec to solve use cases we believe are in the minority
Bryan: The statement about "any linked resources" ...
<dom> [rfc 2396 uses the phrase "network retrievable"; I don't know if it defines it]
Bryan: like subdomains, we should have a way to specify some limited set of resource types
<fhirsch3> s/Lenght./Length/
Bryan: So I could say "images are ok from everywhere", but "scripts are only ok from some places"
RB: say I grant access to images. And the server redirects the image to image?some-javascript
... the widget can retrieve the uri and evaluate the javascript
Bryan: So is that normal?
RB: No, but a widget / js can do it
... Also, SVG is an "image", but it regularly will execute/embed scripts
<paddy> I will be shortly
<timeless_scribe> [ we got power back - thanks ]
<paddy> For the policy agenda item, 10 minutes?
AB: Bryan: please send comments to the mailing list
FH: I'm waiting for Ian before we talk about ...
<JereK> [Marcin, seems like you'd want to restrict/allow access to resources by content type - worth the complexity?]
<darobin> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0011.html
Marcin: In UPnP, the environment is completely different
... there are no domain names, just ip addresses
RB: the issue is that local ip ranges cover millions of IPs
AB: so, do we want to support these?
<AnssiK> for private address space, see 3. section http://tools.ietf.org/html/rfc1918
Marcin: UPnP ~ DLNA
... we are able to determine that DLNA is "local network"
... for BONDI we ...
... there are use cases where you can virtually download images, and then upload them to some network
<darobin> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0372.html
Marcin: I think this is covered in my email messages
... I think multicast is covered by DLNA
RB: could this be covered by a new attribute?
... I'm trying to divide up the work so that we can ship stuff
... I'm not saying this isn't something important for some people
... There are two ways to do this
... either there's a separate spec that defines a delta to WARP
... or it's a new version for WARP
AB: what can you specify and bring as input within 2 weeks
FH: if it has consensus and is available within 2 weeks
Marcin: an attribute [localonly/allow local]
tlr: How does this scale to IPv6?
... I'm vehemently opposed to anything that relies on the specific 192./similar
... I think you're on a very dangerous path here. don't do it
Marcin: I think DLNA only runs on ipv4
... it will live much longer in home networks
AB: we need to wrap up
... thanks Robin, Frederick
<dom> "The future transition from IPv4 to IPv6 will be handled in the DLNA Networked Device Interoperability Guidelines in a manner that enables devices based either on IPv4 or IPv6 to work well together." http://www.dlna.org/industry/why_dlna/key_components/network/
FH: can you be both on the lan and internet at the same time...
scribe is leaving
RB: thanks scribe
<darobin> Hixie, you wanna come over?
<Claes> scribe Claes
<dom> ScribeNick: Claes
Reviewing comments by Laura_Arriba
Paddy on the phone
Defintions, device capability editorial
<JereK> http://dev.w3.org/2009/dap/policy-reqs/
<dom> Laura’s comments
<paddy> It's very hard to hear
Device Capability defintion mapping to Features. Get defintion of Features more elaborate
Get wording right
<dom> (I don't think the notion of strings should appear in the policy requirements, really)
Laura: Paddy's defintion in later email is more accurate that the current one
Above refering to def of Feature
<Bryan> http://bondi.omtp.org/1.1/CR/
<dom> BONDI Architecture and Security 1.1
Laura: Policy def Reqs: 2nd bullet: Unclear what flexibility means
<dom> "A Feature corresponds to specific functionality provided by a Web Runtime,
<dom> made available by a defined set of Web Runtime behaviours and JavaScript
<dom> interfaces
<dom> "
fhirsch: Who writes the policy?
<dom> [I think the key question is not whether policy is needed, but whether interoperability on policy definition/processing is needed]
Marcin: Differ between presentation of policy and who writes it
Fhirsch: Who are the actors?
Paddy: Agrees with fhirsch
<dom> [this suggests we need detailed use cases]
Bryan: Doesn't consider this an issue. The are a number of ways policies can be originated. We can and should what to do in the event of no policy but should not define who creates the policy
Marcin: Absence of a policy is a policy
<JereK> [if policy file is absent, does that mean there is a default policy?]
<fhirsch3> dom notes that if interoperability is not important then perhaps DAP does not need to define policy mechanisms
<fhirsch3> we need detailed use cases to understand who the actors are and the flows
Dom: Need to define detailed use cases and clear actors
<fhirsch3> +1 from stephen to Dom
Steve: Someway to guarantee that SW is consistent. Comapre with MIDP, every op has a different model for signing creating interop problems.
... We should issue policy recommendations
... There is no point in std policy if we don't achive consistent behaviour between platforms
Fhirsch: Need use cases and actors
<dom> [the question is not whether you *can* achieve interoperability, but whether it is needed]
Bryan: Believs there is way to define policy. We done that in Bondi. Don't ignore the problem. The policy does need to be defined and policy processing has to be defined
... Believs there is way to define policy. We done that in Bondi. Don't ignore the problem. The policy does need to be defined and policy processing has to be defined
Where can a explicit user action be consent?
Bryan: In the developing process the policy has to be defined
<fhirsch3> need use cases, look at enforcement
<fhirsch3> suresh notes requirements before use cases might be premature
<dom> [in particular, we need someone to take an action item to start with use cases]
Suresh: We have to step back. Policy user context or eg widget context
<Hixie> darobin, sorry, ended up in i18n. still need me today?
Steve: Agree on IOP goal. However, not efficient to discuss policy language and policy processing
<fhirsch3> dom notes declaring intent to use features is important
<fhirsch3> dom also notes subsequent action whether user consent or policy enforcement is another question
<fhirsch3> dom not clear we need format around policy and need for interop on this
<slewontin> The main value to specifying a policy standard is that it enables an ecosystem in which Web apps and widgets have consistent behavior across many devices.
<darobin> Hixie, it'd be nice if you could come over yes
<fhirsch3> laura notes letting developer write policy can be risky if they are writing malware
<slewontin> Having an interoperable policy spec is a necessary but not sufficient condition for such consistency.
Laura: Can't always let the developer create policies.
Bryan: Need a system to manage trust
<Hixie> darobin: k, omw
<JereK> [so dev says what they want to use, policy says what they can use - but for dev to write policy is meaningless]
Laura: Developer can not define the features his/her app has access to
Fhirsch: Bring Hixie in and contiue with Laura's comments
<Suresh> I agree with what dom said before on the layered apporach i.e. a part where the developer provides an intent by declaring access and feature and the other part where you enforce a policy on top of that
<dom> ACTION: Bryan to offer use cases of policy interoperability needs [recorded in http://www.w3.org/2009/11/02-dap-minutes.html#action09]
<trackbot> Created ACTION-44 - Offer use cases of policy interoperability needs [on Bryan Sullivan - due 2009-11-10].
Laura: Developer can define which features that are requested but not which features hat are allowed to access
<richt> let's keep the use cases simple if possible
<dom> (simple but clear on who's involved)
<richt> dom, agreed
Hixie joined
<fhirsch3> goals - understand basics of model, what is important to DAP, evolution
<paddy> yes, thnx
<dom> [another possible question: the role/formalization of the top frame in access to special APIs]
Hixie: Several aspects to security in HTML5. Biggest pattern used same origin, i.e. scheme, host name or a port. A script is allowed to access only same origin. Generally a script pointing to another domain is not ok.
... Issues wtih images...Cross origin scripts is a secuirty problem.
... Can make the security even worse due origin model (did catch Hixie's example)
... Issues with files, e.g. with drag and drop.
... Origin header contains origin of request in XHR. Manipulation of origin header
scribe needs 2 mins pause
<dom> Anssik: how can we apply this origin model to widgets?
scribe back
<dom> ... could we leverage the Origin header in the context of widgets?
<dom> Adam Barth
Hixie: Talk to Adam Bart about origin header
<dom> "top level browsing context"
<dom> "first script" is the script at the bottom of the call stack
<dom> + "origin" concept
Hixie: Using HTML 5 top level browser concept, orign concept, first script (script in bottom of call stack) concept etc...
Bryan: No of uses cases that expect automatic action
Hixie: E.g. once granted access to files to a web site this can be remembered
... Explicit user action can be long-lived
<Zakim> dom, you wanted to ask about API design anti-patterns
<Bryan> Bryan: some use cases benefit from automated file storage based upon initial explicit consent or implicit consent, e.g. based upon trust in the webapp source
<fhirsch3> + privacy
Hixie: Major principle: Don't rely on a modal prompt
... Design according to a speciifc mode of operation in mind but do not mandate it
<paddy> fhirsch, will you be continuing with agenda items 9c, 9d or finishing after this item?
