1024396 - Allow blocking certain permissions for privileged apps

Status: RESOLVED FIXED

(Core Graveyard :: DOM: Apps, enhancement, P1)

Description

[Frederik Braun [:freddy]]

Some Firefox OS privileges have been downgraded from certified to privileged to make Loop (see bug 988285) work as a marketplace app.

For Security reasons, we need to embargo these permissions from all apps but Loop for a certain amount of time.
Is there a way to do this given the current validation techniques?

Comment 1

[Wil Clouser [:clouserw]]

No, we'd need to write a patch for the validator.  You linked to a tracking bug that is light on technical details.  What exactly are you trying to block, what are the timelines, what are the concerns, etc.  There isn't a way to say "run these rules for everything except $app" so if we patch the validator it will also affect Loop uploads.

Comment 2

[Frederik Braun [:freddy]]

Maire, can you help us filling this in?

Comment 3

[Maire Reavy [:mreavy]]

I've been involved with the getUserMedia permission prompt (the prompt to share your camera/microphone at the beginning of WebRTC/Loop call);  the Loop app would like that prompt bypassed by default (which is controlled in the user settings).  The timeline is for v2.0;  Loop wants to be an app in the marketplace on Flame in time for the v2.0 release. To make sure we don't miss anything, we want the folks who are writing the mobile Loop app to verify the list of permissions they require.  

Shell -- I've added ft:loop to the white board for tracking.  I believe we want to verify what's required here with Viviene, Jonas, Fabrice as well as the folks writing the Loop app.  We may want to do this as an email and then add the results of the discussion to this bug.

Comment 4

[Frederik Braun [:freddy]]

pauljt and had a quick discussion on IRC. We agreed that we should allow the audio permission changes, i.e. allow privileged apps to use the ringer and telephony audio channels (bug 988427 and bug 990552).

As per bug 988212 there is the "attention" privilege, which we should block (for now). Window management will change with Haida, which will reshape the implications of attention screens. We will revisit it by then.

Paul will follow-up about datastore.

