Expose 'embed-apps' to privilege.

[Gary Chen]

Hi all,
We are going to allow 3rd-party APPs open and embed widget in their own APPs.
Such as homescreen, lockscreen APP …..etc.
As far as I know widget is not much different between APP, just only has different size.

So 3rd-party APPs need to have ability to embed "OPEN WEB APPs” in mozAPP frames,
according to MDN [1] and [2] APPs must have 'embed-apps’ permission.

Is there any concern to expose 'embed-apps' to privilege?
I want to bring this topic to WebAPI meeting this week, any comments and discussions are welcome.

[1] https://developer.mozilla.org/en-US/Apps/Build/App_permissions#embed-apps
[2] https://developer.mozilla.org/en-US/docs/WebAPI/Browser#Permissions

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

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

[Vivien Nicolas]

Opening embed-apps to privileged app authors has been discussed a bit,
and my understanding is that it needs to be a lighter version of
embed-apps (as it will expose security issues otherwise).

Not sure there is a bug for that yet. If you open it can you make it
blocks bug 980929 ?

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

[Gary Chen]

I've just filed a bug 1005818 and block bug 980929.
Welcome to comments and discussions on this bug.

Thanks.

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

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

----- Original Message -----

[Evelyn Hung]

Regarding security concern here, we've discussed one case: an app is able to embed another app that occupied its full window size.
Not sure if this is dangerous, but when both apps are running in different sandbox (OOPed), it seems won't hurt each other or cause data leaking or permission checking hole. 'The user will be fooled' is the only bad thing I can think of...


Evelyn

[Paul Theriault]

We discussed this when I was in taipei last time, but I am not sure where we got to. Is there a UX spec or similar for exactly the use case you are trying to solve?
There are actually a number of issues here, and I think Vivien’s suggestion of creating a new API is probably the way to go.

