On 10/07/2013 10:09, Salvador de la Puente González wrote:
Hello!
On 09/07/13 23:13, Antonio Manuel Amaya Calvo wrote:
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, of course but it could be great if I, as web developer, only add a
file saying something like "hey, if you want this application to work
offline, take these files and pack them together". This is said to the
user agent so I'm doing nothing more than declaring the structure of
my package and the the UA pack it "automagically".
So you just want to save the time to make the zip yourself? ;)
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.
With the approach above, it could be the same. :)
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.
I agree it is an extra option, the problem raises when the on-line web
is the extra. At the end, and despite we move to an always-connected
world, the real Web is the Online Web.
Well, if or when we arrive to that always-connected world then the
packaged apps will quietly go away by themselves cause they won't be
useful. Meanwhile, I for one have data limits on my mobile connection,
not to mention the times when connection just isn't available. And I
would like to keep using the apps that don't actually require connection
(games, book readers, whatever). Currently packaged apps fill this need.
Now, I don't actually mind if the developer makes the zip himself or if
he just instructs the UA somehow to download/perma-cache the fixed
resources. But as I said before, this affects mainly the non privileged
apps workflow.
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).
Why? If all is about content and I review the content, trust it and
make a hash for him, any attempt to modify the code will alter the
cryptographic hash making the validation algorithm fail.
Because hashes by themselves give integrity, not security. Why? Cause if
I can change the content and the hash is stored with the content, I can
change the hash also. And just trusting hash by origin (I trust this
hash because I downloaded it from the store while I downloaded the
actual content from the developer site) could work but it links
completely your security to the security of the third party (market)
download site.
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.
But that is how it's working now! If I made a syntax error error in my
v1 application and it lands in the market and I need to fix it, I need
to send an update to the market. A v2 application so it need to be
reviewed again. How to review is responsibility of the third party. It
should keep a code repository an see only the differences and
automatic tools can decide when a change need another human review or
not.
Yep, that was my point exactly, as stated below. That a developer won't
gain anything with this model compared to the existing one (besides not
having to create the zip file).
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).
Just the same with the current approach. The user need to download the
"application update" and the sign must to be recalculated again.
No. If we download resources remotely every time we use them (or if we
can download them remotely) then we have to recheck the signature every
time a file is accessed/downloaded. With packaged apps you check the
signature only at install time (be it first time install, or update).
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.
I like the current security model, I only want some "auto-packing"
method that make the "off-line site" an option, not the "on-line site"
because "on-line" sites are the Web.
Cheers!
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
[email protected]
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
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
