Hi Paul, thanks for your feedback!
On 04/02/2014, at 07:06, Paul Theriault <[email protected]> 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 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 _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