Embedding apps requires at least three permissions: webapps-manage (to allow linking to app://), browser (apps have to be mozbrowser frames) & embed-apps (to make the mozapp attribute work). An app with all three of these can effectively bypass same-origin policy, and access data of the embedded app though. (it doesn’t have full scripting access, but can do things like take screenshots and listen for navigator events). So as it currently stands these APIs are probably too dangerous to give to 3rd party apps.

On 5 May 2014, at 7:36 pm, Evelyn Hung <eh...@mozilla.com> wrote:

> Regarding security concern here, we've discussed one case: an app is able to embed another app that occupied its full window size.
> Not sure if this is dangerous, but when both apps are running in different sandbox (OOPed), it seems won't hurt each other or cause data leaking or permission checking hole. 'The user will be fooled' is the only bad thing I can think of...

Something we have been talking about for Haida is the ability to link to apps - is that basically what you are asking for here?

[Fabrice Desré]

On 05/05/2014 02:46 AM, Paul Theriault wrote:
> We discussed this when I was in taipei last time, but I am not sure where we got to. Is there a UX spec or similar for exactly the use case you are trying to solve?
> There are actually a number of issues here, and I think Vivien’s suggestion of creating a new API is probably the way to go.
>
> Embedding apps requires at least three permissions: webapps-manage (to allow linking to app://), browser (apps have to be mozbrowser frames) & embed-apps (to make the mozapp attribute work). An app with all three of these can effectively bypass same-origin policy, and access data of the embedded app though. (it doesn’t have full scripting access, but can do things like take screenshots and listen for navigator events). So as it currently stands these APIs are probably too dangerous to give to 3rd party apps.

linking to app:// is only useful for homescreens and the settings app to
show other app's icons. I think we don't need that to embed widgets. I
agree with the need for the other two, but I think we should just grant
the browser permission to apps that have the embed-apps one.

Fabrice
--
Fabrice Desré
b2g team
Mozilla Corporation

[Evelyn Hung]

Hi Paul,

Taking screenshots and listening navigator events can be done by requiring browser api which is already a privileged api. I agree we should be careful on exposing webapps-manage since it opens app protocol, I know there is already a bug 899994 having a lot discussion. For embed-apps, I'm not sure how it can be a "lighter" version since it only allows one thing - make mozapp attribute work. Can you explain more? :)

Thanks,

Evelyn


----- Original Message -----

> We discussed this when I was in taipei last time, but I am not sure where we
> got to. Is there a UX spec or similar for exactly the use case you are
> trying to solve?
> There are actually a number of issues here, and I think Vivien’s suggestion
> of creating a new API is probably the way to go.
>
> Embedding apps requires at least three permissions: webapps-manage (to allow
> linking to app://), browser (apps have to be mozbrowser frames) & embed-apps
> (to make the mozapp attribute work). An app with all three of these can
> effectively bypass same-origin policy, and access data of the embedded app
> though. (it doesn’t have full scripting access, but can do things like take
> screenshots and listen for navigator events). So as it currently stands
> these APIs are probably too dangerous to give to 3rd party apps.
>
>

[Vivien Nicolas]

On 05/05/2014 18:59, Evelyn Hung wrote:
> Hi Paul,
>
> Taking screenshots and listening navigator events can be done by
> requiring browser api which is already a privileged api. I agree we
> should be careful on exposing webapps-manage since it opens app
> protocol, I know there is already a bug 899994 having a lot
> discussion. For embed-apps, I'm not sure how it can be a "lighter"
> version since it only allows one thing - make mozapp attribute work.
> Can you explain more? :)
>

One of the only thing I can think of is the special code path at
http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsSubDocumentFrame.cpp#228

We may want to also check in this code path if this is the main process,
just to make sure content processes do not use that.

[Paul Theriault]

So what I was hinting at, was trying to understand exactly what your needs are here. If possible, I would like to find a solution that doesn’t require the 3rd-party app to have complete control/access to the embedded app.This is why I was asking for more details about the proposed UX.

For example, lets consider a few different options:

1. Just grant embed-apps to 3rd party home screens:
- all the security issues mentioned above
- Apps currently need to be embedded in the system app for communication with Gecko to work correctly. If you embed them in another app, you will need to replicate a whole bunch of plumbing (system messages, chrome events etc etc).

2. 3rd party apps can create a button in their app which when clicked, launches another app fullscreen. This use case could be solved just by allowing “linking” to an app (which is effectively the ability to start it.) This isn’t really embedding. but sounds like the scenario you proposed.

3. Perhaps there some way we can ‘fake’ embedding? I.e. same as option 2, but instead of opening an app fullscreen, open it at a specific screen location and dimensions - i.e. so the ‘embedded’ app is still actually a child of the system app in the window heirachy, but visibly it appears to be “embedded” within the 3rd party homescreen. I imagine this would be somewhat complicated for Gaia window management, but this would seem to solve most of the security and plumbing issues to me. Just a thought.


- Paul

On 6 May 2014, at 2:59 am, Evelyn Hung <eh...@mozilla.com> wrote:

> Hi Paul,
>
> Taking screenshots and listening navigator events can be done by requiring browser api which is already a privileged api. I agree we should be careful on exposing webapps-manage since it opens app protocol, I know there is already a bug 899994 having a lot discussion. For embed-apps, I'm not sure how it can be a "lighter" version since it only allows one thing - make mozapp attribute work. Can you explain more? :)
>

[Jonas Sicking]

On Mon, May 5, 2014 at 1:03 AM, Gary Chen <gc...@mozilla.com> wrote:
> Hi all,
> We are going to allow 3rd-party APPs open and embed widget in their own APPs.

> Such as homescreen, lockscreen APP .....etc.

> As far as I know widget is not much different between APP, just only has different size.
>
> So 3rd-party APPs need to have ability to embed "OPEN WEB APPs" in mozAPP frames,
> according to MDN [1] and [2] APPs must have 'embed-apps' permission.
>
> Is there any concern to expose 'embed-apps' to privilege?
> I want to bring this topic to WebAPI meeting this week, any comments and discussions are welcome.
>
> [1] https://developer.mozilla.org/en-US/Apps/Build/App_permissions#embed-apps
> [2] https://developer.mozilla.org/en-US/docs/WebAPI/Browser#Permissions

I don't think that we need to expose all of embed-apps to 3rd party content.

One of the risks with exposing "embed-apps" is click jacking. Here's
what the attack would look like:

1. Attacker creates an app which tells the user "click the monkey as
many times as you can in 30 seconds".
2. The app uses a <iframe mozapp> to launch the dialer app.
3. The app uses CSS to overlay the game on top of the <iframe mozapp>
4. The app renders a monkey over where the "1" button is. However it
leaves a small hole in the middle monkey which displays a few pixels
of the "1" button.
5. Once the user clicks the monkey, move the monkey to be over the "2"
button. Again there's a hole in the middle of the monkey.
6. Repeat until the user has dialed the desired phone number.
7. Place the monkey over the "dial" button.

This way the attacker can trick the user into using the dialer app to
dial any phone number that the attacker wants.

If we instead have a "embed-widgets" permission which only allows
creating <iframe mozbrowser>s which render pages explicitly declared
as widgets. I.e. only if an app has declared that a certain page is a
widget should we allow it to be opened using "embed-widgets".

So an app could put something like the following in its manifest:

{
name: "MyApp2000",
...
widgets: {
"mywidget1": {
href: "widget.html"
positions: ["homescreen", "lockscreen"]
description: "This is my cool widget"
},
"myotherwidget": { ... }
}
}


We could then allow a page with "embed-widgets" permission to do
something like <iframe mozapp="manifesturl" mozwidget="mywidget1">

/ Jonas

[Gary Chen]

Hi Paul,
Thanks for your advice,
Just add some comment inline.

Thanks

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

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

----- Original Message -----

From: "Paul Theriault" <pther...@mozilla.com>
To: "Evelyn Hung" <eh...@mozilla.com>
Cc: dev-w...@lists.mozilla.org
Sent: Tuesday, May 6, 2014 6:37:53 AM
Subject: Re: Expose 'embed-apps' to privilege.

So what I was hinting at, was trying to understand exactly what your needs are here. If possible, I would like to find a solution that doesn’t require the 3rd-party app to have complete control/access to the embedded app.This is why I was asking for more details about the proposed UX.

For example, lets consider a few different options:

1. Just grant embed-apps to 3rd party home screens:
- all the security issues mentioned above
- Apps currently need to be embedded in the system app for communication with Gecko to work correctly. If you embed them in another app, you will need to replicate a whole bunch of plumbing (system messages, chrome events etc etc).

2. 3rd party apps can create a button in their app which when clicked, launches another app fullscreen. This use case could be solved just by allowing “linking” to an app (which is effectively the ability to start it.) This isn’t really embedding. but sounds like the scenario you proposed.

I don't think “linking to an app” is a widget use case.
For example, user expect clock widget can show real time on homescreen not just a 'link' to launch app fullscreen.

3. Perhaps there some way we can ‘fake’ embedding? I.e. same as option 2, but instead of opening an app fullscreen, open it at a specific screen location and dimensions - i.e. so the ‘embedded’ app is still actually a child of the system app in the window heirachy, but visibly it appears to be “embedded” within the 3rd party homescreen. I imagine this would be somewhat complicated for Gaia window management, but this would seem to solve most of the security and plumbing issues to me. Just a thought.

Yes, Stream3 gaia team has already did a similar demo as you mentioned above, we let homescreen communicate with system for rendering widget in system through 'IAC' API.
Unfortunately there are more security issues for exposing 'IAC' to privilege.

>>>> On 05/05/2014 10:03, Gary Chen wrote:
>>>>> Hi all,
>>>>> We are going to allow 3rd-party APPs open and embed widget in their own
>>>>> APPs.

>>>>> Such as homescreen, lockscreen APP …..etc.

>>>>> As far as I know widget is not much different between APP, just only has
>>>>> different size.
>>>>>
>>>>> So 3rd-party APPs need to have ability to embed "OPEN WEB APPs” in mozAPP
>>>>> frames,
>>>>> according to MDN [1] and [2] APPs must have 'embed-apps’ permission.
>>>>>
>>>>> Is there any concern to expose 'embed-apps' to privilege?
>>>>> I want to bring this topic to WebAPI meeting this week, any comments and
>>>>> discussions are welcome.
>>>>>
>>>>> [1]
>>>>> https://developer.mozilla.org/en-US/Apps/Build/App_permissions#embed-apps
>>>>> [2] https://developer.mozilla.org/en-US/docs/WebAPI/Browser#Permissions
>>>>>

[Paul Theriault]

Thanks for the info - I’d suggest then that we pursue Jonas’ suggestion of a embed-widget permission.

On 6 May 2014, at 3:05 pm, Gary Chen <gc...@mozilla.com> wrote:

> Hi Paul,
> Thanks for your advice,
> Just add some comment inline.
>
> Thanks
> Best regards
> -------------------------------------
> Gary Chen 陳柏宇
> Mozilla Taiwan
>
> T: +886-2-87861100 # 206
> M: +886-975151712
> gc...@mozilla.com
>

[Ehsan Akhgari]

I think Jonas' idea for restricting the URLs that the embedding iframe
is allowed to load based on a new "embed-widgets" permission is a good one.

Do you also need parts of the mozbrowser API for this use case? If yes,
can you please clarify which parts?

Thanks!
Ehsan

On 2014-05-05, 9:45 PM, Jonas Sicking wrote:

> On Mon, May 5, 2014 at 1:03 AM, Gary Chen <gc...@mozilla.com> wrote:
>> Hi all,
>> We are going to allow 3rd-party APPs open and embed widget in their own APPs.

>> Such as homescreen, lockscreen APP .....etc.

>> As far as I know widget is not much different between APP, just only has different size.
>>
>> So 3rd-party APPs need to have ability to embed "OPEN WEB APPs" in mozAPP frames,
>> according to MDN [1] and [2] APPs must have 'embed-apps' permission.
>>
>> Is there any concern to expose 'embed-apps' to privilege?
>> I want to bring this topic to WebAPI meeting this week, any comments and discussions are welcome.
>>
>> [1] https://developer.mozilla.org/en-US/Apps/Build/App_permissions#embed-apps
>> [2] https://developer.mozilla.org/en-US/docs/WebAPI/Browser#Permissions
>

[Jonas Sicking]

On Tue, May 6, 2014 at 4:18 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> I think Jonas' idea for restricting the URLs that the embedding iframe is
> allowed to load based on a new "embed-widgets" permission is a good one.
>
> Do you also need parts of the mozbrowser API for this use case? If yes, can
> you please clarify which parts?

Ah, yes, I didn't mention that part. I think we should forbid any
parts of the mozbrowser API which allows reading data from the
contents of the iframe. So grabbing screenshots or getting
notifications about navigations should not be allowed.

Would this break any of the use cases?

/ Jonas

[Gary Chen]

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

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

----- Original Message -----

From: "Jonas Sicking" <jo...@sicking.cc>
To: "Ehsan Akhgari" <ehsan....@gmail.com>
Cc: "Gary Chen" <gc...@mozilla.com>, "dev-webapi" <dev-w...@lists.mozilla.org>, "Ehsan Akhgari" <eh...@mozilla.com>, "Gene Lian" <cl...@mozilla.com>, "Evelyn Hung" <eh...@mozilla.com>, "Marco Chen" <mc...@mozilla.com>
Sent: Wednesday, May 7, 2014 7:41:20 AM
Subject: Re: Expose 'embed-apps' to privilege.

On Tue, May 6, 2014 at 4:18 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> I think Jonas' idea for restricting the URLs that the embedding iframe is
> allowed to load based on a new "embed-widgets" permission is a good one.
>
> Do you also need parts of the mozbrowser API for this use case? If yes, can
> you please clarify which parts?

Ah, yes, I didn't mention that part. I think we should forbid any
parts of the mozbrowser API which allows reading data from the
contents of the iframe. So grabbing screenshots or getting
notifications about navigations should not be allowed.

Would this break any of the use cases?

In some case, grabbing screenshots is needed.
For example, when user switch homescreen pages, some widgets will be suspend which are in the background pages.
I think it just like card view, for better user experience we won't want to show black screen on widgets when they siwtch back to foreground pages.

I am not sure what are "notifications about navigations"? "alert", "confirm" dialog?
If yes, our team also has discussed this issue, we propose to extend mozbrowser api - propagate events to grandparent frames.
In our case the grandparent frame is system app, system app will handle these 'notifications' If we don't want 3rd-party app handle these events.

I just curious is there any security concern about grabbing screenshots?

[Paul Theriault]

On 7 May 2014, at 9:41 am, Jonas Sicking <jo...@sicking.cc> wrote:

> On Tue, May 6, 2014 at 4:18 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>> I think Jonas' idea for restricting the URLs that the embedding iframe is
>> allowed to load based on a new "embed-widgets" permission is a good one.
>>
>> Do you also need parts of the mozbrowser API for this use case? If yes, can
>> you please clarify which parts?
>
> Ah, yes, I didn't mention that part. I think we should forbid any
> parts of the mozbrowser API which allows reading data from the
> contents of the iframe. So grabbing screenshots or getting
> notifications about navigations should not be allowed.

I am all for making a “safer” version of the mozbrowser permission that we can expose more widely (with less risk of abuse). But mozbrowser (browser permission) is already available to privileged apps - the ability to frame an arbitrary web page seems more open to abuse than the ability to frame a widget app. (maybe I am making assumptions about what widgets do).

To frame (sorry;) the question another way: is there a reason we should be more careful framing widgets than framing web pages? Why do widgets need more protection?

>
> Would this break any of the use cases?
>

[Paul Theriault]

On 7 May 2014, at 10:16 am, Gary Chen <gc...@mozilla.com> wrote:

>
>
> Best regards
> -------------------------------------
> Gary Chen 陳柏宇
> Mozilla Taiwan
>
> T: +886-2-87861100 # 206
> M: +886-975151712
> gc...@mozilla.com
>
> ----- Original Message -----
>
> From: "Jonas Sicking" <jo...@sicking.cc>
> To: "Ehsan Akhgari" <ehsan....@gmail.com>
> Cc: "Gary Chen" <gc...@mozilla.com>, "dev-webapi" <dev-w...@lists.mozilla.org>, "Ehsan Akhgari" <eh...@mozilla.com>, "Gene Lian" <cl...@mozilla.com>, "Evelyn Hung" <eh...@mozilla.com>, "Marco Chen" <mc...@mozilla.com>
> Sent: Wednesday, May 7, 2014 7:41:20 AM
> Subject: Re: Expose 'embed-apps' to privilege.
>

> On Tue, May 6, 2014 at 4:18 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>> I think Jonas' idea for restricting the URLs that the embedding iframe is
>> allowed to load based on a new "embed-widgets" permission is a good one.
>>
>> Do you also need parts of the mozbrowser API for this use case? If yes, can
>> you please clarify which parts?
>
> Ah, yes, I didn't mention that part. I think we should forbid any
> parts of the mozbrowser API which allows reading data from the
> contents of the iframe. So grabbing screenshots or getting
> notifications about navigations should not be allowed.
>

> Would this break any of the use cases?
>

> In some case, grabbing screenshots is needed.
> For example, when user switch homescreen pages, some widgets will be suspend which are in the background pages.
> I think it just like card view, for better user experience we won't want to show black screen on widgets when they siwtch back to foreground pages.
>
> I am not sure what are "notifications about navigations"? "alert", "confirm" dialog?
> If yes, our team also has discussed this issue, we propose to extend mozbrowser api - propagate events to grandparent frames.
> In our case the grandparent frame is system app, system app will handle these 'notifications' If we don't want 3rd-party app handle these events.

Events like mozbrowserlocationchange. See https://developer.mozilla.org/en-US/docs/WebAPI/Browser for a list of events (not sure how up to date this is).

Im not sure what the implications would be of just relaying these events to the parent - how would keep track of what was intended for the homescreen, vs what was intended for the widget. It gets messy real quick I think, but maybe someone else (gaia browser team?) have insight here.

>
> I just curious is there any security concern about grabbing screenshots?

Very much so - any sensitive data shown in the child app would be accessible in the parent (albeit only in image form).

[Ehsan Akhgari]

On 2014-05-06, 8:16 PM, Gary Chen wrote:
> On Tue, May 6, 2014 at 4:18 PM, Ehsan Akhgari <ehsan....@gmail.com>
> wrote:
> > I think Jonas' idea for restricting the URLs that the embedding iframe is
> > allowed to load based on a new "embed-widgets" permission is a good one.
> >
> > Do you also need parts of the mozbrowser API for this use case? If
> yes, can
> > you please clarify which parts?
>
> Ah, yes, I didn't mention that part. I think we should forbid any
> parts of the mozbrowser API which allows reading data from the
> contents of the iframe. So grabbing screenshots or getting
> notifications about navigations should not be allowed.
>
> Would this break any of the use cases?
>
> In some case, grabbing screenshots is needed.
> For example, when user switch homescreen pages, some widgets will
> be suspend which are in the background pages.
> I think it just like card view, for better user experience we won't want
> to show black screen on widgets when they siwtch back to foreground pages.

Hmm, why would the widget be suspended? Keeping the widget iframe
rendering while dragging the homescreen page around sounds like the kind
of thing that the platform should be able to handle well for you.

> I am not sure what are "notifications about navigations"? "alert",
> "confirm" dialog?
> If yes, our team also has discussed this issue, we propose to extend
> mozbrowser api - propagate events to grandparentframes.
> In our case the grandparent frame is system app, system app will handle
> these 'notifications' If we don't want 3rd-party app handle these events.

I think Jonas meant navigation in terms of web content navigation (i.e.
navigating to another page, going back/forward, etc.)

> I just curious is there any security concern about grabbing screenshots?

The widget might render sensitive information to the user (for example,
allow the user to enter a password, or show their bank account number,
etc.) We protect against pages from different origins reading pixels
from each others' renderings because of this reason in many other parts
of the Web platform.

Cheers,
Ehsan

[Gary Chen]

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

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

----- Original Message -----
> From: "Ehsan Akhgari" <ehsan....@gmail.com>
> To: "Gary Chen" <gc...@mozilla.com>, "Jonas Sicking" <jo...@sicking.cc>
> Cc: "dev-webapi" <dev-w...@lists.mozilla.org>, "Ehsan Akhgari" <eh...@mozilla.com>, "Gene Lian"
> <cl...@mozilla.com>, "Evelyn Hung" <eh...@mozilla.com>, "Marco Chen" <mc...@mozilla.com>
> Sent: Wednesday, May 7, 2014 9:40:25 AM
> Subject: Re: Expose 'embed-apps' to privilege.
>

> On 2014-05-06, 8:16 PM, Gary Chen wrote:
> > On Tue, May 6, 2014 at 4:18 PM, Ehsan Akhgari <ehsan....@gmail.com>
> > wrote:
> > > I think Jonas' idea for restricting the URLs that the embedding iframe
> > > is
> > > allowed to load based on a new "embed-widgets" permission is a good one.
> > >
> > > Do you also need parts of the mozbrowser API for this use case? If
> > yes, can
> > > you please clarify which parts?
> >
> > Ah, yes, I didn't mention that part. I think we should forbid any
> > parts of the mozbrowser API which allows reading data from the
> > contents of the iframe. So grabbing screenshots or getting
> > notifications about navigations should not be allowed.
> >
> > Would this break any of the use cases?
> >
> > In some case, grabbing screenshots is needed.
> > For example, when user switch homescreen pages, some widgets will
> > be suspend which are in the background pages.
> > I think it just like card view, for better user experience we won't want
> > to show black screen on widgets when they siwtch back to foreground pages.
>
> Hmm, why would the widget be suspended? Keeping the widget iframe
> rendering while dragging the homescreen page around sounds like the kind
> of thing that the platform should be able to handle well for you.
>

Sorry, I should not use 'suspended' this word, it is so confusing.
In current platform, app get high priority to be kill when it is in background and memory pressure occurred.
Same as widget, if homescreen page is dragged to background those widgets on this homescreen may get high priority to be kill.
In this situation screenshots might be a better user experience.
But this is just my though.

> > I am not sure what are "notifications about navigations"? "alert",
> > "confirm" dialog?
> > If yes, our team also has discussed this issue, we propose to extend
> > mozbrowser api - propagate events to grandparentframes.
> > In our case the grandparent frame is system app, system app will handle
> > these 'notifications' If we don't want 3rd-party app handle these events.
>
> I think Jonas meant navigation in terms of web content navigation (i.e.
> navigating to another page, going back/forward, etc.)

Thanks for clarify this point.

>
> > I just curious is there any security concern about grabbing screenshots?
>
> The widget might render sensitive information to the user (for example,
> allow the user to enter a password, or show their bank account number,
> etc.) We protect against pages from different origins reading pixels
> from each others' renderings because of this reason in many other parts
> of the Web platform.
>

Thanks for reminder this issue.
Echo Paul, mozbrowser (browser permission) is already available to privileged apps.
It means APP dev can use this API make a browser-like APP,
and it also has ability to take a screenshot when user enter sensitive information.

[Ben Francis]

On Tue, May 6, 2014 at 2:45 AM, Jonas Sicking <jo...@sicking.cc> wrote:

> We could then allow a page with "embed-widgets" permission to do
> something like <iframe mozapp="manifesturl" mozwidget="mywidget1">
>

Could this be something closer to:

<webview manifest="http://myapp2000.com/manifest.webapp" src="
http://myapp2000.com/widget.html">

or currently:

<iframe mozbrowser mozapp="http://myapp2000.com/manifest.webapp" src="
http://myapp2000.com/widget.html">


Also, could web apps expose widgets in their manifest to be embedded in
packaged apps, or only packaged apps?

[Vivien Nicolas]

On 07/05/2014 02:16, Gary Chen wrote:
>
>
> Best regards ------------------------------------- Gary Chen 陳柏宇
> Mozilla Taiwan
>
> T: +886-2-87861100 # 206 M: +886-975151712 gc...@mozilla.com
>
> ----- Original Message -----
>

> From: "Jonas Sicking" <jo...@sicking.cc> To: "Ehsan Akhgari"
> <ehsan....@gmail.com> Cc: "Gary Chen" <gc...@mozilla.com>,

> "dev-webapi" <dev-w...@lists.mozilla.org>, "Ehsan Akhgari"
> <eh...@mozilla.com>, "Gene Lian" <cl...@mozilla.com>, "Evelyn Hung"
> <eh...@mozilla.com>, "Marco Chen" <mc...@mozilla.com> Sent:
> Wednesday, May 7, 2014 7:41:20 AM Subject: Re: Expose 'embed-apps' to
> privilege.
>

> On Tue, May 6, 2014 at 4:18 PM, Ehsan Akhgari
> <ehsan....@gmail.com> wrote:
>> I think Jonas' idea for restricting the URLs that the embedding
>> iframe is allowed to load based on a new "embed-widgets" permission
>> is a good one.
>>
>> Do you also need parts of the mozbrowser API for this use case? If
>> yes, can you please clarify which parts?
>

I feel like that we will discover the needs for some parts based on
using widgets. That's what it would be nice to have bug 879475 as soon
as we can in order to iterate.

> Ah, yes, I didn't mention that part. I think we should forbid any
> parts of the mozbrowser API which allows reading data from the
> contents of the iframe. So grabbing screenshots or getting
> notifications about navigations should not be allowed.
>
> Would this break any of the use cases?
>
> In some case, grabbing screenshots is needed. For example, when user
> switch homescreen pages, some widgets will be suspend which are in
> the background pages. I think it just like card view, for better user
> experience we won't want to show black screen on widgets when they
> siwtch back to foreground pages.
>

I would like to get rid of screenshots for such case. I would like to
see if we can go forward with bug 1002430
This will basically keeps around the rendering of the widget unless
there is a memory pressure.

[Evelyn Hung]

This case is more like a "worry", not really facing a performance issue now (but I bet we will).

However, I also want to echo Paul's question:

"is there a reason we should be more careful framing widgets than framing web pages? Why do widgets need more protection? "

I see no difference between web pages and widgets on screenshot case. Apps with browser permission can take screenshot of embedded webpage to get any sensitive information rendered on the page.

A problem is app:// protocol which allows embedder be able to read resource in embeded apps. I see the conclusion has been made in bug 899994 comment 24: we will remove this ability while exposing homescreen-webapps-manage. I think it's a good way to go.

Another problem worth to be mentioned regarding mozbrowser is 'mozbrowserusernameandpasswordrequired' event. I'm curious why we exposed this to a privileged app in browser API? As a user I won't trust a 3rd-party app displaying input field to ask my password of another application...

[Vivien Nicolas]

Maybe the question is: why is the browser API a privileged only API ?

[Ehsan Akhgari]

On 2014-05-06, 8:27 PM, Paul Theriault wrote:
>
> On 7 May 2014, at 9:41 am, Jonas Sicking <jo...@sicking.cc> wrote:
>

>> On Tue, May 6, 2014 at 4:18 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>>> I think Jonas' idea for restricting the URLs that the embedding iframe is
>>> allowed to load based on a new "embed-widgets" permission is a good one.
>>>
>>> Do you also need parts of the mozbrowser API for this use case? If yes, can
>>> you please clarify which parts?
>>

>> Ah, yes, I didn't mention that part. I think we should forbid any
>> parts of the mozbrowser API which allows reading data from the
>> contents of the iframe. So grabbing screenshots or getting
>> notifications about navigations should not be allowed.
>

> I am all for making a �safer� version of the mozbrowser permission that we can expose more widely (with less risk of abuse). But mozbrowser (browser permission) is already available to privileged apps - the ability to frame an arbitrary web page seems more open to abuse than the ability to frame a widget app. (maybe I am making assumptions about what widgets do).
>
> To frame (sorry;) the question another way: is there a reason we should be more careful framing widgets than framing web pages? Why do widgets need more protection?

To me, the reason would be that the widget is expected to render an
app:// URI not a normal web page.

Also, I think we should approach the problem in the other way, i.e., by
asking people what we need to satisfy the widget use case, as opposed to
start by assuming that they will have the full mozbrowser API and then
see which parts of it we can take away. :-)

Cheers,
Ehsan

[Ehsan Akhgari]

On 2014-05-07, 12:47 PM, Evelyn Hung wrote:
>
>
> ----- Original Message -----
>>
>>
>> On 07/05/2014 02:16, Gary Chen wrote:
>>>
>>>
>>> Best regards ------------------------------------- Gary Chen 陳柏宇
>>> Mozilla Taiwan
>>>
>>> T: +886-2-87861100 # 206 M: +886-975151712 gc...@mozilla.com
>>>
>>> ----- Original Message -----
>>>
>>> From: "Jonas Sicking" <jo...@sicking.cc> To: "Ehsan Akhgari"
>>> <ehsan....@gmail.com> Cc: "Gary Chen" <gc...@mozilla.com>,
>>> "dev-webapi" <dev-w...@lists.mozilla.org>, "Ehsan Akhgari"
>>> <eh...@mozilla.com>, "Gene Lian" <cl...@mozilla.com>, "Evelyn Hung"
>>> <eh...@mozilla.com>, "Marco Chen" <mc...@mozilla.com> Sent:
>>> Wednesday, May 7, 2014 7:41:20 AM Subject: Re: Expose 'embed-apps' to
>>> privilege.
>>>

>>> On Tue, May 6, 2014 at 4:18 PM, Ehsan Akhgari
>>> <ehsan....@gmail.com> wrote:
>>>> I think Jonas' idea for restricting the URLs that the embedding
>>>> iframe is allowed to load based on a new "embed-widgets" permission
>>>> is a good one.
>>>>
>>>> Do you also need parts of the mozbrowser API for this use case? If
>>>> yes, can you please clarify which parts?
>>>
>>

>> I feel like that we will discover the needs for some parts based on
>> using widgets. That's what it would be nice to have bug 879475 as soon
>> as we can in order to iterate.

Yes, indeed!

>>> Ah, yes, I didn't mention that part. I think we should forbid any
>>> parts of the mozbrowser API which allows reading data from the
>>> contents of the iframe. So grabbing screenshots or getting
>>> notifications about navigations should not be allowed.
>>>

>>> Would this break any of the use cases?
>>>
>>> In some case, grabbing screenshots is needed. For example, when user
>>> switch homescreen pages, some widgets will be suspend which are in
>>> the background pages. I think it just like card view, for better user
>>> experience we won't want to show black screen on widgets when they
>>> siwtch back to foreground pages.

I think taking a screenshot is the wrong solution there anyway, since
depending on the widget, it might actually break its functionality. For
example, a widget that shows the current time displaying seconds would
appear as frozen with the screenshot solution.

>> I would like to get rid of screenshots for such case. I would like to
>> see if we can go forward with bug 1002430
>> This will basically keeps around the rendering of the widget unless
>> there is a memory pressure.
>>
>
> This case is more like a "worry", not really facing a performance issue now (but I bet we will).
>
> However, I also want to echo Paul's question:
>

> "is there a reason we should be more careful framing widgets than framing web pages? Why do widgets need more protection? "
>

> I see no difference between web pages and widgets on screenshot case. Apps with browser permission can take screenshot of embedded webpage to get any sensitive information rendered on the page.
>
> A problem is app:// protocol which allows embedder be able to read resource in embeded apps. I see the conclusion has been made in bug 899994 comment 24: we will remove this ability while exposing homescreen-webapps-manage. I think it's a good way to go.
>
> Another problem worth to be mentioned regarding mozbrowser is 'mozbrowserusernameandpasswordrequired' event. I'm curious why we exposed this to a privileged app in browser API? As a user I won't trust a 3rd-party app displaying input field to ask my password of another application...

Great point! I wasn't really involved in the discussion on making
mozbrowser privileged, but from what we have discussed so far, that
seems like a mistake. :(

Cheers,
Ehsan

[Paul Theriault]

On 8 May 2014, at 6:10 am, Ehsan Akhgari <ehsan....@gmail.com> wrote:

> On 2014-05-06, 8:27 PM, Paul Theriault wrote:
>>
>> On 7 May 2014, at 9:41 am, Jonas Sicking <jo...@sicking.cc> wrote:
>>

>>> On Tue, May 6, 2014 at 4:18 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
>>>> I think Jonas' idea for restricting the URLs that the embedding iframe is
>>>> allowed to load based on a new "embed-widgets" permission is a good one.
>>>>
>>>> Do you also need parts of the mozbrowser API for this use case? If yes, can
>>>> you please clarify which parts?
>>>

>>> Ah, yes, I didn't mention that part. I think we should forbid any
>>> parts of the mozbrowser API which allows reading data from the
>>> contents of the iframe. So grabbing screenshots or getting
>>> notifications about navigations should not be allowed.
>>

>> I am all for making a “safer” version of the mozbrowser permission that we can expose more widely (with less risk of abuse). But mozbrowser (browser permission) is already available to privileged apps - the ability to frame an arbitrary web page seems more open to abuse than the ability to frame a widget app. (maybe I am making assumptions about what widgets do).

>>
>> To frame (sorry;) the question another way: is there a reason we should be more careful framing widgets than framing web pages? Why do widgets need more protection?
>
> To me, the reason would be that the widget is expected to render an app:// URI not a normal web page.

But not just any old app:// URI, one which explicitly expects to the frame in such a way by declaring it as a widget.

>
> Also, I think we should approach the problem in the other way, i.e., by asking people what we need to satisfy the widget use case, as opposed to start by assuming that they will have the full mozbrowser API and then see which parts of it we can take away. :-)

My point is that the mozbrowser API is dangerous currently, and relies on marketplace review as a mitigation. Any improvements to the safety of this API should be available to any consumer of the mozbrowser API, not just when it is being used to frame widgets.

>
> Cheers,
> Ehsan

[Marco Chen]

Hi all,

It seems that this mail thread came out two discussions now.("Widget" and "How to safety mozbrowser")
Could we keep to discuss the widget support and leave the other one to a separate thread?

According to mozbrowser is already exposed to privileged apps, widget support is not the one caused this issue.
But maybe "mozwidget" will bring additional risk to mozbrowser and that would be worth to remain discussion here.

Back to Jonas's proposal, are there any other feedbacks?

Thanks.
----- 原始郵件 -----

寄件者: "Paul Theriault" <pther...@mozilla.com>
收件者: "Ehsan Akhgari" <ehsan....@gmail.com>
副本: "Jonas Sicking" <jo...@sicking.cc>, "Gary Chen" <gc...@mozilla.com>, "dev-webapi" <dev-w...@lists.mozilla.org>, "Gene Lian" <cl...@mozilla.com>, "Evelyn Hung" <eh...@mozilla.com>, "Marco Chen" <mc...@mozilla.com>, "Ehsan Akhgari" <eh...@mozilla.com>
寄件備份: 2014 5 月 8 星期四 上午 7:58:34
主旨: Re: Expose 'embed-apps' to privilege.

On 8 May 2014, at 6:10 am, Ehsan Akhgari < ehsan....@gmail.com > wrote:




On 2014-05-06, 8:27 PM, Paul Theriault wrote:

<blockquote>

On 7 May 2014, at 9:41 am, Jonas Sicking < jo...@sicking.cc > wrote:

<blockquote>

On Tue, May 6, 2014 at 4:18 PM, Ehsan Akhgari < ehsan....@gmail.com > wrote:

<blockquote>

I think Jonas' idea for restricting the URLs that the embedding iframe is
allowed to load based on a new "embed-widgets" permission is a good one.

Do you also need parts of the mozbrowser API for this use case? If yes, can
you please clarify which parts?



Ah, yes, I didn't mention that part. I think we should forbid any
parts of the mozbrowser API which allows reading data from the
contents of the iframe. So grabbing screenshots or getting
notifications about navigations should not be allowed.

</blockquote>

I am all for making a “safer” version of the mozbrowser permission that we can expose more widely (with less risk of abuse). But mozbrowser (browser permission) is already available to privileged apps - the ability to frame an arbitrary web page seems more open to abuse than the ability to frame a widget app. (maybe I am making assumptions about what widgets do).

To frame (sorry;) the question another way: is there a reason we should be more careful framing widgets than framing web pages? Why do widgets need more protection?

</blockquote>

To me, the reason would be that the widget is expected to render an app:// URI not a normal web page.

</blockquote>

But not just any old app:// URI, one which explicitly expects to the frame in such a way by declaring it as a widget.

<blockquote>

Also, I think we should approach the problem in the other way, i.e., by asking people what we need to satisfy the widget use case, as opposed to start by assuming that they will have the full mozbrowser API and then see which parts of it we can take away. :-)

