go...@us... wrote: > Log: > Added "cloak_email_addresses" setting & support; That's cool, really. I think we can *always* cloak addresses (but please read on). We have two things to protect: The mailto: address, and the address appearing as text. * Regarding the mailto: address: The cloak_email_addresses currently encodes the characters using %XY sequences. Is there any browser which does *not* support that? If not, we can do this by default. Furthermore, we could encode at least one of the chars (maybe the "@") again using HTML entities, so that we encode "@" to "%40" to "%40". That gives a *really* strong protection, and with Firefox it works. It also works with w3m, lynx, Opera and Netscape 4.79. It doesn't work with links (which is no problem with me, though). To test it with other browsers, please load <http://www.ososo.de/misc/email.html>, check if the link points to fo...@ex..., and report here. * The other thing is the email address in plain text. We can protect the address by surrounding the "@" with <span> tags, i.e. foo<span>@</span>example.org. Since the "@" is also encoded to "@", the result is foo<span>@</span>example.org, which is pretty decent as well. From my knowledge, the <span> tags will also make the "@" appear disjoint from the rest of the email address in search results (like "foo @ example.org"). (Harvesters might get many addresses just from search engine result pages.) We could also protect dots this way. Both protections should not decrease the usability of the HTML document but give some significant protection against harvesters. Since the email address still appears machine-readable when using the cloak_email_addresses option, the protection wouldn't even be weaker. So maybe, if there aren't any problems with current browsers, we can do without the option and just cloak email addresses by default. Which would be a pretty useful feature. (I'm pretty tired; please excuse any typos and the like.) -- For private mail please ensure that the header contains 'Felix Wiemann'. http://www.ososo.de/ |
From: David G. <go...@py...> - 2005-06-20 18:59:27
Attachments:
signature.asc
|
(catching up on some old email) [Felix Wiemann, re cloak_email_addresses setting] > That's cool, really. > > I think we can *always* cloak addresses (but please read on). I don't think enabling address cloaking as the default would be a good idea. I envisage getting lots of "why is my email address all messed up like this?" questions, and having to add a FAQ entry. Let's apply the principle of least surprise here. > We have two things to protect: The mailto: address, and the address > appearing as text. > > * Regarding the mailto: address: > > The cloak_email_addresses currently encodes the characters using > %XY sequences. Is there any browser which does *not* support > that? If not, we can do this by default. > > Furthermore, we could encode at least one of the chars (maybe the > "@") again using HTML entities, so that we encode "@" to "%40" to > "%40". That gives a *really* strong protection, and > with Firefox it works. > > It also works with w3m, lynx, Opera and Netscape 4.79. It doesn't > work with links (which is no problem with me, though). Such double-indirection seems fragile, and if it doesn't work with *any* browser, I have problems with it. I'd be OK with implementing it as another optional setting, separate from (though possibly implying) cloak_email_addresses. > * The other thing is the email address in plain text. > > We can protect the address by surrounding the "@" with <span> > tags, i.e. foo<span>@</span>example.org. Since the "@" is also > encoded to "@", the result is > foo<span>@</span>example.org, which is pretty decent as well. > From my knowledge, the <span> tags will also make the "@" appear > disjoint from the rest of the email address in search results > (like "foo @ example.org"). (Harvesters might get many addresses > just from search engine result pages.) > > We could also protect dots this way. +1. This could be added to cloak_email_addresses. -- David Goodger <http://python.net/~goodger> |
From: Felix W. <Fel...@gm...> - 2005-06-27 19:57:39
|
David Goodger wrote: > Felix Wiemann wrote: > >> [...] we could encode at least one of the chars (maybe the "@") >> again using HTML entities, so that we encode "@" to "%40" to >> "%40". That gives a *really* strong protection, and >> with Firefox it works. >> >> It also works with w3m, lynx, Opera and Netscape 4.79. It doesn't >> work with links (which is no problem with me, though). Just tested, it works with links as well if I add an XHTML header. > Such double-indirection seems fragile, and if it doesn't work with > *any* browser, I have problems with it. Could y'all test if the link to fo...@ex... on <http://www.ososo.de/misc/email.html> is usable with your browser, please, and report here? In particular, I still need Internet Explorer, Safari, and Konqueror. Other browsers are welcome as well, of course. > I'd be OK with implementing it as another optional setting, separate > from (though possibly implying) cloak_email_addresses. Let's not add yet another option. If it's mostly supported, cloak_email_addresses can do it. After all, cloaking is what it's supposed to do. >> * The other thing is the email address in plain text. >> >> We can protect the address by surrounding the "@" with <span> > > +1. This could be added to cloak_email_addresses. Will implement it all at once when this discussion is finished. -- For private mail please ensure that the header contains 'Felix Wiemann'. "the number of contributors [...] is strongly and inversely correlated with the number of hoops each project makes a contributing user go through." -- ESR |
From: David G. <go...@py...> - 2005-06-27 22:00:59
Attachments:
signature.asc
|
[Felix Wiemann] > Could y'all test if the link to fo...@ex... on > <http://www.ososo.de/misc/email.html> is usable with your browser, > please, and report here? In particular, I still need Internet Explorer, > Safari, and Konqueror. It works fine on Mac OS X (10.3.9) in Firefox, Safari, and IE5.2. >> I'd be OK with implementing it as another optional setting, >> separate from (though possibly implying) cloak_email_addresses. > > Let's not add yet another option. There's nothing wrong with having lots of options. It's too late to try to keep the number of options down anyhow. > If it's mostly supported, cloak_email_addresses can do it. After > all, cloaking is what it's supposed to do. "Mostly supported" isn't good enough. "Universally supported" would be. It still seems fragile, and worthy of another option. -1 on bundling double-indirection into cloak_email_addresses. +1 on a new option, something like "cloak_email_addresses_plus". -- David Goodger <http://python.net/~goodger> |
From: Felix W. <Fel...@gm...> - 2005-06-28 16:07:03
|
David Goodger wrote: > It works fine on Mac OS X (10.3.9) in Firefox, Safari, and IE5.2. Great. >> Let's not add yet another option. > > There's nothing wrong with having lots of options. There is. The more options we have the more difficult it becomes for users to get an overview of the available options. > It's too late to try to keep the number of options down anyhow. No, not at all. There's nothing wrong with having many options, but let's only add an option if it's really needed. >> If it's mostly supported, cloak_email_addresses can do it. After >> all, cloaking is what it's supposed to do. > > "Mostly supported" isn't good enough. "Universally supported" would > be. OK, let me rephrase: It *is* universally supported by any standards-conforming web browser. > It still seems fragile, Not at all. According to the XHTML 1.0 specification, the entities within the href attribute have to be decoded. Then we get a mailto URL, and, according to RFC 2368, the "%40" is to be decoded to "@", so the email address contains indeed an "@". This mechanism can be assumed to work universally, while still providing pretty strong protection against simple regex-harvesters. If we do not cloak the text addresses with " at " but "<span>@</span>" we have a completely invisible harvesting protection. I would even make it the default because it's so useful, providing a --leave-email-addresses option. -- For private mail please ensure that the header contains 'Felix Wiemann'. "the number of contributors [...] is strongly and inversely correlated with the number of hoops each project makes a contributing user go through." -- ESR |
From: David G. <go...@py...> - 2005-06-29 22:32:27
Attachments:
signature.asc
|
[Felix Wiemann] > There is. The more options we have the more difficult it becomes > for users to get an overview of the available options. We're already past that point. Perhaps we need a user document to provide such an overview. >> It's too late to try to keep the number of options down anyhow. > > No, not at all. There's nothing wrong with having many options, but > let's only add an option if it's really needed. I think it really is. We have at least one example of where this doesn't work (in "links", without an XHTML header). That's enough. >>> If it's mostly supported, cloak_email_addresses can do it. After >>> all, cloaking is what it's supposed to do. >> >> "Mostly supported" isn't good enough. "Universally supported" would >> be. > > OK, let me rephrase: It *is* universally supported by any > standards-conforming web browser. Another qualification. Let me restate: "Universally supported." (full-stop, no qualifications) would be good enough. Anything less isn't. > I would even make it the default because it's so useful, providing a > --leave-email-addresses option. -1 -- David Goodger <http://python.net/~goodger> |
From: Felix W. <Fel...@gm...> - 2005-07-03 09:26:55
|
David Goodger wrote: > Felix Wiemann wrote: > >> There is. The more options we have the more difficult it becomes for >> users to get an overview of the available options. > > We're already past that point. Perhaps we need a user document to > provide such an overview. Or just polish docs/user/config.txt. > [...] We have at least one example of where this doesn't work (in > "links", without an XHTML header). That's enough. That's not a valid argument, because the XHTML header *is* present in documents generated by the HTML writer. A similar example: Internet Explorer gives wrong rendering if the XML declaration (IIRC) is omitted. So what? Both the XML and and the XHTML header are present, and if anyone removes it, that's not within the scope of Docutils anymore. >> It *is* universally supported by any standards-conforming web >> browser. > > Another qualification. Let me restate: "Universally supported." > (full-stop, no qualifications) would be good enough. Anything less > isn't. I'm sorry I have to say this, but this argument is unfair, for two reasons: 1. I have no possibility to prove that it is universally supported. 2. The requirement of "universal support" does not apply to other features of the HTML writer either. We are trying to be compatible to the XHTML/CSS standard and to the peculiarities of all major browsers currently in use. We have this compatibility for the proposed cloaking mechanism. We have this compatibility (and nothing more, no "universal" compatibility!) for any other feature of the HTML writer. In fact, we're already using *both* ways of cloaking email addresses: * Using entities ("@") without --cloak-email-addresses. * Using URI-escapes ("%40") with --cloak-email-addresses. All I'm proposing is using the first method (HTML entities) for --cloak-email-addresses as well. This would also have the advantage the the email address is still recognizable from the URL ("mailto:Felix.Wiemann%40gmx.net"), which is not the case with the current cloaking mechanism. >> I would even make it the default because it's so useful, providing a >> --leave-email-addresses option. > > -1 You're right, making it the default might be too unexpected for users. -- For private mail please ensure that the header contains 'Felix Wiemann'. "the number of contributors [...] is strongly and inversely correlated with the number of hoops each project makes a contributing user go through." -- ESR |
From: David G. <go...@py...> - 2005-08-04 23:46:35
Attachments:
signature.asc
|
(now catching up on my docutils-develop backlog; sorry for the delay) [David Goodger] >> Another qualification. Let me restate: "Universally supported." >> (full-stop, no qualifications) would be good enough. Anything less >> isn't. [Felix Wiemann] > I'm sorry I have to say this, but this argument is unfair, for two > reasons: > > 1. I have no possibility to prove that it is universally supported. I'm not asking you to. But you already provided an example where the proposed new feature is unsupported, which is enough for me to veto the idea. > 2. The requirement of "universal support" does not apply to other > features of the HTML writer either. I'm not saying it does, and that's not relevant. Let me restate. What I'm saying is that in order for me to be comfortable adding this (or any other) feature, nothing should break (at least, without a damn good reason). You already showed one example where it *would* break: "links", without an XHTML header (which is easy to produce with the publish_parts API). > In fact, we're already using *both* ways of cloaking email addresses: > > * Using entities ("@") without --cloak-email-addresses. > * Using URI-escapes ("%40") with --cloak-email-addresses. > > All I'm proposing is using the first method (HTML entities) for > --cloak-email-addresses as well. But you're proposing to *combine* the two methods. *That* is what I'm uncomfortable with. From way back: >>> we encode "@" to "%40" to "%40" That's applying 2 encoding steps, which requires 2 steps to decode. If any software applies the steps in the wrong order, it just won't work. That's just too fragile for me. -- David Goodger <http://python.net/~goodger> |
From: Felix W. <Fel...@gm...> - 2005-08-16 19:57:38
|
David Goodger wrote: > I'm not asking you to. But you already provided an example where the > proposed new feature is unsupported, which is enough for me to veto > the idea. First, it turns out that "links" has the problem with or without XHTML header. Second, it turns out that "links" chokes on the current cloaking mechanism as well: The email address in <http://www.ososo.de/misc/email-now.html> ends up being interpreted as "@_46_65_6C_69_78_2E_57_69_65_6D_61_6E_6E_40_67_6D_78_2E_6E_65_74". With my proposed change, as in <http://www.ososo.de/misc/email-proposed.html>, the email address ends up as "@Felix.Wiemann_40gmx.net", which is better. So the current implementation already lacks universal support. The proposed change doesn't worsen the problem. On the contrary, it makes the email address reconstructable should a browser be unable to decode it. Can I go ahead and make the change? > That's applying 2 encoding steps, which requires 2 steps to decode. These two steps happen in two different layers of the browser: One in the HTML parser (decoding entities), the other one in the URI handler (decoding "%xx" characters). That's why it isn't fragile, and why *no* existing browser has a problem with the indirection. (Links' problem is not the indirection but the "%xx" hex-encoding, as you can see from the first example above.) -- For private mail please ensure that the header contains 'Felix Wiemann'. "the number of contributors [...] is strongly and inversely correlated with the number of hoops each project makes a contributing user go through." -- ESR |
From: David G. <go...@py...> - 2005-09-16 13:06:25
Attachments:
signature.asc
|
[Felix Wiemann] > First, it turns out that "links" has the problem with or without > XHTML header. > > Second, it turns out that "links" chokes on the current cloaking > mechanism as well: > > The email address in <http://www.ososo.de/misc/email-now.html> ends > up being interpreted as > "@_46_65_6C_69_78_2E_57_69_65_6D_61_6E_6E_40_67_6D_78_2E_6E_65_74". > > With my proposed change, as in > <http://www.ososo.de/misc/email-proposed.html>, the email address > ends up as "@Felix.Wiemann_40gmx.net", which is better. But still broken. Can't it be fixed? If not, there should be a clear warning in the docs & help that there's a problem when using "links". > So the current implementation already lacks universal support. The > proposed change doesn't worsen the problem. On the contrary, it > makes the email address reconstructable should a browser be unable > to decode it. > > Can I go ahead and make the change? As long as it's optional, and off by default: +1. -- David Goodger <http://python.net/~goodger> |
From: David G. <go...@py...> - 2005-09-16 13:06:27
Attachments:
signature.asc
|
[Felix Wiemann] > First, it turns out that "links" has the problem with or without > XHTML header. > > Second, it turns out that "links" chokes on the current cloaking > mechanism as well: > > The email address in <http://www.ososo.de/misc/email-now.html> ends > up being interpreted as > "@_46_65_6C_69_78_2E_57_69_65_6D_61_6E_6E_40_67_6D_78_2E_6E_65_74". > > With my proposed change, as in > <http://www.ososo.de/misc/email-proposed.html>, the email address > ends up as "@Felix.Wiemann_40gmx.net", which is better. But still broken. Can't it be fixed? If not, there should be a clear warning in the docs & help that there's a problem with "links". > So the current implementation already lacks universal support. The > proposed change doesn't worsen the problem. On the contrary, it > makes the email address reconstructable should a browser be unable > to decode it. > > Can I go ahead and make the change? As long as it's optional, and off by default, go ahead. -- David Goodger <http://python.net/~goodger> |
From: Paul M. <p.f...@gm...> - 2005-06-28 10:40:09
|
On 6/27/05, Felix Wiemann <Fel...@gm...> wrote: > Could y'all test if the link to fo...@ex... on > <http://www.ososo.de/misc/email.html> is usable with your browser, > please, and report here? In particular, I still need Internet Explorer, > Safari, and Konqueror. Other browsers are welcome as well, of course. Works for me in IE6 on Windows 2000 (with Outlook as mail client). Paul |
From: Felix W. <Fel...@gm...> - 2005-09-17 22:51:48
|
David Goodger wrote: > Felix Wiemann wrote: > >> "links" chokes on the current cloaking mechanism as well: >> >> The email address in <http://www.ososo.de/misc/email-now.html> ends >> up being interpreted as >> "@_46_65_6C_69_78_2E_57_69_65_6D_61_6E_6E_40_67_6D_78_2E_6E_65_74". >> >> With my proposed change, as in >> <http://www.ososo.de/misc/email-proposed.html>, the email address >> ends up as "@Felix.Wiemann_40gmx.net", which is better. > > But still broken. Can't it be fixed? Probably not... > If not, there should be a clear warning in the docs & help that > there's a problem with "links". Done. (Not in the help, though. That would be too verbose, and we should keep the help messages as concise as possible, I think.) >> Can I go ahead and make the change? > > As long as it's optional, and off by default, go ahead. Done. :-) -- For private mail please ensure that the header contains 'Felix Wiemann'. "the number of contributors [...] is strongly and inversely correlated with the number of hoops each project makes a contributing user go through." -- ESR |