("Final" proposal, please reply to dev-weba...@lists.mozilla.org by COB
June 4 with any further comments )
Unless there are any further comments, I believe the previous proposal
still remain accurate. Note that in the absence of a magic button or
similar implementation in B2G, realtime preview
I wrote:
>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
>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
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
On 4/16/2012 11:14 AM, Jason Miller wrote:
That is one area where one could trust the app - the only way for it to
gain access to the camera would be to insert the button's DOM node facade
(this is a secure mechanism, because the DOM node is not the button itself,
it is only a placement indicator
>Actually, a lot of apps need access to the preview before starting to
>capture (an image or video). Any app that wants to do realtime
>transformations or effects will need the preview stream and then
>display it themselves. Also, there are a class of apps that do
>"pre-cording" so that you can c
At a high level the proposals are similar in the notification model - either
way we'd have a persistent indicator while the camera is being accessed.
The main difference is how permission to the camera is granted. Whether its
done with:
a) a combination of install-time and run-time UI "dialog"
On Apr 17, 2012, at 8:19 PM, Maire Reavy wrote:
> It seems that one thing we've discovered is that we can't separate the
> security design and discussion from the UX/UI design itself. Our UX/UI teams
> would tell us that the most critical and interesting pieces of the UX/UI
> design is not a p
On 4/17/2012 8:47 PM, Lucas Adamski wrote:
On 4/17/2012 3:43 PM, Maire Reavy wrote:
It feels like we are designing most of the chrome UX/UI for this feature on
this thread -- instead of just calling out
the security requirements for a UX/UI design of the chrome. If we are
designing the UX/UI
On 4/17/2012 3:43 PM, Maire Reavy wrote:
>
> It feels like we are designing most of the chrome UX/UI for this feature on
> this thread -- instead of just calling out
> the security requirements for a UX/UI design of the chrome. If we are
> designing the UX/UI on this thread, then we need
> to g
On 4/17/2012 4:15 PM, Randell Jesup wrote:
On 4/16/2012 11:14 AM, Jason Miller wrote:
That is one area where one could trust the app - the only way for it to
gain access to the camera would be to insert the button's DOM node
facade
(this is a secure mechanism, because the DOM node is not the bu
[ Reposting via mail interface because attempts to cross-post responses
in News appeared to cause my message to end up in approval queues for
the relevant mail lists - and no one appears to have approved them, at
least not in security and B2G ]
>Actually, a lot of apps need access to the previ
> > If the user picks 'no', a well-written app should allow other
> > functionality to work, but won't be able to use the camera.
Too many developers fall into this trap: If a user installs a camera
application (some basic alternative camera), but denies it camera access -
why would the OS even
+1 to the permissions model.
A responsive permissions model could help build any kind of app, and
giving the user total control over what it installs.
On 16/04/2012 16:27, "Mike Habicher" wrote:
>
>* Permission 1: Allow this app to use the camera to take pictures/video?
>yes/no
>
>If the user p
ent: Sunday, 15 April, 2012 4:32:06 PM
> Subject: Re: [b2g] WebAPI Security Discussion: Camera API
>
> Would the following suggestion solve the problem?
>
> * Applications may embed the "magic" photo or videorecord icons. As
> soon
> as the user presses the button,
That is one area where one could trust the app - the only way for it to
gain access to the camera would be to insert the button's DOM node facade
(this is a secure mechanism, because the DOM node is not the button itself,
it is only a placement indicator). The OS then observes the positioning,
det
>
>
> but yes, adrienne - perhaps unintentionally - did actually say that
> it should be userspace. allow me to quote again the relevant part of
> what adrienne (hello adrienne) said:
>
> On Sun, Apr 15, 2012 at 9:32 PM, Adrienne Porter Felt
> wrote:
> > Would the following suggestion solve the
> NO. it *has* to be "the Operating System embeds the 'magic' photo or
> videorecord icons". you CANNOT do "security by cooperation in
> userspace". this isn't firefox: it's a completely different ballgame.
This is the same as text input within the browser on Android - there is a
DOM element t
On Sun, Apr 15, 2012 at 5:30 PM, lkcl luke wrote:
> On Sun, Apr 15, 2012 at 9:32 PM, Adrienne Porter Felt
> wrote:
> > Would the following suggestion solve the problem?
> >
> > * Applications may embed the "magic" photo or videorecord icons.
>
> NO. it *has* to be "the Operating System embeds
Regardless, this is not incompatible with what we are proposing.
Serge
Sent from my iPhone, hence the typos.
On Apr 13, 2012, at 8:27, Jim Straus wrote:
> Actually, a lot of apps need access to the preview before starting to capture
> (an image or video). Any app that wants to do realtime tr
Actually, a lot of apps need access to the preview before starting to capture
(an image or video). Any app that wants to do realtime transformations or
effects will need the preview stream and then display it themselves. Also,
there are a class of apps that do "pre-cording" so that you can cap
Again, this is a complete misunderstanding. We are not requiring a button to
start preview. We are requiring a button to start *capture*. No current camera
app, of which I am aware, gets access to the preview data before the user
actually starts recording or snaps a photo. This would completely
CC jcarpenter
No mobile camera app I know of requires the user to press a button to start
an image preview prior to capturing an image, the "viewfinder" starts as
soon as you open the app. This requirement would really break the UX of the
current B2G camera app. Preventing UI elements being overla
You want the application to be able to overlay things on top of the
picture. Think a barcode scanner, an OCR system, an AR app and so on. OS
imposed previews might be a problem.
--Dev
On 11 April 2012 01:39, Adrienne Porter Felt wrote:
> No, in our proposal, it's up to the app to provide a prev
No, in our proposal, it's up to the app to provide a preview or the final
result (or not). The user knows what his or her phone is pointing at and
whether the context is appropriate. A non-malicious app will provide a
preview on its own; a malicious app might not, but the user won't click the
ico
El 11/04/12 02:59, "Adrienne Porter Felt" escribió:
>I'd like to propose the following based on discussions at Berkeley & with
>others about camera access:
>
>-- The OS provides two trusted UI buttons. One has a photo icon, and the
>other has a recording icon. Applications can embed these icons
26 matches
Mail list logo
