>Apps on other devices do get access to the preview to be able to do
>things with it like providing effects. The proposal to use WebGL
>shaders to modify the preview seems to ameliorate that issue in a way
>that other platforms aren't using (which is good). An API to open the
>preview that takes an optional shader would allow a preview to be shown
>and effects added without providing the preview data to the user.
>Overlays would be allowed (yes, a developer could completely hide the
>preview, but why bother when they can just not invoke the preview).
>And the magic button to allow access would keep the content from
>accessing the image stream before the user has "granted permission"
>using the magic button.
>The questions seem to me are 1) is the shader sufficient and secure
>enough for developer needs and 2) can we design a magic button that is
>secure and distinctive enough for developer needs and sufficiently
>distinctive to the user to let them know what they're allowing access
>to.
Security on the shader: someone else needs to answer. I do wonder about
performance of using a shader, and possible bugs - our WebGL interface
is less than perfect; my Mozilla-issued-last-summer fancy laptop cannot
use accelerated WebGL.
It does mean the app cannot do any sort of processing on the image:
white balance, object detection, etc, etc all have to be handled by the
automatic systems or applied with by user selection. May not be an
issue. (No "smile detection" shutter (or happens after button press), no
object/face-tracking focus/contrast/etc tricks in preview, etc).
There's also the "how" we do preview in a shader. Normally, for
streaming preview we'd use getUserMedia() (which is where we can hook
permissions, camera selection, etc) and take the MediaStream and feed it
to whatever (video elements, peerconnections, etc). I presented a slide
deck at the IETF RTCWEB interim in Feb. on "MediaStream Security" where
we proposed using cross-origin protections to protect the data in a
mediastream from untrusted JS apps (and even allow MediaStream
Processing in JS workers, sandboxed by cross-origin protections against
feeding data back to the app from the JS worker).
>I guess the final question is: can we generalize this for other APIs.
>I would prefer not to go through all the effort of making a secure
>camera without permissions prompts just to have everything else using
>permission prompts. That would make users feel insecure about the
>API(s) that use magic UI infrastructure.
>
>I'm guessing we could come up with magic UI for a class of permissions:
>microphone button, phone handset button for audio/voip, phone handset
>button for dialer, envelope button for email, globe or target button
>for geolocation, bluetooth icon button for bluetooth, usb icon button
>for usb, etc. I'm not sure about things like storage, permissions API,
>settings API, etc. Maybe those are handled more at the install/first
>launch stage and not at runtime. And background apps or services are a
>whole different question. -Jim Straus
Before we go there ("magic buttons", etc), we need to decide if these
are even technically feasible. The number of possible attacks involving
hidden/transparent elements, moving/re-laying out, etc, etc seems
immense and likely a rats-nest of future vulnerabilities - and you're
going to end up relying on time as part of your security flow
(i.e. don't enable button for x ms/s after it gets to a position) - I
just can't see that as a really safe (or user-friendly) UI.
I myself in the WebRTC internal discussions proposed "magic buttons"
last fall, but after discussing it internally, I agreed there was no way
I could see leading to a "safe" implementation, and if it was "safe"
users would probably hate it.
If they can be made to work... then maybe I can be convinced. I'm less
enamoured of them than I was back then. No matter how many you try to
think of, there will be uses that don't fit your
classes/iconography/etc, and lead to a mildly confused UI ("to adjust UI
brightness automatically using the camera, please hit the 'take video'
button"). Bad example, there are better ones.
--
Randell Jesup, Mozilla Corp
remove ".news" for personal email
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
