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