W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

[Bug 17417] Define a security model for requesting access to the MIDIAccess interface

From: <bugzilla@jessica.w3.org>
Date: Tue, 25 Dec 2012 23:40:15 +0000
To: public-audio@w3.org
Message-ID: <bug-17417-5429-eJc0Doop3J@http.www.w3.org/Bugs/Public/>

Marcos Caceres <w3c@marcosc.com> changed:

           What    |Removed                     |Added
                 CC|                            |w3c@marcosc.com

--- Comment #13 from Marcos Caceres <w3c@marcosc.com> ---
> This level of tweakiness is exactly what I'm worried about.  I don't think
> any sane user will walk through the list of their available MIDI ports and
> carefully select which they're comfortable "sharing" with a web application
> - they'll either say OK or not OK. 

Right, but there can be multiple representations of this dialog. I personally
like having the ability to choose, if only because it allows me as a user to
see that everything is plugged in (I know, different use case... but it's still
related because I may choose to unplug something at this point for
privacy/personal reasons). 

Another representation could be like the geolocation permission bar, but with a
way to expand it to give the view that I linked to. 

> And even that, I'd like to minimize as
> much as possible, and I want the spec to continue to make it clear that the
> implementation does not NEED to prompt the user with UI; this may come
> inside a web app that has permissions already set, or in a loose environment
> that has already had MIDI access approved.

Agree. This would be good for just output. For example, in a game, it would
suck to have to ask the user if they want to hear MIDI sound effects.

Regardless, I think the point is that there needs to be enough flexibility in
the security model to allow for these various scenarios (and that both
implementors and users understand the risks ... I know, d'uh Marcos!). 

I think the current text gives that flexibility already and anything else might
be overreaching.

You are receiving this mail because:
You are on the CC list for the bug.
Received on Tuesday, 25 December 2012 23:40:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:15 UTC