</blockquote>

My point is that the mozbrowser API is dangerous currently, and relies on marketplace review as a mitigation. Any improvements to the safety of this API should be available to any consumer of the mozbrowser API, not just when it is being used to frame widgets.

<blockquote>


Cheers,
Ehsan

</blockquote>

[Ehsan Akhgari]

I think we are still waiting to hear more about the use cases here and
see whether Jonas' suggestion on disallowing screenshots and navigation
notifications for widgets will break any of the use cases. Can you
please help provide that information?

Thanks!
Ehsan

On 2014-05-08, 10:54 AM, Marco Chen wrote:
> Hi all,
>
> It seems that this mail thread came out two discussions now.("Widget"
> and "How to safety mozbrowser")
> Could we keep to discuss the widget support and leave the other one to a
> separate thread?
>
> According to mozbrowser is already exposed to privileged apps, widget
> support is not the one caused this issue.
> But maybe "mozwidget" will bring additional risk to mozbrowser and that
> would be worth to remain discussion here.
>
> Back to Jonas's proposal, are there any other feedbacks?
>
> Thanks.

> ------------------------------------------------------------------------
> *寄件者: *"Paul Theriault" <pther...@mozilla.com>
> *收件者: *"Ehsan Akhgari" <ehsan....@gmail.com>
> *副本: *"Jonas Sicking" <jo...@sicking.cc>, "Gary Chen"

