473,320 Members | 2,104 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Jargons of Info Tech industry

Jargons of Info Tech industry

(A Love of Jargons)

Xah Lee, 2002 Feb

People in the computing field like to spur the use of spurious jargons.
The less educated they are, the more they like extraneous jargons, such
as in the Unix & Perl community. Unlike mathematicians, where in
mathematics there are no fewer jargons but each and every one are
absolutely necessary. For example, polytope, manifold,
injection/bijection/surjection, group/ring/field.., homological,
projective, pencil, bundle, lattice, affine, topology, isomorphism,
isometry, homeomorphism, aleph-0, fractal, supremum/infimum, simplex,
matrix, quaternions, derivative/integral, ... and so on. Each and every
one of these captures a concept, for which practical and theoretical
considerations made the terms a necessity. Often there are synonyms for
them because of historical developments, but never “jargons for
jargon's sake” because mathematicians hate bloats and irrelevance.

The jargon-soaked stupidity in computing field can be grouped into
classes. First of all, there are jargons for marketing purposes. Thus
you have Mac OS “X”, Windows “XP”, Sun OS to Solaris and the
versioning confusion of 4.x to 7 to 8 and also the so called
“Platform” instead of OS. One flagrant example is Sun Microsystem's
Java stuff. Oak, Java, JDK, JSDK, J2EE, J2SE enterprise edition or no,
from java 1.x to 1.2 == Java 2 now 1.3, JavaOne, JFC, Jini, JavaBeans,
entity Beans, Awk, Swing... fucking stupid Java and fuck Sun
Microsystems. This is just one example of Jargon hodgepodge of one
single commercial entity. Marketing jargons cannot be avoided in modern
society. They abound outside computing field too. The Jargons of
marketing came from business practice, and they can be excusable
because they are kinda a necessity or can be considered as a naturally
evolved strategy for attracting attention in a laissez-faire economy
system.

The other class of jargon stupidity is from computing practitioners, of
which the Unix/Perl community is exemplary. For example, the name Unix
& Perl themselves are good examples of buzzing jargons. Unix is
supposed to be opposed of Multics and hints on the offensive and
tasteless term eunuchs. PERL is cooked up to be “Practical Extraction
& Reporting Language” and for the precise marketing drama of being
also “Pathologically Eclectic Rubbish Lister”. These types of
jargons exudes juvenile humor. Cheesiness and low-taste is their
hall-mark. If you are familiar with unixism and perl programing, you'll
find tons and tons of such jargons embraced and verbalized by unix &
perl lovers. e.g. grep, glob, shell, pipe, man, regex, more, less,
tarball, shebang, Schwartzian Transform, croak, bless, interpolation,
TIMTOWTDI, DWIM, RFC, RTFM, I-ANAL, YMMV and so on.

There is another class of jargon moronicity, which i find them most
damaging to society, are jargons or spurious and vague terms used and
brandished about by programers that we see and hear daily among design
meetings, online tech group postings, or even in lots of computing
textbooks or tutorials. I think the reason for these, is that these
massive body of average programers usually don't have much knowledge of
significant mathematics, yet they are capable of technical thinking
that is not too abstract, thus you ends up with these people defining
or hatching terms a-dime-a-dozen that's vague, context dependent,
vacuous, and their commonality are often a result of sopho-morons
trying to sound big.

Here are some examples of the terms in question:

• anonymous functions or lambda or lamba function
• closure
• exceptions (as in Java)
• list, array, vector, aggregate
• hash (or hash table) ← fantastically stupid
• rehash (as in csh or tcsh)
• regular expression (as in regex, grep, egrep, fgrep)
• name space (as in Scheme vs Common Lisp debates)
• depth first/breadth first (as in tree traversing.)
• operator
• operator overloading
• polymorphism
• inheritance
• first class objects
• pointers, references
• tail recursion

My time is limited, so i'll just give a brief explanation of my thesis
on selective few of these examples among the umpteen.

In a branch of math called lambda calculus, in which much theories of
computation are based on, is the origin of the jargon _lambda function_
that is so frequently reciprocated by advanced programering donkeys. In
practice, a subroutine without side-effects is supposed to be what
“lambda function” means. Functional languages often can define them
without assigning them to some variable (name), therefore the
“function without side-effects” are also called “anonymous
functions”. One can see that these are two distinct concepts. If
mathematicians are designing computer languages, they would probably
just called such thing _pure functions_. The term conveys the meaning,
without the “lamba” abstruseness. (in fact, the mathematics
oriented language Mathematica refers to lambda function as pure
function, with the keyword Function.) Because most programers are
sopho-morons who are less capable of clear thinking but nevertheless
possess human vanity, we can see that they have not adopted the clear
and fitting term, but instead you see lambda function this and that
obfuscations dropping from their mouths constantly.

