search

WebAudio / web-midi-api

The Web MIDI API, developed by the W3C Audio WG
http://webaudio.github.io/web-midi-api/
Other
323 stars 50 forks source link

Should sysex flag be on access to port somehow, rather than system-wide? #114

Closed cwilso closed 9 years ago

cwilso commented 9 years ago

Would limit security scope more precisely.

agoode commented 9 years ago

Sounds like a good idea. If so, then this is another justification for open, from issue #75.

bome commented 9 years ago

agree. Maybe as an attribute MIDIOptions options in the MIDIPort interface?

toyoshim commented 9 years ago

Do you have any scenarios that port based permission works fine? Originally permission was introduced to protect user devices from attacking scripts running on malicious sites. I have no idea about how fine grained permission contribute to security.

cwilso commented 9 years ago

I was thinking of it as I'd be happy to allow persistent access to my Livid Instruments CNTRLR from https://livid.com/, but might not be as happy to give them sysex access to all my instruments.

toyoshim commented 9 years ago

Hum... this is a big change in terms of implementation and UI/UX aspect.

Even if you allow permission only against a specific device, the site may be able to send sysex against other devices if a security attack succeeded. Of course, it would be very difficult, but potentially possible. Origin-based permission can protect your devices even in such cases at least on Chrome.

Anyway, if we introduce a port based permission, passing MIDIOptions to open() sounds reasonable. Also, even so, I prefer to keep on having system-wide permission on MIDIAccess. That seems to work better on online DAW apps.

cwilso commented 9 years ago

Hmm. Well, we could put the request (to send/receive sysex) as a separate async request on the flag, so without prompting the system doesn't get sysex, but if you ask you can get that access on one object or a class - like how the BT system does. If a vendor doesn't want to implement separate per-port sysex, any request to sysex could prompt for all ports. The current structure forces sysex access to be all-or-nothing.

On Thu, Jan 29, 2015 at 5:47 PM, Takashi Toyoshima <notifications@github.com

wrote:

Hum... this is a big change in terms of implementation and UI/UX aspect.

Even if you allow permission only against a specific device, the site may be able to send sysex against other devices if a security attack succeeded. Of course, it would be very difficult, but potentially possible. Origin-based permission can protect your devices even in such cases at least on Chrome.

Anyway, if we introduce a port based permission, passing MIDIOptions to open() sounds reasonable. Also, even so, I prefer to keep on having system-wide permission on MIDIAccess. That seems to work better on online DAW apps.

— Reply to this email directly or view it on GitHub https://github.com/WebAudio/web-midi-api/issues/114#issuecomment-71978621 .

toyoshim commented 9 years ago

I took a look on Web BT spec. It should be one of the most similar case.

There are two differences between BT and MIDI.

1) BT has a UUID to identify a device, but MIDI doesn't 2) With BT API, user need to query for enumerating device explicitly. It can be the time to prompt the selection UI. But With MIDI API, device can appear at any time via DeviceConnectionEvent.

For 1), We may be able to use a kind of hash that based on MIDIPort attributes, e.g., id+name, or something. It's impossible to identify legacy DIN based MIDI. But it isn't so important.

Because of 2), we can not take the same approach with the BT API.

I'm thinking a better way, but for now, my idea is something like this;

jyasskin commented 9 years ago

In (2), a Bluetooth device can also appear at any time; we (the API designers) just choose not to auto-grant access to a new device so that end-users have control over what access their sites get.

cwilso commented 9 years ago

There's also a significant difference in that (we've already determined) it's not a problem to auto-grant non-sysex access to all MIDI devices.

On Fri, Jan 30, 2015 at 11:03 AM, Jeffrey Yasskin notifications@github.com wrote:

In (2), a Bluetooth device can also appear at any time; we (the API designers) just choose not to auto-grant access to a new device so that end-users have control over what access their sites get.

— Reply to this email directly or view it on GitHub https://github.com/WebAudio/web-midi-api/issues/114#issuecomment-72129991 .

toyoshim commented 9 years ago

Yes, In Web MIDI, MIDIConnectionEvent is notified when a new device is connected, and the device appears in MIDIInputMap or/and MIDIOutputMap automatically without any extra operations. My understanding is that BT needs another requestDevice call to access newly appeared devices.

jyasskin: In case of Bluetooth, can you cache user granted device not to prompt at the next time? Or user just needs to grant permission whenever a site requests to use devices? If you can cache, what happens if new devices appears in the next time. Also, did authors discuss collaborating with Permissions API (https://w3c.github.io/permissions/) before?

jyasskin commented 9 years ago

We haven't spec'ed this yet, but the idea is to save the devices the user has paired with a site, and provide those devices as BluetoothDevice instances somewhere like navigator.bluetooth.devices on subsequent page loads. We'll also probably provide "device in range" and "device out of range" events for these devices. ("in range" rather than "connected" because you don't have to create a connection to every device you could connect to.)

Pages will need to give the user a button to press in order to search for new, unpaired BT devices. This may not apply to normal MIDI access, assuming our Privacy folks are ok with it, but it could apply to sysex access.

We have been talking to @mounirlamouri about the Permissions API. I believe the plan is for us to expose the permission state in our own API and sync up with the uniform API later.

mounirlamouri commented 9 years ago

Unless the Permissions API isn't shipping yet, I think it would be great to have the Permissions API taking care exposing permissions if there permissions to expose and not have to duplicate the information in two APIs.

cwilso commented 9 years ago

Strong feedback from security that the port-level is not a good place to put this. Permissions API exposure would be fine, but then we'd have to remove something that's already there in lieu of an API that's not shipped yet, yes?

mounirlamouri commented 9 years ago

Is any browser shipping webMidi yet? My understanding is that Chrome is the only browser actively working on this. When is the target version for shipping for the moment? Permissions API is expected to ship soon. Hopefully, M43.

cwilso commented 9 years ago

I'm getting concerned about the number of new technologies Web MIDI is reliant upon the implementation of - promises, maplike, permissions....

On Mon, Feb 9, 2015 at 10:30 AM, Mounir Lamouri notifications@github.com wrote:

Is any browser shipping webMidi yet? My understanding is that Chrome is the only browser actively working on this. When is the target version for shipping for the moment? Permissions API is expected to ship soon. Hopefully, M43.

— Reply to this email directly or view it on GitHub https://github.com/WebAudio/web-midi-api/issues/114#issuecomment-73562204 .