"Safer" Browser API and "embed-widget"

[Gary Chen]

Hi all,
I'd like to follow up our previous discussion about "embed-widget" permission and "safer" browser API.
We all agreed browser API should be limited to a "safer" set when it's used in widget cases due to a few security concerns.
So my question is - Should we automatically downgrade browser API to this smaller set when:

a) The app also declare "embed-widget" permission
The app can only use the safer browser API to control all it's embeded iframe no matter the iframe is loading a widget or not.

b) A mozbrowser iframe contains a "widget” attribute.
If a mozbrowser iframe without widget attribute, it can have the full set functions.
For “bookmark case", the iframe looks like: <iframe mozbrowser="true” src=“http://example.com” remote=“true”>
It means the APP has ability to embed “widget” iframe and also embed external website, and these two kinds of mozbrowser iframes have different function sets.

c) Or we are going to invent a new "min-browser" API? (just a temporary name, we can refine the name afterward.)
Affirmative:
More clearly to let developers know what’s different between “browser API”and “min-browser API”.
Imagine that if we don’t invent “min-browser API”, “Browser API” will be downgrade to safer set automatically when it combine with “embed-widget”.
In this situation, developer would not know why some of browser APIs break if they did not realize whole story or read document on MDN.
Negative:
As a developer, if i realized “browser API” has more powerful APIs than “min-browser”, there is no reason to use “min-browser”.
Another strong reason is, each dom element support different "attributes".
Such as <video>, <img>, <audio> ...etc support "src", but <div>, <span> don't support it.
Just like once iframe contains a "widget” attribute and it would be disallowed some of "browser" API.

Any suggestions are welcome, thanks.


Best regards
-------------------------------------
Gary Chen 陳柏宇
Mozilla Taiwan

T: +886-2-87861100 # 206
M: +886-975151712
gc...@mozilla.com

[Kan-Ru Chen (陳侃如)]

I think we should have a permission "browser-embed-widget" that grant
you the permission to use the mozbrowser attribute and widget attribute
together. Then the app need not to request the "browser" permission.

When the embeder app combines these two attributes together then it
could use the browser API limited to widget mode.

This would allow the app to request "browser" permission separately if
it wants to implement a browser. I think it is clearer that app only
requests "browser" permission when it actually wants to implement a
browser.

Kanru

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi

--
Kanru

[Gary Chen]

Hi Kanru,
Nice suggestion, "browser-embed-widget" sounds more convenient for developer.

Base on this suggestion , if developer want to let the APP has ability to embed widget, just only need to declare "browser-embed-widget" in manifest.
Then it has permission to use "widget" attribute and mozbrowser attribute with safer set.

The other case is the APP wants to embed external website, it should requests "browser" permission, just like browser APP.

Once APP wants to embed "widget" and "external website", "browser-embed-widget" and "browser" permission are required.

Here are my understanding, please kindly let me know if I misapprehend anything.

Best regards
-------------------------------------
Gary Chen 陳柏宇
Mozilla Taiwan

T: +886-2-87861100 # 206
M: +886-975151712
gc...@mozilla.com

[Jonas Sicking]

On Sun, Jun 8, 2014 at 8:03 AM, Kan-Ru Chen (陳侃如) <kc...@mozilla.com> wrote:
> I think we should have a permission "browser-embed-widget" that grant
> you the permission to use the mozbrowser attribute and widget attribute
> together. Then the app need not to request the "browser" permission.
>
> When the embeder app combines these two attributes together then it
> could use the browser API limited to widget mode.
>
> This would allow the app to request "browser" permission separately if
> it wants to implement a browser. I think it is clearer that app only
> requests "browser" permission when it actually wants to implement a
> browser.

This is exactly right!

We should treat <iframe mozbrowser mozwidget> as a new feature.

This feature will always have the reduced browser API.

In order to be allowed to use <iframe mozbrowser mozwidget> the
application needs to have the "embed-widgets" permission.

