J
jojo
John said:
That's because spambots are against the spirit of the internet, too. If
the "dark side" does not follow the rules we don't have to follow them
either.
That's because spambots are against the spirit of the internet, too. If
the "dark side" does not follow the rules we don't have to follow them
either.
J
John Dunlop
jojo:
Under discussion was not the spirit of the Internet but the spirit of
Internet specifications. What harvesters do does not run contrary to
the word or the spirit of the two specifications I mentioned. I would
maintain that what you proposed - replacing US-ASCII characters with
character references in HTML, and percent-encoding octets in URLs that
would otherwise be treated as data - does.
Come on. Internet specifications are a boon! If you fail to grasp the
advantages they bring - if you fail to imagine a WWW without them - why
wait until the "dark side" supposedly deviates from them before you
ignore them yourself?
Besides, in this war, there are more effective and less harmful
strategies than obfuscation.
Under discussion was not the spirit of the Internet but the spirit of
Internet specifications. What harvesters do does not run contrary to
the word or the spirit of the two specifications I mentioned. I would
maintain that what you proposed - replacing US-ASCII characters with
character references in HTML, and percent-encoding octets in URLs that
would otherwise be treated as data - does.
Come on. Internet specifications are a boon! If you fail to grasp the
advantages they bring - if you fail to imagine a WWW without them - why
wait until the "dark side" supposedly deviates from them before you
ignore them yourself?
Besides, in this war, there are more effective and less harmful
strategies than obfuscation.
N
Nikita the Spider
"John Dunlop said:
Myself, I'm pretty impressed by the fact that the entity-encoded address
received only two spams while its unprotected counterpart has received
over 700. If this method is inferior, I'd like to know to what! If there
are other methods that are equally easy to implement and don't
inconvenience users, I can't say I've heard of them.
I'd argue that we're not talking about security here so much as
annoyance reduction. I don't mean to nitpick about your words; I
honestly think the difference is important. Security prohibits access to
a resource and there are clear negative consequences when it fails (my
account is cracked, for example). By contrast, my inbox lost its spam
virginity a long time ago. All I can do now with the resources I have
available is to limit further, ahem, penetrations.
I see your point, but the spec isn't strongly worded. As you pointed
out, the relevant section is here:
http://www.w3.org/TR/html401/charset.html#h-5.3
"A given character encoding may not be able to express all characters of
the document character set. For such encodings, or when hardware or
software configurations do not allow users to input some document
characters directly, authors may use SGML character references."
But it also says this:
"Character references are a character encoding-independent mechanism for
entering any character from the document character set."
Using entities to encode email addresses fits perfectly well within this
provision, IMO.
Cheers
C
Chris F.A. Johnson
As NtS pointed out, that's not true (or, at least, debatable).
That's what obfuscate e-mail addresses do. Letting spam be
generated any more than necessary is passing the buck. The
important thing it to prevent it (as much as possible) in the first
place.
J
John Dunlop
Chris F.A. Johnson:
?? No. E-mail address obfuscation tries to deal with the problem at
the user's end. Its aim is to remove all trouble for the e-mail
address owner, no matter the cost to anyone else. If obfuscation dealt
with the problem at your end, it wouldn't be obfuscation since there
would be nothing to obfuscate.
It is not your job to prevent spam being generated, unless you are
actively fighting against it, in which case there are better, more
effective approaches than e-mail address obfuscation.
?? No. E-mail address obfuscation tries to deal with the problem at
the user's end. Its aim is to remove all trouble for the e-mail
address owner, no matter the cost to anyone else. If obfuscation dealt
with the problem at your end, it wouldn't be obfuscation since there
would be nothing to obfuscate.
It is not your job to prevent spam being generated, unless you are
actively fighting against it, in which case there are better, more
effective approaches than e-mail address obfuscation.
J
John Dunlop
Nikita the Spider:
mentioned now more than once in this thread: normal counter-spam
measures. That means junk mail filters both at the server and at the
MUA.
[re e-mail address obfuscation running contrary to the spirit of
Internet specs]
Well, every clause in the spec is vague enough to be open to, however
absurd, interpretation.
I specifically talked not about the spec's wording but about its
spirit. To learn about the spirit of HTML you have to trace its
history: follow the past discussions, study the earlier drafts and
specifications, find out why the constructs were introduced in the
first place.
I quoted from there but did not mean that as the 'relevant section' to
learn why character references came about. You will find that not in
the HTML4.0 spec but in ISO8879 (my copy's at work and I haven't yet
memorised it all, so much to my consternation I can't give you chapter
and verse.)
That's not even half the story.
mentioned now more than once in this thread: normal counter-spam
measures. That means junk mail filters both at the server and at the
MUA.
[re e-mail address obfuscation running contrary to the spirit of
Internet specs]
Well, every clause in the spec is vague enough to be open to, however
absurd, interpretation.
I specifically talked not about the spec's wording but about its
spirit. To learn about the spirit of HTML you have to trace its
history: follow the past discussions, study the earlier drafts and
specifications, find out why the constructs were introduced in the
first place.
I quoted from there but did not mean that as the 'relevant section' to
learn why character references came about. You will find that not in
the HTML4.0 spec but in ISO8879 (my copy's at work and I haven't yet
memorised it all, so much to my consternation I can't give you chapter
and verse.)
That's not even half the story.
D
dorayme
"John Dunlop said:
I am in a picky mood, just excuse and ignore it: the lazy theory
is inadequate, not so plausible. You do need help. Go and study
the robber analogy of mine, the robber is not lazy. He can get
what he wants from unsecured houses. He is rationalising his
resources.
You were giving a different impression to me at least. I was
getting a message from your words that it was ineffective, that
it would not deter. You did not make things so utterly clear. You
did not say out loud, yes, it will reduce spam but these are the
downsides... You gave the impression of conflating these issues.
<g> I have a car protection system I made myself that is a sort
of inverse of this! It consists of a "key" and "switch" that is
not hidden from view, it is just not obvious to anyone's mind. It
gives me a great sense of security and has worked on a number of
occasions, both on my car and my daughter's and a neighbours'...
It is not my spam. Tell that to my client. But, Jock, be careful,
he is 6 foot 8 inches and built like a brick shit-house, has red
hair and is not delicate, if you know what I mean. I think I will
use en encoding just on this occasion...
N
Nikita the Spider
"John Dunlop said:
Hmmm, I guess we'll have to disagree on the criteria we use to measure
"inferior". Even the best mail filters can generate false positives,
which is something that an entity-encoded address won't do. And it'd
have to be a pretty darn effective filter (or set of filters) to achieve
what the entity encoding has done in this test. Furthermore, entity
encoding is something that any Web page author can do; the same can't be
said for setting up and tuning server-side filters. Last but not least,
entity encoding *prevents spam from being generated*. Mail filtering
doesn't do this. And if I just rely on my ISP's filters to handle my
spam for me, isn't that "passing the buck"?
If you say so.
I haven't read ISO8879. I'll grant that my opinion might change after
doing so. But of all of the abuses to which HTML has been and is
subjected (sending XHTML as text/html comes to mind), I find it hard to
believe that entity encoding email addresses would be in the top one
hundred of many people's lists, if at all.
D
Dan
dorayme said:
I personally find it aesthetically distasteful to do any sort of
obfuscation of addresses; it just seems to go against the grain of
Internet standards that have always been designed to keep things as
open as possible, not intentionally obscure. Some of the
character-encoding stuff I can more-or-less tolerate because you have
to view the source code to see that it's whacked out, but other things
like spelling out "address at something dot net", or putting in
signature notes like "remove 'x' from my address", or embedding an
address as a graphic, just rub my nose in the fact that it's being
intentionally made more difficult to use. That's the sort of thing up
with which I won't put.
D
dorayme
"Dan said:
That is a fine speech. See my reference to Burning Mississipi.
But I agree that the seen email address should be normal
looking. There is a way around this, to not put any at all, just
a link, the words being, "email us" or whatever.
I would be interested to hear from anyone who has an idea of the
chances of email harvesting happening from the expressed text on
the page as distinct from the source. Without some idea of this
knowledge, one is less equipped to inform the good-guy dirty
tricks department. (If Spider's impressive figures are anything
to go on, it looks like these evil bots garner from the source
mainly)
N
Nico Schuyt
Nikita said:
Both are unreliable. Even *I* can make script that extracts email addresses
from JS or entity coded text
Use a mail form.
D
dorayme
"Nico Schuyt said:Both are unreliable. Even *I* can make script that extracts email addresses
from JS or entity coded text
Use a mail form.
Would you, Mr Korpela and Jock - you see, Nico what good company
you are in...
- please not ignore the fact that it works to actually stop spam. If you don't think it actually does, say so
loud and clear. The issue of it "being easy" to overcome is quite
irrelevent in a world where almost no bots do this. This is the
world you earthlings and I live for the moment. What world are
you talking about? One in which Spider's stats are not true? In
this world it looks to me to be very reliable for now.
N
Nico Schuyt
Would you, Mr Korpela and Jock - you see, Nico what good company
you are in...
actually stop spam. If you don't think it actually does, say so
loud and clear.
Working *now* is no guarantee what so ever for being effective in the near
future.
Stats are never true
The place is right; it's the time that might be a problem.
Tomorrow I'll launch my new evil bot.
J
John Dunlop
dorayme:
Oops! Ok, so 'lazy' might not be the /mot juste/, as they say in the
Gorbals, but 'rationalising one's resources' seems to be more or less a
rehashing of the same theory, no? Anyway, it's one I'll have to
remember next time I'm asked to go to the gym.
'I should emphasize that I'm not saying that attempts at obfuscation
will universally fail, only that it takes little effort to overcome
them.'
Does it reduce spam? It would seem to reduce the amount of spam that
that e-mail address owner receives, yes, but whether it makes an impact
on spam in the grand scheme of things, I don't know. Wouldn't a
harvester simply pick other addresses?
Ok. Let me list some options.
1. Obfuscate the address on the page:
a. munging
b. character references
c. percent-encodings
d. human-only addresses (e.g., 'user (at) host')
e. address written in javascript
2. Implement junk mail filters:
a. server filters
b. MUA filters
3. Remove all trace of the address.
Now my position regarding 1(b,c). Character references are the lesser
of the two evils, because while percent-encodings actually change the
URL for some degrees of equivalency, upsetting the user-interface,
character references don't.
But character references were 'intended to be used when you could not
otherwise enter a character conveniently in the text' (/The SGML
Handbook/ p. 356). I would be surprised if it inconvenienced you to
enter most US-ASCII characters directly.
I could find other analogies such as hiding the backdoor key to your
house under a stone, or hiding the key to your car under a wheel arch,
but I'm not sure what you're getting at here. The sense of security
can be real but false.
If you feel the practical benefits of e-mail address obfuscation
outweigh the practical downsides - e.g., the impression of
unprofessionalism, the mangling of the user-interface by
percent-encoding - and the theoretical downsides, who am I to stand in
your way.
I suppose any persuasiveness I enjoyed must yield to Friday the 13th.
Oops! Ok, so 'lazy' might not be the /mot juste/, as they say in the
Gorbals, but 'rationalising one's resources' seems to be more or less a
rehashing of the same theory, no? Anyway, it's one I'll have to
remember next time I'm asked to go to the gym.
'I should emphasize that I'm not saying that attempts at obfuscation
will universally fail, only that it takes little effort to overcome
them.'
Does it reduce spam? It would seem to reduce the amount of spam that
that e-mail address owner receives, yes, but whether it makes an impact
on spam in the grand scheme of things, I don't know. Wouldn't a
harvester simply pick other addresses?
Ok. Let me list some options.
1. Obfuscate the address on the page:
a. munging
b. character references
c. percent-encodings
d. human-only addresses (e.g., 'user (at) host')
e. address written in javascript
2. Implement junk mail filters:
a. server filters
b. MUA filters
3. Remove all trace of the address.
Now my position regarding 1(b,c). Character references are the lesser
of the two evils, because while percent-encodings actually change the
URL for some degrees of equivalency, upsetting the user-interface,
character references don't.
But character references were 'intended to be used when you could not
otherwise enter a character conveniently in the text' (/The SGML
Handbook/ p. 356). I would be surprised if it inconvenienced you to
enter most US-ASCII characters directly.
I could find other analogies such as hiding the backdoor key to your
house under a stone, or hiding the key to your car under a wheel arch,
but I'm not sure what you're getting at here. The sense of security
can be real but false.
If you feel the practical benefits of e-mail address obfuscation
outweigh the practical downsides - e.g., the impression of
unprofessionalism, the mangling of the user-interface by
percent-encoding - and the theoretical downsides, who am I to stand in
your way.
I suppose any persuasiveness I enjoyed must yield to Friday the 13th.
N
Nikita the Spider
A mail form != an email address hyperlink. The former is less convenient
for the user. Yes, email forms limit spam but so does putting one's
email address in an image instead of text, or writing "foo (at) example
dot com". As John Dunlop rightly said, that's "passing the buck" -- you
inconvenience the user. I want to avoid that if possible.
The same could be said for all spam blocking methods (my Bayesian
filters used to work a lot better, for example). So should we should
abandon all attempts to block spam because none of them are guaranteed?
Hmmmm, OK. But you go first.
for the user. Yes, email forms limit spam but so does putting one's
email address in an image instead of text, or writing "foo (at) example
dot com". As John Dunlop rightly said, that's "passing the buck" -- you
inconvenience the user. I want to avoid that if possible.
The same could be said for all spam blocking methods (my Bayesian
filters used to work a lot better, for example). So should we should
abandon all attempts to block spam because none of them are guaranteed?
Hmmmm, OK. But you go first.
H
Harlan Messinger
Nikita said:
Not necessarily, and altogether false for users not using an e-mail
client on their local machine, e.g., all users of web-based mail
services, many users of computers at their work place, and all users of
computers at libraries, Internet cafes, etc.
Further, if you are interested in, or think you may ever be interested
in, capturing information from the user besides the message itself (how
did you hear about us? is this a bug report, a help request, or a new
feature suggestion?), then the form is the way to go.
N
Nico Schuyt
Nikita said:Nico Schuyt" said:dorayme said:"Nico Schuyt" wrote:
Nikita the Spider wrote:
I've set up several spamtrap addresses to study this.
[JS versus entity encoding]
Both are unreliable. Even *I* can make script that extracts email
addresses from JS or entity coded text
Use a mail form.
Maybe it's more inconvenient for the user if he tries to contact you in an
internet cafe (no mail client)
Not so friendly for the visitor either
But I just applied your entity-encoding-tric in a site where I needed an
e-mail address and didn't had time to install a form
Thanks for the tip!
BTW for encoding of a string ($str) with the e-mail address into html
entities I used:
<php
$str="<e-mail address>";
for ($i=0;$i<strlen($str);$i++)
printf('&#%03d;',ord($str{$i}));
?>
N
Nikita the Spider
Harlan Messinger said:
Fair enough, I hadn't thought of those scenarios. But Web mail users
*do* have an email client on their local machine -- the browser.
Yes, some of these are good candidates for forms.
D
dorayme
Working *now* is no guarantee what so ever for being effective in the near
future.
[/QUOTE]
This is simply not true. If you had left it at the "no guarantee:
and not added the "whatsoever" you would have had a fighting
chance old chap.
Stats are never true
Come now Nico, you can't believe this.
Ah... this is the kind of talk I like, evil talk. If you have
plans... all this is different...
D
dorayme
"John Dunlop said:
Well, this is what I would like to know more about. When I do
bad, I prefer not to be low class about it. I want to know what
evil I commit. What mangling are you talking about? I have
attempted a few times to raise the question about how bots work,
on the source code or the expressed page text (visible and
audible etc as normal text to humans). It seems it is mainly the
former. If so, who besides alt.html types will it seem so
unprofessional to?