SysApps -- 09 Apr 2013

<chaals> scribe: Chaals

WL: We haven't met each other yet, so this is a good time to introduce ourselves to each other.

… I am Wonsuk LEE, from Samsung. I lead W3C activity in Samsung

<DKA> Is there an audio bridge?

DC: Diana Cheng, Vodafone, also work on DAP

??: HuaWei

ML: Mounir Lamouri, Mozilla

EF: Eduardo Fuller, Telefonica, involved on FirefoxOS project, ...

… editing some APIs in this group

<DKA> Hi folks - this is Dan from Telefonica. I'm not in the room today but I will be joining in person tomorrow. I'm the AC rep for Telefonica and as some of you know I've been playing a role in web standard

CN: Claes Nilsson, SOny

KC: Kenneth, Intel.

<DKA> ...s for a while. Looking forward to meeting you all tomorrow.

MJ: Min Jin, Tizen platform

JS: Jan, Samsung

Josh: RIM/Blackberry (not an official member). WOuld be scribing...

ZK: Zoltan, Intel

CMN: Chaals, Yandex, webapps, ...

TS: Tomoyuki-san, KDDI

KT: Koichi, KDDI, working on FirefoxOS

MC: Marcos Caceres,don't have a proper job

Chris: Chris, working for samsung

???: Gemalto. First time in this activity

AK: Anssi, joined Intel last week after working on DAP for Nokia for years.

<dsuwirya> Darmawan Suwirya - Gemalto ... :)

SP: Sakari, Intel

G?: Gary, Qualcomm

?K: Kim, ETRI

DR: Dave Raggett, W3C

JL: John Lyle, security researcher at Oxford

JS: Jon… Samsung?

Laszlo: Samsung

MT: Mikko Terho, Huawei

s/Jon.../Jung/

DSR: Need a microphone so DKA can hear

CMN: No we don't.

<DKA> :)

<spoussa> chaals: Jungkee

<DKA> Hearing is overrated.

<gmandyam> gmandyam = Giri Mandyam, Qualcomm Innovation Center

KF: Kui Feng, Mozilla

PM: Phil, Adobe - phonegap n stuff

<filmaj> not to be pick but.. Fil

T: Telefonica

JC: Jose Cantera, Telefonica

GL: Gene Lian

Hsin-Yi Tsai: Also mozilla Taipei

JS: Jonas Sicking, Mozilla.

MP: Milan, Huawei.

JJ: Jonathan Jeon, ETRI Korea

SC: Suresh Chitturi, RIM

<mounir> chaals: you missed Gene Lian too

AM: Alexandre Morgaut, 4D

KL: Kevin Lin, 4D

[Scribe apologises to everybody whose name got messed up.]

Agenda bashing

<scribe> scribe: timeless

wonsuk: i think we need to work on the agenda

dsr: we should consider a brief discussion about testing
... either within each topic, or at the end

Marcosc: probably as part of infrastructure

wonsuk: ok

mounir: i don't think we should do phase 2 intents now

anssik: maybe a short introduction of topics

chaals: who is leaving early?

zkis: today?

chaals: no, thursday

Marcosc: i do

<jmajnert> jmajnert: Janusz Majnert, Samsung

mounir: could we put testing in the afternoon?

Marcosc: as long as it's early

mounir: we could start w/ that

Marcosc: that's fine

mounir: we don't have to follow the agenda precisely

wonsuk: other comments?

Execution and Security Model

wonsuk: first, mounir, could you introduce the specification?

mounir: current state or current spec?

[ laughter ]

mounir: the runtime spec is trying to define what is a web application
... how to install it
... how to manipulate them
... what is the lifetime
... how you can start up/wake up
... permission model
... we did a FPWD a week ago
... it's still very drafty, a lot of stuff to fix
... Marcosc has a lot of stuff to say about it

Marcosc: all nice things

mounir: yeah, sure
... i don't know what else to say for introducing it

Marcosc: it covers "packaging"
... there are different categories of applications
... hosted web applications, v. packaged web applications

<chaals> runtime spec

Marcosc: and the overlap w/ traditional web applications

mounir: a hosted app is a simple web app w/ a manifest
... using appcache to make it available offline
... a packaged application is everything embedded inside a zip file
... first thing: it's self contained
... easy to build
... a game developer you can build a package easily
... you are same origin to only yourself

Marcosc: darobin also proposed a uri scheme

suresh: for this introduction
... is it fair to say it will do both posted apps and web apps?
... web apps that people access
... is it a hosted app

Marcosc: the main distinguishing factor is the association w/ a JSON manifest
... which provides you with something similar to the Widget XML manifest
... atm things are very loosely described

<chaals> the manifest section of the spec

sicking: you can sort of do this in FirefoxOS

jose: it's in the draft to have a hosted application
... you can install an application that's hosted or packaged
... and you can have normal web applications
... does the draft capture this?

Marcosc: the draft covers this
... through "installability"

XQ: the sensor doesn't have XXX1

Marcosc: the scope has [list of apis]

mounir: sensors are mostly in DAP

XR: is the SysApps addressing the normal model or not?
... or only apps you install

mounir: the goal of SysApps is mostly for Installed apps
... the manifest and security model could be used for non-installed apps
... WebApps WG has a manifest in Widgets
... so it's in scope for ...

XR: this isn't only phone, it's more general, right?

mounir: yes

Marcosc: the manifest is more general
... there are specific APIs which may be Telephone specific

XR: but contacts would be there in a PC?

spoussa: how do you describe whether a web app is hosted or packaged?

Marcosc: this is an open issue
... to have a hosted web app, you need to go through an api
... do we want a meta tag
... or an attribute
... we currently don't have a solution for that
... we have an installable solution

spoussa: is that recorded as an issue?

mounir: no, not formally yet

chaals: where's your issue tracker?

Marcosc: issues are on GitHub
... but we need to decide if we want to go w/ an API, or extend HTML

<Marcosc> github issues: http://gh.sysapps.org/

gmandyam: you mentioned AppCache in the introduction
... AppCache has its own manifest
... this discussion of a manifest thoroughly confused me

mounir: our manifest can link to appcache manifest
... we're working on fixing AppCache
... we could try to merge the two manifests

<Marcosc> fixing appcache: http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0977.html

mounir: but it's another issue
... the new manifest in AppCache could be used JSON
... and then we could embed the one in the other

gmandyam: that's something broader than this WG, right?

<chaals> more appcache fixing

gmandyam: we could ...

Marcosc: for Widgets, we specifically chose to call it a Configuration instead of a Manifest
... to avoid this confusion

gmandyam: second
... section 5 ED's def
... "a packaged application is self contained ..."

<chaals> packaged applications section

gmandyam: we were wondering why that was a SHOULD instead of a MUST?

mounir: you could have things outside, but they wouldn't be SAME-ORIGIN
... so you'd have to use tricks to import the resources

<joseCantera> could that mean that there can be apps which are hosted and packaged?

<joseCantera> at the same time?

chaals: a packaged app that does search might use an external search engine as one of its resources

gmandyam: either you have a different idea of what resources means

<chaals> [I think we do have a different idea of what a resource is]

gmandyam: we think of resources as Multimedia resources

sicking: imagine Facebook
... you're not going to download ALL of Facebook

gmandyam: you're talking about using XHR to retrieve those?