> <gc...@mozilla.com>, "dev-webapi" <dev-w...@lists.mozilla.org>, "Gene
> Lian" <cl...@mozilla.com>, "Evelyn Hung" <eh...@mozilla.com>, "Marco
> Chen" <mc...@mozilla.com>, "Ehsan Akhgari" <eh...@mozilla.com>

> *寄件備份: *2014 5 月 8 星期四 上午 7:58:34
> *主旨: *Re: Expose 'embed-apps' to privilege.

>
>
> On 8 May 2014, at 6:10 am, Ehsan Akhgari <ehsan....@gmail.com

> <mailto:ehsan....@gmail.com>> wrote:
>
> On 2014-05-06, 8:27 PM, Paul Theriault wrote:
>
>
> On 7 May 2014, at 9:41 am, Jonas Sicking <jo...@sicking.cc

> <mailto:jo...@sicking.cc>> wrote:
>
> On Tue, May 6, 2014 at 4:18 PM, Ehsan Akhgari

> <ehsan....@gmail.com <mailto:ehsan....@gmail.com>>

> wrote:
>
> I think Jonas' idea for restricting the URLs that the
> embedding iframe is
> allowed to load based on a new "embed-widgets"
> permission is a good one.
>
> Do you also need parts of the mozbrowser API for this
> use case? If yes, can
> you please clarify which parts?
>
>
> Ah, yes, I didn't mention that part. I think we should
> forbid any
> parts of the mozbrowser API which allows reading data from the
> contents of the iframe. So grabbing screenshots or getting
> notifications about navigations should not be allowed.
>
>

