118766 - Messages printed from print preview contain full path URL to mailbox in header (privacy/security concern, ux-error-prevention)

Status: RESOLVED WORKSFORME

(MailNews Core :: Printing, defect)

Description

[Jan Urbanek]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.7+) Gecko/20020102

On page top is every printed mail path to mailbox.
Expectation: Normally will be mails printed without path, if path printing is
needed user must to choose it in print dialog window.

Comment 1

[Jesse Ruderman]

It may be a security hazard on systems with short path names, but mostly it just
looks stupid.  This is what I see at the top of a printed message (Win98):

                  mailbox:///C|/WINDOWS/Application%20Data/Mozilla/Profiles/De...

I think it would be better to show the e-mail address for the account at which I
recieved the message, along with the folder name (e.g., Inbox).

Comment 2

[dcone (gone)]

-->Rods.  

Comment 3

[rods (gone)]

this is a mail bug

Comment 4

[Wayne Mery (:wsmwk)]

URL is not being printed even though it is specified in page setup. WUWT?

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to comment #4)
> URL is not being printed even though it is specified in page setup. WUWT?

hmm, bug 286627

Comment 6

[Biju]

Now in TB we could suppress printing URL or any other header/footer fields.

So is this still a problem in SeaMonkey?

Comment 7

[rsx11m]

Biju, this is Core code, I think the format is the same for both Thunderbird
and SeaMonkey. by "in TB we could suppress printing URL", are you referring to another bug or just the Margins & Header/Footer selection fields in the Page Setup dialog?

Also, per comment #1 here and bug 427474, this field could be used for optionally printing account and folder information if needed.

Comment 8

[Biju]

I think I did not understood this bug.
Is this bug asking 
1. not to print URL by default, or
2. in every print ask whether or not print URL 

Comment 9

[rsx11m]

(In reply to comment #8)
> 1. not to print URL by default, or

Good question. I think that a default behavior of omitting the URL, thus not revealing the profile path, is desirable. The other point is comment #1, to replace the (local, thus without any informational value) URL with a somewhat more useful clear-text item like account/folder information. In that case, it could be retained as a printing default.

> 2. in every print ask whether or not print URL 

I don't think that asking which headers to print for every print action would be necessary, this can be a Page Setup preference setting.

Comment 10

[Ludovic Hirlimann [:Usul]]

I've just printed an email from TB3.0b2 - I don't see any URL. This looks WFM. Can anyone confirm ?

Comment 11

[rsx11m]

Yes, I can confirm for Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090226 SeaMonkey/2.0b1pre.

In all tested cases (printing from IMAP or Local Folders, printing to file or actual printer), the URL was not including despite still being set as default in the Page Setup for the upper right corner. However, it still showed up in the Print Preview though. Nevertheless, the original issue here appears resolved, the use of that now blank space is covered by other pending bugs.

-> WFM

Comment 12

[rsx11m]

Sorry, I'll have to reopen that after finding a case to reproduce this...

1. Take an e-mail with large images (within message body or as attachments);
2. Display Attachments Inline and View > Message Body As set to show them;
3. in Page Setup, either have Shrink to Fit or a small scale (I've used 50%);
4. check in Print Preview, URL is present in upper right corner;
5. print all or a page range of the message;
6. you may need to repeat printing a second time, not always reproducible.

Reproduced on both Linux (TB 3.0b2 w/ CUPS) and Windows (Shredder nightly). There is also bug 286627 on URL not being printed, so that's still valid too.

Comment 13

[Ludovic Hirlimann [:Usul]]

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.

Comment 14

[Thomas D. (:thomas8)]

Whoever hacked this didn't get it right.

STR

1) File > Page Setup > URL is set for upper-right corner (also for Page Setup from print preview).
2) File > Print
3) File > Print Preview > Print

Actual result

