WebAPI/WidgetAPI

Goals

The widget API allows privileged APPs have ability to embed APPs in their own iframe, i.e. homescreen, lockscreen ....etc.

Proposal

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": { ... }
   }
 }

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 mozbrowser=“true" mozapp=“manifestURL" widget=“mywidget1” remote=“true”> 

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.

 <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.

Bugs

• bug 1005818 A new 'embed-widgets' permission exposing to privileged apps for solving widget case.
  • Part1: Add permission "embed-widgets" and HTMLIFrameElement attribute "mozWidget"
  • Part2: Implementation of checking if a window is able to embed a specific widget.
  • Part3: Enable to embed a widget if preconditions hold
  • Part4: Only limited browser API are available to a widget