(inactive after 6/18) Alive Kuo [:alive] Reporter
	Description • 11 years ago

Currently we're maintaining the app origin in trustedUI, Modal Dialog, Popup Manager, Attention Screen and all other app specific dialog (except for error dialog, it's moved into appWindow already).

We want to move trustedUI into AppWindow or BaseWindow class and after that we don't need to listen appwillopen/appopen/appwillclose/appclose event anymore.

And with this we could reuse anything has implemented in appWindow like appError.

	(inactive after 6/18) Alive Kuo [:alive] Reporter
	Comment 1 • 10 years ago

A nontrivial one, wanna to challenge?

* Implement TrustedWindow
* Use child_window_factory to open TrustedWindow
* Fix the transition problem when moving trustedWindow in AppWindow

	(Inactive after June) George Duan [:gduan] [:喬智] Assignee
	Comment 2 • 10 years ago

Take it.

	Rudy Lu [:rudyl] (inactive after 2015/7/3)
	Comment 4 • 10 years ago

[Blocking Requested - why for this release]:

Nominated this as 2.1+ as bug 1094550 has been marked as v2.1+.

	Rudy Lu [:rudyl] (inactive after 2015/7/3)
	Comment 5 • 10 years ago

Hi George,

As our discussion, if you're working on this, please be informed this would be needed for v2.1 blocker.
If not, please help share your WIP and maybe I can help follow up.

Thanks.

	Tim Guan-tin Chien [:timdream] (please needinfo)
	Comment 6 • 10 years ago

(In reply to Rudy Lu [:rudyl] from comment #4)
> [Blocking Requested - why for this release]:
> 
> Nominated this as 2.1+ as bug 1094550 has been marked as v2.1+.

I don't think it make sense to nominate refactor work as 2.1+ blocker. You need to consider the risk of introducing more blocker to v2.1 too.

Could we do a regression fix on bug 1094550 instead?

	Rudy Lu [:rudyl] (inactive after 2015/7/3)
	Comment 7 • 10 years ago

See bug 1094550 comment 21, sorry for overlooking the risk and workload that might come with this refactoring, will tackle bug 1094550 with a regression fix.

	(Inactive after June) George Duan [:gduan] [:喬智] Assignee
	Comment 8 • 10 years ago

Hi Alive,
could I have your feedback on this patch? I hope I'm on the right direction.

	(inactive after 6/18) Alive Kuo [:alive] Reporter
	Comment 9 • 10 years ago

Comment on attachment 8522247 [details] [review]
PR to master

Please move all specific elements into TrustedChrome and done event handling there. Minimize the specific code in TrustedWindow.

	(Inactive after June) George Duan [:gduan] [:喬智] Assignee
	Comment 10 • 10 years ago

Comment on attachment 8522247 [details] [review]
PR to master

Hi Alive,
could I have your feedback again? Thanks!

	(inactive after 6/18) Alive Kuo [:alive] Reporter
	Comment 11 • 10 years ago

Comment on attachment 8522247 [details] [review]
PR to master

nits in github

	(Inactive after June) George Duan [:gduan] [:喬智] Assignee
	Comment 12 • 10 years ago

Comment on attachment 8522247 [details] [review]
PR to master

Hi Alive,
could you review this patch? Thanks.

	(inactive after 6/18) Alive Kuo [:alive] Reporter
	Comment 13 • 10 years ago

Comment on attachment 8522247 [details] [review]
PR to master

Well done! especially for integration test. Pay attention to following regression bug if any. Thanks!

	(Inactive after June) George Duan [:gduan] [:喬智] Assignee
	Comment 14 • 9 years ago

master: https://github.com/mozilla-b2g/gaia/commit/7ac2a7f98b144f5f41a32d0b22b33ebe849317a9

	Fernando Jiménez Moreno [:ferjm]
	Comment 15 • 9 years ago

Thanks George and Alive! This is quite an excellent work. We were really hoping to get rid of the old Trusted UI for a long time [1][2] :)

However, as I mentioned on IRC, we missed some input from the security folks here :( We need to keep them in the loop for this kind of changes.

Let's forget about the old trusted UI and the homescreen overlay. I believe we all agree that that design wasn't good and it didn't really provided any real security for the user.

Looking at what we landed here, it seems that we are still not providing enough security for users :( We are opening a regular popup window loading the identity and payment flows where we only show the title of the embedded page and a padlock if it is an https content (which has to be at least for this two APIs cause the implementation enforces it). There is no way for the user to know the URL or the SSL verified information of the embedded content. IMHO we should show this. And as we discussed in IRC, we should do this for all cases, not only for the trusted UI special case. This information should always be available to the user, as it is in the desktop browser [3].

Now, how can we show this information in a way that cannot be (easily) spoofable?

As we said on IRC, one option is to always show this information in the rocketbar. But this is quite easy to mock with a fullscreen app. So IMHO that shouldn't be the solution.

What I think is a better place for this information is the task switcher. This UI can only be shown by holding the home button which triggers an event that 3rd party apps cannot capture and so cannot spoof. It also give us far more screen space than the rocketbar, so we can show more information (and probably with a better UI design).

What do you think?

[1] https://groups.google.com/forum/#!searchin/mozilla.dev.b2g/redesigning$20the$20trusted$20ui$20/mozilla.dev.b2g/aH4rDn3qEiQ/QWF-Nmv9VdQJ
[2] https://groups.google.com/forum/#!msg/mozilla.dev.b2g/t4Fd5r7MD3w/ZAU5sk1eREwJ
[3] https://support.mozilla.org/en-US/kb/how-do-i-tell-if-my-connection-is-secure

	Fernando Jiménez Moreno [:ferjm]
	Comment 16 • 9 years ago

This is how the trusted UI looks like after this patch. There is now way to check the URL, the padlock is not clickable and there is no additional information about the embedded content anywhere.

	Paul Theriault [:pauljt] (no longer reading bugmail)
	Comment 17 • 9 years ago

> What I think is a better place for this information is the task switcher.
> This UI can only be shown by holding the home button which triggers an event
> that 3rd party apps cannot capture and so cannot spoof. It also give us far
> more screen space than the rocketbar, so we can show more information (and
> probably with a better UI design).
> 
> What do you think?

That sounds good to me. Currently we actually already show the URL of hosted apps in the task switcher. 

But there are a couple challenges:
- the home button cancels the mozpay dialog. We'd need to catch for long press and I dont imagine that dialogs actually show up in the taskswitcher right now
- To be consistent, we need to show for the browser too. Which will mean some kind of API for the browser to be able to set the URL based on the whatever it is showing in the address bar. I don't know how the integrated system browser works but there is probably some way for the task manager in the system app to observe the browser app and figure out what page is being displayed? Not sure. 

Its not the most discoverable place but it sounds like a good start.