Dave Townsend schrieb: > Gervase Markham wrote: >> Dave Townsend wrote: >>> Some examples that I have heard (or experienced myself): >>> >>> Long review times leading to slow updates for the users. >>> Dissatisfaction with the new Sandbox. >>> Poor download statistics. >>> Restrictions on what kind of add-ons they will host. >>> Restrictions on the application compatibility you can set. >>> Not appropriate for the market of the add-on (site specific add-ons >>> etc.) >> >> OK. So instead of using our resource to fix these things, we are >> fixing the problem that they can't afford $40 for SSL hosting? > > I think it's foolishness to think that any one add-ons hosting solution > is going to be right for everyone. AMO is probably about what it needs > to be, right for 95% of people and extra investment in making it right > for the other 5% is probably more work than making the updates system > right for those other 5% of people. > >> a.m.o. isn't the best thing, but it's free. Hosting your own with SSL >> isn't free, but it gives you more flexibility. I really think the two >> options available here cover all the bases. > > It doesn't cover those that won't pay for the SSL and don't want to host > on AMO. Yes there are people saying they are in that situation. Numbers > are difficult to guess at though. > >> We seem to be planning to spend a great deal of resource to enable >> people to not use our infrastructure, and also not spend $40. Is this >> really cost-effective? > > At this stage there's been no decision on which way to go. I'm hoping to > draw this discussion to a close in the next day or so and then post some > kind of conclusion and then the decision can be made. In order to do > that I was really hoping this thread to come out with some suggestions > on my initial proposal. So far I've only seen one post which suggests > that it can work. Given that I need to look at just how much work it > would be to implement before we can decide if it is worth implementing > it in order to continue to support those who need it. > > Dave
Addressing gerv: Just to give a counter example for "these two options cover all bases": We already have a "nightlies" repository for dTa, incl. an update.rdf always pointing to the latest nightly. The audience for this is obviously pretty limited. I'm not willing to spend more effort and/or money on it just to get stuff on AMO sandbox (hard to use) or to get a cert and setup an SSL server. Oh, and we will likely publish 2 betas before 1.0 and additional RCs... Not suitable for AMO either really. Another example: I have some extensions I give to buddies, instructing them not to share those as I want to control the distribution. Nothing illegal, however. One is e.g. for a small private forum; maybe 100-150 folks using it. Not suited for AMO obviously; I would go nuts if I had my search results "polluted" by useless-to-me site-specific extensions (I actually hate all these xy-toolbars, or xy-helpers, that are already there and I'm not willing to add to that problem). Unless this drastically changes AMO is not an option, and SSL certs aren't too. And what about new/prototype extensions not yet ready to be consumed by general public? Do you really want to wipe out these use types (and therefore a good amount of extensions) and limit FX/TB/SM/XulRunner as platforms for innovation just to introduce a lazy-devs workaround to a theoretical and practically hard-to-exploit MITM attack vector? Now this would sound like the overreaction and misguided risk management described by Bruce Schneier in that essay eric.jung copied over at m.d.extensions. Therefore I agree with Dave that this would be foolishness, not to say destructive. Addressing Dave's demand for proposals: If there is no workable solution then don't implement one. It isn't like there are armies of evil folks out there lurking on wifi hotspots just to intercept update requests. Furthermore the first installation could be hijacked as well, so until this is addressed the problem persists anyway. Make it opt-in, not must or opt-out, if there is no solution in reach which would satisfy all requirements. Try to promote workable solutions, evangelize authors, to use what is available already (extension code signing, SSL install/updates). Most if not all high-impact (or better popular) extensions will likely implement secure updates, especially if they get some guidance from mozilla. Those are the ones with the highest risk of being "attacked" anyway. That community program that gives away software/hardware could be extended to provide popular extensions with (money for) code-signing certificates... Maybe make it easy for authors to add their own self-signed cert that might check updates. Thinking of a fuel-esque way to easily add those certificates, and tools that make creating certs and signing more easy (all those "help me signing that xpi" threads clearly indicate that it is not easy enough yet). Maybe even allow to use self-signed certificates for installation, then asking the user to import the certificate if he trust it. (Admittedly this raises the question if the users will understand such confirmation-dialog and not just OK-it away). My observation is that none of the distribution systems solved this trust-issue fully yet. E.g. DPKG/RPM will warn you but still allow you to install unsigned/unknown-key-signed packages. Nils _______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