sicking: yes, or <video>/<audio>

joseCantera: an app could be both Hosted and Packaged
... i think the current definition in the draft is broken
... but i could have a packaged app that some of the resources are hosted

sicking: it's very hard from a technical point of view to draw this line
... as soon as we allow you to access external resources
... at some point it's really a hosted application -- if it doesn't work when offline

<chaals> use cases for "fixing appcache" (by getting rid of appcache and having a useful API)

mounir: i don't think the line should be between Packaged and Hosted
... based on offline/online

gmandyam: the definition is clearly broken
... if you want to leave hosted app as is
... then you need to rework the def of packaged

joseCantera: i think we need to make it clear that hosted/packaged aren't so disjoint

Marcosc: i think you're right
... part of it is captured in the abstract

[ which is non-normative ]

Marcosc: that's ok
... using normative language in definitions isn't helpful
... let's file an issue to improve this
... to make it more clear
... i think what gmandyam and joseCantera said are valid

anssik: comment about the AppManifest
... about the scoping
... currently it says a JSON file describes an installable web app
... it looks quite like what apple did for regular web apps
... i'm wondering if our intent is to create a manifest that could be used to move from Apple's thing
... to something standardized
... if that's the goal, then should we state it in the spec?
... and should we split the non packaged/hosted specific parts out of this spec
... is that something to consider?

mounir: yes, the manifest isn't only for installable
... as soon as we fix that
... making the manifest usable to anything on the web

<DKA> Ok I am dropping now but will be dialing back in later this morning.

mounir: we're thinking about splitting the spec
... we don't know how to define the boundary

anssik: i'm interested in a clear migration path from traditional web apps to what's next
... developers are lazy
... if they have to redo a lot of stuff, they probably won't if the tools aren't there yet
... i'm +1'ing that

<wonsuk> +1 for Annsi

AL: is the manifest going to replace the widgets specification that's used by PhoneGap?
... I know people don't like XML today
... another maybe related
... other manifests for AppCache aren't JSON
... i see it as something that others can see in other frameworks
... in our framework, we worked on web-components
... that are kind of packaged
... and can be shared between web apps
... that makes sense

<Zakim> filmaj, you wanted to talk about Cordova's plans

filmaj: Cordova currently consumes the Widget configuration XML document
... but we're shadowing this WG's specification
... a JSON thing
... no timeline on implementing it yet
... but we see moving this way
... to the pain of our users, but not a big deal

sicking: i was going to talk about what anssik and mounir were speaking of
... i'd like to use this Manifest to replace the Apple defined thing
... like Bookmark-to-homepage
... that uses the icon+name+launch path
... and also
... in the current form uses the AppCache property
... AppCache is broken in many ways
... i'd like to fix it so we can extend it
... so we can seamlessly integrate AppCache Manifest and App Manifest
... updates is hard with two separate manifests
... the proposal i sent to WebApps
... and that a bunch of people w/in Mozilla and Google had input on
... allows us to have a smooth transition between a bookmarkable website and an installable web app
... i'd like to go in that direction
... fixing AppCache shouldn't be in scope here, it should be in WebApps

<Zakim> chaals, you wanted to talk about manifests and appcache

<sicking> http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0977.html

Suresh: i think the Widgets also defined config
... i know we want to move in this direction
... i think there's a lot of visibility of Widgets
... i think having some explanation of even a mapping
... it might be a good thing to explain the rationale, and also a migration

filmaj: agree on that

Marcosc: we would need a section in the spec defining a mapping

joseCantera: that was an idea proposed long ago
... to define the data fields outside the specs
... and then have things reference

Marcosc: the question will keep coming up

chaals: the question isn't should this be 100% aligned

joseCantera: saying "X" is the same as "Y" in Widgets
... if two things are the same concept in both specs, that should be made clear

Marcosc: what are Tizen people using?

[ everyone: Widget Spec ]

chaals: BlackBerry

filmaj: Cordova

chaals: M-star

Marcosc: i like JSON stuff
... i don't think anyone will disagree

chaals: strong opinion
... it's useful for developers to tell them "if you know how to do This, then this is how to do it in JSON"
... it's stupid to ask them to read the whole spec
... they will make a lot of mistakes
... you'll get a lot of crap
... if you lay it out for them
... you provide a lot of help to developers
... that's important to getting the ecosystem working

anssik: i'd expect a tool to emerge

Josh_Soref: such tools tend to arrive late, and not perfect

mounir: we could write a WG note explaining the transition

Suresh: it can be referenced from the spec

chaals: I think it should be in this spec - not outside
... it won't add massive amounts of content

<chaals> Josh: I think it is high priority, becuase it provides a migration path

Marcosc: the story sicking is giving about AppCache is also important
... we need a story explaining why we're moving from XML to JSON

chaals: "Because we don't like XML"
... "That is the story"

Josh_Soref: +1

Marcosc: i assume we have consensus to work toward a JSON format

AL: is there a tool?

<chaals> [For the record, I *do* prefer XML. But since most small-shop developers are leaning to JSON for everything, it seems reasonable to use JSON]

Marcosc: Scott Wilson has something

filmaj: Adobe has a lot of tools

chaals: Scott Wilson built a server side solution that converted from Widgets to JSON

App URI

<zkis> App URI spec

[ Marcosc describes the uri based on the spec ]

Marcosc: http semantics have been added to the spec, for, e.g. NotFound
... bits that we might want to change
... the UUID component
... and how this plays with the web at large
... when you make a request to a resource on the web
... the HTTP request would include the app-uri scheme
... and servers won't be able to determine who is making the request
... there are a number of proposals on the table

spoussa: why are we doing this?

Marcosc: so you could run multiple instances of an app

spoussa: within one device?

Marcosc: yes

chaals: yes

Marcosc: this sandboxes the origin of the app
... gives distinct localstorage
... sometimes you might run multiple instances
... Apple's Dashboard lets you run multiple instances of widgets
... In Firefox OS, you can only run one instance of an app at the time
... this isn't a constraint of the URI scheme
... hopefully when implemented it will work nicely with existing web infrastructure

sicking: one of the core design principles of the runtime
... is to allow installing apps from untrusted web sites
... what prevents a web site from saying "here's the new version of Facebook"
... we will not always be able to trust the source of a package
... potentially Signatures/Certificates could solve it
... but we haven't looked into it
... that's why we generate a new instance

spoussa: how does that solve the trust problem?

sicking: each installed thing from each store is a distinct thing
... they might have the same name
... you always know the name of the app and where it came from
... you could know if it shows up on your desktop
... it doesn't Override the existing Facebook
... there might be better solutions, but that's what we have so far
... something i'd like to solve
... is to enable a packaged app that has a app: url to be same-origin to its installing site
... for a developer convenience PoV
... it's dramatically easier to communicate to a web server if it's Same-Origin
... it's much more complicated to communicate to a non Same-Origin server
... if we enable packaged apps to have a home server

spoussa: does this spec explain how to map to home?

Marcosc: no
... this is just for addressing things w/in a zip file

zkis: this is just for identifying apps

Marcosc: there are a number of proposals to solve that

gmandyam: back to the non-normative
... the lack of http response semantics

Marcosc: that's the great feature that this spec

gmandyam: why is this important?
... i've done HTML driven UI w/ feature phones
... file: semantics work well enough