Now the term “closure” can and indeed have meant several things in
the computing field. The most common is for it to mean a subroutine
that holds some memory but without some disadvantages of modifying a
global variable. Usually such is a feature of a programing language.
When taken to extreme, we have the what's called Object Oriented
Programing methodology and languages. The other meaning of
“closure” i have seen in text books, is for it to indicate that the
things in the language is “closed” under the operations of the
language. For example, for some languages you can apply operations or
subroutines to any thing in the language. (These languages are often
what's called “dynamic typing” or “typeless”). However, in
other languages, things have types and cannot be passed around
subroutines or operators arbitrarily. One can see that the term
“closure” is quite vague in conveying its meaning. The term
nevertheless is very popular among talkative programers and dense
tutorials, precisely because it is vague and mysterious. These
pseudo-wit living zombies, never thought for a moment that they are
using a moronic term, mostly because they never clearly understand the
concepts behind the term among the contexts. One can particular see
this exhibition among Perl programers. (for an example of the
fantastically stupid write-up on closure by the Perl folks, see
“perldoc perlfaq7” and “perldoc perlref”.)

in the so-called “high-level” computing languages, there are often
data types that's some kind of a collection. The most illustrative is
LISt Processing language's lists. Essentially, the essential concept is
that the language can treat a collection of things as if it's a single
entity. As computer languages evolve, such collection entity feature
also diversified, from syntax to semantics to implementation. Thus,
beside lists, there are also terms like vector, array, matrix, tree,
hash/“hash table”/dictionary. Often each particular term isto
convey a particular implementation of collection so that it has certain
properties to facilitate specialized uses of such groupy. The Java
language has such groupy that can illustrate the point well. In Java,
there are these hierarchy of collection-type of things:

Collection
Set (AbstractSet, HashSet)
SortedSet (TreeSet)
List (AbstractList, LinkedList, Vector, ArrayList)

Map (AbstractMap, HashMap, Hashtable)
SortedMap (TreeMap)

The words without parenthesis are Java Interfaces, and ones in are
implementations. The interface hold a concept. The deeper the level,
the more specific or specialized. The implementation carry out
concepts. Different implementation gives different algorithmic
properties. Essentially, these hierarchies of Java show the potential
complexity and confusion around groupy entities in computer languages.
Now, among the programers we see daily, who never really thought out of
these things, will attach their own specific meaning to
list/array/vector/matrix/etc type of jargons in driveling and
arguments, oblivious to any thought of formalizing what the fuck they
are really talking about. (one may think from the above tree-diagram
that Java the language has at least put clear distinction to interface
and implementation, whereas in my opinion they are one fantastic fuck
up too, in many respects.)

---------------------
This post is archived at
http://xahlee.org/UnixResource_dir/writ/jargons.html
© Copyright 2002 by Xah Lee.

Xah
xa*@xahlee.org
http://xahlee.org/

Aug 12 '05
385 16815
In comp.lang.perl.misc Roedy Green <my******************************@munged.invalid > wrote:
On Thu, 13 Oct 2005 01:17:45 -0400, Mike Meyer <mw*@mired.org> wrote
No, that's what makes email a vector for infection. What makes using
the address book - for whatever purpose - possible for viruses is
having an API that allows arbitrary code to access it. But you have to
have that API - your customers are going to insist that they be able
to use their address book from third party applications.

An automated change of address is possible today. It would be LESS
easy to pull off under the scheme I proposed that requires digital
signatures.


How? I keep my address book on my Palm as I send mail from different
computers? I suspect many other people do as well.

Axel
Oct 13 '05 #351
Roedy Green <my******************************@munged.invalid > writes:
On Thu, 13 Oct 2005 01:32:03 -0400, Mike Meyer <mw*@mired.org> wrote
or quoted :
That won't prevent phishing, that will just raise the threshhold a
little. The first hurdle you have to get past is that most mail agents
want to show a human name, not some random collection of symbols that
map to a unique address. Even if you do that, most readers aren't
going to pay attention to said random collection of symbols. Given
that, there are *lots* of tricks that can be used to disguise the
signed name, most of which phishers are already using. How many people
do you think will really notice that mail from "John Bath, PayPal
Customer Service Representative" (jo********@paypa1.com) isn't really
from paypal?
I think it better than you imagine.

First of all Mr. Phish will come in as a new communicant begging an
audience. That is your first big clue. PayPal is already allowed in.


That's your first big clue. You've got two problems, though.

1) An as yet unspecified mechanism that magically approves everyone
that you want to talk to. That's a big lump to swallow. It's also
not an easy problem - all existing mechanisms for approving people
require constant attention. Casual users aren't going to put up
with that.

2) What makes you think your average user will realize this? It only
takes a few percent to make it worth the phishers time.
Next if Thawte issues certs, they won't allow Phish names such as
Paypol.com just as now for other certs.
So they'll do what their web sites do now, and sign their own certs.
Mr. Phish is coming in on a different account.
Different from what? And how does the user get told about this, and
what will make them care?
Next Mr. Phish had to present his passport etc when he got his Thawte
ID. Now Interpol has a much better handle on putting him in jail.


Not if he didn't have to go to Thawte.

<mike

--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Oct 13 '05 #352
>Hello? I don't think that should make any difference. I should be able
to visit absolutely any website on the Internet without any danger to my
computer or the data stored on it. Any browser which allows otherwise
has a bug.
Then Javascript *as a language* is a bug.
Javascript is not inherently a virus vector. Flawed
A virus vector is not the only security problem. Leaking
information to the web site is also a problem.
implementations might be; the language itself is not.
Does the language allow Javascript to open a new window? Does the
language allow Javascript to trigger a function when a window is
closed? I believe the answer to both questions is YES. Then it
is possible to have a page that pops up two windows whenever you
close one. This isn't theoretical: I've seen someone demonstrate
this with certain nasty porn sites. The only way to recover was
to kill off the browser and restart it. (Clicking HOME apparently
fired off a cascade of closed windows which then opened more, running
the browser out of virtual memory.) Because of this, he lost work
in progress with another web site. (Apparently he accidentally
clicked on a banner ad which lead to this booby-trapped site.)
Similarly for
anything else. In reality, with a properly-configured, good quality
operating system (probably a UNIX-type system), one ought to be able to
run full native code without any danger to one's computer or data
(think: under the NOBODY account on Linux).


If it can reveal my email address to any web site, it's a bug. If
it can access or alter my personal files or address book, it's a
bug. If it can generate hits on web sites other than that specified
in the HTML, it's a bug. If it can open sockets, it's a bug.
If it can look at or set cookies stored on my system, it's a bug.
If it can look at or alter the list of previously visited URLs, it's
a bug.
Browsers don't read unsolicited web sites. Email readers do, however,
read unsolicited email, and email from downright hostile correspondents.
And I consider "web bugs" and similar tracking methods to be a danger
for something that's supposed to be ONLY "formatted text".


Gordon L. Burditt
Oct 13 '05 #353
Roedy Green wrote in news:ln********************************@4ax.com:
On Tue, 11 Oct 2005 11:45:03 -0400, Mike Meyer <mw*@mired.org> wrote
or quoted :
Jeff Poskanzer, now *he* has a spam problem. He gets a few million
spams a day: <URL: http://www.acme.com/mail_filtering/ >.
It is a bit like termites. If we don't do something drastic to deal
with spam, the ruddy things will eventually make the entire Internet
unusable.

the three keys to me are:

1. flipping to a digital id based email system so that the sender of
any piece of mail can be legally identified and prosecuted.
If every piece of anonymous email disappeared that would go a long
way to clearing up spam. Let those sending ransom notes, death
threats and hate mail use snail mail. As a second best,
correspondents are identified by permission/identity/encryption keys
given to them by their recipients.


The first part seems rather expensive and I'm not sure it would help.
Is spam illegal? I don't see how it can be. I mean, those messages are
annoying, but not that annoying. I get unsolicited email that I
actually want often enough to want to avoid gumming it up in legal
issues.

The second part seems like it would be annoying for the recipients and
would make just sending ordinary email more complicated.
2. flipping to a sender pays system so that the Internet does not
subsidise spam.


