On Wed, Apr 18, 2012 at 12:14 PM, Mounir Lamouri <[email protected]> wrote:
> The general idea of using buttons seems quite odd and rather not secure. > What make <input type=file> secure is clearly not the button it's the > fact that it shows a UI that tells the user to select a file. That UI is > from the OS so the user knows it and understand it will give sensitive > information to the page. Nowadays, you can even trigger that UI using > .click() in most browsers (it has to come from a user action, for > security reasons). > > I haven't followed the thread about Camera API security model but a > button wouldn't solve anything. First of all, it can be hidden. You can > easily put another element on top of it and make that element not > clickable (pointer-events: none;) thus, when the user would click, it > would take a picture. It's very hard to prevent that kind of tricks AFAIK. > If we want to do something similar to <input type=file>, we should have > an UI that pops up everytime an app asks for a picture from the camera. > In that UI, the user would see the current camera view and would have a > "take a picture to send to this website" button. It should be > self-explanatory. > I assert that it is possible to build a "magic button", although it will require care. An application puts a placeholder like <camera type="front"> in order for the element to appear, and CSS cannot be applied to the element. Its z-index is fixed at the highest z-index so it cannot be overlaid, and you can disable the ability to fire its click(). You can enforce that there must be a very short delay (a few ms?) before the UI element becomes active to prevent apps from throwing it up on the screen really quickly, where the user expects another button to be. Even if that does not end up being the best approach for the Camera API, such a UI element might be useful elsewhere (e.g., as an option for SMS apps that don't want a full-screen SMS approval dialog). > IMO, most applications should actually use a Web Intent/Web Activity to > do that without any privilege: the intent/activity would run the Camera > app and then the user would understand what this is about. However, the > Camera App will require a direct access to the camera so accessing the > camera via the Camera API should be easy (even if that requires explicit > consent). > This will break a lot of applications: many applications want/need custom UI around the camera, so transitioning to the camera app and then returning a photo does not address many use cases. > > Can all permissions be moderated by user initiation? Will apps be made > less convenient by making the user click a "Battery" button before they > can access the state of the battery? > > That would be a *very* bad idea. You can't have a general policy for all > APIs. Some should have no permissions, some should require user > interaction, some should require explicit permissions some might have > other restrictions. > I agree with this. The current approach (looking at them individually) is much better than the past one-size-fits-all approach to security. _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
