1319984 - Consider support for a new security UI widget

Status: NEW

(Firefox :: Security, defect, P3)

Description

[Jonathan Kingston [:jkt] he/him]

Attachment: masterpass.jpeg

There are several features within the browser future/present that would benefit from a specific 'global' security UX that isn't site specific such as the site identity door hanger.
These are:
- Master password
- Credential management API
- Payment request API

This has been discussed many times to have something clearer to the user that the user can trust and perhaps have more room for details.

This probably would be something that appears from below the URL bar and overlaps with the browser chrome. This shouldn't be hidden when the user loses focus with the window but could hide when the user changes tab however probably shouldn't in the master password case.

Comment 1

[Daniel Veditz [:dveditz]]

A bugzilla component? A UI widget?

Comment 2

[Tanvi Vyas[:tanvi]]

I believe there is UX work underway in Taipei for Web Payments.  Adding pdol to add the relevant UX designers.

Comment 3

[Jonathan Kingston [:jkt] he/him]

Sorry yes a UI widget.

Comment 4

[Axel Nennker]

There should no modal dialogs anyways.
This one is jumping in my face every time I start Nightly.
Please put it in the chrome.

Comment 5

[Peter Dolanjski [:pdol]]

+Philipp (for general PrivSec UX), Juwei (for web payments) for thoughts

Comment 6

[Axel Nennker]

Attachment: Login To Chrome

Should this UI support something like "login to Chrome"?
Login to Firefox

Comment 7

[(Currently slow to respond) Philipp Sackl [:phlsa] (Firefox UX) please use needinfo]

Bouncing this to Amin who is working on this component

Comment 8

[Amin Al Hazwani [:amin] (Firefox UX)]

I am currently working on a Tab Modal that covers all these scenarios. We thought about a Tab Modal instead of a Window Modal because it freezes only the current tab instead of the whole application. I'm listing an inventory of all cases that we could cover with this modal. Currently I have listed:
- http authentication
- js alert/prompt messages
- web payments
- wifi warnings/VPN
- add-on installation
As soon as I have the spec I will share it with you guys.

Jonathan could you share also a screenshot for credential management and payments API? Thank you!

Comment 9

[Axel Nennker]

Is the masterpassword prompt deliberately not on this list

Comment 10

[Jonathan Kingston [:jkt] he/him]

Hey :marcosc, do you have a screenshot of the payments API? How is that implemented/going to be implemented?

:amin - We currently don't support credential management, this is a prerequisite.

- For the payment request API see how Chrome has implemented it: https://developers.google.com/web/fundamentals/discovery-and-monetization/payment-request/ However last time I checked it was only for mobile checking how Apple pay in Safari is implemented might be a good reference: https://support.apple.com/kb/PH25811?locale=en_US

- Some videos of how Chrome implements the credential management API are here: https://developers.google.com/web/updates/2016/04/credential-management-api

Comment 11

[Jonathan Kingston [:jkt] he/him]

Do you have a bug for the Tab Modal so we can tie these together?

Comment 12

[Amin Al Hazwani [:amin] (Firefox UX)]

Axel no, that was not intentional. That is also a case that can be included in the list. I only listed the cases I identified jfyi.

:jkt thanks for your feedback. I don't think there's a bug for the Tab Modal, shall we create one?

Comment 13

[Matthew N. [:MattN]]

Can't this be the bug?

Comment 14

[Amin Al Hazwani [:amin] (Firefox UX)]

:MattN I agree

Comment 15

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

