pan-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pan-users] HTML posting Was: Should "Go Next Watched Article" work?


From: Duncan
Subject: Re: [Pan-users] HTML posting Was: Should "Go Next Watched Article" work?
Date: Sat, 28 Sep 2013 08:54:23 +0000 (UTC)
User-agent: Pan/0.140 (Chocolate Salty Balls; GIT 6e6fd84 /usr/src/portage/src/egit-src/pan2)

Steven D'Aprano posted on Sat, 28 Sep 2013 12:31:11 +1000 as excerpted:

> On Fri, Sep 27, 2013 at 07:53:59PM +0000, Duncan wrote:
> 
>> > WRT HTML malware, I suppose it's possible, but it seems that you
>> > would have to have pretty lax defaults for your browser and OS for
>> > that to really be a serious problem.  I worry more about my email
>> > address leaking onto the Internet
>> 
>> With email, one of the tricks spammers use to verify an address is
>> sending an HTML mail that references an image on their site. [...] This
>> sort of tracker image is called a web bug.
> 
> Web bugs and HTML are not just good for verifying email address. There
> are all sorts of tricks people can do with HTML email. They can track
> when, and if, you open emails. They can't literally tell if you have
> read the email, but they can certainly tell when and how often you've
> opened it.

That's all web bug yes.  I focused in on the email address bit since 
that's what manthony said he was worried about and that's possible with 
email, but did mention the read (or open) message tracking as well, in 
the context of news posts.

> They can implement "self-destructing emails", which can only
> be opened once, or which cannot be forwarded to others, or printed from
> the mail client. Or they can track who you forward emails to.

Of course that's beyond the relatively simple web bug, but it's doable 
with HTML, as long as the HTML client allows it, of course.  (There's a 
reason I run firefox with the noscript and requestpolicy extensions, and 
won't run non-FLOSS plugins at all, tho in general I've found plugins 
more trouble than they're worth so actually am not running any at all 
ATM.)


> If IE has a bug that lets a website install malware on your machine,
> so does Outlook which uses IE.

And the latter is worse, as at least with IE, you must visit the site, 
but with OL, anybody (or anything, including the malware a "trusted 
friend" might be inadvertently running) can send you the message.

Tho one thing requestpolicy, even more than noscript, has made quite 
apparent to me is the extent to which sites I visit pull from other 
sites, either via "website sharding" such as img1.whatever.net, 
img2.whatever.net, img3, static1, static2..., etc, or via entirely 
different sites, such as the ever-present ad and tracker sites 
(googleanalytics and the facebook/twitter/etc like buttons, anyone?).  So 
without something like requestpolicy, "must visit the site" isn't the 
restriction that it once was, for sure.

>> Meanwhile, how many non-spam/non-malware messages actually NEED HTML to
>> deliver their message effectively?
> 
> Don't mistake HTML (a technology) for the ability to use rich text (a
> function). Formatted text can be useful. We have bold and italics and
> superscripts and similar for a reason, they add information to text (or
> at least they *can* add information to text). In plain text, we're
> limited to pseudo-formatting using markup, which is second-quality at
> best. But there's no technical reason why formatted rich-text must be
> implemented by inefficient, insecure, user-hostile HTML. There are
> alternatives:
> 
> - Web and news clients could be aware of markup standards such as
>   ReST and Markdown, displaying (say) *italic* and **bold** using actual
>   italic and bold. Or at least a subset of the markup. Pan already does
>   this, in a very limited way, but doesn't support the full ReST or
>   Markdown specification.
> 
>   [Aside: technically HTML is also a markup language, but it's too
>   powerful, too verbose, and too hard to read to be a good standard for
>   rich text.)
> 
>   ReST and Markdown are good choices because they are designed to look
>   just like the ad hoc and intuitive pseudo-formatting people already
>   use for plain text email: if your mail client doesn't support ReST,
>   the marked-up text still looks good.

Indeed.

FWIW, I keep pan's markdown options (both the smilies and the formatting) 
turned off, tho, because unlike HTML, to me there's something charming 
and "get back to basics" feeling about seeing the actual markup,

But of course that's /entirely/ personal preference.  Turning on those 
options isn't going to hurt security any.  I just like them off.

> So there are options for rich text that don't involve HTML. Mail and
> news clients could include WYSIWYG editors that generated (say) ReST or
> Markdown text, and the user would never need deal with the markup
> commands themselves. They would just select a range of text and click
> the B button to format it bold. The recipient would see bold text if
> their client supported ReST, otherwise they would see **bold** text.

And of course if the client supported ReST, but the user was like me and 
preferred seeing **bold** in the literal text form so turned off the 
formatting option, they'd see it that way too. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




reply via email to

[Prev in Thread] Current Thread [Next in Thread]