Hey all.
You know, at the risk of being the discordant voice here, I don't see
what the issue with packaged apps is. It's not like you're required to
use packaged app if you want do develop a non special-api-using app. You
can just develop the app as you would normally, host it somewhere, test
it that way and then, after you've finished developing it, if it's
mostly static content (static HTMLs, JSs and images) then you have the
*option* to package it so your users can use it without having a network
connection. You don't have to do it, though, it's your decision. If you
prefer not to package it, you can just distribute it as a hosted app.
Oh, and the cool thing is that so long as you've only used relative URIs
on your app, you won't have to change a single iota to change it from a
hosted app to a packaged app.
So, for normal apps, I don't see having packaged apps as a bad thing.
It's an extra option, and having more options is good on my book. I
don't believe in forcing people into any vision of what the web should
be, and what is webby and what isn't. The web will be whatever people
make of it. If packaged apps are useful they will prosper and grow, if
they're not, they'll shrink and die. And that's good.
Now, for privileged app, that's another problem altogether, and
something that doesn't actually have a close relative on the existing
web. At Firefox OS we're exposing some APIs to content that are or can
be dangerous if used incorrectly or with bad intent. And to do that,
we've taken onto us the responsibility of telling the user, hey, it's ok
if you allow this app to access your contact because WE have checked it
and WE have seen it will treat your data with the due respect. We cannot
do that unless we ensure that the content of the app we've examined is
*static*. We could give the option for that content to be served
remotely, along with the signature of every piece of code we download
(raw hashes as Salva said below will just not work). But the server
cannot serve dynamic content, cause otherwise the signatures won't be of
any use. And I'm not even sure if even that would be enough, since a
developer could send to be signed more content than he actually uses...
Anyway...
On that model, every time a developer wanted to change a single comma on
his code he would have to resend all the content (and not just the code
he just changed, because of possible interactions) to be reexamined.
Then a trusted third party (cause I, as a user, love developer but don't
trust them as far as I can throw them) will sign the data again, and
send the signatures back and only then the developer can change one set
of static content for another set of static content.
What does he win with this model, compared with the current one? Just
the actual packaging of the app. What do end users win? Hmm... without
any way of local caching of content, they actually *lose*. They'll have
to download the static content over and over and over. Oh, and the
signature will have to be re-verified every time the content is loaded
(while actually is only checked at install time).
Going away from a packaged/controlled environment for privileged app
will make harder to actually trust them. The way I would actually like
for us to go is to, slowly, start opening some APIs that are currently
certified only to be privileged, so more and richer third party apps can
be added to the ecosystem. And I don't see that happening if we relax
the current trust/security model.
Best regards,
Antonio
On 09/07/2013 16:58, Salvador de la Puente González wrote:
Hello
I want to say I totally support the ideal of removing packaged apps.
INMHO, I think we need a way to move from on-line to off-line
applications in a transparent way in order to make "installation"
process almost trivial. For this purpose some mechanism like offline
cache is necessary. If current implementation is bugged, let's find a
better alternative.
For the problems exposed by Jonas, I'm not an expert but some of them
can be easily addressed:
On 08/07/13 23:31, Ben Francis wrote:
In his email, Jonas proposed the following requirements for trusted
apps:
1. The ability for a trusted party to review an app and indicate some
level
of trust in the app (or potentially in the app developer).
With a list of downloadable content to be installed (some like the
Offline Cache), a third party could retrieve a version of the software,
then review it.
2. A mechanism for signing an app to verify that the app actually
contains
the content that was reviewed.
With a digest algorithm based on the content of each file the third
party and the User Agent could compute the same signature and see if it
matches. I have in mind some sha1-based like in Git. At least, all is
about content.
3. Use of a minimum CSP policy for all pages of an app to ensure only
the
reviewed code runs.
Sorry but I don't understand the problem here. I can currently load an
external script from a packaged application and run its code.
4. A separate data jar for local data to ensure a compromised web
site can
not write to the local data of an app to alter the way it behaves.
If the UA receive an update order for the Offline Cache of a determined
App, it can perform another digest and sent to the third party in order
to see if the new code has been reviewed. Maybe I did not understand
what is a compromised web in this context or how it could be a hazard..
5. A separate origin for the resources of an app so that the app can
not be
tricked into running un-reviewed code from the same origin with
escalated
privileges.
Same as above. With the digest mechanism you can say if the version the
third party reviewed and the device version differs, then ask the user.
If you think the digest process delays the application execution, it is
true but you can cover this time by adding it to the
"installation/update process".
Maybe I'm very naive about security so if you can clarify me some
aspects I did not take in count, I was very pleased to read about.
Best!
________________________________
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
_______________________________________________
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
________________________________
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
_______________________________________________
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