However none of this affects other APIs. I.e. if an application also
has the "browser" permission it can use a <iframe mozbrowser> which
will behave just like it does today. I.e. it will have the full
browser API, but it will never be able to render other apps.

At some point I think we should reside all of these elements so that
instead of <iframe mozbrowser>, <iframe mozbrowser mozapp> and <iframe
mozbrowser mozwidget> we should have <mozbrowser>, <mozapp> and
<mozwidget>.

That should make it more clear that those are three separate
independent APIs. It will alos have some implementation and probably
performance benefits.

/ Jonas

[JOSE MANUEL CANTERA FONSECA]

________________________________________
De: dev-webapi [dev-webapi-bounces+jmcf=tid...@lists.mozilla.org] en nombre de Jonas Sicking [jo...@sicking.cc]
Enviado: lunes, 09 de junio de 2014 18:09
Para: Kan-Ru Chen (陳侃如)
CC: dev-webapi; Paul Theriault; Evelyn Hung; Gary Chen
Asunto: Re: "Safer" Browser API and "embed-widget"

On Sun, Jun 8, 2014 at 8:03 AM, Kan-Ru Chen (陳侃如) <kc...@mozilla.com> wrote:
> I think we should have a permission "browser-embed-widget" that grant
> you the permission to use the mozbrowser attribute and widget attribute
> together. Then the app need not to request the "browser" permission.
>
> When the embeder app combines these two attributes together then it
> could use the browser API limited to widget mode.
>
> This would allow the app to request "browser" permission separately if
> it wants to implement a browser. I think it is clearer that app only
> requests "browser" permission when it actually wants to implement a
> browser.

> This is exactly right!

Could we have something more structured for this permission, instead of relying on string concatenation. What about

"embed": {
"apps": true,
"browser": true
}

And all possible combinations

I disagree with the term 'widget'. I would prefer to name 'app'. The reason is that this new functionality will allow an app to embed other apps, being those apps widgets or full apps. For instance, we plan to use that functionality to embed the Contacts App in the Dialer app, so getting rid of the 'entry points' hack.

> We should treat <iframe mozbrowser mozwidget> as a new feature.

Same here, I would prefer not to use the term 'widget' but the term 'app' in general.

> At some point I think we should reside all of these elements so that
> instead of <iframe mozbrowser>, <iframe mozbrowser mozapp> and <iframe
> mozbrowser mozwidget> we should have <mozbrowser>, <mozapp> and
> <mozwidget>.

<mozapp> I would prefer

/ Jonas

_______________________________________________
dev-webapi mailing list
dev-w...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapi

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

[Ben Francis]

On Mon, Jun 9, 2014 at 5:09 PM, Jonas Sicking <jo...@sicking.cc> wrote:

> At some point I think we should reside all of these elements so that
> instead of <iframe mozbrowser>, <iframe mozbrowser mozapp> and <iframe
> mozbrowser mozwidget> we should have <mozbrowser>, <mozapp> and
> <mozwidget>.
>

> That should make it more clear that those are three separate
> independent APIs. It will alos have some implementation and probably
> performance benefits.
>

If we're going to start renaming things, I'd strongly encourage converging
with Chromium/Chrome/Blink with the use of the "<webview>" naming [1]. They
were originally going with "<browser>" because we said that's what we were
going to rename <iframe mozbrowser>, but when we took no action they went
with "<webview>" instead.

I have started to draft a proposal for a standardised <webview> element and
associated API on GitHub [2] after an initial evaluation of Gecko's Browser
API and Blink's Webview API. Feedback is welcome.

In thinking about how this specification could interact with the W3C
"Manifest for web application" specification [3] I have proposed a
"manifest" attribute to the "<webview>" element whose value would be the
URL of a web app manifest, much like the mozapp attribute we have today.
This attribute would restrict a particular <webview> to the scope of the
app described in the app manifest.

In order to propose a separate <widget> element for standardisation in
future I think we'd need to have a good argument as to why the use cases
are sufficiently different to <webview>, but I don't see any harm in
experimenting with a <mozwidget> element to explore that space further.

