Audio Working Group Teleconference -- 10 Jan 2013

<trackbot> Date: 10 January 2013

3) MIDI security Model

<ack> i'm also on the call, muted due to cold

<scribe> Agenda: http://lists.w3.org/Archives/Public/public-audio/2013JanMar/0029.html

<scribe> Scribe: olivier

Midi Security Model

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17417

cwilso: long standing issue

… not sure how concerning the security/privacy issue is wrt midi access

… current model is asynchronous. midi system can mask but if user or user agent approves, then midi access exposes your devices

… earlier spec version said you MUST prompt for access

… currently says MAY

… less tedious

… popup asking each time would be very distracting

… Marcos asked how we could tweak model to mask some

… more flexible

Marcos: trying to get back to fundamental assumption

… of having midi access object does request, then gives you access to inputs and outputs

… model kind of weird

… fundamental difference with midi api is that permissioning is done on per-script basis

… rather than per site basis

Cwilso: you are pressuming that every script would ask for permission
... not detailed in the spec how permission works

… in some cases you may not care

<Marcos> https://gist.github.com/4384745

Marcos: example case I was considering (see link above)

… was trying to access system default port

… shouldn't need to request access for that, is like playing an audio file

Cwilso: not necessarily true though

… you could send commands that would erase settings etc

… you could actually expose input access without asking

… there is still the fingerprinting issue

Joe: that is a valid concern

Marcos: getting back to gaming use case

… assuming something malicious happens

… what could I send that could cause issues

… just using the system port

CWilso: not sure there is much you could do. Not sure they even have sysex support

… would only be making noise

… this is a very minor scenario though

… best you can do with midi in this scenario is to play with general midi

… simpler to just play audio sound from disk

Joe: don't think that game devs are all likely to use MIDI at all

… our use case is more people working with music production

… rather than apps needing generic sound output

… and wouldn't be using generic port

… those would be at risk, offering sysex support

CWilso: agree with that

Marcos: understand my use case is not very valid then

… second case, the model is correct to give UA a way to take away access

… other question is being about to hot swap / hot plug

CWilso: that becomes a problem primarily if you have specific devices you give access to

… we had at some point specific events for that

… hard to implement on some systems

… you just don't get notification for such events

Olivier: asks for clarification

Joe: similar as file storage

CWilso: we really don't know how big of an issue this is

… question is whether you need to give granularity on what you are giving access to

… scenarios where you want fine granularity are few

… in essence: would complexify the model

… better to let them choose

Cwilso: similarly, in iOS you can't get access to web audio without user interaction

Joe: tradeoff between simplicity and granularity. In my opinion granularity should be coarse

… don't think it will happen casually as you visit web pages

… limited to applications

