Closed Bug 623198 Opened 15 years ago Closed 6 years ago

Improve UI to workaround scam detection generating too many false positives

Categories

(Thunderbird :: Security, enhancement)

Product:
Thunderbird
Component:
Security
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: bugzilla, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: privacy)

Attachments

(5 files, 4 obsolete files)

Flip the checkbox default
1.04 KB, patch
bwinton
: ui-review-
Details | Diff | Splinter Review
Screenshot of scam notification [bug 653103]
5.19 KB, image/png
Details
Screenshot of button version
5.29 KB, image/png
Details
Screenshot of new link version
5.13 KB, image/png
Details
Plain-text email falsely marked as scam
14.67 KB, text/plain
Details
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.19 Safari/534.13 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 Regularly, several times a day, Thunderbird will claim that it thinks "This message may be a scam." It is never clear why it thinks this (it would be good if this was documented somewhere), but so far it has never been right. I've had dozens of such warnings for perfectly legitimate emails, and *not once* have I had it for an actual scam. This means that the detection logic is apparently bad at detecting actual scams and has been degraded so much in order to make it catch some actual scams that it generates an enormous amounts of false positives in the process. This makes it completely useless, since nobody will believe it anymore when it says a message may be a scam. It's the "boy who cried wolf" syndrome. The net effect on security is probably negative. People who don't rely on it gain no extra security, while people who do rely on it may not themselves scrutinize messages enough anymore and may therefore be more likely to be deceived by one of the many scams not detected by Thunderbird. This is a hard problem. Any time the positives far outnumber the negatives an algorithm that generates even a small percentage of false positives will be useless. I think the scam detection should therefore be turned off, or vastly improved (which I don't think is possible). Reproducible: Sometimes Steps to Reproduce: Monitor incoming messages. Actual Results: Many legitimate messages will be labelled as scams, and very few actual scams will be. Expected Results: Legitimate messages should not be marked as scams, and actual scams should be.
Version: unspecified → 3.1
Bryan do you have thoughts on that ?
Exactly as described, this is a big problem. As I understand it the problem is fairly difficult to solve well, like spam, and so we get it wrong a lot. It would be really great to get this fixed. I'm assuming there is already some existing bugs about improving the performance of the scam link detection.
xref bug 265226 Probably should consider some pref breakout there, IE existing checks or new checks provided there, or both.
Could be assume that this is a dupe of bug #320351 ?
@Aureliano: I'm not sure it's a dupe, although it greatly overlaps. I'm specifically requesting that the scam detection be turned *off* by default, as long as it can't be made much more reliable, since the net effect on security is probably negative now.
(In reply to comment #5) > @Aureliano: I'm not sure it's a dupe, although it greatly overlaps. I'm > specifically requesting that the scam detection be turned *off* by default, as > long as it can't be made much more reliable, since the net effect on security > is probably negative now. Ok, your primary goal isn't bug #320351: thanks Pepijn! ;-)
The bug lies in the fact that the scam detection algorithm is unreliable. This *is* a dup of bug #320351, since the source of the problem is identical. The only difference is your proposed solution, which doesn't correct the bug at all, but simply ignores it. I recommend that you add your votes to 320351, which calls for a proper solution. In the meantime, in Tools > Options > Security > E-Mail Scams: clear the check box.
(In reply to comment #7) > The bug lies in the fact that the scam detection algorithm is unreliable. This > *is* a dup of bug #320351, since the source of the problem is identical. The > only difference is your proposed solution, which doesn't correct the bug at > all, but simply ignores it. I recommend that you add your votes to 320351, > which calls for a proper solution. In the meantime, in Tools > Options > > Security > E-Mail Scams: clear the check box. The bug I'm reporting is not that the scam detection is unreliable. That's bug #320351. The bug I'm reporting is that given that the scam detection is so unreliable, it should not be enabled by default, since it actually *decreases* security, for the reasons stated above. It's not just a nuisance. I know *I* can disable it easily, but that's besides the point. Bug #320351 will take a very long time solve. In fact, in my opinion, it will never be solved as long as the scam detection tries to use heuristics, given the nature of the problem. See http://en.wikipedia.org/wiki/False_positive_paradox. To leave the scam detection enabled all that time, given that in my opinion in its current form it makes people *less* safe, would be the wrong thing to do.
A software "bug" is an error or flaw in a computer program that prevents it from working correctly or produces an incorrect or unintended result. The bug in T'bird is that it misidentifies legitimate mail as potential scams ("incorrect result"), as reported in bug #320351. What you are doing here is (a) duplicating a bug that has already been reported in 320351 and (b) requesting a change in the way the feature is implemented. The fact that the scam filter is enabled by default is not an error or flaw in the code; it is a decision by the programmer and produces exactly his "intended result". Changing that behaviour is a feature request, not a bug-fix. You would be more helpful by adding your vote and your comments to the *bug* report 320351 as a suggestion for an interim solution to it, rather than confusing the issue by making a feature request in the form of a duplicate bug report.
@Stuart: I'm assuming (contrary to your implication) that the developers of Thunderbird did *not* have the "intended result" in mind of decreasing the overall safety of their users. There's a good argument that that makes enabling it by default a bug, but since you seem to feel so strongly about it, I'll set the severity to "enhancement". It's definitely a separate issue though, as you yourself point out. However, all arguments about semantics aside, I'm afraid that if this bug is closed as a duplicate of bug #320351 nothing will ever come of it, since my suggestion has nothing to do with actually fixing that bug, again as you say yourself. I do agree that adding my comments to that bug would be helpful though, so I'll do that. If you feel that strongly about closing this bug as a duplicate, go ahead and do what you gotta do. But I don't think that would be contributing to improving this situation.
Severity: normal → enhancement
Technically it's not a duplicate. This would be a mitigating solution until bug 320351 comes up with an acceptable permanent solution, so it's different though dependent on that other bug. Thus, confirming as valid RFE but setting the dependencies respectively. The current scam-detection algorithm based on a few fixed rules might have been appropriate when it was introduced, but these days many commercial senders are using third-party services and servers which they "hide" underneath their official web addresses, so it's an unfortunate practice but makes the current implementation - as established here and elsewhere - mostly useless.
Status: UNCONFIRMED → NEW
Depends on: 320351
Ever confirmed: true
Summary: Scam detection generates too many false positives to be useful and should be turned off → Scam detection generates too many false positives to be useful and should be turned off by default as interim fix
Version: 3.1 → Trunk
So, apparently there are three different prefs related to that feature: - mail.phishing.detection.enabled (that's the one the checkbox controls) - mail.phishing.detection.ipaddresses (triggering on numerical sites) - mail.phishing.detection.mismatched_hosts (mismatch of link and text) Assuming that warning for numerical (i.e., non-DNS links) might still be useful for warning about a scam, mail.phishing.detection.mismatched_hosts seems to be the main culprit for the false alarms and could be set to "false", leaving the IP-address warning intact. On the other hand, this would prevent the user from easily activating it if indeed he or she wants to, given that the checkbox only seems to provide the global switch but no control over the fine-grain options.
(In reply to comment #11) > The current scam-detection algorithm based on a few fixed rules might have been > appropriate when it was introduced, but these days many commercial senders are > using third-party services and servers which they "hide" underneath their > official web addresses, so it's an unfortunate practice but makes the current > implementation - as established here and elsewhere - mostly useless. It was introduced in 2005 and NEVER worked right. From the very beginning it has been worse than useless. My vote is to kill it permanently, but if that is not possible, it should be turned off by default. That way, it will never be a problem for the vast majority of the Thunderbird users as they won't even know where to find the setting, leave alone how to change it.
Another vote to turn it off by default. I know of one company that was going to convert to Thunderbird but didn't because of this issue.
Bryan, can you expand on your comment #2 how to proceed?
Having suffered this problem for years - it affects several daily and weekly emails I receive - I was pleased to be advised that it could be turned off. I add my vote to turning it off by default.
(In reply to comment #13) > It was introduced in 2005 and NEVER worked right. From the very beginning it > has been worse than useless. After a closer look on the code in security.xul implementing the checkbox, this appears to be "incomplete by design" looking at the part that's commented out: > <checkbox id="enablePhishingDetector" > label="&enablePhishingDetector1.label;" accesskey="&enablePhishingDetector1.accesskey;" > preference="mail.phishing.detection.enabled"/> > <!-- > <checkbox id="useDownloadedList" class="indent" label="&useDownloadedList.label;" > accesskey="&useDownloadedList.accesskey;" > preference="browser.safebrowsing.enabled"/> > --> This was introduced by bug 328749 porting the Firefox phishing-list API to Thunderbird, but due to a lack of a provider, it apparently never went into effect (no URL) and "browser.safebrowsing.enabled" remained "false". The design mentioned in bug 328749 comment #6 and the implementation comments in bug 328749 comment #10 suggest that a local white/black-list mechanism exists, but I was unable to actually find that. It sure wouldn't be as useful as an up-to-date global scam list, given that web sites frequently change. So, I think the incompleteness of the feature as it was initially designed is a further argument to switch it off by default until the remainder of the algorithm has been improved and/or a global list is in place, isn't it?
Since the patch is simple and I have it on the shelf already (and also given that the users' verdict appears to be unambiguously in favor of that step), I'll post it here for review for the Message Reader and Security module owners. Note that this just switches off the scam warning by default for the time being until that feature is fixed, this is not intended to be a permanent change. For that purpose, I've added a couple of comments pointing to the related bugs. Since those won't show up in the HG logs (you'll need to go into the CVS blame to find the list-based bugs mentioned in comment #17) I figured it's a good idea to mention them explicitly.
Attachment #527010 - Flags: ui-review?(bwinton)
Attachment #527010 - Flags: review?(bugzilla)
Comment on attachment 527010 [details] [diff] [review] Flip the checkbox default I don't believe that switching this off entirely is really in the best interests of the majority of our users. I would heartily support one or both of: a) whitelisting addresses in our address book, or b) adding an easier way to turn off spam detection from the notification as interim measures, though, if you wanted to take a stab at those (or get someone else to take a stab). Thanks, Blake.
Attachment #527010 - Flags: ui-review?(bwinton)
Attachment #527010 - Flags: ui-review-
Attachment #527010 - Flags: review?(bugzilla)
(In reply to comment #19) > I don't believe that switching this off entirely is really in the best > interests of the majority of our users. As if these continuous false positives (without a single correct positive) are in the interest of the majority of the users. I suggest you spend some time helping users experiencing problems with this on the mozillazine forum before expressing your beliefs.
Thanks to Blake for the review, however... have a look at the lower part of comment #8 regarding oversaturation of a user by false positives actually decreasing security, so I question the "best interest" argument too here. > (comment #19) I would heartily support one or both of: > a) whitelisting addresses in our address book, or This won't help and rather make things worse, see my bug 320351 comment #34. Whitelisting e-mail addresses would induce false negatives due to spoofing. > b) adding an easier way to turn off [scam] detection from the notification > as interim measures, though, if you wanted to take a stab at those (or get > someone else to take a stab). I won't look further into that, anybody feel invited to take this bug. I'd say anything beyond the off switch should go into bug 320351 or a new spin-off.
Thanks for your analysis work rsx11m!
My own experience is that it has been annoying me for a very long time, but only recently did the annoyance cross the line of searching for a way to make a complaint. I found 100 topics on getsatisfaction tagged as "scam". http://getsatisfaction.com/mozilla_messaging/searches?query=scam&x=0&y=0&style=topics The vast majority of them are complaints about false positives on the scam detection, and there are some very frustrated people on there. Now factor in how many other users are frustrated, but haven't found that site, havent posted, or simply figured out how to turn it off by themselves. Turning it off by default as a temporary measure does not stop security-conscious users turning it back on. It also does not stop people working on bug 320351 and getting it working. Once the feature is working the default can be changed again.
(In reply to comment #23) > Turning it off by default as a temporary measure does not stop > security-conscious users turning it back on. Given the ratio of false positives, I am afraid there will be very few people who will turn it on. I am quite security-conscious (some call me paranoid), but it has been turned off since about 10 minutes after I got confronted with it sometime in 2005. > It also does not stop people working on bug 320351 and getting it working. True, but as far as I can determine, nobody has started working on it anyway. > Once the feature is working the default can be changed again. True, but given past experience, I consider it quite unlikely that it will be switched on by any user with a working Thunderbird installation.
(In reply to comment #24) > switched on by any user with a working Thunderbird installation. Users who explicitly switched it off (e.g., after installing 3.1.x or earlier) would retain this in their prefs.js even after it's switched off in the default preferences, afaik. For a new profile with "false" default as provided by the proposed patch would allow it to be switched to "true" later after the feature is fixed and considered suitable for an "on" default again, and such users would automatically have it switched on for them after a future major update.
A.P. Veening 2011-04-19 14:13:03 PDT said: > Given the ratio of false positives, I am afraid there will be very few people > who will turn it on. I am quite security-conscious (some call me paranoid), but > it has been turned off since about 10 minutes after I got confronted with it > sometime in 2005. On the security question, it's far worse than nothing. Firstly, so many false positives de-sensitise us from the real threat. Secondly, it's human nature to defer responsibility for identifying scams if we think there's a tool keeping us safe.
(In reply to comment #26) > A.P. Veening 2011-04-19 14:13:03 PDT said: > > Given the ratio of false positives, I am afraid there will be very few people > > who will turn it on. I am quite security-conscious (some call me paranoid), but > > it has been turned off since about 10 minutes after I got confronted with it > > sometime in 2005. > > On the security question, it's far worse than nothing. Firstly, so many false > positives de-sensitise us from the real threat. Secondly, it's human nature to > defer responsibility for identifying scams if we think there's a tool keeping > us safe. True, on another bug report I've called it worse than useless.
(In reply to comment #26) > A.P. Veening 2011-04-19 14:13:03 PDT said: > Secondly, it's human nature to defer responsibility for identifying scams if > we think there's a tool keeping us safe. An interesting point. However I have no problem with a _fully-functioning_ scam detector being on by default. I just think it should be off by default until it _works_, and most of us seem to be in agreement on that. Exactly *how* it should work is a completely different discussion. (bug 320351)
So the problem is that the the user should be warned of a potential dangerous action. So why not put that warning where it belongs..on-click, rather than the message display. It wouldn't solve the problem of false positives, but I venture that many times the offending messages are just viewed rather than a deceptive link clicked. For those that know what their doing, it would just be an extra click to dispatch the scam bar, for those that don't..they have been dutifully forewarned. So enhancement bug proposal: Execute scam detection on-click rather than message display. (It's been so long since I've had that disabled, I hope I got the sequence correct)
(In reply to comment #19) > b) adding an easier way to turn off spam detection from the notification > as interim measures, though, if you wanted to take a stab at those Well, this one ain't rocket science either, so I'll give it another try. This patch adds a clickable label similar to the "remote content" notification which will switch off the preference setting. As visual feedback to the user, the link is then disabled but the bar kept open in case the user want yet to click on the "not scam" button. That should hopefully do for an interim solution to allow users to more easily opt out of the feature. Once a list provider is found, the label can be switched against the "report" one which is already in place (incomplete implementation, see comment #17).
Attachment #527159 - Flags: ui-review?(bwinton)
(In reply to comment #29) > So the problem is that the the user should be warned of a potential dangerous > action. So why not put that warning where it belongs..on-click I sure like the idea of somehow highlighting the triggering link(s) in the message (possibly an on-hover tooltip-like popup of the real address), but that's independent of the actual algorithm employed to /identify/ the links. Joe, do you want to spin this off as a new bug?
(In reply to comment #32) > (In reply to comment #29) > > So the problem is that the the user should be warned of a potential dangerous > > action. So why not put that warning where it belongs..on-click > > I sure like the idea of somehow highlighting the triggering link(s) in the > message (possibly an on-hover tooltip-like popup of the real address), but > that's independent of the actual algorithm employed to /identify/ the links. > > Joe, do you want to spin this off as a new bug? I was thinking more along the lines of suppressing the "original message scan" scam bar and allowing only the action notification. It seems we notify twice now Certainly a better tooltip like notification would be nice, but you would have to then duplicate all the code here if phishing detection was preffed off http://mxr.mozilla.org/mozilla/source/mail/base/content/phishingDetector.js#88
(In reply to comment #32) > (In reply to comment #29) > Joe, do you want to spin this off as a new bug? Bug 651334
Blake, any ETA for the ui-review on the revised patch? This now follows your own suggestion (b) made in comment #19, thus hopefully should be acceptable. The anticipated string freeze for TB 3.3 is in a week or two, and the patch yet needs "regular" review, thus I'd appreciate your decisions on this.
Well, it's not _too_ far down my list of review requests (found at https://bugzilla.mozilla.org/request.cgi?action=queue&requestee=bwinton@mozilla.com )… I can't say exactly when, but at least now you know which order it'll happen in. :) (Oh, and I'm basically reviewing stuff until my queue is clear, and then working on other things.)
Ok, thanks. Being #6 in the queue looks promising... :-)
Comment on attachment 527159 [details] [diff] [review] Add a "disable" link to notification Review of attachment 527159 [details] [diff] [review]: Hmm. For the attachment bar, we use two buttons, as in http://dl.dropbox.com/u/2301433/AttachmentBar.png so I'm kind of leaning towards adding a second button instead of using a link… (At a minimum, I'ld like the link to line up with the text above it.) But, for the general idea of adding something to the notification bar to handle this case, ui-r=me.
Attachment #527159 - Flags: ui-review?(bwinton) → ui-review+
(In reply to comment #38) > I'm kind of leaning towards adding a second button instead of using a link… The link has the advantage that it can accommodate a longer text. If you just make a button saying "Disable Warning" it may be ambiguous if it's for all messages or just for "this type" of messages (which we can't do yet). I could make it "Disable this Feature" and then a button?
Summary: Scam detection generates too many false positives to be useful and should be turned off by default as interim fix → Scam detection generates too many false positives to be useful and should be easier to turn off as interim fix
How does "Disable Scam Detection" look as a button? Too long? Thanks, Blake.
Works for me, looks fine. I'll have an updated patch and screenshot shortly.
So, I just hit http://dl.dropbox.com/u/2301433/Privacy.png which has a very similar link, similarly misaligned… So, I guess what I'm saying is r=me if you wanted to leave it as a descriptive link. But I do still want to see it lined up with the text above. ;) Thanks, Blake.
Attached patch Button with better label (obsolete) — — Splinter Review
Well, I've just finished up and tested the button version, now you want me to change it back to a link, or is the button what you would actually prefer? I've noted in my comment when uploading the patch that I took the remote content link was used as template, thus I assumed you were aware of that.
Assignee: nobody → rsx11m.pub
Attachment #527010 - Attachment is obsolete: true
Attachment #527159 - Attachment is obsolete: true
Attachment #528478 - Flags: ui-review+
Attached patch Aligned link with better label (obsolete) — — Splinter Review
So, this is now part of the linked-version code merged back into the patch of attachment 528478 [details] [diff] [review], horizontally aligned with the message label. This may be better than the button in a way that it's less likely to hit the "Disable Scam Detection" accidentally where just "Ignore Warning" is meant. Anyway, let's keep in mind that this (hopefully) will be just a temporary feature, for that purpose it will do.
Attachment #528484 - Flags: ui-review+
Attachment #528484 - Flags: review?(mbanner)
I'll leave the button variant non-obsoleted in case you change your mind. ;-)
Attachment #527160 - Attachment is obsolete: true
(In reply to comment #43) > Well, I've just finished up and tested the button version, now you > want me to change it back to a link, or is the button what you would > actually prefer? I've gone back and forth on this. Disabling Scam Detection for all messages seems like a fairly big thing to hide behind a link. Then again, having the link there to turn it off while still letting you ignore the warning for this message seems useful. So perhaps the right thing to do is to make the button "Disable All Scam Detection", and the link "Ignore the warning for this message". But that's different than the Remote Content warning, where the button is only for this message, and the link is for the more general email address (but that's still less general than turning off scam detection for all email)… I agree that we want to make it hard to hit "Disable Scam Detection" when "Ignore Warning" is meant, and so we should probably put the two options further away, which brings us back to your first suggestion. Or the opposite of that first suggestion, with the general thing as the button… But no, I've now come to think that the first suggestion is the way to go. I apologize for making you do extra work on this one just to get back to where we started. :( > I've noted in my comment when uploading the patch that I took the > remote content link was used as template, thus I assumed you were > aware of that. Yeah, I didn't really understand that that's what you meant. D'oh. Thanks, Blake.
Attachment #527159 - Flags: review?(mbanner)
Attachment #527159 - Attachment is obsolete: false
Attachment #528484 - Flags: review?(mbanner)
Attachment #527160 - Attachment is obsolete: false
All right, so I'm posting yet another version merged from the previous ones. Re-enabling the link was missing in attachment 527159 [details] [diff] [review] which I've added back to make it clickable again if you reactivated the scam feature. Also, I've made the label now "Disable scam detection for all messages" as a mix of both variants, which also makes it clear that it disables the feature and not just the warning. I'm not posting a new screenshot, should be obvious.
Attachment #527159 - Attachment is obsolete: true
Attachment #528478 - Attachment is obsolete: true
Attachment #528484 - Attachment is obsolete: true
Attachment #528503 - Flags: ui-review+
Attachment #528503 - Flags: review?(mbanner)
Attachment #527159 - Flags: review?(mbanner)
On the main point, I agree that a button or a link as demonstrated will do the job. But with two observations: - This is a bureaucrats' solution. It has not only been agreed but also demonstrated that the current solution has no merit: it was never connected-up to services which might give it a positive functional utility. But as things stand, Thunderbird might just as well come with an enabled utility to identify e-mails from your ideal future partner, but which actually highlights a percentage of e-mails at random. The current functionality is entirely without merit, and would be better disabled entirely. That logic is inescapable. - On a note of form, changing a bug's title to something which conveys a different meaning is effectively falsification of the system. The people who voted for "...should be turned off by default..." did not vote for "...should be easier to turn off...". That should be a separate, related bug; and Bugzilla does support separate and related bugs.
I agree with Andi. I'm the original reporter of this request, and I still think the best thing to do is just to disable the functionality entirely by default. Adding a link or button to disable it is unnecessary work, and still has some of the same disadvantages as leaving the situation as is. New and/or naive users may not realise how badly the scam detection is serving them and not think to turn it off. Making it easier to turn if off kind of misses the point of why it should not be enabled by default at all. I also agree with Andi that it would have been better not to change the bug description into something which is actually fundamentally different than what I requested.
Well, that makes three as I agree with Andi and Pepijn. As far as I am concerned, the whole code for the scam-detection should be removed from the sources.
(In reply to comment #30) > That should hopefully do for an interim solution to > allow users to more easily opt out of the feature. That misses the point. The current scam detection isn't a "feature" to be opted out of. It is *broken* and should be turned off by default until it is fixed or removed entirely. I also agree with Andi; I don't think it is a good idea to change the title after people have voted for the previous title. I didn't vote for "Scam detection generates too many false positives to be useful and should be easier to turn off as interim fix". To imply that I did is 'bait-and-switch'. Can the title be changed back to what it was please? To say "this message may be a scam. Do you want to turn off scam detection?" misses the point that the message was almost certainly a false-positive and NOT a scam at all. It still casts suspicion on legitimate email lists rather than acknowledging that the real problem lies with the broken scam detection system. As comment #29 points out: >It wouldn't solve the problem of false positives
Guys, personally I agree with you. The scam feature went into effect basically incomplete with "things to come" - which eventually didn't come, so indeed switching it off by default until it is completed would be best in my and your opinions. Per comment #19 this is not going to happen, so I went with the next best thing to provide an easier "off" switch. Sure, I can scratch those five patches and switch the bug back to its original scope, but most likely nothing would happen then within the TB 3.3 time frame (and beyond)... Again, this is a mitigating interim fix, the real focus should be bug 320351.
Bug 320351 was opened in 2005. It has not been a priority up to now and no discussion has hinted that there is either priority or facility (willing partners to provide the blacklisting service) now. Where the focus "should be" is a moot point if there is no power or no will to fix it among the people who make the builds. Over five years of procrastination makes the case that Bug 320351 might as well be resolved to "WILLNOTFIX". This bug (Bug 623198) remains on a small island of hope for some (evidently quite a number) of us who are concerned not for ourselves, since we all know how to switch off the flawed feature, but for other users who may be misled by it. You have read before of the very low level of my hope: not because I am cynical but because all the evidence I have seen of the project shows that it long ago lost any intention to progress user involvement beyond unmet requests to this system. Do I expect that a button will be implemented to allow the function to turned off easily in Thunderbird 3.3 or subsequently? I do not - any more than I expect the function to be disabled or removed entirely from the source code. And if any of these things do happen, I expect it will be completely independent of the Bugzilla cases we here have raised.
(In reply to comment #54) > Do I expect that a button will be implemented to allow the function to turned > off easily in Thunderbird 3.3 or subsequently? I do not I do, otherwise I wouldn't have spent a couple of hours of my free time to implement that function. It sure has very good chances to make it into 3.3, pending Mark's technical review. (In reply to comment #49) > - On a note of form, changing a bug's title to something which conveys a > different meaning is effectively falsification of the system. The people who > voted for "...should be turned off by default..." did not vote for "...should > be easier to turn off...". That should be a separate, related bug; and > Bugzilla does support separate and related bugs. You are certainly correct, and I have spun off bug 653103 for that purpose so that this bug can focus on the default. I'll move the patch over in a moment. Unfortunately it's not unusual to refocus bugs, and I've lost count of how many bugs I had to re-file after their scope was changed and the implementation was either incomplete or something different. Sorry for adopting that bad habit.
Assignee: rsx11m.pub → nobody
Summary: Scam detection generates too many false positives to be useful and should be easier to turn off as interim fix → Scam detection generates too many false positives to be useful and should be turned off by default as interim fix
Comment on attachment 528503 [details] [diff] [review] Merged link version (has l10n impact) This is now attachment 528581 [details] [diff] [review] in bug 653103.
Attachment #528503 - Attachment is obsolete: true
Attachment #528503 - Flags: review?(mbanner)
Attachment #527010 - Attachment is obsolete: false
Keywords: privacy
Attachment #527160 - Attachment description: Screenshot of scam notification → Screenshot of scam notification [bug 653103]
I haven't read all the comments, so I apologize if that's been said already. What the scam detector currently does is check for <a href="URL1">URL2</a> where URL2 is, of course, a valid URL, and is different from URL1. This is fairly basic. There are provisions all over the code for using the Google Blacklists for scam, but the deal never went through, so we have this old code which could use a blacklist, but actually doesn't. I would heartily support a rewrite of the scam detector with maybe saner heuristics, or simply relying on external tools/libraries/online services to determine whether a message is scam.
I thought Jonathan's comments above were interesting and useful, although they probably need re-posting to "Bug 320351 - should learn what is not a scam". I agree that some more useful heuristics would be good. I'd like to emphasise the point that a <a href="URL1">URL2</a> alone (even as one test among many) isn't sufficient to trigger a scam warning. (For example, it returns false positives even in text e-mails like 'logwatch' output e-mails, where the only URL link mark-up is what Thunderbird applies all by itself.) Maybe we're talking about a system of weighted scores like SpamAssassin (although it sounds like a product in its own right). "Simply relying on external tools/libraries/online services" sounds like a good idea, because even in the short term that would take away the one flawed rule which you're suggesting is responsible for 100% of the false positives. Sure, it would mean that at present no messages would be marked as "Scam", but that in itself would be the basic improvement we're looking for as a first step.
I thought Jonathan's comments above were interesting and useful, although they probably need re-posting to "Bug 320351 - should learn what is not a scam". I agree that some more useful heuristics would be good. I'd like to emphasise the point that a <a href="URL1">URL2</a> alone (even as one test among many) isn't sufficient to trigger a scam warning. (For example, it returns false positives even in text e-mails like 'logwatch' output e-mails, where the only URL link mark-up is what Thunderbird applies all by itself.) Maybe we're talking about a system of weighted scores like SpamAssassin (although it sounds like a product in its own right). "Simply relying on external tools/libraries/online services" sounds like a good idea, because even in the short term that would take away the one flawed rule which you're suggesting is responsible for 100% of the false positives. Sure, it would mean that at present no messages would be marked as "Scam", but that in itself would be the basic improvement we're looking for as a first step.
Blocks: mail-scam
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
... no, it is not - please read comment #49 and comment #55. -> Reopening.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I would, however, argue that this should be WONTFIX in light of that bug.
That would be a valid resolution but not our call to make.
To be more specific, switching the default is independent from the UI-solution to make it more discoverable that it /can/ be switched off, which was also the reason that I didn't establish a formal dependency between these two bugs.
howdy y'all, as rsx11m pointed out, _this_ should be the default. it's handy to make turn-off-ability more obvious when it is turned ON, but turning it OFF until there is at least _some_ vague pretense that it does something vaguely useful is what needs to be done here. the default [until spam detection actually works] should be OFF. take care, lee
SCAM not SPAM. [*sigh ...*]
I agree with comments 49, 50, 51, & 52 (Andy, Pepijn, A.P., and Darrin. This 'feature' (which apparently never has worked and likely never will), should be turned off by default, if not totally removed. To do anything less is to PLAN to confuse users.
As a new member of getsatisfaction and needing a new password for this site I was amused / alarmed that the confirm email / change password email were sent straight to the Spam folder! TB doesn't even recognise mozilla.org as a good guy. How difficult would it be to implement white / black hat lists that were compared to the sender's email address, possibly using similar code to that already used with the address book? They could contain specific email addresses such as scammer@badguys.com and wild cards such as *@goodguys.com. Other, older email and webmail programs do this already, so it can't be that hard, can it? Someone pointed out elsewhere that turning it is a Catch 22 situation. Turned on most of the time it finds false positives, turned off you don't get warned of the few genuine scams.
(In reply to Peter Jennings from comment #68) > As a new member of getsatisfaction and needing a new password for this site > I was amused / alarmed that the confirm email / change password email were > sent straight to the Spam folder! TB doesn't even recognise mozilla.org as a > good guy. [...] The fact that the From line is @mozilla.org doesn't guarantee that it's no spam. It's extremely easy to spoof a from-address, and in fact about half the spam I get has my own address as the "From".
(In reply to Tony Mechelynck [:tonymec] from comment #69) > (In reply to Peter Jennings from comment #68) > > As a new member of getsatisfaction and needing a new password for this site > > I was amused / alarmed that the confirm email / change password email were > > sent straight to the Spam folder! TB doesn't even recognise mozilla.org as a > > good guy. > [...] > > The fact that the From line is @mozilla.org doesn't guarantee that it's no > spam. It's extremely easy to spoof a from-address, and in fact about half > the spam I get has my own address as the "From". I agree, it happens all the time, but examining the header in full shows no evidence to the contrary, so why was it assumed to be spam? In any case this is off topic, so I suggest we leave it to another bug report at a later date.
Domenico Addotta less than a minute ago My name is Dominic CEO Founder of the alleged "Domiad Photo Network", the largest national network dedicated to photography in Italy, which includes the most important forum of national photography scene, especially the Canon Club Italy. I am writing just because the forum that I manage and administer, some users who use Thunderbird for e-mail complained about a suspicious e-mail that sends this forum, where even talking about fraud, I enclose here Screenshots: http://www.canonclubitalia.com/canonc... This message, as well as defamatory and damaging to my forum and I represent and manage the network, creates many doubts and perplexities on users. What's in this message that can be seen as a fraud? I would like if possible a contact with the leaders of the project upstream Thunderbird to raise this issue. Thank you for listening. sincerely Dominic alleged Founder CEO Domiad Photo Network www.domiad.it/forum/converge
Probably the most likely thing that triggers the scam warning is when you have HTML in your message like so: <a href="http://www.a.com/">http://b.com/</a> Usually, newsletters use this for tracking purposes (i.e. the displayed link is to their site, but really it's being funneled through another domain that's tracking clicks). This is a common technique in scam emails to get people to go to evil websites. I'd also argue that it's pretty dishonest even when people are just using it to track clicks.
(In reply to Addotta Domenico from comment #71) Dominic there is probably nothing in your email that warrants it being labelled as a scam, the problem lies entirely with Thunderbird. The scam detection system in Thunderbird is *broken*, and apparently has always been broken since it was introduced. I and many others have asked for the scam detection to be turned off by default until it is fixed or removed entirely. This has not happened, and it does not look like this is going to happen. Sadly the best course of action is for you is probably to let your list know that this is a known problem with Thunderbird, and your members who find it annoying would be better off switching to another email client that does not have this problem.
Not only is the functionality broken, but it has no hope of ever functioning reliably enough to be useful, the problem is just too hard for that. And leaving it on actually *decreases* security due to the many false positives training people to ignore it. Once again, it should be turned off by default. Everyone who agrees, please vote for this bug! I would also like to remove the dependency on bug 320351, since this bug is about turning off the functionality, not improving it (on the premise that improving it sufficiently is not feasible). Does anyone object to that?
(In reply to Pepijn Schmitz from comment #74) > [...] > > I would also like to remove the dependency on bug 320351, since this bug is > about turning off the functionality, not improving it (on the premise that > improving it sufficiently is not feasible). Does anyone object to that? I sure won't object to that. If it were at all feasible, it would already have been done a couple of years ago.
No longer depends on: 320351
I just received a message from Mark Surman with the subject line "Tune in: One Millionth Tower premiere" which was automatically sent in response to my RSVP. Thunderbird thinks it's a scam. (Also, after clicking on the link and clicking through the "this is a scam" warning, Firefox tries to load the documentary and promptly crashes...but that's a different bug and I can't isolate it). We're coming up on six years (see 320351) for a bug affecting basic user experience and even Mozilla's own mass e-mails are marked as scams...this 'feature' should be turned off by default until it is significantly improved.
Here's an email from a listserv marked as a scam for no visible reason. This is a PLAIN TEXT email, with no HTML. So it cannot contain most of the problems the heuristics are supposed to detect. The headers went through SpamAssassin with a score of 0.0, so there's nothing serious to complain about in the headers. If this feature stays in, it needs to come with a mechanism to find out what it's unhappy about.
Comment on attachment 577631 [details] Plain-text email falsely marked as scam Best guess = numerical links: > ITTY News is at http://65.243.191.51:8000 > ITTY National is at http://65.243.191.51:8040 > ITTY Autostart is at http://65.243.191.51:8030 However, those should be obvious in plain text, thus the argument that non-registered addresses are disguised by putting text over it (as possible in HTML) wouldn't apply here.
No need to guess, since comment 78 triggered scam detection in my bugmail :)
(In reply to Joe Sabash from comment #79) > No need to guess, since comment 78 triggered scam detection in my bugmail :) FTR, I saw it too, and I'm using SeaMonkey. Shouldn't this bug be in MailNews Core somewhere, maybe MailNews Core → Filters ?
Reminder: this bug is not about the poor performance of the scam detection filter. Please post your examples on bug 320351 for that. This bug is a feature request for turning off the scam detection completely by default, because it performs so poorly that the net result is /less/ security for the users, and due to the fundamental nature of the problem it is highly unlikely ever to become good enough.
Yes, the observation made in comment #77 should be filed as a separate bug if it doesn't exist yet (and please make it block bug 654502 for tracking). (In reply to Tony Mechelynck [:tonymec] from comment #80) > FTR, I saw it too, and I'm using SeaMonkey. Shouldn't this bug be in > MailNews Core somewhere, maybe MailNews Core → Filters ? Not necessarily - while the scam detection is indeed MailNews Core functionality, the choice whether or not to enable it by default (this bug) is made separately for each application (see attachment 527010 [details] [diff] [review]).
I find it amusing that you want scam detection disabled as an "interim fix", since the permanent fix you appear to be waiting for is bug 398875, which the powers that be have decided will never be fixed.
@John David Galt: I assume you're talking to me as the bug reporter? I don't want it disabled "as an interim fix". The original summary was "scam detection generates too many false positives to be useful and should be turned off"; I want it disabled, period. The bug you mention is new to me. Even if it were implemented it would not fix this issue though. The "permanent fix" in this context would be to make the scam detection work accurately, but I'm not waiting for that as it is clear to me that that is impossible, and bug 320351, which tracks it, will never be resolved.
We have bugs filed about implementing toolkit phishing which are easily found via search. This is what is needed. Please only comment in those bugs if you are contributing in the effort to get them fixed. Ditto regarding this bug, please.
(In reply to John Nagle from comment #77) > Created attachment 577631 [details] > Plain-text email falsely marked as scam > > Here's an email from a listserv marked as a scam for no visible reason. Fixing this in bug 937265.
Blocks: 937265
Summary: Scam detection generates too many false positives to be useful and should be turned off by default as interim fix → Scam detection generates too many false positives to be useful
(In reply to rsx11m from comment #32) > (In reply to comment #29) > > So the problem is that the the user should be warned of a potential dangerous > > action. So why not put that warning where it belongs..on-click > > I sure like the idea of somehow highlighting the triggering link(s) in the > message (possibly an on-hover tooltip-like popup of the real address), but > that's independent of the actual algorithm employed to /identify/ the links. > > Joe, do you want to spin this off as a new bug? Excellent idea. At least that allows us to understand *why* a given mail was labeled a scam. And if it is not a link that triggers the detection, have some easily accessible button "Why" that pops up a small dialog with the explanation. The button could for instance be in the red bar on top of the message, right next to the "Preferences" button.
Assignee: nobody → jsbruner
Status: REOPENED → ASSIGNED
Summary: Scam detection generates too many false positives to be useful → Reduce false-positive rate of scam detector
For the "wrong link" case, what I think we should do is trigger the scam warning only when the user clicks it. Then allow them to use the link the text said it would be.
(BTW, this is *not* in response to Magnus' comment 88) It's been mentioned multiple times that the reason we can't improve scam detection is because of the fundamental nature of the problem. This is likely true if we continue this simple decision tree-like model. We could likely relax it to lower false-positives, but trying to improve true positive rate would be difficult and attackers would surely find ways to bypass it. That being said, I don't think hope is lost. We need to take a different approach, likely based on heuristics which mostly works out of the box (local-only Bayesian filtering is unlikely to work because users have few samples, unlike spam). For example, "Detecting Phishing Emails Using Hybrid Features" (https://ieeexplore.ieee.org/document/5319188/) describes one such method and there are many more in the literature that rely on machine learning or similar techniques. I think such a ML-based approach is the correct one and will probably solve the false-positive issue (this bug) as well as improve true positive detection. The most difficult part of the ML approach will be getting data to train a model on. The Anti-Phishing Working Group (https://apwg.org/) evidently has a large database of phishing emails that have been submitted, but the data is not freely available. However, it's possible that Mozilla could join the group for a discount, since they offer that for non-profits. Maybe we could have some discussions with them? If that approach doesn't pan out, we'll need another way to obtain a large sample of known phishing emails as well as non-phishing emails to use for training. The latter is much easier, and I could volunteer much of my own data (assuming it isn't stored publicly). If anyone has any ideas on how to get such phishing email examples, please comment with your suggestions. @Magnus, what do you think of switching to a machine learning approach for scam detection?
Flags: needinfo?(mkmelin+mozilla)
Summary: Reduce false-positive rate of scam detector → Scam detection generates too many false positives to be useful and should be turned off
I changed the summary back to what I (the reporter) originally submitted. This bug is not about improving the scam detection, it is about turning it off by default, for reasons explained above.
Hi Pepijn, Thanks for filing this bug and staying involved! Apologies for changing your subject without discussion first. The reason for suggesting to disable this feature by default was because of poor performance. If that performance issue was resolved, would you still want the feature disabled by default? In fact you answered that in your first comment: > "I think the scam detection should therefore be turned off, or vastly improved (which I don't think is possible)" I think it *is* possible, just difficult. I changed the subject to make this bug workable. Disabling scam detection by default is IMO not a valid workaround. The current false positive rate is annoying, certainly, but it also mitigates against common phishing attempts for naive users (who, for better or worse, will rely on it and won't turn it off due to FUD). -------------------- [ Security Tradeoffs ] -------------------- I read why you think this detector actually harms security, and don't find the argument convincing (though I recognize the lack of data is problematic for decision making). > "The net effect on security is probably negative. People who don't rely on it gain no extra security, This is absolutely true. If by "don't rely on it" you mean "have it disabled". > "... while people who do rely on it may not themselves scrutinize messages enough anymore and may therefore be more likely to be deceived by one of the many scams not detected by Thunderbird." This is only applicable to users who understand email security to begin with [1]. You missed an entire class of users who are worried about this stuff, but don't understand security, and therefore wouldn't have scrutinized messages anyway. This last group is the main target of the scam detector, and the reason it is enabled by default. So the question becomes: "Is the value we get out of protecting naive users greater than or equal to the absolute negative value we get from people not scrutinizing messages due to the scam detector." Unfortunately, we have no metrics for this, and it is partially a project management (read: opinion) call. Personally, I find the value for protecting naive users to be greater. If you really want this bug to stay "disable scam detection by default", then that is fine and I will file another bug to lower the false positive rate. In that case, you would need to convince the TB leadership that the pros of disabling are greater than keeping enabled. Magnus is definitely one of the key players you'll have to convince. Regards, Josiah [1] I don't agree that the high false positive rate necessarily means people will scrutinize email less. I do security engineering professionally, understand email and email security quite well, and keep the scam detection turned on. Even though I experience the high false positive rate, I still scrutinize emails just as carefully, and am glad that scam detection provides at least some protection against attacks (e.g. Bug 1249562).
With all due respect, I disagree that turning it off by default is not a valid workaround. If the devs don’t like the idea of disabling it by default, at least allow the user to turn it off. For me the scam detection was also completely useless and in fact worse than useless. If I remember correctly I’ve had government or some other equally super important email marked as possibly a scam; it was ridiculous.
I cannot foresee any circumstance where detection off would become the default - and such a request would like not be accepted in the product. We prefer to fix issues rather than workaround them with preference options or ill-advised defaults, therefore if you have a UI or performance issue a productive avenue would be to file a bug for it and help get it fixed. https://mzl.la/2KJcmgm is the current list, and there is only one performance bug currently filed.
(In reply to Ambrose Li from comment #92) > With all due respect, I disagree that turning it off by default is not a > valid workaround. If the devs don’t like the idea of disabling it by > default, at least allow the user to turn it off. For me the scam detection > was also completely useless and in fact worse than useless. If I remember > correctly I’ve had government or some other equally super important email > marked as possibly a scam; it was ridiculous. Hi Ambrose, For the record, you can turn it off yourself in preferences. This bug is suggesting to make off the default setting.
(In reply to Wayne Mery (:wsmwk) from comment #93) > I cannot foresee any circumstance where detection off would become the > default - and such a request would like not be accepted in the product. We > prefer to fix issues rather than workaround them with preference options or > ill-advised defaults, therefore if you have a UI or performance issue a > productive avenue would be to file a bug for it and help get it fixed. > https://mzl.la/2KJcmgm is the current list, and there is only one > performance bug currently filed. In that case, please feel free to fix this problem after more than 13 years. Until that time, turning this worse than useless so-called feature off is a perfectly acceptable default, at least for ordinary users suffering from a surfeit of false positives with a perfect score of zero correct positives and way too many false negatives.
(In reply to Josiah Bruner [:jsbruner] (needinfo for responses) from comment #91) > [...] > > [1] I don't agree that the high false positive rate necessarily means people > will scrutinize email less. I do security engineering professionally, > understand email and email security quite well, and keep the scam detection > turned on. Even though I experience the high false positive rate, I still > scrutinize emails just as carefully, and am glad that scam detection > provides at least some protection against attacks (e.g. Bug 1249562). I am afraid you lack a basic understanding of human nature. After way too many false positives without any true positive, normal people tend to ignore such warnings. Just remember the story about the bo boy who cried wolf. When you add in the false negatives, the added security of these warnings is negative for normal people.
Here's another reason to think we can improve the detection algorithm. In the ACM DIMVA 2007 article there's a chapter called "On the Effectiveness of Techniques to Detect Phishing Sites" by the Technical University Vienna. In that chapter the authors built a phishing classifier for phishing sites which actually used a relatively simple decision tree. This was the effectiveness confusion matrix data: Number of Phishing Samples: 680 Number of benign samples: 4149 Benign classified as benign: 4131 Benign classified as phishing: 18 = 0.3% FP rate Phishing classified as benign: 115 Phishing classified as phishing: 565 = 83% TP rate Which is actually pretty good. It's been over 10 years, and we could likely do even better.
(In reply to A.P. Veening from comment #96) > (In reply to Josiah Bruner [:jsbruner] (needinfo for responses) from comment > #91) > > [...] > > > > [1] I don't agree that the high false positive rate necessarily means people > > will scrutinize email less. I do security engineering professionally, > > understand email and email security quite well, and keep the scam detection > > turned on. Even though I experience the high false positive rate, I still > > scrutinize emails just as carefully, and am glad that scam detection > > provides at least some protection against attacks (e.g. Bug 1249562). > > I am afraid you lack a basic understanding of human nature. After way too > many false positives without any true positive, normal people tend to ignore > such warnings. Just remember the story about the bo boy who cried wolf. When > you add in the false negatives, the added security of these warnings is > negative for normal people. I don't have actual data on this. So I won't contest it. Note though that I agree people may "ignore" the scam detection warning. It isn't clear to me, however, that those people would then be less careful than if the message was never flagged to begin with. Regardless, I don't make the calls here, I'm just providing my opinion and any data I have. I am actively working to improve phishing detection. I will make those changes in other bugs though. So unassigning....
Status: ASSIGNED → NEW
Assignee: jsbruner → nobody
I'll repeat my comment made 7 years ago, because it's still true: "This 'feature' (which apparently never has worked and likely never will), should be turned off by default, if not totally removed. To do anything less is to PLAN to confuse users." And since, in those 7 years, those in charge seem to think it's useful as is and don't seem to think it's important enough to fix, I think I'll write this thread off as a lost cause and try to sign off from this thread after completing this rant.
It’s not really 7 years even. I added myself to two similar bugs on this issue when it got so bad I was about to dump Thunderbird; this is one of them. The other one was from 13 years ago. This is a 13-year-old problem that’s still unfixed.
(In reply to Josiah Bruner [:jsbruner] (needinfo for responses) from comment #91) > The reason for suggesting to disable this feature by default was because of > poor performance. If that performance issue was resolved, would you still > want the feature disabled by default? I might, but that should be done in a different issue, to prevent muddying the water. I'm not going to rehash all the arguments. Of course anyone is welcome to try and improve the scam detection, and if it ever reaches the dizzying heights of reliability that would actually be needed to make the feature useful, turning it on by default again can be debated then, but until then it should be off by default, which is the sole focus of this bug report. > If you really want this bug to stay "disable scam detection by default", > then that is fine and I will file another bug to lower the false positive > rate. I do, so I think that would be the best course, thank you. > In that case, you would need to convince the TB leadership that the > pros of disabling are greater than keeping enabled. Magnus is definitely one > of the key players you'll have to convince. I've put enough energy in that all those years ago. The arguments are sound and speak for themselves. If the TB leadership choose to ignore them then that is on them.
(In reply to Pepijn Schmitz from comment #101) > (In reply to Josiah Bruner [:jsbruner] (needinfo for responses) from comment > #91) > [...] > If the TB leadership choose to ignore them then that is on them. I would recommend the TB leadership spend some time on helping users with their problems (like on the Mozillazine forums) instead of spouting lofty ideals from their ivory towers. Alternatively, they might spend some time on fixing the original bug so this work around isn't necessary any more, but I've given up the hope on that after 13 years.
+1 to Comments 100-101. This is one of the bugs that drove me back off Thunderbird. I also think the false positive rate is teaching users to ignore security warnings even when they **really should** be paying attention to them. (+1 to Comment 96). While I agree that in theory, the detector could get better, the age of this bug suggests no credible reason to believe it actually will. Until that actually happens, as tracked in another bug (like Bug 623198), I support Comment 95's proposal to turn it off.
Thank you guys for your comments. My name is Ryan Sipes and I am Community Manager and, as of this year, on the Thunderbird Council. I don't have an ivory tower, but I do get your point. I will raise this bug in the mailing list and with some of the devs and see if there is something we can do to improve this and address your concerns.
Also, as a reminder, I ask everyone to keep your comments considerate and constructive. Most folks working on the project are volunteers giving of their free time to create free software. So bear that in mind when having these conversations.
(In reply to Josiah Bruner [:jsbruner] (needinfo for responses) from comment #89) > (BTW, this is *not* in response to Magnus' comment 88) > The most difficult part of the ML approach will be getting data to train a > model on. Exactly. > @Magnus, what do you think of switching to a machine learning approach for > scam detection? The results would probably be better. I don't think improving scam detection other than by simple means is a huge priority though. Implementing comment 88 should improve the situation a lot, regarding the annoying false positives..
Flags: needinfo?(mkmelin+mozilla)
Apologies for my circular reference; I'd copied that number from an e-mail when this bug's title had been changed. I do think there should be two separate bugs filed here: one for turning off scam detection, one for dramatically improving its performance, and another (eventually) for re-enabling it as default. I recognize that the project is maintained by volunteers and users can't expect important bugs to just get fixed. That's why some of us are trying to focus on the most direct route to improving on the status quo: turning off this system that gets in the way and trains people to ignore real important security warnings elsewhere. It's a small chunk of work that can be done quickly, by changing a default. The code to support scam detection shouldn't be ripped out; a user who wants to try it out should be able to do so by a user preference and/or extension, but it should be off by default. Yes, maybe it'd be better long-term to have a fantastic scam detection system. Right now, we don't, and it's bad enough that it should be turned off until such indeterminate time in the future if/when the large chunk of difficult work has been done to make the system much better. NB: if a URL links to a substantially different one, I support the proposal of comment 88 as long as the dialog also allows them to use the alternative URL, which might have some real use cases especially within the same domain and in the case of false positives. However, I think that should be tracked in a separate bug. Thanks!
(In reply to WBT from comment #107) > Apologies for my circular reference; I'd copied that number from an e-mail > when this bug's title had been changed. I do think there should be two > separate bugs filed here: one for turning off scam detection, one for > dramatically improving its performance, and another (eventually) for > re-enabling it as default. No need to file a separate bug for turning it off; that is what this bug is, and always has been, about.

Attempted to capture the suggested development direction. One of you want to tackle comment 88?

The blocker list in bug 654502 might also be instructive

Flags: needinfo?(kaie)
Flags: needinfo?(alessandro)
Summary: Scam detection generates too many false positives to be useful and should be turned off → Improve UI to workaround ccam detection generating too many false positives

BTW, this is a common complaint of users in support forums

Flags: needinfo?(kaie)
Summary: Improve UI to workaround ccam detection generating too many false positives → Improve UI to workaround scam detection generating too many false positives
Flags: needinfo?(kaie)

(In reply to Wayne Mery (:wsmwk) from comment #109)

Attempted to capture the suggested development direction. One of you want to tackle comment 88?

The blocker list in bug 654502 might also be instructive

I would have thought Bug 1476428 addressed comment 88 . Implemented in 68

Yes bug 1476428 has that covered. That also reduces the false scam rate quite significantly.
I think we're done here and if there are concrete suggestions in the new situation, we can handle those as they are filed.

Status: NEW → RESOLVED
Closed: 14 years ago → 6 years ago
Resolution: --- → WORKSFORME
Flags: needinfo?(kaie)
Flags: needinfo?(alessandro)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: