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, [email protected] wrote: > >> Send dev-webapps mailing list submissions to >> [email protected] >> >> 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 >> [email protected] >> >> You can reach the person managing the list at >> [email protected] >> >> 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 >> ([email protected]) >> 2. Re: WebAPI Security Discussion: Mobile Connection API >> ([email protected]) >> 3. Re: WebAPI Security Discussion: Socket API >> ([email protected]) >> 4. Re: WebAPI Security Discussion: Geolocation >> ([email protected]) >> 5. Re: WebAPI Security Discussion: Sensor API >> ([email protected]) >> 6. Re: "installs_allowed_from" and openness (Gervase Markham) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Thu, 31 May 2012 03:48:12 -0700 (PDT) >> From: "[email protected]" <[email protected]> >> To: [email protected] >> Cc: "[email protected]" <[email protected]> >> Subject: Re: WebAPI Security Discussion: Power Management >> Message-ID: <[email protected]> >> 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 [email protected] >>> * >>> 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: "[email protected]" <[email protected]> >> To: [email protected] >> Subject: Re: WebAPI Security Discussion: Mobile Connection API >> Message-ID: <[email protected]> >> 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 [email protected] >>> >>> 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: "[email protected]" <[email protected]> >> To: [email protected] >> Subject: Re: WebAPI Security Discussion: Socket API >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> >> "Final" proposal. Please reply-to [email protected] with any >> major issues. >> >> On Wednesday, 9 May 2012 04:50:15 UTC+10, Lucas Adamski wrote: >>> Please reply-to [email protected] >>> >>> 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: "[email protected]" <[email protected]> >> To: [email protected] >> Subject: Re: WebAPI Security Discussion: Geolocation >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> "Final" proposal. Please reply-to [email protected] 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: "[email protected]" <[email protected]> >> To: [email protected] >> Subject: Re: WebAPI Security Discussion: Sensor API >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> "Final" proposal. Please reply-to [email protected] with any >> major issues. >> >> On Wednesday, 9 May 2012 04:41:46 UTC+10, Lucas Adamski wrote: >>> Please reply-to [email protected] >>> >>> 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 <[email protected]> >> To: [email protected] >> Subject: Re: "installs_allowed_from" and openness >> Message-ID: <[email protected]> >> 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 >> [email protected] >> https://lists.mozilla.org/listinfo/dev-webapps >> >> >> End of dev-webapps Digest, Vol 6, Issue 21 >> ****************************************** > _______________________________________________ > dev-webapps mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-webapps _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