<cwilso> Incidentally, Marcos: the "request an object, then act just on that" model is very similar to Web Audio. (WA doesn't use it as a security point, though)

… skew the model towards blanket conditions

Doug: agree with joe

Olivier: agree with fairly coarse

… and see if scenarios require something finer

Marcos: [missed]

CWilso: yes, UA could give that option

… but most users don't ever touch that level of granularity

Marcos: makes sense in my experiments to have fine-grained access

… but apart from that it makes sense if everything is set up to have coarse control

Marcos?: seem to have general agreement

Olivier: does current spec reflect current agreement

Cwilso: I think so

Marcos: still concerned about how the current prose is translated into API

… instead of using navigator.midi.requestinput (or output) it uses requestaccess

<Marcos> https://gist.github.com/4384745

… wondering if we could have navigator.midi object which could be used to make requests

… need to prototype it

… e.g. https://gist.github.com/4384745

Joe: it's a case of trying to get something and if you don't get it, ask permission

Cwilso: could we just expose what you have access to

… this design ends up having state of whether you have access, but you don't have a way to query it

[general agreement]

Cwilso: goal is to have asynchronous call to check if you have access

Marcos: gets us back to where we are with current API

CWilso: have to think about how we can restructure to have synchronous/asynchronous report

… would be better to go that route, especially if we don't care too much about granularity

Marcos: agree that current model works, no big deal with it

… the model is just a little bit strange, just a bit uncomfortable

… but it works

Cwilso: best thing may be to think about how would structure more granular system

… and see what that's like before closing this issue

… necessary to take a closer look at it

Marcos: onmessage could be used

Joe: quota request mechanism for file storage takes a callback

… callback invoked immediately if you have previously requested

… may be wise to assume that something like that may be necessary

<joe> https://developers.google.com/chrome/whitepapers/storage#managing_quota

Jussi: don't really see value in having asynchronous OR synchronous

… better to be always asynchronous

Joe: agree

Marcos: agree on request part

… not necessarily agree with asynchronous when you are just getting ports themselves

CWilso: currently you don't have asynchronous way to get port

… only asynchronous to get midi object

<Marcos> out = midi.outputs();

<Marcos> midi.request("outputs", success, fail);

Marcos: I was thinking you could do the check first

Joe: don't see the advantage of that

Doug: some of this could be discussed on list

<scribe> ACTION: CWilso to document options re security model (asynchronous, synchronous, granularity) onto bugzilla [recorded in http://www.w3.org/2013/01/10-audio-minutes.html#action01]

<trackbot> Error finding 'CWilso'. You can review and register nicknames at <http://www.w3.org/2011/audio/track/users>.

<scribe> ACTION: CWilson to document options re security model (asynchronous, synchronous, granularity) onto bugzilla [recorded in http://www.w3.org/2013/01/10-audio-minutes.html#action02]

<trackbot> Error finding 'CWilson'. You can review and register nicknames at <http://www.w3.org/2011/audio/track/users>.

<scribe> ACTION: ChrisWilson to document options re security model (asynchronous, synchronous, granularity) onto bugzilla [recorded in http://www.w3.org/2013/01/10-audio-minutes.html#action03]

<trackbot> Created ACTION-54 - Document options re security model (asynchronous, synchronous, granularity) onto bugzilla [on Chris Wilson - due 2013-01-17].

github

Marcos: at the moment we have a number of version of specs

… some on w3c server, some on github (living in master branch)

… Tobie from FB has document on how you can only have a gh-pages branch which is then always available as latest/greatest snapshot

… could represent the latest editor's draft

… gets rid of the problem of having to maintain 2 branches

… dvcs.w3.org version can then be redirected

… advantage is that we'd have all versioning on GH, ability to pull in issues etc

… official snapshots can still be published on w3.org

… nice thing is the usability that people get

… more user friendly

Olivier: as chair I can live with either

… how about editors?

Marcos: easier for me to to pull request

… nice way to see changes in the request

… easier code review

… definitely easier for contributions

CRogers: comfortable sticking with mercurial. I occasionally get a diff but don't get patches very often

… mercurial not significantly inferior to git

Olivier: notes we don't have to migrate both

CWilso: not sure you can redirect the raw-tip from dvcs

… absolutely agree with Chris that toolwise git and hg are equivalent

… github has great community

… would be happy to move midi space to github

… would work well

… leave webaudio stuff where it is

Jussi: would be happy to move specs and issues

<scribe> ACTION: Thierry to ask systeam about dvcs -> github redirect [recorded in http://www.w3.org/2013/01/10-audio-minutes.html#action04]

<trackbot> Created ACTION-55 - Ask systeam about dvcs -> github redirect [on Thierry Michel - due 2013-01-17].

Jussi: I have tool to migrate issues to GH

<scribe> ACTION: Jussi to migrate issues to bugzilla [recorded in http://www.w3.org/2013/01/10-audio-minutes.html#action05]

<trackbot> Created ACTION-56 - Migrate issues to bugzilla [on Jussi Kalliokoski - due 2013-01-17].

<scribe> ACTION: Jussi to update midi draft to mention issues to be sent to github [recorded in http://www.w3.org/2013/01/10-audio-minutes.html#action06]

<trackbot> Created ACTION-57 - Update midi draft to mention issues to be sent to github [on Jussi Kalliokoski - due 2013-01-17].

<scribe> ACTION: Olivier to clean up midi actions on bugzilla once they have been migrated [recorded in http://www.w3.org/2013/01/10-audio-minutes.html#action07]

<trackbot> Created ACTION-58 - Clean up midi actions on bugzilla once they have been migrated [on Olivier Thereaux - due 2013-01-17].

- DRAFT -

Audio Working Group Teleconference

10 Jan 2013

Attendees

Contents

3) MIDI security Model

Midi Security Model

github

Summary of Action Items

Scribe.perl diagnostic output