On 8/28/14, 6:00 AM,
quick...@gmail.com wrote:
> Hi all,
>
> I just binge-read most of the threads in the group, so it's possible I may be confusing a few details on what was just a suggestion at the time, and what's being currently considered to be implemented.
>
> Most of my opinions and concerns have already been voiced by others, so I'll just skip those, because it seems those have all been taken into account already of what seems to be the "more accepted" proposal. As a developer, there are however a few things that I want to give voice to that I haven't seen mentioned yet.
>
> 1) I haven't seen any reference anywhere about test builds: alphas, betas, rc's and pretty much anything that, when uploaded, will appear in the development channel. I assume they would be signed as well, following the same process as normal releases, but that really should be made more obvious.
That's a good question, since it's an edge case that wasn't covered. If
we follow the same policy we apply on AMO now, you can only upload to
the developer channel if your add-on is already Fully Reviewed. Those
versions don't go through review, and they would also be automatically
signed. However, we need to further discuss this case since it can be
considered a vulnerability in the system.
> 2) One common scenario that happens for me: user reports a bug, I can't reproduce the exact same bug but only something similar, or even not at all; I make some fixes; I reply to user "Try this test build and let me know if that works.".
>
> Usually I upload that package as a test build to AMO (like in the above point) and link the user to it. But that is a commodity, AMO shouldn't be made so it's a necessity that we must rely on. For example, if this signing enforcement was already in place, development (bugfixing) of one of my add-ons would have essentially stopped, as AMO has been on the fritz for the last month and I haven't been able to reliably upload anything for weeks.
>
> On the other hand, I (you/we) can't expect regular users to install any firefox developmental build in this situation just to test a dev package of an add-on. Not only is it an incredible hassle for them that they're not used to, it can be scary to see messages like "Be careful, as this build can be unstable and does not provide protection against unwanted apps." and the such. I don't see most normal users with the (conscious) confidence to do something like this.
>
> In short, all of the "developer work and hassle" being discussed seems to be centered on the developer. But sometimes the end-user is a part of this work too. That also needs to be taken into account!
Just like in the non-AMO case, AMO developers will have the option to
request certificates to sign their add-ons. The idea is to charge for
this service, but we can probably do something like offer them for free
to developers of fully reviewed add-ons on AMO. The only other option
would be to ask users to use the testing version of Firefox, which can
be a hassle like you mention, but hopefully won't be terribly
inconvenient to do.
> 3) Another issue that's still not clear to me is the case of personal add-ons. I'm not sure of how enterprise policies work or would work, as this is not my case. My case is I do have a couple of personal add-ons that, because of their specificity, would be of no use to anyone else, so uploading them to AMO would be useless.
>
> Would I still need to upload them to AMO in order to have them signed? I'm against this of course, personally I don't care if their code is public or not, but unless AMO has some kind of "make add-on hidden" feature that we can turn on, I don't think many people would want to make their code public. And even with that kind of hidden feature, others have already noted the "need for secrecy" that some enterprises would require, which even uploading their code anywhere would be going against.
>
> Which brings me to, would this kind of add-on be considered non-AMO hosted, and would I have to pay the $5 (or whatever that ends up being)? That's also unacceptable, at least in my case, I'm not going to pay to use something that I have made myself. That's just a human basic principle, especially when it's not supposed to "meet mozilla's standards", but mine only (also a valid point for enterprises btw). We would be forced to give up the securities these policies are supposed to bring (by using a firefox developmental build) just to use our own little special add-ons, this is a very inconsiderate tradeoff you would be imposing. (Again, personally I don't care and could use the developmental build for personal use, as I know what to avoid on the web so I have close to zero problems with these malware issues, but I'm against the principle.)
Yeah, your options in that case would be to either get a (non-free in
most cases) self-signing cert, or use the developer build of Firefox.
For enterprises I don't expect it to be a problem to make a one-time
payment to sign private add-ons. For users with the technical skills to
make add-ons just for themselves, I think using the development build
should also be agreeable.
Also, as I've argued before, we need to make reasonable exceptions for
the self-signing certs since we don't want to kill a potential long tail
of non-AMO development.
> 4) As a more general concern, I honestly don't see this making a lot of progress against unwanted add-on installations, whether they're malware, greyware or however you want to classify them.
>
> Nothing stops a blocked/banned user from using a proxy/going to a friends house/using a high techy-techy IP scrambler/whatever to create a new account, repack and reupload their add-on with new valid automatic certificates and start the "be bad/user report of badness/investigate/terminate" cycle all over again. This is also valid for non-AMO hosted add-ons, as someone (sorry, I can't find that post at the moment) said, there's money in this and a lot of it. Someone who's made a lucrative effort in coding a malicious add-on is probably not above pretending to be someone else and acquiring new certificates for five bucks (and produce a few more lucrative weeks before anyone notices again), regardless of the install process they choose.
It's true that we can't create a completely effective solution for this,
but we don't need to. One of the important changes this brings in is a
level of accountability that we don't have now. There are many add-on
IDs in the wild that we have no idea what they are. There's plenty of
evidence of randomized add-on IDs (different ID per install), and
malware using add-on IDs of known add-ons. With this system we will at
least be able to track the origin of a malicious ID and deal with it and
all IDs created with that cert. This will also significantly increase
the difficulty of creating and distributing new add-on IDs, and allow
developers to really own their IDs to prevent abuse.
Also, in the cases of non-malicious non-AMO add-ons, we will be able to
find the developers more easily in case there are problems with their
add-ons, which is a problem we have to deal with regularly.
> Sure it would be more difficult to do it than it is now, but if it still allows money to be made with these activities, they aren't going to diminish by any significant amount. This would only bring an increased degree in maintenance, of the certificates and of AMO and its tools in general.
Yes, there's certainly an additional cost in maintenance, but I think
it's worth it because of the benefits I mention above.
> I don't mean to sound discouraging, it's just an honest opinion. And note that I'm not against the principle of signing either the add-on or the user himself. But in the end, I only see it as a sort of glorified whitelist, that would be as effective as the current blocklist system in place, with all these added "side-effects" and compromises on all sides that I don't think will bring enough benefit so that they would be justified.
The blocklist has served us well, but it's showing its age and needs
major improvements. To deal with the way add-on malware is created now,
we need something more sophisticated, which is why we're going with signing.
> But it's just my opinion, and of course if/when this is implemented, I look forward to being proven wrong. :)
>
> Lu�s Miguel
>
Thanks for the feedback!
Jorge