(In reply to Amin Al Hazwani [:amin] (Firefox UX) from comment #8)
> I am currently working on a Tab Modal that covers all these scenarios. We
> thought about a Tab Modal instead of a Window Modal because it freezes only
> the current tab instead of the whole application. I'm listing an inventory
> of all cases that we could cover with this modal. Currently I have listed:
> - http authentication
> - js alert/prompt messages
> - web payments
> - wifi warnings/VPN
> - add-on installation

Perhaps I've misunderstood the aim of this bug, but I wanted to also throw out the idea of adding client certificate authentication to this list if it made sense.

Comment 16

[Amin Al Hazwani [:amin] (Firefox UX)]

:keller if you must make a decision, either accept or reject the certificate in order to access the tab, then yes - it makes sense to add it to the list. The more cases we have the better I will understand the content requirements. This will help me in structuring the component in a flexible manner.

Comment 17

[Jonathan Kingston [:jkt] he/him]

This can be the bug certainly I just wanted to mark this as duplicate if there was another.

:keeler I suspect the widget can work for client certs, I have however never seen them in action. Do you have any example urls?

The use-case as :amin suggested would be for a tab related prompt similar to how alert behaves but is clear that it came from browser chrome. This would be distinct from extension doorhangers and the site identity doorhanger that comes from the (i) icon in the URL bar.

Comment 18

[Juwei Huang[:juwei]]

(In reply to Jonathan Kingston [:jkt] from comment #10)
> Hey :marcosc, do you have a screenshot of the payments API? How is that
> implemented/going to be implemented?
> 
> :amin - We currently don't support credential management, this is a
> prerequisite.
> 
> - For the payment request API see how Chrome has implemented it:
> https://developers.google.com/web/fundamentals/discovery-and-monetization/
> payment-request/ However last time I checked it was only for mobile checking
> how Apple pay in Safari is implemented might be a good reference:
> https://support.apple.com/kb/PH25811?locale=en_US
> 
> - Some videos of how Chrome implements the credential management API are
> here:
> https://developers.google.com/web/updates/2016/04/credential-management-api

Hihi this is the current mock up for web payment on desktop: https://drive.google.com/open?id=0BzpS-SDqaHnAbk5TSS1Vc0Z2NUk
The UI contains multiple functions to let users select, add and edit the payment details.
It would be better to use tab model so that users still can switch tabs if they want to compare price.

Comment 19

[Juwei Huang[:juwei]]

Oh sorry I dismissed Marcos's needinfo... Keep flagging Marcos for more updates.

Comment 20

[Marcos Caceres [:marcosc]]

Attachment: UI_widget.png

Ok, the attached is not official in any way (it's something I slapped together)... but it shows the use cases for what we need: 

  1. an overlay/"sheet" that can load remote content.
  2. some way of showing the relationship between the two origins ("you are buying from ebay.com using paypal.com" or some such). 
  3. some way for the use to cancel out (not an option in my sketch)
  4. communication between the UI widget can only happen via a Service Worker. And the SW can only spawn one of these for the requesting tab. Current proposal is to bind this to an event, so:

    merchant.com -> paymentRequest.show(): send a message to the SW to open the widget if required.
 
    paymenthandler.com -> calls:
      var client = event.openSpecialUIWidgetSheetThing(); - and sheet is shown
   
    client.postMessage() passes messages back and forth. 

client cannot close itself via the API - only the user or the remote content can lose the window.

Hopefully that makes sense.

Comment 21

[Marcos Caceres [:marcosc]]

Just a note... everything inside that panel is "web content" - not generated by the browser (only the bounding box, and corresponding shadow, is generated by the browser).

Comment 22

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

(In reply to Jonathan Kingston [:jkt] from comment #17)
...
> :keeler I suspect the widget can work for client certs, I have however never
> seen them in action. Do you have any example urls?

StartSSL might still offer free client certificates that you can use to authenticate to their site: https://www.startssl.com/ (once you have an account and certificate, use "client certificate login")

Another option would be to set up a local web server, configure it to ask for client auth, and generate your own certificates like so: http://blog.nategood.com/client-side-certificate-authentication-in-ngi

Comment 23

[Marcos Caceres [:marcosc]]

This is slightly unrelated to the bug, but I thought I'd mention it. I showed Henri and William Cheng the UI mockup by Juwei Huang and they pointed out that her design solves a really important privacy problem: it doesn't require the browser to send the purchase items to the payment app 

Comment 24

[Axel Nennker]

w3c webauthn talks about user agent UI e.g. here:

https://w3c.github.io/webauthn/#makeCredential
	"The user agent will prompt the user to approve this operation."
and
	"During the above process, the user agent SHOULD show some UI to the user to guide them in the process of selecting and authorizing an authenticator."
Things to be shown in the UI could be taken from the Account parameter of the makeCredential call:
dictionary Account {
    required DOMString rpDisplayName;
    required DOMString displayName;
    required DOMString id;
    DOMString          name;
    DOMString          imageURL;
};

Also in https://w3c.github.io/webauthn/#op-make-cred 
	"Prompt the user for consent to create a new credential. The prompt for obtaining this consent is shown by the authenticator if it has its own output capability, or by the user agent otherwise."
Currently most authenticators (yubikeys) only have an LED to prompt the user. Firefox could/should guide the user through this flow, I think.

Also here regarding getAssertion: https://w3c.github.io/webauthn/#op-get-assertion
	"Prompt the user to select a credential from among the above list. Obtain user consent for using this credential. The prompt for obtaining this consent may be shown by the authenticator if it has its own output capability, or by the user agent otherwise."

I guess implementing the UI for webauthn is a bug in itself but that should be related to this bug.

Comment 25

[Amin Al Hazwani [:amin] (Firefox UX)]

(In reply to Axel Nennker from comment #24)
> I guess implementing the UI for webauthn is a bug in itself but that should
> be related to this bug.

We should rename this bug. It started from the "UI security widget" but it's just one scenario of the many that a Tab Modal can cover. Same thing for Web Authentication, as for the HTTP Authentication, is one of the many cases that this Tab Modal can support.

Comment 26

[Matthew N. [:MattN]]

(In reply to Axel Nennker from comment #24)
> I guess implementing the UI for webauthn is a bug in itself but that should
> be related to this bug.

That may be able to use a doorhanger. Not everything needs to use this new widget as that may make it too complex or lead to perfect being the enemy of the good.

Comment 27

[Amin Al Hazwani [:amin] (Firefox UX)]

(In reply to Matthew N. [:MattN] (PM if requests are blocking you) from comment #26)
> That may be able to use a doorhanger. Not everything needs to use this new
> widget as that may make it too complex or lead to perfect being the enemy of
> the good.

Just as a reminder, the threshold is the following: does the request need urgent user action? Does the request come directly from the tab? If yes, we can use the Tab Modal and block the access to the tab until the user has taken action. If no, we should use another component which is easily dismissalable like a doorhanger.

Comment 28

[Johann Hofmann [:johannh]]

Hope I'm not too late to the party but I have several concerns

> I'm listing an inventory of all cases that we could cover with this modal. Currently I have listed:

> - js alert/prompt messages

No. If I understand this correctly the widget will overlay with browser chrome UI, which is a no-go for content-based messages. It would be very easy for phishers to craft a real looking basic auth dialog. Those can not use the same dialog.

> - wifi warnings/VPN

What is that exactly? Captive portal? Doesn't sound like it should be "tab-modal".

> - add-on installation

That's not necessarily "tab-modal" and what's wrong with the doorhanger? We recently made it non-dismissable and we already have people complaining about that. If we make it more in-your-face, locking up the page, we have to consider prevention mechanisms like only showing it on user action. I guess that's something we might consider anyway.

> does the request need urgent user action? Does the request come directly from the tab?

This does not apply to the master password prompt which is one of the original use cases Jonathan proposed. Also the master password prompt doesn't mix well with anything that allows web content to have a say in how it's displayed.

> Just a note... everything inside that panel is "web content" - not generated by the browser (only the bounding box, and corresponding shadow, is generated by the browser).

What is stopping that widget from looking exactly like the master password prompt or a Firefox Sync Login dialog instead of asking for payment credentials then?

> It started from the "UI security widget" but it's just one scenario of the many that a Tab Modal can cover.

I hope I misunderstand this. I basically need someone to tell me that we're not about to create a chrome-overlaying widget that displays both content-generated messages and security-sensitive messages.

Comment 29

[Amin Al Hazwani [:amin] (Firefox UX)]

(In reply to Johann Hofmann [:johannh] from comment #28)
Thanks for your feedback! You raised very interesting points, especially regarding the distinction between web content and browser content. You can have a look at the inventory I am listing here https://docs.google.com/a/mozilla.com/document/d/1W4j4zWYeP9v2CmuwKAgQzA_2rE31mRC_1bmaaRzYqOI/edit?usp=sharing where I made some considerations, feel free to leave comments! I will then report to either Stephen or Philipp.

Comment 30

[Johann Hofmann [:johannh]]

Ah, cool that you collected those use-cases in a doc. I'll take a look. I guess my primary concern is still the mixing of content and browser (security) messages in the same widget, I don't see how that is going to happen TBH.

Comment 31

[Amin Al Hazwani [:amin] (Firefox UX)]

(In reply to Johann Hofmann [:johannh] from comment #30)
> Ah, cool that you collected those use-cases in a doc. I'll take a look. I
> guess my primary concern is still the mixing of content and browser
> (security) messages in the same widget, I don't see how that is going to
> happen TBH.

Yes, that was mine concern too. They asked me to design this Tab Modal and think about possible scenarios that could fall under this component. This is why I wanted to carefully examine case by case with this inventory. You raised a very good issue about browser vs web content. Now that you pointed out I also see no reason in mixing the two. I will report that and follow up with you.