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 <[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
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). > > > >>> >>> 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. I think displaying the URL and lock icon in card view is a good idea. But also we should be able to make rocketbar difficult to spoof. 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. Yeh maybe, and at least it gives up space to explain it. > > > >> 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. > > > >> 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
