I'm late to this discussion. I think I've done the necessary homework
(reading bugs 28327, 37983, 40756) and caught up on this NG.
Ben Bucksch wrote:
> <http://bugzilla.mozilla.org/show_bug.cgi?id=28327>
>
> We're currently discussing
> 1. if we should still allow external resources to be loaded, and if
> yes, how much pref UI we should offer (only on/off or also
> black-/whitelist editing)
I'm in the "rich text email should be multipart/related" camp. This
preserves privacy and has some usability benefits. One major benefit is
that it resolves this bug without requiring a new preference.
The realist that I am, I realize that support for displaying HTML email
with external references isn't going away. The rest of this longish
message covers how best to cope. For the time-challenged, the executive
summary is:
1. don't display external resources by default. Create whatever UI you
want so power users can change this to their heart's content
2. support multipart/related in composer so we can start being good
citizens today and one day in the future forget about that awful
"loading external resources in email" thing. The benefits outweigh the
drawbacks.
3. "Send page" as sending only the HTML was a bad idea. Either just
send the URL, or send the page as multipart/related (which has issues,
so just send the URL).
> About 1.:
>
> slucy wrote:
>
>> its a well known concept so it shouldn't be difficult to get
>> across or produce a UI for.
>
>
> The problem is not the time it takes to create a UI, it's confusing users
> with yet more clutter. On/off means one checkbox, black-/whitelists
> mean one *page* of prefs UI.
I agree.
The only sensible default is "off". A default of "on" obviously defeats
the purpose of preserving privacy, but so does "ask". The non-power user
won't understand the implication of saying "yes", regardless of how well
crafted the dialog is.
Note: when I write "user won't understand X", this is shorthand for
"user doesn't have/want-to-make time for learning what X is when all
they want to do is Y", which is another way of saying "by the time user
learns all the X's, she will have become a power user and no longer
applicable to my argument" :)
>> The user wants to receive, say, an HTML mag in his email and it
>> contains images and tagged images and refresh meta tags and god
>> knows what, plugins probably as well.
>
>
> So, you want to allow all that? IMO, Jerry is right. If you want to
> deliver HTML mail with images, then include them. There might be
> people reading offline etc.. slucy, when sensing email, you can
> adjust the server usage much better. Email is usually read between
> 8-12am, and the USA makes up the majority. OTOH, you can send email
> all night. The only reasons I see for wanting to keep mails small
> are - when you expect most of them not to be read, and this is
> usually spam - in an intranet, if you want to keep the mailboxes
> small
So one day this won't be a problem, Mozilla should only generate
multipart/related when sending HTML mail. This should be a separate bug
from 28327, right? Does it already exist?
It's usefull to ask "what are the legitimate use cases of rich text
email?" when contemplating the impact of requiring multipart/related.
Here are the ones that have come up in discussion:
1. subscription periodicals from major publishers
2. internal corporate communication
3. individual email to immediate circle of recipients
4. "send page" type URL/page sharing
The "bandwidth spike" argument against multipart/related as applied to
#1 and #2 is a straw man. The cost of abolishing the expectation of
privacy when reading email is far greater than the cost to publishers to
have capable servers/bandwidth to send out their multipart/related
email. How large are these emails anyway?
For #3, multipart/related is the *only* approach that enables the
non-power user to send rich text email. They don't have a public Web
server from which to serve embedded links. Even if they did, they most
certainly would forget to use the proper image URL, instead creating a
URL like "C|///My%20Documents/...". Email composition that sends
multipart/related is simple to use and behaves as the user expects
without requiring them to understand URLs, HTML, and Web servers.
For #4, this is a special case of the bandwidth spike problem, except
the publisher is behind a 56k modem. User's won't understand the
implications of clicking "Send page" on that Flash-laden,
took-two-minutes-to-download page they want to share with their 20-50
recipient circle. So this is a legitimate problem for having mozilla
only send multipart/related.
The solution: replace "Send page" with the functionality of "Send link".
The presence of both "Send page" and "Send link" options is a
usability decreasing choice. The user wants to share a page. The
distinction between sending an attached document versus sending the URL
is irrelevant to them. Having the page display in the recipient's email
pane is a convienience, but at the cost of privacy.
Even if "Send page" must continue to send the page as an attachment,
it's innapropriate to time-shift only the markup portion of a page. In
addition to breaking offline browsing as already discussed, when you
time-shift only the markup you're asking for broken images and embedded
objects if the site's content is moved, removed, or modified. You may
think I'm being pedantic, but after 5 minutes of plugging some sites
into Google's cache, I found a cached version of www.bayarea.com where
an embedded image was later resized/changed and no longer looks
appropriate. With multipart/related, the "snapshot" is a coherent set
of content that works together.
And in case the offline browsing horse wasn't beaten to death enough...
With regards to sending pages, either really support offline browsing
and send /all/ the referenced content as multipart/related, or don't
support offline browsing and require the user to download the page
themself. The current half-implementation is the worst of both worlds
and has gotten us into this predicament.
Uhm, thanks for reading,
Tim
--
Tim Taylor
[EMAIL PROTECTED]
