On Mon, May 21, 2012 at 4:29 AM, Gervase Markham <g...@mozilla.org> wrote:
> On 17/05/12 19:24, Fabrice Desré wrote:
> >> Could the team explain the purpose of this value? What security concern
> >> prompted its inclusion in the manifest format?
> >
> > I'm not part of the apps team, but I guess the purpose is to prevent
> > rogue stores to sell apps without the author consent.
>
> What exactly does that mean? What is a "rogue store"?
>
> Is the problem that stores which list apps have no obligation to
> actually pay the app author anything?
>
More specifically, we don't facilitate payment so any app owner that is
actually having people buy their app needs to enter into a business
relationship with the store. A new store will need to enter into business
relationships with however many paid apps they actually want to list. This
is a high bar for a new store, but there's no real way around that. That
said, of course an app could still refuse to work once you've installed it
from a store that isn't authorized to sell the app – the advantage of
installs_allowed_from is just to halt the process a bit earlier.
For free apps it's hard to come up with a good use case besides a kind of
blacklist, and yes, using a whitelist to bar just one store is kind of
obstructionist.
> If this is the case, surely a blacklist ("installs_forbidden_from")
> might work better?
>
I think the rogue store fear is more a concern about people standing up
quick sites with good SEO (or more likely fraudulently good SEO, i.e.,
misdescribing apps) and selling apps, making money until people catch on
and then doing it again on another name. Individual app authors are going
to have a hard time maintaining a blacklist in this situation.
(Potentially we could maintain a global blacklist.)
> Have we changed our position on wanting there to be multiple competing
> stores, or not? If we have not, then how do we envisage it working in
> practice?
>
> Does each store need to have a relationship with the author of the apps
> it lists? I was under the impression this wasn't going to be necessary.
>
Payment without a relationship won't really work.
If someone wanted to provide payment relationships for multiple stores, it
would be possible to do so through various proxying techniques (where the
payment handler actually did all the "real" installs). But that's the
let-a-thousand-stores-bloom model, which I don't think we are expecting.
If it does happen (intranet stores being one possible reason it would) then
we figure out new ways to support it.
All that said, the way the payment flows are working out it's not a great
experience – actual "installation" only happens at the end of the flow, and
though a well-implemented store can try to detect failed installation and
roll things back, it's not actually a particularly helpful time to fail.
The app can always refuse to open, and I'm not sure install_allowed_from
provides a much better experience than that. If an app could do a kind of
preflight check before installation that would be better and more general,
I think.
_______________________________________________
dev-webapps mailing list
dev-webapps@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps
