("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
>
> This *is* a dangerous ability to give, though it's equivalent to what
> users grant Skype or WebEx or Hangouts already by installing them
> (perhaps less, actually).
Agreed. App installation can never be free from danger. Regardless of any
security restrictions, you are granting the app perm
[Grrr. Silly tbird messing up quotes below... Resent because direct
posting from Emacs/Gnus keeps getting flagged as needing moderator approval]
>There _is_ a more powerful capability that we may want to have
available to
>a small handful of apps: "turn on the camera at some indefinite time
[Grrr. Silly tbird messing up quotes below... Resent because direct
posting from Emacs/Gnus keeps getting flagged as needing moderator
approval]
>There _is_ a more powerful capability that we may want to have
available to
>a small handful of apps: "turn on the camera at some indefinite time
On 4/17/2012 9:00 PM, Lucas Adamski wrote:
On 4/15/2012 1:32 PM, Adrienne Porter Felt wrote:
Would the following suggestion solve the problem?
* Applications may embed the "magic" photo or videorecord icons. As soon as
the user presses the button, the app
receives the data. A notification is
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
>The countdown annoyance could also be mitigated by adding an "always allow"
>option to the user countdown indicator or recording notification UI. That
>way a user can grant her favorite alternative Camera application persisted
>access to immediate stream access. Those two concepts combined solve
On 2012-04-24 9:50 AM, Randell Jesup wrote:
>a small handful of apps: "turn on the camera at some indefinite time
in the
>future, without user interaction at the time".
That need is exactly what some WebRTC apps need (think VoIP-like
service - replacement for Skype, Google Hangouts where you w
>
> >There _is_ a more powerful capability that we may want to have available
> to
> >a small handful of apps: "turn on the camera at some indefinite time in
> the
> >future, without user interaction at the time". The only use case I can
> >think of for that is an anti-device-theft system (turn on
We thought about this (it's in the proposal that we're currently
writing up), and there is no optimal solution. Implicit access
through trusted UI works for *most* use cases, but there is a special
set of edge cases---mostly security apps---that require permission for
future events where the user
[Grrr. Resent because direct posting from Emacs/Gnus keeps getting
flagged as needing moderator approval.
Re-resent to mailing list because posting to the newsgroup from
thunderbird went into a black hole...]
>There _is_ a more powerful capability that we may want to have
available to
>a small
I spent yesterday afternoon playing around with a lot of the most-popular
iOS camera apps. Most of the special effects applied to previews are
extremely simple: they change the contrast, blur everything but the center,
shade everything but the center, etc. It would be pretty simple to write
these
I've attempted to update the proposal per all of the recent discussion. I've
almost certainly missed something so please let me know what.
The controversial part of this proposal may be not allowing persistent access
to the camera from unauthenticated content, only from trusted apps. The rea
On Apr 13, 2012, at 10:37 PM, Adrienne Porter Felt wrote:
>
> On Fri, Apr 13, 2012 at 6:19 PM, Lucas Adamski wrote:
> Even from my casual poking around in app stores its clear many mobile camera
> apps are applying realtime custom filters in preview, so we'd need a pretty
> compelling case to
On 2012-04-17 6:05 PM, Lucas Adamski wrote:
On 4/17/2012 11:31 AM, Zack Weinberg wrote:
But we have an alternative ready-to-hand, without falling back to
permissions dialogs: video recording mode. If
WebGL-preview-until-user-authorizes-still isn't good enough, ask
for permission to record vide
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 11:31 AM, Zack Weinberg wrote:
> On 2012-04-14 9:57 PM, Lucas Adamski wrote:
>> On Apr 13, 2012, at 8:20 PM, Zack Weinberg wrote:
>>
>>> On 2012-04-13 6:37 PM, Adrienne Porter Felt wrote:
I'm trying to brainstorm a new way to fit trusted UI into the
user's normal flow that wo
On 4/15/2012 1:32 PM, Adrienne Porter Felt wrote:
> Would the following suggestion solve the problem?
>
> * Applications may embed the "magic" photo or videorecord icons. As soon as
> the user presses the button, the app
> receives the data. A notification is present as long as the app is
> re
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
On 2012-04-14 9:57 PM, Lucas Adamski wrote:
On Apr 13, 2012, at 8:20 PM, Zack Weinberg wrote:
On 2012-04-13 6:37 PM, Adrienne Porter Felt wrote:
I'm trying to brainstorm a new way to fit trusted UI into the
user's normal flow that would enable preview modification,
without throwing up a standa
[ 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
[ 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 ]
>The countdown annoyance could also be mitigated
> > 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
The countdown annoyance could also be mitigated by adding an "always allow"
option to the user countdown indicator or recording notification UI. That
way a user can grant her favorite alternative Camera application persisted
access to immediate stream access. Those two concepts combined solve the
The trick with a notification is that you want the user to be able to say
"ack! not wearing pants! stop!" before the app actually gets any data.
There are some ramifications of this:
* You probably want a software notification so that the user can click on
the notification and halt the recording.
Why wouldn't a hardware camera light and/or persisted "recording" indicator
(bar, light or otherwise) sufficient for both cases? The general idea
being that the user is now forced into being aware of the recording process
and can always terminate it in the same way.
Also, I think the idea of a fo
Would the following suggestion solve the problem?
* Applications may embed the "magic" photo or videorecord icons. As soon
as the user presses the button, the app receives the data. A notification
is present as long as the app is recording. The API provides an optional
preview window, but the a
On Apr 13, 2012, at 8:20 PM, Zack Weinberg wrote:
> On 2012-04-13 6:37 PM, Adrienne Porter Felt wrote:
>> I'm trying to brainstorm a new way to fit trusted UI into the user's normal
>> flow that would enable preview modification, without throwing up a standard
>> dialog. If anyone buys my case th
On 2012-04-13 6:37 PM, Adrienne Porter Felt wrote:
I do agree that the proposal is mostly the same: I think that the
permission should be granted at run-time, and there should be a
notification. However, the way that the actual permission prompt is shown
to the user is very important, and a run
On Fri, Apr 13, 2012 at 6:19 PM, Lucas Adamski wrote:
> Even from my casual poking around in app stores its clear many mobile
> camera apps are applying realtime custom filters in preview, so we'd need a
> pretty compelling case to discourage that entire class of functionality.
>
Yes. I had not
On Apr 10, 2012, at 5:59 PM, Adrienne Porter Felt wrote:
> 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 th
If you can have a way of accurately capturing a user's intent to use the
camera/location in an application, you don't need a prompt. The buttons
that Adrienne suggested in her original email (or at least the first email
I saw) let you do this, or get closer to it.
One of the reasons that existing
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
I think there's a huge misunderstanding here:
We're not advocating getting rid of the preview screen. What we're
advocating is that apps cannot receive camera data until the user has
pressed the button (which is owned by the OS).
In the current state of the world, some apps do not show preview s
> I'm not opposed to a trusted UI approach, but I don't think it is possible
> to provide adequate functionality using a "take picture" button. The
> preview point is spot on. Think about the camera apps people use - preview
> is a universal feature among them.
Apps can still have a preview win
I'm not opposed to a trusted UI approach, but I don't think it is possible
to provide adequate functionality using a "take picture" button. The
preview point is spot on. Think about the camera apps people use - preview
is a universal feature among them.
One solution might be to bundle the previe
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
Just as a case in point, we've now performed no less than four studies
on the types of information that users care about (i.e., the data
types that permissions purport to protect). We've found that users
have *significantly* greater levels of concern for things like taking
photos than they do for
On Thu, Apr 12, 2012 at 8:57 AM, Jason Miller wrote:
>
> What would be wrong with using the same UI from Geolocation access for
> something like camera access? An API method requests that the user grant
> camera permissions, which shows them the appropriate dialog to confirm.
> Events are fired
>
>
> This is a good point. Clickjacking could be addressed by designing a way
> to ensure an element is "on top" (a master z-index?) and also ensuring that
> the button is visible for at least {the time it takes for a human to
> recognize a button}+1 before it can be pressed.
>
>
No, this does no
On Wed, Apr 11, 2012 at 5:46 PM, Lucas Adamski wrote:
> How do we determine a size/shape/look&feel of this button that will work
> with a wide variety of apps? I browsed around a bit and it seems like
> camera apps use a wide variety of button shapes/colors for the shutter.
>
This is true, a st
On Apr 10, 2012, at 5:59 PM, Adrienne Porter Felt wrote:
> 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 th
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
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 into their
UIs but cannot write over them.
-- When the use
This discussion will be a bit more involved I think but I'd like to wrap this
up by Tue 17th EOD PDT.
Name of API: Camera API
References:
http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html
("Section 2 Scenarios") are use case
scenarios from the media capture task that is
62 matches
Mail list logo
