WebAPI/WidgetAPI

From MozillaWiki
Jump to navigation Jump to search

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.

Bugs