Jargons of Info Tech industry

[Mike Meyer]

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

 

[Gordon Burditt]

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.

Gordon L. Burditt

 

[Brendan Guild]

Roedy Green wrote in

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]

 

[Brendan Guild]

Gordon Burditt wrote in

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.

 

[Paul Rubin]

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.

 

[Gordon Burditt]

Does the language allow Javascript to open a new window? Does the

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.

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

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

 

[Bent C Dalager]

The first part seems rather expensive and I'm not sure it would help.
Is spam illegal?

Spam is fast becoming illegal in quite a few countries, so, yes.

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.

There are two basic reasons why this isn't a good idea.

First, it won't work. The spam will be sent by bot-nets and the
quantities would still aggregate to a serious problem.

Second, people will work around the limitation. A fair number of
people want to belong to mailing lists, and they don't want to be
taxed just for sending mail to big lists, nor do they want to be told
they can't join a list just because their membership would be too
expensive for the list owner to support. A parallel mail system would
soon arise, possibly SMTP-based but with mail daemons on home
computers rather than on ISP ones. Alternatively, it might be HTTP
based. Whatever the case, it would soon exhibit the same spam problems
that we see in the current system.

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.

This solution isn't too different from the various black lists that
have been in use on many sites for a number of years now. The strategy
is effectively defeated by the use of bot-nets.

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.

The problem is that some users actually need to send 1,000 emails in a
day. There needs to be a way to cater to these users as many of them
are among the most useful people on the net.

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.

It seems likely that for this to effectively curb bot-nets, the limits
will need to be set so low as to inconvenience even normal mail users.
I don't see commercial ISPs doing this any time soon.

Cheers
Bent D

 

[Paul Rubin]

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.

 

[Stefaan A Eeckels]

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).

 

[Mike Meyer]

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

 

[Scott Ellsworth]

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

 

[Brendan Guild]

Bent C Dalager wrote in [snip]

Second, people will work around the limitation. A fair number of
people want to belong to mailing lists, and they don't want to be
taxed just for sending mail to big lists, nor do they want to be told
they can't join a list just because their membership would be too
expensive for the list owner to support. A parallel mail system would
soon arise, possibly SMTP-based but with mail daemons on home
computers rather than on ISP ones. Alternatively, it might be HTTP
based. Whatever the case, it would soon exhibit the same spam
problems that we see in the current system.

Given two parallel mail systems, one with spam and one without, I know
which one I would choose. Perhaps if the new parallel mail system was
used only for mailing lists the spammers would ignore it, or else it
could become swamped with spam while the normal email survives. Either
way, it seems like an improvement.

The problem is that some users actually need to send 1,000 emails in
a day. There needs to be a way to cater to these users as many of
them are among the most useful people on the net.

Who are these people? Surely those 1,000 emails are not all distinct.
Why not use a website?

It seems likely that for this to effectively curb bot-nets, the
limits will need to be set so low as to inconvenience even normal
mail users. I don't see commercial ISPs doing this any time soon.

Bot-nets are a scary things! I can't imagine how someone could be
misusing my machine like that, but I suppose it must be possible. I was
assuming that many/most spammers weren't actually doing anything that
seems so illegal as that.

In that case, we have to put an end to botnet emailing. One way to do
that would be for each ISP to have a firewall that blocked all SMTP
messages unless they were sent securely with a password protection.
That way only you could ever send email from your own computer. Plus,
the ISP would email you with the contents of any unencrypted email that
your machine tries to send, so the only spam you get will be the spam
you send.

I was thinking more of crazy mass-emailers. I don't know what they are
thinking when they do what they do, but I wish I could tell them that I
don't even glance at the vast piles of spam I get. They really should
take me off their lists.

 

[Tim Tyler]

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.

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.

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.

 

[Tim Tyler]

Yes. But erasing hard drives is stupid and pointless, and viruses written
by digital vandals do exactly that.

Rarely. In fact, I haven't /ever/ seen a virus do that. Viruses that
format their owner's hard drives typically do so at the expense of
their own reproductive success - consequently such viruses are not
common.

Viruses *these days* are mostly written by criminals looking to make
money, not criminals looking to do the equivalent of smashing your windows
and running away.

Suppose I wanted to gather industrial espionage about, oh, say Roedy
Green. If my virus could impersonate him, I could tell everyone in sight
that his email has changed to (e-mail address removed) (or wherever). I would
harvest his email, forward it on to him so he doesn't even notice, and
sell the data to the highest bidder. Or use it for blackmail. Or sell it
to companies who want to buy demographic and purchasing information ("I
see he has bought seven books from Amazon this month...").

If you have a virus on Roedy's machine, you can send out change-of-address
advisory's that appear to come from him *today*.

You probably don't have to bother doing that, though - if your aim is to
monitor his email, you can simply have your virus send it to you - that
is silent and reduces the chance of your virus being discovered.

Roedy's automated change-of-address advisory scheme would make negligible
difference in this general area.

 

[Eike Preuss]

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

 

[Bent C Dalager]

Given two parallel mail systems, one with spam and one without, I know
which one I would choose.

You are assuming that this would be the only meaningful difference
between the two systems. I doubt that this would be the case.

Who are these people? Surely those 1,000 emails are not all distinct.

Mailing list managers. People who play mail-based games. Very socially
active people.

Why not use a website?

Web sites aren't mail delivery systems.

Bot-nets are a scary things! I can't imagine how someone could be
misusing my machine like that, but I suppose it must be possible. I was
assuming that many/most spammers weren't actually doing anything that
seems so illegal as that.

They will use whatever tool they need to. They used to use open mail
servers. As those got closed down, they inevitably moved to other
options, including bot-nets. The more complicated the other
alternatives, the more will they be using bot-nets.

Illegal or not doesn't matter to these people. They are already
operating in an ethical gray zone, and few of them would care if they
had to step over the line every now and then in order to maintain
their revenue stream.

In that case, we have to put an end to botnet emailing. One way to do
that would be for each ISP to have a firewall that blocked all SMTP
messages unless they were sent securely with a password protection.
That way only you could ever send email from your own computer. Plus,
the ISP would email you with the contents of any unencrypted email that
your machine tries to send, so the only spam you get will be the spam
you send.

Bot-net software would have very little trouble obtaining the
password. It's already installed on your computer with administrator
privileges so it can easily snoop both your password and your
encryption key.

I was thinking more of crazy mass-emailers. I don't know what they are
thinking when they do what they do, but I wish I could tell them that I
don't even glance at the vast piles of spam I get. They really should
take me off their lists.

Single-source spam is trivially defeated by blacklisting. This is a
problem only if you desire it to be.

Cheers
Bent D

 

[Paul Rubin]

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?

 

[Mike Meyer]

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

 

[Branimir Maksimovic]

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:<[email protected]>
rcpt to:[email protected]
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:<[email protected]>
auth req:<[email protected]>
ok
auth req:<[email protected]>
request already in queue
rcpt to:<[email protected]>
not authorized

user authorization:
helo victims.org
ok
user:[email protected]
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.

 

[Bengt Richter]

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