I used to run the main mail router
for a major Canadian university. Incoming mail to us was accepted, outgoing from us was sent. Through email, except to bitnet and uucp, was not. While total spam volume increased without
bound, the spam volume we had to deal with climbed only rather slowly.
The problem space is harder these days, but these basic steps limited it
substantially. If I were still running
the service, I'd be concentrating on spotting outgoing spam and notifying the sender that they'd been zombied.
If you think you see a pattern here, you're right (;-)).
Canada nominally requires the merchant to tell the credit card company the 4-digit check-number on the card, and replies either "yes" or "no". Adresses are personally identifying information, and are normally only disclosed if a suit is filed, otherwise the credit card company can get in trouble.
Some vendors ask for you address and get the credit card company to confirm it, although strictly speaking they're not supposed to do so.
Alas, this varies from jurisdiction to jurisdiction, as does the enforcement of it (;-))
It's fairly hard to get good margins if you consistently spend your moores-law dollars on lowering the price. So
businesses do that only when spending on performance stops working.
Either they're not checking or the credit card company isn't allowed to disclose the
customer's address without a court order, as my canadian card works fine.
Siemens Sietec used to use the
table of elements: if a manger gives
you a machine to install late on
a Friday, you can then leave a
voicemail for him that says "your
new machine is disprosium, IP
address 66".
After a few hundred tries, he'll
remember how its spelled.
Er, what I said!
"enough data a trained person can catch many lies, [...] but are generally not accepted by courts as evidence. Some people can beat them, others conversely always seem to be lying."
Just to clarify: these are so-called
"voice stress analyzers", not polygraphs.
The latter are capable of producing enough data that a trained person can catch many lies, and are the devices commonly used by police, but are generally not accepted by courts as evidence. Some people can beat them, others conversely always seem to be lying.
Voice stress analyzers measure a
single weak indicator, and are quite capable of both false positives and negatives, irrespective of the expertise of the user. They're also easy to use covertly,
such as over a telephone line. Add that
to inaccuracy and you have a recipe for a disaster.
Do we have a estimate for the corresponding profit to the music industry? If the loass was on the
order of 50%, it would be well within the range a distributor would accept for getting penetration.
Back when 286s were bleeding-edge technology, my employer noticed that
locked or gelded software didn't sell.
They sold their product (a competitor to
Lotus 1-2-3) without any locks, and
found that businesses who borrowed copies
then tended to call us us and but copied.
So we worked with the local high schools and colleges to maximize the "trying".
There's quite an discussion on one of the nerd sites on this
(http://yro.slashdot.org/article.pl?sid=09/01/24/1312203) where
I ran across it.
It strikes me we can best deal with this by addressing companies
that pay for the unwanted calls. Not the companies that do the illegal
acts, but instead the ones who pay them.
They (Canadian) purchasers of the illegal advertisements
deserve a nasty fine. Mind you, that does require extra staffing
for the investigators! An appropriate levels of fines, though, should
nicely cover the cost.
To a degree, the same thing would dry up email spam: if there
was a Canadian do-not-spam list, and substantial fines for paying
someone to disobey it, the number of Canadian spammers would
fall rapidly. Alas, Canada isn't where all the illegal calls
and emails originate, so that might have to wait for a majority
of countries to implement it.
Returning to do-not-call lists, a purely Canadian effort to fine
the paymasters would dry up a lot of the calls, especially the
ones being made from local numbers or for Canadian products.
And one can stop spam by using the
same technique that both Canada and the U.S. use for scams: charge the company that's paying for it.
Mind you, that does require extra staffing for the fraud squad! A
suitable levels of fines applied to
the companies who pay for this dreck should nicely cover it.
McNealy arguably knows the value of open source: the closed-source vampires
have sucked a fair bit of his blood over
the years (;-))
He and his friends started a company based on
4.1.3 BSD, and had to buy 32V licenses
(the "Bell tax")
to be able to resell the OS with his machines. Worse, they had to buy the later
Bell kernel to get scalability, and it took from the era of Solaris 8 to now to get the whole OS freed up from
such cooperative folks as SCO.
Or rewritten where they couldn't free it.
--dave (who worked on some of
the freeing, circa Solaris 8) c-b
Dasco Disk Cleaning Service in Toronto used to restore scratched drives with great reliability, and magnetically zapped ones with occasional success. Reputedly with analog equipment...
Presumably the monitor itself would need to be tricked into thinking the harmless operation was evil, so it would submit it
to peer review on the p2p network.
Then you'd need to trick some other subscribers into agreeing it was evil, and somehow arrange for them to be selected by the system as peers. Then and only then could you get the system to DoS it's users.
One part of this is just the "it was in yesterday's activity log" test. If you
have data from a period leading up to a problem, set-subtract the previous activity from the activity on the day of
the crash to get just the new, unexpected
activity. That's the material you should be looking at.
Numerous companies either breach the policies or work around them.
Tthere was a big flap last year when the parent company of Winners and Home Sense was found to have been capturing all their customer's credit card numbers,
which are supposed to be passed directly the the banks' clearing house without ever being seen by the retailer.
See http://www.cbc.ca/money/story/2007/01/18/winnersbreach.html
I liked that too, but I actually expect
Sun to keep on selling hardware. I was
just on a benchmark for something like four mainframe-sized M9000s and
a dozen or so M5000s, so some folks are happily buying their products.
I'm a performance/capacity guy, so most
of my business comes from big companies who buy Solaris, AIX and HP/UX boxes.
After a few jobs like that, I resolved
never to work for the undermotivated.
If the folks who are interviewing you
aren't actively engaged, you're looking
at a bad employer (;-))
If you're an employer, try asking
interviewees the current open, unsolved
question that your team is struggling with. We've had some amazing new hires when we had to guts to challenge them.
The general answer is to manage the change you suffer, so as to keep it
from getting ahead of you.
You can do this several ways, but the best requires you be the creator of the
interfaces that are to change. If you are, you can make it easy for your customers (and your own team) to change
asynchronously, basically by version-numbering your interfaces.
Paul Stachour has a good talk on this at
multicians.org.
A primitive form of this is freezing
your interfaces: once they're in the
Application Binary Interface (ABI), don't change then until the hardware
changes so much that everyone has to
recompile (e.g., when switching to 64-bit). This is heavily used in operating systems, but not in the
world of programming languages.
Finally, if you're the consumer of
someone else's changes, steal a technique from
the porting/migration community and
automate your changes when your
supplier forces you into them.
One tools, aimed at Vim/Emacs users is
"port", described at
Strength-Reducing the Task of Porting. It only takes about 10
minutes to create a change-database entry and
optionally a sed script, so you can
make a controlled change of all your
sources to match a vendor's newest brainstorm.
Back when I worked for Honeywell, they
has exactly that kind of agreement. A
colleague looked at it and said "So
I have to divest my company to you, then? How much do you plan to pay me for it?".
No, it's called a "firewall" these
days, a term apparently borrowed
from the computer industry.
The province of Alberta wanted
to put one up a few years back, to
keep Canadians out. (;-))
Many moons ago at Siemens Sietec, a colleague did a similar
notification/error popup, but didn't think to make it
go away without your clicking it.
However, the cool thing was what happened if you
right-clicked it or clicked the "more" button:
it displayed a series of messages, starting with
the most meaningful to the user, usually
written by the GUI designer. This was followed
by messages from farther and farther down the
call stack, until you got so something quite
user-unfriendly like "invalid block count at
inode #16538128".
The sequence could be pasted into email by
users if and only if they were inconvenienced
by the thing the message reported.
In effect, the message producer was an exception
mechanism, handling both minor exceptions
to the expected behavior and also more serious
ones, and at each level the handler could and
often would add their interpretation of the problem.
The engineers loved the very precise pointers
to the problem, and users enjoyed knowing that
they could hand the nerds something useful, and
not be grumbled at for reporting a problem
but not knowing the solution(;-))
Slashdot Mirror
I used to run the main mail router for a major Canadian university. Incoming mail to us was accepted, outgoing from us was sent. Through email, except to bitnet and uucp, was not. While total spam volume increased without bound, the spam volume we had to deal with climbed only rather slowly.
The problem space is harder these days, but these basic steps limited it substantially. If I were still running the service, I'd be concentrating on spotting outgoing spam and notifying the sender that they'd been zombied.
If you think you see a pattern here, you're right (;-)).
--dave
Canada nominally requires the merchant to tell the credit card company the 4-digit check-number on the card, and replies either "yes" or "no". Adresses are personally identifying information, and are normally only disclosed if a suit is filed, otherwise the credit card company can get in trouble.
Some vendors ask for you address and get the credit card company to confirm it, although strictly speaking they're not supposed to do so.
Alas, this varies from jurisdiction to jurisdiction, as does the enforcement of it (;-))
--dave
It's fairly hard to get good margins if you consistently spend your moores-law dollars on lowering the price. So businesses do that only when spending on performance stops working.
--dave
Either they're not checking or the credit card company isn't allowed to disclose the customer's address without a court order, as my canadian card works fine.
--dave
Odd, I have a Canadian credit card and itunes still takes my money (;-))
--dave
Siemens Sietec used to use the table of elements: if a manger gives you a machine to install late on a Friday, you can then leave a voicemail for him that says "your new machine is disprosium, IP address 66".
After a few hundred tries, he'll remember how its spelled.
--dave
Er, what I said! "enough data a trained person can catch many lies, [...] but are generally not accepted by courts as evidence. Some people can beat them, others conversely always seem to be lying."
--dave
sorry, s/but/buy/
Just to clarify: these are so-called "voice stress analyzers", not polygraphs. The latter are capable of producing enough data that a trained person can catch many lies, and are the devices commonly used by police, but are generally not accepted by courts as evidence. Some people can beat them, others conversely always seem to be lying.
Voice stress analyzers measure a single weak indicator, and are quite capable of both false positives and negatives, irrespective of the expertise of the user. They're also easy to use covertly, such as over a telephone line. Add that to inaccuracy and you have a recipe for a disaster.
--dave
Do we have a estimate for the corresponding profit to the music industry? If the loass was on the order of 50%, it would be well within the range a distributor would accept for getting penetration.
--dave
--dave
Those folks are already being chased by the existing (underpaid, overworked) fraud squads (;-))
Fining companies only works on real companies trying to use arguably illegal means to flog legal products.
--dave
You may have seen the Globe article about telemarketers using the do-not-call list as a source of people to call, including some explicitly fraudulent calls: http://www.theglobeandmail.com/servlet/story/RTGAM.20090123.wdonotcall23/BNStory/National/home
There's quite an discussion on one of the nerd sites on this (http://yro.slashdot.org/article.pl?sid=09/01/24/1312203) where I ran across it.
It strikes me we can best deal with this by addressing companies that pay for the unwanted calls. Not the companies that do the illegal acts, but instead the ones who pay them.
They (Canadian) purchasers of the illegal advertisements deserve a nasty fine. Mind you, that does require extra staffing for the investigators! An appropriate levels of fines, though, should nicely cover the cost.
To a degree, the same thing would dry up email spam: if there was a Canadian do-not-spam list, and substantial fines for paying someone to disobey it, the number of Canadian spammers would fall rapidly. Alas, Canada isn't where all the illegal calls and emails originate, so that might have to wait for a majority of countries to implement it.
Returning to do-not-call lists, a purely Canadian effort to fine the paymasters would dry up a lot of the calls, especially the ones being made from local numbers or for Canadian products.
--dave
And one can stop spam by using the same technique that both Canada and the U.S. use for scams : charge the company that's paying for it.
Mind you, that does require extra staffing for the fraud squad! A suitable levels of fines applied to the companies who pay for this dreck should nicely cover it.
Hmmn, time to write to my MP!
--dave
McNealy arguably knows the value of open source: the closed-source vampires have sucked a fair bit of his blood over the years (;-))
He and his friends started a company based on 4.1.3 BSD, and had to buy 32V licenses (the "Bell tax") to be able to resell the OS with his machines. Worse, they had to buy the later Bell kernel to get scalability, and it took from the era of Solaris 8 to now to get the whole OS freed up from such cooperative folks as SCO. Or rewritten where they couldn't free it.
--dave (who worked on some of the freeing, circa Solaris 8) c-b
Dasco Disk Cleaning Service in Toronto used to restore scratched drives with great reliability, and magnetically zapped ones with occasional success. Reputedly with analog equipment...
--dave
Presumably the monitor itself would need to be tricked into thinking the harmless operation was evil, so it would submit it to peer review on the p2p network.
Then you'd need to trick some other subscribers into agreeing it was evil, and somehow arrange for them to be selected by the system as peers. Then and only then could you get the system to DoS it's users.
--dave
One part of this is just the "it was in yesterday's activity log" test. If you have data from a period leading up to a problem, set-subtract the previous activity from the activity on the day of the crash to get just the new, unexpected activity. That's the material you should be looking at.
For syslog, this can be implemented with an awk script: there's an example in "Sherlock Holmes on Log Files", at http://datacenterworks.com/stories/antilog.html
--dave
Numerous companies either breach the policies or work around them.
Tthere was a big flap last year when the parent company of Winners and Home Sense was found to have been capturing all their customer's credit card numbers, which are supposed to be passed directly the the banks' clearing house without ever being seen by the retailer. See http://www.cbc.ca/money/story/2007/01/18/winnersbreach.html
Yes, they got stolen (;-))
--dave
I liked that too, but I actually expect Sun to keep on selling hardware. I was just on a benchmark for something like four mainframe-sized M9000s and a dozen or so M5000s, so some folks are happily buying their products.
I'm a performance/capacity guy, so most of my business comes from big companies who buy Solaris, AIX and HP/UX boxes.
--dave
After a few jobs like that, I resolved never to work for the undermotivated.
If the folks who are interviewing you aren't actively engaged, you're looking at a bad employer (;-))
If you're an employer, try asking interviewees the current open, unsolved question that your team is struggling with. We've had some amazing new hires when we had to guts to challenge them.
--dave
The general answer is to manage the change you suffer, so as to keep it from getting ahead of you.
You can do this several ways, but the best requires you be the creator of the interfaces that are to change. If you are, you can make it easy for your customers (and your own team) to change asynchronously, basically by version-numbering your interfaces. Paul Stachour has a good talk on this at multicians.org.
A primitive form of this is freezing your interfaces: once they're in the Application Binary Interface (ABI), don't change then until the hardware changes so much that everyone has to recompile (e.g., when switching to 64-bit). This is heavily used in operating systems, but not in the world of programming languages.
Finally, if you're the consumer of someone else's changes, steal a technique from the porting/migration community and automate your changes when your supplier forces you into them. One tools, aimed at Vim/Emacs users is "port", described at Strength-Reducing the Task of Porting. It only takes about 10 minutes to create a change-database entry and optionally a sed script, so you can make a controlled change of all your sources to match a vendor's newest brainstorm.
--dave
Back when I worked for Honeywell, they has exactly that kind of agreement. A colleague looked at it and said "So I have to divest my company to you, then? How much do you plan to pay me for it?".
--dave
No, it's called a "firewall" these days, a term apparently borrowed from the computer industry. The province of Alberta wanted to put one up a few years back, to keep Canadians out. (;-))
--dave
Many moons ago at Siemens Sietec, a colleague did a similar notification/error popup, but didn't think to make it go away without your clicking it.
However, the cool thing was what happened if you right-clicked it or clicked the "more" button: it displayed a series of messages, starting with the most meaningful to the user, usually written by the GUI designer. This was followed by messages from farther and farther down the call stack, until you got so something quite user-unfriendly like "invalid block count at inode #16538128".
The sequence could be pasted into email by users if and only if they were inconvenienced by the thing the message reported.
In effect, the message producer was an exception mechanism, handling both minor exceptions to the expected behavior and also more serious ones, and at each level the handler could and often would add their interpretation of the problem.
The engineers loved the very precise pointers to the problem, and users enjoyed knowing that they could hand the nerds something useful, and not be grumbled at for reporting a problem but not knowing the solution(;-))
--dave