W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2009

revised minutes 2009-11-02 DAP F2F day 1

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Tue, 3 Nov 2009 17:06:44 -0800
Message-Id: <F88E7FB4-976C-40E5-994F-886275B7E7A5@nokia.com>
To: W3C Device APIs and Policy WG <public-device-apis@w3.org>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>
revised minutes 2009-11-02 DAP F2F day 1. corrected Eric Uhrhane's name

regards, Frederick

Frederick Hirsch

# Device APIs and Policy Working Group F2F Day 1

## 02 Nov 2009


See also: [IRC log][4]

## Attendees


    Dominique_Hazael-Massieux, Laura_Arribas, Ian_Hickson, Thomas_Roessler,
DanielColoma, Marco_Marengo, Claes_Nilsson, Kangchan, Richard_Tibbett,
Marcin_Hanclik, JonathanJ, Anssi_Kostiainen, Robin_Berjon, Steve, Lewontin,
Wonsuk_Lee, David_Rogers, Niklas_Widell, Noah, Mendelsohn, Ingmar_Kliche,
Ashok, Laszlo_Gombos, Paddy_Byers, Chaals, (Webapps), ArtB, SamW, (WebApps),
ifette_(DAP, webapps), sicking_(webapps, mozilla), Josh, Soref, BryanSullivan,



    Frederick_Hirsch, Robin_Berjon


    Bryan, richt, Richard, timeless

## Contents

  * [Topics][5]

    1. [minutes approval][6]

    2. [update to contacts API][7]

    3. [Policy Requirements][8]

    4. [policy requirements draft][9]

    5. [File API][10]

    6. [Web Notifications][11]

    7. [MMI/DAP WG joint meeting][12]

    8. [Multi Modal Interaction][13]

    9. [Policy requirements][14]

    10. [HTML5 Security Model][15]

  * [Summary of Action Items][16]

* * *

<trackbot> Date: 02 November 2009

<dom> Scribe: Bryan

<drogersuk> BONDI 1.1 Candidate Release today: [http://bondi.omtp.org][17]

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-

<darobin> (direct link to BONDI 1.1 CR: [http://bondi.omtp.org/Documents/CR1.1

Resolution: minutes of 28t Oct are approved

### update to contacts API

<fhirsch> [http://lists.w3.org/Archives/Public/public-device-

<drogersuk> [http://bondi.omtp.org/1.1/CR/][21]

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

### Policy Requirements

<darobin> live updated agenda, together with scribe slots:

<scribe> new topic: policy requirements draft

### policy requirements draft

<dom> [Device API Policy Requirements draft][23]

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.

<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][24]

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-

<Laura_Arribas> [Laura’s comments on policy requirements][26]

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

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

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

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

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

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

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

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

<fhirsch> anssiK asks about domain based trust

AnssiK: is a domain based model included ?

<fhirsch> see [http://www.w3.org/2008/security-

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

... thus we need to be clear on where we are limited to the model provided by

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][29]

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

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

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

<scribe> **ACTION:** claes should issue recommendation on the granularity of
the security system [recorded in [http://www.w3.org/2009/11/02-dap-

<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/][33]

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

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][33]

Arun: discusses the individual components of the File API spec.

<darobin> the Blob API:

<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

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][34]

mjs: the write handle should be different to the read handle for the file

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


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][34]

<dom> [BONDI Filesystem API][36]

<anne> youwant [http://dev.w3.org/2009/dap/file-system/][37]

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][38] (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][39] )

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

<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

<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

<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

<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

<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

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

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

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

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

<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

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

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

<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

<trackbot> Created ACTION-40 - Write up security considerations section of
existing File API spec. in preparation for FPWD [on Arun Ranganathan - due

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][46]

sicking: you can trust a page to read file system. would be hard to delegate

<darobin> **ACTION:** ifette to start drafting a unitarian file API [recorded
in [http://www.w3.org/2009/11/02-dap-minutes.html#action06][47]]

<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

... suggested before that these messages may want to be implemented async /

<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

slewontin: APIs don't say anything about Policies. API and Policies are

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

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


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

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

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

John Gregg, Google: do we want to look at it

marcos: sure

<ArtB> [http://sites.google.com/a/chromium.org/dev/developers/design-documents

<marcin2> arun: "policy file" is just representation of the policy,
specifically for its exchange

<AnssiK> I listed related prior art in this mail

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-

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

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/][53] 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

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

?: 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/][54]

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

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

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

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

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

<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][58]]

<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

<trackbot> Created ACTION-43 - Forward specs to MMI [on Robin Berjon - due

<darobin> MMI's work: [http://www.w3.org/2002/mmi/Group/#Specs][60]

<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/][61]

<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

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

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

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

<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

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

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

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

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-

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

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

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/][23]

<dom> [Laura’s comments][26]

<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/][21]

<dom> [BONDI Architecture and Security 1.1][67]

Laura: Policy def Reqs: 2nd bullet: Unclear what flexibility means

<dom> "A Feature corresponds to specific functionality provided by a Web

<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

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

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

<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][68]]

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

<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

... Issues with files, e.g. with drag and drop.

... Origin header contains origin of request in XHR. Manipulation of origin

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?

## Summary of Action Items