Marcosc: did you use XHR?

gmandyam: no

Marcosc: how'd you read a text file

Josh_Soref: you could use an <iframe>

sicking: that's inconvenient
... we have JSON files for email for localization information
... it's very inconvenient
... to read information out of an iframe and manually pass it to a JSON parser
... it consumes a lot more resources
... an XHR request is much cheaper
... you can't use jQuery-AJAX
... we don't want to force people to do things one way

<Marcosc> MC: JQuery Mobile too

chaals: it's clear there are reasons you'd want to be able to use XHR, and equally to use simple HTML links
... you might have a case where a user might physically navigate within the package

gmandyam: the undefined security model
... section 6 of the runtime for security apps should give you a security model

Marcosc: the question is
... how do you sandbox file:
... and then you have some virtual sandbox
... how do you prevent two apps from sharing things?

gmandyam: VMs solve this. J2ME solves this.
... it's painful to solve, but it's solvable

mounir: i don't understand the problem

Marcosc: gmandyam is saying, why not just use file: ?
... sicking and I are saying that http semantics are useful

gmandyam: what is the problem you're solving by inventing a new URI?
... do we have to address the problem with frameworks here?

chaals: yes
... because developers rely on them

gmandyam: these aren't big deals
... but the arguments in the intro aren't convincing

Marcosc: it might not be convincing
... but our experience from Opera which used a different scheme w/o HTTP semantics
... had lots of problems
... developers want to be able to use XHR

gmandyam: bridging between Native apps and Web apps ...

Marcosc: we're working w/ a super-hostile environment
... the web is fairly robust
... we believe the web platform has better capabilities and better security than native apps
... and tools that allow you do to cool things than in native

filmaj: for Cordova users
... this (file:) has been a big problem
... as an abstraction, app: is very useful
... from Cordova's experience, referencing files using file: was very hard to do/get right in a cross platform manner

Marcosc: the sandboxing issue
... with dashboard widgets on a mac
... it exposes your Username
... it doesn't sandbox things properly
... exposing your username is half your credentials

chaals: but that's just crappy sandboxing

Marcosc: but there might not be a way around that
... using app: avoids this

lgombos: is there a position to manage file: 's relative behavior?

chaals: we know what it does

Josh_Soref: Marcosc you made this presentation to TAG, you should include a reference for it

Marcosc: Josh_Soref is right
... we looked at a whole range
... the pros and cons of each
... i'll link to that from the spec

<Marcosc> Issue filed: https://github.com/marcoscaceres/app-uri/issues/2

gmandyam: sandboxing seems like it should be in the runtime spec
... i can provide bits offline

AL: i have requirements when developing
... when i want to link to an app w/ a specific state
... we have a history api
... i wrote my app for packaged apps
... i might want to go to an app, maybe mine, maybe not
... in a state
... i needed a fallback url for when an app isn't installed
... i saw an app shim that could address that

Marcosc: app: relies on mime type to handle fragment identifiers
... app: doesn't deal w/ semantics like that
... if you point to an html page w/ #some-state
... it would work
... this is based on media type

AL: i want to point the user to a service
... or a feature
... if he has the app, it would be most effective to go to the app
... but if it isn't installed, i'd like it to go to a place where it could get it

kenneth: sounds like web intents

mounir: if it wasn't a packaged app, you'd be able to launch the app using the api
... but you'd have to be same origin

chaals: if you run two instances
... the "meeting scribing app"
... each instance only lets you scribe one meeting
... you get it installed twice
... effectively two copies
... the opera widgets implementation
... took the zip file
... and made a copy of the zip file for each widget it had
... i still have it in cache

Marcosc: it installed only one app in your folder?

chaals: it installed them as two copies

mounir: for packaged apps, you would install two times the app
... but for hosted apps, it's the same app

<chaals> Josh: If I am using an app, I want to be able to have it running twice whether it is hosted or installed.

AL: about the fallback, i wasn't talking about for installing
... i'm talking about using the URL to get to a `non-installing` app (i.e. live running)

Marcosc: i don't have a good answer to that
... i think it's a valid UC
... it would be good if you could follow up
... on the ML
... and we could hash it out

<wonsuk> ?q

s/?q/q/?

lgombos: i see a value in the app: schema
... my concern is
... how can we capture the exceptions where we can't use the http semantics
... you can have a URL that points to an app-manifest
... can i have an http iframe in a packaged app, and have it include the app: uri in the http iframe?

Marcosc: i don't think there will be an issue

lgombos: what does it mean to have an app: url to an appcache?

<chaals> issues for the runtime spec

Marcosc: it's silly to do, but it should work
... the browser shouldn't really care
... as long as it gets the right responses

lgombos: i can have <img src="http://evil.example.com">

Marcosc: you can use img from within app cache as a fallback

lgombos: i don't have a good example where it's broken
... but i'm not sure it's always the same

Marcosc: hopefully we can, but there might be issues

<spoussa> *break?*

Marcosc: sicking, can you think of any case where using app: might cause issues,
... like where you point to an appcache as app:

lgombos: or even src=app:

sicking: using <iframe src=app:> should work

lgombos: even if it's a different uuid?

sicking: what we did in FirefoxOS
... <iframes> and <img> can usually link cross-origin
... all browsers have special exceptions for file:

a/all/all modern/

scribe: so there's something special about file:
... in gecko, we don't even allow you to link <a href=file:>
... we have the same limitation with <iframe> for app:

lgombos: so sometimes it behaves like file: and sometimes like http:

chaals: http: only sometimes behave like http:
... browsers deal in a hostile space

sicking: different origins within app:
... are more than just different origin
... between http:, https:, ftp:, you can link just fine
... between http: and file:, you can't
... we don't allow redirects from http: to app:
... but that breaks OAuth

Marcosc: in WAC, we tried

<chaals> Josh: Is there a requirement to make it possible to use OAuth?

<Marcosc> Webview API

sicking: i'd like to fix this
... but it's a big issue

joseCantera: there's another issue

Marcosc: we've found different ways of solving this
... we might need something similar
... you gave an endpoint using window.open
... and when you did the closing
... it gave you the last url
... in theory that worked
... but it wasn't thoroughly tested
... the security people thought it would work
... in general, the less we rely on app:, the better
... a lot of the web infrastructure relies on http stuff
... the more we use http, the better off we'll be

lgombos: how do we document that you can't do <a href=app:otheruuid>

Marcosc: in Opera Link, you could

sicking: in FirefoxOS, you can't

Marcosc: because otherwise you weren't able to do things easily
... it isn't a restriction of the current URI scheme
... it's a restriction we could talk about

sicking: i don't think we should allow you to put a facebook app that points to a link to another app

<gmandyam_> +q

sicking: where you're suddenly running another app

lgombos: how do we document this?

Marcosc: it's common sense that you wouldn't jump from one to another
... they can use URIs (tel:, mailto:)
... there's the Intents/Web Activities solution
... how they relate to URI, i haven't looked

[ Time check ]

Marcosc: where do we want this spec to be?
... right now, it's in my personal github
... i can contribute it
... "my gift to you"

chaals: break before we go on

wonsuk: 20 minute break
... Lunch is @1pm (local time)

<Zakim> chaals, you wanted to ask how, with a uuid, you can decide which ebackfoo app is the trustworthy one?