> I am all for making a “safer” version of the mozbrowser
> permission that we can expose more widely (with less risk of
> abuse). But mozbrowser (browser permission) is already available
> to privileged apps - the ability to frame an arbitrary web page
> seems more open to abuse than the ability to frame a widget app.
> (maybe I am making assumptions about what widgets do).
>
> To frame (sorry;) the question another way: is there a reason
> we should be more careful framing widgets than framing web
> pages? Why do widgets need more protection?
>
>

> To me, the reason would be that the widget is expected to render an
> app:// URI not a normal web page.
>
>

> But not just any old app:// URI, one which explicitly expects to the
> frame in such a way by declaring it as a widget.
>
>

> Also, I think we should approach the problem in the other way, i.e.,
> by asking people what we need to satisfy the widget use case, as
> opposed to start by assuming that they will have the full mozbrowser
> API and then see which parts of it we can take away. :-)
>
>

> My point is that the mozbrowser API is dangerous currently, and relies
> on marketplace review as a mitigation. Any improvements to the safety of
> this API should be available to any consumer of the mozbrowser API, not
> just when it is being used to frame widgets.
>
>

> Cheers,
> Ehsan
>
>
>

[Evelyn Hung]

Let me summarize a bit:

It looks like everybody agrees to invent a new 'embed-widgets' permission instead of exposing 'embed-apps', so I renamed bug 1005818 to reflect we are moving to 'embed-widgets' permission.
We are collecting more use cases to see if restricting functions below on browser API will break any use case.
At least 3 items been mentioned in this thread:

