Canmove, confirm, emeritus
2,776
edits
Changes
Created page with "Items to be reviewed: In-content UI Visual Unification - https://wiki.mozilla.org/Features/Firefox/In-content_UI_Visual_Unification == Introduce Feature == === Goal of Feature..."
Items to be reviewed:
In-content UI Visual Unification - https://wiki.mozilla.org/Features/Firefox/In-content_UI_Visual_Unification
== Introduce Feature ==
=== Goal of Feature, what is trying to be achieved (problem solved, use cases, etc) ===
* in content pages that are chrome privileged
* make things more consistent
** Updated Error and Phishing Mockups:
*** http://cl.ly/170i2e2m1m1R3k3f3g3h/o
*** http://cl.ly/003d1L272z0p3G0b0s10/o
*** http://www.stephenhorlander.com/images/blog-posts/incontent-ui/win7-neterror.jpg
* updating about:crashes & error pages, security exception pages
** just updating the look for consistency
* for other pages this is a unification of the look, but not a lot that is new
* also want things to be less able to be spoofed
** i.e. navigation not shown in places like add-ons manager, about:config
=== What solutions/approaches were considered other than the proposed solution? ===
* none, unification is necessary to avoid confusing users
=== Why was this solution chosen? ===
* best way to give consistency to the product
=== Any security threats already considered in the design and why? ===
* some thought given to the UI to prevent its use as a spoofable object
== Threat Brainstorming ==
* Given there is no address bar for app tabs how does this help with spoofing?
** does this imply the breadcrumbs won't be shown for app tabs also ?
*** yes, it does. Whatever the content provides, would but up to the content provider
** For in-content UI this will style to mesh with the page
** main concern is if a dialog box can be opened that would allow a user to input sensitive info such as username/password
* Could we leverage a theme or persona the user has chosen to help with this?
** this is being looked at but not landed at this time
** there is a platform problem that makes the text look bad that needs to be fixed first
== Conclusions / Action Items ==
* need to have a larger discussion on how to make master password or sign-in type items less spoofable
** out of scope for this discussion
* Change code so that address bar will not be removed when the about: page is marked "safe". Then, we can rely on the fact that the user navigated to the page by some Chrome action or keyboard shortcut.
** We are assuming all pages will open in a new tab. We should document this decision somewhere (e.g. in the code)
** We should document that we are not allowing open web apps to let personas bleed through due to security concerns.
In-content UI Visual Unification - https://wiki.mozilla.org/Features/Firefox/In-content_UI_Visual_Unification
== Introduce Feature ==
=== Goal of Feature, what is trying to be achieved (problem solved, use cases, etc) ===
* in content pages that are chrome privileged
* make things more consistent
** Updated Error and Phishing Mockups:
*** http://cl.ly/170i2e2m1m1R3k3f3g3h/o
*** http://cl.ly/003d1L272z0p3G0b0s10/o
*** http://www.stephenhorlander.com/images/blog-posts/incontent-ui/win7-neterror.jpg
* updating about:crashes & error pages, security exception pages
** just updating the look for consistency
* for other pages this is a unification of the look, but not a lot that is new
* also want things to be less able to be spoofed
** i.e. navigation not shown in places like add-ons manager, about:config
=== What solutions/approaches were considered other than the proposed solution? ===
* none, unification is necessary to avoid confusing users
=== Why was this solution chosen? ===
* best way to give consistency to the product
=== Any security threats already considered in the design and why? ===
* some thought given to the UI to prevent its use as a spoofable object
== Threat Brainstorming ==
* Given there is no address bar for app tabs how does this help with spoofing?
** does this imply the breadcrumbs won't be shown for app tabs also ?
*** yes, it does. Whatever the content provides, would but up to the content provider
** For in-content UI this will style to mesh with the page
** main concern is if a dialog box can be opened that would allow a user to input sensitive info such as username/password
* Could we leverage a theme or persona the user has chosen to help with this?
** this is being looked at but not landed at this time
** there is a platform problem that makes the text look bad that needs to be fixed first
== Conclusions / Action Items ==
* need to have a larger discussion on how to make master password or sign-in type items less spoofable
** out of scope for this discussion
* Change code so that address bar will not be removed when the about: page is marked "safe". Then, we can rely on the fact that the user navigated to the page by some Chrome action or keyboard shortcut.
** We are assuming all pages will open in a new tab. We should document this decision somewhere (e.g. in the code)
** We should document that we are not allowing open web apps to let personas bleed through due to security concerns.