chaals: when you have two Facebook apps
... one from facebook.com, and one from the non evil company

sicking: what does the trusted one mean?

chaals: how does one identify one as trustworthy?

sicking: what does it mean by trustworthy?

chaals: authentic
... in runtime model, there's the appstore source

sicking: if we're talking about APIs
... then it's the responsibility of the Store to provide access

chaals: how does a user know what they've got
... they're phished

sicking: a Facebook app doesn't need SMS
... the trust is when a user enters facebook credentials

chaals: i can live with the simplification knowing it's untrue

sicking: any website can put up a store
... which has an app called facebook, using the facebook logo
... which when run uses the credentials and pulls down facebook data
... but it's the responsibility of the user to not enter sensitive information into an app they don't trust
... anyone can set up a web site with the facebook name, and facebook logo
... this fails a lot
... that's what we call phishing

zkis: does the user have a way to identify origin?

mounir: the origin is provided by the manifest

sicking: for a hosted app, we show origin at install time
... but it's a pretty weak way to secure
... relying on URLs leads to phishing

zkis: if you do a platform using web apps
... and you use icons and origins
... you could use a different icon for trusted apps from your store or from another store

sicking: yeah, you could certainly do that
... one goal here is to enable anyone to set up app stores
... i don't think we want to do too much warnings

zkis: but it's possible

sicking: ultimately, we'll have to
... have a database
... most browsers have a database that checks "is this web site a scam"
... we should encourage implementations to protect users by checking to see if something is a scam
... we'll need similar mechanisms to what we use on the web today
... great, i like talking

gmandyam: to Marcosc
... what is your expectation of an sdcard reference?

Marcosc: depends on the UC

gmandyam: a file created by the App on the sdcard

Marcosc: in that UC, you'd use a Blob uri
... so you don't expose that to developers

gmandyam: so the uuid doesn't expose that
... if you use fs: there's a distinct ref

Marcosc: i don't see a UC for knowing you're on an sd card

gmandyam: the app might want to know if there's a place for more space

chaals: but that...

gmandyam: that isn't how native file apis
... JSR-75
... the api lets you see if there's a sdcard

Marcosc: we don't want that
... it provides another attack vector
... the aim is to make it absolutely transparent
... we're only providing a manifest
... we don't want to deviate from the security model
... it's unfortunate that we'd potentially have to add a uri scheme
... as chaals said, decisions to save to media

gmandyam: but we're not talking about browsers

Marcosc: we need to get consensus
... in my mind, we're talking about browsers

chaals: the rationale is we're adopting the browser security model
... consequently, if there are things we're putting into the spec w/o explaining, we should explain it

gmandyam: the UCs are well established

Marcosc: i come from browser land
... in my browser world, the world works this way

gmandyam: i'd suggest
... what kind of permissions are exposed wrt storage
... considering a Media Storage API in phase 2

sicking: we chose to put a Media Storage API in phase 2
... an sdcard: scheme would go hand in hand w/ that
... it'd be possible to provide an sdcard: protocol
... we could enable reading from sdcard: and have a permission for that
... and let it be used as w/ http:
... we could do the same thing w/ file:
... we could do the same thing w/ native apps
... it's quite doable to write a separate spec
... trying to define file:, and adding that as a permission
... we have a permission model
... adding a permission is possible
... but doesn't require adjusting the model
... it can be a separate spec
... we can do it, as long as there's agreement that the UC needs to be solved that way

Marcosc: in FirefoxOS, device storage uses Blob:
... someone accesses Pictures, Videos -- predefined folders

sicking: we're working on a feature w/ install time allows the user to decide where an app is installed
... the implementation can do whatever it wants as long as it exposes the same feature set
... this would allow app: to sometimes read from file:, and sometimes sdcard: or sometimes even http:
... but that would be completely transparent to the app
... doing that, moving an app to sdcard: would also migrate the LocalStorage, Cookies, IndexedDB

gmandyam: on the EFS, you obscure the data
... but you might not obscure the data on the sdcard

<sicking> mounir, i was, but i just said what i wanted

Josh_Soref: BlackBerry sometimes encrypts its sdcard too...

sicking: we should talk about UCs
... a lot of things are solved on the web a different way
... because we have a different trust model
... my goal is to align w/ the web model

filmaj: Cordova has run into this problem as well
... referencing things w/in the app package/not
... we used the File Directories and System
... an api to select if you get Temporary or Persistent
... perhaps better describing the relationship w/ that api

Suresh: app: shouldn't preclude you from doing things you'd normally do
... you can still continue to access file:

sicking: assuming we permit that by the security model
... in FirefoxOS, we don't allow any app to access file:
... the only thing that needs direct file access is the runtime itself
... we don't have *any* apps that need direct access
... the only thing we need access for is Files/Pictures
... and we use Device Storage apis

Suresh: so you use Device Storage
... we're silent on this access?

<anssik> should we continue this discussion Thu afternoon in the phase 2 slot?

sicking: the runtime is silent

jplyle: in Webinos, we use the file: api
... we use multiple impls, persistent and non persistent
... we seem to be covering a wide span of UCs
... both native replacements (Telephony/Raw sockets)
... as well as roughly Web apps
... this is a wide gap

<Zakim> chaals, you wanted to point to webapps as a place where some things Apps will use are actually defined (file reader, writer, quota API,...)

chaals: there's an intent to bridge a wide range of apps you'd be able to build
... some would be a fairly plain SMS app
... and some would be something like Twitter/Facebook
... and some will blend those together
... but, i'm on the queue...
... this is One of the groups working on APIs
... WebApps WG has "file reader" (completed w/in 10 centuries)
... we have the next editor of it in this room
... there's a "file writer" (read, write, mount)
... there are other APIs outside this group
... we shouldn't repeat what they're doing
... it's worth knowing what they are

gmandyam: we'll reuse Blob:
... WebApps doesn't really consider use of these apis on handheld devices

chaals: they're meant to work on handheld devices
... some of us in this room are in WebApps

sicking: the goal here shouldn't be to create a web version of
... we shouldn't have a webified Win32 api
... we don't want to take existing apis and

gmandyam: so we don't want to just take the raw socket api

Josh_Soref: +1

sicking: the goal is to be able to support creating, e.g. an IRC app

<wonsuk> ;''

<wonsuk> ]

sicking: the reason we created a tcp socket api

<wonsuk> \'

sicking: was to support platforms that don't have the web model
... email servers don't support CORS/http
... we want to support IPTV
... at least an IPTV that doesn't support CORS
... tcp socket api is a way to interact w/ legacy systems
... it's much better to use WebSockets than TCP sockets
... but we can't expect everyone to support WebSockets
... that was the goal of TCP sockets for us
... and similarly for UDP sockets
... we'd much rather everyone support WebRTC
... but that's why we'd consider UDP
... we have the specific goal of supporting legacy systems
... essentially the entire world is legacy systems
... but not as "supporting file or network"
... we can already do HTTP w/ XHR

Internationalization (i18n) Model

Marcosc: what's in the spec is loosely defined
... working on respecifying it
... working w/ the i18n WG
... back and forth with them
... i have a proposal to send to the group
... it's fairly similar to the Widget spec, and the FirefoxOS impl
... there are some issues
... around canonicalization of language tags
... atm, FirefoxOS's l10n model is String Matching
... it only supports language tags w/ 2 levels (language and country)
... it doesn't support private use or variants
... and it only has a very simple fallback