1. screenshots
2. navigation notifications
3. event 'mozbrowserusernameandpasswordrequired'

I can't think of a use case that really need functions above, so I agree we disallow them first and not make our situation as the "dangerous" browser api. We always can reopen the discussion when we have more information. :)

By the way, Gary is creating a wiki page to write down our discussion and the proposal.

Regards,

Evelyn

----- Original Message -----

[Gary Chen]

Hi All,
I've just created a wiki page for Widget API[1], will add more information later.
Any suggestions are welcome and looking forward to enrich the wiki page.
[1] https://wiki.mozilla.org/WebAPI/WidgetAPI

Thanks.

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

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

----- Original Message -----
> From: "Evelyn Hung" <eh...@mozilla.com>
> To: "Ehsan Akhgari" <ehsan....@gmail.com>

[Ehsan Akhgari]

On 2014-05-09, 4:31 AM, Evelyn Hung wrote:
> Let me summarize a bit:
>
> It looks like everybody agrees to invent a new 'embed-widgets' permission instead of exposing 'embed-apps', so I renamed bug 1005818 to reflect we are moving to 'embed-widgets' permission.

Great!

> We are collecting more use cases to see if restricting functions below on browser API will break any use case.
> At least 3 items been mentioned in this thread:
>
> 1. screenshots
> 2. navigation notifications
> 3. event 'mozbrowserusernameandpasswordrequired'
>
> I can't think of a use case that really need functions above, so I agree we disallow them first and not make our situation as the "dangerous" browser api. We always can reopen the discussion when we have more information. :)

So, which parts of the mozbrowser API do you think you will actually
need? The mozwidget attribute on the iframe lets you load the desired
widget into the iframe, what other things do you need to be able to do
with the iframe past that point?

Thanks!
Ehsan

[Vivien Nicolas]

iframe.setVisible would be nice IMO. That will let the app tells that
the widget is not visible and so the priority of the widget can be
decreased even if the embedder is foreground.

In terms of navigation events, maybe
[mozbrowserloadstart/mozbrowserloadend]. It will let the embedder create
a UI on top of the widget until this one is loaded.

|mozbrowsererror| may be nice as well, so the embedder can create a UI
on top of the widget if this one has been killed.

I wonder about the |mozbrowseresize| event. If the widget needs to be
resize, the embedder may allow that. Same thing for |mozbrowserclose|,
the embedder may need to know that the widget wants to close itself (not
sure why the widget would like such a thing but it will likely not work
correctly after that anyway).

That's what I have on top of my head.

> Thanks!
> Ehsan

[Gary Chen]

Hi all,
Our team has a assumption that widget is forbidden to "open a new UI".
Such as 'window.open', 'alert', |mozbrowserusernameandpasswordrequired| ...etc.
The main reason is to prevent embedder 'hijack' the UI dialog.
I've update and listed the relative events on wiki page[1].

And echo to Vivien's comment.
We prefer to allow UI changes events like |mozbrowseresize|, |mozbrowserclose|, |mozbrowsericonchange| and |mozbrowsertitlechange|.
Seems there is no any security concern and as a embedder may need to know these information for updating UI.

[1] https://wiki.mozilla.org/WebAPI/WidgetAPI#Issues_under_discussion#Issues_under_discussion

All suggestions are welcome.
Thanks

Gary Chen

----- Original Message -----
> From: "Vivien Nicolas" <vnic...@mozilla.com>
> To: dev-w...@lists.mozilla.org
> Sent: Friday, May 9, 2014 9:25:46 PM
> Subject: Re: Expose 'embed-apps' to privilege.
>
>
>

[Ben Francis]

On Tue, May 20, 2014 at 9:33 PM, Ben Francis <bfra...@mozilla.com> wrote:

>
> Is there any reason why...

>
> <iframe mozapp="manifesturl" mozwidget="mywidget1">
>

> can't be...
>
> <iframe mozapp="http://foo.com/manifest.webapp" src="
> http://foo.com/widget.html">
>

