Security/AppsProject/IdentityKPIBackend

Please use "Edit with form" above to edit this page.

Item Reviewed

Identity KPI Backend
Target	https://wiki.mozilla.org/Identity/BrowserID/KPI_Dashboard# bug 742796

{{#set:SecReview name=Identity KPI Backend

|SecReview target=

• https://wiki.mozilla.org/Identity/BrowserID/KPI_Dashboard#
• bug 742796

}}

Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

The main objective of this feature is to allow the BrowserID product team to access how well changes to the service are meeting key performance indicators (KPI). UX will design a feature change, engineering will build it and a KPI Dashboard will give us the feedback of how successful the change is with real users.

We're providing an authenitcation UI for the web, so having the most tested and refined flows is critical to Mozilla's success. (This isn't the auth flow for a single web property).
KPI Backend must be built before we build the KPI Dashboard, which will  be built next quarter and have it's own privacy review. KPI Backend  stores the raw data described at https://wiki.mozilla.org/Privacy/Reviews/KPI_Backend#Example_data.

• Use Cases:
  • https://bugzilla.mozilla.org/show_bug.cgi?id=746231
  • https://bugzilla.mozilla.org/show_bug.cgi?id=746233

• phase 1 is setting up the backend
• phase 2 will be setting it all up to actually collect the data

What solutions/approaches were considered other than the proposed solution?

• Web analytics
• It's very early in design, few major concrete designs to document here.

Why was this solution chosen?

• Web analytics don't exist and won't be performant for the fine-grained detail we want.
• Also, see previous question.

Any security threats already considered in the design and why?

• Bogus submissions - mitigation via nonce or CSRF token
• DDOS
• Bogus data

Threat Brainstorming

' {{#set: SecReview feature goal=The main objective of this feature is to allow the BrowserID product team to access how well changes to the service are meeting key performance indicators (KPI). UX will design a feature change, engineering will build it and a KPI Dashboard will give us the feedback of how successful the change is with real users.

We're providing an authenitcation UI for the web, so having the most tested and refined flows is critical to Mozilla's success. (This isn't the auth flow for a single web property).
KPI Backend must be built before we build the KPI Dashboard, which will  be built next quarter and have it's own privacy review. KPI Backend  stores the raw data described at https://wiki.mozilla.org/Privacy/Reviews/KPI_Backend#Example_data.

• Use Cases:
  • https://bugzilla.mozilla.org/show_bug.cgi?id=746231
  • https://bugzilla.mozilla.org/show_bug.cgi?id=746233

• phase 1 is setting up the backend
• phase 2 will be setting it all up to actually collect the data

|SecReview alt solutions=* Web analytics

• It's very early in design, few major concrete designs to document here.

|SecReview solution chosen=* Web analytics don't exist and won't be performant for the fine-grained detail we want.

• Also, see previous question.

|SecReview threats considered=* Bogus submissions - mitigation via nonce or CSRF token

• DDOS
• Bogus data

|SecReview threat brainstorming=' }}

Action Items

Action Item Status	In Progress
Release Target	`
Action Items
* code review of JS (when ready) code review of WebService API (when ready)

{{#set:|SecReview action item status=In Progress

|Feature version=` |SecReview action items=* code review of JS (when ready)

• code review of WebService API (when ready)

}}