**[NEW]** **ACTION:** Arun to write up security considerations section of
existing File API spec. in preparation for FPWD [recorded in

**[NEW]** **ACTION:** Bryan to offer use cases of policy interoperability
needs [recorded in [http://www.w3.org/2009/11/02-dap-

**[NEW]** **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

**[NEW]** **ACTION:** chaals to shepperd the discussion on File API, Reader,
Writer, FS Browser layers; collecting use cases [recorded in

**[NEW]** **ACTION:** claes should issue recommendation on the granularity of
the security system [recorded in [http://www.w3.org/2009/11/02-dap-

**[NEW]** **ACTION:** ifette to start drafting a unitarian file API [recorded
in [http://www.w3.org/2009/11/02-dap-minutes.html#action06][47]]

**[NEW]** **ACTION:** Robin to check that Chaals shepperds the discussion on
file API, Reader, Writer, FS Browser layers; collecting use cases [recorded in

**[NEW]** **ACTION:** Robin to forward specs to MMI [recorded in

**[NEW]** **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][58]]

[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][69] version 1.135 ([CVS

$Date: 2009-03-02 03:52:20 $

   [1]: http://www.w3.org/Icons/w3c_home

   [2]: http://www.w3.org/

   [3]: http://lists.w3.org/Archives/Public/public-device-

   [4]: http://www.w3.org/2009/11/02-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #item07

   [13]: #item08

   [14]: #item09

   [15]: #item10

   [16]: #ActionSummary

   [17]: http://bondi.omtp.org

   [18]: http://lists.w3.org/Archives/Public/public-device-


   [20]: http://lists.w3.org/Archives/Public/public-device-

   [21]: http://bondi.omtp.org/1.1/CR/

   [22]: http://www.w3.org/2009/dap/wiki/F2F_Agenda_2-3_November_2009%2C_TPAC/

   [23]: http://dev.w3.org/2009/dap/policy-reqs/

   [24]: http://www.w3.org/mid/59db1b5a0911020854o3f14f88bsb7339ce88a3b98ca@ma

   [25]: http://lists.w3.org/Archives/Public/public-device-

   [26]: http://lists.w3.org/Archives/Public/public-device-

   [27]: http://www.w3.org/2009/dap/track/issues/35/edit

   [28]: http://www.w3.org/2008/security-ws/papers/SecurityPolicyNokia.pdf

   [29]: http://lib.tkk.fi/Dipl/2009/urn100073.pdf

   [30]: http://www.w3.org/2009/dap/track/issues/36/edit

   [31]: http://www.w3.org/2009/dap/track/issues/37/edit

   [32]: http://www.w3.org/2009/11/02-dap-minutes.html#action01

   [33]: http://dev.w3.org/2006/webapi/FileAPI/

   [34]: http://www.w3.org/TR/dap-api-reqs/#file-system


   [36]: http://bondi.omtp.org/1.1/cr/apis/filesystem.html

   [37]: http://dev.w3.org/2009/dap/file-system/

   [38]: http://bondi.omtp.org/1.01/apis/filesystem.html


   [40]: http://www.w3.org/2009/11/02-dap-minutes.html#action02

   [41]: http://www.w3.org/2009/11/02-dap-minutes.html#action03

   [42]: http://www.w3.org/2009/11/02-dap-minutes.html#action04

   [43]: http://www.w3.org/2009/dap/track/issues/38/edit

   [44]: http://www.w3.org/2009/dap/track/issues/39/edit

   [45]: http://www.w3.org/2009/11/02-dap-minutes.html#action05

   [46]: http://www.w3.org/2008/webapps/wiki/Coordination

   [47]: http://www.w3.org/2009/11/02-dap-minutes.html#action06

   [48]: http://lists.w3.org/Archives/Public/public-device-

   [49]: http://www.w3.org/2009/dap/track/issues/40/edit

   [50]: http://sites.google.com/a/chromium.org/dev/developers/design-

   [51]: http://lists.w3.org/Archives/Public/public-device-

   [52]: http://dev.chromium.org/developers/design-documents/desktop-

   [53]: http://www.w3.org/2008/webapps/charter/

   [54]: http://dev.w3.org/2009/dap/system-info/

   [55]: http://lists.w3.org/Archives/Public/public-device-

   [56]: http://www.w3.org/2009/dap/track/issues/41/edit

   [57]: http://www.w3.org/2009/dap/track/issues/42/edit

   [58]: http://www.w3.org/2009/11/02-dap-minutes.html#action07

   [59]: http://www.w3.org/2009/11/02-dap-minutes.html#action08

   [60]: http://www.w3.org/2002/mmi/Group/#Specs

   [61]: http://westfield.com/valleyfair/dining/

   [62]: http://www.w3.org/TR/XMLHttpRequest/#infrastructure-for-the-send-

   [63]: http://lists.w3.org/Archives/Public/public-

   [64]: http://tools.ietf.org/html/rfc1918

   [65]: http://lists.w3.org/Archives/Public/public-

   [66]: http://www.dlna.org/industry/why_dlna/key_components/network/

   [67]: http://bondi.omtp.org/1.1/cr/security/BONDI_Architecture_and_Security

   [68]: http://www.w3.org/2009/11/02-dap-minutes.html#action09

   [69]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

   [70]: http://dev.w3.org/cvsweb/2002/scribe/

Received on Wednesday, 4 November 2009 01:07:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:13 UTC