This is very promising. Our ISPs should put limits on how much email we
can send. The limits should be rather insane, nothing that any
nonspammer would ever come close to, but low enough to stop spam dead.
If we want to send more than that, we'd better be charged extra.

We could make each mail server responsible for the spam that it sends
out. It seems that currently mail servers are swamped and spending big
money on handling the vast loads of spam that gets pumped into them
from other mail servers, so I'm sure they wouldn't mind having a rule
like: Refuse to allow email to be transported from any server that
spews more than 50% spam. Servers could be audited occasionally to
check if they are spammers.

I don't know exactly how spammers send spam, but a rule like that would
sure stop ISPs from allowing any one person to send a thousand emails a
day.

In fact, if 99% of the email sent is spam, then we can safely assume
that the proper email traffic is 1/100th of what it is now. We just
have to close the valves a little. Mail servers could have an upper
limit on how much they will transfer each day to force restrictions
throughout the system and finally to the individual emailer. I'd rather
have my mail server give me an error message saying that I've sent too
much email every once in a while than have the entire Internet clogged
with spam.

[snipped third key]
Oct 13 '05 #354
On Wednesday 12 October 2005 04:37 pm, Roedy Green wrote:
It is a bit like termites. If we don't do something drastic to deal
with spam, the ruddy things will eventually make the entire Internet
unusable.

the three keys to me are:

1. flipping to a digital id based email system so that the sender of
any piece of mail can be legally identified and prosecuted.
If every piece of anonymous email disappeared that would go a long way
to clearing up spam. Let those sending ransom notes, death threats
and hate mail use snail mail. As a second best, correspondents are
identified by permission/identity/encryption keys given to them by
their recipients.
Well, that certainly won't accomplish much -- not without a world
government, anyway. Much (maybe most) of the spam I receive is
international (from Russia, Japan, Southeast Asia, the Middle East,
Africa, even the Phillipines). Most of it is also already illegal,
so new legislation will certainly make no difference.

The only thing you buy with an authentication system is that you
can filter out the problems at the ISP or on the uploading side,
thus saving a lot of bandwidth. But it would have to be very widely
accepted to actually reduce spamming.

Now, of course, spammers are also hitting web forms and blogs and
other protocols besides e-mail.
2. flipping to a sender pays system so that the Internet does not
subsidise spam.
Then I won't be posting on the Python list anymore, I can assure you.
This would chill a lot of the purposes for which email is ideal.
3. Mail is not transported without prior permission. The receiver can
turn that permission on and off any time he chooses. This is
basically an automated version of what Zaep does where the sender is
not consciously aware of the permission-getting step.


Well, this is already happening at the level of my mail client. I
gather you have something more centralized in mind?

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks http://www.anansispaceworks.com

Oct 13 '05 #355
Gordon Burditt wrote in
news:11*************@corp.supernews.com:
Does the language allow Javascript to open a new window? Does the
language allow Javascript to trigger a function when a window is
closed? I believe the answer to both questions is YES. Then it
is possible to have a page that pops up two windows whenever you
close one.
This was a problem, but modern browsers implement Javascript in such a
way that it requires permission from the user before it will open a new
window.
If it can reveal my email address to any web site, it's a bug. If
it can access or alter my personal files or address book, it's a
bug. If it can generate hits on web sites other than that specified
in the HTML, it's a bug. If it can open sockets, it's a bug.
If it can look at or set cookies stored on my system, it's a bug.
If it can look at or alter the list of previously visited URLs, it's
a bug.


All of those things seem like major problems except the bit about
cookies. What possible harm can reading and setting cookies do? I had
always thought they were carefully and successfully designed to be
harmless. That's not personal information in your cookies. That
information is set by websites for the sole purpose of being read by
websites. Plus, I'm pretty sure that browsers have always allowed us to
disable cookies.
Oct 13 '05 #356
Brendan Guild <do**@spam.me> writes:
This was a problem, but modern browsers implement Javascript in such a
way that it requires permission from the user before it will open a new
window.
Not really true, it's easy to defeat that, and also generally the
pop-up blocker only blocks window.open on load events. JS can usually
still open windows when you mouse over something.
All of those things seem like major problems except the bit about
cookies. What possible harm can reading and setting cookies do? I had
always thought they were carefully and successfully designed to be
harmless. That's not personal information in your cookies. That
information is set by websites for the sole purpose of being read by
websites.


If you have a cookie from site ABC on your system, that shows you
visited site ABC sometime in the past. That is personal information
all by itself, that shouldn't be revealed (including to site ABC)
without your permission. And that doesn't even begin to address web
bugs.

If the JS from site ABC can also read cookies set by unrelated site
XYZ, that's an absolute disaster. It can steal login credentials and
anything else. MSIE actually had a bug of that type a few years ago.
Oct 13 '05 #357
>> Does the language allow Javascript to open a new window? Does the
language allow Javascript to trigger a function when a window is
closed? I believe the answer to both questions is YES. Then it
is possible to have a page that pops up two windows whenever you
close one.
This was a problem, but modern browsers implement Javascript in such a
way that it requires permission from the user before it will open a new
window.


An infinite loop of asking permission is *ALSO* a denial-of-service
attack. And I don't believe that the limitation applies in all
circumstances. This seems to be a feature of the *language*, not
only the implementation.
If it can reveal my email address to any web site, it's a bug. If
it can access or alter my personal files or address book, it's a
bug. If it can generate hits on web sites other than that specified
in the HTML, it's a bug. If it can open sockets, it's a bug.
If it can look at or set cookies stored on my system, it's a bug.
If it can look at or alter the list of previously visited URLs, it's
a bug.


All of those things seem like major problems except the bit about
cookies. What possible harm can reading and setting cookies do? I had


Javascript may be able to set cookies even if they are turned off
by the normal mechanism of setting cookies. Even if that isn't the
case, cookies are supposed to be domain-specific and a cookie from
site A (which might have a session ID for an active login session, or
login credentials for site A) should not be sent to site B. Javascript
can apparently make its own URLs and send anything it gets its hands
on to any site it wants to.

The existence of a cookie from site A shouldn't be revealed at all
to site B (or to Javascript from site B), regardless of what it
contains.
always thought they were carefully and successfully designed to be
harmless. That's not personal information in your cookies. That
Some websites *DO* put personal information in cookies. They don't
all just use randomized session identifiers. Some of them store
login credentials for a site (not just a currently active session,
but permanent login credentials. That might not be "personal" the
same way a SSN or credit card number is, but you could still do
damage with it). A lot of the popularity of Javascript comes from
the ability to steal information from the client computer that
normal HTML does not give access to (e.g. screen/window size, email
address, IP address as seen by the client (because of NAT and
proxies, might not be the same IP as seen by the server), MAC
address, browsing history, Windows serial number, Pentium CPU serial
number, etc.)
information is set by websites for the sole purpose of being read by
websites.
*BY THE WEBSITES THAT SET THEM*, not by all websites. The "domain"
parameter for setting cookies has been in there since the beginning
of the standard for cookies.