<mounir> https://gist.github.com/marcoscaceres/5055717

Marcosc: it's fairly underspecified in the spec
... i found issues in FirefoxOS
... i compared this to w/ what Chrome is doing w/ packaged apps
... they use a more "sophisticated" i18n model
... it's "more traditional"
... it's geared to i18n teams
... whereas, what we have here is a centralized model
... this is problematic on a large scale
... depending on how it's implemented

mounir: does chrome put all l10n strings inside the model

chaals: i'd call chrome's "crappy"

Marcosc: it goes and replaces things

Josh_Soref: this is roughly a GetText implementation?

chaals: it's basically a ported GetText

mounir: there are few strings to translate in the manifest
... app name, author, description

Marcosc: developer

mounir: there's no point to have an api just for that

chaals: as a developer, i disagree

mounir: darobin pointed out that you can have references in JSON

Marcosc: we see Bibliography for ReSpec
... i sent invalid JSON somewhere (lack of comma)
... I assume it's going to be the same issues w/ this
... (merging content can result in fatal corruption)

[ Marcosc points to "CASE 9" ]

Marcosc: a slight cleanup of FirefoxOS
... to handle language matching
... to hopefully match what developers expect

[ Marcosc walks us through the case ]

Marcosc: it's about decomposition of language tags, so you get the right one
... walking from en-US to en before jumping to the default
... otherwise you define developer over and over
... it's about reducing redundancy
... but how that model works gets fancy
... the equivalent is for http the accept-language
... en-US + en-AU. Do I go to en-US, en-AU, en, or en-US, en, en-AU, en
... in Widgets, we went from en-US to en

dsr: can you walk through examples

Marcosc: pt-PT and pt-BR are fairly incompatible

dsr: this is embedding multiple locales into one document

Marcosc: LTR languages in JSON are messy
... this is why in the Widget spec we added a span tag

chaals: isn't this more a JSON issue?

dsr: the i18n folks wanted to know when they should look

Marcosc: i started communicating w/ them
... i have a proposal almost ready to send
... but not LTR/Ruby
... this is the difference between JSON and things solved in XML

<JonathanJ1> FYI - http://www.w3.org/TR/widgets/#localization-model

Marcosc: maybe filmaj
... i know most of your market base is US
... but I know you have i18n
... can you share experience?

filmaj: nothing built in for metadata

Marcosc: from opera extensions
... 33% of apps
... were internationalized
... mostly Russian

chaals: opera's user base is mostly Russian speaking
... you had the odd person doing Hebrew/Arabic
... using XML was a win
... People mix Latin into Hebrew/Arabic
... I can draw you a map and i can paint where this is going to fall over

Marcosc: I don't know if the Tizen/FirefoxOS guys have experience

sicking: i don't have anything to share

Marcosc: we know there's a potential problem

Josh_Soref: We ship to Arabic, in fact the BlackBerry Z10 launched in an Arabic speaking market second only to the UK.

[ Lunch - resuming at 2pm ]

Security Requirements

<mounir> Security Requirement WG Note

jplyle: i got involved in this because I got involved in Webinos
... the aim of our involvement was to try and share what we learned
... it became apparent that it was too complicated
... so we came up w/ this document which is a set of requirements and threats
... we discussed this on the list
... and decided to have a document to cover requirements / threats
... and use that to validate a spec
... i think this is valuable because
... the specification adds enormous complexity
... package levels, signing, CORS, CSP, ...
... it's quite difficult to separate that from threats/the underlying requirements
... we tried to build on things already posted
... my plan was to get feedback today

Marcosc: it's interesting
... great to see, the idea of the user, and the various device owner [categories]
... Corporate IP department
... network operator
... owner of device

jplyle: that concept comes from the Trusted Computing Group
... which we're also involved in
... this only talks about packaged apps

<mounir> http://notes.sysapps.org/security-requirements/#system-assets-and-stakeholders

jplyle: i'm going to try to update it based on the other FirefoxOS model

Marcosc: in SysApp requirements
... `required to be able to do`
... required is awkward

jplyle: there aren't any well documented UCs/Reqs anywhere else

Marcosc: i raised that issue early on
... as to why things are in SysApps in that order

<Zakim> Josh_Soref, you wanted to second Marcosc

<chaals> josh: sent feedback saying the group is lacking requirements and use cases

<chaals> … also, officially W3C specs are in en-US - add some "zzz" and less of "u"

<chaals> scribe: chaals

jpl: We'd like to see that we link the real threats and requirements that this work faces, to the work we do

MC: We have back-and-forth about trying to nail down the model.

… looking briefly at the pictures (not actually reading), if we could describe the model of what we build in similar ways and see how it fits with the web security model would be good. This currently only covers the packaged app model

JPL: I would love to have better references to the Web Security Model

JS: Talk to Adam Barth...

ZK: I like the picture. What are the mechanisms to enforce security, who defines what is mandatory?

… I ahve seen features that may require permissions - that is one way to do it. So who defines policies, where are the enforcement points?

JPL: It isn't my intention to define policies - that is really too low-level for this doc. But there are requirements from manufacturers to have policies

MC: There are already things like same-origin - these are policies in effect.

… and CORS, CSP, ...

JPL: There needs to be some kind of policy, but my aim is to explain the threats that justify the policies

CMN: Developers need guidance, so you need to explain the threats and the common restrictions they face, but don't reinforce the assumption that some protection will always be in place.

JPL: Right...

ZK: Would be nice to augment this with how policies could be enforced. And is there a basic set that we see as really being common? How far can we go?

CMN: People *will* take the technology out of the context it was conceived for, so it is important to think about capturing what those implications are.

<inserted> JPL: Maybe there should be "security Considerations" sections

MC: That should generally be in the API

ZK: SHould also talk about the minimum security constraints developers need to know

ML: In FirefoxOS we have privileges depending on the level of trust in the app source, so the security model needs to allow for the variability.

JS: Developers care a lot about a prompt coming up. So vaguely saying "the implementation may ask the user permission for…" isn't a good idea. Developers end up not knowing what is going to happen.

… we generally need to define whether things are going to prompt or not (as an expected *default*)

Kenneth: That would be useful. On Android applications ask for all sorts of permissions I don't understand why they should have, so would rather be prompted at the time of usage.

JS: One of our decisions was to avoid security decisions at the time of install. That also lets us do upgrade without needing security decisions. The prompt happens if (and only if) you use the relevant functionality

… the app can pre-warn about that.

… in the manifest spec you enumerate permissions and *why you want them*

[CMN: \o/]

JS: … which is why l10n is important

ZK: E.g. chat application explains why it wants to use eg SMS

AK: There is an example of this in Feature Permissions, which was factored out of Web Notification, and the app can find out if the prompt will be presented...

Laszlo: It's like geolocation. There you can prompt when you try to get the location. But an alarm API that asked for permission to ring only when the alarm was ready to go off would be a bad idea.

Josh: It is hard to find an example where this is really useful

JS: THink notifications is the one example where we found it necessary to have a request in advance.

… If you want to use 5 things, developers don't want to ask 5 times. Our experience in testing is that asking the user to make 5 decisions on a single button is a bad idea - they make worse decisions.

… so we want to ask the user to make 5 atomic decisions.