Comment 5

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(In reply to Wil Clouser [:clouserw] from comment #1)
> No, we'd need to write a patch for the validator.  You linked to a tracking
> bug that is light on technical details.  What exactly are you trying to
> block, what are the timelines, what are the concerns, etc.  There isn't a
> way to say "run these rules for everything except $app" so if we patch the
> validator it will also affect Loop uploads.

I can add some background: we want to expose "attention" permission to loop, but only loop, since this API is still in flux. This situation will be for 2.0 only - eventually attention screen will be safe to give to all privileged apps, but in some different form.  

Because loop is a privileged app, other apps could ask for this permission. The vague plan discussed with loop (without marketplace, hence this bug) was enforcing this in marketplace somehow - perhaps in the review process. The question is how best to make sure that we don't miss anything, and accidentally grant this permission.

We need to allow 'attention' permission to privileged apps, but make sure that only Loop gets this permission. There may be a few other permissions like this for 2.0, but this less that ideal situation will be resolved in 2.1

I am sure there is at least one permission that is in the same boat for 2.0 - it might be "nfc", but I am not sure off the top of my head. I'll comment here again once I remember which one it was. The other thing is hat we may want to restrict access to audio channels pending the outcome of 991011.

Wil & Andrew - what would your recommendation be given this situation? Can we just address this somehow in the review process? Or do you think it would be safer to make a marketplace (or maybe platform?) modification.

Comment 6

[Andrew Williamson [:eviljeff]]

The issue would be that once 2.1 launches and the API is available to all... then we will allow apps that use the permission.  What happens when this app is installed on a 2.0 device?  

That concern aside, it *could* be implemented in the review process - but the risk is that the permission will be overlooked, even with the restricted number of reviewers who approve privileged apps.  It depends on how bad it would be if an app got approved by accident.

Comment 7

[Wil Clouser [:clouserw]]

Can you link to documentation for "attention"?  A quick google search didn't find it.  I'm wondering if this will need to be added to getFeature() or not for the Marketplace to detect.

Comment 8

[Paul Theriault [:pauljt] (no longer reading bugmail)]

The system app catches window.open calls like this and opens them in the attention screen. (In reply to Andrew Williamson [:eviljeff] from comment #6)
> The issue would be that once 2.1 launches and the API is available to all...
> then we will allow apps that use the permission.  What happens when this app
> is installed on a 2.0 device?  

That's a good point. We would probably call the new attention screen permission by a new permission name. 

> 
> That concern aside, it *could* be implemented in the review process - but
> the risk is that the permission will be overlooked, even with the restricted
> number of reviewers who approve privileged apps.  It depends on how bad it
> would be if an app got approved by accident.

An app that got this by accident could spawn a window at any time above all other content (including when the phone is locked). So maybe phishing attacks but I am more worried about apps using this permission insecurely than maliciously.

I am wondering - maybe we should just have loop specify its origin (something like app://loop.gaiamobile.org) and then create a whitelist preference that only allows attention screen to be added for privileged apps for this origin. 

What do you think Jonas?


(In reply to Wil Clouser [:clouserw] from comment #7)
> Can you link to documentation for "attention"?  A quick google search didn't
> find it.  I'm wondering if this will need to be added to getFeature() or not
> for the Marketplace to detect.

There is no documentation, and its not really an API we want to publish. Its really a gaia only feature, but one that is needed for loop in order to answer calls when the phone is locked. Basically the api is used like this:
window.open(...."attention") 

The system app then opens a window for this content, and sets it with the highest z-index so no other content can overlay it. (or that is how it used to work). Bug 988212 adds support for multiple attention screens and switching between them.

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

(In reply to Paul Theriault [:pauljt] from comment #8)
> The system app catches window.open calls like this and opens them in the
> attention screen. (In reply to Andrew Williamson [:eviljeff] from comment #6)
> > The issue would be that once 2.1 launches and the API is available to all...
> > then we will allow apps that use the permission.  What happens when this app
> > is installed on a 2.0 device?  
> 
> That's a good point. We would probably call the new attention screen
> permission by a new permission name. 

Yeah. This is indeed a very good point. Possibly we should rename the permission for the 2.0 release to make sure that we don't use up good names. Not a huge deal but seems easy enough.

> I am wondering - maybe we should just have loop specify its origin
> (something like app://loop.gaiamobile.org) and then create a whitelist
> preference that only allows attention screen to be added for privileged apps
> for this origin. 

I'd rather not. Though the permission is only for Loop in the 2.0 timeframe, we could end up deciding later that we want to sign additional apps that also use these permissions. I'd rather not make this more Loop specific than it needs to be.


Couldn't marketplace simply use the manifest validator to make sure that any app that asks for the "attention" (or whatever we'll call it for the 2.0 release) permission is considered an invalid manifest? Then we can sideload Loop onto the marketplace.

Comment 10

[Andrew Williamson [:eviljeff]]

(In reply to Jonas Sicking (:sicking) from comment #9)
> Yeah. This is indeed a very good point. Possibly we should rename the
> permission for the 2.0 release to make sure that we don't use up good names.
> Not a huge deal but seems easy enough.

a new permission seems the easiest fix.
 
> Couldn't marketplace simply use the manifest validator to make sure that any
> app that asks for the "attention" (or whatever we'll call it for the 2.0
> release) permission is considered an invalid manifest? Then we can sideload
> Loop onto the marketplace.

We can certainly have the validator mark the manifest invalid, but there isn't a way to 'sideload' apps currently.  @clouserw - is this practical?

Although if there was a way to 'sideload', it wouldn't be available to a 3rd party developer to upload new versions (which I guessed was the reason we wanted Loop on Marketplace).

Comment 11

[Wil Clouser [:clouserw]]

(In reply to Andrew Williamson [:eviljeff] from comment #10)
> (In reply to Jonas Sicking (:sicking) from comment #9)
> > Couldn't marketplace simply use the manifest validator to make sure that any
> > app that asks for the "attention" (or whatever we'll call it for the 2.0
> > release) permission is considered an invalid manifest? Then we can sideload
> > Loop onto the marketplace.
> 
> We can certainly have the validator mark the manifest invalid, but there
> isn't a way to 'sideload' apps currently.  @clouserw - is this practical?

The validator part is easy, we just need the name of the permission and the message you want to display when its there.

As for sideloading, it's come up before but was wontfixed (see bug 877454) but that was for extra large apps or weird failures.  The setting actually landed in https://github.com/mozilla/zamboni/pull/510 but it might not have made it to the Marketplace.  I'm not opposed to a sideload option.  Is that officially what we're asking for in this bug now?

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I think it's up to the marketplace team to decide what solution to use which satisfies:

1. Ensure to not hand out a set of privileges to any apps other than some set of "special" apps.
2. Still allow hosting said special apps on marketplace.

Sideloading is one option.

Another option is to enforce that for apps that ask for certain privileges go through some extra approval steps. And in those steps only approve Loop for now until we feel more comfortable with exposing them to more 3rd parties.

As long as the above two conditions are fulfilled I'm happy.

Comment 13

[Andrew Williamson [:eviljeff]]

I'd prefer to have the validation bypass (aka sideloading) be available for a limited number of white-listed apps than the solution in pull/510 (I think it was just an AMO-side fix so didn't affect apps).

It would prevent other, non-white listed apps from using the permissions, and we would mark those apps as VIP so to pay them appropriate extra attention. But not push the developer control of uploads onto Marketplace staff.  

On the platform side, there are requirements that a) different permission names be used when the APIs are fully exposed in 2.1; and b) both the 2.0 loop-only and the 2.1 general-availability APIs/permissions are feature detectable with getFeature.  These are so an app for 2.1 isn't installable on a non-harded/security checked version of fxOS, such as 2.0.

This is all assuming that we're not trying to permanently create a fourth category of type, sitting between privileged and certified, (super-privileged?) that have additional approval steps.  I wasn't clear from comment 12.

Comment 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'm not sure if you'd call it a 4th type or not.

The idea of putting permissions in the manifest was always to enable us to create APIs that could cause badness for the user, but then prevent that badness through marketplace review.

So for the example the "audio-channel-telephony" permission grants access to playing audio with the same priority as GSM telephony audio. This enables creating VoIP apps like Loop, by allowing the VoIP app to interfere with GSM calls in responsible ways. But it also, if abused, runs the risk that an app interferes with GSM calls in bad ways!

To ensure that the "audio-channel-telephony" doesn't interfere with the GSM call in bad ways we need to take extra steps to ensure that the API isn't used in bad ways. Either maliciously or accidentally.

We can either do this by only signing apps that ask for that permission after doing extra thorough reviews. Or by only signing apps that ask for that permission if they are coming from developers that we trust to not mess up. Either way some form of extra steps are needed. What exactly those steps are is something that we need to decide on a permission-by-permission basis.

This bug is just asking for marketplace to detect that extra steps are needed and ensure that we don't sign apps without having verified that those steps were taken.

Comment 15

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I guess this bug is also that, for now, the extra steps needed for "audio-channel-telephony" (and a few more) are: Application must be the Loop app.

Comment 16

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Another permission that will likely fall into this category is the 'firefox-accounts' permission proposed as a response to this bug 1028398.

Comment 17

[Wil Clouser [:clouserw]]

I talked to Andrew on IRC today - he wants to comment here again to clarify but it's night there now, so ni'ing him.

Comment 18

[Andrew Williamson [:eviljeff]]

For the general case, of having permissions that allow access to APIs that potentially lead to badness, we (App Review) don't think we need to expand on the current model.  This is that privileged apps are highlighted as such; reviews are limited to a small number of extra-trusted reviewers; and reviews for those apps contain a code review step that identifies potential problems.

For the specific case of allowing a limited number of apps 'early' access to an API in a version of FxOS then those permissions should be prefixed to identify them as different to the 'release' version of the API.  In the case of permissions that already exist as certified (e.g. audio-channel-telephony) the unprefixed permission should stay certified.

That way, an app that asks for '[moz|loop|pre|whatever]-audio-channel-telephony' can be denied* approval normally, or given approval for specific apps, and *only* those apps will function on 2.0.  An app that ask for the normal, unprefixed 'audio-channel-telephony' permission could be approved (assuming it passes code review step, etc) but wouldn't be functional on 2.0 (because the permission would be denied or wouldn't exist), but would be functional on 2.1, where the access is relaxed and available to 3rd party apps.

* For Marketplace to support this it only needs to: 
1) throw a validation error for any apps that use any of these prefixed permissions (or any unknown permission?  - It might already do this today); and
2) allow certain apps on a whitelist to still get through, either by:
  a) allowing an upload with a validator error to proceed, rather than preventing it, or
  b) suppress the validation error for those specific permissions for the apps on the whitelist.

(2b would be the ideal, but 2a would do if we're only talking about a handful of apps)

Comment 19

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Thanks Andrew - sound like good suggestions. 

Jonas, I am wondering though, if we need gecko changes here anyways, should we just whitelist the approved privileged apps, and be done with it? Then we don't need to create any additional review complications. (this presumes loop doesn't ever need to change its origin though).

Comment 20

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'd really prefer not to whitelist any particular apps in the client. I strongly suspect that we'll want to allow additional VoIP clients to be installed once we've seen Loop working well.

I don't think that "audio-channel-telephony" specifically should be considered "early" access. I think we're pretty satisfied with that API/permission. If you feel that the current review process will sufficiently guard against that permission being used then we might be good here.

However I agree that we should rename "attention" to something like "[moz|loop|pre|whatever]-attention".

Comment 21

[Wil Clouser [:clouserw]]

prefixing works for me.  If we can get buy-in from everyone here about what needs to happen we can move forward on this.  Andrew - what do you need from us?

Comment 22

[Andrew Williamson [:eviljeff]]

(In reply to Wil Clouser [:clouserw] from comment #21)
> prefixing works for me.  If we can get buy-in from everyone here about what
> needs to happen we can move forward on this.  Andrew - what do you need from
> us?

from Jonas & co: a list of which permissions need kid gloves - [moz-attention,moz-firefox-accounts] ?

On Marketplace:
either:
a)
- app-validator to throw and error on those permissions (it may do already if they're not listed, not sure)
- developer pages allowing an error on the validator to still proceed for apps on with a flag set
- someway of admins setting that flag (edit listing:admin section?)

or
b)
- app-validator having an app whitelist and only throwing the error on those permissions if the app isn't on the whitelist
- someway of admins adding to that whitelist... if this isn't likely to need to change quickly or often could even be hardcoded.

as (a) would need the submission started before we could set the flag (which they can't do because the validator would throw an error - catch 22) I prefer (b) but I'm not sure how we would define the whitelist without listing origins.  An alternative to (a), while we're at it:

c) (the stretch goal!)
- app-validator allowing any arbitrary list of allowed permissions to be passed in on each validation and those permissions would be checked.  i.e. stop defining allowed permissions in the validator code.
- marketplace passing those default permissions along to the validator on each validation call, along with any extra permissions definable per app
- someway of admins adding extra permissions to specific apps (edit listing: admin section?)

Comment 23

[Wil Clouser [:clouserw]]

@eviljeff: how about we modify the validator to put any apps using the special permissions in the escalation queue?  That would be an easy way to identify them, a relatively easy patch to write/maintain, and easy to back out when 2.1 lands.  I think for the low volume here (it sounds very likely no one will even try to use these other permissions) that is the easiest solution.

@others: we still need the names of the permissions.

Comment 24

[Andrew Williamson [:eviljeff]]

(In reply to Wil Clouser [:clouserw] from comment #23)
> @eviljeff: how about we modify the validator to put any apps using the
> special permissions in the escalation queue?  That would be an easy way to
> identify them, a relatively easy patch to write/maintain, and easy to back
> out when 2.1 lands.  I think for the low volume here (it sounds very likely
> no one will even try to use these other permissions) that is the easiest
> solution.

yeah I think that would work.

Comment 25

[Wil Clouser [:clouserw]]

Paul - please give us the names of all the permissions you want to flag. Thanks.

Comment 26

[Paul Theriault [:pauljt] (no longer reading bugmail)]

So the permissions I am aware of that need restricting to loop are (ignoring renaming for now):
- "attention" 
- "firefox-accounts" (to be added by 1028398)
- "audio-channel-ringer" 

I presume after renaming, these will be:

- "moz-attention" 
- "moz-firefox-accounts" (to be added by 1028398)
- "moz-audio-channel-ringer" 

So to be clear on the renaming, I assume we mean "adding a new permission for the pre-release version of the permission" - since we need to keep the existing permissions for Gaia. But then wont we need to go through all the places in the codebase that check these permissions and check for either permission instead? That sounds hard and likely to cause regressions.

I have an alternative proposal that I think achieves the same effect more simply:

- keep these "pre-release" APIs as certified
- add functionality in the permissions installer code to grant prefixed permissions to privileged apps, at the certified level. So in 2.0 a privileged app can request a certified permission by requesting the prefixed version, but only for this list of 3 permissions.
- in 2.1, we can just remove the permissions installer code
- marketplace can do their extra assurance for all apps which request prefixed permissions.

Since Jonas is away this week, what do you think about this approach Fabrice?

Comment 27

[Antonio Manuel Amaya Calvo (:amac)]

(In reply to Paul Theriault [:pauljt] from comment #26)
> So the permissions I am aware of that need restricting to loop are (ignoring
> renaming for now):
> - "attention" 
> - "firefox-accounts" (to be added by 1028398)
> - "audio-channel-ringer" 
> 
> I presume after renaming, these will be:
> 
> - "moz-attention" 
> - "moz-firefox-accounts" (to be added by 1028398)
> - "moz-audio-channel-ringer" 
> 
> So to be clear on the renaming, I assume we mean "adding a new permission
> for the pre-release version of the permission" - since we need to keep the
> existing permissions for Gaia. But then wont we need to go through all the
> places in the codebase that check these permissions and check for either
> permission instead? That sounds hard and likely to cause regressions.
> 
> I have an alternative proposal that I think achieves the same effect more
> simply:
> 
> - keep these "pre-release" APIs as certified
> - add functionality in the permissions installer code to grant prefixed
> permissions to privileged apps, at the certified level. So in 2.0 a
> privileged app can request a certified permission by requesting the prefixed
> version, but only for this list of 3 permissions.
> - in 2.1, we can just remove the permissions installer code
> - marketplace can do their extra assurance for all apps which request
> prefixed permissions.
> 
> Since Jonas is away this week, what do you think about this approach Fabrice?

Why can't we just add the new prefix-permission to PermissionTable as privileged and use them on the places where the non-prefix permission check is done? And why do we need prefixes again? Can't the marketplace escalate the normal permissions (and thus no code change will be needed?)

Comment 28

[Fernando Jiménez Moreno [:ferjm]]

    (In reply to Paul Theriault [:pauljt] from comment #26)
    > So the permissions I am aware of that need restricting to loop are (ignoring
    > renaming for now):
    > - "attention" 
    > - "firefox-accounts" (to be added by 1028398)
    > - "audio-channel-ringer" 
    > 

    We might also want to consider adding "audio-channel-telephony" and "mobileid" to the list.

    > I presume after renaming, these will be:
    > 
    > - "moz-attention" 
    > - "moz-firefox-accounts" (to be added by 1028398)
    > - "moz-audio-channel-ringer" 
    > 
    > So to be clear on the renaming, I assume we mean "adding a new permission
    > for the pre-release version of the permission" - since we need to keep the
    > existing permissions for Gaia. But then wont we need to go through all the
    > places in the codebase that check these permissions and check for either
    > permission instead? That sounds hard and likely to cause regressions.
    > 

    That's true for already existing permissions. FxA and MobileID for instance are not affected by this.

    > I have an alternative proposal that I think achieves the same effect more
    > simply:
    > 
    > - keep these "pre-release" APIs as certified
    > - add functionality in the permissions installer code to grant prefixed
    > permissions to privileged apps, at the certified level. So in 2.0 a
    > privileged app can request a certified permission by requesting the prefixed
    > version, but only for this list of 3 permissions.
    > - in 2.1, we can just remove the permissions installer code
    > - marketplace can do their extra assurance for all apps which request
    > prefixed permissions.
    > 
    > Since Jonas is away this week, what do you think about this approach Fabrice?

    Just to double check, I understand that this would require us to keep a list in the client side, specifying also the permission action (allow or prompt) that we want to provide for each case.

    How would the system update scenario work here? Would an app with moz-* permission installed in 2.0 (and so with * permission granted) keep the permission in 2.1 or would it be required to update to use the new permission (supposedly granted for privileged in 2.1)?

Comment 29

[[:fabrice] Fabrice Desré]

(In reply to Paul Theriault [:pauljt] from comment #26)

> I have an alternative proposal that I think achieves the same effect more
> simply:
> 
> - keep these "pre-release" APIs as certified
> - add functionality in the permissions installer code to grant prefixed
> permissions to privileged apps, at the certified level. So in 2.0 a
> privileged app can request a certified permission by requesting the prefixed
> version, but only for this list of 3 permissions.
> - in 2.1, we can just remove the permissions installer code
> - marketplace can do their extra assurance for all apps which request
> prefixed permissions.
> 
> Since Jonas is away this week, what do you think about this approach Fabrice?

I think we have an easier way to do it. We have support for name substitution in PermissionsTable.jsm (see https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/PermissionsTable.jsm#142).

So what about doing something like:

attention: {
  app: DENY_ACTION,
  privileged: DENY_ACTION,
  certified: ALLOW_ACTION
},

priv-attention: {
  app: DENY_ACTION,
  privileged: ALLOW_ACTION,
  certified: ALLOW_ACTION,
  substitute: ["attention"]
},

This way we just grant the "attention" permission, and we don't pollute the permission manager db.

Comment 30

[Antonio Manuel Amaya Calvo (:amac)]

Fabrice's solution is much nicer to implement. BTW, when I was checking that I found bug 1033453 (which will have to be fixed for this to work also). Will upload a patch for that in a few minutes.

Comment 31

[Maire Reavy [:mreavy]]

Paul, Maria --Since we seem to be converging on a design, I think we need to find an owner.  Do either of you have suggestions?  Thanks.

Comment 32

[Fernando Jiménez Moreno [:ferjm]]

I already have to do it for FxA, so I can do it for the rest of permissions. I just need to know the final list of permissions.

Comment 33

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(In reply to Fabrice Desré [:fabrice] from comment #29)
> 
> I think we have an easier way to do it. We have support for name
> substitution in PermissionsTable.jsm (see

Perfect.

And i just realized I wrote the wrong permission above (audio-channel-ringer instead of -telephony). The list of permissions is:

- attention
- firefox-accounts (do this in 1028398 or dupe the bug)
- audio-channel-telephony
- audio-channel-ringer

I am unsure about audio-channel-ringer but I feel like it might be prudent.I think at worst a foreground app can prevent the phone from playing the ringing sound, but the callscreen attention screen overlay will still happen so I think this is ok. But I want to make that when your screen is off that an app is no longer considered foreground. Because otherwise an app could accidentally prevent your phone from ringing. Anyways I'll confirm this behavior asap and reply.

Comment 34

[Paul Theriault [:pauljt] (no longer reading bugmail)]

So its hard to get an idea of exactly what impact 1016277 will have on audio-channel-ringer, but for consistency, and because any app that wants audio-channel-telephony probably wants ringer too, I think we should prefix both of them.

For completeness, note that I have also considered the mobile-id permission from msisdn API, but jonas stated in an email list:

> I think we should expose this one to all content. No need for a
> permission at all. But someone needs to send a "intent to implement"
> mail to dev-platform.

I double checked the current Loop FxOS client [1] and I can't see anything else that falls into the same category. So as per the previous post, the list of permission we should prefix for 2.0 is:

- attention
- firefox-accounts (do this in 1028398 or dupe the bug)
- audio-channel-telephony
- audio-channel-ringer


[1] https://github.com/mozilla-b2g/firefoxos-loop-client/blob/master/manifest.webapp

Comment 35

[Fernando Jiménez Moreno [:ferjm]]

Attachment: v1

Comment 37

[Maria Angeles Oteo (:oteo)]

Nominating to 2.0, as it was explained in bug 1033354 comment 4

Comment 38

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Comment on attachment 8450068 [details] [diff] [review]
v1

Review of attachment 8450068 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me (I'm not a peer though).

Comment 39

[[:fabrice] Fabrice Desré]

Comment on attachment 8450068 [details] [diff] [review]
v1

Review of attachment 8450068 [details] [diff] [review]:
-----------------------------------------------------------------

Same remark as in https://bugzilla.mozilla.org/show_bug.cgi?id=1028398#c61 about the naming. Sorry about that but I feel it's worth it to do something sane. Naming is hard!

Comment 40

[Fernando Jiménez Moreno [:ferjm]]

Attachment: v2

Comment 41

[Fernando Jiménez Moreno [:ferjm]]

Attachment: v2

Comment 42

[Fernando Jiménez Moreno [:ferjm]]

https://hg.mozilla.org/integration/b2g-inbound/rev/2af5b7483d69

Comment 43

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/2af5b7483d69

Comment 44

[Andrew Williamson [:eviljeff]]

"Target Milestone: --- → mozilla33"
its mozilla32, isn't it?

Comment 45

[Ryan VanderMeulen [:RyanVM]]

Target milestone tracks trunk landings. Status flags track branch uplifts.

https://hg.mozilla.org/releases/mozilla-aurora/rev/63f8f9ace234

Comment 46

[Andrew Williamson [:eviljeff]]

Filed bug 1036921 for Marketplace work

Comment 47

[Wil Clouser [:clouserw]]

(In reply to Andrew Williamson [:eviljeff] from comment #46)
> Filed bug 1036921 for Marketplace work

Thanks!