If a marketer wants a piece of information, then I don't want him
to have it, even if it's something like "I visited <page X> and
then went to <page Y>" even if there's no identification of who "I"
is.
Plus, I'm pretty sure that browsers have always allowed us to
disable cookies.


I'm not sure that you can disable Javascript from reading cookies
from other sites while allowing Javascript to read cookies from the
site it came from on all browsers.

Gordon L. Burditt
Oct 13 '05 #358
go***********@burditt.org (Gordon Burditt) writes:
I'm not sure that you can disable Javascript from reading cookies
from other sites while allowing Javascript to read cookies from the
site it came from on all browsers.


Javascript is not supposed to be able to read cross-site cookies.
It's bad but it's not THAT bad. There was an MSIE bug that allowed
reading other sites' cookies but it was correctly considered a
horrendous security breach and it was fixed quickly after discovery.
It caused a big fire drill where I was working at the time of the
incident. We had to write a special ActiveX control to protect our
cookie info until the browser patch went out.
Oct 13 '05 #359
In article <7x************@ruckus.brouhaha.com>,
Paul Rubin <http://ph****@NOSPAM.invalid> wrote:
Roedy Green <my******************************@munged.invalid > writes:
Next Mr. Phish had to present his passport etc when he got his Thawte
ID. Now Interpol has a much better handle on putting him in jail.
He can't repudiate his phishing attempt.


Any underage drinker in a college town can tell you a hundred ways to
get sufficient fake ID to get around that.


Most such jurisdictions get very excited, though, if that underage
drinker kills someone while driving drunk. Ofttimes, that gets _real_
police attention, rather than occasional bouncer investigation.

Make each recieved spam be worth a buck to the reciever, and the
spammers/phishers/etc will be facing felony charges. I suspect much of
the spamming would stop.

Some, of course, would continue. Pyramid schemes still get proposed,
but their scope is much smaller.

Scott

--
Scott Ellsworth
sc***@alodar.nospam.com
Java and database consulting for the life sciences
Oct 14 '05 #360
Brendan Guild <do**@spam.me> writes:
2. flipping to a sender pays system so that the Internet does not
subsidise spam.
This is very promising. Our ISPs should put limits on how much email we
can send. The limits should be rather insane, nothing that any
nonspammer would ever come close to, but low enough to stop spam dead.
If we want to send more than that, we'd better be charged extra.

We could make each mail server responsible for the spam that it sends
out. It seems that currently mail servers are swamped and spending big
money on handling the vast loads of spam that gets pumped into them
from other mail servers, so I'm sure they wouldn't mind having a rule
like: Refuse to allow email to be transported from any server that
spews more than 50% spam. Servers could be audited occasionally to
check if they are spammers.


Except that lots of spam doesn't *go* through the ISPs server. It's
running on some Windows zombie, and delivering mail directly to the
recipients server. It'll only go through the ownee's mail server if
the ISP blocks outbound SMTP connections.
I don't know exactly how spammers send spam, but a rule like that would
sure stop ISPs from allowing any one person to send a thousand emails a
day.


And that would work if spammers needed an ISPs permissions to send
email. But they don't.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Oct 14 '05 #361
On Wed, 12 Oct 2005 22:04:14 GMT
Roedy Green <my******************************@munged.invalid > wrote:
On Mon, 10 Oct 2005 00:42:18 +0200, Stefaan A Eeckels
<te***@DELETEMEecc.lu> wrote or quoted :
"I don't understand that attitude. Don't we want email that has
dancing bears, cute little videos, musical tunes, animated waving
hands, sixty fonts, and looks like it's been done with crayolas?
Good grief, man, think like a three year old!"


that excuse could also be used to explain why you have not cracked a
book since high school. The same tools that create dancing bears can
do a UML diagram.


Mine doesn't. Stick figures is as far as it'll go.

