Hi
On 10/07/13 10:45, Antonio M. Amaya wrote:
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? ;)
Yes, because in this way it becomes a Web feature, not a developer concern.
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.
Let's discuss this later on this answer. After our off-line conversation
I see the problem now.
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.
You could sign the hash then. There are no further problems here.
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).
Important thing is that he does not loose anything. And we drop the
developer concern about packing the application. So, you, as web
developer, only worry about working in your web application, then
publish a list of files to allow off-line mode and let The Web do the
hard job (when saying The Web I'm referring indeed to User Agents,
servers and HTTP protocol).
Of course, a drawback of this approach is that you need not only a
server but a domain name too.
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).
Ok, this is part of the former discussion. But we can simply not allow
load resources from the Internet.
Only remarking, if we allow this auto-packing , then we are encouraging
web development and adding the packing as an option.
Best!
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
