WebAPI/WidgetAPI: Difference between revisions
< WebAPI
Jump to navigation
Jump to search
Luke-chang (talk | contribs) |
Luke-chang (talk | contribs) |
||
Line 79: | Line 79: | ||
==Experimental Note== | ==Experimental Note== | ||
* What will happen when a pure iframe (without mozbrowser/mozapp/remote) calls "window.top.location = window.location"? | * 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 | ** It works. The embedder window will be overwritten. | ||
* Can a pure iframe steal the permissions from its embedder? | * Can a pure iframe steal the permissions from its embedder? | ||
** No. Even the window.top is overwritten. | ** 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== | ==Bugs== |
Revision as of 05:59, 23 May 2014
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": { ... } } }
Restriction
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.