Security/AppsProject/IdentityKPIBackend
From MozillaWiki
< Security | AppsProject
Please use "Edit with form" above to edit this page.
Item Reviewed
Identity KPI Backend | |
Target |
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:
- 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
'
- Property "SecReview feature goal" (as page type) with input value "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:
- phase 1 is setting up the backend
- phase 2 will be setting it all up to actually collect the data" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
- Property "SecReview alt solutions" (as page type) with input value "* Web analytics
- It's very early in design, few major concrete designs to document here." contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
- Property "SecReview solution chosen" (as page type) with input value "* Web analytics don't exist and won't be performant for the fine-grained detail we want.
- Also, see previous question." contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
- Property "SecReview threats considered" (as page type) with input value "* Bogus submissions - mitigation via nonce or CSRF token
- DDOS
- Bogus data" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
Action Items
Action Item Status | In Progress |
Release Target | ` |
Action Items | |
* code review of JS (when ready)
|