WebAPI Security Discussion: Camera API - mozilla.dev.webapi

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
mozilla.dev.webapi
Message from discussion WebAPI Security Discussion: Camera API
Path: r9ni45875pbh.0!nntp.google.com!news2.google.com!news1.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.mozilla.org!news.mozilla.org.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 11 Apr 2012 19:47:18 -0500
Received-SPF: none (mozilla.com: No applicable sender policy available)
	receiver=notorious.mozilla.org; identity=mailfrom;
	envelope-from="ladam...@mozilla.com";
	helo=zimbra1.shared.sjc1.mozilla.com; client-ip=10.2.72.15
Subject: Re: WebAPI Security Discussion: Camera API
Mime-Version: 1.0 (Apple Message framework v1257)
From: Lucas Adamski <ladam...@mozilla.com>
In-Reply-To: <CA+yvPmfEV_1nOHQLGOwtQKq+_baVdDH=QiNNUsPk_0k2KJ4Q=g@mail.gmail.com>
Date: Wed, 11 Apr 2012 17:46:59 -0700
References: <4F84D516.8030702@mozilla.com>
	<CA+yvPmfEV_1nOHQLGOwtQKq+_baVdDH=QiNNUsPk_0k2KJ4Q=g@mail.gmail.com>
To: Adrienne Porter Felt <a...@berkeley.edu>
Cc: "dev-weba...@lists.mozilla.org" <dev-weba...@lists.mozilla.org>,
	Devdatta Akhawe <devda...@cs.berkeley.edu>,
	"Matthew S. Finifter" <finif...@cs.berkeley.edu>,
	David Wagner <d...@cs.berkeley.edu>, Serge Egelman <se...@guanotronic.com>,
	"dev-web...@lists.mozilla.org" <dev-web...@lists.mozilla.org>,
	Franzi Roesner <fra...@cs.washington.edu>,
	"dev-secur...@lists.mozilla.org" <dev-secur...@lists.mozilla.org>,
	dev-b2g <dev-...@lists.mozilla.org>
Precedence: list
Approved: dev-web...@lists.mozilla.org
Newsgroups: mozilla.dev.webapi
Message-ID: <mailman.20650.1334191638.31724.dev-web...@lists.mozilla.org>
Lines: 64
NNTP-Posting-Host: 63.245.208.166
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

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:
>=20
> -- 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 user presses one of these buttons, a photo is taken or
> recording begins.  The result is returned to the user.
> -- When the app takes a photo, some notification briefly appears on =
the
> screen (on top of any other UI, including full-screened apps) to =
indicate
> that a photo was just taken.
> -- When the app is recording, a notification appears on the screen for =
the
> duration of the recording.  Again, the notification is on top of any =
other
> UI, including full-screened apps.  We recommend the notification be a
> blinking red light since that is a standard warning that a device is
> recording.
> -- Applications can continue recording in the background but the
> notification will persist.
> -- If the user clicks on the recording notification (ie the blinking =
red
> light) he/she is given the option of halting the recording.
> -- Applications can register timeouts for taking photos instead of
> recording, but the UI will make it appear as if the app is recording =
the
> whole time.  This is to satisfy apps that take time-lapsed photos =
without
> additional user intervention (e.g., an app that you mount to the front =
of
> your bike that takes photos at 5 minute increments), but without =
incurring
> the battery drain of needing to record the whole time to catch those =
frames.

Hi Adrienne,

So after sleeping on this I think this model is pretty compatible with =
what I sent out, modulo the idea of the "magic buttons".  I don't have a =
strong opinion about this from a security standpoint, but I do wonder =
about the feasibility of enforcing a specific button style.  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. =20

What about an app that wants to take a picture on a time delay, say once =
a minute (but doesn't want a video feed)?

It seems like the consistent recording notification indicator is the key =
security mitigation.  Is the required button due to concerns a user =
might be tricked into enabling the camera without realizing they are?  =
Or is this a more specific concern for web content rather than installed =
apps?  As with anything HTML, clickjacking is a concern.
  Lucas.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
