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

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

--- Comment #17 from Chris Wilson <cwilso@gmail.com> ---
(In reply to comment #16)
> (In reply to comment #12)
> > 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.  And even that, I'd like to minimize as
> > much as possible
> 
> In general I agree, but I can think of one case where a user might want to
> have more fine-grained control. Suppose they are happy to share their input
> devices (keyboards, pads etc) and the output devices that can be played
> (including bank switch etc) *except* for a device that can be written to
> destructively (e.g. can have new patches or samples uploaded, loosing the
> previously stored ones).

If someone really wants this power, of course it's not my place to say no.  My
point is that this is a very advanced tweaky configuration, and experience
leads me to believe 99.99...% of users will not mess with such things (kinda
like people hand-editing their security zones in IE - super-useful tool, few
people mess with it.)  I'm not say I want to prevent a UA from working this
way, I am saying I do not want to mandate it.  The current spec would
absolutely let a UA selectively decide to expose each port independently and be
compliant.

> But maybe that is better addressed as write access or disabling sysex rather
> than port-by-port.

It would have to be sysex - there's no "write access", other than access to
output ports.  And you could selectively enable sysex port-by-port.  That would
be marginally acceptable (there are still a lot of devices that use sysex
heavily for normal operatio

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Tuesday, 8 January 2013 17:51:44 UTC