1. https://developer.chrome.com/apps/tags/webview
2. http://benfrancis.github.io/webview/
3. http://w3c.github.io/manifest/

[Jonas Sicking]

On Tue, Jun 10, 2014 at 12:58 AM, JOSE MANUEL CANTERA FONSECA
<jm...@tid.es> wrote:
> Could we have something more structured for this permission, instead of relying on string concatenation. What about
>
> "embed": {
> "apps": true,
> "browser": true
> }
>
> And all possible combinations

We played around with stuff like this for audio channels at one point.
In the end we ended up reverting it because it was too much trouble.
One of the problems is other metadata that exists per-permission, like
the description.

When it comes to security, it's better to be slightly verbose but keep
things simple. There's lot of value in making processing of each
permission be exactly the same.

> I disagree with the term 'widget'. I would prefer to name 'app'. The reason is that this new functionality will allow an app to embed other apps, being those apps widgets or full apps. For instance, we plan to use that functionality to embed the Contacts App in the Dialer app, so getting rid of the 'entry points' hack.

We're intentionally not allowing embedding arbitrary apps. Or even
embedding of arbitrary pages of apps that do have widgets.

The mozwidget feature will only able to open pages that are explicitly
labeled as widgets.

>> We should treat <iframe mozbrowser mozwidget> as a new feature.
>
> Same here, I would prefer not to use the term 'widget' but the term 'app' in general.

The problem with this is that it would enable the homescreen to launch
clickjacking attacks against the dialer and other apps.

/ Jonas

[Ben Francis]

Can you list the parts of the Browser API which you think should and
shouldn't be available to an app which embeds widgets?


Depending on the answer to that question I may have an alternative
proposal...

1. Requesting only the "embed-webapps" permission allows you to do:

<iframe mozapp="http://foo.com/manifest.webapp">

...which gives you a reduced browser API and restricts the iframe to the
scope of the app defined by the manifest URL in the mozapp attribute. This
allows you to safely embed an app as a widget.

2. Requesting the "browser" permission allows you to do:

<iframe mozbrowser>

... which gives you full access to the browser API and the frame can
navigate to any URL.

3. Requesting both embed-webapps and browser allows you to do:

<iframe mozbrowser mozapp="http://foo.com/manifest.webapp">

... which gives you full access to the browser API and restricts the iframe
to the scope of the app defined by the manifest URL in the mozapp attribute.


I understand that one of the requirements is that an app can control
whether or not it can be embedded in another app. Note that the web already
has a solution to this problem in the form of the X-Frame-Options HTTP
response header [1] which an app can use to ask not to be rendered inside
an iframe. We ignore these headers when the mozbrowser attribute is set on
an iframe to allow the embedder to act as a browser. But in example 1
above, an app could use this header to ask not to allow itself to be
embedded as a widget in an iframe without the mozbrowser attribute.


In the future one possibility is that all of this could become:

<iframe manifest=""> for embedding apps as widgets with a reduced API
<webview manifest=""> for embedding apps with the full API
<webview> for building a browser


1. https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options

[JOSE MANUEL CANTERA FONSECA]

________________________________________
De: Jonas Sicking [jo...@sicking.cc]
Enviado: martes, 10 de junio de 2014 14:54
Para: JOSE MANUEL CANTERA FONSECA
CC: Kan-Ru Chen (陳侃如); dev-webapi; Paul Theriault; Evelyn Hung; Gary Chen

Asunto: Re: "Safer" Browser API and "embed-widget"

On Tue, Jun 10, 2014 at 12:58 AM, JOSE MANUEL CANTERA FONSECA
<jm...@tid.es> wrote:
> Could we have something more structured for this permission, instead of relying on string concatenation. What about
>
> "embed": {
> "apps": true,
> "browser": true
> }
>
> And all possible combinations

> We played around with stuff like this for audio channels at one point.
> In the end we ended up reverting it because it was too much trouble.
> One of the problems is other metadata that exists per-permission, like
the description.