Specific document formats can be attached to an email without any
problems. When exact rendering is important, the appropriate format
(e.g. PDF) can be used. Only a fool would want his email program to
render a UML diagram (which is far more than a cute drawing done in
Visio, in case you hadn't noticed).

--
Stefaan
--
As complexity rises, precise statements lose meaning,
and meaningful statements lose precision. -- Lotfi Zadeh
Oct 14 '05 #362
In comp.lang.java.programmer Mike Meyer <mw*@mired.org> wrote or quoted:
Tim Tyler <ti*@tt1lock.org> writes:
In comp.lang.java.programmer Mike Meyer <mw*@mired.org> wrote or quoted:
The technial problems have been solved for over a decade. NeXT shipped
systems that used text/richtext, which has none of the problems that
HTML has. The problems are *social* - you've got to arrange for
people to use mail/news readers that understand a rich text format
that isn't a vector for viruses.


It's not HTML that has problems, it's Microsoft's crappy software.


HTML is a problem on *other* peoples crappy software as well. It
wasn't designed to carry code content, but has been hacked up to do
that.


Are there any examples of HTML email causing security problems - outside
of Microsoft's software?

I can think of one: the JPEG virus. However, that affected practically
any program that could render JPEGs - not just HTML.
Writing virus-free HTML renderers is not hard - but of course
Microsoft can still screw it up.


Sure - just disable all the features that make people want to use HTML
instead of something else.


Not so: you disable Java, Javascript and plugins. You leave the ability
to format, colour and hint documents. This is not /that/ difficult.
Don't blame HTML for viruses - *every* document format Microsoft has
anything to do with becomes a vector for viruses.


Which would mean that every open format that MS has had anything to do
with comes a vector for viruses. Somehow, I'm not buying it.


I exaggerate only slightly.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Oct 14 '05 #363
>>
1. flipping to a digital id based email system so that the sender of
any piece of mail can be legally identified and prosecuted.
If every piece of anonymous email disappeared that would go a long
way to clearing up spam. Let those sending ransom notes, death
threats and hate mail use snail mail. As a second best,
correspondents are identified by permission/identity/encryption keys
given to them by their recipients.

The first part seems rather expensive and I'm not sure it would help.
Is spam illegal? I don't see how it can be. I mean, those messages are
annoying, but not that annoying. I get unsolicited email that I
actually want often enough to want to avoid gumming it up in legal
issues.

Just think about 'protecting the youth'. Everybody can send highly
sexual (to the abnormal) content to everybody. If you would do this
personally on the streets you would surely be prosecuted in most
countries. So, if it isn't illegal, it should be.

[snip]

++ Eike
Oct 14 '05 #364
Tim Tyler <ti*@tt1lock.org> writes:
Are there any examples of HTML email causing security problems - outside
of Microsoft's software?
There was a pretty good one that went something like

Click this link to download latest security patch!
<a href=http://www.mxxxxxx.com.....>Microsoft Security Center</a>

where "mxxxxxx" is "microsoft" with the letter "i" replaced by some
exotic Unicode character that looks exactly like an ascii "i" in normal
screen fonts. The attacker had of course registered that domain and
put evil stuff there.
Not so: you disable Java, Javascript and plugins. You leave the ability
to format, colour and hint documents. This is not /that/ difficult.


Don't forget disabling Unicode.

What happens if you have a <meta redirect=....> tag in the html email
that tries to redirect the browser to some other url?
Oct 14 '05 #365
Not so: you disable Java, Javascript and plugins. You leave the ability
to format, colour and hint documents. This is not /that/ difficult.


Don't forget disabling Unicode.


http://news.netcraft.com/archives/20...g_defense.html

--
Richie Hindle
ri****@entrian.com
Oct 14 '05 #366
Paul Rubin <http://ph****@NOSPAM.invalid> writes:
Not so: you disable Java, Javascript and plugins. You leave the ability
to format, colour and hint documents. This is not /that/ difficult.

Don't forget disabling Unicode.


To kill web bugs, you have to turn off images, and anything else that
automattically loads content from an external server. No inline images
is a pretty large hit on formatting.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Oct 14 '05 #367

"Roedy Green" <my******************************@munged.invalid > wrote in
message news:ln********************************@4ax.com...
On Tue, 11 Oct 2005 11:45:03 -0400, Mike Meyer <mw*@mired.org> wrote
or quoted :
Jeff Poskanzer, now *he* has a spam problem. He gets a few million
spams a day: <URL: http://www.acme.com/mail_filtering/ >.
It is a bit like termites. If we don't do something drastic to deal
with spam, the ruddy things will eventually make the entire Internet
unusable.

the three keys to me are:

1. flipping to a digital id based email system so that the sender of
any piece of mail can be legally identified and prosecuted.
If every piece of anonymous email disappeared that would go a long way
to clearing up spam. Let those sending ransom notes, death threats
and hate mail use snail mail. As a second best, correspondents are
identified by permission/identity/encryption keys given to them by
their recipients.


Too complicated.

2. flipping to a sender pays system so that the Internet does not
subsidise spam.
This would turn cost of sending mail to ordinary people.
Spammers pay for bandwith as much as receivers (except in
case when they hijack server).

3. Mail is not transported without prior permission. The receiver can
turn that permission on and off any time he chooses. This is
basically an automated version of what Zaep does where the sender is
not consciously aware of the permission-getting step.


That is the solution.
rcpt from:<sp*****@spam.org>
rcpt to:vi****@victims.org
not authorized

Then simply users have to maintain list of domains/users that can send mail
which need just one more smtp command.
mail from:<sp*****@spam.org>
auth req:<vi****@victims.org>
ok
auth req:<vi****@victims.org>
request already in queue
rcpt to:<vi****@victims.org>
not authorized

user authorization:
helo victims.org
ok
user:vi****@victims.org
ok
password:victim
ok
auth list req
....
....
....
auth add:<spammer@slam,org>
error no such user at slam org
auth add:<spammer@spam,org>
ok
auth add:<*@*>
ok
auth remove:<*@*>
ok
auth add:<*@friends.org>
ok
quit

and there it is, spam free solution.
User can maintain two email addresses one for general public
and one spam free. Of course smtp should be really extended
to support user authorization.

Greetings, Bane.
Oct 15 '05 #368
On Tue, 04 Oct 2005 17:14:45 GMT, Roedy Green <my******************************@munged.invalid > wrote:
On Tue, 23 Aug 2005 08:32:09 -0500, l v <lv@aol.com> wrote or quoted :
I think e-mail should be text only.
I think that is a useful base standard, which allows easy creation of
ad-hoc tools to search and extract data from your archives, etc.
I disagree. Your problem is spam, not HTML. Spam is associated with
HTML and people have in Pavlovian fashion come to hate HTML.

But HTML is not the problem! Right, it's what the HTML-interpreting engines might do that is
the problem.
That is like hating all choirs because televangelists use them.

HTML allows properly aligned table, diagrams, images, use of
colour/fonts to encode speakers. emphasis, hyperlinks. All good stuff, but I don't like worrying about side effects when I read
email.
I try to explain Java each day both on my website on the plaintext
only newsgroups. It is so much easier to get my point across in HTML. How about pdf?

Program listings are much more readable on my website.

IMO FOSS pdf could provide all the layout benefits while
avoiding (allowing for bugs) all the downsides of X/HTML in emails.

Regards,
Bengt Richter
Oct 15 '05 #369
bo**@oz.net (Bengt Richter) wrote:
On Tue, 04 Oct 2005 17:14:45 GMT, Roedy Green
<my******************************@munged.invalid > wrote:
On Tue, 23 Aug 2005 08:32:09 -0500, l v <lv@aol.com> wrote or quoted :
I think e-mail should be text only. I think that is a useful base standard, which allows easy creation of
ad-hoc tools to search and extract data from your archives, etc.

I disagree. Your problem is spam, not HTML. Spam is associated with
HTML and people have in Pavlovian fashion come to hate HTML.

But HTML is not the problem! Right, it's what the HTML-interpreting engines might do that is
the problem.


You mean the same problem as for example using a very long header in
your email to cause a buffer overflow? That is possible with plain
ASCII, and has been done.
That is like hating all choirs because televangelists use them.

HTML allows properly aligned table, diagrams, images, use of
colour/fonts to encode speakers. emphasis, hyperlinks.

All good stuff, but I don't like worrying about side effects when I
read email.


Then you should ask people to print it out, and use snail mail. Exploits
in email programs are not happening since HTML was added to them.
I try to explain Java each day both on my website on the plaintext
only newsgroups. It is so much easier to get my point across in HTML. How about pdf?


Ah, and that's exploit free?
Program listings are much more readable on my website.

IMO FOSS pdf could provide all the layout benefits while
avoiding (allowing for bugs) all the downsides of X/HTML in emails.


Amazing, so one data format that's open is better compared to another
open data format based on what?

--
John Small Perl scripts: http://johnbokma.com/perl/
Perl programmer available: http://castleamber.com/
I ploink googlegroups.com :-)