1) For Page Setup, URL in upper-right corner is TB default setting, but it's useless and dangerous, per this bug 118766.
2) For direct Print, Page Setup is ignored and the URL is not printed (bug 286627). That's good, but unexpected, hence wrong.
3) For Print via Print Preview, both the preview and the actual printout have the URL, i.e. Page Setup is respected, but its default setting is useless and dangerous (this bug 118766).

Expected result

1) File > Page Setup should default to --blank-- to match the current direct print.
2) File > Print should just print whatever is chosen in Page setup, i.e. --blank-- per this bug.
3) File > Print Preview > Print should just print whatever is chosen in Page setup, i.e. --blank-- per this bug.

Anyone with clues where in code these things get set and digested?

Comment 15

[Jorg K (CEST = GMT+2)]

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #14)
> Anyone with clues where in code these things get set and digested?
Sure. You pass a location to M-C core code for printing and it by default prints the URL onto the page (like it you print a web page in FF). I might be naïve, but where is the security hazard? No one forces you to give the paper out. It's the same as saying: Oh, my paper bank statement is a security hazard since it has the credit card number.

WONTFIX for me and for all its brothers and sisters.

Comment 16

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+2) from comment #15)
> Sure. You pass a location to M-C core code for printing

Sure... I was hoping for more specific hints but never mind, I understand this doesn't have priority so spending time on this is voluntary.

> and it by default prints the URL onto the page (like it you print a web page in FF).

Exactly. But we're not a web page, and printing message URLs on message printouts makes absolutely no sense. That's why we removed it from direct printouts, but unfortunately forgot to fix page setup and (printing from) print-preview, too.

> I might
> be naïve, but where is the security hazard? No one forces you to give the
> paper out. It's the same as saying: Oh, my paper bank statement is a
> security hazard since it has the credit card number.

You are right, it's not hazardous, hence SG:low (I couldn't find the exact meaning or list of those flags, anyone?).
But there are several ux-problems including privacy/security concerns with the current default behaviour:

1) ux-consistency: 
- Page Setup -> URL included (always)
- Direct print -> NO URL (contrary to Page Setup)
- Print Preview > Print -> URL included
Meaning it depends on how you start your printout whether the URL is included or not, and it's not predictable. I think that's quite confusing, and unprofessional.

2) privacy/security concerns:
- the physical URL of a mailbox on user's system, worse a specific message in that mailbox, is sensitive information which should never be leaked into the real world by default because it's an attack vector which depending on circumstances might be exploited for cyber attacks. It is totally not up to us to judge the actual danger, but for companies with security sensitive information in their emails this might pose a problem. Even I myself as a normal private person wouldn't want my private profile path to become known. God knows what others might do with that, and I don't really know how secure my system is if somebody tries.
- It's insufficient and irresponsible to just say "No one forces you to give the [printed] paper out"; I think it's our responsibility to avoid such risks for default setups before they actually occur (see 2, ux-error-prevention). Why expose our users to potential risk if we can avoid it?

3) ux-error-prevention:
- because of ux-inconsistency (see 1), users can easily get their secret URL printed where they didn't intend to, or NOT get their URL printed where they expected it.
- very easy to overlook the small URL header, so again there's a risk of unintentionally leaking private/security-sensitive information.

4) ux-efficiency:
- If we agree that having the full message URL on every printout is quite useless and a potential privacy/security concern for the default case (see 5), then forcing the majority of users into multi-step workarounds to switch this off is clearly violating ux-efficiency. We should just do the right thing out-of-the-box.

5) useless-UI:
- I couldn't imagine any scenario where having the full message URL would be useful, so this is useless as a default (but I'd still let the user decide in page setup to put the URL if for some reason he needs it).
- This bug causes that both long subjects AND the message URL are clipped on the printout (with ellipsis ...). So absurdly, a useless information causes loss of useful information. Full Message subject is useful information, especially on consecutive pages where the subject is not on the main part of the printed page. Subject, page numbering, and print date also help to keep your set of printed sheets together.
- While the world will still go on in spite of this bug, the current behaviour is a clear case of useless-UI (see 1). It's another one of those details which are just ridiculous, because when you copy stuff from a browser into a desktop email application, you're supposed to adjust things so that they work right for the new context.

