WebAPI/WidgetAPI
< WebAPI
Goals
The widget API allows privileged APPs have ability to embed APPs in their own iframe, i.e. homescreen, lockscreen ....etc.
Use case
Proposal
embed-widgets bug 1005818
In order to expose to privileged APPs and consider security issue.
- "embed-widgets" is a new permission for "mozapp" attribute, it comes from 'embed-apps' but is more restricted. Please refer to next section.
- Set manifest entry in "widget" attribute.
<iframe mozapp="manifesturl" widget="mywidget1">
extend manifest.webapp
Declare details of widget in mainfest.
{ name: "MyApp2000", ... widgets: { "mywidget1": { href: "widget.html" positions: ["homescreen", "lockscreen"] description: "This is my cool widget" }, "myotherwidget": { ... } } }
permission requirements
- embed-widgets
- homescreen-webapp-manage (bug 899994, bug 1000313)
- browser-api (combine with embed-widget would be downgrade )
Restriction
- Disallow SRC attribute.
- Disallow parts of security sensitive browser API
- Ignore mozLockOrientation/mozUnlockOrientation
examples
- APP:
<iframe mozbrowser=“true" mozapp=“manifestURL” remote=“true” src=“appURL”>
- Widget:
- Disallow “src" attribute.
//Q: Can we set remote is true by default? <iframe mozbrowser=“true" mozapp=“manifestURL" widget=“widgetEntry” remote=“true”>
- Open Bookmark:
//browser (full-set) <iframe mozbrowser src="" remote="true">
Issues under discussion
Browser API
Need to clarify which methods/Events are safe or unsafe.
Not security sensitive
- Performance methods
- setVisible()
- getVisible()
- Event methods
- addNextPaintListener()
- removeNextPaintListener()
- Events
- mozbrowserasyncscroll
- mozbrowserclose
- mozbrowsererror
- mozbrowserloadend
- mozbrowserloadstart
Security sensitive
- Event methods
- sendMouseEvent() - cross-origin interaction, can cause unexpected actions in web apps
- sendTouchEvent() - cross-origin interaction, can cause unexpected actions in web apps
- getScreenshot()
- Events
- mozbrowserusernameandpasswordrequired - leaks host and realm
- mozbrowseropenwindow (i.e. window.open)
- mozbrowsershowmodalprompt (i.e. alert(), confirm(), prompt())
- mozbrowsercontextmenu
- mozbrowsersecuritychange - can tell is page is https or not
- mozbrowserlocationchange - discloses URL (can contain secrets)
- mozbrowsericonchange - discloses the icon URL. Might be a privacy issue.
- mozbrowsertitlechange - discloses title, privacy issue.
- mozbrowseropensearch - I assume this discloses the link value, maybe a privacy issue?
no use case
- Navigation methods
reload()stop()getCanGoBack()goBack()getCanGoForward()goForward()
- Performance methods
purgeHistory()
Experimental Note
- What will happen when a pure iframe (without mozbrowser/mozapp/remote) calls "window.top.location = window.location" within an app?
- It works. The embedder window will be overwritten.
- Can a pure iframe steal the permissions from its embedder?
- No. Even the window.top is overwritten.
- What will happen when an iframe has mozapp but doesn't have mozbrowser?
- "remote=true" malfunction. So, no permission can be obtained.
- Does the visibility state of an OOP'ed iframe correspond to its parent?
- Yes.