1318495 - Move to "Inbox" again moves mail to the wrong inbox, posing a potential privacy issue

Status: RESOLVED DUPLICATE of bug 382104

(Thunderbird :: Security, defect)

Description

[stie]

When moving false positives in any of my accounts' spam folder using right click -> Move to "Inbox" again, the message in question always disappears from the said account and is actually moved to the other account's inbox (I have only two accounts). Besides being an additional pain in the already painful, yet unavoidable process of searching for false positives in my spam folders, regarding privacy, this could be a serious issue, as some private e-mail inadvertently moved this way could end-up in corporate inbox and vice versa, should the user use one thunderbird instance for both private and corporate accounts. Didn't flag this as "security" as disclosure seems to be more beneficial than hiding this bug from the general public in this peculiar case, although it would definitely qualify as a security bug in my humble opinion.

Comment 1

[Wayne Mery (:wsmwk)]

Thanks for your concern regarding privacy.  Privacy issues that don't have a security component are not bounty eligible afaik.  I'm not authorized to minus it.

I'm afraid I don't understand how this is not just user error - because 
a) only user initiated manual move operation can cause "Inbox" to appear in "move again" - no automated filters or processes update that field
b) if you were the person who did such a move, why wouldn't you know which account was last used

Further, I don't understand what usecase would have a user moving message to the inbox from some other folder. The normal practice is certainly to move messages OUT of the Inbox. 

Lastly, if this involves junk processing and your Junk folder, you should be marking messages as Not Junk which will cause them to move back to Inbox but NOT change the move again folder name.

If I'm mising something, please describe why you are moving messages to Inbox. If you really have a usecase, then what you want is probably bug 382104

Comment 2

[stie]

Attachment: Occurences of moveToFolderAgain, which is behaving badly, in tbird-45.4.0

I am uploading this list of files containing the text "moveToFolderAgain" in the mail subdirectory of Tbird 45.4.0's source package (latest in Debian Jessie / stable) for further review of the function in question, that is thought to be responsible for the odd behavior described above. If I catch time this week-end, I will try to hunt down the bug's cause further myself. Anyhow, this should provide a good starting point to fellow bug catchers. Any confirmation of this bug (without further digging) would of course be more than welcome, by the way.

Comment 3

[Al Billings [:abillings - ex-MoCo]]

Please don't nominate your own bugs for bounty in bugzilla. Email [e-mail] as our Security pages indicate so our security team can examine the issue.

https://www.mozilla.org/en-US/security/client-bug-bounty/

Comment 4

[stie]

(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #1)
> Thanks for your concern regarding privacy.  Privacy issues that don't have a
> security component are not bounty eligible afaik.  I'm not authorized to
> minus it.
> 
> I'm afraid I don't understand how this is not just user error - because 
> a) only user initiated manual move operation can cause "Inbox" to appear in
> "move again" - no automated filters or processes update that field
> b) if you were the person who did such a move, why wouldn't you know which
> account was last used
> 
> Further, I don't understand what usecase would have a user moving message to
> the inbox from some other folder. The normal practice is certainly to move
> messages OUT of the Inbox. 
> 
> Lastly, if this involves junk processing and your Junk folder, you should be
> marking messages as Not Junk which will cause them to move back to Inbox but
> NOT change the move again folder name.
> 
> If I'm mising something, please describe why you are moving messages to
> Inbox. If you really have a usecase, then what you want is probably bug
> 382104

Thank you Wayne for providing this reference to bug 382104; basically this seems to be the same bug as the 2007 one you are referring to, seen with 2016 privacy-aware lenses. So actually a bug, but was not deemed important at the time and hence probably left dormant for this reason (the "feature request" classification probably hasn't helped either). I suggest that it is time to work on it, regardless of its "bounty" status. I would actually donate back the proceeds of the bounty, should Mozilla solve it and still award me a bounty for having uncovered it (but apparently, someone already found it in 2007,
albeit without considering it under the privacy angle).