<timeless> Josh_Soref: +1

JPL: There is an issue around designing UI. And context can break it. But designing without thinking about at least a common UI paradigm is also irresponsible.

JS: We cannot define the exact UI but I think we should at least describe the "default" user experience...

… I think that is what geolocation does.

… There is room for variation, but the common thing is described.

Kenneth: It's bad to have things that cost money, or give away privacy. There are different *groups* of permissions.

… normal people don't know what they are getting.

CMN: There was a group that worked on looking at the security experience and getting enough consistency to make things understandable across agents.

ML: If your app comes from an untrusted source you might find that the policy you expect doesn't get applied.

JS: Currently we just reject priveliged apps from untrusted stores.

ZK: Either you ask the user for permissions, or implement a deep security infrastructure. That's a general restriction.

Josh: There is a 3rd approach - "lie".

… you give e.g. a dummy picture or location when the app wants it, and that helps the user decide if they like what happens then.

GM: In native apps a lot of that is signature driven with a trust authority.

… the trust is whoever signs.

AK: Think that <input type="file"> is something well known by users, and widely implemented. Looking for a camera that way makes sense. I think that is a proven way to make things work.

… we did this with things like contacts and address book interface.

ML: Think it is good that an untrusted app has to do this. Trusted apps can get access direct.

… think for the fallback we should be using web intents / web activities / one of that family

… so the user gets to work out how a given app gets to do something.

… through an app that they know.

JPL: Doesn't work for all classes of apps. e.g. a contacts manager can't use an intent request for every call.

Josh: A contacts manager owns a database of its own.

JS: Really?

Josh: that is how I would write it.

CMN: I would write it exactlyopposite, to talk to the platform's database. We have both use cases.

Josh: Web Intents would allow you to authorise continued access to an app (unless the user changes that)

… you are not required to get prompted for every call if the user doesn't want that.

ML: Your point is correct. web intents/activities solves the issue for untrusted apps. But we need APIs for trusted apps to use, and at some point it needs to be a web API.

… while untrusted apps may not care and don't need that anyway.

GM: If you have a single delivery model say so, or you need to relax requirements to account for different levels of trust - e.g. a bad app got put in.

JPL: Uninstall is a tricky one. Users might want to leave the data there because it is theirs and the app uses it, or it might be malware and you want to get rid of it. "Kill-switch case..."

[section 7]

GM: This isn't assuming malware. But there are cases where user intervention isn't required.

JPL: I didn't mean to assume a total delivery model - "device owner" here is defined as a range of things to ensure I can cover different use experiences.

GM: E.g. a user may be prevented from uninstalling a priveleged pre-installed app

JPL: Tried to capture that here.

DSR: Please clarify what "device owners" are.

JPL: Think I said that.

DSR: for example a triggered unistallation because some app is *no longer* considered trustworthy.

JPL: I will look again at the heirarchies and ordering.

Josh: There are lots of things in the first list that are irrelevant.

JPL: They are there because you can't talk about security without functional requirements - you need the context. I agree that this isn't a final version...

Josh: Please add a note explaining that thinking.

ZK: There should be a threats section in each spec if they are not gathered here.

Mikko: Isn't it quite loose for handsets - best case is a statement of threats without requiring enforcement.

MC: Yes. It is common to put that info in specs too.

Josh: Requiring API features normatively in security isn't good.

MC: Yes, drop RFC2119 langauge for informative stuff.

JPL: Sure.

<timeless> Josh_Soref: +1 to MC

Runtime issues...

1. Remove application management interface

ML: It is in the spec to allow building app stores or managers as apps.

MC: I didn't understand the purpose of this when I sent the email.

Mikko: Where are these web-style attacks specified that apps need to protect against? Are they outlined somewhere?

MC: This is the list of threats Jon had.

… Developers need to take care - buggy code allows threats.

ZK: W3C doesn't have responsibility for the attacks. What matters here is what is the security implications in the API?

… e.g. if Telefonica phone has a security hole, Telefonica is to blame.

AK: Think you want to look at the Content Securty Policy.

[back to app management API]

MC: How do I get the permission?

ML: request it in your manifest.

… we only grant the request for trusted apps

MC: Raised another issue about "list every API considered to require user permission".

JS: Intent was to list capabilities beyond basic website (DOM, setTimeout)

… you already have geoloocation on the web.

… but we did add notifications because you can use it without having a prompt.

… for device storage you need to request it.

… we made a somewhat inconsistent rule.

MC: This is like the feature element in widgets, that was developed for proprietary APIs.

JS: Normal web pages cannot use alarm API. It is additional so must be enumerated.

… but not proprietary.

MC: Putting it in the request doesn't ensure your request is granted.

JS: By default, you get your permissions by requesting (depending on which tier of trust you are in)

MC: You don't want to enable APIs unless you have to. But you could enable them for hosted apps.

JS: If the app gets hacked, they are not exposed.

… geolocation is an exceptional case. By normal logic would not need to be listed.

MC: Can close this issue.

AK: This ties to feature stuff, so strings could be fetched from API edited by Laszlo. We are unable to discover up front if the permissions have been granted.

JS: Successful installation implies the app has got the permissions it asked for.

AK: In the context of traditional web using the manifest that would not be the case.

JS: Maybe.

LK: If you know your target audience is sensitive about location you may have two versions.

ML: listing geolocation doesn't get permission

LK: installation would fail without permission

ML: No, if you list it, the when you use it you can ask. If you don't declare, you don't even get to ask the user for it.

JS: Right. Unlisted APIs are going to be blocked.

… for alarm, if you list it, no prompt.

LK: So as an app developer you need to be prepared to handle different combinations.

SC: There is no default because you don't know what the user will actually allow at run time

JS: The default policy is "what you can do on the web"

… we can disable things.

… e.g. disable things that have been exploited in the past. Users can choose to do that. e.g. the noscript addon is really popular

… we should define how things normally behave, but be aware that anything might fail because users can stop that.

SC: Default policy may or may not be honoured.

JS: Yes, depends on user.

ML: If i ask for SMS, I still might not get to ask the user to use SMS.

SC: It is only a hint, right, not a guarantee.

JS: Behaviour we are defining is the behaviour implementations should have unless the user has chosen to do something else.

SC: User need to know the app is accessing the alarm.

JS: Why?

<JonathanJ1> FYI - http://www.w3.org/community/webappstore/wiki/Manifest (I've updated manifest comparison chart. inlcude sysapp manifest)

SC: You should know, at installation or some time, what the app is meant to do.

CMN: Yes, I want to know what an app needs to work, if I ahve overridden normal behaviour. I think the interaction belongs with the user interaction for disabling things.

AK: Chrome allows this.

JS: With permissions we can list just the things the app uses, but the spec should define a default case

… developers should be aware that users can disable anything. I am aware that behaviour is broken because I made the change, so I ahve explicitly decided to live with that.

… I don't know what that means we are expecting developers to handle.

MC: Follow on: description is mandatory. Put russian descripiton - who is it for?

JS: User

MC: I wrote the description in russian...

… i18n problem.

JS: Same as the app name.

MC: When does this get displayed?

JS: When you are prompting for permission.

MC: Issue with i18n - not localisable?

JS: No, this is localisable.

MC: This gets pretty crazy pretty fast.

