On 04/17/2012 10:35 PM, Jim Straus wrote: > What does an upload button look like (that is distinguishable from other > buttons?) How does the upload communicate where it is going to upload that is > not spoof-able by an application? Can an upload button protect from an app > uploading other information?
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. 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). > 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. For example, the Battery API should clearly *not* require user interaction. If my email app want to check for my battery life to know if it should try to fetch email, I clearly don't want to have to click somewhere... Another example is the Screen Orientation API that requires to be fullscreen on regular content and doesn't have any restriction for installed apps. Also, being able to received SMS shouldn't require user interaction and shouldn't be implicit. Any sane user would like its direct consent for an app to do that. In general, I think the current approach that is having a discussion for each API is very good: that way, we can see individually what would be the best way to solve each problems. If we want to have as less explicit user consent, that seems a sane goal but I really doubt we will be able to have 0 prompts. -- Mounir _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