By the way, to answer your question, what I would expect as normal behavior is that when clicking on "Move to "Inbox" again" using contextual menu on a false positive that was incorrectly moved / ended up in Spam - not by me, but by either my e-mail provider or Thunderbird (putting my user hat on, I shouldn't have to care about the inner workings of automated spam filtering anyways, as long as it "works") -, it should go back to Inbox, the one from the same account, that is (and in no case, the Inbox from another account, which could be totally unrelated and hence, a potential threat to privacy).

Marking the message as "Not Junk" as you suggest, whilst technically valid, is still less direct than clicking on "Move to "Inbox" again", which only costs two clicks (namely one right click, then hit this option) without having to go through a submenu. This makes an important usability difference when one often has to sort false positives as I do.

Last but not least, before adding a second account to Thunderbird, using the incriminated function sometimes (unpredictably) caused the same bug as in http://forums.mozillazine.org/viewtopic.php?f=39&t=2656871, meaning that there is definitely something wrong with this function, not only in my opinion but also in the opinion of and facts related by others (and making messages disappear is probably even more problematic than having them end up in another account on the same Thunderbird instance, privacy concerns aside). 
Basically, without having looked at the code yet, from what I could gather by my own experience and by reading your message as well as bug 382104, this function (moveToFolderAgain) has a very short "memory" and sometimes even shows alarming signs of memory disorder, comparable to Alzheimer's if it were an human being, confusing accounts, etc. If this bug/bug 382104 ends up being too costly to be solved, said function should at least be greyed out in such cases, if detectable, in order to avoid the incriminated behavior. Admittedly, deleting it altogether would be a regression, but would provide more consistent behavior. This, in turn, would be the "cheapest" option (in all acceptations of the word "cheap") and hence probably not the way to go.

Comment 5

[stie]

(In reply to Al Billings [:abillings] from comment #3)
> Please don't nominate your own bugs for bounty in bugzilla. Email
> [e-mail] as our Security pages indicate so our security team can
> examine the issue.
> 
> https://www.mozilla.org/en-US/security/client-bug-bounty/

Sorry about that. This was mainly to mark the bug with a security tag, without making it non-public, as I think it could help other users facing the same issue and do no harm for them to know about it. But it may be redundant with the "Security" component choice (although I doubt this is the right choice, since technically speaking the moveToFolderAgain function is not a security function). Hence, also, the non-following of the flow of e-mailing you first, as is usually the case for security bugs.
Maybe you should add a "privacy" category / tag / flag / ... to Mozilla's bugzilla, so as to distinguish it from more critical security issues that demand another, more confidential treatment?

Comment 6

[Wayne Mery (:wsmwk)]

(In reply to stie from comment #4)
> (In reply to Wayne Mery (:wsmwk, NI for questions) from comment #1)
> > Thanks for your concern regarding privacy.  Privacy issues that don't have a
> > security component are not bounty eligible afaik.  I'm not authorized to
> > minus it.
> > 
> > I'm afraid I don't understand how this is not just user error - because 
> > a) only user initiated manual move operation can cause "Inbox" to appear in
> > "move again" - no automated filters or processes update that field
> > b) if you were the person who did such a move, why wouldn't you know which
> > account was last used
> > 
> > Further, I don't understand what usecase would have a user moving message to
> > the inbox from some other folder. The normal practice is certainly to move
> > messages OUT of the Inbox. 
> > 
> > Lastly, if this involves junk processing and your Junk folder, you should be
> > marking messages as Not Junk which will cause them to move back to Inbox but
> > NOT change the move again folder name.
> > 
> > If I'm mising something, please describe why you are moving messages to
> > Inbox. If you really have a usecase, then what you want is probably bug
> > 382104
> 
> Thank you Wayne for providing this reference to bug 382104; basically this
> seems to be the same bug as the 2007 one you are referring to, seen with
> 2016 privacy-aware lenses. So actually a bug, but was not deemed important
> at the time and hence probably left dormant for this reason (the "feature
> request" classification probably hasn't helped either). I suggest that it is
> time to work on it, regardless of its "bounty" status. I would actually
> donate back the proceeds of the bounty, should Mozilla solve it and still
> award me a bounty for having uncovered it (but apparently, someone already
> found it in 2007,
> albeit without considering it under the privacy angle).
> 
> By the way, to answer your question, what I would expect as normal behavior
> is that when clicking on "Move to "Inbox" again" using contextual menu on a
> false positive that was incorrectly moved / ended up in Spam - not by me,
> but by either my e-mail provider or Thunderbird (putting my user hat on, I
> shouldn't have to care about the inner workings of automated spam filtering
> anyways, as long as it "works") -, it should go back to Inbox, the one from
> the same account, that is (and in no case, the Inbox from another account,
> which could be totally unrelated and hence, a potential threat to privacy).
> 
> Marking the message as "Not Junk" as you suggest, whilst technically valid,
> is still less direct than clicking on "Move to "Inbox" again", which only
> costs two clicks (namely one right click, then hit this option) without
> having to go through a submenu. This makes an important usability difference
> when one often has to sort false positives as I do.

Marking "not junk" is not just technically valid, it also best practice, and needed to help prevent similar "wanted" messages from going to the junk folder in the first place. You don't need a menu or a mouse. Hit capital "J". Done.
You might have a look at the training section of http://kb.mozillazine.org/index.php?title=Junk_Mail_Controls

 
> Last but not least, before adding a second account to Thunderbird, using the
> incriminated function sometimes (unpredictably) caused the same bug as in
> http://forums.mozillazine.org/viewtopic.php?f=39&t=2656871, meaning that
> there is definitely something wrong with this function, not only in my
> opinion but also in the opinion of and facts related by others (and making
> messages disappear is probably even more problematic than having them end up
> in another account on the same Thunderbird instance, privacy concerns
> aside). 

True, someone complained. But only few complaints in 10 years is some indication that most users don't have a problem. You will note there are no duplicates to bug 382104, and only Magnus and me are CC on the bug.  Google pulls up nothing with https://www.google.com/search?q=%22move+to+inbox+again%22&ie=utf-8&oe=utf-8  I've written my share of bug reports about the move function, and also never seen this mentioned in support forums. So I went digging - found 3
https://support.mozilla.org/en-US/questions/1104333
https://support.mozilla.org/en-US/questions/1047938
https://support.mozilla.org/en-US/questions/1043669

That said, bug 382104 might well be an improvement whose time has come.

> Basically, without having looked at the code yet, from what I could gather
> by my own experience and by reading your message as well as bug 382104, this
> function (moveToFolderAgain) has a very short "memory" and sometimes even
> shows alarming signs of memory disorder, comparable to Alzheimer's if it
> were an human being, confusing accounts, etc. If this bug/bug 382104 ends up
> being too costly to be solved, said function should at least be greyed out
> in such cases, if detectable, in order to avoid the incriminated behavior.
> Admittedly, deleting it altogether would be a regression, but would provide
> more consistent behavior. This, in turn, would be the "cheapest" option (in
> all acceptations of the word "cheap") and hence probably not the way to go.

I don't know what broken aspect you are referring to here. I am not aware of any broken aspects, other than messages might disappear if the target folder wasn't accepting messages.

Comment 7

[stie]

Basically the fact that the option is not disabled when it should not be used is a bug, as semantically "Move to "Inbox" again" sounds like the perfect match for a false positive. I understand now that I was doing a mistake of using it instead of "Not Junk", however this is counter-intuitive (such as the "J" trick, which additionally could pose a problem to disabled users that do not use a keyboard in order to interact with their computers) and under no circumstance, clicking "Move to "Inbox" again" should make messages disappear or be moved to another inbox, if they didn't come originally from that inbox. This is the issue I am referring to when comparing the function's behavior to human mental illness for its fundamentally broken aspects. Yet, optimistic as I am, I think that this can and should be solved, so as to make Tbird user-friendlier and less hazardous.

Comment 8

[Wayne Mery (:wsmwk)]

regardless of the reason, bug 382104 would solve your problem. We don't keep two bugs open for the same issue.