JS: You can match the pattern for "permission": { "ru" :{ "context" : "Боже ьой" }}}

MC: OK...

… for access you need to know what the values of access mean for each API.

JS: Yes.

MC: You need to define these for all APIs

JS: Depends on the permission whether it is mandatory or not.

Josh: What if you specify a value that is invalid for a permission?

JS: Then you get an invalid manifest

MC: The permutations can become a testing nightmare.

… e.g. what happens if you try to write when you have read access?

ML: We use it for APIs where it is really straightforward. DeviceStorage, Settings, …

JS: Right. It increases complexity, like having separate prompts does.

… Android optimised for reducing prompts and answer complexity,we optimised for user autonomy

MC: Worried that devs will just always ask for the most permissive level to keep it simple

JS: APIs have all been privileged apps - they get reviewed which is the incentive to minimise requests

… Android shows developers minimise set of permissions they ask, in large part.

Josh: What if someone wants different explanations for different access requests?

JS: We decided not to enable different descriptions for different types of access. That can put a lot of restrictions on UI.

… we don't say currently what access is being requested. But might change that.

… We didn't want to get too complicated.

MC: So long as we have clear guidelines about how functionality is denied (throw? security exception? fail? ...)

GM: Would the API spec have to define what happens when something doesn't work?

MC: Yes. Did this in WAC

JPL: Wanted to jump on "priveleged apps are reviewed". I think that assumption is not very strong.

Josh: +1

CMN: +1

AM: I give permission to an app, eg alarm, but there is no notification. But I don't now the whole behaviour - it might set alarms when I don't want it. I would like a way to get notification of that.

ML: We decided alarm isn't just alarm clock, and it isn't a major threat. If you don't like what it does, you can uninstall. Threat is trivial so threshold for action is low.

AM: If you don't ask permission you don't have access to the API. If I ask permission user might not know why they ask for all permissions. I think there needs to be the concept for mandatory permissions, and allow the user to activate other permissions later.

ML: When you install the app you don't present all the permissions to the user.

… they get asked for the specific things that get used when they get used.

Josh: Request only on use.

AM: First use only?

ML: Depends - can say yes, no, always, …

ZK: Asking for permission doesn't necessarily trigger request to the user.

ML: We have permissions panels so you can configure each apps permission based on their requests, if you want to work that way.

AM: Can taht be done globally?

JS: It isn't in our UI but the spec allows it to happen in an implementation.

Kenneth: Problem of Android is platforms embedded taht ask for everything.

ML: That is why some classes of apps are just not going to be allowed to have all permissions...

… trust is delegated to the appstores

… Android has a single trust level. We have more granularity.

… see section 10.4

<mounir> ;?

AK: Implementation comment - I would make a paranoid mode, like private mode. App gets dummy content, and youcan check what happened with that to decide whether to give access everywhere. JPL have you looked at that approach?

JPL: This is like Mockdroid. Developers said no, we don't want that. Breaks expectations between apps and the user.

JS: Sounds like a UA feature. We will define the default behaviour, and recognise that it can be changed (we can, the user can, ...)

AK: This is quality of implementation issue

Josh: It would be helpful to have a statement of that for developers to understand it applies to the Web

CMN: See "Dao of Web Design".

MC: Should have agreement that the manifest format should not be extended.

… there is no way to distribute extensebility in JSON, so that is dangerous.

Josh: Then you run into permission registry issue

MC: We are the authority for the spec. Ask us.

CMN: We will extend anyway. Come up with a better answer.