Oct 16 '05 #370
>>>But HTML is not the problem!
Right, it's what the HTML-interpreting engines might do that is
the problem.


You mean the same problem as for example using a very long header in
your email to cause a buffer overflow? That is possible with plain
ASCII, and has been done.


Before worrying about the possible bugs in the implementations,
worry about security issues present in the *DESIGN*. Email ought
to be usable to carry out a conversation *SAFELY* with some person out
to get you. Thus features like this are dangerous (in the *design*,
not because they *might* hide a buffer-overflow exploit):

- Hyperlinks to anything *outside* the email in which the link
resides ("web bugs").
- Javascript.
- Any ability to automatically generate hits on sender-specified
servers when the email is read.
- Any kind of return-receipt mechanism that doesn't require initiation
by the recipient.
- Any kind of return-receipt mechanism that indicates that the
message got past the spam filter.
That is like hating all choirs because televangelists use them.

HTML allows properly aligned table, diagrams, images, use of
colour/fonts to encode speakers. emphasis, hyperlinks.
The trouble is, it allows way too much dangerous stuff.
All good stuff, but I don't like worrying about side effects when I
read email.


Then you should ask people to print it out, and use snail mail. Exploits
in email programs are not happening since HTML was added to them.


Yes, they are. Why do you think people put "web bugs" in email?
Because they work.
I try to explain Java each day both on my website on the plaintext
only newsgroups. It is so much easier to get my point across in HTML.

Gordon L. Burditt
Oct 16 '05 #371
go***********@burditt.org (Gordon Burditt) wrote:
But HTML is not the problem!
Right, it's what the HTML-interpreting engines might do that is
the problem.
You mean the same problem as for example using a very long header in
your email to cause a buffer overflow? That is possible with plain
ASCII, and has been done.


Before worrying about the possible bugs in the implementations,
worry about security issues present in the *DESIGN*.


You mean like email travels like plain text over the Internet?
Email ought
to be usable to carry out a conversation *SAFELY* with some person out
to get you. Thus features like this are dangerous (in the *design*,
not because they *might* hide a buffer-overflow exploit):

- Hyperlinks to anything *outside* the email in which the link
resides ("web bugs").
Same holds for a link in plain ASCII
- Javascript.
Is not HTML
That is like hating all choirs because televangelists use them.

HTML allows properly aligned table, diagrams, images, use of
colour/fonts to encode speakers. emphasis, hyperlinks.
The trouble is, it allows way too much dangerous stuff.


Same with attachements, shall we remove those too?
All good stuff, but I don't like worrying about side effects when I
read email.


Then you should ask people to print it out, and use snail mail.
Exploits in email programs are not happening since HTML was added to
them.


Yes, they are.


No, they are not. Buffer overruns with plain ASCII text have happened in
the past. Dangerous attachements have been sent before HTML was
available in email.
Why do you think people put "web bugs" in email?
Because they work.


Same with attachements...

--
John Small Perl scripts: http://johnbokma.com/perl/
Perl programmer available: http://castleamber.com/
I ploink googlegroups.com :-)

Oct 16 '05 #372
On Sat, 15 Oct 2005 23:24:21 GMT, bo**@oz.net (Bengt Richter) wrote or
quoted :
I try to explain Java each day both on my website on the plaintext
only newsgroups. It is so much easier to get my point across in HTML.

How about pdf?


End users HATE PDF. Why?

It takes so long for the reader to load.

It is so slow on older machines to render and scroll.

My complaint with it is it is Adobe proprietary. This make the tools
very expensive.

I like PDF because:

1. documents have to be prepared before posting. This means you don't
have malformed syntax in them.

2. You can reasonably quickly turn computer printouts or paper
documents into web content.

3. You don't have to guess what the end user will see.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
Oct 16 '05 #373
Roedy Green <my******************************@munged.invalid > writes:
End users HATE PDF. Why?

It takes so long for the reader to load.


xpdf comes up almost instantly here. Maybe end users should
consider finding a better PDF reader.
--
"Your correction is 100% correct and 0% helpful. Well done!"
--Richard Heathfield
Oct 16 '05 #374
On 16 Oct 2005 00:31:38 GMT, John Bokma <jo**@castleamber.com> wrote:
bo**@oz.net (Bengt Richter) wrote:
On Tue, 04 Oct 2005 17:14:45 GMT, Roedy Green
<my******************************@munged.invalid > wrote:
On Tue, 23 Aug 2005 08:32:09 -0500, l v <lv@aol.com> wrote or quoted :

I think e-mail should be text only. I think that is a useful base standard, which allows easy creation of
ad-hoc tools to search and extract data from your archives, etc.

I disagree. Your problem is spam, not HTML. Spam is associated with
HTML and people have in Pavlovian fashion come to hate HTML.

But HTML is not the problem!

Right, it's what the HTML-interpreting engines might do that is
the problem.


You mean the same problem as for example using a very long header in
your email to cause a buffer overflow? That is possible with plain
ASCII, and has been done.

Are you trolling? No, I don't mean the same problem.
What an HTML interpreter does by _design_ is not in the same category
as an implementation error enabling a root exploit.
That is like hating all choirs because televangelists use them.

HTML allows properly aligned table, diagrams, images, use of
colour/fonts to encode speakers. emphasis, hyperlinks. All good stuff, but I don't like worrying about side effects when I
read email.


Then you should ask people to print it out, and use snail mail. Exploits

_I_ should, because _you_ can't think of a better solution?
Always happy to get useful advice, though ;-)
in email programs are not happening since HTML was added to them.
You mean they didn't start happening, presumably. But I'm not talking about exploits,
I'm talking about what HTML is designed to do, which is to describe a presentation
composed of elements which in general requires retrieving many elements separately
as the indirect references (links) are interpreted and the data is requested from
the indicated servers -- all at HTML interpretation-time, whatever client engine is
doing that for browser or email reader etc.

Don't get me wrong, I said "all good stuff," as far as control of presentation
is concerned. And I would be happy to have nice graphic email if I could get it
as a self-contained file from my ISP's mail server, and I had a presentation
engine involved that I knew was guaranteed to stick to presentation work without
communicating over the web or doing anything else without my knowledge.