> When it comes to security, it's better to be slightly verbose but keep
> things simple. There's lot of value in making processing of each
> permission be exactly the same.

I see

>> I disagree with the term 'widget'. I would prefer to name 'app'. The reason is that this new functionality will allow an app to embed other apps, being those apps widgets or full apps. For instance, we plan to use that functionality to embed the Contacts App in the Dialer app, so getting rid of the 'entry points' hack.

> We're intentionally not allowing embedding arbitrary apps. Or even
> embedding of arbitrary pages of apps that do have widgets.

> The mozwidget feature will only able to open pages that are explicitly
> labeled as widgets.

I disagree, We should allow to embed apps in other apps at least for certified content. The main use case we have right now is Dialer and Contacts

> We should treat <iframe mozbrowser mozwidget> as a new feature.
>
>> Same here, I would prefer not to use the term 'widget' but the term 'app' in general.

> The problem with this is that it would enable the homescreen to launch
> clickjacking attacks against the dialer and other apps.

This can be avoided, if, as Ben pointed out in another email, the permission request in the manifest includes the origin of the app that is intended to be embedded and we don't allow to embed any other app apart from that

[JOSE MANUEL CANTERA FONSECA]

________________________________________
De: dev-webapi [dev-webapi-bounces+jmcf=tid...@lists.mozilla.org] en nombre de Ben Francis [bfra...@mozilla.com]
Enviado: martes, 10 de junio de 2014 14:55
Para: Jonas Sicking
CC: Gary Chen; dev-webapi; Paul Theriault; Evelyn Hung

Asunto: Re: "Safer" Browser API and "embed-widget"

Can you list the parts of the Browser API which you think should and
shouldn't be available to an app which embeds widgets?


Depending on the answer to that question I may have an alternative
proposal...

> 1. Requesting only the "embed-webapps" permission allows you to do:

> <iframe mozapp="http://foo.com/manifest.webapp">

> ...which gives you a reduced browser API and restricts the iframe to the
> scope of the app defined by the manifest URL in the mozapp attribute. This
> allows you to safely embed an app as a widget.

On the manifest of the embedding app it should be declared what app/s intends to embed, right?

> 2. Requesting the "browser" permission allows you to do:

> <iframe mozbrowser>

> ... which gives you full access to the browser API and the frame can
> navigate to any URL.

Does this mean I can also navigate to app://xx.gaiamobile.org URLs ?

> 3. Requesting both embed-webapps and browser allows you to do:

> <iframe mozbrowser mozapp="http://foo.com/manifest.webapp">

> ... which gives you full access to the browser API and restricts the iframe
> to the scope of the app defined by the manifest URL in the mozapp attribute.

What use case do you envisage for this option?

> ...

> In the future one possibility is that all of this could become:

> <iframe manifest=""> for embedding apps as widgets with a reduced API
> <webview manifest=""> for embedding apps with the full API
> <webview> for building a browser

How would deal a developer with OAuth flows in this proposal? Currently We have a 'redirects' property (see communications app in Gaia for instance) in the app manifest for certified content. It would be nice to come up with a proposal that allows to use that approach to other types of content and enabling playing safe OAuth flows. It might be a Webview that can only navigate to certain URLs and that could be closed once there is a redirection to the callback URL.

_______________________________________________
dev-webapi mailing list
dev-w...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapi

[Jonas Sicking]

On Tue, Jun 10, 2014 at 3:55 PM, Ben Francis <bfra...@mozilla.com> wrote:
> Can you list the parts of the Browser API which you think should and
> shouldn't be available to an app which embeds widgets?

I would say start with exposing the 'mozbrowserloadstart' and
'mozbrowserloadend' events and nothing else. I'm curious what else the
homescreen needs in order to render widgets.

> Depending on the answer to that question I may have an alternative
> proposal...
>
> 1. Requesting only the "embed-webapps" permission allows you to do:
>
> <iframe mozapp="http://foo.com/manifest.webapp">
>
> ...which gives you a reduced browser API and restricts the iframe to the
> scope of the app defined by the manifest URL in the mozapp attribute. This
> allows you to safely embed an app as a widget.

