Hi Jonathan, I'm sorry if my message seemed dismissive. I was not trying to suggest we should not take any action. Opinions are my own. This is not the Thunderbird leadership perspective, nor would engineering decisions such as these be a good topic to discuss within the council. Whatever comes out of this should be a joint decision of those on this list, and if there needs to be a final decision of sorts, it would be up to the Thunderbird module owner. From my own purely anecdotal perspective the scam warning has been helpful to me, and I have not been getting many false positives. Just based on my experience I would not want to see it go. Then again I can understand that it may be useful to flip the default if it does not prove to be effective. And you've provided some great data points to investigate further. A concern I have is the messaging. If we turn off a feature called "detect suspected scam" by default, a new user reading their preferences would likely go ahead and enable it without question. Marking it as experimental does not sound right for a release, and I think removing it would be too drastic. Therefore my preferred approach would be to start with some quick, actionable improvements (if there are any), and see if we can get people interested. Long term improvements may be an interesting thesis topic for a student, and there may be a partnership opportunities or some other options worth considering. Philipp > On 14. Jul 2018, at 8:16 PM, Jonathan Kamens <jik@kamens.us> wrote: > > I've already explained why an alert with a high false positive and low true positive rate makes people more likely to fall for the thing the alert is trying to protect against. I explained it in the very message to which you replied. > > This is accepted wisdom in the security community. It also seems patently obvious to me as someone who has worked in this field for 30 years. > > It seems clear at this point that the folks making the decisions about what to do about this issue are not going to listen to the data, the feedback from users, or the experienced experts. I will therefore bow out of this discussion now so as not to waste more of my time or yours. > > Regards, > jik >> On 7/14/18 2:09 PM, Josiah Bruner wrote: >> For the record my proposed experiment does not test for alert fatigue. I'm well aware of that research and I'm sure almost everyone agrees with it. >> >> My experiment tests for whether people with scam detection enabled fall for phishing emails *more often* than those with it disabled. (this is the main argument is the bug for disabling) >> >> As far as I'm aware there is no such research available. If you have counter examples though, please share. >> >> Regards, >> Josiah >> >>> On Sat, Jul 14, 2018, 1:21 PM Jonathan Kamens <jik@kamens.us> wrote: >>> Oh, I forgot one more thing that I wanted to point out. The other risk of a scam detector with a low success rate and a high false positive rate is that it gives people a false sense of security. They see the scam detector triggering frequently enough that they know it's there and think that a high false positive rate must also mean that it does a good job of detecting real scams, and that makes them more likely to click on the link when they receive a scam that the detector doesn't flag. >>> >>> In short, the scam detector really is doing more harm than good in its current form. >>> jik >>>> On 7/14/18 1:17 PM, Jonathan Kamens wrote: >>>> OK, so if you want to dismiss the experiences of people commenting on the bug as anecdotal, then here's some hard data to consider. >>>> >>>> I save all of my spam / scam messages and legitimate email messages going back for several months so that I can retrain my Bayesian spam filter when it proves necessary to do so. I was therefore able to conduct the following experiment. >>>> I scanned 4,703 spam / scam messages I received between April 13 and July 13 (92 days) to find out which of them Thunderbird would flag as a scam. It flagged 38 of them, a success rate of 0.8%. Not all of the messages in question were ones that I would expect a scam detector to flag, but most of them are, so I would certainly not consider a scam detector that only flags 0.8% of my spam messages as scams as particularly useful or accurate. >>>> >>>> More significantly, I also scanned 12,860 legitimate email messages which I received between February 13 and July 13 (151 days) to find out which of them Thunderbird would flag falsely as a scam. It flagged 105 of them, a rate of 0.82%. The difference of only 0.02% between the false positive rate and the true positive rate seems to imply that it's pretty much a crap-shoot whether the scam detector is accurate for any particular message. >>>> >>>> Note that most of the known spam / scam messages which I fed through the scam detector were detected and filtered out by my spam filter when I first received them, i.e., I never actually saw them in my inbox. If a user is using any halfway decent spam detector, then they will have a similar experience. That means that they are likely to see far more false positives than true positives from the scam detector. >>>> >>>> In another message in this thread, Josiah proposed a UX experiment to determine whether a a lot of false positives from the scam detector are influencing people to ignore its warnings. With all due respect to Josiah, we don't need to do that research. The research has already been done. It's well-established in the cybersecurity field (about which I can speak with some conviction, seeing as how I've been working in cybersecurity for nearly 30 years and I'm currently a CISO) that alert fatigue causes alerts to be ignored. Furthermore, alert fatigue bleeds between applications, which means that by generating a lot of false positives in Thunderbird, we're making it more likely that people will ignore real alerts from other applications. This is not good for anyone. >>>> >>>> Frankly, if Thunderbird's spam filter is halfway decent (and I don't know whether it is, because as I said previously, I use bogofilter), it is probably going to do a far better job of filtering out scams than Thunderbird's current scam detector, and given the accuracy of the detector as illustrated above, I'd advocate ditching it entirely and sticking with just the spam filter. >>>> >>>> So, I've now presented hard data illustrating just how bad the scam detector's performance is. Are we still going to insist that we shouldn't take any action because we only have anecdotal data to work with? >>>> >>>> Jonathan Kamens >>>>> On 7/13/18 2:35 PM, Philipp Kewisch wrote: >>>>> Hi Folks, >>>>> >>>>> I do get this on a few messages from people I know, but all in all, is there is something that tells me a link does not have the same target it seems to have, that alone would be enough for me to have it enabled. >>>>> >>>>> Both sides are purely anecdotal iiuc, so telemetry data would be great. Unfortunately I believe it is not set up correctly, so gathering data is a little more involved. >>>>> >>>>> I am certain though we shouldn't just go turn it off because of a hunch. >>>>> >>>>> Philipp >>>>> >>>>> On 13. Jul 2018, at 6:59 PM, Jonathan Kamens <jik@kamens.us> wrote: >>>>> >>>>>> I agree with the many commenters there who have argued that extremely inaccurate scam detection is in fact worse than no scam detection at all, and if indeed it is as inaccurate as people there are claiming it is, it should be turned off by default. >>>>>> >>>>>> Personally, I use bogofilter on my mail server, which catches the vast majority of spam and phishing emails before I ever see them with a very low false-positive rate, so the first thing I do whenever setting up a new Thunderbird profile is disable the spam and scam detection engines in Thunderbird. Therefore, I don't have any first-hand experience speaking to whether the claims of inaccuracy in that ticket are accurate. >>>>>> The thing about Wayne's "We should fix it rather than replace it" argument (in comment 93) is that we need to recognize the reality that the resources currently available for substantive Thunderbird development are extraordinarily limited, so unless this issue is bounced to the top of the priority list, it's not going to get any developer work directed at it for a long time. Given that, it really should be turned off if it's so inaccurate that it gives users bad information more often than good. >>>>>> >>>>>> I suppose there is a third alternative, which may or may have been suggested in that ticket (frankly, I'm not going to read over 100 comments to find out). I'm under the impression that Thunderbird's Telemetry support allows the app to capture information about what users do and transmit it anonymously to the developers to give them a better idea about how the app is being used and guide future changes. A good start would be to capture Telemetry support about how often TB marks a message as a potential scam, how often users click the button telling TB that a message in fact is not a scam, and how often users click the button telling TB that a message which wasn't classified as such is a scam (the latter statistic would need to be taken much less seriously than the others, though, since the most likely outcome of a user recognizing a scam message as such is to delete it). That Telemetry data might give us a better idea of how accurate the scam detector is. >>>>>> >>>>>> Regarding the question of how to build a better scam detector, as comment 97 points out, there is a lot of good research into how to build effective scam detectors, so I would suggest the first step in any effort to build a better scam detector into TB would be to consult the research and the experts. >>>>>> >>>>>> Or recognize that spam / scam detection is actually the job of the MTA, not the MUA, and therefore we should get rid of all the spam and scam detection functionality in TB and tell people who want it to switch to a better mail service provider if theirs isn't doing a good job of filtering. >>>>>> >>>>>> jik >>>>>>> On 7/13/18 11:59 AM, Ryan Sipes wrote: >>>>>>> Fellow Thunder Flock Members, >>>>>>> >>>>>>> A long standing bug has been brought to my attention regarding false >>>>>>> positives in scam detection: >>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=623198 >>>>>>> >>>>>>> I wanted to post this bug here and see if anyone on this list had ideas >>>>>>> on how to address this. Do you think we should keep scam detection >>>>>>> enabled? If so, are there any ways to improve scam detection so that >>>>>>> there are not so many false positives? >>>>>>> >>>>>>> Thoughts and feedback appreciated. >>>>>>> >>>>>> _______________________________________________ >>>>>> Maildev mailing list >>>>>> Maildev@lists.thunderbird.net >>>>>> http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net >>> _______________________________________________ >>> Maildev mailing list >>> Maildev@lists.thunderbird.net >>> http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