<jplyle> (The MockDroid discussion: http://www.androidpolice.com/2011/05/22/cyanogenmod-adds-support-for-revoking-and-faking-app-permissions/ )

MC: Parsing model is very liberal. Only *need* a name for an app to work.

… ignore things that are unknown. If someone is going to make extensions we need to decide how to deal with it.

JS: Not super-worried about people writing extension specs on this. I am much more concerned that users will stick random data in and collide when we add features. Maybe we should have a data property or similar extension point.

MC: Yep, makes sense.

Josh: How much of the manifest is exposed to the app?

MC: All of it, as an object.

Josh: makes it really likely to have extensions added.

MC: Let's add a property for extensibility

… need to keep it liberal for back-compat.

ML: Process required to extend...

JS: Like the way HTMl does it with extension specs.

GM: You can create a registry. Opens the path for proprietary extensions.

… we said in WebRTC that W3C-spec'ed stuff is required, and there is a way to add extensions if you want to use them.

Josh: We have no idea how this works yet. To be fair, MIME didn't work wonderfully.

MC: Right now we can update this doc any time.

ML: Would prefer to have something less specific than sysapps.

MC: Sure, that's a tweak.

CMN: Give us an extension point or we will make our own.

JS: This has worked in HTML

CMN: Not really… data-* is a point...

Josh: And MPEG demonstrates that they will just extend on whim.

JS: Think we should add a data property as an extension point.

… and if something gets traction from there, we could standardise it.

<joseCantera> +1 to the extension point

Josh: In general extensions are talking to themselves, so they tend not to have real issues about conflicts.

CMN: An extension point works for me.

RESOLUTION: We will add an extension point.

Floggings will continue until morale improves

Navigator.language should notify language changes.

MC: Yep. Filed bug on HTML

<timeless> scribe: timeless

chris: the runtime spec specifies Terminated, Running
... but the system messages section
... is vague "if the app is not running, launch it"

mounir: the reason it isn't clear
... system message was part of the first version of the spec
... then we added the samsung execution model
... we didn't update system message
... i guess
... it should leave both states

<JonathanJ1> https://github.com/sysapps/runtime/issues

chris: it should resume the app?

mounir: i guess
... i'd have to think more about it
... we have no implementation experience

chris: the spec isn't clear if it powers on the device

mounir: it says that it may power on the device
... but it doesn't

Josh_Soref: Nokia was proud of alarms waking up
... and BlackBerry does unless the user picks the other "really turn off" option

sicking: you definitely don't want all system messages
... when you have a system message, you've already started the phone

zkis: what about wake up messages

Josh_Soref: (wake-on-lan)

sicking: system messages don't come out of nowhere
... it should be based on the specification of the API

zkis: there's an event in the car, where you need to wake up one of the displays in the car
... if we add something later, it shouldn't break the API

sicking: ok

zkis: could we add an argument to clean messages of the type
... i want a message, but only the latest one
... otherwise i might show the wrong buttons for a while

mounir: i'd assume the system to clear the events

sicking: i don't think it would
... could we define it in the telephony api?
... potentially it depends on the type of message
... do we have a state transition message for telephony?

zkis: yes

sicking: if you have multiple incoming calls

zkis: if you have a live call, and the dialer crashes

joseCantera: we don't really have this

zkis: we have events right now
... but i was thinking system message would be better

Raw Socket API

Claes: the first version was based on the BSD style
... it wasn't webbish, it could be made more easy for developers
... this is a new version
... inspired by WebSockets

<Claes> http://raw-sockets.sysapps.org/

Claes: this is the base Interface, it inherits from EventTarget
... then we have UDPSocket
... based on RawSocket
... then we have TCPSocket
... based on RawSocket
... then we have TCPServerSocket, it inherits directly from EventTarget
... i got comments from 4D
... proposing a set of changes, and added functionality, and clarifications
... and one major comment-proposal
... we should align w/ WebSockets
... we've had a discussion on the security implications of that
... WebSockets is for all web content
... but this Sockets API assumes System privileges

lgombos: you don't see providing this to web content

[ No - you can attack SMTP/IMAP/POP badly ]

Claes: 4D asked about WebSocket:RawSocket

AM: i saw it as defining an abstract socket
... so the how to manage send/close would be defined in the final

KF: we wanted to make things easier for the developer, they're just send() and receive()

AM: i was talking before
... you have an App, or a Web
... but the business rules should be the same

joseCantera: the other thing that's strange to me
... in the UDPSocket example
... i don't know why it's sendUDP
... address and port are params

Claes: that's another proposal
... Set Remote Address ()
... and then use the same send style
... but i think there are UCs about sending to differing destinations

joseCantera: they suggest a full refactoring...
... it seems strange to have onreceivedudp
... that it should be onmessage

AM: i'm not sure how we'd define an abstract socket, given that WebSocket is already defined

sicking: moving things around for JS doesn't usually affect things
... there's no advantage to a common base
... objects don't have a type
... it doesn't affect code
... nor what implementations would do

Marcosc: only for instanceof/chain checking

sicking: but in normal code, you own't detect a difference

mounir: if we had a Constructor() which returned an object
... and the only thing beyond the base interface was the constructor
... if you can't do that, then you should have two interfaces

Claes: i think we can try to align style+naming w/ WebSocket

Marcosc: these are spec gymnastics we could go through later
... i was liking "new Socket('udp')"
... and the rest is managed in the background

AM: so the protocol could be passed in the constructor
... W8 is more involved

<Marcosc> http://ringojs.org/

AM: Ringo.js uses DatagramSocket

sicking: why does UDP need to have a socket address?

Claes: for Multicast
... to listen to multicast addresses

sicking: if you're writing a Game using UDP
... you don't want to specify when you're creating the socket if you're going to use WiFi or 3G
... you want to use whatever data connection the user has

[ Claes shows a UDP listen multicast ... ]

mikko: i think zkis's suggestion

sicking: with optional arguments, you can't specify the second w/o the first

mounir: you could use an object

[ The IDL doesn't match the example ]

<dka> … you might want to specify which data connection if you want to explicitly use the mobile operator connection (if available) so that you can take advantage of operator network identity. For example: google play market does this so that it can determine if the user is using a network operator which has a direct-billing relationship with Google so that it can display the "pay to your bill?" option on the payment screen… (sorry for the interruption)

KF: UDP Multicast
... you can have things listen on one interface
... and provide a way to join the other

mounir: you should at least fix the IDL [to use Dictionary]

sicking: it'd be nice if you could specify remote address and remote port in the constructor

Claes: it seems the current proposal is to start w/ a separate socket API for SysApps while trying to align as much as possible w/ WebSockets
... i think we need explicit methods for join/leave-ing a multicast group

gmandyam: your example was m-search, right?
... how does that contrast with Discovery work on DAP

Claes: this could be the basis for a JS impl of Discovery

gmandyam: i'd suggest a different example

Claes: the reason we have this API is we want a flexible solution
... you could implement other service discovery solutions using this API

gmandyam: there's no reason to introduce this feature
... the original spec didn't have any mention of UDP multicast

mounir: we don't know if that will take off

<mounir> q lin

Claes: DAP's specification is open for Browsers, with a security model

gmandyam: there's a dispute as to how the security model is different

sicking: web apps have all the capabilities of web pages
... if the Discovery API covers the UC
... then SysApps apps will have that API

Claes: we might want to implement other discovery

gmandyam: i'd rather you take it back to DAP

KF: raw functionality is ...
... maybe there's no current UC from now
... maybe developer will need those features
... it's not about UC but about functionality

gmandyam: we already rejected Muilticast in WebRTC

dsr: another UC is games
... if you want to build an advertisement for games, you might need this

Claes: i can look at other examples

sicking: you don't need the UDP API to implement Discovery
... as an implementer, I can do this w/o the UDP API
... my backend has this
... it should never be an argument that another implementation can build on it
... generally speaking, as an implementation, I almost never implement one web feature on top of another
... UDP will require a stricter security model
... WebRTC, you can use anywhere

dsr: you have to identify the other person you want to talk to

Claes: another issue
... i didn't specify a close method
... but we need a way to kill the socket
... another issue: send buffering

<gmandyam> Josh, did you want me to scribe? - Giri

Claes: i've been looking at the mozilla socket api for firefox os

<scribe> scribe: gmandyam

<scribe> ScribeNick: gmandyam

KF: Send API is non-blocking.

<Marcosc> KF: please see my feedback to the list

<mounir> Chair: Wonsuk, Mounir

Klaus: Mozilla API has 2 limits: (1) buffer is almost full and data send is blocked, and (2) buffer is full

Jonas: The limit to the API is currently based on available memory
... And another limit is the buffer has to be under 64K

<mounir> Alexandre: there are a some concerns regarding security and exposing Raw Socket API to content but Microsoft and Mozilla have similar APIs, do we have experience feedback?

KF: How is the API protected from misuse in current OS's?

Jonas: It is the store's responsibility (Mozilla perspective)
... Regarding send buffer, the WS spec says basically that when you run out of memory then send an error. But the principle is that you must not block data due to some internal buffer limit. It will be annoying to developers to have to deal with different buffer limits, so memory should be the primary cause of a send error.
... Mozilla's send API returning false is not an error - it is an indication of a large buffer status. App should treat it as indication to hold back data.

thinker: Maybe we need an API to indicate how much data has been sent since the last send() operation

KF: We can add a method to enable that

Klaus: We'll consider adding this to the spec.

KF: Would like a read-only attribute that indicates IPV4 or IPV6 is being used.

Jonas: Provide a use case - then we can add.

<sicking> ack

KF: Would like address to be able to be spec'ed as URL rather than absolute IP address.

Jonas: There is an options property that contains all the socket options. This could be where the remote address and port could be discovered.

Klaus: Need stronger use cases for URL address specification. This issue is RBD for now.

<gmandyam_> ScribeNick: gmandyam

<gmandyam_> Klaus: Will add upgradeToSSL() method, as Exchange Server e.g. starts connection w/o TLS

<gmandyam_> Jonas: We don't need outgoing data type to be specified, and we should be allowed to send blobs.

<gmandyam_> ScribeNick: gmandyam_

Klaus: Agree that we don't need outgoing data type.

Jonas: In our implementation, we always return ArrayBuffers

Klaus: WebSockets provide more information, so it can provide an ArrayBuffer or blob.
... We should only return ArrayBuffers.
... We have resolved to have separate TCP and UDP socket interfaces - not an inherited I/F

zkis: Should we have a NAT traversal mechanism as part of the socket?

Klaus: I have not seen a socket API with such a feature.

zkis: The WebRTC spec has it built in.

Jonas: This API is meant for communication with legacy systems.

Klaus: I have not seen a socket API with such a feature.

Mounir: The Socket API is not build on DOM Requests. I suggest API's in this group should be based on DOM Futures.
... DOM Futures are going to have more traction than DOM Request. It will be used by Mozilla.

dsr: I'd like to switch to a common design pattern for APIs.

Mounir: DOM is more stable than any API in this WG. Webkit already has a patch.

- DRAFT -

SysApps

09 Apr 2013

Attendees

Contents