Closed Bug 363856 Opened 15 years ago Closed 13 years ago
entries in address book should default to have the remote images permission already
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0 Build Identifier: Thunderbird version 2 beta 1 (20061213) This is a new feature in Thunderbird 2. Sometimes when you click on it, the message just goes away (does it do anything?) and sometimes it pops up the dialog to add an address to the address book, seemingly at random. Also, the released version of Thunderbird has an option to select which address book to check recipients against to decide whether to display images; I can't find a similar option in Thunderbird 2. Reproducible: Always Steps to Reproduce: 1. Get sent a message with remote images. 2. See the Click here.. message 3. Click on it Actual Results: Sometimes nothing happens, sometimes it offers to add the sender to the address book Expected Results: Consistent behaviour Either put it in the address book or do something else to make the sender's email always display images (and make it clear what's happening)
I think I understand better now how this is supposed to work. I found a checkbox in the address book for selecting whether a given person has permission to send email with remote images displayed, and I assume the apparent randomness in displaying the add to address book dialog is due to some senders already being in the address book and some not. So, not really a bug, but would benefit from better (any?) documentation and a more intuitive user interface.
*** This bug has been marked as a duplicate of 363948 ***
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Not a duplicate. (In reply to comment #1) > So, not really a bug, but would benefit from better (any?) documentation and > a more intuitive user interface. I think the UI is OK: if a new card is being created, I want the option to change my mind without having to go delete the new card; but if someone's already in my AB, it seems likely enough that if I whitelist them, I mean it and don't need to second-guess myself. As for documentation, I suppose it would be possible to have a box pop up the first time you whitelist a new contact (like we do the first time you select Junk Mail Controls) explaining what's going on. Do you want to morph this bug into a request for such a thing?
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Perhaps by default entries in your address book should have the remote images permission already? I'm not sure I can foresee a reason why I'd want to have someone in my address book but not allow them to send remote images. The old idea of having an address book listing Trusted Senders seemed more intuitive.
Assignee: mscott → nobody
Severity: trivial → enhancement
Component: Mail Window Front End → Security
QA Contact: front-end → thunderbird
Summary: "Click here to always load remote images" doesn't work consistently → entries in address book should default to have the remote images permission already
CC'ing Standard8 to get his opinion on this.
There are several cases where we add cards to the address book: 1) Auto-collection when you send to a new email address. 2) Add a card by selecting Add To Address Book when clicking a new email or selecting the link on the whitelist remote images banner. 3) Manually add a new card in the address book. In case 1 I don't think we should allow remote images by default. The user doesn't necessarily realise the full implications of allowing auto-collection. In case 2 I think we could enable it by default, cc'ing Bryan for his thoughts as we may want to add an extra option to http://wiki.mozilla.org/MailNews:Address_Book_New_Card_Inline when we implement that. In case 3 I'm torn, but I think we could probably enable that by default as well without upsetting users.
I'm somewhat hesitant to adding remote content permissions as default at all... It's easy to click the banner once you really get such content, and very few users use it (except mailing lists). If it's on by default, at least make it a pref.
I'm a bit uncertain about the relationship of contacts to remote images. Essentially it is allowing for Thunderbird's concept of an identity to send a user mail with remote images from any of that identities accounts. It just doesn't seem beneficial to our users. Also the reverse of requiring that an email address be a contact in order to allow remote images doesn't seem beneficial either. It all feels like a hack that's evolving. A simple list of email addresses that are allowed to send a user mail with remote images seems like the simple and correct solution. The sender doesn't have to be a "contact" of mine, often it's just the noreply@bankofcanada sending me mail and I'll never be able to send it mail. On the other side of the interaction it should be a single click operation to allow anyone, contact or not to include remote images in a mail. At worst what happens is that a users contact, uses remote images from different addresses and that user needs to select always each time. I feel pretty comfortable with this because there is less behind the scenes magic going on. I understand we could optimize a few interactions but the fact that we are questioning ourselves which of the 3 cases are correct means to me that our users won't really know when we're going to ask them either.
i very much like the idea of this not adding entries to my AB.
Now that I've had a chance to really think this over I'm more convinced than ever that remote images has nothing to do with cards in your address book. I've created bug 457296 for changing the current address book system over to just a simple list of addresses. I'd recommend for this bug to block on bug 457296 and then remove the UI for this from the Contact Editor dialog.
I vote for this one too. We need some UI to have white/black list that also supports wildcards and/or regex (to allow/block whole domains for example).
This seems like an easy extension to build once bug 457296 is fixed, then we'd have something to test and play with. However by default we can't enable this kind of behavior. For the extension: I think there is room in both the Address Book interface and the image load/block interface for adding an item that enables something exactly like this or even similar. The address book could have a checkbox that enables an address book -> remote image loading link. In the inline remote image loading bar you could also insert an option to "Always load images from people in my address book"
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago → 13 years ago
Resolution: --- → WONTFIX
I don't get why this is a wontfix! Some people want it and have asked for it, while others don't agree. Thus, I believe it should be an option in tb like 'Always trust people in my address book and load remote images in their mail by default' (or something shorter than that). I mean... each time, *and I mean each and every single time* I add a contact to my address book, I also tick the relevant checkbox. This means extra work to just simply add a contact and have it behave the way I want it to. My point is that this way, even if it doesn't default to 'always allow' (because people think it is a security issue), someone could at least have the option to set it to that if they understand the risk. After all, I don't think it is so hard to implement a checkbox allowing exactly that (btw there is room for that in 'Advanced' options -> 'Reading & Display' tab and it seems the most appropriate place for it). Now that I think of it, perhaps a hidden-from-the-main-audience 'display.options.always_allow_remote_img_from_address_book' that can be set to true/false? What do you say? Please do reconsider and reopen it. Thank you in advance.
Brian, can you please reconsider this one? At least the hidden pref in about:config to toggle default state (a true/false boolean). Once again, please leave this open. Mark for future/P5/minor if you wish, but don't close it as wontfix, because I really want to see it implemented someday.
You need to log in before you can comment on or make changes to this bug.