I don't see any technical obstacle to that, but HTML is not designed to be
the solution to that. IMO pdf comes close. I recognize that a pdf interpreter
can also have exploitable implementation errors, just like an ascii email client,
but that is not what I am talking about.

I prefilter email into plain and X/HTML-containing mailboxes, and I don't open
HTML email from unknown sources, though if I am really curious I will drag and
drop the email into a "probtrash" mailbox and use a python script that extracts the
text or other info as text in a console window. All the ones purportedly from ebay and amazon
and paypal have been phishing attempts which would look pretty convincing if displayed
by normal X/HTML interpretation. If my ISP had a better filter or I imporved mine,
I wouldn't see that, but in my normal ascii email boxes I don't have to worry about that,
I just have to resist the social engineering of the offers from Nigeria etc. ;-)
I try to explain Java each day both on my website on the plaintext
only newsgroups. It is so much easier to get my point across in HTML.
How about pdf?


Ah, and that's exploit free?

That's not the issue. All programs can have the kind of exploit possibilities
that you are talking about. A program with the single purpose of interpreting
a page description and presenting it graphically is easier to eliminate
exploitable vulnerabilities from than a program that involves a lot of additional
stuff.Program listings are much more readable on my website.

IMO FOSS pdf could provide all the layout benefits while
avoiding (allowing for bugs) all the downsides of X/HTML in emails.


Amazing, so one data format that's open is better compared to another
open data format based on what?

I take it you don't understand the difference between pdf and html?

A primary thing is the monitorable data-moving activity that is involved.
A pdf can have links, but they are not followed (not counting what closed
source proprietary softare might risk a PR black eye doing) in the process
of opening and presenting the document to you.

The whole file comes as a single unit normally (though I could see the temptation
to implement automatic font downloads and enable font-bugs like web-bugs based on that,
though in a FOSS implementation, such [mal]features could easily be made optional).

You could say features can be optional re HTML CSS and JS and all the
other automatic web-accessing and other features of HTML, but by the time you
made them all optional and turned them off, you wouldn't see the HTML-author's
intended presentation. That is not the case with pdf. Also, a single pdf file would
be coming from one place. There is not an on-the-fly gathering of elements
that you have to use a special tool to determine for sure where all the
requests to get them went, or to prevent them from going, and having the activity
logged, not to mention what the interpretation of unknown elements might do.

Regards,
Bengt Richter
Oct 16 '05 #375
Roedy Green <my******************************@munged.invalid > writes:
3. You don't have to guess what the end user will see.


If you include the fonts, which makes big documents which slows down
the loading and rendering... I've seen quite a number of PDF that are
ill-rendered or not rendered at all.

--
"You cannot really appreciate Dilbert unless you read it in the
original Klingon"
Oct 16 '05 #376
Roedy Green <my******************************@munged.invalid > writes:
On Sat, 15 Oct 2005 23:24:21 GMT, bo**@oz.net (Bengt Richter) wrote or
quoted :
How about pdf?

My complaint with it is it is Adobe proprietary. This make the tools
very expensive.


No, it isn't. The standard is publicly available, so anyone can write
tools that produce and/or manipulate PDF. Lots of people do. Pretty
much any WP or DP package worth using will generate PDF at out of the
box - and some of those are free.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Oct 16 '05 #377
bo**@oz.net (Bengt Richter) wrote:
On 16 Oct 2005 00:31:38 GMT, John Bokma <jo**@castleamber.com> wrote:
bo**@oz.net (Bengt Richter) wrote:
On Tue, 04 Oct 2005 17:14:45 GMT, Roedy Green
<my******************************@munged.invalid > wrote:

On Tue, 23 Aug 2005 08:32:09 -0500, l v <lv@aol.com> wrote or quoted
:

>I think e-mail should be text only.
I think that is a useful base standard, which allows easy creation
of ad-hoc tools to search and extract data from your archives, etc.

I disagree. Your problem is spam, not HTML. Spam is associated
with HTML and people have in Pavlovian fashion come to hate HTML.

But HTML is not the problem!
Right, it's what the HTML-interpreting engines might do that is
the problem.
You mean the same problem as for example using a very long header in
your email to cause a buffer overflow? That is possible with plain
ASCII, and has been done.

Are you trolling? No, I don't mean the same problem.
What an HTML interpreter does by _design_ is not in the same category
as an implementation error enabling a root exploit.


Ok, what do you think are the bad things in HTML design? (For email that
is). I can name only two:

1 - remote loading of objects
2 - when a user clicks on a link, this can be seen as a confirmation.

The latter is also possible in the email clients I have used when plain
text is used. Ok, you can say that in HTML you can hide somewhat the
destination, e.g. <a href="http://example.com/user-1234">Check out this
</a>.

OTOH, you are not forced not to read the status bar.

[ ... ]
Don't get me wrong, I said "all good stuff," as far as control of
presentation is concerned. And I would be happy to have nice graphic
email if I could get it as a self-contained file from my ISP's mail
server, and I had a presentation engine involved that I knew was
guaranteed to stick to presentation work without communicating over
the web or doing anything else without my knowledge.

I don't see any technical obstacle to that, but HTML is not designed
to be the solution to that.
Of course: I can compose an HTML file which has the graphics embedded in
HTML which works in the client I am using. Another option is to include
the graphics as attachements (this works). I am convinced this also
works for stylesheets and any other object. So in short, it's possible
to get a self-contained email.

[ pdf ]
Ah, and that's exploit free?

That's not the issue. All programs can have the kind of exploit
possibilities that you are talking about. A program with the single
purpose of interpreting a page description and presenting it
graphically is easier to eliminate exploitable vulnerabilities from
than a program that involves a lot of additional stuff.


I thought it was possible to add a remote link to PDF (but I couldn't
make one with OOo -> export pdf). But I am afraid that as soon as PDF is
taking over the role of HTML in email, it will certainly going to
support things you consider harmfull (and are in some occasions, I mean,
I agree that tracking of images in spam is a bad thing).
Program listings are much more readable on my website.
IMO FOSS pdf could provide all the layout benefits while
avoiding (allowing for bugs) all the downsides of X/HTML in emails.


Amazing, so one data format that's open is better compared to another
open data format based on what?

I take it you don't understand the difference between pdf and html?

A primary thing is the monitorable data-moving activity that is
involved. A pdf can have links, but they are not followed (not
counting what closed source proprietary softare might risk a PR black
eye doing) in the process of opening and presenting the document to
you.


