All,

Had a couple of questions regarding the apps security model (from the
deprecated https://wiki.mozilla.org/Apps/SecurityDetails and the
latest https://wiki.mozilla.org/Apps/Security) wiki page. Some of them
might already have been discussed as part of the dev discussions, in
which case getting clarifications will help in keeping the wiki page
upto-date. Also, some of the questions below might be more closer to
how a certain functionality would work or what the user experience
would be. Please comment


Data stored per app
=================
1. If two apps can't see the cookies of each other, then what will be
the user experience when there is something like browserid or openid
support? In that case, will the user have to login on each site that
uses browserid?

Apps can't open each other
======================
2. In this case, how do app developers build separate 'apps' and
string them together. An example, developer builds an app that has
login to the corporate site. Then the developer builds another app
that gives access to corporate wiki. Developer wants to build a
work-flow with login and wiki. In this case, what is the best way
forward for the developer?

3. Related https://bugzilla.mozilla.org/show_bug.cgi?id=773060 - can
there be a mutual trust relationship built between apps that two
different apps can negotiate in a P2P way? Facebook says, I trust the
app from StackOverflow and SO's app says I trust the FB's app.
3.1  One way this can be achieved (at a high level and skipping a
*lot* of details) is by signing both the apps with each others'
certificates , thereby creating a mutual trust. Allowing application
signing might provide users a bit more trust. The signing doesn't have
to be from a central authority (like Apple or Symbian does), but can
be from the application vendor.

Sandboxed permissions
===============
4. If an app launches maps.google.com on the main window, and then in
an iframe (eg., user opens the maps, then selects one area for
restaurants. The second one opens in an iframe)., the user will need
to accept the message for location tracking twice. Wouldn't it be
easier if we provided a way on the first access that there are 'n'
number of accesses (can find out from the iFrame src in the code) and
if the user wants to access them.
   4.1 And by clicking on the top right hand corner the user can turn
off location-tracking for the whole app or the active frame. This way,
the location-tracking status is available always and the user can turn
on/off with one keypress
   4.2 Or on the location-acceptance-message, there can be a checkbox
that says, accept decision for all the access of maps.google.com by
*this app*

5. Feature suggestion: Also, whenever a location is being tracked by
an app, suggest an icon on the top right-hand corner (left-hand corner
based on localization) which visually represents that the location is
being tracked

Access property
==============
6. For the example given for the 'createonly' access to the contacts
API, would the reading of the contacts API in the case throw an error?
Will that error be bubbled up to the user? If not - shouldn't it be?
If so, will it be possible to 'statically' analyze this sort of a
violation when the app is published to the market-place?

7. Answer for the open question - I think any violation should be
bubbled up to the user - if permissions were changed dynamically?
Assuming that the permissions are stored in the manifest file, any
change to it, I believe is already notified to the user - no?

Delivery mechanisms
==================
Hosted apps
-----------------
8. Is it fair to assume that the onus of authentication (or any setup
steps) are left to the app-developer; since I expect that developers
would write one page for both the device and the desktop - and it
would 'automagically' get rendered appropriately

9. Not clear on the same-origin restriction. What does this mean -
'this restriction (of same-origin) is relaxed when the manifest app,
and *thus the app manifest* , is same-origin with the page that
requested the app to be installed'.
What is the difference between manifest app and the app-manifest? Is
there a separate manifest ap?

Packaged apps
----------------------
10. What would it take to have the UUID to become the home domain of
the app? Is that a future enhancement?

11. Open question: forbid the usage of the app:// URL in the iFrame of
a page - when the page is downloaded over the web (hosted app), but
allow it when it is a packaged app - is that what the question is
about?
If so, does this mean one app can 'host' another app (the sandbox
restrictions will still apply of course). If so, this will be good,
since component developers can build apps and other application
developers can include their components. For example, FB can build an
app, that also works as a component for other app developers to
include it in their iFrames

12. >We only know which store was used to install the app
How is this known? Is the UUID of the home-directory generated via the
store that the app was installed from?

13. Cross-origin-reads: I think it will help if an example is provided
in the wiki of what the developer needs to do if they want to enable
cross-origin-reads (say, to download some resource, like news, from a
remote website in the app).

14. Not sure what is meant by 'package has to be served with a
specific MIME type or has to be the same-origin with the page
installing the package'. Does the latter consider this scenario
User goes to Moz's marketplace -> Install app -> Something bad happens
on Moz's marketplace and the app is being downloaded from a malicious
site -> The installation will fail since the origin of the package is
not the same as the page installing the package
If this is so, then this logic should be part of the gecko engine
isn't it - since this will happen via the browser and that should be
doing this check.
Also, isn't that available for the addons that are installed on firefox?

Privileged apps
============
15. Suggestion: There should not be a 'remember my decision' for any
privileged API (or atleast this should be hidden behind a about:Config
sort of a permission setting)

16. The notes about the store ensuring that the bad / difficult things
are offload to the store - have they been implemented, or is the list
a suggested approach?

App Review
----------------
17. Would all the approved app-stores carry the same version of the
application? In the spirit of openness, I would think so, but I think
it will be good to add that in the wiki

Default CSP policy
------------------------
18. Would the evaluation of the policies provided be done manually or
will it be a combination of jslint + (some other tool) + manual
review?


Thank you
Gangadhar
(irc: gnittala)
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps

Reply via email to