Re: App store moderation

[Kumar McMillan]

On May 31, 2012, at 5:25 PM, David Leadbolt wrote:

> Hi all
>
> Apologies if this is not the correct place, just just getting on board. I'm keen to learn of the apps QA Policies that are going to be employed such as content assessment and maturity ratings etc. we (LeadBolt) have a Very tight QA process that ensures only quality apps that are of an appropriate content are enabled with our advertising code. That said, if Google Play or iOS App Store allows a certain type of app that we normally would not then we will also allow this. My feeling is that we would continue this approach with B2G, so keen to learn of the intended categorisation, maturity assessment, restricted content and practices etc that's planned for the B2G app store. I'm also more than happy to help in this area.

Hi David.
We have a team of folks working to review app submissions sent to the marketplace -- this team is open to the community (just like with add-ons) so you or anyone is more than welcome to help out. There's another list for app discussions when they are more specific to the marketplace (https://lists.mozilla.org/listinfo/dev-marketplace). I've cc'd this thread over there.

Someone with more knowledge of the review process can answer to specifics.

-Kumar


>
> David
> VP Operations
> LeadBolt
>
> On 31/05/2012, at 9:50 PM, dev-webap...@lists.mozilla.org wrote:
>
>> Send dev-webapps mailing list submissions to
>> dev-w...@lists.mozilla.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.mozilla.org/listinfo/dev-webapps
>> or, via email, send a message with subject or body 'help' to
>> dev-webap...@lists.mozilla.org
>>
>> You can reach the person managing the list at
>> dev-weba...@lists.mozilla.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of dev-webapps digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: WebAPI Security Discussion: Power Management
>> (pther...@mozilla.com)
>> 2. Re: WebAPI Security Discussion: Mobile Connection API
>> (pther...@mozilla.com)
>> 3. Re: WebAPI Security Discussion: Socket API
>> (pther...@mozilla.com)
>> 4. Re: WebAPI Security Discussion: Geolocation
>> (pther...@mozilla.com)
>> 5. Re: WebAPI Security Discussion: Sensor API
>> (pther...@mozilla.com)
>> 6. Re: "installs_allowed_from" and openness (Gervase Markham)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Thu, 31 May 2012 03:48:12 -0700 (PDT)
>> From: "pther...@mozilla.com" <pther...@mozilla.com>
>> To: mozilla-d...@lists.mozilla.org
>> Cc: "dev-w...@lists.mozilla.org" <dev-w...@lists.mozilla.org>
>> Subject: Re: WebAPI Security Discussion: Power Management
>> Message-ID: <78cb7fd0-59e8-42b7...@googlegroups.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Final call for comment/changes to the permissions model for this API. Please provide comment by COB Friday June 1.
>>
>> On Wednesday, 2 May 2012 12:08:31 UTC+10, Lucas Adamski wrote:
>>> *Please reply-to dev-w...@lists.mozilla.org
>>> *
>>> Name of API: Power Management APIs
>>> Reference: https://wiki.mozilla.org/WebAPI/PowerManagementAPI
>>>
>>> Brief purpose of API: Allow apps to turn off or restart device and catch on-wake events
>>> General Use Cases: None
>>>
>>> Inherent threats: Denial of serviceto device (including telephone), annoyance
>>>
>>> Threat severity: Moderate
>>>
>>> == Regular web content (unauthenticated) ==
>>> Use cases for unauthenticated code:None
>>> Authorization model for normal content:
>>> Authorization model for installed content:
>>> Potential mitigations:
>>>
>>> == Trusted (authenticated by publisher) ==
>>> Use cases for authenticated code: None
>>> Potential mitigations:
>>>
>>> == Certified (vouched for by trusted 3rd party) ==
>>> Use cases for certified code: Replacement Power Management App
>>> Authorization model: Implicit
>>> Potential mitigations:
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 31 May 2012 03:50:26 -0700 (PDT)
>> From: "pther...@mozilla.com" <pther...@mozilla.com>
>> To: mozilla-d...@lists.mozilla.org
>> Subject: Re: WebAPI Security Discussion: Mobile Connection API
>> Message-ID: <3db0f0ee-c0e6-4658...@googlegroups.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Final call for comment/changes to the permissions model for this API. Please provide comment by COB Friday June 1.
>>
>> On Tuesday, 8 May 2012 06:35:42 UTC+10, Lucas Adamski wrote:
>>> Please reply-to dev-w...@lists.mozilla.org
>>>
>>> Name of API: Mobile Connection API
>>> Reference: https://wiki.mozilla.org/WebAPI/WebMobileConnection
>>>
>>> Brief purpose of API: This exposes information about the current mobile voice and data connection to (certain) HTML content.
>>>
>>> Use Cases: The primary use case for this is the status bar of the main phone UI.
>>>
>>> Inherent threats:
>>> Access to sensitive information such as:
>>> ICC-related (SIM/RUIM card)
>>> own phone number and other ICC I/O related features
>>> entering PIN, PIN2, PUK, PUK2 to unlock various states of the SIM card. Entering the PIN isn't *that* exotic, actually. Some carriers deliver their SIM cards with the PIN lock enabled, for instance.
>>> changing the PIN (also serves as enabling/disabling the PIN lock.)
>>> device-related
>>> get IMEI, IMEISV
>>> depersonalize (remove network lock)
>>> baseband-related information and features
>>>
>>> Threat severity: High
>>>
>>> == Regular web content (unauthenticated) ==
>>> Use cases for unauthenticated code: None
>>> Authorization model for normal content: None
>>> Potential mitigations: None
>>>
>>> == Trusted (authenticated by publisher) ==
>>> Use cases for authenticated code: None
>>> Authorization model: None
>>> Potential mitigations: None
>>>
>>> == Certified (vouched for by trusted 3rd party) ==
>>> Use cases for certified code: Telephone status UI
>>> Authorization model: Implicit
>>> Potential mitigations: None
>>>
>>> Notes: Some radio feature are also accessible via Settings API
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Thu, 31 May 2012 03:55:45 -0700 (PDT)
>> From: "pther...@mozilla.com" <pther...@mozilla.com>
>> To: mozilla-d...@lists.mozilla.org
>> Subject: Re: WebAPI Security Discussion: Socket API
>> Message-ID: <6c9df7c4-a91d-4f2d...@googlegroups.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>>
>> "Final" proposal. Please reply-to dev-w...@lists.mozilla.org with any major issues.
>>
>> On Wednesday, 9 May 2012 04:50:15 UTC+10, Lucas Adamski wrote:
>>> Please reply-to dev-w...@lists.mozilla.org
>>>
>>> Name of API: Socket API
>>> Reference: https://bugzilla.mozilla.org/show_bug.cgi?id=733573
>>>
>>> Brief purpose of API: Grant full access to raw sockets to allow applications such as SMTP clients etc
>>> General Use Cases: None
>>>
>>> Inherent threats:Malicious apps attacking internal systems (firewall bypass), local device access
>>>
>>> Threat severity: High
>>>
>>> == Regular web content (unauthenticated) ==
>>> Use cases for unauthenticated code:None
>>> Authorization model for normal content:
>>> Authorization model for installed content:
>>> Potential mitigations:
>>>
>>> == Trusted (authenticated by publisher) ==
>>> Use cases for authenticated code: Talk to non-HTTP services. SSH, FTP, mail clients, supporting custom protocols
>>> Use cases for trusted code: Implicit
>>> Potential mitigations: Firewall should prohibit access to privileged low number OS ports (<1024). Listening on a port < 1024 should be prohibited.
>>>
>>> == Certified (vouched for by trusted 3rd party) ==
>>> Use cases for certified code: Open a connection to any domain/port
>>> Authorization model: Implicit
>>> Potential mitigations: None
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Thu, 31 May 2012 04:02:14 -0700 (PDT)
>> From: "pther...@mozilla.com" <pther...@mozilla.com>
>> To: mozilla-d...@lists.mozilla.org
>> Subject: Re: WebAPI Security Discussion: Geolocation
>> Message-ID: <4cbff92e-2e76-4e02...@googlegroups.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> "Final" proposal. Please reply-to dev-w...@lists.mozilla.org with any major issues.
>>
>> The only change below reflects a discussion from the work week, which suggested that we should always show the geolocation indicator, even though it may be undesirable for a "find my stolen phone" app. The logic in this proposal was that it isn't worth trading the privacy risk all the time, for the relatively unlikely scenario of a recovered lost device (an determined thief could simply turn the phone off)
>>
>>
>> Name of API: Geolocation API
>> Reference: _https://developer.mozilla.org/En/Using_geolocation_
>>
>> Brief purpose of API: Obtain current location of user
>> General Use Cases: Mapping applications, GPS navigation, geotagging
>>
>> Inherent threats:
>> * Leakage of user's current location to app
>> * Leakage of user's current location to 3rd party geolocation service
>> * Profiling of user behavior
>>
>> Threat severity: Moderate
>>
>> == Regular web content (unauthenticated) ==
>> Use cases for unauthenticated code: Same
>> Authorization model for normal content: Explicit (default to not remember)
>> Authorization model for installed content:Explicit (default to... ?)
>> Potential mitigations: UI indicator for active geolocation with a path for user to disable
>>
>> == Trusted (authenticated by publisher) ==
>> Use cases for authenticated code: Same
>> Authorization model: Explicit (default to... ?)
>> Potential mitigations: UI indicator for active geolocation with a path for user to disable
>>
>> == Certified (vouched for by trusted 3rd party) ==
>> Use cases for certified code: Device theft recovery; same
>> Authorization model: Implicit
>> Potential mitigations: UI indicator for active geolocation with a path for user to disable
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Thu, 31 May 2012 04:06:41 -0700 (PDT)
>> From: "pther...@mozilla.com" <pther...@mozilla.com>
>> To: mozilla-d...@lists.mozilla.org
>> Subject: Re: WebAPI Security Discussion: Sensor API
>> Message-ID: <8a3398eb-cb95-43a9...@googlegroups.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> "Final" proposal. Please reply-to dev-w...@lists.mozilla.org with any major issues.
>>
>> On Wednesday, 9 May 2012 04:41:46 UTC+10, Lucas Adamski wrote:
>>> Please reply-to dev-w...@lists.mozilla.org
>>>
>>> Name of API: Sensor API
>>> Reference:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=697361
>>> http://dvcs.w3.org/hg/dap/raw-file/tip/sensor-api/
>>>
>>> Brief purpose of API: Let apps access environmental sensor data gathered by devices.
>>> General Use Cases: None
>>>
>>> Inherent threats:Privacy
>>>
>>> Threat severity: Moderate
>>>
>>> == Regular web content (unauthenticated) ==
>>> Use cases for unauthenticated code: Monitor environmental sensor data like temperature, barometer, magnetic field,
>>> Authorization model for normal content: Explicit
>>> Authorization model for installed content: Implicit
>>> Potential mitigations: Only available to top-level content while focused
>>>
>>> == Trusted (authenticated by publisher) ==
>>> Use cases for authenticated code: Same
>>> Use cases for trusted code: Implicit
>>> Potential mitigations:
>>>
>>> == Certified (vouched for by trusted 3rd party) ==
>>> Use cases for certified code:
>>> Backlight Dimming based on ambient light
>>> Screen-off based on proximity
>>> Authorization model: Implicit
>>> Potential mitigations:
>>>
>>> Note: Many device sensor and motion use cases already covered by DeviceOrientation / DeviceMotion API (http://dev.w3.org/geo/api/spec-source-orientation.html)
>>
>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Thu, 31 May 2012 12:48:22 +0100
>> From: Gervase Markham <ge...@mozilla.org>
>> To: dev-w...@lists.mozilla.org
>> Subject: Re: "installs_allowed_from" and openness
>> Message-ID: <4FC75A86...@mozilla.org>
>> Content-Type: text/plain; charset=UTF-8
>>
>> On 29/05/12 22:48, Asa Dotzler wrote:
>>> On 5/29/2012 8:59 AM, Mounir Lamouri wrote:
>>>> Im my opinion, if you give the tools for an application developer to do
>>>> a whitelist of marketplaces allowed to install its application, you are
>>>> giving the tools to prevent openness.
>>>
>>> That sounds an awful lot like the kinds of arguments the walled gardens
>>> are making. "IF you give developers power and control, they'll abuse it
>>> so we're better off not giving it."
>>
>> There are certainly some sorts of power and control we don't want to
>> give developers. The power to send 20 texts without a prompt to a
>> premium-rate SMS number when the app is installed, for example. Your
>> generalization isn't helpful; you need to be more specific about why
>> this particular capability is important enough to free app developers to
>> override my desire as a website creator to facilitate people installing
>> their app because I think it's great.
>>
>> Gerv
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> dev-webapps mailing list
>> dev-w...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-webapps
>>
>>
>> End of dev-webapps Digest, Vol 6, Issue 21
>> ******************************************
> _______________________________________________
> dev-webapps mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapps