On 03/19/2013 05:09 PM, Kevin Chadwick wrote: >> If you're going to call me out for ignoring things, missing things or >> simply not knowing things, please highlight what it is. "the quote" >> isn't very enlightening in this context. You have a nasty habit of >> referencing things without inlining them or referencing them directly, >> and this has gotten in the way of clear communication *multiple* times >> over the last week. >> >>> I only wrote two lines and you still missed it >> >> I respond to what's written in the email I'm replying to, because that's >> what I've just read, and that's the context of the email. >> >>> never mind the examples I had given in my original mail that do not >>> only apply to remote content and that you wrongly interpreted. >> >> Honestly, I never expected you to be up in arms over being exposed to >> HTML syntax. >> >> I presumed you were concerned about libpng, libjpeg, swf and gif. > > As I clearly said both, but actually less so html. You seem to be under > the impression Androids mail clients let you avoid all that but they do > not. Talk about hitting your head against a brick wall.
I can't tell any more whether you're complaining about people sending HTML, whether you're complaining about receiving HTML emails without being able to avoid parsing them, or whether you're complaining about other people receiving HTML emails and their being placed at risk of parsing bugs as a result. If you're complaining about other people sending HTML emails: OK, fine. Politely point out to them that it's common courtesy not to send HTML emails. PLONK them if you need to. But make it clear this is what you're complaining about. I don't see the relevance of most of your arguments if your complaint is with other people sending HTML messages. If you're complaining about receiving HTML emails without being able to avoid parsing them: You're clearly technical enough to implement some solution to avoid it. One solution would be to grab the source of an existing mail client and patch it to not handle the HTML parts. Another solution would be to have your mail pass through a server which strips messages of those parts, or modifies them in some way to make them safe. Yet another solution would be to find a mail client which does this for you. I see no reason to continue raging about the state of the mail clients you use, if this is your argument. If you're complaining about other people receiving HTML emails and their being placed at risk of parsing bugs, then provide a solution (I detailed a few in the above paragraph) and allow them to adopt it if they wish. If what you're complaining about isn't enumerated above, please try to state it simply and clearly. > >> I >> presumed you were concerned about privacy concerns. Those are what most >> people who gripe about HTML email security are concerned with. > > That would be to do with scripts and remote content. > > Remote content Is as you have said almost always switchable and so was > not a concern/thought of mine but yes, what people shout about. Scripts, > well with Googles love of javascript (for obvious tracking reasons) I > wouldn't be too surprised if that is enabled without recourse on > android email. I'm pretty sure I've never seen JS in email. Traditionally, tracking is done with image bugs. There's little to no point in using scripting in emails. And given Google is pushing as fast as they can away from RSS and toward Google+, I'm rather expecting them to look for ways to get away from email and XMPP, too. Further, most GMail users use the web interface; there's No Way In Hell Google would allow mail-delivered code to be executed from within that security context. That would be the fastlane to account hijacking. This argument boils down to: "I don't trust Google, so I'd like to suggest they would use JS in emails, because that's scary, too."
signature.asc
Description: OpenPGP digital signature
