info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
whitelisting legitimate unlisted extensions
591 views
Skip to first unread message
Dan Stillman
Sep 15, 2015, 2:45:21 PM9/15/15
to mozilla-addons-...@lists.mozilla.org
As I understand it, unsigned extensions now won't be disabled until
Firefox 43 and won't be disallowed until 44.
I'd like to ask that Mozilla use the extra time to reconsider the review
process for unlisted extensions and add the option to whitelist
unlisted, non-side-loaded extensions for automatic signing once it's
clear that they're legitimate.
Some context: I'm one of the developers of Zotero, which is one of the
largest and most complex Firefox extensions. Zotero has been developed
out of the same large research university for 9 years and was even
previously distributed by Mozilla itself in a campus edition of Firefox,
so there's no question as to our legitimacy. Our extensions are all now
signed — but only after a rejection, many emails back and forth, a delay
of many weeks, and AMO editors' eventually acknowledging that every
issue raised in the initial review was innocuous in context. (This
mirrored our experience when we distributed a version of Zotero on AMO
originally, and it's why we stopped.) Because of our use of js-ctypes,
nsIProcess, and other advanced features, we can't currently submit a new
version of any of our extensions without it going to manual review,
which means that there's a multi-day delay for any submission, even for
daily (well, previously daily) beta releases. Even if the review tools
gain the ability to ignore individual warnings in future reviews, as is
planned, the Zotero code base is large and complicated enough that most
updates would likely see us flagged again for manual review.
A few months ago on this list, I asked Jorge whether, since the stated
goal of the signing system is to prevent malware, an option for
whitelisting obviously legitimate extensions would exist, and he
suggested that it would [1]. That no longer seems to be the plan. He
said recently that they don't want to add a whitelist option [2], and he
informed us that Zotero "will probably have to go through manual review
every time it is submitted".
As I told him, we can't develop Zotero in that environment — Zotero is
mission-critical software for many people, and we need to be able to
release bug fixes immediately (meaning, if signing is required, via an
API) and put out daily beta releases to allow end users to test changes.
So something will need to change. People use our Firefox version because
it's more deeply integrated into the browser, but if the full version of
Zotero doesn't run in Firefox, three things will happen:
1) In the short term, we'll actively encourage all Zotero for Firefox
users to switch to the unbranded Firefox build with extension signing
disabled so that they can continue to use new versions as we release them.
2) We'll recommend that people who don't care about the tighter browser
integration switch to our standalone application and one of our
lightweight connector extensions now, removing the main reason a huge
number of people have switched to or stayed on Firefox over the years.
3) We'll abandon dedicated Firefox development over the next 12-18
months, since, even if WebExtensions gain support for everything we
need, which is far from clear, it won't be worth rewriting the full
extension after the XUL/XPCOM ban if we can't release it normally for
the standard Firefox build.
We don't want to do any of these things, but we won't have a choice. (A
popular third-party fork of Zotero used by legal scholars and
multilingual academics has already abandoned its Firefox version due to
the developer's inability to deal with the manual review system.)
Despite huge public opposition to this plan, Mozilla has insisted that
extension signing is necessary to combat malware. Well, fine, but then
make it about malware. Review recently added unlisted extensions and
unlisted extensions requesting side-load capability — those that might
actually pose the threat that Mozilla has repeatedly cited — and add
tools to make reviewing updates to those extensions easier. But allow
the developers of unlisted, non-side-loaded extensions who have
demonstrated that they're legitimate and take security seriously to have
their extensions signed automatically. If there's ever a problem — if,
say, we at Zotero decide to get out of the free, open-source academic
research software business and try our hand at malware — then block the
extension via the infrastructure that's now in place.
- Dan
[1]
https://groups.google.com/d/msg/mozilla.addons.user-experience/rS_07mU40vk/P_yJjfDAPpoJ
[2]
https://blog.mozilla.org/addons/2015/09/04/turning-the-queues-around-new-forum/comment-page-1/#comment-219554
Firefox 43 and won't be disallowed until 44.
I'd like to ask that Mozilla use the extra time to reconsider the review
process for unlisted extensions and add the option to whitelist
unlisted, non-side-loaded extensions for automatic signing once it's
clear that they're legitimate.
Some context: I'm one of the developers of Zotero, which is one of the
largest and most complex Firefox extensions. Zotero has been developed
out of the same large research university for 9 years and was even
previously distributed by Mozilla itself in a campus edition of Firefox,
so there's no question as to our legitimacy. Our extensions are all now
signed — but only after a rejection, many emails back and forth, a delay
of many weeks, and AMO editors' eventually acknowledging that every
issue raised in the initial review was innocuous in context. (This
mirrored our experience when we distributed a version of Zotero on AMO
originally, and it's why we stopped.) Because of our use of js-ctypes,
nsIProcess, and other advanced features, we can't currently submit a new
version of any of our extensions without it going to manual review,
which means that there's a multi-day delay for any submission, even for
daily (well, previously daily) beta releases. Even if the review tools
gain the ability to ignore individual warnings in future reviews, as is
planned, the Zotero code base is large and complicated enough that most
updates would likely see us flagged again for manual review.
A few months ago on this list, I asked Jorge whether, since the stated
goal of the signing system is to prevent malware, an option for
whitelisting obviously legitimate extensions would exist, and he
suggested that it would [1]. That no longer seems to be the plan. He
said recently that they don't want to add a whitelist option [2], and he
informed us that Zotero "will probably have to go through manual review
every time it is submitted".
As I told him, we can't develop Zotero in that environment — Zotero is
mission-critical software for many people, and we need to be able to
release bug fixes immediately (meaning, if signing is required, via an
API) and put out daily beta releases to allow end users to test changes.
So something will need to change. People use our Firefox version because
it's more deeply integrated into the browser, but if the full version of
Zotero doesn't run in Firefox, three things will happen:
1) In the short term, we'll actively encourage all Zotero for Firefox
users to switch to the unbranded Firefox build with extension signing
disabled so that they can continue to use new versions as we release them.
2) We'll recommend that people who don't care about the tighter browser
integration switch to our standalone application and one of our
lightweight connector extensions now, removing the main reason a huge
number of people have switched to or stayed on Firefox over the years.
3) We'll abandon dedicated Firefox development over the next 12-18
months, since, even if WebExtensions gain support for everything we
need, which is far from clear, it won't be worth rewriting the full
extension after the XUL/XPCOM ban if we can't release it normally for
the standard Firefox build.
We don't want to do any of these things, but we won't have a choice. (A
popular third-party fork of Zotero used by legal scholars and
multilingual academics has already abandoned its Firefox version due to
the developer's inability to deal with the manual review system.)
Despite huge public opposition to this plan, Mozilla has insisted that
extension signing is necessary to combat malware. Well, fine, but then
make it about malware. Review recently added unlisted extensions and
unlisted extensions requesting side-load capability — those that might
actually pose the threat that Mozilla has repeatedly cited — and add
tools to make reviewing updates to those extensions easier. But allow
the developers of unlisted, non-side-loaded extensions who have
demonstrated that they're legitimate and take security seriously to have
their extensions signed automatically. If there's ever a problem — if,
say, we at Zotero decide to get out of the free, open-source academic
research software business and try our hand at malware — then block the
extension via the infrastructure that's now in place.
- Dan
[1]
https://groups.google.com/d/msg/mozilla.addons.user-experience/rS_07mU40vk/P_yJjfDAPpoJ
[2]
https://blog.mozilla.org/addons/2015/09/04/turning-the-queues-around-new-forum/comment-page-1/#comment-219554
Mike Connor
Sep 15, 2015, 3:57:09 PM9/15/15
to Dan Stillman, mozilla-addons-...@lists.mozilla.org
Hi Dan,
Overall, I wouldn't assert that directly distributing malware is the sole
consideration in play. There's lots of software out there that I wouldn't
necessarily label as malware in itself, but violates our add-on guidelines
and best practices in many other ways that lead directly to users moving
away from Firefox. Security/privacy/stability problems are too common
still, as well as notable performance degradation, especially memory. The
long term solution is to build a better add-on system, and that work is
progressing in parallel. In the meantime, we're raising the bar in general.
That said, the main concern with any sort of proposal like this is that
even some of the most trusted add-on authors have broken their users' trust
in the past. (One key example was a security-centric add-on that started
injecting ads into content.) Any sort of program where we allow, in
effect, self-certification has to be able to address the following
questions in a concrete and effective fashion:
* Who gets to be on the list?
* What criteria are these developers evaluated against?
* What would prevent a developer from abusing this ability to sneak things
under the radar? We'd only know if someone discovered and reported a
problem.
* If abuse does happen, how would we fix the problems caused from that
abuse? (Blocklisting isn't a solution, more on this below.)
To reiterate something I've said before, blocklisting is not an effective
remedy post attack. It's a preventative tool to stop further spread, more
like a flu shot. Smart attackers go after blocklists, updaters, and any
other system that could shut them down. Even if they don't, removing the
add-on doesn't and can't undo all changes made by that add-on to the local
system.
It's a hard problem, and no one's got a convincing set of answers to those
questions. Suggestions welcome, as long as they will be effective and
reasonably fair.
-- Mike
> _______________________________________________
> addons-user-experience mailing list
> addons-user...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/addons-user-experience
>
Overall, I wouldn't assert that directly distributing malware is the sole
consideration in play. There's lots of software out there that I wouldn't
necessarily label as malware in itself, but violates our add-on guidelines
and best practices in many other ways that lead directly to users moving
away from Firefox. Security/privacy/stability problems are too common
still, as well as notable performance degradation, especially memory. The
long term solution is to build a better add-on system, and that work is
progressing in parallel. In the meantime, we're raising the bar in general.
That said, the main concern with any sort of proposal like this is that
even some of the most trusted add-on authors have broken their users' trust
in the past. (One key example was a security-centric add-on that started
injecting ads into content.) Any sort of program where we allow, in
effect, self-certification has to be able to address the following
questions in a concrete and effective fashion:
* Who gets to be on the list?
* What criteria are these developers evaluated against?
* What would prevent a developer from abusing this ability to sneak things
under the radar? We'd only know if someone discovered and reported a
problem.
* If abuse does happen, how would we fix the problems caused from that
abuse? (Blocklisting isn't a solution, more on this below.)
To reiterate something I've said before, blocklisting is not an effective
remedy post attack. It's a preventative tool to stop further spread, more
like a flu shot. Smart attackers go after blocklists, updaters, and any
other system that could shut them down. Even if they don't, removing the
add-on doesn't and can't undo all changes made by that add-on to the local
system.
It's a hard problem, and no one's got a convincing set of answers to those
questions. Suggestions welcome, as long as they will be effective and
reasonably fair.
-- Mike
> addons-user-experience mailing list
> addons-user...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/addons-user-experience
>
Dan Stillman
Sep 15, 2015, 6:28:43 PM9/15/15
to mozilla-addons-...@lists.mozilla.org
Hi Mike,
I think we have to realistically balance the surely rare threat of
trusted add-on authors' turning to the dark side with the continued
vibrancy of the Firefox add-on model, not to mention what the review
system is even capable of. If Mozilla wants to guarantee beyond a doubt
that no malware will ever make it through, it should just start
soliciting add-on ideas and developing add-ons itself. Anything short of
that will fail sometimes, but that's no reason to destroy the ability of
add-on developers to create advanced tools for the Firefox ecosystem
that couldn't be created for other browsers. (If Mozilla isn't
interested in such tools — which seemed like an open question after the
initial XUL/XPCOM announcement, though follow-ups have been slightly
more encouraging — I guess this can be a shorter discussion, and we can
take our leave.)
The editors do their best within a flawed system, but the review system
appears to be mostly security theater. It has never identified a
legitimate security issue in Zotero, it has flagged countless innocuous
issues that we've had to explain the context of, and it has ignored many
parts of our code base that, if we were somehow inclined, would allow us
to attack our users.
You give the example of a security-centric add-on starting to inject ads
into content. Do you think that developers that were inclined to do that
really couldn't get that past the automated scanner, or hide that
behavior amidst other code in a sufficiently complex add-on that was
manually reviewed? (We certainly could — and someone would eventually
find out, and that would be the end of Zotero.) Legitimate extension
developers are already bragging in other forums about how easy it is to
circumvent the automated scanner, even to execute remote code — and
those are people who mean no harm. I said when this plan was announced
that, given JavaScript's dynamic nature, truly protecting against such
circumvention doesn't even seem to be a solvable problem, and that
appears to have been borne out.
I don't know what the exact criteria for whitelisting should be — and I
don't know how many add-ons are even in our position — but "I know it
when I see" seems like a reasonable place to start. The alternative, at
least in Zotero's case, is our recommending that Firefox users switch to
the unbranded build — which of course will provide no protection from
malware — in the short term and our ceasing development of a
full-featured Firefox extension in the long term.
- Dan
> <mailto:addons-user...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/addons-user-experience
>
>
I think we have to realistically balance the surely rare threat of
trusted add-on authors' turning to the dark side with the continued
vibrancy of the Firefox add-on model, not to mention what the review
system is even capable of. If Mozilla wants to guarantee beyond a doubt
that no malware will ever make it through, it should just start
soliciting add-on ideas and developing add-ons itself. Anything short of
that will fail sometimes, but that's no reason to destroy the ability of
add-on developers to create advanced tools for the Firefox ecosystem
that couldn't be created for other browsers. (If Mozilla isn't
interested in such tools — which seemed like an open question after the
initial XUL/XPCOM announcement, though follow-ups have been slightly
more encouraging — I guess this can be a shorter discussion, and we can
take our leave.)
The editors do their best within a flawed system, but the review system
appears to be mostly security theater. It has never identified a
legitimate security issue in Zotero, it has flagged countless innocuous
issues that we've had to explain the context of, and it has ignored many
parts of our code base that, if we were somehow inclined, would allow us
to attack our users.
You give the example of a security-centric add-on starting to inject ads
into content. Do you think that developers that were inclined to do that
really couldn't get that past the automated scanner, or hide that
behavior amidst other code in a sufficiently complex add-on that was
manually reviewed? (We certainly could — and someone would eventually
find out, and that would be the end of Zotero.) Legitimate extension
developers are already bragging in other forums about how easy it is to
circumvent the automated scanner, even to execute remote code — and
those are people who mean no harm. I said when this plan was announced
that, given JavaScript's dynamic nature, truly protecting against such
circumvention doesn't even seem to be a solvable problem, and that
appears to have been borne out.
I don't know what the exact criteria for whitelisting should be — and I
don't know how many add-ons are even in our position — but "I know it
when I see" seems like a reasonable place to start. The alternative, at
least in Zotero's case, is our recommending that Firefox users switch to
the unbranded build — which of course will provide no protection from
malware — in the short term and our ceasing development of a
full-featured Firefox extension in the long term.
- Dan
> https://lists.mozilla.org/listinfo/addons-user-experience
>
>
Philip Chee
Sep 16, 2015, 4:18:21 AM9/16/15
to mozilla-addons-...@lists.mozilla.org
On 16/09/2015 02:44, Dan Stillman wrote:
> As I told him, we can't develop Zotero in that environment — Zotero is
> mission-critical software for many people, and we need to be able to
> release bug fixes immediately (meaning, if signing is required, via an
> API) and put out daily beta releases to allow end users to test changes.
> So something will need to change. People use our Firefox version because
> it's more deeply integrated into the browser, but if the full version of
> Zotero doesn't run in Firefox, three things will happen:
>
> 1) In the short term, we'll actively encourage all Zotero for Firefox
> users to switch to the unbranded Firefox build with extension signing
> disabled so that they can continue to use new versions as we release them.
>
> 2) We'll recommend that people who don't care about the tighter browser
> integration switch to our standalone application and one of our
> lightweight connector extensions now, removing the main reason a huge
> number of people have switched to or stayed on Firefox over the years.
>
> 3) We'll abandon dedicated Firefox development over the next 12-18
> months, since, even if WebExtensions gain support for everything we
> need, which is far from clear, it won't be worth rewriting the full
> extension after the XUL/XPCOM ban if we can't release it normally for
> the standard Firefox build.
Please consider using SeaMonkey in place of Firefox.
> As I told him, we can't develop Zotero in that environment — Zotero is
> mission-critical software for many people, and we need to be able to
> release bug fixes immediately (meaning, if signing is required, via an
> API) and put out daily beta releases to allow end users to test changes.
> So something will need to change. People use our Firefox version because
> it's more deeply integrated into the browser, but if the full version of
> Zotero doesn't run in Firefox, three things will happen:
>
> 1) In the short term, we'll actively encourage all Zotero for Firefox
> users to switch to the unbranded Firefox build with extension signing
> disabled so that they can continue to use new versions as we release them.
>
> 2) We'll recommend that people who don't care about the tighter browser
> integration switch to our standalone application and one of our
> lightweight connector extensions now, removing the main reason a huge
> number of people have switched to or stayed on Firefox over the years.
>
> 3) We'll abandon dedicated Firefox development over the next 12-18
> months, since, even if WebExtensions gain support for everything we
> need, which is far from clear, it won't be worth rewriting the full
> extension after the XUL/XPCOM ban if we can't release it normally for
> the standard Firefox build.
http://www.seamonkey-project.org/releases/
SeaMonkey will not enable/enforce extension signing.
The Zotero extension already works in SeaMonkey after going through the
SeaMonkey addon-converter
http://addonconverter.fotokraina.com/
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
Robert Kaiser
Sep 18, 2015, 6:11:59 PM9/18/15
to mozilla-addons-...@lists.mozilla.org
Philip Chee schrieb:
coffin of SeaMonkey, but do whatever you like.
KaiRo
> SeaMonkey will not enable/enforce extension signing.
In the long run, that is probably a mistake and one more nail in the
coffin of SeaMonkey, but do whatever you like.
KaiRo
Kaply Consulting
Sep 18, 2015, 6:22:04 PM9/18/15
to addons-user...@lists.mozilla.org
On 9/18/15 5:11 PM, Robert Kaiser wrote:
> Philip Chee schrieb:
SeaMonkey's coffin. I'm not sure that extension signing will matter.
Do you really think SeaMonkey will become a haven for malware?
>
> KaiRo
--
Mike Kaply - Kaply Consulting in Austin, TX
Sign up for my newsletter - http://mike.kaply.com/email/
http://mike.kaply.com | http://www.linkedin.com/in/mkaply
> Philip Chee schrieb:
>> SeaMonkey will not enable/enforce extension signing.
>
>
> In the long run, that is probably a mistake and one more nail in the
> coffin of SeaMonkey, but do whatever you like.
I would think that Mozilla killing XUL will be all the nails in
> coffin of SeaMonkey, but do whatever you like.
SeaMonkey's coffin. I'm not sure that extension signing will matter.
Do you really think SeaMonkey will become a haven for malware?
>
> KaiRo
>
> _______________________________________________
> addons-user-experience mailing list
> addons-user...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/addons-user-experience
> _______________________________________________
> addons-user-experience mailing list
> addons-user...@lists.mozilla.org
--
Mike Kaply - Kaply Consulting in Austin, TX
Sign up for my newsletter - http://mike.kaply.com/email/
http://mike.kaply.com | http://www.linkedin.com/in/mkaply
Lemon Juice
Sep 19, 2015, 6:26:48 PM9/19/15
to mozilla-addons-...@lists.mozilla.org
On 2015-09-19 00:21, Kaply Consulting wrote:
> On 9/18/15 5:11 PM, Robert Kaiser wrote:
>> Philip Chee schrieb:
>>> SeaMonkey will not enable/enforce extension signing.
>>
>> In the long run, that is probably a mistake and one more nail in the
>> coffin of SeaMonkey, but do whatever you like.
> I would think that Mozilla killing XUL will be all the nails in
> SeaMonkey's coffin. I'm not sure that extension signing will matter.
Actually, if enough people and businesses flock to SeaMonkey it will
> On 9/18/15 5:11 PM, Robert Kaiser wrote:
>> Philip Chee schrieb:
>>> SeaMonkey will not enable/enforce extension signing.
>>
>> In the long run, that is probably a mistake and one more nail in the
>> coffin of SeaMonkey, but do whatever you like.
> I would think that Mozilla killing XUL will be all the nails in
> SeaMonkey's coffin. I'm not sure that extension signing will matter.
mean good future for SeaMonkey. Popularity will result in more people
interested in helping with development.
Emiliano Heyns
Sep 20, 2015, 7:20:41 AM9/20/15
to mozilla-addons-...@lists.mozilla.org
On Tuesday, September 15, 2015 at 9:57:09 PM UTC+2, Mike Connor wrote:
> Hi Dan,
>
> Overall, I wouldn't assert that directly distributing malware is the sole
> consideration in play. There's lots of software out there that I wouldn't
> necessarily label as malware in itself, but violates our add-on guidelines
> and best practices in many other ways that lead directly to users moving
> away from Firefox. Security/privacy/stability problems are too common
> still, as well as notable performance degradation, especially memory.
Without disputing this claim, I'd love to see the data that underpins it. It seems somewhat counter-intuitive to me, to be honest. If I look at Zotero, and my own extension on Zotero (BBT), I can easily produce data on why people choose Mozilla over an existing preferred browser specifically because of the existence of Zotero/BBT. I simply can't fathom how people would say "Firefox used to be my thing, but because of Zotero, it is not now". But that is teh claim on the table, since Zotero does use these "add-on guidelines and best practices" (not even going into the fact that I would contest that these guidelines constitute best practices, or that the validator intelligently checks for them.
> Hi Dan,
>
> Overall, I wouldn't assert that directly distributing malware is the sole
> consideration in play. There's lots of software out there that I wouldn't
> necessarily label as malware in itself, but violates our add-on guidelines
> and best practices in many other ways that lead directly to users moving
> away from Firefox. Security/privacy/stability problems are too common
> still, as well as notable performance degradation, especially memory.
> The
> long term solution is to build a better add-on system, and that work is
> progressing in parallel. In the meantime, we're raising the bar in general.
> That said, the main concern with any sort of proposal like this is that
> even some of the most trusted add-on authors have broken their users' trust
> in the past. (One key example was a security-centric add-on that started
> injecting ads into content.) Any sort of program where we allow, in
> effect, self-certification has to be able to address the following
> questions in a concrete and effective fashion:
>
> * Who gets to be on the list?
> * What criteria are these developers evaluated against?
> * What would prevent a developer from abusing this ability to sneak things
> under the radar? We'd only know if someone discovered and reported a
> problem.
> * If abuse does happen, how would we fix the problems caused from that
> abuse? (Blocklisting isn't a solution, more on this below.)
> It's a hard problem, and no one's got a convincing set of answers to those
> questions. Suggestions welcome, as long as they will be effective and
> reasonably fair.
Emiliano Heyns
Sep 20, 2015, 7:22:01 AM9/20/15
to mozilla-addons-...@lists.mozilla.org
On Wednesday, September 16, 2015 at 10:18:21 AM UTC+2, Philip Chee wrote:
> On 16/09/2015 02:44, Dan Stillman wrote:
>
> > As I told him, we can't develop Zotero in that environment -- Zotero is
> On 16/09/2015 02:44, Dan Stillman wrote:
>
> > mission-critical software for many people, and we need to be able to
> > release bug fixes immediately (meaning, if signing is required, via an
> > API) and put out daily beta releases to allow end users to test changes.
> > So something will need to change. People use our Firefox version because
> > it's more deeply integrated into the browser, but if the full version of
> > Zotero doesn't run in Firefox, three things will happen:
> >
> > 1) In the short term, we'll actively encourage all Zotero for Firefox
> > users to switch to the unbranded Firefox build with extension signing
> > disabled so that they can continue to use new versions as we release them.
> >
> > 2) We'll recommend that people who don't care about the tighter browser
> > integration switch to our standalone application and one of our
> > lightweight connector extensions now, removing the main reason a huge
> > number of people have switched to or stayed on Firefox over the years.
> >
> > 3) We'll abandon dedicated Firefox development over the next 12-18
> > months, since, even if WebExtensions gain support for everything we
> > need, which is far from clear, it won't be worth rewriting the full
> > extension after the XUL/XPCOM ban if we can't release it normally for
> > the standard Firefox build.
>
> Please consider using SeaMonkey in place of Firefox.
> http://www.seamonkey-project.org/releases/
> SeaMonkey will not enable/enforce extension signing.
>
> The Zotero extension already works in SeaMonkey after going through the
> SeaMonkey addon-converter
> http://addonconverter.fotokraina.com/
>
Is it possible to create extensions that simply are compatible with both? Will XUL/XPCOM (realistically) remain supported on Seamonkey when Firfox axes it?
> > release bug fixes immediately (meaning, if signing is required, via an
> > API) and put out daily beta releases to allow end users to test changes.
> > So something will need to change. People use our Firefox version because
> > it's more deeply integrated into the browser, but if the full version of
> > Zotero doesn't run in Firefox, three things will happen:
> >
> > 1) In the short term, we'll actively encourage all Zotero for Firefox
> > users to switch to the unbranded Firefox build with extension signing
> > disabled so that they can continue to use new versions as we release them.
> >
> > 2) We'll recommend that people who don't care about the tighter browser
> > integration switch to our standalone application and one of our
> > lightweight connector extensions now, removing the main reason a huge
> > number of people have switched to or stayed on Firefox over the years.
> >
> > 3) We'll abandon dedicated Firefox development over the next 12-18
> > months, since, even if WebExtensions gain support for everything we
> > need, which is far from clear, it won't be worth rewriting the full
> > extension after the XUL/XPCOM ban if we can't release it normally for
> > the standard Firefox build.
>
> Please consider using SeaMonkey in place of Firefox.
> http://www.seamonkey-project.org/releases/
> SeaMonkey will not enable/enforce extension signing.
>
> The Zotero extension already works in SeaMonkey after going through the
> SeaMonkey addon-converter
> http://addonconverter.fotokraina.com/
>
The Wanderer
Sep 20, 2015, 8:27:05 AM9/20/15
to mozilla-addons-...@lists.mozilla.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2015-09-15 at 15:57, Mike Connor wrote:
> Hi Dan,
>
> Overall, I wouldn't assert that directly distributing malware is
> the sole consideration in play.
Eh?
In past discussion here and elsewhere, countering directly-malicious
extensions has been the _only_ argument I've seen presented in support
of requiring extensions to be signed at all (much less requiring them to
be signed by Mozilla) or against suggestions of ways to disable the
signing requirement in release-channel builds.
If there is another justification for it which would be considered
enough on its own, to only present that justification _now_ (when things
are so far along that virtually no counterargument could have enough of
an impact to change the course) rather than up-front at the start of the
discussion is - at the very least - a significant case of moving the
goalposts for a potential counterargument.
> There's lots of software out there that I wouldn't necessarily
> label as malware in itself, but violates our add-on guidelines and
> best practices in many other ways that lead directly to users
> moving away from Firefox.
And that is reason enough not to host such addons on AMO.
It is _not_ reason enough to refuse signing in a central
signing-is-mandatory paradigm, unless what you are trying to do is not
to improve security but to increase centralized control.
Under the "countering malware" justification for requiring extensions to
be signed, the answer to "will we sign this extension?" should be
exactly the inverse of the answer to "if we saw this extension in the
wild under the blocklist-based paradigm, would we add it to the
blocklist?". Anything else turns this from an attempt to improve
security into an attempt to seize control.
Many people who object to the move to require extensions to be signed
understand the "need to counter malware" argument, even if they disagree
that the proposed solution is proportionate, and can grudgingly accept
that the move might be justifiable on those grounds.
I suspect that _very few_ of those people would be _remotely_ willing to
accept an assertion of centralized control by Mozilla on the
less-critical "code quality" argument which you seem to be making.
Such move to centralized control would be counter to the ethos of
freedom and user control which Firefox and Mozilla have historically at
least appeared to stand for.
> Security/privacy/stability problems are too common still, as well
> as notable performance degradation, especially memory. The long
> term solution is to build a better add-on system, and that work is
> progressing in parallel. In the meantime, we're raising the bar in
> general.
You may well be right that all of these things are problems, and that
they would be improved by following Mozilla's "add-on guidelines and
best practices".
But it is not Mozilla's place to enforce such things, especially not
using a system which has been sold _exclusively_ as being a means of
improving security. That sort of bait-and-switch tactic reminds me
unpleasantly of the security-theater, "because terrorism, so don't
question it" governmental power-grab shenanigans which have been
proliferating in recent years... and I would be highly disappointed to
see such a thing coming from Mozilla.
- --
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCgAGBQJV/qX2AAoJEASpNY00KDJrObsP/1iwQZthJo5lAdEY6w646B91
RolysepvUqML/Uvy1UxTXWq1lZcHLQ5Y6C3T+FB6fJawxYsul8zp81uAxjbk8LLT
e0Wp1tFvJI92goZg0iDYw5rs3LeIeMQFJmsrAprq8Wnr4l+MXOUBnQe66OwA8Zm6
QDzkchp2qcuHHEpg2fCWnxM/4IMehb6WfrHoaGbrUduEyNOGYA0eV9kfYl3deLBG
rv4et1+QH0WWYviwlGGb9dPV+WnbXt7svUccSUY9SVS881fOPAM6S3l1kjxFb+J9
LNDp2YFw5nJ0Ll57R2OcGjjnzDXRKTq5BDbjR2ENHdG171MDycpYpDbKS5QpQ75a
lXTHfdI766yBt3mPHHP2oMiQ0wg1k4MgOm/27ctSyHmHgAuhyWxsNTwtrvU4OqXD
LEyt3cxp0SlCakPZMB3zUS7hskD7cUW/XF09eJUZXEXrZOyBEiClN0WooDFA7UyL
Q6pMxuOf5ZSuj+McRVoM05AHAmrNYZf2N4+C/P7V3MwEit1v4WHgfFDanSx24CXy
EHeUqPU/Gi4X1OEYcr6CBg1IqorcdFAnF2MQV5Am548casW5SzzN4t/2TppwN98B
F5EIBw287z4nV3o1y6xxHjpX5YeOUUlO4G5DE/eD0V4cH3Ee80VbUZi2W+cKRY9A
pkBmWUSVD2DU0KVqdHOa
=9jQ9
-----END PGP SIGNATURE-----
Hash: SHA512
On 2015-09-15 at 15:57, Mike Connor wrote:
> Hi Dan,
>
> Overall, I wouldn't assert that directly distributing malware is
> the sole consideration in play.
In past discussion here and elsewhere, countering directly-malicious
extensions has been the _only_ argument I've seen presented in support
of requiring extensions to be signed at all (much less requiring them to
be signed by Mozilla) or against suggestions of ways to disable the
signing requirement in release-channel builds.
If there is another justification for it which would be considered
enough on its own, to only present that justification _now_ (when things
are so far along that virtually no counterargument could have enough of
an impact to change the course) rather than up-front at the start of the
discussion is - at the very least - a significant case of moving the
goalposts for a potential counterargument.
> There's lots of software out there that I wouldn't necessarily
> label as malware in itself, but violates our add-on guidelines and
> best practices in many other ways that lead directly to users
> moving away from Firefox.
It is _not_ reason enough to refuse signing in a central
signing-is-mandatory paradigm, unless what you are trying to do is not
to improve security but to increase centralized control.
Under the "countering malware" justification for requiring extensions to
be signed, the answer to "will we sign this extension?" should be
exactly the inverse of the answer to "if we saw this extension in the
wild under the blocklist-based paradigm, would we add it to the
blocklist?". Anything else turns this from an attempt to improve
security into an attempt to seize control.
Many people who object to the move to require extensions to be signed
understand the "need to counter malware" argument, even if they disagree
that the proposed solution is proportionate, and can grudgingly accept
that the move might be justifiable on those grounds.
I suspect that _very few_ of those people would be _remotely_ willing to
accept an assertion of centralized control by Mozilla on the
less-critical "code quality" argument which you seem to be making.
Such move to centralized control would be counter to the ethos of
freedom and user control which Firefox and Mozilla have historically at
least appeared to stand for.
> Security/privacy/stability problems are too common still, as well
> as notable performance degradation, especially memory. The long
> term solution is to build a better add-on system, and that work is
> progressing in parallel. In the meantime, we're raising the bar in
> general.
they would be improved by following Mozilla's "add-on guidelines and
best practices".
But it is not Mozilla's place to enforce such things, especially not
using a system which has been sold _exclusively_ as being a means of
improving security. That sort of bait-and-switch tactic reminds me
unpleasantly of the security-theater, "because terrorism, so don't
question it" governmental power-grab shenanigans which have been
proliferating in recent years... and I would be highly disappointed to
see such a thing coming from Mozilla.
- --
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCgAGBQJV/qX2AAoJEASpNY00KDJrObsP/1iwQZthJo5lAdEY6w646B91
RolysepvUqML/Uvy1UxTXWq1lZcHLQ5Y6C3T+FB6fJawxYsul8zp81uAxjbk8LLT
e0Wp1tFvJI92goZg0iDYw5rs3LeIeMQFJmsrAprq8Wnr4l+MXOUBnQe66OwA8Zm6
QDzkchp2qcuHHEpg2fCWnxM/4IMehb6WfrHoaGbrUduEyNOGYA0eV9kfYl3deLBG
rv4et1+QH0WWYviwlGGb9dPV+WnbXt7svUccSUY9SVS881fOPAM6S3l1kjxFb+J9
LNDp2YFw5nJ0Ll57R2OcGjjnzDXRKTq5BDbjR2ENHdG171MDycpYpDbKS5QpQ75a
lXTHfdI766yBt3mPHHP2oMiQ0wg1k4MgOm/27ctSyHmHgAuhyWxsNTwtrvU4OqXD
LEyt3cxp0SlCakPZMB3zUS7hskD7cUW/XF09eJUZXEXrZOyBEiClN0WooDFA7UyL
Q6pMxuOf5ZSuj+McRVoM05AHAmrNYZf2N4+C/P7V3MwEit1v4WHgfFDanSx24CXy
EHeUqPU/Gi4X1OEYcr6CBg1IqorcdFAnF2MQV5Am548casW5SzzN4t/2TppwN98B
F5EIBw287z4nV3o1y6xxHjpX5YeOUUlO4G5DE/eD0V4cH3Ee80VbUZi2W+cKRY9A
pkBmWUSVD2DU0KVqdHOa
=9jQ9
-----END PGP SIGNATURE-----
Dan Stillman
Oct 16, 2015, 4:54:00 AM10/16/15
to mozilla-addons-...@lists.mozilla.org
On 9/20/15 8:26 AM, The Wanderer wrote:
> On 2015-09-15 at 15:57, Mike Connor wrote:
>
> On 2015-09-15 at 15:57, Mike Connor wrote:
>
>> Hi Dan,
>>
>> Overall, I wouldn't assert that directly distributing malware is
>> the sole consideration in play.
>>
>> Overall, I wouldn't assert that directly distributing malware is
>> the sole consideration in play.
> Eh?
>
> In past discussion here and elsewhere, countering directly-malicious
> extensions has been the _only_ argument I've seen presented in support
> of requiring extensions to be signed at all (much less requiring them to
> be signed by Mozilla) or against suggestions of ways to disable the
> signing requirement in release-channel builds.
>
> If there is another justification for it which would be considered
> enough on its own, to only present that justification _now_ (when things
> are so far along that virtually no counterargument could have enough of
> an impact to change the course) rather than up-front at the start of the
> discussion is - at the very least - a significant case of moving the
> goalposts for a potential counterargument.
While it's been a pleasant lull, since the clock is still ticking, I'd
>
> In past discussion here and elsewhere, countering directly-malicious
> extensions has been the _only_ argument I've seen presented in support
> of requiring extensions to be signed at all (much less requiring them to
> be signed by Mozilla) or against suggestions of ways to disable the
> signing requirement in release-channel builds.
>
> If there is another justification for it which would be considered
> enough on its own, to only present that justification _now_ (when things
> are so far along that virtually no counterargument could have enough of
> an impact to change the course) rather than up-front at the start of the
> discussion is - at the very least - a significant case of moving the
> goalposts for a potential counterargument.
like to return to this issue. I can't echo this response enough.
Mozilla gave one justification for this scheme, over and over, without
variation: combating malware. To now say that malware isn't "the sole
consideration in play" implies that Mozilla was misleading the community
about its intentions.
Just to set the record straight, let's review some of the comments from
Mozilla folks about this plan:
- From the "Introducing Extension Signing: A Safer Add-on Experience"
blog post [1]: "gives bad actors too much freedom to take advantage of
our users", "malicious developers", "bad add-ons". Jorge, in the
comments: " automated malware check", "We only need to verify the add-on
isn’t malicious on its own", "add-on malware is currently an
uncontrollable mess"
- From the "The Case for Extension Signing" blog post [2]: "The adware
scourge", "unwanted add-ons", "malicious developers", "malicious add-on"
- From the Extension Signing wiki page: "Will this protect users against
all forms of add-on malware? No, there is no perfect solution for this.
Fighting malware requires defenses on many levels… Extension signing is
a big step in protecting Firefox against malicious add-ons"
- Daniel Veditz in June 2014 [3]: "We're doing this because every time
any of us visits our family their Firefox is a toolbar laden crapfest
that we have to clean up, and because the resulting bad performance is
causing us to lose users."
- Jorge even said outright in a comment on the first blog post: "our
purpose is to block malware distribution, not police code quality"
Nowhere in the posts above was it suggested that there was any other
motivation for the change. (Honestly, I looked.) In August 2014 Jorge
even said that "The evidence we have points to silent side-loading as
the main culprit for add-on problems" [4], suggesting that front-loaded
non-AMO extensions were hardly even a problem to begin with.
But if policing "code quality" is indeed part of the goal and Mozilla
wants to assert AMO-style review over every non-trivial extension (or at
least the ones that don't trivially circumvent the scanner), then let's
get that out in the open and have the debate again under honest terms.
(Just to clarify what that looks like: 1) an obviously legitimate
extension like Zotero being rejected, 2) our being given notes for
having variables in the global scope (which they actually weren't), for
a JS file being in the 'skin' directory, for making changes to TinyMCE
to fix incompatibilities with the Zotero UI, for /not/ making changes to
TinyMCE to avoid the use of document.write, for using innerHTML in
shared code that's not even run in Firefox and that was copied verbatim
from the MDN DOMParser documentation, and for a few other harmless
things, 3) our having to explain, over the course of several weeks, why
every one of these issues was innocuous in context, as we always had to
on AMO before we left several years ago, 4) Jorge acknowledging that
there were no actual security issues, and 5) our resubmitting a new
build in which the only changes were a couple unminified TinyMCE plugins
and a few comments saying that the lines that followed weren't actually
security issues. And then a 4+-day wait for every review since.)
If the concern really is malware, though, there's no plausible reason
for forcing an obviously legitimate, unlisted, front-loaded extension
like Zotero to be manually reviewed every single time an update — and
even a beta update — is released. It's wildly disproportionate to insist
on that because of one supposedly legitimate extension years ago that
started injecting ads. It's also not my job to figure out what the
criteria are for whitelisting, but it's Mozilla's job to ensure that
legitimate extensions that empower users can continue to exist.
I said previously that we can't keep developing Zotero as a
full-featured Firefox extension if every update takes days to put out.
Well, a few weeks ago, when Firefox 41 came out, we had to put out four
releases in rapid succession due to major breakage — including an
absolute showstopper — from various undocumented changes in 41. The
biggest breakage we should have caught and somehow missed. The rest was
platform-specific and harder to catch (though the best chance would've
been through more people running daily beta updates, something this
scheme will prevent, since even betas will take days to review).
Fortunately we were able to put out unsigned builds within minutes of
the first reports, keeping most of our users from even seeing the bugs.
If Firefox 41 had enforced extension signing as originally planned, it
would have been disastrous for our users, who rely on Zotero to write
dissertations, submit academic papers, complete homework assignments,
and perform daily research. This sort of thing doesn't usually happen —
minor changes in Firefox don't usually cause major breakage in Zotero,
and we almost always catch compatibility issues in time — but it
underscores why we can't continue developing Zotero if we can't put out
releases quickly.
So if we can't find a solution here, then that's the end of Zotero as a
full-featured Firefox extension. But let's start by being clear about
the purpose of this system.
- Dan
[1]
https://blog.mozilla.org/addons/2015/02/10/extension-signing-safer-experience/
[2]
https://blog.mozilla.org/addons/2015/04/15/the-case-for-extension-signing/
[3]
https://groups.google.com/d/msg/mozilla.addons.user-experience/F2ejhP32a0Y/6rWyYX84VLYJ
[4]
https://groups.google.com/d/msg/mozilla.addons.user-experience/qIgLq28aTdI/IyD2p_CFAEUJ
>> There's lots of software out there that I wouldn't necessarily
>> label as malware in itself, but violates our add-on guidelines and
>> best practices in many other ways that lead directly to users
>> moving away from Firefox.
> And that is reason enough not to host such addons on AMO.
>
> It is _not_ reason enough to refuse signing in a central
> signing-is-mandatory paradigm, unless what you are trying to do is not
> to improve security but to increase centralized control.
>
> Under the "countering malware" justification for requiring extensions to
> be signed, the answer to "will we sign this extension?" should be
> exactly the inverse of the answer to "if we saw this extension in the
> wild under the blocklist-based paradigm, would we add it to the
> blocklist?". Anything else turns this from an attempt to improve
> security into an attempt to seize control.
>
> Many people who object to the move to require extensions to be signed
> understand the "need to counter malware" argument, even if they disagree
> that the proposed solution is proportionate, and can grudgingly accept
> that the move might be justifiable on those grounds.
>
> I suspect that _very few_ of those people would be _remotely_ willing to
> accept an assertion of centralized control by Mozilla on the
> less-critical "code quality" argument which you seem to be making.
>
> Such move to centralized control would be counter to the ethos of
> freedom and user control which Firefox and Mozilla have historically at
> least appeared to stand for.
>
>
> It is _not_ reason enough to refuse signing in a central
> signing-is-mandatory paradigm, unless what you are trying to do is not
> to improve security but to increase centralized control.
>
> Under the "countering malware" justification for requiring extensions to
> be signed, the answer to "will we sign this extension?" should be
> exactly the inverse of the answer to "if we saw this extension in the
> wild under the blocklist-based paradigm, would we add it to the
> blocklist?". Anything else turns this from an attempt to improve
> security into an attempt to seize control.
>
> Many people who object to the move to require extensions to be signed
> understand the "need to counter malware" argument, even if they disagree
> that the proposed solution is proportionate, and can grudgingly accept
> that the move might be justifiable on those grounds.
>
> I suspect that _very few_ of those people would be _remotely_ willing to
> accept an assertion of centralized control by Mozilla on the
> less-critical "code quality" argument which you seem to be making.
>
> Such move to centralized control would be counter to the ethos of
> freedom and user control which Firefox and Mozilla have historically at
> least appeared to stand for.
>
>> Security/privacy/stability problems are too common still, as well
>> as notable performance degradation, especially memory. The long
>> term solution is to build a better add-on system, and that work is
>> progressing in parallel. In the meantime, we're raising the bar in
>> general.
>> as notable performance degradation, especially memory. The long
>> term solution is to build a better add-on system, and that work is
>> progressing in parallel. In the meantime, we're raising the bar in
>> general.
Andreas Wagner
Oct 16, 2015, 5:03:08 AM10/16/15
to Dan Stillman, mozilla-addons-...@lists.mozilla.org
As a side note: In order to avoid last minute changes to add-ons for new
stable releases, we offer different channels (beta, aurora/dev-edition,
nightly) which give you the opportunity to spot issues with your extension
early and give you multiple weeks of time to work on and submit a fix.
On Fri, Oct 16, 2015 at 10:53 AM, Dan Stillman <dsti...@zotero.org> wrote:
> On 9/20/15 8:26 AM, The Wanderer wrote:
>
>> On 2015-09-15 at 15:57, Mike Connor wrote:
>>
stable releases, we offer different channels (beta, aurora/dev-edition,
nightly) which give you the opportunity to spot issues with your extension
early and give you multiple weeks of time to work on and submit a fix.
On Fri, Oct 16, 2015 at 10:53 AM, Dan Stillman <dsti...@zotero.org> wrote:
> On 9/20/15 8:26 AM, The Wanderer wrote:
>
>> On 2015-09-15 at 15:57, Mike Connor wrote:
>>
>> Hi Dan,
>>>
>>> Overall, I wouldn't assert that directly distributing malware is
>>> the sole consideration in play.
>>>
>>>
>>> Overall, I wouldn't assert that directly distributing malware is
>>> the sole consideration in play.
>>>
> There's lots of software out there that I wouldn't necessarily
>>> label as malware in itself, but violates our add-on guidelines and
>>> best practices in many other ways that lead directly to users
>>> moving away from Firefox.
>>>
>>> label as malware in itself, but violates our add-on guidelines and
>>> best practices in many other ways that lead directly to users
>>> moving away from Firefox.
>>>
>> And that is reason enough not to host such addons on AMO.
>>
>> It is _not_ reason enough to refuse signing in a central
>> signing-is-mandatory paradigm, unless what you are trying to do is not
>> to improve security but to increase centralized control.
>>
>> Under the "countering malware" justification for requiring extensions to
>> be signed, the answer to "will we sign this extension?" should be
>> exactly the inverse of the answer to "if we saw this extension in the
>> wild under the blocklist-based paradigm, would we add it to the
>> blocklist?". Anything else turns this from an attempt to improve
>> security into an attempt to seize control.
>>
>> Many people who object to the move to require extensions to be signed
>> understand the "need to counter malware" argument, even if they disagree
>> that the proposed solution is proportionate, and can grudgingly accept
>> that the move might be justifiable on those grounds.
>>
>> I suspect that _very few_ of those people would be _remotely_ willing to
>> accept an assertion of centralized control by Mozilla on the
>> less-critical "code quality" argument which you seem to be making.
>>
>> Such move to centralized control would be counter to the ethos of
>> freedom and user control which Firefox and Mozilla have historically at
>> least appeared to stand for.
>>
>>
>> It is _not_ reason enough to refuse signing in a central
>> signing-is-mandatory paradigm, unless what you are trying to do is not
>> to improve security but to increase centralized control.
>>
>> Under the "countering malware" justification for requiring extensions to
>> be signed, the answer to "will we sign this extension?" should be
>> exactly the inverse of the answer to "if we saw this extension in the
>> wild under the blocklist-based paradigm, would we add it to the
>> blocklist?". Anything else turns this from an attempt to improve
>> security into an attempt to seize control.
>>
>> Many people who object to the move to require extensions to be signed
>> understand the "need to counter malware" argument, even if they disagree
>> that the proposed solution is proportionate, and can grudgingly accept
>> that the move might be justifiable on those grounds.
>>
>> I suspect that _very few_ of those people would be _remotely_ willing to
>> accept an assertion of centralized control by Mozilla on the
>> less-critical "code quality" argument which you seem to be making.
>>
>> Such move to centralized control would be counter to the ethos of
>> freedom and user control which Firefox and Mozilla have historically at
>> least appeared to stand for.
>>
>> Security/privacy/stability problems are too common still, as well
>>> as notable performance degradation, especially memory. The long
>>> term solution is to build a better add-on system, and that work is
>>> progressing in parallel. In the meantime, we're raising the bar in
>>> general.
>>>
>>> as notable performance degradation, especially memory. The long
>>> term solution is to build a better add-on system, and that work is
>>> progressing in parallel. In the meantime, we're raising the bar in
>>> general.
>>>
>> You may well be right that all of these things are problems, and that
>> they would be improved by following Mozilla's "add-on guidelines and
>> best practices".
>>
>> But it is not Mozilla's place to enforce such things, especially not
>> using a system which has been sold _exclusively_ as being a means of
>> improving security. That sort of bait-and-switch tactic reminds me
>> unpleasantly of the security-theater, "because terrorism, so don't
>> question it" governmental power-grab shenanigans which have been
>> proliferating in recent years... and I would be highly disappointed to
>> see such a thing coming from Mozilla.
>>
>> - -- The Wanderer
>>
>> they would be improved by following Mozilla's "add-on guidelines and
>> best practices".
>>
>> But it is not Mozilla's place to enforce such things, especially not
>> using a system which has been sold _exclusively_ as being a means of
>> improving security. That sort of bait-and-switch tactic reminds me
>> unpleasantly of the security-theater, "because terrorism, so don't
>> question it" governmental power-grab shenanigans which have been
>> proliferating in recent years... and I would be highly disappointed to
>> see such a thing coming from Mozilla.
>>
>> - -- The Wanderer
>>
Dan Stillman
Oct 16, 2015, 5:58:06 AM10/16/15
to mozilla-addons-...@lists.mozilla.org
On 10/16/15 5:02 AM, Andreas Wagner wrote:
> As a side note: In order to avoid last minute changes to add-ons for
> new stable releases, we offer different channels (beta,
> aurora/dev-edition, nightly) which give you the opportunity to spot
> issues with your extension early and give you multiple weeks of time
> to work on and submit a fix.
Yes, thanks — we're well aware of the different channels. (We've been
> As a side note: In order to avoid last minute changes to add-ons for
> new stable releases, we offer different channels (beta,
> aurora/dev-edition, nightly) which give you the opportunity to spot
> issues with your extension early and give you multiple weeks of time
> to work on and submit a fix.
putting out Zotero since 2006.) But those don't guarantee that all
breaking changes will be caught, and they don't prevent regular bugs, so
they don't obviate the need for us to be able to put out critical bug
fixes immediately when people are relying on our software for important
work.
Andreas Wagner
Oct 16, 2015, 6:03:23 AM10/16/15
to Dan Stillman, mozilla-addons-...@lists.mozilla.org
So, are you saying the issues you had to fix last minute were not in any of
the beta versions? If so, I'd like to know which ones that were so we can
investigate and improve in the future.
Also, please let us know about that undocumented change you mentioned, so
we can investigate why that one has not been documented.
Regards,
Andreas Wagner
the beta versions? If so, I'd like to know which ones that were so we can
investigate and improve in the future.
Also, please let us know about that undocumented change you mentioned, so
we can investigate why that one has not been documented.
Regards,
Andreas Wagner
Dan Stillman
Oct 16, 2015, 6:55:04 AM10/16/15
to mozilla-addons-...@lists.mozilla.org
On 10/16/15 6:03 AM, Andreas Wagner wrote:
> So, are you saying the issues you had to fix last minute were not in
> any of the beta versions? If so, I'd like to know which ones that were
> so we can investigate and improve in the future.
I appreciate that, but no, they were on all the channels. We just didn't
> So, are you saying the issues you had to fix last minute were not in
> any of the beta versions? If so, I'd like to know which ones that were
> so we can investigate and improve in the future.
catch them. My point is just that saying that bug fixes shouldn't be
necessary because you can always just test your software before
releasing it isn't exactly reasonable. That's sort of what makes them bugs.
> Also, please let us know about that undocumented change you mentioned,
> so we can investigate why that one has not been documented.
thousands of changes between Firefox releases, and Zotero is hundreds of
thousands of lines of code, and everything that might go wrong between
the two isn't going to be documented on the "Firefox [x] for Developers"
page. In this case, there were some low-level changes to login manager
code, to drag-and-drop code on Windows, and to file: URI access via
Image from the hidden window on Windows/Linux. The last one maybe
should've been documented, but it doesn't really matter. Bugs happen,
and we need to be able to fix them immediately if we're going to ask
people to trust Zotero with their research.
I don't imagine that most extensions are in this situation — certainly
the sheer number of things that can break, but also the potential
seriousness of bugs — but we are, and I'm sure some others are too.
Emiliano Heyns
Oct 16, 2015, 7:29:01 PM10/16/15
to mozilla-addons-...@lists.mozilla.org
Like me. I develop the BBT extension to zotero, and all the concerns Dan lists apply to me. As a single developer against an underspecified target (bibtex) with my users usually under time pressure people outside academia can often hardly understand, I pride myself on providing immediate fixes. I need to be able to do instrumented builds for debugging. And I've already had to skip or drop valuable features because I need to stay in the straightjacket of automated reviews to make that even plausibly attainable.
Not that I couldn't have those features if I wanted to play the cat and mouse game. I'm fairly certain I can create a keylogger, including remote code execution, that passes the automated validator. So the current proposal does exactly nothing to prevent malware, but it's very successful at preventing people writing legitimate extensions at just getting on with their work.
I'm slightly more upbeat about where things are headed now that I see concrete activity on the signing api, and talk about a chrome-style developer mode which would make immediate fixes and debug builds possible. I still think the signing proposal was ill conceived security theater with legitimate concerns being systematically downplayed.
All this is probably moot in about a year when the bottom falls out under xul. But we'll burn that bridge when we get to it.
(if you're imagining a subtle undercurrent of annoyance in the above text, you're reading it correctly)
Not that I couldn't have those features if I wanted to play the cat and mouse game. I'm fairly certain I can create a keylogger, including remote code execution, that passes the automated validator. So the current proposal does exactly nothing to prevent malware, but it's very successful at preventing people writing legitimate extensions at just getting on with their work.
I'm slightly more upbeat about where things are headed now that I see concrete activity on the signing api, and talk about a chrome-style developer mode which would make immediate fixes and debug builds possible. I still think the signing proposal was ill conceived security theater with legitimate concerns being systematically downplayed.
All this is probably moot in about a year when the bottom falls out under xul. But we'll burn that bridge when we get to it.
(if you're imagining a subtle undercurrent of annoyance in the above text, you're reading it correctly)
Dan Stillman
Nov 16, 2015, 4:20:10 PM11/16/15
to mozilla-addons-...@lists.mozilla.org
Just bringing the discussion back to this thread. There has been a long
discussion of the Zotero situation, as well as proposed whitelist rules
from Gijs.
Relevant discussion begins here:
https://groups.google.com/d/msg/mozilla.addons.user-experience/3bAaITHf1Xo/b_G-v7QgAwAJ
Nothing after this — where I clarify the very limited scope of the
whitelist proposal — has received a response from Mozilla folks:
https://groups.google.com/d/msg/mozilla.addons.user-experience/3bAaITHf1Xo/ulnmgVeaAwAJ
My comments on the whitelist rules are here:
https://groups.google.com/d/msg/mozilla.addons.user-experience/3bAaITHf1Xo/61siUR0cBgAJ
We'd appreciate a response.
discussion of the Zotero situation, as well as proposed whitelist rules
from Gijs.
Relevant discussion begins here:
https://groups.google.com/d/msg/mozilla.addons.user-experience/3bAaITHf1Xo/b_G-v7QgAwAJ
Nothing after this — where I clarify the very limited scope of the
whitelist proposal — has received a response from Mozilla folks:
https://groups.google.com/d/msg/mozilla.addons.user-experience/3bAaITHf1Xo/ulnmgVeaAwAJ
My comments on the whitelist rules are here:
https://groups.google.com/d/msg/mozilla.addons.user-experience/3bAaITHf1Xo/61siUR0cBgAJ
We'd appreciate a response.
Jorge Villalobos
Nov 16, 2015, 6:43:56 PM11/16/15
to mozilla-addons-...@lists.mozilla.org
to respond tomorrow.
Jorge
0 new messages