I don't want to expose this capability to 3rd party apps, as it allows
the 3rd party app to launch clickjacking attacks against the embedded
app.

> 2. Requesting the "browser" permission allows you to do:
>
> <iframe mozbrowser>
>
> ... which gives you full access to the browser API and the frame can
> navigate to any URL.

This will not use the right cookie jar for the embedded page. And if
it did, it would allow launching clickjacking attacks against the
embedded page.

> 3. Requesting both embed-webapps and browser allows you to do:
>
> <iframe mozbrowser mozapp="http://foo.com/manifest.webapp">
>
> ... which gives you full access to the browser API and restricts the iframe
> to the scope of the app defined by the manifest URL in the mozapp attribute.
>
>

> I understand that one of the requirements is that an app can control whether
> or not it can be embedded in another app. Note that the web already has a
> solution to this problem in the form of the X-Frame-Options HTTP response
> header [1] which an app can use to ask not to be rendered inside an iframe.
> We ignore these headers when the mozbrowser attribute is set on an iframe to
> allow the embedder to act as a browser. But in example 1 above, an app could
> use this header to ask not to allow itself to be embedded as a widget in an
> iframe without the mozbrowser attribute.

How would a page protect itself from being iframed by random untrusted
content, while still allowing itself to be opened by a trusted party
such as the browser app or the homescreen?

/ Jonas

[Jonas Sicking]

On Tue, Jun 10, 2014 at 6:13 PM, JOSE MANUEL CANTERA FONSECA
<jm...@tid.es> wrote:
> I disagree, We should allow to embed apps in other apps at least for certified content. The main use case we have right now is Dialer and Contacts

We can certainly look at that. But I think that's a very different
conversation from this thread. The use case that we're starting with
here is wanting to enable 3rd party home screens to embed widgets.

/ Jonas

[JOSE MANUEL CANTERA FONSECA]

________________________________________
De: Jonas Sicking [jo...@sicking.cc]

Enviado: miércoles, 11 de junio de 2014 0:12

Para: JOSE MANUEL CANTERA FONSECA

CC: Kan-Ru Chen (陳侃如); dev-webapi; Paul Theriault; Evelyn Hung; Gary Chen

Asunto: Re: "Safer" Browser API and "embed-widget"

I have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1023737 in order to continue the discussion there

/ Jonas

[Ben Francis]

On Tue, Jun 10, 2014 at 4:27 PM, JOSE MANUEL CANTERA FONSECA <jm...@tid.es>
wrote:

>

> > 1. Requesting only the "embed-webapps" permission allows you to do:
>
> > <iframe mozapp="http://foo.com/manifest.webapp">
>
> > ...which gives you a reduced browser API and restricts the iframe to the
> > scope of the app defined by the manifest URL in the mozapp attribute.
> This
> > allows you to safely embed an app as a widget.
>

> On the manifest of the embedding app it should be declared what app/s
> intends to embed, right?
>

I didn't intend that, but you could do that yes.

> > 2. Requesting the "browser" permission allows you to do:
>
> > <iframe mozbrowser>
>
> > ... which gives you full access to the browser API and the frame can
> > navigate to any URL.
>

> Does this mean I can also navigate to app://xx.gaiamobile.org URLs ?
>

No, just web (HTTP) URLs as it is today .

> > 3. Requesting both embed-webapps and browser allows you to do:
>
> > <iframe mozbrowser mozapp="http://foo.com/manifest.webapp">
>
> > ... which gives you full access to the browser API and restricts the
> iframe
> > to the scope of the app defined by the manifest URL in the mozapp
> attribute.
>

> What use case do you envisage for this option?
>

The Gaia window manager!