I'm aware that we don't like to go into this type of bugs because of the hairy combination of external and internal code ("much pain, little gain" as Jörg would say). But that's a problem of ux-implementation-level which shouldn't affect our UX judgement and software quality standards.

So whilst this may not be a high-priority problem, and I'm certainly sympathetic against an attitude of reluctance to fix this, it definitely doesn't look like WONTFIX to me - if someone comes up with a patch, we should happily accept it.
(Which btw might make this another instance showing the insufficiency of the current monolithic wontfix resolution, because we can't distinguish between different types of wontfix).

Comment 17

[Thomas D. (:thomas8)]

As a real-life example, think of semi-automated systems where emails get printed into PDF and then published. User picks an email which doesn't have sensitive information, prints it to PDF (there's absolutely no reason to expect that this would expose the physical URL of the entire mail profile, more so because we don't print it on direct print). User expects (from direct print experience) that URL is NOT printed. Then prints via print preview to check the general layout before printing to PDF. Suddenly the URL comes back from nowhere, and it's easy to overlook in the small print of the header. PDF gets published, nobody cares, nobody notices, but cyber attacker is happy to get this information for free, and takes it from there.

This may or may not be far-fetched, it doesn't matter; it's still a case of ux-error-prevention. Otherwise it's just useless, and useless behaviour should be fixed. Let's have some pride in what we're doing.

Comment 18

[Thomas D. (:thomas8)]

(In reply to Thomas D. (currently busy elsewhere; needinfo?me) from comment #16)

> 1) ux-consistency: 
> 2) privacy/security concerns:
> 3) ux-error-prevention:
> 4) ux-efficiency:
> 5) useless-UI:

... and also:

6) ux-mode-error
7) ux-userfeedback

https://bugzilla.mozilla.org/describekeywords.cgi

Comment 19

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+2) from comment #15)
> Sure. You pass a location to M-C core code for printing and it by default
> prints the URL onto the page (like it you print a web page in FF). I might
> be naïve, but where is the security hazard? No one forces you to give the
> paper out. It's the same as saying: Oh, my paper bank statement is a
> security hazard since it has the credit card number.

The example is misleading. Our case is like when your bank would print your credit card number on a leaflet about their latest products, i.e. it's totally useless and unexpected to have your credit card number there and hence you might easily pass on the leaflet to someone else without noticing the leak of confidential information. More so if *some* of the advertising leaflets have your credit card number, but *others* don't. In fact, even the *same* leaflet sometimes has your number, and sometimes doesn't, in their next mailing, or depending on whether you opened your letter with a knife or a scissor (that type of behavioral "magic" is possible only in computer programs, but you get the sense).

Comment 20

[Thomas D. (:thomas8)]

Note that banks do typically *not* print full credit card numbers on any other document, even if related to your credit card account, except your credit card statement or else where it's absolutely required.

Comment 21

[Jorg K (CEST = GMT+2)]

Oh, I see, preview+print doesn't give the desired result, but (direct) print does. So you'd just have to see how those two code paths differ. As a wild guess, (direct) print passes a parameter not to print the URL, and print preview gets you into M-C core land where the print button will call printing with URL.

Fixing bugs is 97% searching and debugging and 3% adding/changing the one line that makes the difference. All core developers have spent countless hours searching to find a needle (line) in a haystack (7+ million lines). And that's the time consuming bit.

Comment 22

[Thomas D. (:thomas8)]

Attachment: Screenshot 1: Default sample printout from message reader

TL;DR of my comment 16: There are a lot of good reasons not to print the full path to the mailbox-message URL on every printout by default.

Seems like once again, time has proved me right and someone else on some other bug decided to remove the URL from default printouts after all. The new unified Print dialog of TB 91 also does away with the separate legacy print preview and page setup, it's now all-in-one.

Comment 23

[Thomas D. (:thomas8)]

Fixed by new print dialog of TB 91 -> WFM per my comment 22.