And a link in an HTML file is? (Ok, there are so called caching systems
that do this with browsers).
The whole file comes as a single unit normally
As I stated, this is possible with HTML, at least Firefox does support
inline images (data scheme). CSS can already be included in the file
itself.
(though I could see the
temptation to implement automatic font downloads and enable font-bugs
like web-bugs based on that, though in a FOSS implementation, such
[mal]features could easily be made optional).

You could say features can be optional re HTML CSS and JS and all the
other automatic web-accessing and other features of HTML, but by the
time you made them all optional and turned them off, you wouldn't see
the HTML-author's intended presentation. That is not the case with
pdf. Also, a single pdf file would be coming from one place. There is
not an on-the-fly gathering of elements that you have to use a special
tool to determine for sure where all the requests to get them went, or
to prevent them from going, and having the activity logged, not to
mention what the interpretation of unknown elements might do.


If it's not possible to remote link to an image in PDF, I wouldn't be
amazed that if it is replacing HTML in email, such a thing will be
added.

--
John Small Perl scripts: http://johnbokma.com/perl/
Perl programmer available: http://castleamber.com/
I ploink googlegroups.com :-)

Oct 17 '05 #378
In comp.lang.java.programmer Paul Rubin <http://ph****@nospam.invalid> wrote or quoted:
Tim Tyler <ti*@tt1lock.org> writes:

Are there any examples of HTML email causing security problems - outside
of Microsoft's software?


There was a pretty good one that went something like

Click this link to download latest security patch!
<a href=http://www.mxxxxxx.com.....>Microsoft Security Center</a>

where "mxxxxxx" is "microsoft" with the letter "i" replaced by some
exotic Unicode character that looks exactly like an ascii "i" in normal
screen fonts. The attacker had of course registered that domain and
put evil stuff there.


I didn't think unicode domain names existed.

It seems that they are in the pipeline:

``After much debate and many competing proposals, a system called
Internationalizing Domain Names in Applications (IDNA) was adopted as
the chosen standard, and is currently, as of 2005, in the process of
being rolled out.''

- http://en.wikipedia.org/wiki/Interna...d_domain_names

It looks like the security issues are probably going to be dealt
with via technical fixes:

``On February 17, 2005, Mozilla developers announced that they would ship
their next versions of their software with IDN support still enabled,
but showing the punycode URLs instead, thus thwarting any attacks while
still allowing people to access websites on an IDN domain. This is a
change from the earlier plans to disable IDN entirely for the time
being.''

- http://en.wikipedia.org/wiki/Interna...d_domain_names

Anyway, I'm inclined to suggest this is a DNS problem. It would
apply to any format that allowed rendering of domain names using
the unicode character set they are intended to be displayed using.

Even without unicode, the "homograph attack" is still viable, due
to things like the "l"/"I" issue in many fonts - as pointed out on:

http://www.centr.org/docs/2005/02/homographs.html
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Oct 18 '05 #379
In comp.lang.java.programmer Ross Bamford <ro***@roscopeco.remove.co.uk> wrote or quoted:
Roedy, I would just _love_ to see the response from the industry when you
tell them they should dump their whole mail infrastructure, and switch
over to a whole new system (new protocols, new security holes, new
problems start to finish). [...]


That's essentially what the IM folk did.

It seems quite possible that future email systems will evolve out of
existing IM ones.

Essentially, IM can do pretty-much everything email can these days, but
the reverse is not true at all.

IM also seems more evolvable than email is managing to be.

About all email has going for it these days is an open format and a
large existing user base.
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Oct 18 '05 #380
Gordon Burditt <go***********@burditt.org> wrote or quoted:
Before worrying about the possible bugs in the implementations,
worry about security issues present in the *DESIGN*. Email ought
to be usable to carry out a conversation *SAFELY* with some person out
to get you. Thus features like this are dangerous (in the *design*,
not because they *might* hide a buffer-overflow exploit):

- Hyperlinks to anything *outside* the email in which the link
resides ("web bugs").
Acceptable risk, IMO.
- Any ability to automatically generate hits on sender-specified
servers when the email is read.


I hadn't though of that one. As well as use in DDOS attacks, that
can help let spammers know if they have reached a human :-|

Even a link in a plain text email can be used (though with reduced
effectiveness) in such a context :-(
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.
Oct 18 '05 #381
On Tue, 18 Oct 2005 07:40:26 GMT, Tim Tyler <ti*@tt1lock.org> wrote
or quoted :
I didn't think unicode domain names existed.


you can even buy them. See http://mindprod.com/jgloss/domainnames.html

under "Chinese Domain Names".
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
Oct 18 '05 #382
On Tue, 18 Oct 2005 08:12:23 GMT, Tim Tyler <ti*@tt1lock.org> wrote
or quoted :
- Any ability to automatically generate hits on sender-specified
servers when the email is read.


I hadn't though of that one. As well as use in DDOS attacks, that
can help let spammers know if they have reached a human :-|


If you think about it, much as you hate spammers you WANT them to have
that information. If you never read spam, and they know that, they
eventually might stop sending it to you and focus on the nitwits who
read it.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
Oct 18 '05 #383
On Tue, 18 Oct 2005 07:59:47 GMT, Tim Tyler <ti*@tt1lock.org> wrote
or quoted :
Essentially, IM can do pretty-much everything email can these days, but
the reverse is not true at all.


The problem with IM is the various IM schemes don't talk to each
other. You need a client that knows all the IM protocols. But that
seems to be happening with Jabber and Trillian.

You have too much reliance on a central server. You have to trust the
relaying company. I think it is time that nearly all mail was
routinely and transparently end to end encrypted, with the exception
of long enclosures that are explicitly marked not confidential.

You still have spam to a lesser extent and strangers just wanting to
talk.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
Oct 18 '05 #384
Tim Tyler <ti*@tt1lock.org> writes:
In comp.lang.java.programmer Ross Bamford <ro***@roscopeco.remove.co.uk> wrote or quoted:
About all email has going for it these days is an open format and a
large existing user base.


Yeah, and all that Windows has going for it is being on 9X% of the
desktops. Nothing really important at all.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Oct 18 '05 #385
On Wed, 12 Oct 2005 21:50:22 GMT
Roedy Green <my******************************@munged.invalid > wrote:
It is almost like providing ladders and setting out cookies and milk
for the burglars.


Fire escapes at christmas.
Oct 22 '05 #386

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

336
by: Xah Lee | last post by:
Jargons of Info Tech industry (A Love of Jargons) Xah Lee, 2002 Feb People in the computing field like to spur the use of spurious jargons. The less educated they are, the more they like...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shllpp 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.