Maybe because this will only be available to packaged apps which don't have
known URLs to set the src attribute to? :(

[Paul Theriault]

On 21 May 2014, at 10:15 am, Paul Theriault <pther...@mozilla.com> wrote:

>
> On 21 May 2014, at 6:33 am, Ben Francis <bfra...@mozilla.com> wrote:

>
>>
>> On Fri, May 9, 2014 at 10:07 AM, Gary Chen <gc...@mozilla.com> wrote:
>> I've just created a wiki page for Widget API[1], will add more information later.
>> Any suggestions are welcome and looking forward to enrich the wiki page.
>> [1] https://wiki.mozilla.org/WebAPI/WidgetAPI
>>

>> Again, is there any reason why...

>>
>> <iframe mozapp="manifesturl" mozwidget="mywidget1">
>>
>> can't be...
>>

>> <iframe mozapp="http://foo.com/manifest.webapp" src="http://foo.com/widget.html”>
>
> The difference between the two, is that in Jonas’ proposal above, the widget author decides what the launch URI is. But in your proposal, the embedding page does.
>
> TLDR: I don’t think we should mix apps, and widgets. Apps should either be widgets, or apps not both.
>
> Because if we allow framing a widget which is some page inside an app, the parent can just set the src attribute of the iframe to be some other page in the app and it has effectively embedded the app.
>
> So instead of apps being allowed to declare certain pages as widgets, how about we just allow apps to declare themselves as widgets like:
>
> {
> name: "MyWidgetApp2000",
> ...
> widget:
> {
> positions: ["homescreen", "lockscreen"]
> },
> }
>
> Widgets can have many different ‘widget pages' within and the embedder choose which one, just by setting the URL
>
> <iframe mozapp="http://foo.com/manifest.webapp" src=“widget.html”>

Er I mean absolute,

<iframe mozapp="http://foo.com/manifest.webapp" src="http://foo.com/widget.html”>

but then you hit the issue you raise in the next post (packaged apps not having a URI.



>
>
>>
>> I see this eventually becoming...
>>
>> <webview manifest="http://foo.com/manifest.webapp" src="http://foo.com/widget.html”>
>>
>> and it would be nice not to have to add another vendor-prefixed attribute.
>>
>>
>> Will the existing "browser" permission become the "safe" browser API or the "unsafe" browser API?
>
> I was expecting a new permission and new api to be the ‘safe’ one.

[Ehsan Akhgari]

On 2014-05-20, 8:17 PM, Paul Theriault wrote:
>
> On 21 May 2014, at 10:15 am, Paul Theriault <pther...@mozilla.com> wrote:
>
>>
>> On 21 May 2014, at 6:33 am, Ben Francis <bfra...@mozilla.com> wrote:
>>
>>>
>>> On Fri, May 9, 2014 at 10:07 AM, Gary Chen <gc...@mozilla.com> wrote:
>>> I've just created a wiki page for Widget API[1], will add more information later.
>>> Any suggestions are welcome and looking forward to enrich the wiki page.
>>> [1] https://wiki.mozilla.org/WebAPI/WidgetAPI
>>>
>>> Again, is there any reason why...
>>>
>>> <iframe mozapp="manifesturl" mozwidget="mywidget1">
>>>
>>> can't be...
>>>

>>> <iframe mozapp="http://foo.com/manifest.webapp" src="http://foo.com/widget.html�>
>>
>> The difference between the two, is that in Jonas� proposal above, the widget author decides what the launch URI is. But in your proposal, the embedding page does.
>>
>> TLDR: I don�t think we should mix apps, and widgets. Apps should either be widgets, or apps not both.

>>
>> Because if we allow framing a widget which is some page inside an app, the parent can just set the src attribute of the iframe to be some other page in the app and it has effectively embedded the app.
>>
>> So instead of apps being allowed to declare certain pages as widgets, how about we just allow apps to declare themselves as widgets like:
>>
>> {
>> name: "MyWidgetApp2000",
>> ...
>> widget:
>> {
>> positions: ["homescreen", "lockscreen"]
>> },
>> }
>>

>> Widgets can have many different �widget pages' within and the embedder choose which one, just by setting the URL
>>
>> <iframe mozapp="http://foo.com/manifest.webapp" src=�widget.html�>
>
> Er I mean absolute,
>
> <iframe mozapp="http://foo.com/manifest.webapp" src="http://foo.com/widget.html�>

>
> but then you hit the issue you raise in the next post (packaged apps not having a URI.

Yeah, and that's why Jonas' proposal is better. :-)

On the naming issue, we've unfortunately digged ourselves pretty deep
here with exposing the names "mozapp" and "mozbrowser". I think it's
slightly better to call this new attribute "widget" and not "mozwidget"
but then we'd be less consistent with what we have today. I hesitate to
rename the element itself to <webview> because that might incorrectly
indicate some level of interop with Chrome App's <webview> which
currently does not exist. I think it is a noble goal to try to get
there but we should probably consider renaming mozbrowser et al to
<webview> once we're ready to converge on the API as well.

Cheers,
Ehsan

[Paul Theriault]

On 21 May 2014, at 10:33 am, Ehsan Akhgari <ehsan....@gmail.com> wrote:

> On 2014-05-20, 8:17 PM, Paul Theriault wrote:
>>
>> On 21 May 2014, at 10:15 am, Paul Theriault <pther...@mozilla.com> wrote:
>>
>>>
>>> On 21 May 2014, at 6:33 am, Ben Francis <bfra...@mozilla.com> wrote:
>>>
>>>>
>>>> On Fri, May 9, 2014 at 10:07 AM, Gary Chen <gc...@mozilla.com> wrote:
>>>> I've just created a wiki page for Widget API[1], will add more information later.
>>>> Any suggestions are welcome and looking forward to enrich the wiki page.
>>>> [1] https://wiki.mozilla.org/WebAPI/WidgetAPI
>>>>
>>>> Again, is there any reason why...
>>>>
>>>> <iframe mozapp="manifesturl" mozwidget="mywidget1">
>>>>
>>>> can't be...
>>>>

>>>> <iframe mozapp="http://foo.com/manifest.webapp" src="http://foo.com/widget.html”>
>>>
>>> The difference between the two, is that in Jonas’ proposal above, the widget author decides what the launch URI is. But in your proposal, the embedding page does.
>>>
>>> TLDR: I don’t think we should mix apps, and widgets. Apps should either be widgets, or apps not both.

>>>
>>> Because if we allow framing a widget which is some page inside an app, the parent can just set the src attribute of the iframe to be some other page in the app and it has effectively embedded the app.
>>>
>>> So instead of apps being allowed to declare certain pages as widgets, how about we just allow apps to declare themselves as widgets like:
>>>
>>> {
>>> name: "MyWidgetApp2000",
>>> ...
>>> widget:
>>> {
>>> positions: ["homescreen", "lockscreen"]
>>> },
>>> }
>>>

>>> Widgets can have many different ‘widget pages' within and the embedder choose which one, just by setting the URL
>>>
>>> <iframe mozapp="http://foo.com/manifest.webapp" src=“widget.html”>
>>
>> Er I mean absolute,
>>
>> <iframe mozapp="http://foo.com/manifest.webapp" src="http://foo.com/widget.html”>

>>
>> but then you hit the issue you raise in the next post (packaged apps not having a URI.
>
> Yeah, and that's why Jonas' proposal is better. :-)

Fair enough - but my main point is that the frame can be navigated. What happens when someone does this:

<iframe mozapp="manifesturl" mozwidget="mywidget1" src="http://foo.com/“ >

(Does the app get embedded, because it contains a widget? That seems like a dangerous side effect that devs might not be aware of.)

[Ehsan Akhgari]

On 2014-05-20, 9:02 PM, Paul Theriault wrote:
>
> On 21 May 2014, at 10:33 am, Ehsan Akhgari <ehsan....@gmail.com

> <mailto:ehsan....@gmail.com>> wrote:
>
>> On 2014-05-20, 8:17 PM, Paul Theriault wrote:
>>>
>>> On 21 May 2014, at 10:15 am, Paul Theriault <pther...@mozilla.com

>>> <mailto:pther...@mozilla.com>> wrote:
>>>
>>>>
>>>> On 21 May 2014, at 6:33 am, Ben Francis <bfra...@mozilla.com

>>>> <mailto:bfra...@mozilla.com>> wrote:
>>>>
>>>>>
>>>>> On Fri, May 9, 2014 at 10:07 AM, Gary Chen <gc...@mozilla.com
>>>>> <mailto:gc...@mozilla.com>> wrote:
>>>>> I've just created a wiki page for Widget API[1], will add more
>>>>> information later.
>>>>> Any suggestions are welcome and looking forward to enrich the
>>>>> wiki page.
>>>>> [1] https://wiki.mozilla.org/WebAPI/WidgetAPI
>>>>>
>>>>> Again, is there any reason why...
>>>>>
>>>>> <iframe mozapp="manifesturl" mozwidget="mywidget1">
>>>>>
>>>>> can't be...
>>>>>
>>>>> <iframe mozapp="http://foo.com/manifest.webapp"

>>>>> src="http://foo.com/widget.html�>
>>>>
>>>> The difference between the two, is that in Jonas� proposal above,

>>>> the widget author decides what the launch URI is. But in your
>>>> proposal, the embedding page does.
>>>>

>>>> TLDR: I don�t think we should mix apps, and widgets. Apps should

>>>> either be widgets, or apps not both.
>>>>
>>>> Because if we allow framing a widget which is some page inside an
>>>> app, the parent can just set the src attribute of the iframe to be
>>>> some other page in the app and it has effectively embedded the app.
>>>>
>>>> So instead of apps being allowed to declare certain pages as
>>>> widgets, how about we just allow apps to declare themselves as
>>>> widgets like:
>>>>
>>>> {
>>>> name: "MyWidgetApp2000",
>>>> ...
>>>> widget:
>>>> {
>>>> positions: ["homescreen", "lockscreen"]
>>>> },
>>>> }
>>>>

>>>> Widgets can have many different �widget pages' within and the

>>>> embedder choose which one, just by setting the URL
>>>>

>>>> <iframe mozapp="http://foo.com/manifest.webapp" src=�widget.html�>

>>>
>>> Er I mean absolute,
>>>
>>> <iframe mozapp="http://foo.com/manifest.webapp"

>>> src="http://foo.com/widget.html�>

>>>
>>> but then you hit the issue you raise in the next post (packaged apps
>>> not having a URI.
>>
>> Yeah, and that's why Jonas' proposal is better. :-)
>
> Fair enough - but my main point is that the frame can be navigated. What
> happens when someone does this:
>

> <iframe mozapp="manifesturl" mozwidget="mywidget1" src="http://foo.com/� >

>
> (Does the app get embedded, because it contains a widget? That seems
> like a dangerous side effect that devs might not be aware of.)

I think we need to make sure that widget iframes cannot be navigated to
a different @src by their embedders.

Cheers,
Ehsan

[Evelyn Hung]

----- Original Message -----

> On 21 May 2014, at 6:33 am, Ben Francis < bfra...@mozilla.com > wrote:

> > On Fri, May 9, 2014 at 10:07 AM, Gary Chen < gc...@mozilla.com > wrote:
>

> > > I've just created a wiki page for Widget API[1], will add more
> > > information
> > > later.
> >
>
> > > Any suggestions are welcome and looking forward to enrich the wiki page.
> >
>
> > > [1] https://wiki.mozilla.org/WebAPI/WidgetAPI
> >
>

> > Again, is there any reason why...
>

> > <iframe mozapp="manifesturl" mozwidget="mywidget1">
>

> > can't be...
>

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

> > http://foo.com/widget.html ”>
>

> The difference between the two, is that in Jonas’ proposal above, the widget

> author decides what the launch URI is. But in your proposal, the embedding
> page does.

> TLDR: I don’t think we should mix apps, and widgets. Apps should either be

> widgets, or apps not both.

> Because if we allow framing a widget which is some page inside an app, the
> parent can just set the src attribute of the iframe to be some other page in
> the app and it has effectively embedded the app.

I agree this point and the design of framing a widget.

Following the logic comes to one question - so why we allowed app embedder to specify src attribute? What if the src is set to a different origin from mozapp attribute, like:

<iframe mozapp="app://foo.gaiamobile.org/manifest.webapp" src=“http://bar.com/index.html”>

Luke tested it before, and he told me the behavior looks as the mozapp attribute was not assigned, and there is no error message in log.

> > Will the existing "browser" permission become the "safe" browser API or the
> > "unsafe" browser API?
>

> I was expecting a new permission and new api to be the ‘safe’ one.

I was thinking when a embedder requires embed-widgets permission, it can only use the 'safe' browser API, so we can force widget container to follow the rule. But we should document it pretty clearly if we want to do so.

Regards,
Evelyn

[Gary Chen]

comment inline.

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

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

----- Original Message -----
> From: "Evelyn Hung" <eh...@mozilla.com>
> To: "Paul Theriault" <pther...@mozilla.com>
> Cc: "Ben Francis" <bfra...@mozilla.com>, "Gary Chen" <gc...@mozilla.com>, "Ehsan Akhgari" <ehsan....@gmail.com>,
> "Marco Chen" <mc...@mozilla.com>, "Gene Lian" <cl...@mozilla.com>, "dev-webapi" <dev-w...@lists.mozilla.org>,
> "Ehsan Akhgari" <eh...@mozilla.com>, "Jonas Sicking" <jo...@sicking.cc>
> Sent: Wednesday, May 21, 2014 12:49:16 PM
> Subject: Re: Expose 'embed-apps' to privilege.
>

I have already filed a bug for this issue.
https://bugzilla.mozilla.org/show_bug.cgi?id=1010011
FYI

[Paul Theriault]

On 21 May 2014, at 2:49 pm, Evelyn Hung <eh...@mozilla.com> wrote:

>
>
> On 21 May 2014, at 6:33 am, Ben Francis <bfra...@mozilla.com> wrote:
>
>
> On Fri, May 9, 2014 at 10:07 AM, Gary Chen <gc...@mozilla.com> wrote:
> I've just created a wiki page for Widget API[1], will add more information later.
> Any suggestions are welcome and looking forward to enrich the wiki page.
> [1] https://wiki.mozilla.org/WebAPI/WidgetAPI
>
> Again, is there any reason why...
>
> <iframe mozapp="manifesturl" mozwidget="mywidget1">
>
> can't be...
>
> <iframe mozapp="http://foo.com/manifest.webapp" src="http://foo.com/widget.html”>
>
> The difference between the two, is that in Jonas’ proposal above, the widget author decides what the launch URI is. But in your proposal, the embedding page does.
>
> TLDR: I don’t think we should mix apps, and widgets. Apps should either be widgets, or apps not both.
>
> Because if we allow framing a widget which is some page inside an app, the parent can just set the src attribute of the iframe to be some other page in the app and it has effectively embedded the app.
> I agree this point and the design of framing a widget.
>
> Following the logic comes to one question - so why we allowed app embedder to specify src attribute? What if the src is set to a different origin from mozapp attribute, like:
>
> <iframe mozapp="app://foo.gaiamobile.org/manifest.webapp" src=“http://bar.com/index.html”>
>
> Luke tested it before, and he told me the behavior looks as the mozapp attribute was not assigned, and there is no error message in log.

When you navigate an app window off its origin, it is no longer considered part of the app. If you navigate back to the app origin, you are considered part of the app again. By the way, mozapp doesn’t do anything is mozbrowser isn’t set.

[Paul Theriault]

On 21 May 2014, at 3:47 pm, Gary Chen <gc...@mozilla.com> wrote:

> comment inline.
>
> Best regards
> -------------------------------------
> Gary Chen 陳柏宇
> Mozilla Taiwan
>
> T: +886-2-87861100 # 206
> M: +886-975151712
> gc...@mozilla.com
>
> ----- Original Message -----
>> From: "Evelyn Hung" <eh...@mozilla.com>
>> To: "Paul Theriault" <pther...@mozilla.com>
>> Cc: "Ben Francis" <bfra...@mozilla.com>, "Gary Chen" <gc...@mozilla.com>, "Ehsan Akhgari" <ehsan....@gmail.com>,
>> "Marco Chen" <mc...@mozilla.com>, "Gene Lian" <cl...@mozilla.com>, "dev-webapi" <dev-w...@lists.mozilla.org>,
>> "Ehsan Akhgari" <eh...@mozilla.com>, "Jonas Sicking" <jo...@sicking.cc>
>> Sent: Wednesday, May 21, 2014 12:49:16 PM
>> Subject: Re: Expose 'embed-apps' to privilege.
>>
>> ----- Original Message -----
>>

> I have already filed a bug for this issue.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1010011
> FYI

This is strange behaviour, but I don’t think it should raise an error. After all, there is nothing stopping an app from navigating away from its origin. Content that is not the same origin as the app will not get any app permissions so there isn’t really any security issue I think.

[Gary Chen]

> > So instead of apps being allowed to declare certain pages as widgets, how
> > about we just allow apps to declare themselves as widgets like:
> >
> > {
> > name: "MyWidgetApp2000",
> > ...
> > widget:
> > {
> > positions: ["homescreen", "lockscreen"]
> > },
> > }
> >

> > Widgets can have many different ‘widget pages' within and the embedder

> > choose which one, just by setting the URL
> >

> > <iframe mozapp="http://foo.com/manifest.webapp" src=“widget.html”>
>
> Er I mean absolute,
>

> <iframe mozapp="http://foo.com/manifest.webapp"
> src="http://foo.com/widget.html”>
>

> but then you hit the issue you raise in the next post (packaged apps not
> having a URI.
>
>

As I know, packaged apps have url with "app://" protocol.
Like this:
<iframe mozbrowser="true" remote="true" mozapp="app://camera.gaiamobile.org/manifest.webapp" src="app://camera.gaiamobile.org/index.html" data-url="app://camera.gaiamobile.org/index.html" data-frame-origin="app://camera.gaiamobile.org" >

>
> >
> >
> >>
> >> I see this eventually becoming...
> >>

> >> <webview manifest="http://foo.com/manifest.webapp"
> >> src="http://foo.com/widget.html”>
> >>

> >> and it would be nice not to have to add another vendor-prefixed attribute.
> >>
> >>

> >> Will the existing "browser" permission become the "safe" browser API or
> >> the "unsafe" browser API?
> >
> > I was expecting a new permission and new api to be the ‘safe’ one.
> >
> >
> >

[Francisco Jordano]

On 21/05/2014 01:15, Paul Theriault wrote:
> On 21 May 2014, at 6:33 am, Ben Francis <bfra...@mozilla.com> wrote:
>
>> On Fri, May 9, 2014 at 10:07 AM, Gary Chen <gc...@mozilla.com> wrote:
>> I've just created a wiki page for Widget API[1], will add more information later.
>> Any suggestions are welcome and looking forward to enrich the wiki page.
>> [1] https://wiki.mozilla.org/WebAPI/WidgetAPI
>>
>> Again, is there any reason why...
>>
>> <iframe mozapp="manifesturl" mozwidget="mywidget1">
>>
>> can't be...
>>

>> <iframe mozapp="http://foo.com/manifest.webapp" src="http://foo.com/widget.html�>
> The difference between the two, is that in Jonas� proposal above, the widget author decides what the launch URI is. But in your proposal, the embedding page does.
>
> TLDR: I don�t think we should mix apps, and widgets. Apps should either be widgets, or apps not both.
I understand that concern about separating apps and widgets, but we have
an interesting use case.

Right now in dialer we have a embedded view of the contacts app, that's
the only reason why we had to put both logical apps under the same
physical app (manifest) and use the infamous entry points.

Perhaps we could save this situation and display contacts inside the
dialer as a widget, then we could have completely separate apps.

Could be a bit tricky (specially displaying a whole app within another
app could be confusing or even malicious), but pretty handy to solve
situations like this one.

>
> Because if we allow framing a widget which is some page inside an app, the parent can just set the src attribute of the iframe to be some other page in the app and it has effectively embedded the app.
>
> So instead of apps being allowed to declare certain pages as widgets, how about we just allow apps to declare themselves as widgets like:
>
> {
> name: "MyWidgetApp2000",
> ...
> widget:
> {
> positions: ["homescreen", "lockscreen"]
> },
> }
>

> Widgets can have many different �widget pages' within and the embedder choose which one, just by setting the URL
>
> <iframe mozapp="http://foo.com/manifest.webapp" src=�widget.html�>

>
>
>> I see this eventually becoming...
>>

>> <webview manifest="http://foo.com/manifest.webapp" src="http://foo.com/widget.html�>

>>
>> and it would be nice not to have to add another vendor-prefixed attribute.
>>
>>
>> Will the existing "browser" permission become the "safe" browser API or the "unsafe" browser API?

> I was expecting a new permission and new api to be the �safe� one.

[Ehsan Akhgari]

Do you expect what we're discussing here to be inadequate for that use case?

[Francisco Jordano]

On 21/05/2014 14:39, Ehsan Akhgari wrote:
>
> Do you expect what we're discussing here to be inadequate for that use
> case?
>

Nope, actually just wanted to highlight a possible use case.

Cheers,
F.

[JOSE MANUEL CANTERA FONSECA]

El 21/05/14 15:41, "Francisco Jordano" <fran...@mozilla.com> escribió:

FYI we are tracking that work on bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1013810

>
>Cheers,
>F.

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