Anonymous Coward wrote on Saturday December 04, @08:50AM (#10996046)
I propose Slashdot's editors agree to "accidentally" incorrectly rewrite one submitted link per week to point to the site of a major spammer.
It will have exactly the same effect as the Lycos DDOS screensaver...
Sadly, no, it wouldn't have the same effect. Links anywhere are subject to redirection by meta refresh tag and by DNS modification to point Web traffic to any other host on the planet.
Something like this has to be done the way Lycos was doing it, with human qualification of the target sites, retrievals by mechanisms less intelligent than browsers, and with monitoring of host/IP settings to catch DNS redirection.
Of course the open source community could come up with a substitute potentially even better than the Lycos tool...
Design for a Free Open Source Spamsite Hammer
The key to the legitimacy of a user doing this is that SPAM emails contain explicit invitations to visit the spamvertized Websites. There can be no implied or inferred limit to the browsing an invitee does on a publicly accessible Website, at least not within the range of what a human could or might do, even an obsessive-compulsive human who can't resist clicking on all the links he or she finds on the site that extended the invitation. Nor can there be any limit to the use of automated tools, as those have legitimate roles in off-line browsing of downloaded Websites. To the end of making the tool's HTTP requests indistinguishable from regular browser requests the retrieval tool could intelligently construct "Referer" headers and use a very common "User-agent" header, and request actual documents as a browser would instead of formulating invalid requests as the Lycos screen saver did. This would simply make it very difficult for a spamsite operator to figure out who is who and who is doing what.
The short version of the design spec:
A background distributed-computing type of app that uses only otherwise unused CPU time to hammer targeted Websites,
that uses low-level TCP to request objects from servers on its target list,
that does forward DNS lookups either every time or periodically to verify that a target's DNS has not been repointed to a possibly innocent third party,
that has a companion email plug-in that allows the user to flag an email as SPAM,
that has a companion site qualifier that parses the often obfuscated URL(s) from the selected email,
that retrieves the Web page from each spamvertized URL for review and confirmation by the user,
that offers the user the option to add the URL to his personal target list, and
that logs the SPAM email, the de-obfuscated URL, any redirection URLS along the way, and the Web page so retrieved.
The email-based target list builder should, if the final retrieved web page is determined by the user to be spammy, add to the target list any and all redirection sites along the way. Often the SPAM email contains the URL of a middleman redirector and it's not unusual for the second site to also be a redirector.
Once the user has confirmed that the target is a spamvertized Website, all redirectors leading there are added to the target list and the host/domain(s) and IP address(es) are logged.
The background process works from the target list, perhaps at a rate that is somewhat configurable by the user.
Using low-level TCP to retrieve objects should make it possible to avoid malicious HTTP redirection to innocent sites. Qualification of a target site and all normal spam response redirector sites leading to it is accomplished merely by the go/no-go determination by the user of the spamminess of the ultimate Web page retrieved.
...has anyone who's been executed by the US govt ever been declared innocent after the fact?
Rarely, if ever. That's because one of the ways the just-us system protects itself is to use any available excuse to avoid reexamining done deals. The "donest" deal of all is a convict who has already been executed. The gummint usually argues that if the guy is dead, it's moot whether or not he was really, factually guilty. So it shouldn't be a surprise that the system tries to bury its mistakes rather than own up to them.
Look for references to Randall Adams, Adams vs Texas, and The Thin Blue Line. It's a stunning case of prosecutorial misconduct in which the prosecutor apparently got away scot free after ruining a man's life and very nearly getting him executed.
The prosecutor had a choice: he could prosecute the perp he knew did the crime, but with no witnesses, and probably lose, or he could prosecute the innocent guy using the perp's purjured testimony and get a conviction.
If we were going to have a death penalty for anything, it should be only for that kind of abuse of power.
There is no point at all in arguing any of the traditional arguments for or against capital punishment as long as the gummint can't be trusted to get it right and always convict only the truly guilty party. No other basis for supporting or opposing capital punishment has any meaning unless and until this glaring problem is resolved.
Maybe not HTTP redirection, but it is vulnerable to DNS redirection. If the DNS record for www.moretgage.info is changed then it will DoS whoever it points to. Lycos could be doing it by IP, but if they are then the spammer just needs to get a new IP for their address, something they are used to doing.
Sorry, no. All that's required to detect DNS modification is to do a forward DNS lookup periodically. If the client does it as a browser would on each new access, it could detect an IP change, remove the target from its list, and report to the Lycos server that the IP of such-and-such hostname had changed. The server could put the item on a short list for immediate reexamination by humans. If the new IP is also a spamvertized web server, the host could go back onto the target list. Otherwise it could be examined periodically by a robot and flagged again for reexamination when either the IP or the content changes again.
So, so simple. And the beauty of having the client detect the IP change is that clients would continue to hammer the original until the DNS change propagates to them.
Easy fix, point the domain to lycos servers, have them DoS themselves.
Only if we presume that the Lycos people who crafted this have no brains. More likely, the outline of what they do looks something like this:
Get URL of spamvertized site
Review manually, confirm spamminess
Log IP address, add to target list
Monitor DNS for any change in IP
If IP changes, remove from target list, add to short list to monitor URL's site for return to spamminess
If and when it resolves to a spammy site again, add URL to target list again
Most of the naysayers have not taken more than a superficial look at what Lycos did, and too many are relying on the uninformed opinions of other posters who have also failed to look closely at it or to think it through.
The Lycos screen saver is dynamic, not static. It can be given new instructions virtually in real time, including instructions to target nothing or to go into its present dimmed "Stay Tuned" mode.
Isn't it rather easy for Lycos to simply block traffic redirected from a handful of (spam redirecting) sites?
Unnecessary. The Lycos tool is not a browser, nor does it request any existing document. Metatag redirection never comes into play for both these reasons. The Lycos tool formulates a GET or POST request that cannot be satisfied, stimulating an error response from the target web server. Even if the target were to attempt redirection in the error response the Lycos tool would merely receive the response, not act on it.
One of the spam sites www.moretgage.info has changed it so it has a meta refresh tag to redirect traffic to lycos.
Interesting, but I don't think the screensaver actually renders and executes HTML code, it just does a GET, meaning the redirect would do nothing, right?
Right. Pretty much all of the recent news stories about this got it 100% wrong. In fact, from a sample HTTP request someone posted in one of these Lycos threads here, the screen saver doesn't even request a valid file. It generates a GET or POST intentionally formulated to generate a web server error response. Very clever. Not so clever are all the whiners and speculators who erroneously presume things like the imagened vulnerability of the Lycos tool to HTTP redirection.
aren't a lot of these spam sites located on hijacked PCs on DSL lines?
I think you're thinking of the senders of spam. The spamvertized ecommerce websites generally have to have a bit more stability than hijacked machines, and have to be pointed to by DNS, which would provide a link from the domain owner to the illegally hijacked machine, etc.
How about a slashdot feature 'spammer of the day' link at the top of the homepage. When you log in you click the link a few times - a bit like the hungersite, only vindictive?
Sorry, no. This kind of punishment can't be done effectively from browsers for several reasons.
First, host/domain addresses can easily be jiggered by the spamsite operator to point to innocent IP addresses. One of the Lycos targets, "go-medz.com", did exactly this last night. They updated their DNS to point to an open source mirror site for a few hours in the apparent hope of causing collateral damage that might be blamed on Lycos. I'm pretty sure Lycos is wise to such stunts and anticipated them in the design of the anti-spam screen saver and its supporting servers.
Second, a spamsite operator could easily modify the site's front page to contain links to objects such as graphics located on innocent servers elsewhere. SpamVampire is particularly vulnerable to being deceived in this manner. The Lycos screen saver is not, since it does not act in the manner of a browser and in fact doesn't even retrieve any actual documents from the target sites much less act on any object links in documents.
From information posted here earlier by someone else, the Lycos screen saver appears to formulate an HTTP request guaranteed not to be understood by the target server, eliciting an error response.
I think it's a safe bet that Lycos anticipated the DNS trick and logs the IP address of each target site at the time their spamminess is verified by a human and then periodically checks by DNS request to take the site off the target list if the IP address changes in DNS. If I were designing this the repointed site would then go onto a short list for quick manual reverification and as long as it remained pointed at a non-spammy site, DNS would be monitored closely to catch it reverting back to its business IP address.
go-medz.com apparently couldn't resist going back to their internet pharmacy business server, because their kind of spiteful action resulted in 100% loss of business traffic to their site. It only lasted a few hours.
Some of the target sites did apparently change IP addresses to other of their hosting facilities. This is an expected reaction that could be interpreted to mean that they wore out their welcome at the original hosting sites or upstream ISP feeds. It reveals, though, that the spamsites are resilient and not easy pushovers.
That spammer who was recently convicted in Virginia was spending $50,000/month on Internet connectivity with which to push out his millions of emails a day and presumably receive the website visits from those stupid enough to respond.
The screen saver isn't a tool that blindly does its work. It communicates with the server to report and to receive new targets. For a time, leading up to about 25 hours ago, the screen savers were not given any targets at all, either because Lycos had maxed out the targets of the day or maybe because the Lycos folks were implementing a workaround for an unanticipated spamsite evasion trick. Around midnight US CST the server started handing out targets again, slowly at first, ramping up to the normal levels of recent days. Dec 1 was actually the inauguration of the Lycos makelovenotspam program, so we can guess that the earlier days may have been pre-release testing and validation of the concept.
I have no argument with anything you wrote. A huge ice storm is not a common event, though, and general experience throughout my lifetime has shown that ordinary phones continue to work in almost all the situations we encounter unless the lines are physically down or we're unlucky enough to have taken enough of a lightning hit to fry the line or the phone or the CO port.
My first point was simply the quibble that what powers the old-fashioned phone isn't a "trickle," it's the primary power intentionally provided by design and implementation on the phone line. Decades ago when I used to play with such things, my phone line had, if I recall, an open circuit voltage of either 48VDC or 120VDC. Picking up the phone dropped the voltage across the phone to just about 6VDC with "talk current" passing through it. The ring signal was 120V 20 cycle AC, very easy to feel if holding the wires when it came through. Yes, extended power outages will strain the telco's ability to keep the phone system powered, but extended outages are the exception, not the rule, even in a shitty power area such as mine.
My other point was that not all that many people use ordinary, non-electronic phones anymore, and variants such as ISDN and broadband-based VoIP have been multiplying in the last few decades. All the electronic stuff breaks the model of an always-working phone, but power, at least, can be assured for a long time with even a modest UPS.
All my computer and communication gear is on various UPS units. The cable modem is on its own UPS, the DSL is on its own UPS and the VoIP and phone are on their own UPS. My CPAP machine has its own UPS because more than once in the past I had the unpleasant experience of waking with no air to breathe when power went out at night. All told I have about 10KVA of UPS on line at all times and another 10KVA rotated out of service or awaiting battery replacement. The smallest one, that runs my VoIP and phone, would suffice for the averge non-geek consumer using VoIP.
Yeah, the only problem is that if his number is still an NYC number, he is making all those people he meets in Texas pay long distance to call him locally!
First, that's not the point. The point is that he was able to move 1700 miles without changing anything about how people reach him by phone. That's 40 years worth of people who have his number in their minds, their phones and their address books.
Second, if and when he wants to have a "local" Texas number all he has to do is surf to the Vonage page and order one. $4.99 + $1.50 federal tax per month. He can have as many as he likes... his original one in NYC, one in Texas, maybe one in Chicago to allow a few friends there to reach him by local call...
Third, so far, at least, he originates all the calls to local people, and his LD is unlimited throughout the U.S. and Canada. I have Vonage, too, with a local Texas number, and on occasion he has called the living room at my Texas number from the guest bedroom and his NYC number. That's nominally LD but since we both have unlimited LD it's a no-brainer for either to call the other within the same house. That was very weird the first couple of times, just as it was when he first arrived and we hooked up his Vonage box to my network and I dialled his NYC number. I know all about the technology but I just had to experience calling NYC and having his phone in the next room ring.
Maybe you can, maybe you can't. I just tried it on mine and there was no identifiable sound. You certainly can't hear the higher-than-audible DSL signal directly, although maybe you could hear harmonics or artifacts of it. Telco techs have told me that sometimes you can hear it. Maybe it also depends on the particular signalling flavor being used, and/or on the type of test set being plugged into the line.
In any case, the possible noise of DSL is not why filters are used. It's the other way around: Filters are used to prevent the low-frequency phones from killing the DSL signal. Plug an unfiltered phone into your DSL line and watch the green light turn red. Perhaps more accurately, filters are used to prevent the high and low frequency channels and components from interfering with each other.
For a nice, understandable writeup on DSL technology, see: xDSL Technology
if there is a landline to your house, and a plug, you can pick that up and dial 911 on it, and it will connect, its a FCC regulation, I believe.
I doubt it's a requirement. "Disconnected" phone lines in this area always go completely dead. There's no way to dial 911 without a dial tone. Also, in most places where I have lived, unused phone circuits sooner or later get segments stolen by phone techs for use in new subscriber circuits. Almost all subscriber circuits are actually collections of shorter circuits from junction box to junction box, and the tradition has long been that each hop of an unused circuit is up for grabs when a tech is installing new stuff and needs a path from one box to another.
There is even a problem with DSL circuits that don't have underlying POTS because the tech can't find current on the line and can't hear dial tone, so it looks like a dead circuit. This results in circuit segments being taken out of active DSL lines for use in new circuits being established.
Maybe this isn't true everywhere, but whenever I've moved into a new place, there is a phone line already attached. You pick up, and it's not a dead line - a cheery voice will tell you how to order service. You can't make any calls, other than to their order line, or 911.
Unfortunately Southwestern Bell Telephone, now SBC, has never been that intelligent in this area. I've allowed the land line service to lapse a number of times in the last decade and a half and it always struck me as rather brainless that the phone line went completely dead, making it impossible for the phone company to call me to sell me on restoring service, not to mention the altruistic (but, ahem, fully funded) ideal of maintaining 911 service.
I don't know whether it's a red herring or just mass confusion. What almost everyone seems to be missing is that VoIP for individual subscribers has evolved to be IP-address independent, which is a wonderful thing because it means we can take our tiny VoIP boxes with us and thereby take our phone numbers with us almost anywhere in the world. The VoIP box calls home when powered up and periodically thereafter to let the connection server know where its phone number may be found in the IP network. This is overwhelmingly more advantageous and on a far more frequent basis than 911 service.
Also, problems of power outages or location ambiguity are not new... ISDN phones and other electronically enhanced phones have always been dependent on house power, and location determination for cell phones is a very new thing. I lived most of my life without 911, which itself is not very old, so I find it more than a bit strange that so many people think they can't live without it and don't think far enough to realize that there are alternatives for having 911 other than on their VoIP service.
The only form of VoIP location determination acceptable to me would be one I could enable/disable and program myself. Vonage already includes an approximation of this. I can turn 911-equivalent on or off and I can register the location of the "phone" with their server. If I dial 911 Vonage routes it to the emergency service number for my area or for my principal emergency service agency. Unfortunately the control freaks will probably find something this much under my control to fall short of their compulsion to build in location determination that is not under the control of the phone user.
Someone will probably say that the cable will go out when the power goes out.
I wouldn't say that. YMMV but around here the outages are almost always highly localized and never affect my cable or DSL service. Once in a great while the cable will go out with a lightning strike while the power remains on.
Also, the custom in the phone business is full battery power, and the cable companies are slowly beginning to catch on to the fact that they, too, are providing critical services that can't just disappear if their head end facility loses power. In the Great Northeast Blackout of 1965 all the phone lines remained operational, with occasional clicks that may have been the switching of battery banks.
When power goes down, the trickle in the land line means I still have a phone connection...
That's not a "trickle" -- the telco central office completely powers a standard telephone. Electronic phones that use wall warts for power will likely not work in a power outage, which means that the VoIP situation is not unique -- it is simply a side effect of using electronics to make the phone connection no matter what the phone technology. Long before VoIP ISDN users were warned by the telcos that unless they provided UPS for their ISDN equipment they would have no service during power outages.
Of course, if I actually joined the 21st century and bought one of those new fangled doo dads called "cell phones" this problem would go away...
Indeed. Or you could just make a one-time expenditure for a small UPS. A UPS will keep a VoIP box up and running for a long time. Or you could do both. I do both. My Vonage and 900 MHz phone are on a UPS and I have a prepaid cellphone that is very economical to have available for infrequent use. A bonus is that Vonage can ring both the Vonage phone and the cellphone at the same time, so I don't have to set up and take down forwarding when I leave the house and return -- I just have to remember to take the cellphone with me when I go out.
And of course currently it is unlikely that you are using Voip if you're not at home
Oh? People are rapidly discovering that VoIP, mostly being independent of IP address since it "calls home" to announce its location to the VoIP connection server, works almost anywhere on the planet. People are now taking VoIP boxes with them when they travel, or permanently relocating them to other countries after account establishment. The whole location determination issue is incompatible with the incredibly convenient location-independent manner in which VoIP has been developing for single-line users.
A friend of mine recently relocated from NYC to the Southwest U.S. I got him onto Vonage before he moved, and he transferred his NYC number of 40 years to Vonage. Now the same stable number he has had for four decades rings in Texas and no one has to know or care that his physical location has changed by 1700 miles.
Another friend travels regularly to South America. He took his Vonage box there and found that it works perfectly, so he left it there. Now his U.S. phone number rings and is answered in South America.
It's a new phone world, first with IP-address-independent VoIP and now enhanced with phone number portability, at least within the areas of portability. I can now consider that I have a lifetime phone number that I can relocate anywhere in the U.S. with or without VoIP and almost anywhere in the world with VoIP.
One misconception you seem to have is that somebody might avoid making more money for fear of being pushed into a higher tax bracket.
Another cluless fuckwit! I've watched people adjust their work to avoid getting taxed at a higher rate, including my own father, who scaled back his work after going on Social Security and stopped working each year just before he reached the earnings limit after which his SS would be reduced.
You are probably too young to remember that not long ago we had an incremental income tax rate that topped out over 90%. No one did anything without first considering the tax consequences, and lots of people refused opportunities and jobs because it wasn't worth the effort to keep only 10 cents of each additional dollar.
It's a real tragedy that people as ignorant and/or destructively oriented as you are allowed to vote.
I wonder whether that would be Wang's COBOL ReSource, which has been available for AIX on RS/6000 and HP/UX on HP-9000 since its release in 1993?
If so, there was nothing of "emulation" in it whatsoever. COBOL ReSource provides the look and feel of the Wang VS with Wang's COBOL 85, Procedure Language, principal VS utilities, Job Queue, Print Queue, and very capable PDMS file system. The compiler is of a modern design that generates an intermediate language, translates that into native assembly language, then invoke the native assembler and linker. No pseudocode or interpretation is used.
Both the Wang VS and COBOL ReSource are still alive and kicking.
RPG is one of those languages that is higher up than assembly, but barely. We had a manager who had a wiring board in her office. It was from the mainframe days when the card sorter was a separate machine from the 'CPU'.
You seem to be mixing together two distinct generations of computing. Tabulating card machines came before mainframes and coexisted with mainframes for some years, but had little directly to do with mainframes. Entire operations worked with cards and plugboard-programmed tab card machines -- sorters, collaters, duplicators, report machines, and perhaps a few others. No "CPU" needed.
Point being, in RPG II, I could 'see' the wiring board in the source code.
True. RPG was developed by IBM, as I understand it, to provide an upward path for all those tab-card-machine plugboard programmers. That's why it closely mapped the plugboard metaphor in its early version.
...One wouldn't expect a G/L, A/P, and A/R system to be written in assembler. They *could* be, but using a language built around records and the cycle of output, input, calculate makes more sense than trying it in assembler.
You may not be aware that major applications were commonly written in assembly language, including in the mainframe arena. Classified job ads of the late 1960s well into the 1970s were as full of IBM BAL Programmer positions as they were of COBOL Programmer positions.
In Wang VS Assembler (a 360/370-like machine but with stacks and an entirely different, interactive OS), for example, it is a matter of one line to open a file for input, output or, for some file types, shared access. That's any type of file -- consecutive, indexed, alt-indexed, relative, print, object, etc. Simple block mode workstation I/O can be done in a few lines and a few more lines of variables and some constants. It is therefore possible to write a program in a few tens of lines that, say, solicits first name, last name, address, city, state and ZIP and builds an alternate indexed file from the entries and then retrieves records on demand by any of those fields. Maybe a few score of lines.
Macros in Assembler were developed to a high art. A macro to open a file might contain hundreds of lines in its source, with conditional assembly pseudo-ops for decision logic, to munch the almost English-like single statement the programmer used to open the file. The macro would expand into a customized set of mostly PUSH operations to set things up to invoke the OPEN SVC instruction, which in turn generated an interrupt and was acted on by the OS.
Other seemingly complex things were as easy to do as opening a file. A screen full of parameters to be filled in by a calling program or procedure could be generated with some variables and a simple macro call or two. The result might only display on the workstation for human intervention if it failed to pick up all its necessary fields from some higher level program or procedure.
Essentially all the complex operations involving interaction with the OS and file system were packaged into macros, leaving only the actual data manipulation and decision logic to be written in seemingly cryptic Assembler that actually generated machine instructions one-for one.
Oh yes... since the hardware directly supported not only binary floating point but decimal floating point, pretty complex calculations could be done directly in Assembler.
Last, there are still quite a few of those Wang VS machines in production roles around the world. They've been extremely difficult and expensive to replace. And they're about to make a comeback. Film at 11.
Exactly right. This is Slashdot, where it's considered lame to read the article or have a clue about the subject before posting.
do they assume you can only talk to other vonage customers?
No, most posters assume the opposite but leap to an incorrect conclusion. Many understand that Vonage interacts with the PSTN and erroneously believe that therefore it should be regulated. They don't know that interfacing to the PSTN is not and never has been the legal basis for regulating telephone companies. Phone companies are regulated because they were believed to be "natural monopolies" and were given the exclusive privilege in their service areas of running lines on public private property. It was believed that as monopolies they should be regulated and that as exclusive franchisees for building infrastructure on public property and having the power to use private property without permission, they should be regulated. None of those factors is present in the Vonage scenario. The PSTN to which Vonage interfaces for some calls is already funded, built and taxed. Any common carrier such as a phone or cable service that an Internet user employs to utilize Vonage is already taxed.
Many posters also assume that Vonage ties into the 911 system. Maybe someday it will, but right now it doesn't. Vonage lets you set up a kind of speed dial in which "911" will call the regular phone number of your local emergency service. They do this for you when you explicitly request that fake 911 be activated and you provide your certified physical address. If you take your Vonage VoIP box to Italy and dial 911 the emergency folks will show up at your registered address in the U.S.
Personally I would clasify vonage as a real phone company,
Then you're giving up the battle before it's fought. Just because you use Vonage the same way you used the services of your local telco doens't mean Vonage is a phone company in the context of regulation. You're falling into the same trap that advertisers and publishers and legislators and others have fallen into, thinking that the Internet is just like broadcast radio or TV, or just like magazines, or whatever. It's not any of those things, and Vonage is not a phone company. If you favor VoIP as a new, more efficient, less costly and less taxed way of communicating by voice, then perhaps you should learn not to fall into the vocabulary and other traps being used to good advantage by the opponents of VoIP, none of whom are your friends.
No they're not. Vonage doesn't provide me with phone service. They don't provide a line and they don't carry my phone calls on any of their equipment. They provide an IP finder, not unlike Yahoo Instant Message service does. Vonage calls are peer to peer once the IP has been found. If one side of the call is in the PSTN then Vonage interfaces there, and pays for it.
There's also no hardware required if you don't want it. In the extreme you can use Vonage just like using Yahoo IM for voice communication -- entirely through your computer. The only difference, even if you elect to use the VoIP router, is that the "user id" for locating the IP of the other party is something that looks an awful lot like a traditional phone number.
Vonage is clearly not a phone company providing phone service, so NY is not taxing telephone service when they tax Vonage and its customers.
Since your broadband provider could be the critical link between you and 911, shouldn't they bare some of the burdon of ensuring 911 is available as well?
An awful lot of you seem to be completely ignorant of the fact that Vonage has nothing to do with 911 service. All Vonage does, and then only if you ask for it, is to set up a kind of speed dial in which "911" on your Vonage phone will speed dial your local emergency 7- or 10-digit phone number. Get it?
Slashdot Mirror
See 10999036 just posted.
Anonymous Coward wrote on Saturday December 04, @08:50AM (#10996046)
Sadly, no, it wouldn't have the same effect. Links anywhere are subject to redirection by meta refresh tag and by DNS modification to point Web traffic to any other host on the planet.
Something like this has to be done the way Lycos was doing it, with human qualification of the target sites, retrievals by mechanisms less intelligent than browsers, and with monitoring of host/IP settings to catch DNS redirection.
Of course the open source community could come up with a substitute potentially even better than the Lycos tool...
Design for a Free Open Source Spamsite Hammer
The key to the legitimacy of a user doing this is that SPAM emails contain explicit invitations to visit the spamvertized Websites. There can be no implied or inferred limit to the browsing an invitee does on a publicly accessible Website, at least not within the range of what a human could or might do, even an obsessive-compulsive human who can't resist clicking on all the links he or she finds on the site that extended the invitation. Nor can there be any limit to the use of automated tools, as those have legitimate roles in off-line browsing of downloaded Websites. To the end of making the tool's HTTP requests indistinguishable from regular browser requests the retrieval tool could intelligently construct "Referer" headers and use a very common "User-agent" header, and request actual documents as a browser would instead of formulating invalid requests as the Lycos screen saver did. This would simply make it very difficult for a spamsite operator to figure out who is who and who is doing what.
The short version of the design spec:
The email-based target list builder should, if the final retrieved web page is determined by the user to be spammy, add to the target list any and all redirection sites along the way. Often the SPAM email contains the URL of a middleman redirector and it's not unusual for the second site to also be a redirector.
Once the user has confirmed that the target is a spamvertized Website, all redirectors leading there are added to the target list and the host/domain(s) and IP address(es) are logged.
The background process works from the target list, perhaps at a rate that is somewhat configurable by the user.
Using low-level TCP to retrieve objects should make it possible to avoid malicious HTTP redirection to innocent sites. Qualification of a target site and all normal spam response redirector sites leading to it is accomplished merely by the go/no-go determination by the user of the spamminess of the ultimate Web page retrieved.
The background process would do a forward DNS loo
Rarely, if ever. That's because one of the ways the just-us system protects itself is to use any available excuse to avoid reexamining done deals. The "donest" deal of all is a convict who has already been executed. The gummint usually argues that if the guy is dead, it's moot whether or not he was really, factually guilty. So it shouldn't be a surprise that the system tries to bury its mistakes rather than own up to them.
Look for references to Randall Adams, Adams vs Texas, and The Thin Blue Line. It's a stunning case of prosecutorial misconduct in which the prosecutor apparently got away scot free after ruining a man's life and very nearly getting him executed.
The prosecutor had a choice: he could prosecute the perp he knew did the crime, but with no witnesses, and probably lose, or he could prosecute the innocent guy using the perp's purjured testimony and get a conviction.
If we were going to have a death penalty for anything, it should be only for that kind of abuse of power.
There is no point at all in arguing any of the traditional arguments for or against capital punishment as long as the gummint can't be trusted to get it right and always convict only the truly guilty party. No other basis for supporting or opposing capital punishment has any meaning unless and until this glaring problem is resolved.
Sorry, no. All that's required to detect DNS modification is to do a forward DNS lookup periodically. If the client does it as a browser would on each new access, it could detect an IP change, remove the target from its list, and report to the Lycos server that the IP of such-and-such hostname had changed. The server could put the item on a short list for immediate reexamination by humans. If the new IP is also a spamvertized web server, the host could go back onto the target list. Otherwise it could be examined periodically by a robot and flagged again for reexamination when either the IP or the content changes again.
So, so simple. And the beauty of having the client detect the IP change is that clients would continue to hammer the original until the DNS change propagates to them.
Only if we presume that the Lycos people who crafted this have no brains. More likely, the outline of what they do looks something like this:
Most of the naysayers have not taken more than a superficial look at what Lycos did, and too many are relying on the uninformed opinions of other posters who have also failed to look closely at it or to think it through.
The Lycos screen saver is dynamic, not static. It can be given new instructions virtually in real time, including instructions to target nothing or to go into its present dimmed "Stay Tuned" mode.
Unnecessary. The Lycos tool is not a browser, nor does it request any existing document. Metatag redirection never comes into play for both these reasons. The Lycos tool formulates a GET or POST request that cannot be satisfied, stimulating an error response from the target web server. Even if the target were to attempt redirection in the error response the Lycos tool would merely receive the response, not act on it.
Right. Pretty much all of the recent news stories about this got it 100% wrong. In fact, from a sample HTTP request someone posted in one of these Lycos threads here, the screen saver doesn't even request a valid file. It generates a GET or POST intentionally formulated to generate a web server error response. Very clever. Not so clever are all the whiners and speculators who erroneously presume things like the imagened vulnerability of the Lycos tool to HTTP redirection.
I think you're thinking of the senders of spam. The spamvertized ecommerce websites generally have to have a bit more stability than hijacked machines, and have to be pointed to by DNS, which would provide a link from the domain owner to the illegally hijacked machine, etc.
Sorry, no. This kind of punishment can't be done effectively from browsers for several reasons.
First, host/domain addresses can easily be jiggered by the spamsite operator to point to innocent IP addresses. One of the Lycos targets, "go-medz.com", did exactly this last night. They updated their DNS to point to an open source mirror site for a few hours in the apparent hope of causing collateral damage that might be blamed on Lycos. I'm pretty sure Lycos is wise to such stunts and anticipated them in the design of the anti-spam screen saver and its supporting servers.
Second, a spamsite operator could easily modify the site's front page to contain links to objects such as graphics located on innocent servers elsewhere. SpamVampire is particularly vulnerable to being deceived in this manner. The Lycos screen saver is not, since it does not act in the manner of a browser and in fact doesn't even retrieve any actual documents from the target sites much less act on any object links in documents.
From information posted here earlier by someone else, the Lycos screen saver appears to formulate an HTTP request guaranteed not to be understood by the target server, eliciting an error response.
I think it's a safe bet that Lycos anticipated the DNS trick and logs the IP address of each target site at the time their spamminess is verified by a human and then periodically checks by DNS request to take the site off the target list if the IP address changes in DNS. If I were designing this the repointed site would then go onto a short list for quick manual reverification and as long as it remained pointed at a non-spammy site, DNS would be monitored closely to catch it reverting back to its business IP address.
go-medz.com apparently couldn't resist going back to their internet pharmacy business server, because their kind of spiteful action resulted in 100% loss of business traffic to their site. It only lasted a few hours.
Some of the target sites did apparently change IP addresses to other of their hosting facilities. This is an expected reaction that could be interpreted to mean that they wore out their welcome at the original hosting sites or upstream ISP feeds. It reveals, though, that the spamsites are resilient and not easy pushovers.
That spammer who was recently convicted in Virginia was spending $50,000/month on Internet connectivity with which to push out his millions of emails a day and presumably receive the website visits from those stupid enough to respond.
The screen saver isn't a tool that blindly does its work. It communicates with the server to report and to receive new targets. For a time, leading up to about 25 hours ago, the screen savers were not given any targets at all, either because Lycos had maxed out the targets of the day or maybe because the Lycos folks were implementing a workaround for an unanticipated spamsite evasion trick. Around midnight US CST the server started handing out targets again, slowly at first, ramping up to the normal levels of recent days. Dec 1 was actually the inauguration of the Lycos makelovenotspam program, so we can guess that the earlier days may have been pre-release testing and validation of the concept.
Yes, we need that. Our municipalities have far too many ordinances.
I have no argument with anything you wrote. A huge ice storm is not a common event, though, and general experience throughout my lifetime has shown that ordinary phones continue to work in almost all the situations we encounter unless the lines are physically down or we're unlucky enough to have taken enough of a lightning hit to fry the line or the phone or the CO port.
My first point was simply the quibble that what powers the old-fashioned phone isn't a "trickle," it's the primary power intentionally provided by design and implementation on the phone line. Decades ago when I used to play with such things, my phone line had, if I recall, an open circuit voltage of either 48VDC or 120VDC. Picking up the phone dropped the voltage across the phone to just about 6VDC with "talk current" passing through it. The ring signal was 120V 20 cycle AC, very easy to feel if holding the wires when it came through. Yes, extended power outages will strain the telco's ability to keep the phone system powered, but extended outages are the exception, not the rule, even in a shitty power area such as mine.
My other point was that not all that many people use ordinary, non-electronic phones anymore, and variants such as ISDN and broadband-based VoIP have been multiplying in the last few decades. All the electronic stuff breaks the model of an always-working phone, but power, at least, can be assured for a long time with even a modest UPS.All my computer and communication gear is on various UPS units. The cable modem is on its own UPS, the DSL is on its own UPS and the VoIP and phone are on their own UPS. My CPAP machine has its own UPS because more than once in the past I had the unpleasant experience of waking with no air to breathe when power went out at night. All told I have about 10KVA of UPS on line at all times and another 10KVA rotated out of service or awaiting battery replacement. The smallest one, that runs my VoIP and phone, would suffice for the averge non-geek consumer using VoIP.
First, that's not the point. The point is that he was able to move 1700 miles without changing anything about how people reach him by phone. That's 40 years worth of people who have his number in their minds, their phones and their address books.
Second, if and when he wants to have a "local" Texas number all he has to do is surf to the Vonage page and order one. $4.99 + $1.50 federal tax per month. He can have as many as he likes... his original one in NYC, one in Texas, maybe one in Chicago to allow a few friends there to reach him by local call...
Third, so far, at least, he originates all the calls to local people, and his LD is unlimited throughout the U.S. and Canada. I have Vonage, too, with a local Texas number, and on occasion he has called the living room at my Texas number from the guest bedroom and his NYC number. That's nominally LD but since we both have unlimited LD it's a no-brainer for either to call the other within the same house. That was very weird the first couple of times, just as it was when he first arrived and we hooked up his Vonage box to my network and I dialled his NYC number. I know all about the technology but I just had to experience calling NYC and having his phone in the next room ring.
Maybe you can, maybe you can't. I just tried it on mine and there was no identifiable sound. You certainly can't hear the higher-than-audible DSL signal directly, although maybe you could hear harmonics or artifacts of it. Telco techs have told me that sometimes you can hear it. Maybe it also depends on the particular signalling flavor being used, and/or on the type of test set being plugged into the line.
In any case, the possible noise of DSL is not why filters are used. It's the other way around: Filters are used to prevent the low-frequency phones from killing the DSL signal. Plug an unfiltered phone into your DSL line and watch the green light turn red. Perhaps more accurately, filters are used to prevent the high and low frequency channels and components from interfering with each other.
For a nice, understandable writeup on DSL technology, see: xDSL Technology
I doubt it's a requirement. "Disconnected" phone lines in this area always go completely dead. There's no way to dial 911 without a dial tone. Also, in most places where I have lived, unused phone circuits sooner or later get segments stolen by phone techs for use in new subscriber circuits. Almost all subscriber circuits are actually collections of shorter circuits from junction box to junction box, and the tradition has long been that each hop of an unused circuit is up for grabs when a tech is installing new stuff and needs a path from one box to another.
There is even a problem with DSL circuits that don't have underlying POTS because the tech can't find current on the line and can't hear dial tone, so it looks like a dead circuit. This results in circuit segments being taken out of active DSL lines for use in new circuits being established.
Unfortunately Southwestern Bell Telephone, now SBC, has never been that intelligent in this area. I've allowed the land line service to lapse a number of times in the last decade and a half and it always struck me as rather brainless that the phone line went completely dead, making it impossible for the phone company to call me to sell me on restoring service, not to mention the altruistic (but, ahem, fully funded) ideal of maintaining 911 service.
I don't know whether it's a red herring or just mass confusion. What almost everyone seems to be missing is that VoIP for individual subscribers has evolved to be IP-address independent, which is a wonderful thing because it means we can take our tiny VoIP boxes with us and thereby take our phone numbers with us almost anywhere in the world. The VoIP box calls home when powered up and periodically thereafter to let the connection server know where its phone number may be found in the IP network. This is overwhelmingly more advantageous and on a far more frequent basis than 911 service.
Also, problems of power outages or location ambiguity are not new... ISDN phones and other electronically enhanced phones have always been dependent on house power, and location determination for cell phones is a very new thing. I lived most of my life without 911, which itself is not very old, so I find it more than a bit strange that so many people think they can't live without it and don't think far enough to realize that there are alternatives for having 911 other than on their VoIP service.
The only form of VoIP location determination acceptable to me would be one I could enable/disable and program myself. Vonage already includes an approximation of this. I can turn 911-equivalent on or off and I can register the location of the "phone" with their server. If I dial 911 Vonage routes it to the emergency service number for my area or for my principal emergency service agency. Unfortunately the control freaks will probably find something this much under my control to fall short of their compulsion to build in location determination that is not under the control of the phone user.
I wouldn't say that. YMMV but around here the outages are almost always highly localized and never affect my cable or DSL service. Once in a great while the cable will go out with a lightning strike while the power remains on.
Also, the custom in the phone business is full battery power, and the cable companies are slowly beginning to catch on to the fact that they, too, are providing critical services that can't just disappear if their head end facility loses power. In the Great Northeast Blackout of 1965 all the phone lines remained operational, with occasional clicks that may have been the switching of battery banks.
That's not a "trickle" -- the telco central office completely powers a standard telephone. Electronic phones that use wall warts for power will likely not work in a power outage, which means that the VoIP situation is not unique -- it is simply a side effect of using electronics to make the phone connection no matter what the phone technology. Long before VoIP ISDN users were warned by the telcos that unless they provided UPS for their ISDN equipment they would have no service during power outages.
Indeed. Or you could just make a one-time expenditure for a small UPS. A UPS will keep a VoIP box up and running for a long time. Or you could do both. I do both. My Vonage and 900 MHz phone are on a UPS and I have a prepaid cellphone that is very economical to have available for infrequent use. A bonus is that Vonage can ring both the Vonage phone and the cellphone at the same time, so I don't have to set up and take down forwarding when I leave the house and return -- I just have to remember to take the cellphone with me when I go out.
Oh? People are rapidly discovering that VoIP, mostly being independent of IP address since it "calls home" to announce its location to the VoIP connection server, works almost anywhere on the planet. People are now taking VoIP boxes with them when they travel, or permanently relocating them to other countries after account establishment. The whole location determination issue is incompatible with the incredibly convenient location-independent manner in which VoIP has been developing for single-line users.
A friend of mine recently relocated from NYC to the Southwest U.S. I got him onto Vonage before he moved, and he transferred his NYC number of 40 years to Vonage. Now the same stable number he has had for four decades rings in Texas and no one has to know or care that his physical location has changed by 1700 miles.
Another friend travels regularly to South America. He took his Vonage box there and found that it works perfectly, so he left it there. Now his U.S. phone number rings and is answered in South America.
It's a new phone world, first with IP-address-independent VoIP and now enhanced with phone number portability, at least within the areas of portability. I can now consider that I have a lifetime phone number that I can relocate anywhere in the U.S. with or without VoIP and almost anywhere in the world with VoIP.
Another cluless fuckwit! I've watched people adjust their work to avoid getting taxed at a higher rate, including my own father, who scaled back his work after going on Social Security and stopped working each year just before he reached the earnings limit after which his SS would be reduced.
You are probably too young to remember that not long ago we had an incremental income tax rate that topped out over 90%. No one did anything without first considering the tax consequences, and lots of people refused opportunities and jobs because it wasn't worth the effort to keep only 10 cents of each additional dollar.
It's a real tragedy that people as ignorant and/or destructively oriented as you are allowed to vote.
I wonder whether that would be Wang's COBOL ReSource, which has been available for AIX on RS/6000 and HP/UX on HP-9000 since its release in 1993?
If so, there was nothing of "emulation" in it whatsoever. COBOL ReSource provides the look and feel of the Wang VS with Wang's COBOL 85, Procedure Language, principal VS utilities, Job Queue, Print Queue, and very capable PDMS file system. The compiler is of a modern design that generates an intermediate language, translates that into native assembly language, then invoke the native assembler and linker. No pseudocode or interpretation is used.
Both the Wang VS and COBOL ReSource are still alive and kicking.
COBOL ReSource
VS WebCenter
Degrees wrote:
You seem to be mixing together two distinct generations of computing. Tabulating card machines came before mainframes and coexisted with mainframes for some years, but had little directly to do with mainframes. Entire operations worked with cards and plugboard-programmed tab card machines -- sorters, collaters, duplicators, report machines, and perhaps a few others. No "CPU" needed.
True. RPG was developed by IBM, as I understand it, to provide an upward path for all those tab-card-machine plugboard programmers. That's why it closely mapped the plugboard metaphor in its early version.
You may not be aware that major applications were commonly written in assembly language, including in the mainframe arena. Classified job ads of the late 1960s well into the 1970s were as full of IBM BAL Programmer positions as they were of COBOL Programmer positions.
In Wang VS Assembler (a 360/370-like machine but with stacks and an entirely different, interactive OS), for example, it is a matter of one line to open a file for input, output or, for some file types, shared access. That's any type of file -- consecutive, indexed, alt-indexed, relative, print, object, etc. Simple block mode workstation I/O can be done in a few lines and a few more lines of variables and some constants. It is therefore possible to write a program in a few tens of lines that, say, solicits first name, last name, address, city, state and ZIP and builds an alternate indexed file from the entries and then retrieves records on demand by any of those fields. Maybe a few score of lines.
Macros in Assembler were developed to a high art. A macro to open a file might contain hundreds of lines in its source, with conditional assembly pseudo-ops for decision logic, to munch the almost English-like single statement the programmer used to open the file. The macro would expand into a customized set of mostly PUSH operations to set things up to invoke the OPEN SVC instruction, which in turn generated an interrupt and was acted on by the OS.
Other seemingly complex things were as easy to do as opening a file. A screen full of parameters to be filled in by a calling program or procedure could be generated with some variables and a simple macro call or two. The result might only display on the workstation for human intervention if it failed to pick up all its necessary fields from some higher level program or procedure.
Essentially all the complex operations involving interaction with the OS and file system were packaged into macros, leaving only the actual data manipulation and decision logic to be written in seemingly cryptic Assembler that actually generated machine instructions one-for one.
Oh yes... since the hardware directly supported not only binary floating point but decimal floating point, pretty complex calculations could be done directly in Assembler.
Last, there are still quite a few of those Wang VS machines in production roles around the world. They've been extremely difficult and expensive to replace. And they're about to make a comeback. Film at 11.
Exactly right. This is Slashdot, where it's considered lame to read the article or have a clue about the subject before posting.
No, most posters assume the opposite but leap to an incorrect conclusion. Many understand that Vonage interacts with the PSTN and erroneously believe that therefore it should be regulated. They don't know that interfacing to the PSTN is not and never has been the legal basis for regulating telephone companies. Phone companies are regulated because they were believed to be "natural monopolies" and were given the exclusive privilege in their service areas of running lines on public private property. It was believed that as monopolies they should be regulated and that as exclusive franchisees for building infrastructure on public property and having the power to use private property without permission, they should be regulated. None of those factors is present in the Vonage scenario. The PSTN to which Vonage interfaces for some calls is already funded, built and taxed. Any common carrier such as a phone or cable service that an Internet user employs to utilize Vonage is already taxed.
Many posters also assume that Vonage ties into the 911 system. Maybe someday it will, but right now it doesn't. Vonage lets you set up a kind of speed dial in which "911" will call the regular phone number of your local emergency service. They do this for you when you explicitly request that fake 911 be activated and you provide your certified physical address. If you take your Vonage VoIP box to Italy and dial 911 the emergency folks will show up at your registered address in the U.S.
Then you're giving up the battle before it's fought. Just because you use Vonage the same way you used the services of your local telco doens't mean Vonage is a phone company in the context of regulation. You're falling into the same trap that advertisers and publishers and legislators and others have fallen into, thinking that the Internet is just like broadcast radio or TV, or just like magazines, or whatever. It's not any of those things, and Vonage is not a phone company. If you favor VoIP as a new, more efficient, less costly and less taxed way of communicating by voice, then perhaps you should learn not to fall into the vocabulary and other traps being used to good advantage by the opponents of VoIP, none of whom are your friends.
Excellent! Yours is the clearest post in the entire thread.
No they're not. Vonage doesn't provide me with phone service. They don't provide a line and they don't carry my phone calls on any of their equipment. They provide an IP finder, not unlike Yahoo Instant Message service does. Vonage calls are peer to peer once the IP has been found. If one side of the call is in the PSTN then Vonage interfaces there, and pays for it.
There's also no hardware required if you don't want it. In the extreme you can use Vonage just like using Yahoo IM for voice communication -- entirely through your computer. The only difference, even if you elect to use the VoIP router, is that the "user id" for locating the IP of the other party is something that looks an awful lot like a traditional phone number.
Vonage is clearly not a phone company providing phone service, so NY is not taxing telephone service when they tax Vonage and its customers.
An awful lot of you seem to be completely ignorant of the fact that Vonage has nothing to do with 911 service. All Vonage does, and then only if you ask for it, is to set up a kind of speed dial in which "911" on your Vonage phone will speed dial your local emergency 7- or 10-digit phone number. Get it?