How would deal a developer with OAuth flows in this proposal? Currently We
> have a 'redirects' property (see communications app in Gaia for instance)
> in the app manifest for certified content. It would be nice to come up with
> a proposal that allows to use that approach to other types of content and
> enabling playing safe OAuth flows. It might be a Webview that can only
> navigate to certain URLs and that could be closed once there is a
> redirection to the callback URL.
>

That's probably part of the separate "app scope" discussion, there are a
couple of proposals of how to solve that use case. I filed bug 1023803 to
discuss that.

[Ben Francis]

On Tue, Jun 10, 2014 at 11:10 PM, Jonas Sicking <jo...@sicking.cc> wrote:

I would say start with exposing the 'mozbrowserloadstart' and
> 'mozbrowserloadend' events and nothing else.
>

So could we just fire those events on iframes which specify the mozapp
attribute, even if the mozbrowser attribute isn't specified?

>
> > 1. Requesting only the "embed-webapps" permission allows you to do:
> >
> > <iframe mozapp="http://foo.com/manifest.webapp">
> >
> > ...which gives you a reduced browser API and restricts the iframe to the
> > scope of the app defined by the manifest URL in the mozapp attribute.
> This
> > allows you to safely embed an app as a widget.
>

> I don't want to expose this capability to 3rd party apps, as it allows
> the 3rd party app to launch clickjacking attacks against the embedded
> app.
>

It seems you do want to allow third party apps to embed other apps, but in
a more controlled way.

The web in general has the same risk of clickjacking attacks and web pages
have a an "opt-out of being embedded" mechanism with "X-Frame-Options
DENY". It sounds like what you're saying is that for privileged apps the
default should be the equivalent of "X-Frame-Options DENY" and pages of
apps should be able to opt-in to being embedded with the equivalent of
"X-Frame-Options ALLOW-FROM <url>"?

> > 2. Requesting the "browser" permission allows you to do:
> >
> > <iframe mozbrowser>
> >
> > ... which gives you full access to the browser API and the frame can
> > navigate to any URL.
>

> This will not use the right cookie jar for the embedded page. And if
> it did, it would allow launching clickjacking attacks against the
> embedded page.
>

I'm not proposing any changes here, this would still be used for the use
cases it is used for today (i.e. building a browser).

>
> > 3. Requesting both embed-webapps and browser allows you to do:
> >
> > <iframe mozbrowser mozapp="http://foo.com/manifest.webapp">
> >
> > ... which gives you full access to the browser API and restricts the
> iframe
> > to the scope of the app defined by the manifest URL in the mozapp
> attribute.
> >
> >

> > I understand that one of the requirements is that an app can control
> whether
> > or not it can be embedded in another app. Note that the web already has a
> > solution to this problem in the form of the X-Frame-Options HTTP response
> > header [1] which an app can use to ask not to be rendered inside an
> iframe.
> > We ignore these headers when the mozbrowser attribute is set on an
> iframe to
> > allow the embedder to act as a browser. But in example 1 above, an app
> could
> > use this header to ask not to allow itself to be embedded as a widget in
> an
> > iframe without the mozbrowser attribute.
>
> How would a page protect itself from being iframed by random untrusted
> content, while still allowing itself to be opened by a trusted party
> such as the browser app or the homescreen?
>

The browser app can frame any content because the mozbrowser attribute
means it ignores X-Frame-Options headers.

Gecko supports an "ALLOW-FROM <uri>" value for the X-Frame-Options header
so that you can specify trusted embedder apps like homescreen.gaiamobile.org.
The one thing this doesn't support is allowing a page to be embedded in a
particular "class" of app, like 'positions: ["homescreen", "lockscreen"]'
in your original proposal. Maybe that is something we need. That does seem
to be quite specific to a particular UX though and I do wonder how easy
that might be to standardise in future?

I'm still not convinced that embedding "widgets" is any different to
embedding "apps" in general or that "widgets" are even a new class of thing
that we need. But I am happy to be convinced otherwise.

As far as I can tell this all seems to already exist on the web. It may be
that we need to hack some more HTTP-like semantics into the app:// protocol
to make it work for packaged apps though.