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 > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
