phishing capability and presentation of separate browsing context

[npdoty]

It seems like one advantage to this kind of proposal is that a separate modal dialog can open up from a totally different origin (like a single-sign on authentication provider, or a financial services provider) and then the user can enter sensitive, origin-specific information into that modal (like her password or credit card number) without the sensitive information being shared with the original site. A worthy goal!

Do we have plausible mock-ups of the UX for representing to the user what is/isn't a modal and what origin is presenting it? I'm concerned that if the modal is typically presented within the window of the original site that a site could fake it: show a non-modal dialog (complete with blurring out the rest of the window) that purports to be a modal dialog from the authentication provider, where the user feels comfortable typing in their password, but it's actually the host site that gets it. That would make phishing a lot easier, and defeat the (insufficient, but extant) mitigation we have today of asking users to check the origin in the URL bar before entering their password.

That is, if we're creating a new form of native UI, do we have mitigations to prevent sites from mimicking that UI within a tab? How will a user have confidence about which origin they are interacting with and providing sensitive data to?

[rsolomakhin]

We're thinking of using the same UI paradigms as payment handlers, which try to reduce fake UI possibility by overlapping the browser address bar. See a demo at https://rsolomakhin.github.io/pr/apps/password/ for example.

[npdoty]

Thanks for the example. It looks to me like the difference between your example and a phishing site is an overlap of a couple of pixels into the browser chrome. If the drop-shadowed box is a couple of pixels lower down, then the user needs to notice the (subtle) difference and conclude that they may be being phished.

It could be really valuable to get some user research studies of this kind of problem to inform the requirements we would have in standardizing a new method of showing content from different origins. From a first glance, I feel like I would seriously struggle to explain to any of my friends or family why they need to carefully observe the exact position of the drop-shadowed box that pops up for entering authentication or financial information.

The pop-up does include text of origin of the embedded/modal site, but in a different place and format than the still visible address bar origin of the hosting site, so even in the non-phishing case, it seems hard to explain to a user how to determine what site is receiving the data they're entering.

[adrianhopebailie]

This came up here too:
w3ctag/design-reviews#427 (comment)

In the explainer we say that we require :

the ability to position this browsing context at least relative to the top or bottom of the container window, and perhaps have the ability to visually expand/contract the context (or let the user expand it) - and the ability to go fullscreen. The browsing context (not the opener) controls the dimensions.

I think this is causing confusion around who controls the size and position of the modal window.

Specifically, this is the critical phrase that seems to be missed:

The browsing context (not the opener) controls the dimensions.

Could we re-write the above to be:

the ability for the UA to position the new browsing context at least relative to the top or bottom of the container window, and perhaps have the ability to visually expand/contract the context (or let the user expand it) - and the ability to go fullscreen. The UA (not the opener) controls the dimensions and position.

@rsolomakhin @marcoscaceres WDYT?

[rsolomakhin]

@adrianhopebailie : Your proposed text looks good to me. Also let's add a caveat that the positioning feature is secondary to spoof protection, i.e., the UA should make it clear to the user that the origin is painted by the UA and not by content.

[npdoty]

To be clear, one phishing danger here isn't the use of the proposed API, but rather that if it becomes common to use a modal dialog to gather sensitive info like passwords or financial information (for the single-sign on or financial provider use cases), users will be trained to enter that info into a dialog box assuming that the dialog is a communication directly with their account or financial provider, but a malicious or semi-malicious site could mimic the dialog within the site's tab contents and convince users to enter their passwords into a different origin.

[marcoscaceres]

What @npdoty says is also the concern we voice about payment handler in our standards position. I'm still not sure how we mitigate this even with the new proposal. We did conduct a fair few user studies into the "Basic Card" payment handler UI, and users found it jarring and confusing, which is also part of the reason we ditched it. I'll see if we can release that research.

Although we never released Basic Card in Firefox, we had considered making the actual URL bar morph into the payment handler - so only one URL would be shown, and it would sprout directly from the URL bar, making it really hard to spoof. We never user-tested that, however. We also are trying to avoid showing web content in a privileged UI space (above those magical pixels).

One solution here might be that only pre-installed web applications are allowed to use this feature. That way, a user grants this capability to the web application, and then only those web applications can show up in this privileged UI space.

[adrianhopebailie]

To be clear, this is no different to SSO login pop-ups today, no?

Users are so used to clicking "Login with Google" or "Login with Facebook" and getting a popup that if they did and it was a faked pop-up they'd almost certainly not notice.

I think this API is an opportunity to create UI that is better and an API that is less generic and more context aware.

I don't think we can be too prescriptive about UI but that's oaky because we know browsers will do their best to help users we just need to make that easier for them by ensuring the API design supports this goal.

For example, we can create an API that is specifically intended to be used for only these high-trust cross-origin use cases so that when it is invoked browsers can design UI specifically for that context and train users that when they see that UI it means "Take Care!".

It also means browsers know that the context created by invoking this API is supposed to be high-trust so they can take additional measures to protect users.

One solution here might be that only pre-installed web applications are allowed to use this feature. That way, a user grants this capability to the web application, and then only those web applications can show up in this privileged UI space.

I like the sound of this but not sure exactly what a "pre-installed web application" is? Does the user need to visit a site with an app manifest and explicitly install it?

Is there a risk that this starts to imply additional "permissions" are being granted to installed apps?

A compromise might be a warning from the browser if the user invokes a modal and the app rendered in the modal is not pre-installed.

Also worth considering is @agektmr 's suggestion that we lock this down to specific contexts (invocation of Payment Handlers, Credentials API, Share API) which leaves it to these APIs to define how an an origin becomes an "approved" candidate to be rendered in the modal (see #2).

Personally I think the modal nature of the window is sufficient if the UI is carefully designed but we should do some experiments to prove/disprove this theory.