I too find it useful with little false positives. nobody disputes that it desperately needs improvement. but that does not mean removal. I'd rather hear some concrete suggestions how we can improve the algorithm. there should be some low hanging fruit, given how primitive the algo is. it should not be hard to implement, either. note that both the false positive and the false negative rates could be improved, each with different approaches. Am 15. Juli 2018 09:28:13 MESZ schrieb Philipp Kewisch <kewisch@thunderbird.net>: >Hi Jonathan, > >I'm sorry if my message seemed dismissive. I was not trying to suggest >we should not take any action. Opinions are my own. This is not the >Thunderbird leadership perspective, nor would engineering decisions >such as these be a good topic to discuss within the council. Whatever >comes out of this should be a joint decision of those on this list, and >if there needs to be a final decision of sorts, it would be up to the >Thunderbird module owner. > >From my own purely anecdotal perspective the scam warning has been >helpful to me, and I have not been getting many false positives. Just >based on my experience I would not want to see it go. > >Then again I can understand that it may be useful to flip the default >if it does not prove to be effective. And you've provided some great >data points to investigate further. > >A concern I have is the messaging. If we turn off a feature called >"detect suspected scam" by default, a new user reading their >preferences would likely go ahead and enable it without question. >Marking it as experimental does not sound right for a release, and I >think removing it would be too drastic. > >Therefore my preferred approach would be to start with some quick, >actionable improvements (if there are any), and see if we can get >people interested. Long term improvements may be an interesting thesis >topic for a student, and there may be a partnership opportunities or >some other options worth considering. > >Philipp > > >> On 14. Jul 2018, at 8:16 PM, Jonathan Kamens <jik@kamens.us> wrote: >> >> I've already explained why an alert with a high false positive and >low true positive rate makes people more likely to fall for the thing >the alert is trying to protect against. I explained it in the very >message to which you replied. >> >> This is accepted wisdom in the security community. It also seems >patently obvious to me as someone who has worked in this field for 30 >years. >> >> It seems clear at this point that the folks making the decisions >about what to do about this issue are not going to listen to the data, >the feedback from users, or the experienced experts. I will therefore >bow out of this discussion now so as not to waste more of my time or >yours. >> >> Regards, >> jik >>> On 7/14/18 2:09 PM, Josiah Bruner wrote: >>> For the record my proposed experiment does not test for alert >fatigue. I'm well aware of that research and I'm sure almost everyone >agrees with it. >>> >>> My experiment tests for whether people with scam detection enabled >fall for phishing emails *more often* than those with it disabled. >(this is the main argument is the bug for disabling) >>> >>> As far as I'm aware there is no such research available. If you have >counter examples though, please share. >>> >>> Regards, >>> Josiah >>> >>>> On Sat, Jul 14, 2018, 1:21 PM Jonathan Kamens ><jik@kamens.us> wrote: >>>> Oh, I forgot one more thing that I wanted to point out. The other >risk of a scam detector with a low success rate and a high false >positive rate is that it gives people a false sense of security. They >see the scam detector triggering frequently enough that they know it's >there and think that a high false positive rate must also mean that it >does a good job of detecting real scams, and that makes them more >likely to click on the link when they receive a scam that the detector >doesn't flag. >>>> >>>> In short, the scam detector really is doing more harm than good in >its current form. >>>> jik >>>>> On 7/14/18 1:17 PM, Jonathan Kamens wrote: >>>>> OK, so if you want to dismiss the experiences of people commenting >on the bug as anecdotal, then here's some hard data to consider. >>>>> >>>>> I save all of my spam / scam messages and legitimate email >messages going back for several months so that I can retrain my >Bayesian spam filter when it proves necessary to do so. I was therefore >able to conduct the following experiment. >>>>> I scanned 4,703 spam / scam messages I received between April 13 >and July 13 (92 days) to find out which of them Thunderbird would flag >as a scam. It flagged 38 of them, a success rate of 0.8%. Not all of >the messages in question were ones that I would expect a scam detector >to flag, but most of them are, so I would certainly not consider a scam >detector that only flags 0.8% of my spam messages as scams as >particularly useful or accurate. >>>>> >>>>> More significantly, I also scanned 12,860 legitimate email >messages which I received between February 13 and July 13 (151 days) to >find out which of them Thunderbird would flag falsely as a scam. It >flagged 105 of them, a rate of 0.82%. The difference of only 0.02% >between the false positive rate and the true positive rate seems to >imply that it's pretty much a crap-shoot whether the scam detector is >accurate for any particular message. >>>>> >>>>> Note that most of the known spam / scam messages which I fed >through the scam detector were detected and filtered out by my spam >filter when I first received them, i.e., I never actually saw them in >my inbox. If a user is using any halfway decent spam detector, then >they will have a similar experience. That means that they are likely to >see far more false positives than true positives from the scam >detector. >>>>> >>>>> In another message in this thread, Josiah proposed a UX experiment >to determine whether a a lot of false positives from the scam detector >are influencing people to ignore its warnings. With all due respect to >Josiah, we don't need to do that research. The research has already >been done. It's well-established in the cybersecurity field (about >which I can speak with some conviction, seeing as how I've been working >in cybersecurity for nearly 30 years and I'm currently a CISO) that >alert fatigue causes alerts to be ignored. Furthermore, alert fatigue >bleeds between applications, which means that by generating a lot of >false positives in Thunderbird, we're making it more likely that people >will ignore real alerts from other applications. This is not good for >anyone. >>>>> >>>>> Frankly, if Thunderbird's spam filter is halfway decent (and I >don't know whether it is, because as I said previously, I use >bogofilter), it is probably going to do a far better job of filtering >out scams than Thunderbird's current scam detector, and given the >accuracy of the detector as illustrated above, I'd advocate ditching it >entirely and sticking with just the spam filter. >>>>> >>>>> So, I've now presented hard data illustrating just how bad the >scam detector's performance is. Are we still going to insist that we >shouldn't take any action because we only have anecdotal data to work >with? >>>>> >>>>> Jonathan Kamens >>>>>> On 7/13/18 2:35 PM, Philipp Kewisch wrote: >>>>>> Hi Folks, >>>>>> >>>>>> I do get this on a few messages from people I >know, but all in all, is there is something that tells me a link does >not have the same target it seems to have, that alone would be enough >for me to have it enabled. >>>>>> >>>>>> Both sides are purely anecdotal iiuc, so telemetry data would be >great. Unfortunately I believe it is not set up correctly, so gathering >data is a little more involved. >>>>>> >>>>>> I am certain though we shouldn't just go turn it off because of a >hunch. >>>>>> >>>>>> Philipp >>>>>> >>>>>> On 13. Jul 2018, at 6:59 PM, Jonathan Kamens <jik@kamens.us> >wrote: >>>>>> >>>>>>> I agree with the many commenters there who have argued that >extremely inaccurate scam detection is in fact worse than no scam >detection at all, and if indeed it is as inaccurate as people there are >claiming it is, it should be turned off by default. >>>>>>> >>>>>>> Personally, I use bogofilter on my mail server, which catches >the vast majority of spam and phishing emails before I ever see them >with a very low false-positive rate, so the first thing I do whenever >setting up a new Thunderbird profile is disable the spam and scam >detection engines in Thunderbird. Therefore, I don't have any >first-hand experience speaking to whether the claims of inaccuracy in >that ticket are accurate. >>>>>>> The thing about Wayne's "We should fix it rather than replace >it" argument (in comment 93) is that we need to recognize the reality >that the resources currently available for substantive Thunderbird >development are extraordinarily limited, so unless this issue is >bounced to the top of the priority list, it's not going to get any >developer work directed at it for a long time. Given that, it really >should be turned off if it's so inaccurate that it gives users bad >information more often than good. >>>>>>> >>>>>>> I suppose there is a third alternative, which may or may have >been suggested in that ticket (frankly, I'm not going to read over 100 >comments to find out). I'm under the impression that Thunderbird's >Telemetry support allows the app to capture information about what >users do and transmit it anonymously to the developers to give them a >better idea about how the app is being used and guide future changes. A >good start would be to capture Telemetry support about how often TB >marks a message as a potential scam, how often users click the button >telling TB that a message in fact is not a scam, and how often users >click the button telling TB that a message which wasn't classified as >such is a scam (the latter statistic would >need to be taken much less seriously than the others, though, since the >most likely outcome of a user recognizing a scam message as such is to >delete it). That Telemetry data might give us a better idea of how >accurate the scam detector is. >>>>>>> >>>>>>> Regarding the question of how to build a better scam detector, >as comment 97 points out, there is a lot of >good research into how to build effective scam detectors, so I would >suggest the first step in any effort to build a better scam detector >into TB would be to consult the research and the experts. >>>>>>> >>>>>>> Or recognize that spam / scam detection is actually the job of >the MTA, not the MUA, and therefore we should get rid of all the spam >and scam detection functionality in TB and tell people who want it to >switch to a better mail service provider if theirs isn't doing a good >job of filtering. >>>>>>> >>>>>>> jik >>>>>>>> On 7/13/18 11:59 AM, Ryan Sipes wrote: >>>>>>>> Fellow Thunder Flock Members, >>>>>>>> >>>>>>>> A long standing bug has been brought to my attention regarding >false >>>>>>>> positives in scam detection: >>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=623198 >>>>>>>> >>>>>>>> I wanted to post this bug here and see if anyone on this list >had ideas >>>>>>>> on how to address this. Do you think we should keep scam >detection >>>>>>>> enabled? If so, are there any ways to improve scam detection so >that >>>>>>>> there are not so many false positives? >>>>>>>> >>>>>>>> Thoughts and feedback appreciated. >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Maildev mailing list >>>>>>> Maildev@lists.thunderbird.net >>>>>>> >http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net >>>> _______________________________________________ >>>> Maildev mailing list >>>> Maildev@lists.thunderbird.net >>>> >http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net -- Sent from my phone. Please excuse the brevity.

Hi Jon, thanks for the test and sharing the results with us. i find your numbers useful. however, i have 2 comments: 1. your test lumps together spam and scam, and that unfortunately completely falsifies the result, because a) there is more spam than real scam, b) the spam filter already removes the email, so the scam filter is no longer needed for these messages. the scam warning is specifically for those messages that the spam filter did not catch. your post already mentioned that very fact, however your conclusion is wrong: this could improve the scam filter hit rate, because the number of messages is lower, but the number of detected scams might stay the same or shrink less. the right positive hit rate would be: all messages, which are manually verified as scam, which the spam filter does not catch, but which the thunderbird scam filter detected. 2. even if the current thunderbird scam filter would indeed factually do more harm than good, it does not imply that the right action is to remove it. but rather to improve it. that said, thanks for the data. please keep it coming. Ben Am 14. Juli 2018 19:17:16 MESZ schrieb Jonathan Kamens <jik@kamens.us>: >OK, so if you want to dismiss the experiences of people commenting on >the bug as anecdotal, then here's some hard data to consider. > >I save all of my spam / scam messages and legitimate email messages >going back for several months so that I can retrain my Bayesian spam >filter when it proves necessary to do so. I was therefore able to >conduct the following experiment. > >I scanned 4,703 spam / scam messages I received between April 13 and >July 13 (92 days) to find out which of them Thunderbird would flag as a > >scam. It flagged 38 of them, a success rate of 0.8%. Not all of the >messages in question were ones that I would expect a scam detector to >flag, but most of them are, so I would certainly not consider a scam >detector that only flags 0.8% of my spam messages as scams as >particularly useful or accurate. > >More significantly, I also scanned 12,860 legitimate email messages >which I received between February 13 and July 13 (151 days) to find out > >which of them Thunderbird would flag falsely as a scam. It flagged 105 >of them, a rate of 0.82%. The difference of only 0.02% between the >false >positive rate and the true positive rate seems to imply that it's >pretty >much a crap-shoot whether the scam detector is accurate for any >particular message. > >Note that most of the known spam / scam messages which I fed through >the >scam detector were detected and filtered out by my spam filter when I >first received them, i.e., I never actually saw them in my inbox. If a >user is using any halfway decent spam detector, then they will have a >similar experience. That means that they are likely to see far more >false positives than true positives from the scam detector. > >In another message in this thread, Josiah proposed a UX experiment to >determine whether a a lot of false positives from the scam detector are > >influencing people to ignore its warnings. With all due respect to >Josiah, we don't need to do that research. The research has already >been >done. It's well-established in the cybersecurity field (about which I >can speak with some conviction, seeing as how I've been working in >cybersecurity for nearly 30 years and I'm currently a CISO) that alert >fatigue causes alerts to be ignored. Furthermore, alert fatigue bleeds >between applications, which means that by generating a lot of false >positives in Thunderbird, we're making it more likely that people will >ignore real alerts from other applications. This is not good for >anyone. > >Frankly, if Thunderbird's spam filter is halfway decent (and I don't >know whether it is, because as I said previously, I use bogofilter), it > >is probably going to do a far//better job of filtering out scams than >Thunderbird's current scam detector, and given the accuracy of the >detector as illustrated above, I'd advocate ditching it entirely and >sticking with just the spam filter. > >So, I've now presented hard data illustrating just how bad the scam >detector's performance is. Are we still going to insist that we >shouldn't take any action because we only have anecdotal data to work >with? > >   Jonathan Kamens > >On 7/13/18 2:35 PM, Philipp Kewisch wrote: >> Hi Folks, >> >> I do get this on a few messages from people I know, but all in all, >is >> there is something that tells me a link does not have the same target > >> it seems to have, that alone would be enough for me to have it >enabled. >> >> Both sides are purely anecdotal iiuc, so telemetry data would be >> great. Unfortunately I believe it is not set up correctly, so >> gathering data is a little more involved. >> >> I am certain though we shouldn't just go turn it off because of a >hunch. >> >> Philipp >> >> On 13. Jul 2018, at 6:59 PM, Jonathan Kamens <jik@kamens.us >> <mailto:jik@kamens.us>> wrote: >> >>> I agree with the many commenters there who have argued that >extremely >>> inaccurate scam detection is in fact worse than no scam detection at > >>> all, and if indeed it is as inaccurate as people there are claiming >>> it is, it should be turned off by default. >>> >>> Personally, I use bogofilter on my mail server, which catches the >>> vast majority of spam and phishing emails before I ever see them >with >>> a very low false-positive rate, so the first thing I do whenever >>> setting up a new Thunderbird profile is disable the spam and scam >>> detection engines in Thunderbird. Therefore, I don't have any >>> first-hand experience speaking to whether the claims of inaccuracy >in >>> that ticket are accurate. >>> >>> The thing about Wayne's "We should fix it rather than replace it" >>> argument (in comment 93 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=623198#c93>) is that >we >>> need to recognize the reality that the resources currently available > >>> for substantive Thunderbird development are extraordinarily limited, > >>> so unless this issue is bounced to the top of the priority list, >it's >>> not going to get any developer work directed at it for a long time. >>> Given that, it really should be turned off if it's so inaccurate >that >>> it gives users bad information more often than good. >>> >>> I suppose there is a third alternative, which may or may have been >>> suggested in that ticket (frankly, I'm not going to read over 100 >>> comments to find out). I'm under the impression that Thunderbird's >>> Telemetry support allows the app to capture information about what >>> users do and transmit it anonymously to the developers to give them >a >>> better idea about how the app is being used and guide future >changes. >>> A good start would be to capture Telemetry support about how often >TB >>> marks a message as a potential scam, how often users click the >button >>> telling TB that a message in fact is not a scam, and how often users > >>> click the button telling TB that a message which wasn't classified >as >>> such is a scam (the latter statistic would need to be taken much >less >>> seriously than the others, though, since the most likely outcome of >a >>> user recognizing a scam message as such is to delete it). That >>> Telemetry data might give us a better idea of how accurate the scam >>> detector is. >>> >>> Regarding the question of how to build a better scam detector, as >>> comment 97 <https://bugzilla.mozilla.org/show_bug.cgi?id=623198> >>> points out, there is a lot of good research into how to build >>> effective scam detectors, so I would suggest the first step in any >>> effort to build a better scam detector into TB would be to consult >>> the research and the experts. >>> >>> Or recognize that spam / scam detection is actually the job of the >>> MTA, not the MUA, and therefore we should get rid of all the spam >and >>> scam detection functionality in TB and tell people who want it to >>> switch to a better mail service provider if theirs isn't doing a >good >>> job of filtering. >>> >>>   jik >>> >>> On 7/13/18 11:59 AM, Ryan Sipes wrote: >>>> Fellow Thunder Flock Members, >>>> >>>> A long standing bug has been brought to my attention regarding >false >>>> positives in scam detection: >>>> https://bugzilla.mozilla.org/show_bug.cgi?id=623198 >>>> >>>> I wanted to post this bug here and see if anyone on this list had >ideas >>>> on how to address this. Do you think we should keep scam detection >>>> enabled? If so, are there any ways to improve scam detection so >that >>>> there are not so many false positives? >>>> >>>> Thoughts and feedback appreciated. >>>> >>> _______________________________________________ >>> Maildev mailing list >>> Maildev@lists.thunderbird.net <mailto:Maildev@lists.thunderbird.net> >>> >http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net -- Sent from my phone. Please excuse the brevity.

 OK, so if you want to dismiss the experiences of people commenting
 on the bug as anecdotal, then here's some hard data to consider.

 I save all of my spam / scam messages and legitimate email
 messages going back for several months so that I can retrain my
 Bayesian spam filter when it proves necessary to do so. I was
 therefore able to conduct the following experiment.

 I scanned 4,703 spam / scam messages I received between April 13
 and July 13 (92 days) to find out which of them Thunderbird would
 flag as a scam. It flagged 38 of them, a success rate of 0.8%. Not
 all of the messages in question were ones that I would expect a
 scam detector to flag, but most of them are, so I would certainly
 not consider a scam detector that only flags 0.8% of my spam
 messages as scams as particularly useful or accurate.

 More significantly, I also scanned 12,860 legitimate email
 messages which I received between February 13 and July 13 (151
 days) to find out which of them Thunderbird would flag falsely as
 a scam. It flagged 105 of them, a rate of 0.82%. The difference of
 only 0.02% between the false positive rate and the true positive
 rate seems to imply that it's pretty much a crap-shoot whether the
 scam detector is accurate for any particular message.

 Note that most of the known spam / scam messages which I fed
 through the scam detector were detected and filtered out by my
 spam filter when I first received them, i.e., I never actually saw
 them in my inbox. If a user is using any halfway decent spam
 detector, then they will have a similar experience. That means
 that they are likely to see far more false positives than true
 positives from the scam detector.

 In another message in this thread, Josiah proposed a UX experiment
 to determine whether a a lot of false positives from the scam
 detector are influencing people to ignore its warnings. With all
 due respect to Josiah, we don't need to do that research. The
 research has already been done. It's well-established in the
 cybersecurity field (about which I can speak with some conviction,
 seeing as how I've been working in cybersecurity for nearly 30
 years and I'm currently a CISO) that alert fatigue causes alerts
 to be ignored. Furthermore, alert fatigue bleeds between
 applications, which means that by generating a lot of false
 positives in Thunderbird, we're making it more likely that people
 will ignore real alerts from other applications. This is not good
 for anyone.

 Frankly, if Thunderbird's spam filter is halfway decent (and I
 don't know whether it is, because as I said previously, I use
 bogofilter), it is probably going to do a far//better job of
 filtering out scams than Thunderbird's current scam detector, and
 given the accuracy of the detector as illustrated above, I'd
 advocate ditching it entirely and sticking with just the spam filter.

 So, I've now presented hard data illustrating just how bad the
 scam detector's performance is. Are we still going to insist that
 we shouldn't take any action because we only have anecdotal data
 to work with?

   Jonathan Kamens

 On 7/13/18 2:35 PM, Philipp Kewisch wrote:

 Hi Folks,

 I do get this on a few messages from people I know, but all in
 all, is there is something that tells me a link does not have the
 same target it seems to have, that alone would be enough for me
 to have it enabled.

 Both sides are purely anecdotal iiuc, so telemetry data would be
 great. Unfortunately I believe it is not set up correctly, so
 gathering data is a little more involved.

 I am certain though we shouldn't just go turn it off because of a
 hunch.

 Philipp

 On 13. Jul 2018, at 6:59 PM, Jonathan Kamens <jik@kamens.us
 <mailto:jik@kamens.us>> wrote:

 I agree with the many commenters there who have argued that
 extremely inaccurate scam detection is in fact worse than no
 scam detection at all, and if indeed it is as inaccurate as
 people there are claiming it is, it should be turned off by default.

 Personally, I use bogofilter on my mail server, which catches
 the vast majority of spam and phishing emails before I ever see
 them with a very low false-positive rate, so the first thing I
 do whenever setting up a new Thunderbird profile is disable the
 spam and scam detection engines in Thunderbird. Therefore, I
 don't have any first-hand experience speaking to whether the
 claims of inaccuracy in that ticket are accurate.

 The thing about Wayne's "We should fix it rather than replace
 it" argument (in comment 93
 <https://bugzilla.mozilla.org/show_bug.cgi?id=623198#c93>) is
 that we need to recognize the reality that the resources
 currently available for substantive Thunderbird development are
 extraordinarily limited, so unless this issue is bounced to the
 top of the priority list, it's not going to get any developer
 work directed at it for a long time. Given that, it really
 should be turned off if it's so inaccurate that it gives users
 bad information more often than good.

 I suppose there is a third alternative, which may or may have
 been suggested in that ticket (frankly, I'm not going to read
 over 100 comments to find out). I'm under the impression that
 Thunderbird's Telemetry support allows the app to capture
 information about what users do and transmit it anonymously to
 the developers to give them a better idea about how the app is
 being used and guide future changes. A good start would be to
 capture Telemetry support about how often TB marks a message as
 a potential scam, how often users click the button telling TB
 that a message in fact is not a scam, and how often users click
 the button telling TB that a message which wasn't classified as
 such is a scam (the latter statistic would need to be taken much
 less seriously than the others, though, since the most likely
 outcome of a user recognizing a scam message as such is to
 delete it). That Telemetry data might give us a better idea of
 how accurate the scam detector is.

 Regarding the question of how to build a better scam detector,
 as comment 97
 <https://bugzilla.mozilla.org/show_bug.cgi?id=623198> points
 out, there is a lot of good research into how to build effective
 scam detectors, so I would suggest the first step in any effort
 to build a better scam detector into TB would be to consult the
 research and the experts.

 Or recognize that spam / scam detection is actually the job of
 the MTA, not the MUA, and therefore we should get rid of all the
 spam and scam detection functionality in TB and tell people who
 want it to switch to a better mail service provider if theirs
 isn't doing a good job of filtering.

   jik

 On 7/13/18 11:59 AM, Ryan Sipes wrote:

 Fellow Thunder Flock Members,

 A long standing bug has been brought to my attention regarding false
 positives in scam detection:
 https://bugzilla.mozilla.org/show_bug.cgi?id=623198

 I wanted to post this bug here and see if anyone on this list had ideas
 on how to address this. Do you think we should keep scam detection
 enabled? If so, are there any ways to improve scam detection so that
 there are not so many false positives?

 Thoughts and feedback appreciated.

 _______________________________________________
 Maildev mailing list
 Maildev@lists.thunderbird.net <mailto:Maildev@lists.thunderbird.net>
 http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net

