Device APIs and Policy Working Group F2F Day 1 -- 02 Nov 2009

<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

minutes approval

<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

update to contacts API

<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

Policy Requirements

<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

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

File API

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

Web Notifications

<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

<ArtB> http://sites.google.com/a/chromium.org/dev/developers/design-documents/desktop-notifications/api-specification

<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

MMI/DAP WG joint meeting

<slewontin> ScribeNick: slewontin

Multi Modal Interaction

<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

Policy requirements

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

HTML5 Security Model

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?

- DRAFT -

Device APIs and Policy Working Group F2F Day 1

02 Nov 2009

Attendees

Contents