On 17/03/12 00:08 AM, Ben Francis wrote:
The Open Web Apps team has proposed a model very similar to the Chrome Web
Store model with three important differences:
(It's worth stating that in the goal/objectives/mission...)
1) There shouldn't just be just one web app store run by one corporation,
anyone should be able to run their own web app store and users should be
able to install apps from stores they trust, without the intervention of
Mozilla or anyone else.
2) Web app developers should be able to list their web apps in multiple app
stores and even host their own apps on their own web server and have a
direct relationship of trust with the user.
Which probably means they need a net-centric identity and brand system.
In this sense, the identity would likely come from a private-key-pair
of some form as a handle (the common ones are x.509 and OpenPGP but
there are others). The brand would come from the name the developer
chooses, their other apps and the sum of the direct relationships they
have with their users.
There is an essential tension between the brand of the store and the
brand of the developer, best seen from examples. People buy from the
Apple store because they know Apple's brand, and it is relied upon not
to sell them stuff they don't want. They feel somewhat less certain
about Google's brand, which has explicitly loosened the controls... so
there is a perception that what they buy in the Chrome store isn't as
safe - they have to look after themselves. So they put more trust in
other brands.
The alternate brands they look to for trustworthy decisions are friends
- download what some mate has - and the net - reviews, columns, blogs.
By saying that app developers need to be able to move between stores,
this takes the emphasis off of the store brand (that worked so well for
Apple) and puts the pressure on other brands ... including and
especially developer branding.
If we look at say Microsoft Word, the brand of Microsoft is all people
need to make their buying decision. So as long as that brand cannot be
attacked, the developer can sell the product happily across different
stores.
so that would lead to these things:
1. all developers have/are a brand
2. they can attach that brand definitively to their product
3. all shops can technically at least support the products and brands
4. supporting things that enable the other brand channels to work (by
this I mean ways for mates to pass reliable links back and forth, and
for blogs/columns/reviews to past in articles).
From where I sit it seems that some form of brand/id/public key/signing
technology is needed.
Surely there should be no central authority for permissions requests other
than the user?
ah - yes. but are the users technically competent to evaluate the
safety of the code? no, they're not. they haven't got time. so
whilst the word "permissions" is the wrong word to use, the concepts
in this section are still kinda sound.
To be honest, other than verifying that an app developer is who they say
they are and displaying this verification in the app description, I'm not
sure how feasible it is for the app store to verify that a web app (which
has a server-side component) is safe without having full access to the
entire source code of the app and checking every change that's made to that
source code. I could be wrong but this seems to me to be more of a
contractual issue of trust between the owner of the store store and app
developers than a technical one.
At a technical level, yes. There are contracts, clauses, etc, between
various of the parties.
But at the human level, the average customer just follows brand and
recommendations based on brand. This is the great simplifier. E.g.,
most users of Firefox do whatever is presented to them by Mozilla,
rightly or wrongly. They trust in the brand of Mozilla to more or less
get it right, or not so wrong as to be disastrous. (Indeed, for much of
Firefox's life, there wasn't really a proper agreement, and that
agreement or contract is still quite light and boilerplate.)
This is seen in the permissions - relatively few users adjust
permissions as delivered. Instead they trust in the brand.
So, following this along to its architectural import: ignore the
contracts for now, and think how to allow the brand of the developer to
successfully attach to the product and on the user's privileged space.
iang
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security