1) The discussion I thought we were having here is about what we should do about the scam detector until a developer is able to devote some time to identifying ways it can be improved. I don't think it's particularly helpful or useful assert -- as several people have -- that surely we could find some easy wins if someone spent some time looking at the code. First of all, no one has offered any evidence that such easy wins exist, and second of all, no one has actually volunteered to spend some time looking at the code. Absent such a volunteer, we have to assume that like so many other bugs that have been growing mold for many years in Bugzilla, no one is going to do any work on this one in the foreseeable future, which brings us back to the discussion I think we need to be having: /without any improvements to the scam filter,/ is it better to leave it turned on or turn it off? Anyone who feels like proving me wrong can just go ahead and volunteer to spend some time working on the code in the short term. That would be great. I'm sure all of us would appreciate it. 2) People here have criticized the folks who've commented on the bug for offering only "anecdotal" evidence to support their claims that the scam detector has too many false positives. Many of these same people have commented on how they find the scam detector useful because it doesn't have too many false positives for them. Guess what, folks, THAT'S ENTIRELY ANECDOTAL TOO. If you're going to reject the anecdotal experiences of the people who think the detector should be turned off, then you can't turn around and offer your own entirely anecdotal experience as somehow more valid and relevant than theirs. I am the only person in this discussion who has made any effort at all to collect and present hard data (and, by the way, it took me quite a few hours to produce that data). So, you have two choices: you can either accept that the anecdotal experiences of people commenting on that bug are actually relevant, since USER EXPERIENCE MATTERS, or you can stop using your own anecdotal experience as an argument in support of your position. 3) Reality check: with the limited resources available to develop and maintain new functionality in Thunderbird, and with the requirement that whatever be built into Thunderbird be self-contained, cross-platform functionality, it is simply impossible that a scam detector built into Thunderbird is going to achieve accuracy that comes anywhere near that of the numerous purpose-built spam and scam detectors out there, whether they are commercial, open-source, or proprietary to individual service providers like Gmail. Trying to build a good scam detector into Thunderbird is, in my opinion, a fool's errand. You know what would be much more useful? Finding out what headers the various purpose-built scam and spam detectors put into the emails that pass through them to indicate how suspicious they are, and modifying Thunderbird to parse those headers and display warnings based on them, like it theoretically already does for SpamAssassin. 4) There is at least one Thunderbird add-on <https://addons.mozilla.org/thunderbird/addon/signal-spam/> which claims to work with the current Thunderbird extension which does spam / phishing detection based on crowdsourced reports, which is frankly far more likely to be accurate than whatever is built into Thunderbird. This seems like the perfect type of functionality to be implemented in add-ons rather than Thunderbird core. 5) Regarding Ben's rejection of my analysis, Ben, you are measuring the wrong thing. How accurate the scam detector is at detecting scams in the messages that get through the spam filter is far less important than the ratio of true to false scam detections, because the lower that ratio is, the more likely it is that the scam detector will do more harm than good, for reasons I've already explained -- a low ratio encourages users to ignore the scam detector with it goes off /and/ makes them more likely to click on a scam link when the detector /doesn't/ fire, because seeing frequent detections lures their subconscious into a false sense of security that they are being detected. 6) Having said that, Ben is correct that if the scam detector really were somewhat good at correctly flagging scams that make it through the spam filter, we could justify leaving it in place while working on an alternative, because that would imply a good enough ratio of true to false detections. So let's see if we can measure just how good it is, shall we? Because I am willing to put my money (time) where my mouth is and actually collect real data based at least on the corpus of emails that I have available, i.e., my own, I did the following: start with empty spam training data; train 1,000 random ham messages from my corpus; train 1,000 random spam messages from my corpus; ask Thunderbird to classify 1,000 other known spam / scam messages; manually divide the messages that make it through the junk filter into different categories and check how many of them get flagged as scams. The spam filter failed to catch 840 out of the 1,000 known spam / scam messages I fed into it after training. I categorized the 840 messages into the following categories: * attachment scams, i.e., emails that either hid the details of the scam in an attachment so it couldn't be detected easily by a scam detector, or included an attachment containing malware: 59 messages * email scams, i.e., scams which were trying to get you to reply by email or by some other non-link mechanism (most commonly a phone number) in the body of the email: 501 messages * link scams, i.e., scams with malicious links in them: 137 messages * "regular" spam messages, i.e., spam messages which weren't actually a scam, or at least I wasn't sufficiently convinced that they were a scam to classify them in one of the other categories: 143 messages. Note that this includes spam about products that are obviously fake or bogus, since I assume Thunderbird's scam detector isn't actually designed to prevent people from buying into bogus timeshares or bad fake Ray-Ban sunglasses. Of the 59 attachment scams, Thunderbird did not flag a single one as a potential scam. This is not surprising, because I suspect the scam detector wasn't designed to detect this type of scam, but from the user's point of view it doesn't really matter that these are a different "kind" of scam; they're still scams, so we should count them against the detector's success ratio. The scam detector also didn't flag a single one of the 501 email scam messages. This is both problematic and not surprising for the reasons outlined in the previous paragraph. The scam detector flagged exactly 1 out of the 137 messages with malicious links in them. The scam detector falsely flagged 7 out of the 143 non-scam spam messages as scams. N.B. This implies that the false-positive rate is actually higher than what I reported in the results of my previous experiment, assuming I'm correct that the scam detector is designed to flag only actual scams, not run-of-the-mill spam pitching products people aren't interested in. So, the scam detector flagged 1 out of 697 scam messages that got through the spam filter, or 0.14%. If you reject the argument I made above that attachment and email scams need to be included when calculating its success ratio, the success rate is 1 out of 137, i.e., 0.73%, which also is rather unimpressive. Note: I eyeballed many of the emails with malicious links while performing this analysis, and while it's easy enough for me to recognize that most of them are scams, I don't see any easy way for Thunderbird to do so. Most of them come from legitimate email addresses and have legitimate links in them, with the link text matching the actual link. If we start going down the road of trying to teach Thunderbird how to recognize that these emails are malicious, we'll basically be reinventing SpamAssassin. I can't even begin to imagine how that would be a good idea. Let me summarize my position: 1) I don't think we can build a good enough scam detector into Thunderbird core to justify one being there. It's not practical, and it's a waste of our limited development resources. I might change my mind if someone stepped forward and committed to building and maintaining spam / scam detection in Thunderbird to the same level of commitment that Patrick Brunschwig does for Enigmail, but I see no evidence that's going to happen. 2) All the data I have collected and presented indicates that the current scam detector is incredibly inaccurate. No one has offered data pointing to a different conclusion. 3) A bad scam detector is worse than no scam detector at all.   jik On 7/15/18 3:09 PM, Ben Bucksch wrote: > Hi Jon, > > thanks for the test and sharing the results with us. i find your > numbers useful. > > however, i have 2 comments: > 1. your test lumps together spam and scam, and that unfortunately > completely falsifies the result, because a) there is more spam than > real scam, b) the spam filter already removes the email, so the scam > filter is no longer needed for these messages. the scam warning is > specifically for those messages that the spam filter did not catch. > your post already mentioned that very fact, however your conclusion is > wrong: this could improve the scam filter hit rate, because the number > of messages is lower, but the number of detected scams might stay the > same or shrink less. the right positive hit rate would be: all > messages, which are manually verified as scam, which the spam filter > does not catch, but which the thunderbird scam filter detected. > > 2. even if the current thunderbird scam filter would indeed factually > do more harm than good, it does not imply that the right action is to > remove it. but rather to improve it. > > that said, thanks for the data. please keep it coming. > > Ben > > Am 14. Juli 2018 19:17:16 MESZ schrieb Jonathan Kamens <jik@kamens.us>: > > OK, so if you want to dismiss the experiences of people commenting > on the bug as anecdotal, then here's some hard data to consider. > > I save all of my spam / scam messages and legitimate email > messages going back for several months so that I can retrain my > Bayesian spam filter when it proves necessary to do so. I was > therefore able to conduct the following experiment. > > I scanned 4,703 spam / scam messages I received between April 13 > and July 13 (92 days) to find out which of them Thunderbird would > flag as a scam. It flagged 38 of them, a success rate of 0.8%. Not > all of the messages in question were ones that I would expect a > scam detector to flag, but most of them are, so I would certainly > not consider a scam detector that only flags 0.8% of my spam > messages as scams as particularly useful or accurate. > > More significantly, I also scanned 12,860 legitimate email > messages which I received between February 13 and July 13 (151 > days) to find out which of them Thunderbird would flag falsely as > a scam. It flagged 105 of them, a rate of 0.82%. The difference of > only 0.02% between the false positive rate and the true positive > rate seems to imply that it's pretty much a crap-shoot whether the > scam detector is accurate for any particular message. > > Note that most of the known spam / scam messages which I fed > through the scam detector were detected and filtered out by my > spam filter when I first received them, i.e., I never actually saw > them in my inbox. If a user is using any halfway decent spam > detector, then they will have a similar experience. That means > that they are likely to see far more false positives than true > positives from the scam detector. > > In another message in this thread, Josiah proposed a UX experiment > to determine whether a a lot of false positives from the scam > detector are influencing people to ignore its warnings. With all > due respect to Josiah, we don't need to do that research. The > research has already been done. It's well-established in the > cybersecurity field (about which I can speak with some conviction, > seeing as how I've been working in cybersecurity for nearly 30 > years and I'm currently a CISO) that alert fatigue causes alerts > to be ignored. Furthermore, alert fatigue bleeds between > applications, which means that by generating a lot of false > positives in Thunderbird, we're making it more likely that people > will ignore real alerts from other applications. This is not good > for anyone. > > Frankly, if Thunderbird's spam filter is halfway decent (and I > don't know whether it is, because as I said previously, I use > bogofilter), it is probably going to do a far//better job of > filtering out scams than Thunderbird's current scam detector, and > given the accuracy of the detector as illustrated above, I'd > advocate ditching it entirely and sticking with just the spam filter. > > So, I've now presented hard data illustrating just how bad the > scam detector's performance is. Are we still going to insist that > we shouldn't take any action because we only have anecdotal data > to work with? > >   Jonathan Kamens > > On 7/13/18 2:35 PM, Philipp Kewisch wrote: >> Hi Folks, >> >> I do get this on a few messages from people I know, but all in >> all, is there is something that tells me a link does not have the >> same target it seems to have, that alone would be enough for me >> to have it enabled. >> >> Both sides are purely anecdotal iiuc, so telemetry data would be >> great. Unfortunately I believe it is not set up correctly, so >> gathering data is a little more involved. >> >> I am certain though we shouldn't just go turn it off because of a >> hunch. >> >> Philipp >> >> On 13. Jul 2018, at 6:59 PM, Jonathan Kamens <jik@kamens.us >> <mailto:jik@kamens.us>> wrote: >> >>> I agree with the many commenters there who have argued that >>> extremely inaccurate scam detection is in fact worse than no >>> scam detection at all, and if indeed it is as inaccurate as >>> people there are claiming it is, it should be turned off by default. >>> >>> Personally, I use bogofilter on my mail server, which catches >>> the vast majority of spam and phishing emails before I ever see >>> them with a very low false-positive rate, so the first thing I >>> do whenever setting up a new Thunderbird profile is disable the >>> spam and scam detection engines in Thunderbird. Therefore, I >>> don't have any first-hand experience speaking to whether the >>> claims of inaccuracy in that ticket are accurate. >>> >>> The thing about Wayne's "We should fix it rather than replace >>> it" argument (in comment 93 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=623198#c93>) is >>> that we need to recognize the reality that the resources >>> currently available for substantive Thunderbird development are >>> extraordinarily limited, so unless this issue is bounced to the >>> top of the priority list, it's not going to get any developer >>> work directed at it for a long time. Given that, it really >>> should be turned off if it's so inaccurate that it gives users >>> bad information more often than good. >>> >>> I suppose there is a third alternative, which may or may have >>> been suggested in that ticket (frankly, I'm not going to read >>> over 100 comments to find out). I'm under the impression that >>> Thunderbird's Telemetry support allows the app to capture >>> information about what users do and transmit it anonymously to >>> the developers to give them a better idea about how the app is >>> being used and guide future changes. A good start would be to >>> capture Telemetry support about how often TB marks a message as >>> a potential scam, how often users click the button telling TB >>> that a message in fact is not a scam, and how often users click >>> the button telling TB that a message which wasn't classified as >>> such is a scam (the latter statistic would need to be taken much >>> less seriously than the others, though, since the most likely >>> outcome of a user recognizing a scam message as such is to >>> delete it). That Telemetry data might give us a better idea of >>> how accurate the scam detector is. >>> >>> Regarding the question of how to build a better scam detector, >>> as comment 97 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=623198> points >>> out, there is a lot of good research into how to build effective >>> scam detectors, so I would suggest the first step in any effort >>> to build a better scam detector into TB would be to consult the >>> research and the experts. >>> >>> Or recognize that spam / scam detection is actually the job of >>> the MTA, not the MUA, and therefore we should get rid of all the >>> spam and scam detection functionality in TB and tell people who >>> want it to switch to a better mail service provider if theirs >>> isn't doing a good job of filtering. >>> >>>   jik >>> >>> On 7/13/18 11:59 AM, Ryan Sipes wrote: >>>> Fellow Thunder Flock Members, >>>> >>>> A long standing bug has been brought to my attention regarding false >>>> positives in scam detection: >>>> https://bugzilla.mozilla.org/show_bug.cgi?id=623198 >>>> >>>> I wanted to post this bug here and see if anyone on this list had ideas >>>> on how to address this. Do you think we should keep scam detection >>>> enabled? If so, are there any ways to improve scam detection so that >>>> there are not so many false positives? >>>> >>>> Thoughts and feedback appreciated. >>>> >>> _______________________________________________ >>> Maildev mailing list >>> Maildev@lists.thunderbird.net <mailto:Maildev@lists.thunderbird.net> >>> http://lists.thunderbird.net/mailman/listinfo/maildev_lists.thunderbird.net > > > -- > Sent from my phone. Please excuse the brevity.