Confirmed users
1,022
edits
| Line 183: | Line 183: | ||
=Security Review= | =Security Review= | ||
Review the Server side components of Campaign Manager | |||
== Introduce Feature (5-10 minutes) [can be answered ahead of time to save meeting time]== | |||
This feature provides the server components to remote clients for the Campaign Manager. It accepts general device profile information including: | |||
* Product (e.g. "android") | |||
* Channel (e.g. "nightly") | |||
* Platform (e.g. "ARMv6") | |||
* Version (e.g. "18.0") | |||
* User Locale and Language (e.g. "en-US") | |||
* Idle time in days | |||
and returns a set of candidate messages to display to the user. Messages include a title, brief call to action message and an action URL. | |||
The URL passes through the redirector function which records that the url for the campaign has been selected. No other user specific information is recorded. | |||
=== Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)=== | |||
See above. | |||
tl;dr: Campaigns attempt to re-engage users who may not be using the device as frequently as we'd prefer. | |||
=== What solutions/approaches were considered other than the proposed solution?=== | |||
Since this is a mozilla specific concern and issue, with tight integration to the client, I don't believe that other solutions were considered. | |||
=== Why was this solution chosen?=== | |||
== Any security threats already considered in the design and why?== | |||
The biggest thread is the authoring system. We rely on persona providing a fully verified email address, then check that the provided address originates with @mozilla.com or @mozilla.org. Rogue entries could be blocked by a 'whitelist', however entries are recorded with the author's email and could be easily identified. | |||
== Threat Brainstorming (30-40 minutes)== | |||
== Conclusions / Action Items (10-20 minutes)== | |||