WebAPI meta: permission prompts considered harmful

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

WebAPI meta: permission prompts considered harmful

Zack Weinberg-2
I feel very strongly that we should initially attempt to design a system
where there are no install-time permission prompts, and more generally,
no prompts for which "remember this decision" is a desirable option.

As Adrienne has been pointing out, permissions dialogs in general do not
work.  They ask a non-expert user to make a security-critical choice,
based on inadequate information, at a point in the workflow where most
users will actively *avoid* stopping to think. (I don't have studies to
hand, but I'm sure Adrienne does.)  From the UX perspective *and* the
security perspective, anything we can do to get away from them is worth
doing.  And we have a known better alternative: implicit, one-time-only
deduction of permission from intentional user actions, such as pressing
a "take photo" button.

I'm frustrated by the Camera API discussion because there seem to be a
bunch of people who don't even want to *try* to do something better.
Sure, there exist applications for which it's not obvious how to fit
them into an only-if-the-user-pressed-the-button-just-now paradigm, but
that doesn't mean we should give up!  (I'm pretty sure we can fit all
camera use cases into a combination of "you can draw over the preview
but you can't see the results" and "video recording mode".)

Let's treat permissions dialogs as an option of last resort.  Let's only
do them if we really can't find any other way for a particular privilege.

zw
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI meta: permission prompts considered harmful

Adrienne Porter Felt
+1 to everything Zack said

Standard runtime dialogs that ask for Allow/deny are familiar, so system
designers seem to like them -- but a lot of literature establishes that
they don't work.  Android tried moving them to install-time, which works
for a small minority of users sometimes. Unfortunately, they're either
ignored or impossible to interpret without context.  (People who aren't
programmers have a hard time imagining how install-time permissions connect
to what applications actually do.)

There are certain resources that might need to be represented as either
install-time permission prompts or standard runtime dialogs.  (For example,
I can't think of another way to represent the ability to read all of the
user's text messages.)  However, I view these as last resorts in the
toolbox.  A very small number of prompts/standard dialogs will be OK.  OTOH
if a new one is added along with each new WebAPI, we end up with
dialogs/prompts that are completely useless because people will see them
all the time.

On Tue, Apr 17, 2012 at 8:18 PM, Zack Weinberg <[hidden email]> wrote:

> I feel very strongly that we should initially attempt to design a system
> where there are no install-time permission prompts, and more generally, no
> prompts for which "remember this decision" is a desirable option.
>
> As Adrienne has been pointing out, permissions dialogs in general do not
> work.  They ask a non-expert user to make a security-critical choice, based
> on inadequate information, at a point in the workflow where most users will
> actively *avoid* stopping to think. (I don't have studies to hand, but I'm
> sure Adrienne does.)  From the UX perspective *and* the security
> perspective, anything we can do to get away from them is worth doing.  And
> we have a known better alternative: implicit, one-time-only deduction of
> permission from intentional user actions, such as pressing a "take photo"
> button.
>
> I'm frustrated by the Camera API discussion because there seem to be a
> bunch of people who don't even want to *try* to do something better. Sure,
> there exist applications for which it's not obvious how to fit them into an
> only-if-the-user-pressed-the-**button-just-now paradigm, but that doesn't
> mean we should give up!  (I'm pretty sure we can fit all camera use cases
> into a combination of "you can draw over the preview but you can't see the
> results" and "video recording mode".)
>
> Let's treat permissions dialogs as an option of last resort.  Let's only
> do them if we really can't find any other way for a particular privilege.
>
> zw
> ______________________________**_________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/**listinfo/dev-security<https://lists.mozilla.org/listinfo/dev-security>
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI meta: permission prompts considered harmful

Jim Straus
I like the original thinking that is going into trying to avoid specific permission prompts and use implied consent.  I have some questions and concerns, so I'm going to go through a scenario and see if I'm understanding correctly and solicit thoughts on some issues.

Scenario:  A camera that takes antique style pictures, including showing the antique style in the preview, that wants to geotag the image and upload to a photo-sharing site.

Possible implementation, given previous discussions here and on "WebAPI Security Discussion: Camera API":
App opens the camera, bring up a system preview, supplying a shader to do the antique styling.  There is a system shutter button to take the picture (that can't be click-jacked or hidden).  At this point, I'm not sure how the geolocation is granted.  I don't think we want a second "apply geolocation" system button that the user has to know to press.  Maybe this is common enough that there is a special system shutter button that grants both permissions, or we need a permission dialog to appear.  The user then sees the captured image and can apply whatever other transformations desired (cropping, rotating, brighten, etc.)  On the captured image page there is a system "upload" button that is labeled by the app with the destination.  Pressing the button grants permission to communicate with the photo-sharing site to upload the photo.

Specific concerns are that apps that need more than one implied consent require users to know what to touch.  In the case of a geolocation button (often a circle with cross-hairs on iOS), how does the user know that they need to press that in addition to the shutter button?

If we start combining common permission patterns (geolocation with shutter, for example), how many do we end up with, will users know what they are granting, and what about a user who wants to take a picture but not tag it with the location?

Can we make clear enough buttons for most (all) of the permissions?  Shutter is particularly easy.  Geolocation in some cases is pretty easy.  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?

What does a Socket button look like?  Or NFC, or even calendar or contacts?

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?

This isn't meant to discourage the idea of coming up with ways of making implicit permissions work.  But I think we have been focusing on a relatively easy case.  I'd like to see the thread explore some of the other APIs and how implicit consent would work.  And how they would work in conjunction with each other.

On Apr 17, 2012, at 3:56 PM, Adrienne Porter Felt wrote:

> +1 to everything Zack said
>
> Standard runtime dialogs that ask for Allow/deny are familiar, so system
> designers seem to like them -- but a lot of literature establishes that
> they don't work.  Android tried moving them to install-time, which works
> for a small minority of users sometimes. Unfortunately, they're either
> ignored or impossible to interpret without context.  (People who aren't
> programmers have a hard time imagining how install-time permissions connect
> to what applications actually do.)
>
> There are certain resources that might need to be represented as either
> install-time permission prompts or standard runtime dialogs.  (For example,
> I can't think of another way to represent the ability to read all of the
> user's text messages.)  However, I view these as last resorts in the
> toolbox.  A very small number of prompts/standard dialogs will be OK.  OTOH
> if a new one is added along with each new WebAPI, we end up with
> dialogs/prompts that are completely useless because people will see them
> all the time.
>
> On Tue, Apr 17, 2012 at 8:18 PM, Zack Weinberg <[hidden email]> wrote:
>
>> I feel very strongly that we should initially attempt to design a system
>> where there are no install-time permission prompts, and more generally, no
>> prompts for which "remember this decision" is a desirable option.
>>
>> As Adrienne has been pointing out, permissions dialogs in general do not
>> work.  They ask a non-expert user to make a security-critical choice, based
>> on inadequate information, at a point in the workflow where most users will
>> actively *avoid* stopping to think. (I don't have studies to hand, but I'm
>> sure Adrienne does.)  From the UX perspective *and* the security
>> perspective, anything we can do to get away from them is worth doing.  And
>> we have a known better alternative: implicit, one-time-only deduction of
>> permission from intentional user actions, such as pressing a "take photo"
>> button.
>>
>> I'm frustrated by the Camera API discussion because there seem to be a
>> bunch of people who don't even want to *try* to do something better. Sure,
>> there exist applications for which it's not obvious how to fit them into an
>> only-if-the-user-pressed-the-**button-just-now paradigm, but that doesn't
>> mean we should give up!  (I'm pretty sure we can fit all camera use cases
>> into a combination of "you can draw over the preview but you can't see the
>> results" and "video recording mode".)
>>
>> Let's treat permissions dialogs as an option of last resort.  Let's only
>> do them if we really can't find any other way for a particular privilege.
>>
>> zw
>> ______________________________**_________________
>> dev-security mailing list
>> [hidden email]
>> https://lists.mozilla.org/**listinfo/dev-security<https://lists.mozilla.org/listinfo/dev-security>
>>
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI meta: permission prompts considered harmful

ianG-2
In reply to this post by Zack Weinberg-2
On 18/04/12 04:18 AM, Zack Weinberg wrote:
> I feel very strongly that we should initially attempt to design a system
> where there are no install-time permission prompts, and more generally,
> no prompts for which "remember this decision" is a desirable option.
>
> As Adrienne has been pointing out, permissions dialogs in general do not
> work.

+1


> They ask a non-expert user to make a security-critical choice,
> based on inadequate information, at a point in the workflow where most
> users will actively *avoid* stopping to think. (I don't have studies to
> hand, but I'm sure Adrienne does.) From the UX perspective *and* the
> security perspective, anything we can do to get away from them is worth
> doing. And we have a known better alternative: implicit, one-time-only
> deduction of permission from intentional user actions, such as pressing
> a "take photo" button.
>
> I'm frustrated by the Camera API discussion because there seem to be a
> bunch of people who don't even want to *try* to do something better.
> Sure, there exist applications for which it's not obvious how to fit
> them into an only-if-the-user-pressed-the-button-just-now paradigm, but
> that doesn't mean we should give up! (I'm pretty sure we can fit all
> camera use cases into a combination of "you can draw over the preview
> but you can't see the results" and "video recording mode".)


How about a tag approach?  Any App with the word CAMERA in it
automatically gets all the normal camera permissions enabled from the
start, every one of them.  So as long as the seller displays the tag
words prominently, people know, to the extent that they can manage the
tags in their heads.  (Which, is surely an easier task than managing
their dialogs with their fingers...)


> Let's treat permissions dialogs as an option of last resort. Let's only
> do them if we really can't find any other way for a particular privilege.
>
> zw




iang
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI meta: permission prompts considered harmful

Mounir Lamouri-3
In reply to this post by Jim Straus
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI meta: permission prompts considered harmful

Adrienne Porter Felt
On Wed, Apr 18, 2012 at 12:14 PM, Mounir Lamouri <[hidden email]> 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI meta: permission prompts considered harmful

Mounir Lamouri-3
On 04/19/2012 03:22 PM, Adrienne Porter Felt wrote:
> 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.

I don't like this solution at least for those two reasons:
 - web developers will want to style that button;
 - you can't guarantee that there will not an element on top of that
magic button with "pointer-events: none;" to have the click traverse it
and going to the magic button.

> 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).

When does SMS app have to show a full-screen SMS approval dialog?
Regular content have to use intents-like system and other content will
just be able to use the API, AFAIK.

>> 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.

I doubt that many applications would require a specific UI. On Android,
for example, most applications are very ok with using intents to pick a
camera instead of re-building a camera picker.

This said, apps that require a custom UI would have to just use the
Camera API. An intent-like system would solve most use cases but not all.

Cheers,
--
Mounir
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI meta: permission prompts considered harmful

Adrienne Porter Felt
>
> > 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).
>
> When does SMS app have to show a full-screen SMS approval dialog?
> Regular content have to use intents-like system and other content will
> just be able to use the API, AFAIK.
>

You can theoretically use Intents to send something silently in the
background, or you can use Intents to open a full-screen SMS dialog that is
pre-populated where the user just hits "Send".  Which do you mean?  I think
the former is a bad idea, and the latter does not satisfy many apps that
send text messages.  (Handcent SMS, for example.)


> I doubt that many applications would require a specific UI. On Android,
> for example, most applications are very ok with using intents to pick a
> camera instead of re-building a camera picker.
>

That is untrue.  Many apps use the direct API call for taking photos.


> This said, apps that require a custom UI would have to just use the
> Camera API. An intent-like system would solve most use cases but not all.
>

I have no objections to also supporting an Intent system where you open the
full-screen Camera app, which returns a stream of data.  The question is
what to do for all the apps that this does not satisfy (which is a very
large number of apps).
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI meta: permission prompts considered harmful

Mounir Lamouri-3
On 04/20/2012 10:58 AM, Adrienne Porter Felt wrote:
> You can theoretically use Intents to send something silently in the
> background, or you can use Intents to open a full-screen SMS dialog that is
> pre-populated where the user just hits "Send".  Which do you mean?  I think
> the former is a bad idea, and the latter does not satisfy many apps that
> send text messages.  (Handcent SMS, for example.)

I meant using Intents to open a real SMS app that will handle the
sending. So, indeed, Handcent SMS will not do that because it is an SMS
app and such an app will want to be able to style something like a 'send
sms' button which would make such a magic button useless IMO.
When I was mentioning intents I was much more thinking of apps that
allow you to do stuff like 'share this via sms'.

> That is untrue.  Many apps use the direct API call for taking photos.

I haven't seen that much apps doing that but it's only based on my
experience.

> I have no objections to also supporting an Intent system where you open the
> full-screen Camera app, which returns a stream of data.  The question is
> what to do for all the apps that this does not satisfy (which is a very
> large number of apps).

The question is what are the valid use cases to do that?

--
Mounir
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI meta: permission prompts considered harmful

Adrienne Porter Felt
On Fri, Apr 20, 2012 at 11:13 AM, Mounir Lamouri <[hidden email]> wrote:

> On 04/20/2012 10:58 AM, Adrienne Porter Felt wrote:
> > You can theoretically use Intents to send something silently in the
> > background, or you can use Intents to open a full-screen SMS dialog that
> is
> > pre-populated where the user just hits "Send".  Which do you mean?  I
> think
> > the former is a bad idea, and the latter does not satisfy many apps that
> > send text messages.  (Handcent SMS, for example.)
>
> I meant using Intents to open a real SMS app that will handle the
> sending. So, indeed, Handcent SMS will not do that because it is an SMS
> app and such an app will want to be able to style something like a 'send
> sms' button which would make such a magic button useless IMO.
>
Right -- the apps would just use the magic button in place of their own
custom button.  Is the way the button looks really an integral part of the
app?  Having a standard button might even improve the overall look of
applications; for example, iOS apps share many common UI elements, which
gives them a clean, concise feel. The standard button could have a neutral
design, or perhaps the system could provide a few buttons that have the
same icon and layout but with different colors.

(See the wireframe attachment to see how minor a change it would be for
Handcent SMS -- just a different button.)

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI meta: permission prompts considered harmful

Kyle Hamilton
In reply to this post by Zack Weinberg-2
Suggestion:

"Program <name> is attempting to <action> on <resource>.  If you expected it to, tap here.  If not, tap below."

Then, if the same permission dialog keeps happening at the same point in the same process, and the user has never said "no", allow the option to save a "just say yes" or "just say no" for that particular request flow and request address only.

-Kyle H

On Tue, Apr 17, 2012 at 12:56 PM, Adrienne Porter Felt <[hidden email]> wrote:

> +1 to everything Zack said
>
> Standard runtime dialogs that ask for Allow/deny are familiar, so system
> designers seem to like them -- but a lot of literature establishes that
> they don't work.  Android tried moving them to install-time, which works
> for a small minority of users sometimes. Unfortunately, they're either
> ignored or impossible to interpret without context.  (People who aren't
> programmers have a hard time imagining how install-time permissions connect
> to what applications actually do.)
>
> There are certain resources that might need to be represented as either
> install-time permission prompts or standard runtime dialogs.  (For example,
> I can't think of another way to represent the ability to read all of the
> user's text messages.)  However, I view these as last resorts in the
> toolbox.  A very small number of prompts/standard dialogs will be OK.  OTOH
> if a new one is added along with each new WebAPI, we end up with
> dialogs/prompts that are completely useless because people will see them
> all the time.
>
> On Tue, Apr 17, 2012 at 8:18 PM, Zack Weinberg <[hidden email]> wrote:
>
>> I feel very strongly that we should initially attempt to design a system
>> where there are no install-time permission prompts, and more generally, no
>> prompts for which "remember this decision" is a desirable option.
>>
>> As Adrienne has been pointing out, permissions dialogs in general do not
>> work.  They ask a non-expert user to make a security-critical choice, based
>> on inadequate information, at a point in the workflow where most users will
>> actively *avoid* stopping to think. (I don't have studies to hand, but I'm
>> sure Adrienne does.)  From the UX perspective *and* the security
>> perspective, anything we can do to get away from them is worth doing.  And
>> we have a known better alternative: implicit, one-time-only deduction of
>> permission from intentional user actions, such as pressing a "take photo"
>> button.
>>
>> I'm frustrated by the Camera API discussion because there seem to be a
>> bunch of people who don't even want to *try* to do something better. Sure,
>> there exist applications for which it's not obvious how to fit them into an
>> only-if-the-user-pressed-the-**button-just-now paradigm, but that doesn't
>> mean we should give up!  (I'm pretty sure we can fit all camera use cases
>> into a combination of "you can draw over the preview but you can't see the
>> results" and "video recording mode".)
>>
>> Let's treat permissions dialogs as an option of last resort.  Let's only
>> do them if we really can't find any other way for a particular privilege.
>>
>> zw
>> ______________________________**_________________
>> dev-security mailing list
>> [hidden email]
>> https://lists.mozilla.org/**listinfo/dev-security<https://lists.mozilla.org/listinfo/dev-security>
>>
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security