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".
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.
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.
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.
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.
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
