Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Redesigning the trusted UI
45 views
Skip to first unread message
Paul Theriault
Feb 4, 2014, 1:06:12 AM2/4/14
to Fernando Jiménez Moreno, Kumar McMillan, dev-b2g
Hi Fernando,
Thanks for rekindling this discussion, with all the Haida changes now would seem like a good time to revisit trusted UI, and security UX in general. Firstly - a question: do we use Trusted UI for anything other than payments right now? I assume Firefox Accounts might plan to use this too?
On Jan 28, 2014, at 1:35 AM, Fernando Jiménez Moreno wrote:
> Hi folks!
>
> tl;dr: I would like to change the current trusted UI by:
>
> 1. A system dialog enabled via hardware buttons.
>
> 2. Extra information about web apps.
TLDR response:
My 2 cents: we should abolish trusted UI, and aim for a consistent, UX for displaying the URL and SSL status of the currently displayed page/window/sheet/app/whatever (regardless of whether in app, web page or notification). Instead of entering a "trusted mode" we should just make the current URL and ssl state accessible at all times, which I believe is one of the use cases for Rocketbar (though I may be overstating the use case).
1. Not so sure about this approach - to me it complicates the user experience and doesn't provide a lot of extra security. It also doesnt work for tablets or devices without a button.
2. I think our approach needs to focus on this - we need to provide the equivalent protection of a url bar and certificate information for all web content, no matter where it is rendered. I had a feeling that rocketbar was going to provide this, but I could be wrong.
UX can you point to the latest wireframes for rocketbar? The latest I could find is 0.4 linked from https://wiki.mozilla.org/FirefoxOS/systemsfe#Rocketbar ? PS links here are broken https://wiki.mozilla.org/FirefoxOS/Haida . I thought I saw rocketbar displaying SSL information in the demo Gordon gave last week, but I don't see SSL status being specified in this version. Though I do see this as a use case in 0.4 spec.
>
> Long version:
>
> Let's face it. Nobody likes the trusted UI :(.
Agreed. But if we had a stronger SSL story then we shouldn't need it. Which is where I think you are going with (2).
>
> With the current design, it is really hard for an user to notice why the content embedded within the trusted UI should be considered as trustworthy. We are not giving any hints to the user to help her understand the reasons and rationale behind the current UX. It is even hard for people involved in the development of FxOS to understand these reasons. And even understanding them, there are some serious doubts about its effectiveness. The current visual experience is also far from perfect. We are losing the 20% of the screen size, which is quite significant and seems like a high prize to pay for the questionable benefits of the current UI, specially for some devices already in the market.
>
> So I'd like to take a step back and revisit the design of the trusted UI.
>
> I won't enter in too many details about its use case and requirements. There is an endless discussion about it at [1] that you can read if you feel strong enough for it. But basically, the main reason to require a trusted UI in FxOS is the lack of a browser chrome UI as defined in [2]. In FxOS everything on the screen is web content and fullscreen apps can easily emulate system components like the status bar.
Actually I think this was part of the problem - I feel like we are not clear enough on exactly the threat model, or what the purpose of the trusted UI is, and why we need it. I mean I know why we chose it for v1. But with Haida, and a return to a more website look and feel, solving the general SSL information case would seem to solve our problems here.
>
> So my proposal to solve the issues associated with the lack of a chrome UI is the following:
>
> (A) - Require the usage of hardware buttons to enable system flows where the user is required to enter sensitive information like the payment pin or the Persona password. I am thinking about a flow like:
>
> The user clicks in the "Buy" button of a Marketplace app.
> A system dialog containing the payment flow is shown.
> The dialog is disabled by default and we ask the user to click in (for example) the home button to enable the flow (with a nice expanded explanation about it).
> Once the user clicks the home button, the dialog is usable and the home button recovers its default behavior.
>
> No app can emulate this behavior since hardware button events are only available to the System app. If an app tries to emulate it, the default action assigned to the hardware button will be triggered. In the example above, the app will be closed after hitting the home button.
>
> You may argue that we are making the flow more tedious by adding one extra step to the flow, but this can be mitigated by letting the user disable it via settings at her own risk.
There are a couple issues with this approach:
1. We have to teach the user that "Trusted UI" has to be enabled by a home button click. (and you propose they can disable it, which seems contrary to this goal).
2. User won't notice the absence of this mechanism
3. Could a web page detect the home button press via orientation/accelerometer?
4. Regardless of orientation/accelerometer, an app could spoof this flow just by pretending to receive the home button click and "enabling" the page after a timeout, assuming that the user pressed the home button out of frustration.
5. Last time we discussed this idea, I vaguely remember someone smarter that me explaining that the home button is like a 'panic button' for the user . Ie when the user is confused or freaked out, they can press the home button and it takes them to the home screen, no matter where they are, or what they are doing. How do they escape, now that you stole their beloved home button from them? I'm no designer, but that was the gist I think. (ie What is the user supposed to do if they didnt want to make a payment and the home button isnt currently the home button? )
>
> (B) - The proposal for (A) is only valid for system dialogs and we can only apply it over flows that we trust 100%.
The only place I know we use trusted UI is with payments, and to me this flow isn't actually 100% trusted. Its a remote payment processor, and not part of the system itself - this is part of the reason I don't like our current Trusted UX, we don't even show SSL state so in fact our current trusted UI is actually less secure
> So we are still open to phishing attacks within any other application as we are only exposing a very limited information about them. Right now we are only showing in the card view the origin of the content being shown if it defers from the content of the web app loading it. And sometimes this information is not complete as it might not even fit well in the screen [3]. This can not only confuse and create misleading cues for novice users that are not aware of what an URL is, but it is also insufficient to advanced users who are knowledgable enough to interpret what this means cause we are not providing them enough information.
>
> IMHO we should be showing at least similar information to the one that we show in desktop [4] to tell the user if a connection to a website can be considered secure or not. We should be showing "if the website you are viewing is encrypted, if it is verified, who owns the website, and who verified it". And we should show it with an easily recognizable code like the icons and colors already used in desktop [5].
Totally agree, but after seeing how Trusted UI played out I feel we should solve this for ALL browser windows in one unified way, rather than having a special case for content loaded at one specificURL.
That is of course assuming that we only use Trusted UI for payments. Maybe there are other use cases I am not thinking of.
- Paul
>
> The card view seems like the appropriate place to do it because it is not spoofable by any other app as it is triggered only via hardware buttons and we have relative freedom to show additional information in the same context of the app without affecting the app itself. We can show icons with extended information accesible via click or whatever. I'll let UX decide the best way to display this information.
>
> Any feedback is highly appreciated.
>
> Thanks,
>
> / Fernando
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=768943
> [2] https://developer.mozilla.org/en-US/docs/Chrome
> [3] http://imgur.com/YxBchvS
> [4] https://support.mozilla.org/en-US/kb/how-do-i-tell-if-my-connection-is-secure?as=u&utm_source=inproduct
> [5] https://support.cdn.mozilla.net/media/uploads/gallery/images/2013-07-12-06-34-11-d9ae16.png
> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
Thanks for rekindling this discussion, with all the Haida changes now would seem like a good time to revisit trusted UI, and security UX in general. Firstly - a question: do we use Trusted UI for anything other than payments right now? I assume Firefox Accounts might plan to use this too?
On Jan 28, 2014, at 1:35 AM, Fernando Jiménez Moreno wrote:
> Hi folks!
>
> tl;dr: I would like to change the current trusted UI by:
>
> 1. A system dialog enabled via hardware buttons.
>
> 2. Extra information about web apps.
TLDR response:
My 2 cents: we should abolish trusted UI, and aim for a consistent, UX for displaying the URL and SSL status of the currently displayed page/window/sheet/app/whatever (regardless of whether in app, web page or notification). Instead of entering a "trusted mode" we should just make the current URL and ssl state accessible at all times, which I believe is one of the use cases for Rocketbar (though I may be overstating the use case).
1. Not so sure about this approach - to me it complicates the user experience and doesn't provide a lot of extra security. It also doesnt work for tablets or devices without a button.
2. I think our approach needs to focus on this - we need to provide the equivalent protection of a url bar and certificate information for all web content, no matter where it is rendered. I had a feeling that rocketbar was going to provide this, but I could be wrong.
UX can you point to the latest wireframes for rocketbar? The latest I could find is 0.4 linked from https://wiki.mozilla.org/FirefoxOS/systemsfe#Rocketbar ? PS links here are broken https://wiki.mozilla.org/FirefoxOS/Haida . I thought I saw rocketbar displaying SSL information in the demo Gordon gave last week, but I don't see SSL status being specified in this version. Though I do see this as a use case in 0.4 spec.
>
> Long version:
>
> Let's face it. Nobody likes the trusted UI :(.
Agreed. But if we had a stronger SSL story then we shouldn't need it. Which is where I think you are going with (2).
>
> With the current design, it is really hard for an user to notice why the content embedded within the trusted UI should be considered as trustworthy. We are not giving any hints to the user to help her understand the reasons and rationale behind the current UX. It is even hard for people involved in the development of FxOS to understand these reasons. And even understanding them, there are some serious doubts about its effectiveness. The current visual experience is also far from perfect. We are losing the 20% of the screen size, which is quite significant and seems like a high prize to pay for the questionable benefits of the current UI, specially for some devices already in the market.
>
> So I'd like to take a step back and revisit the design of the trusted UI.
>
> I won't enter in too many details about its use case and requirements. There is an endless discussion about it at [1] that you can read if you feel strong enough for it. But basically, the main reason to require a trusted UI in FxOS is the lack of a browser chrome UI as defined in [2]. In FxOS everything on the screen is web content and fullscreen apps can easily emulate system components like the status bar.
Actually I think this was part of the problem - I feel like we are not clear enough on exactly the threat model, or what the purpose of the trusted UI is, and why we need it. I mean I know why we chose it for v1. But with Haida, and a return to a more website look and feel, solving the general SSL information case would seem to solve our problems here.
>
> So my proposal to solve the issues associated with the lack of a chrome UI is the following:
>
> (A) - Require the usage of hardware buttons to enable system flows where the user is required to enter sensitive information like the payment pin or the Persona password. I am thinking about a flow like:
>
> The user clicks in the "Buy" button of a Marketplace app.
> A system dialog containing the payment flow is shown.
> The dialog is disabled by default and we ask the user to click in (for example) the home button to enable the flow (with a nice expanded explanation about it).
> Once the user clicks the home button, the dialog is usable and the home button recovers its default behavior.
>
> No app can emulate this behavior since hardware button events are only available to the System app. If an app tries to emulate it, the default action assigned to the hardware button will be triggered. In the example above, the app will be closed after hitting the home button.
>
> You may argue that we are making the flow more tedious by adding one extra step to the flow, but this can be mitigated by letting the user disable it via settings at her own risk.
There are a couple issues with this approach:
1. We have to teach the user that "Trusted UI" has to be enabled by a home button click. (and you propose they can disable it, which seems contrary to this goal).
2. User won't notice the absence of this mechanism
3. Could a web page detect the home button press via orientation/accelerometer?
4. Regardless of orientation/accelerometer, an app could spoof this flow just by pretending to receive the home button click and "enabling" the page after a timeout, assuming that the user pressed the home button out of frustration.
5. Last time we discussed this idea, I vaguely remember someone smarter that me explaining that the home button is like a 'panic button' for the user . Ie when the user is confused or freaked out, they can press the home button and it takes them to the home screen, no matter where they are, or what they are doing. How do they escape, now that you stole their beloved home button from them? I'm no designer, but that was the gist I think. (ie What is the user supposed to do if they didnt want to make a payment and the home button isnt currently the home button? )
>
> (B) - The proposal for (A) is only valid for system dialogs and we can only apply it over flows that we trust 100%.
The only place I know we use trusted UI is with payments, and to me this flow isn't actually 100% trusted. Its a remote payment processor, and not part of the system itself - this is part of the reason I don't like our current Trusted UX, we don't even show SSL state so in fact our current trusted UI is actually less secure
> So we are still open to phishing attacks within any other application as we are only exposing a very limited information about them. Right now we are only showing in the card view the origin of the content being shown if it defers from the content of the web app loading it. And sometimes this information is not complete as it might not even fit well in the screen [3]. This can not only confuse and create misleading cues for novice users that are not aware of what an URL is, but it is also insufficient to advanced users who are knowledgable enough to interpret what this means cause we are not providing them enough information.
>
> IMHO we should be showing at least similar information to the one that we show in desktop [4] to tell the user if a connection to a website can be considered secure or not. We should be showing "if the website you are viewing is encrypted, if it is verified, who owns the website, and who verified it". And we should show it with an easily recognizable code like the icons and colors already used in desktop [5].
Totally agree, but after seeing how Trusted UI played out I feel we should solve this for ALL browser windows in one unified way, rather than having a special case for content loaded at one specificURL.
That is of course assuming that we only use Trusted UI for payments. Maybe there are other use cases I am not thinking of.
- Paul
>
> The card view seems like the appropriate place to do it because it is not spoofable by any other app as it is triggered only via hardware buttons and we have relative freedom to show additional information in the same context of the app without affecting the app itself. We can show icons with extended information accesible via click or whatever. I'll let UX decide the best way to display this information.
>
> Any feedback is highly appreciated.
>
> Thanks,
>
> / Fernando
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=768943
> [2] https://developer.mozilla.org/en-US/docs/Chrome
> [3] http://imgur.com/YxBchvS
> [4] https://support.mozilla.org/en-US/kb/how-do-i-tell-if-my-connection-is-secure?as=u&utm_source=inproduct
> [5] https://support.cdn.mozilla.net/media/uploads/gallery/images/2013-07-12-06-34-11-d9ae16.png
> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
Frederik Braun
Feb 4, 2014, 5:00:28 AM2/4/14
to dev...@lists.mozilla.org
On 27.01.2014 15:35, Fernando Jiménez Moreno wrote:
> Hi folks!
>
> tl;dr: I would like to change the current trusted UI by:
>
> 1. A system dialog enabled via hardware buttons.
This is tempting, but I don't know if UX likes it if the home button has
> Hi folks!
>
> tl;dr: I would like to change the current trusted UI by:
>
> 1. A system dialog enabled via hardware buttons.
an implicit second meaning.
>
> 2. Extra information about web apps.
I think the cards view (task manager?) is a possible good place for
> 2. Extra information about web apps.
this. Paul said on IRC he remembered that there was a demo or a mock-up
where you could flip the app card and see some info about it. That would
be interesting.
If all is lost and nobody wants to innovate, we could still display a
lock in the notification bar that indicates the status of the current app :(
Antonio Manuel Amaya Calvo
Feb 7, 2014, 4:59:56 AM2/7/14
to Frederik Braun, dev...@lists.mozilla.org
On 04/02/2014 11:00, Frederik Braun wrote:
> On 27.01.2014 15:35, Fernando Jiménez Moreno wrote:
>> Hi folks!
>>
>> tl;dr: I would like to change the current trusted UI by:
>>
>> 1. A system dialog enabled via hardware buttons.
> This is tempting, but I don't know if UX likes it if the home button has
> an implicit second meaning.
>> 2. Extra information about web apps.
> I think the cards view (task manager?) is a possible good place for
> this. Paul said on IRC he remembered that there was a demo or a mock-up
> where you could flip the app card and see some info about it. That would
> be interesting.
Card view could be a good place for this. In fact, we're already showing
> On 27.01.2014 15:35, Fernando Jiménez Moreno wrote:
>> Hi folks!
>>
>> tl;dr: I would like to change the current trusted UI by:
>>
>> 1. A system dialog enabled via hardware buttons.
> This is tempting, but I don't know if UX likes it if the home button has
> an implicit second meaning.
>> 2. Extra information about web apps.
> I think the cards view (task manager?) is a possible good place for
> this. Paul said on IRC he remembered that there was a demo or a mock-up
> where you could flip the app card and see some info about it. That would
> be interesting.
the URL of the page being shown on the cardview when the domain is
different than the app domain. That is, if you're on the app
"Fantabulous App" and the content being shown belongs to the app, then
the card view shows "Fantabulous App", but if it's showing a page from
http://anotherdifferentdomain.com then it shows
http://anotherdifferentdomain.com (or as much as that as it fits on the
window).
The problem I see with that is that there should be also something on
what the user is actually seeing that tells him that something is
different about that dialog, that it comes from the system. The idea
behind Trusted UI was not as much rethinking the SSL indicator as to
have some way of telling the user 'hey, you can trust this dialog
content because it's been loaded by the OS, nor by any app'. Or more
concise: This dialog is owned by the operating system.
That's a much simple trust decision. Showing the information on the card
view can fill the same role (we can say there also the owner of the
window) but it hides it from plain sight.
>
> If all is lost and nobody wants to innovate, we could still display a
> lock in the notification bar that indicates the status of the current app :(
screen app can imitate this without much problem (they can even copy the
code we use to show that :)).
Best regards,
Antonio
> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
Fernando Jiménez Moreno
Feb 7, 2014, 5:07:39 AM2/7/14
to Paul Theriault, Kumar McMillan, dev-b2g
Hi Paul,
thanks for your feedback!
On 04/02/2014, at 07:06, Paul Theriault <pther...@mozilla.com> wrote:
> Hi Fernando,
>
> Thanks for rekindling this discussion, with all the Haida changes now would seem like a good time to revisit trusted UI, and security UX in general. Firstly - a question: do we use Trusted UI for anything other than payments right now? I assume Firefox Accounts might plan to use this too?
We also use it in the Persona flow.
Firefox Accounts is not using it during the account creation, but we might be using it when re-entering the password is required by relying parties.
>
> On Jan 28, 2014, at 1:35 AM, Fernando Jiménez Moreno wrote:
>
>> Hi folks!
>>
>> tl;dr: I would like to change the current trusted UI by:
>>
>> 1. A system dialog enabled via hardware buttons.
>>
> UX can you point to the latest wireframes for rocketbar? The latest I could find is 0.4 linked fromhttps://wiki.mozilla.org/FirefoxOS/systemsfe#Rocketbar ? PS links here are broken https://wiki.mozilla.org/FirefoxOS/Haida . I thought I saw rocketbar displaying SSL information in the demo Gordon gave last week, but I don't see SSL status being specified in this version. Though I do see this as a use case in 0.4 spec.
>
This seems to be the latest UX wireframes for the rocketbar: https://mozilla.app.box.com/s/v81wwi4xrnfkniin0pn9
>
>>
>> Long version:
>>
>> Let's face it. Nobody likes the trusted UI :(.
>
> Agreed. But if we had a stronger SSL story then we shouldn't need it. Which is where I think you are going with (2).
If the security team is ok with getting rid of the trusted UI in favor of a stronger SSL story, then I am more than happy to remove the trusted UI :)
>>
>> With the current design, it is really hard for an user to notice why the content embedded within the trusted UI should be considered as trustworthy. We are not giving any hints to the user to help her understand the reasons and rationale behind the current UX. It is even hard for people involved in the development of FxOS to understand these reasons. And even understanding them, there are some serious doubts about its effectiveness. The current visual experience is also far from perfect. We are losing the 20% of the screen size, which is quite significant and seems like a high prize to pay for the questionable benefits of the current UI, specially for some devices already in the market.
>>
>> So I'd like to take a step back and revisit the design of the trusted UI.
>>
>> I won't enter in too many details about its use case and requirements. There is an endless discussion about it at [1] that you can read if you feel strong enough for it. But basically, the main reason to require a trusted UI in FxOS is the lack of a browser chrome UI as defined in [2]. In FxOS everything on the screen is web content and fullscreen apps can easily emulate system components like the status bar.
>
> Actually I think this was part of the problem - I feel like we are not clear enough on exactly the threat model, or what the purpose of the trusted UI is, and why we need it. I mean I know why we chose it for v1. But with Haida, and a return to a more website look and feel, solving the general SSL information case would seem to solve our problems here.
>
If I am not wrong, in Haida we still have the same issue of not having a visible chrome UI. The rocketbar shows extra information, but it can still be emulated by fullscreen apps. We have the card view though, but it is not always visible.
>> So my proposal to solve the issues associated with the lack of a chrome UI is the following:
>>
>> (A) - Require the usage of hardware buttons to enable system flows where the user is required to enter sensitive information like the payment pin or the Persona password. I am thinking about a flow like:
>>
>> The user clicks in the "Buy" button of a Marketplace app.
>> A system dialog containing the payment flow is shown.
>> The dialog is disabled by default and we ask the user to click in (for example) the home button to enable the flow (with a nice expanded explanation about it).
>> Once the user clicks the home button, the dialog is usable and the home button recovers its default behavior.
>>
>> No app can emulate this behavior since hardware button events are only available to the System app. If an app tries to emulate it, the default action assigned to the hardware button will be triggered. In the example above, the app will be closed after hitting the home button.
>>
>> You may argue that we are making the flow more tedious by adding one extra step to the flow, but this can be mitigated by letting the user disable it via settings at her own risk.
>
> There are a couple issues with this approach:
> 1. We have to teach the user that "Trusted UI" has to be enabled by a home button click. (and you propose they can disable it, which seems contrary to this goal).
Yes. IMHO it is easier to teach them this mechanism than the homescreen thing that we have now. It is still a challenge though.
> 2. User won't notice the absence of this mechanism
That's part of the teaching part. But I agree that it will be easy for users not to notice the absence of this mechanism.
> 3. Could a web page detect the home button press via orientation/accelerometer?
> 4. Regardless of orientation/accelerometer, an app could spoof this flow just by pretending to receive the home button click and "enabling" the page after a timeout, assuming that the user pressed the home button out of frustration.
> 5. Last time we discussed this idea, I vaguely remember someone smarter that me explaining that the home button is like a 'panic button' for the user . Ie when the user is confused or freaked out, they can press the home button and it takes them to the home screen, no matter where they are, or what they are doing. How do they escape, now that you stole their beloved home button from them? I'm no designer, but that was the gist I think. (ie What is the user supposed to do if they didnt want to make a payment and the home button isnt currently the home button? )
>
These concerns sound reasonable to me and I am afraid that I have no good answer for them. Thanks for pointing them out.
Cheers,
/ Fernando
thanks for your feedback!
On 04/02/2014, at 07:06, Paul Theriault <pther...@mozilla.com> wrote:
> Hi Fernando,
>
> Thanks for rekindling this discussion, with all the Haida changes now would seem like a good time to revisit trusted UI, and security UX in general. Firstly - a question: do we use Trusted UI for anything other than payments right now? I assume Firefox Accounts might plan to use this too?
Firefox Accounts is not using it during the account creation, but we might be using it when re-entering the password is required by relying parties.
>
> On Jan 28, 2014, at 1:35 AM, Fernando Jiménez Moreno wrote:
>
>> Hi folks!
>>
>> tl;dr: I would like to change the current trusted UI by:
>>
>> 1. A system dialog enabled via hardware buttons.
>>
>> 2. Extra information about web apps.
>
>
> TLDR response:
>
> My 2 cents: we should abolish trusted UI, and aim for a consistent, UX for displaying the URL and SSL status of the currently displayed page/window/sheet/app/whatever (regardless of whether in app, web page or notification). Instead of entering a "trusted mode" we should just make the current URL and ssl state accessible at all times, which I believe is one of the use cases for Rocketbar (though I may be overstating the use case).
>
> 1. Not so sure about this approach - to me it complicates the user experience and doesn't provide a lot of extra security. It also doesnt work for tablets or devices without a button.
>
> 2. I think our approach needs to focus on this - we need to provide the equivalent protection of a url bar and certificate information for all web content, no matter where it is rendered. I had a feeling that rocketbar was going to provide this, but I could be wrong.
>
I agree that a consistent UX for displaying the URL and SSL status is required, but we still have the lack of a visible chrome UI. The rocketbar might not be the best place to show this information as it can be emulated by fullscreen apps. I would rather not show anything about the SSL status in the rocketbar and show it only in the cardview. This way apps won't be able to emulate a fake secure situation.
>
> My 2 cents: we should abolish trusted UI, and aim for a consistent, UX for displaying the URL and SSL status of the currently displayed page/window/sheet/app/whatever (regardless of whether in app, web page or notification). Instead of entering a "trusted mode" we should just make the current URL and ssl state accessible at all times, which I believe is one of the use cases for Rocketbar (though I may be overstating the use case).
>
> 1. Not so sure about this approach - to me it complicates the user experience and doesn't provide a lot of extra security. It also doesnt work for tablets or devices without a button.
>
> 2. I think our approach needs to focus on this - we need to provide the equivalent protection of a url bar and certificate information for all web content, no matter where it is rendered. I had a feeling that rocketbar was going to provide this, but I could be wrong.
>
> UX can you point to the latest wireframes for rocketbar? The latest I could find is 0.4 linked fromhttps://wiki.mozilla.org/FirefoxOS/systemsfe#Rocketbar ? PS links here are broken https://wiki.mozilla.org/FirefoxOS/Haida . I thought I saw rocketbar displaying SSL information in the demo Gordon gave last week, but I don't see SSL status being specified in this version. Though I do see this as a use case in 0.4 spec.
>
This seems to be the latest UX wireframes for the rocketbar: https://mozilla.app.box.com/s/v81wwi4xrnfkniin0pn9
>
>>
>> Long version:
>>
>> Let's face it. Nobody likes the trusted UI :(.
>
> Agreed. But if we had a stronger SSL story then we shouldn't need it. Which is where I think you are going with (2).
>>
>> With the current design, it is really hard for an user to notice why the content embedded within the trusted UI should be considered as trustworthy. We are not giving any hints to the user to help her understand the reasons and rationale behind the current UX. It is even hard for people involved in the development of FxOS to understand these reasons. And even understanding them, there are some serious doubts about its effectiveness. The current visual experience is also far from perfect. We are losing the 20% of the screen size, which is quite significant and seems like a high prize to pay for the questionable benefits of the current UI, specially for some devices already in the market.
>>
>> So I'd like to take a step back and revisit the design of the trusted UI.
>>
>> I won't enter in too many details about its use case and requirements. There is an endless discussion about it at [1] that you can read if you feel strong enough for it. But basically, the main reason to require a trusted UI in FxOS is the lack of a browser chrome UI as defined in [2]. In FxOS everything on the screen is web content and fullscreen apps can easily emulate system components like the status bar.
>
> Actually I think this was part of the problem - I feel like we are not clear enough on exactly the threat model, or what the purpose of the trusted UI is, and why we need it. I mean I know why we chose it for v1. But with Haida, and a return to a more website look and feel, solving the general SSL information case would seem to solve our problems here.
>
>> So my proposal to solve the issues associated with the lack of a chrome UI is the following:
>>
>> (A) - Require the usage of hardware buttons to enable system flows where the user is required to enter sensitive information like the payment pin or the Persona password. I am thinking about a flow like:
>>
>> The user clicks in the "Buy" button of a Marketplace app.
>> A system dialog containing the payment flow is shown.
>> The dialog is disabled by default and we ask the user to click in (for example) the home button to enable the flow (with a nice expanded explanation about it).
>> Once the user clicks the home button, the dialog is usable and the home button recovers its default behavior.
>>
>> No app can emulate this behavior since hardware button events are only available to the System app. If an app tries to emulate it, the default action assigned to the hardware button will be triggered. In the example above, the app will be closed after hitting the home button.
>>
>> You may argue that we are making the flow more tedious by adding one extra step to the flow, but this can be mitigated by letting the user disable it via settings at her own risk.
>
> There are a couple issues with this approach:
> 1. We have to teach the user that "Trusted UI" has to be enabled by a home button click. (and you propose they can disable it, which seems contrary to this goal).
> 2. User won't notice the absence of this mechanism
> 3. Could a web page detect the home button press via orientation/accelerometer?
> 4. Regardless of orientation/accelerometer, an app could spoof this flow just by pretending to receive the home button click and "enabling" the page after a timeout, assuming that the user pressed the home button out of frustration.
> 5. Last time we discussed this idea, I vaguely remember someone smarter that me explaining that the home button is like a 'panic button' for the user . Ie when the user is confused or freaked out, they can press the home button and it takes them to the home screen, no matter where they are, or what they are doing. How do they escape, now that you stole their beloved home button from them? I'm no designer, but that was the gist I think. (ie What is the user supposed to do if they didnt want to make a payment and the home button isnt currently the home button? )
>
Cheers,
/ Fernando
Paul Theriault
Feb 7, 2014, 9:39:58 PM2/7/14
to Fernando Jiménez Moreno, Kumar McMillan, dev-b2g, Gordon Brander
On Feb 7, 2014, at 9:07 PM, Fernando Jiménez Moreno wrote:
> Hi Paul,
>
> thanks for your feedback!
>
> On 04/02/2014, at 07:06, Paul Theriault <pther...@mozilla.com> wrote:
>
>> Hi Fernando,
>>
>> Thanks for rekindling this discussion, with all the Haida changes now would seem like a good time to revisit trusted UI, and security UX in general. Firstly - a question: do we use Trusted UI for anything other than payments right now? I assume Firefox Accounts might plan to use this too?
>
> We also use it in the Persona flow.
>
> Firefox Accounts is not using it during the account creation, but we might be using it when re-entering the password is required by relying parties.
>
>>
>> On Jan 28, 2014, at 1:35 AM, Fernando Jiménez Moreno wrote:
>>
>>> Hi folks!
>>>
>>> tl;dr: I would like to change the current trusted UI by:
>>>
>>> 1. A system dialog enabled via hardware buttons.
>>>
>>> 2. Extra information about web apps.
>>
>> TLDR response:
>>
>> My 2 cents: we should abolish trusted UI, and aim for a consistent, UX for displaying the URL and SSL status of the currently displayed page/window/sheet/app/whatever (regardless of whether in app, web page or notification). Instead of entering a "trusted mode" we should just make the current URL and ssl state accessible at all times, which I believe is one of the use cases for Rocketbar (though I may be overstating the use case).
>>
>> 1. Not so sure about this approach - to me it complicates the user experience and doesn't provide a lot of extra security. It also doesnt work for tablets or devices without a button.
>>
>> 2. I think our approach needs to focus on this - we need to provide the equivalent protection of a url bar and certificate information for all web content, no matter where it is rendered. I had a feeling that rocketbar was going to provide this, but I could be wrong.
>>
>
> I agree that a consistent UX for displaying the URL and SSL status is required, but we still have the lack of a visible chrome UI. The rocketbar might not be the best place to show this information as it can be emulated by fullscreen apps. I would rather not show anything about the SSL status in the rocketbar and show it only in the cardview. This way apps won't be able to emulate a fake secure situation.
>
>
>
>> UX can you point to the latest wireframes for rocketbar? The latest I could find is 0.4 linked fromhttps://wiki.mozilla.org/FirefoxOS/systemsfe#Rocketbar ? PS links here are broken https://wiki.mozilla.org/FirefoxOS/Haida . I thought I saw rocketbar displaying SSL information in the demo Gordon gave last week, but I don't see SSL status being specified in this version. Though I do see this as a use case in 0.4 spec.
>>
>
> This seems to be the latest UX wireframes for the rocketbar: https://mozilla.app.box.com/s/v81wwi4xrnfkniin0pn9
>
>
>
>>
>>>
>>> Long version:
>>>
>>> Let's face it. Nobody likes the trusted UI :(.
>>
>> Agreed. But if we had a stronger SSL story then we shouldn't need it. Which is where I think you are going with (2).
>
> If the security team is ok with getting rid of the trusted UI in favor of a stronger SSL story, then I am more than happy to remove the trusted UI :)
>
>
>
>>>
>>> With the current design, it is really hard for an user to notice why the content embedded within the trusted UI should be considered as trustworthy. We are not giving any hints to the user to help her understand the reasons and rationale behind the current UX. It is even hard for people involved in the development of FxOS to understand these reasons. And even understanding them, there are some serious doubts about its effectiveness. The current visual experience is also far from perfect. We are losing the 20% of the screen size, which is quite significant and seems like a high prize to pay for the questionable benefits of the current UI, specially for some devices already in the market.
>>>
>>> So I'd like to take a step back and revisit the design of the trusted UI.
>>>
>>> I won't enter in too many details about its use case and requirements. There is an endless discussion about it at [1] that you can read if you feel strong enough for it. But basically, the main reason to require a trusted UI in FxOS is the lack of a browser chrome UI as defined in [2]. In FxOS everything on the screen is web content and fullscreen apps can easily emulate system components like the status bar.
>>
>> Actually I think this was part of the problem - I feel like we are not clear enough on exactly the threat model, or what the purpose of the trusted UI is, and why we need it. I mean I know why we chose it for v1. But with Haida, and a return to a more website look and feel, solving the general SSL information case would seem to solve our problems here.
>>
>
> If I am not wrong, in Haida we still have the same issue of not having a visible chrome UI. The rocketbar shows extra information, but it can still be emulated by fullscreen apps. We have the card view though, but it is not always visible.
So I think, from the spec and seeing demos, the rocketbar usually hides itself (I mean collapse to small state or hidden completely). The user has to swipe down from the top of the screen to see the view which shows the URL I think. At this point, I _think_ we can guarantee the real rocketbar is displayed. (assuming the app can somehow intercept the touch event - I don't know how this works when the app is fullscreen. Is a 'swipe-from-top-of-screen' treated as a different type of event or something that goes straight to the system app? If it is, then this would stop a fullscreen app from interfering. Not sure if this is too subtle a distinction though - maybe need user testing to determine if users actually notice the difference.
From here, we are showing a url bar, so we can display an ssl indicator. Tapping on the SSL icon should then provide more information, the way it does on desktop. This could in something like the existing trusted UI.
>
>
>
>>> So my proposal to solve the issues associated with the lack of a chrome UI is the following:
>>>
>>> (A) - Require the usage of hardware buttons to enable system flows where the user is required to enter sensitive information like the payment pin or the Persona password. I am thinking about a flow like:
>>>
>>> The user clicks in the "Buy" button of a Marketplace app.
>>> A system dialog containing the payment flow is shown.
>>> The dialog is disabled by default and we ask the user to click in (for example) the home button to enable the flow (with a nice expanded explanation about it).
>>> Once the user clicks the home button, the dialog is usable and the home button recovers its default behavior.
>>>
>>> No app can emulate this behavior since hardware button events are only available to the System app. If an app tries to emulate it, the default action assigned to the hardware button will be triggered. In the example above, the app will be closed after hitting the home button.
>>>
>>> You may argue that we are making the flow more tedious by adding one extra step to the flow, but this can be mitigated by letting the user disable it via settings at her own risk.
>>
>> There are a couple issues with this approach:
>> 1. We have to teach the user that "Trusted UI" has to be enabled by a home button click. (and you propose they can disable it, which seems contrary to this goal).
>
> Yes. IMHO it is easier to teach them this mechanism than the homescreen thing that we have now. It is still a challenge though.
>
>
>
>> 2. User won't notice the absence of this mechanism
>
> That's part of the teaching part. But I agree that it will be easy for users not to notice the absence of this mechanism.
You are right. On reflection this is true of all security indicators.
>
>
>> 2. User won't notice the absence of this mechanism
>
> That's part of the teaching part. But I agree that it will be easy for users not to notice the absence of this mechanism.
Paul Theriault
Feb 7, 2014, 10:00:28 PM2/7/14
to Antonio Manuel Amaya Calvo, Frederik Braun, dev...@lists.mozilla.org
On Feb 7, 2014, at 8:59 PM, Antonio Manuel Amaya Calvo wrote:
> On 04/02/2014 11:00, Frederik Braun wrote:
>> On 27.01.2014 15:35, Fernando Jiménez Moreno wrote:
>>> Hi folks!
>>>
>>> tl;dr: I would like to change the current trusted UI by:
>>>
>>> 1. A system dialog enabled via hardware buttons.
>>> Hi folks!
>>>
>>> tl;dr: I would like to change the current trusted UI by:
>>>
>>> 1. A system dialog enabled via hardware buttons.
>> This is tempting, but I don't know if UX likes it if the home button has
>> an implicit second meaning.
>> an implicit second meaning.
>>> 2. Extra information about web apps.
>> I think the cards view (task manager?) is a possible good place for
>> this. Paul said on IRC he remembered that there was a demo or a mock-up
>> where you could flip the app card and see some info about it. That would
>> be interesting.
> Card view could be a good place for this. In fact, we're already showing
> the URL of the page being shown on the cardview when the domain is
> different than the app domain. That is, if you're on the app
> "Fantabulous App" and the content being shown belongs to the app, then
> the card view shows "Fantabulous App", but if it's showing a page from
> http://anotherdifferentdomain.com then it shows
> http://anotherdifferentdomain.com (or as much as that as it fits on the
> window).
>
> The problem I see with that is that there should be also something on
> what the user is actually seeing that tells him that something is
> different about that dialog, that it comes from the system. The idea
> behind Trusted UI was not as much rethinking the SSL indicator as to
> have some way of telling the user 'hey, you can trust this dialog
> content because it's been loaded by the OS, nor by any app'. Or more
> concise: This dialog is owned by the operating system.
The main thing that bugs me about the current trusted UI is that we use it to load remote content, and content that is worth spoofing (since in the payment flow the user is asked for PIN & payment information). So to the user it looks like it is part of the system, but in actual fact it is loading a remote web page.
>> this. Paul said on IRC he remembered that there was a demo or a mock-up
>> where you could flip the app card and see some info about it. That would
>> be interesting.
> Card view could be a good place for this. In fact, we're already showing
> the URL of the page being shown on the cardview when the domain is
> different than the app domain. That is, if you're on the app
> "Fantabulous App" and the content being shown belongs to the app, then
> the card view shows "Fantabulous App", but if it's showing a page from
> http://anotherdifferentdomain.com then it shows
> http://anotherdifferentdomain.com (or as much as that as it fits on the
> window).
>
> The problem I see with that is that there should be also something on
> what the user is actually seeing that tells him that something is
> different about that dialog, that it comes from the system. The idea
> behind Trusted UI was not as much rethinking the SSL indicator as to
> have some way of telling the user 'hey, you can trust this dialog
> content because it's been loaded by the OS, nor by any app'. Or more
> concise: This dialog is owned by the operating system.
>
> That's a much simple trust decision. Showing the information on the card
> view can fill the same role (we can say there also the owner of the
> window) but it hides it from plain sight.
>
>
>>
>> If all is lost and nobody wants to innovate, we could still display a
>> lock in the notification bar that indicates the status of the current app :(
> And the problem with this (and also with the rocket bar) is that a full
> screen app can imitate this without much problem (they can even copy the
> code we use to show that :)).
Alive
Feb 8, 2014, 5:41:18 AM2/8/14
to Paul Theriault, Antonio Manuel Amaya Calvo, Frederik Braun, dev...@lists.mozilla.org
Paul Theriault <pther...@mozilla.com> 於 2014/2/8 上午4:00 寫道：
> I could be wrong, but if we have a way to shown the rocketbar in fullscreen, can't we ensure that the rocketbar is always shown when you swipe down from the top? And therefore have a way to ensure that the _real_ rocketbar is always shown. I guess what I'm hoping is that the "swipe from top of screen" gesture can be made unspoofable in the same way that a homescreen button is unspoofable. Not sure if this is actually possible though. Can this be done by catching gesture events somehow? Or could a fullscreen app intercept these events?
>>
>> Best regards,
>>
>> Antonio
>>
>>> _______________________________________________
>>> dev-b2g mailing list
>>> dev...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-b2g
>>
>>
>> ________________________________
>>
>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
>> This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>> _______________________________________________
>> dev-b2g mailing list
>> dev...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-b2g
>
> _______________________________________________
> dev-b2g mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-b2g
Alive C. Kuo, Senior Front-end/Software Engineer, FirefoxOS, MoCo. Taiwan, Taipei office.
al...@mozilla.com
Kumar McMillan
Feb 18, 2014, 3:27:07 PM2/18/14
to Paul Theriault, Fernando Jiménez Moreno, dev-b2g, Gordon Brander
On Feb 7, 2014, at 8:39 PM, Paul Theriault <pther...@mozilla.com> wrote:
>
> On Feb 7, 2014, at 9:07 PM, Fernando Jiménez Moreno wrote:
>
>> Hi Paul,
>>
>> thanks for your feedback!
>>
>> On 04/02/2014, at 07:06, Paul Theriault <pther...@mozilla.com> wrote:
>>
>>> Hi Fernando,
>>>
>>> Thanks for rekindling this discussion, with all the Haida changes now would seem like a good time to revisit trusted UI, and security UX in general. Firstly - a question: do we use Trusted UI for anything other than payments right now? I assume Firefox Accounts might plan to use this too?
>>
>> We also use it in the Persona flow.
>>
>> Firefox Accounts is not using it during the account creation, but we might be using it when re-entering the password is required by relying parties.
>>
>>>
>>> On Jan 28, 2014, at 1:35 AM, Fernando Jiménez Moreno wrote:
>>>
>>>> Hi folks!
>>>>
>>>> tl;dr: I would like to change the current trusted UI by:
>>>>
>>>> 1. A system dialog enabled via hardware buttons.
>>>>
>>>
>>>> Hi folks!
>>>>
>>>> tl;dr: I would like to change the current trusted UI by:
>>>>
>>>> 1. A system dialog enabled via hardware buttons.
>>>>
>>>> 2. Extra information about web apps.
>>>
>>>
>>> TLDR response:
>>>
>>> My 2 cents: we should abolish trusted UI, and aim for a consistent, UX for displaying the URL and SSL status of the currently displayed page/window/sheet/app/whatever (regardless of whether in app, web page or notification). Instead of entering a "trusted mode" we should just make the current URL and ssl state accessible at all times, which I believe is one of the use cases for Rocketbar (though I may be overstating the use case).
>>>
>>> 1. Not so sure about this approach - to me it complicates the user experience and doesn't provide a lot of extra security. It also doesnt work for tablets or devices without a button.
>>>
>>> 2. I think our approach needs to focus on this - we need to provide the equivalent protection of a url bar and certificate information for all web content, no matter where it is rendered. I had a feeling that rocketbar was going to provide this, but I could be wrong.
>>>
>>
>> I agree that a consistent UX for displaying the URL and SSL status is required, but we still have the lack of a visible chrome UI. The rocketbar might not be the best place to show this information as it can be emulated by fullscreen apps. I would rather not show anything about the SSL status in the rocketbar and show it only in the cardview. This way apps won't be able to emulate a fake secure situation.
>>
>>
>>
>>> UX can you point to the latest wireframes for rocketbar? The latest I could find is 0.4 linked fromhttps://wiki.mozilla.org/FirefoxOS/systemsfe#Rocketbar ? PS links here are broken https://wiki.mozilla.org/FirefoxOS/Haida . I thought I saw rocketbar displaying SSL information in the demo Gordon gave last week, but I don't see SSL status being specified in this version. Though I do see this as a use case in 0.4 spec.
>>>
>>
>> This seems to be the latest UX wireframes for the rocketbar: https://mozilla.app.box.com/s/v81wwi4xrnfkniin0pn9
>
> So I see displaying SSL listed as a use case in this spec, but i can't see the flow actually specified. But it should be possible to display SSL information in the rocketbar, whilst also deterring spoofing. Note that the rocketbar is usually hidden but shown when the user drags from the top of the screen. This behavior should always show the real rocketbar i think? (ie an app could create a fake bar, but it wouldnt be able to mimic the behavior of the real rocket bar, I think?)
>
>>
>>
>>
>>>
>>>>
>>>> Long version:
>>>>
>>>> Let's face it. Nobody likes the trusted UI :(.
>>>
>>> Agreed. But if we had a stronger SSL story then we shouldn't need it. Which is where I think you are going with (2).
>>
>> If the security team is ok with getting rid of the trusted UI in favor of a stronger SSL story, then I am more than happy to remove the trusted UI :)
>
> I just don't think we should be using for remote content, especially when we don't enforce any requirements (e.g. we don't even force SSL here).
We only allow mozPay to open an HTTPS URL to a payment provider. However, there is a potential subsequent request done over HTTP to sniff header injection.
>>>
>>> My 2 cents: we should abolish trusted UI, and aim for a consistent, UX for displaying the URL and SSL status of the currently displayed page/window/sheet/app/whatever (regardless of whether in app, web page or notification). Instead of entering a "trusted mode" we should just make the current URL and ssl state accessible at all times, which I believe is one of the use cases for Rocketbar (though I may be overstating the use case).
>>>
>>> 1. Not so sure about this approach - to me it complicates the user experience and doesn't provide a lot of extra security. It also doesnt work for tablets or devices without a button.
>>>
>>> 2. I think our approach needs to focus on this - we need to provide the equivalent protection of a url bar and certificate information for all web content, no matter where it is rendered. I had a feeling that rocketbar was going to provide this, but I could be wrong.
>>>
>>
>> I agree that a consistent UX for displaying the URL and SSL status is required, but we still have the lack of a visible chrome UI. The rocketbar might not be the best place to show this information as it can be emulated by fullscreen apps. I would rather not show anything about the SSL status in the rocketbar and show it only in the cardview. This way apps won't be able to emulate a fake secure situation.
>>
>>
>>
>>> UX can you point to the latest wireframes for rocketbar? The latest I could find is 0.4 linked fromhttps://wiki.mozilla.org/FirefoxOS/systemsfe#Rocketbar ? PS links here are broken https://wiki.mozilla.org/FirefoxOS/Haida . I thought I saw rocketbar displaying SSL information in the demo Gordon gave last week, but I don't see SSL status being specified in this version. Though I do see this as a use case in 0.4 spec.
>>>
>>
>> This seems to be the latest UX wireframes for the rocketbar: https://mozilla.app.box.com/s/v81wwi4xrnfkniin0pn9
>
> So I see displaying SSL listed as a use case in this spec, but i can't see the flow actually specified. But it should be possible to display SSL information in the rocketbar, whilst also deterring spoofing. Note that the rocketbar is usually hidden but shown when the user drags from the top of the screen. This behavior should always show the real rocketbar i think? (ie an app could create a fake bar, but it wouldnt be able to mimic the behavior of the real rocket bar, I think?)
>
>>
>>
>>
>>>
>>>>
>>>> Long version:
>>>>
>>>> Let's face it. Nobody likes the trusted UI :(.
>>>
>>> Agreed. But if we had a stronger SSL story then we shouldn't need it. Which is where I think you are going with (2).
>>
>> If the security team is ok with getting rid of the trusted UI in favor of a stronger SSL story, then I am more than happy to remove the trusted UI :)
>
> I just don't think we should be using for remote content, especially when we don't enforce any requirements (e.g. we don't even force SSL here).
There are a couple different threats but these are the specific phishing threats I see for payments:
- someone other than Mozilla Persona asks you for your email + password
- someone other than Firefox Marketplace asks you for your payment PIN
The attacker would then need to steal your phone (since operator billing and/or saved credit cards are tied to a MSISDN) and they could make fraudulent payments with those credentials.
I also think trying to solve this with some kind of trusted SSL indicator is probably a better way to go. If you could inspect the cert when something looked phishy then you could trust the site you're on. However, one also have to *know* how to inspect the identity of a web page. There is a major UX challenge here. Even if the rocket bar pulldown is not spoofable, users still need to *know* how to verify someone's identity. Pulling down the rocket bar also seems like friction. A user might do it the first couple times but afterward they will just want to pay for the item. If nothing looks suspicious they probably won't check.
I agree with Paul's points about the problems of a home button.
I don't see any clear solutions here but I'm glad we're talking about it again. It's pretty well established that the current trusted UI adds no protection whatsoever and removes valuable screen real estate. If nothing else, I think we should consider getting rid of it until we have something that actually adds security.
-Kumar
0 new messages