Why, he invented, created, authored the thing, it seems to mean just the same (intellectual property you know, there is no significant difference between an invention and a work of art).
What would you think if Al Gore claimed to have written the Internet? Would that make any more sense?
However, Katu News doesn't tell who invented that news item either, only that it came via Associated Press. Maybe this particular news item is a bit short for a patentable invention, but it never hurts to provide some credit to the guy behind it...
Correct, the identity of the true copyright holder is in doubt. However, that doesn't mean Sun can do as they please with the Unix code in question; they still need approval from the copyright holder if they intend to change the licensing terms for anything that includes Unix code.
I seem to recall Novell has publicly exonerated IBM from allegations of copyright infringement made by SCO (pointing to provisions in their agreement with SCO allowing Novell to act on behalf of SCO, no less), but has Novell spoken out on the issue of others using Unix code in any way they see fit? Does Sun have a license from Novell too, just in case?
Since I don't have any actual SCO code myself, I'm tempted to write some code of my own and assign it to SCO, just to be able to distribute it without their permission. As if they would care.
Are ISPs required by law to keep the kind of information that enables anyone to find out who was logged on where and when? If so, for how long must that information be kept?
It obviously depends on your jurisdiction, and I don't know which countries have enacted legislation like this, although there is certainly talk about increased logging for law enforcement purposes. In Sweden, public entities such as government agencies and universities are required to log pretty much any transactions with others and to retain those logs for at least two years, so if you see suspicious traffic from a Swedish university IP address, inquiring about it is a good idea (I work at a university). Perhaps the logs aren't always there when you want them, but if we do have any logs left, we are required by law to either provide the information sought or justify (in writing) why we cannot provide it.
Private corporations, such as your average ISP, operate under a less rigorous set of rules in Sweden, and they need to maintain logs primarily for billing purposes and to otherwise fulfil their committments towards their own customers only, normally for a couple of months. I'm sure they have some obligations towards law enforcement as well, but I don't know what those amount to.
One problem I see with enacting far-reaching legislation for what an ISP must log and for how long is, what constitutes an ISP? If I set up a free e-mail forwarding service, sponsored by advertising, does that make me an ISP even when my customers are not identical with the users of the site? I may even be the only user myself; would I have to log my own e-mail?
If there is no law for them to keep that kind of data, it seems to me that ISPs would save themselves a lot of trouble to simply not log anything that can identify any particular user. This means for a DHCP assigned address, the ip number that was assigned at any particular time is unknown.
It doesn't matter too much whether there is a law or the ISP maintains logs of its own free will. Maintaining adequate logs is a matter of good security measures to me, and an ISP systematically failing to keep any logs would be enough for me to block traffic from said ISP.
I'm not out to do the job of law enforcement; I'm interested in protecting my property, and if my neighbour refuses to help me find out who crossed his lawn to break into my house, I'll put up a higher fence between the two of us. I don't require him to put up surveillance cameras on his driveway, but if he does nothing to keep burglars away from our common premises, I won't exactly invite him to dinner at my house. Why can't the same standard of cooperation be upheld on the Internet?
If someone from a particular IP attacked your computer, that's a criminal issue, not civil. Make sure you're wearing the right hat when you make analogies.
In what jurisdiction? I mentioned the cross-border situation for a particular reason (I'm not located in the United States). Don't you think I could file a civil lawsuit against someone involved in causing harm to my property, just because the harm was done by means of a computer and there is a criminal statue against computer intrusion? What about DDoS attacks that cause harm without being criminalized?
I agree with the original poster that the RIAA should not utilize criminal law enforcement resources to obtain evidence for the purpose of civil litigation, but are you saying that they do precisely that? Then who is wearing the wrong hat, me or the RIAA?
Whether the case is civil or criminal, asking for anonymity and exoneration (i.e. recognition that you did nothing wrong) at the same time doesn't work. Anonymity may shield you from litigation, but increases suspicion and encourages potential litigants to seek alternative means of action rather than "pound sand". Right or wrong, the end result isn't necessarily prettier or better for everyone involved.
I know that this is a civil case, not a criminal case, but I think you should still know who you are suing before you can do it. If the RIAA can't figure out who say, 66.35.250.150 is, they can go pound sand as far as I'm concerned. Figure it out and come back, or don't, and drop it. And while you're at it, don't use our criminal justice system to go fishing for you.
That would create a legal loophole big enough to drive even SCO through it. Or perhaps, we already suffer from such a loophole. When my computer is attacked by an appearant intruder at 66.35.250.150 (using the IP from your example; I don't recall seeing it before), I conclude that someone is responsible for the intrusion. I contact the ISP to find out who, but they won't tell without a court order. Going through the paperwork to obtain a court order, especially across national borders, is something I'd like to avoid, so I'd rather sue the ISP for their involvement and let them sort it out with their customer if they want.
By requiring me to know the name and residential address of the real perpetrator before I can take any kind of legal action against them, I'm effectively prohibited from taking action against either the perpetrator (because he is anonymous) or the ISP acting as his front (because they can correctly claim that they acted on behalf of their customer only and uphold his anonymity).
I don't like being on the same side as the RIAA, and I feel their lawsuit campaign does infringe on the rights and freedoms of individuals, but it's not because those are "John Doe" lawsuits. The combined claims of "I did nothing wrong" and "I have the right to be anonymous and immune against legal action even in case of suspected wrongdoing" sound a bit hypocritical to me. I'd rather request to defend my actions in court, if I had the opportunity. If you don't trust your legal system to be fair to you, don't ask that same legal system for protection against said infairness, but ask someone else.
I tried accessing your website, but it appears both your name servers (ns.globalwebpromotions.com [69.31.33.254] and ns2.globalwebpromotions.com [69.31.33.253]) are inaccessible right now. Back in the old days (early 1990's) connectivity was generally worse, and we made a bit more of an effort to set up several name servers on different networks, for backup.
Gradually, those efforts became regarded as unnecessary. Today, connectivity is generally better, but when a link goes down for whatever reason, it all too often happens that a number of domains go down with it.
note before I said that the standard should be a 10TB server if you're going to do DNS at all
It doesn't matter how much disk space you have, and I wasn't commenting on it. I was commenting on how much data you expect "some other company" to store in order to delegate a domain to your server. Again, you said:
Another company doesn't have to pay for the 256 bytes of space a DNS name takes up
If the domain 256bytename.com is assigned to you, the root server only needs to know that "com" is handled by the.COM server, and the.COM server needs to know that "256bytename" is handled by your server. Regardless of whether you have a name server of your own or use the services of some ISP, the.COM server still has to remember "256bytename".
If we implement a flat namespace instead and forget about the.COM level, all that happens is that the root server is now required to keep track of the "256bytename" and where your name server is located. The root server has to do the same for every other domain out there. They may well have 10 TB of disk space for that purpose, but someone has to pay for it, and that someone is you, the domain owner. You cannot avoid that cost by setting up a server of your own with 10 TB of disk, because everybody will still ask the one and only root server where your domain is. That's why your suggestion "use your own root server" sounds nonsensical to me.
I'm not saying that it's impossible to implement a flat namespace, only impractical given the benefits of a hierarchical namespace. With a flat namespace, you can't subdelegate; instead you will have to pay the root server administrators for every single domain you want. If you have hundreds of workstations, a handful of servers, a dozen printers and a few other gizmos on your office LAN, do you really want to pay Verisign $10 annually for each connected unit?
A flat namespace is not at all alien to the Internet; we had that 20 years ago, and maintaining a central list of all the hosts (the SRI-NIC HOSTS.TXT file) was an administrative nightmare already with a few thousand hosts only. That's why the DNS was introduced, allowing us to delegate entire branches of the namespace to different organizations, so you no longer had to contact SRI-NIC to connect annother server to your office LAN. Maybe you don't need to advertise every single host to the world, but you still need a way to reserve its name for your own use only.
This isn't exactly about tech support (which I seldom call anyway), but here is a story from a long gone past:
In 1987, our university department had moved to a new building, and a 10base5 ethernet (yellow coax) divided into five segments had been installed to serve offices and labs on six floors. Since we brought with us a few hundred DEC VT100 terminals, we had maybe 40 Ungermann-Bass NIU-180 terminal servers (eight RS-232 ports each) distributed throughout the building, booted with software downloaded from a dedicated IBM PC.
The Ungermann-Bass TCP/IP software was still only in beta state when it was delivered to us, something I wasn't quite aware of from the start but learned the hard way. Occasionally the terminal servers would simply hang for no obvious reason, requiring us to reset them manually. This was a bit tedious (six floors, remember), and I tried unsuccessfully to find the cause by analyzing network traffic using two SpiderMonitors.
Then one day our DEC Field Service engineer arrived to install the NIA20 ethernet interfaces we had acquired for our two DEC-2060 systems. The installation procedure involved extensive testing of the equipment, some of it when connected to the ethernet, and I could see lots of funny packets with different protocol types (including ISO packets using the 802.3 protocol type field for packet length) scrolling by on the SpiderMonitor.
Minutes later I found out that pretty much every NIU-180 terminal server was now hung. Time for another walk through the building.
Given that we also had HP workstations using ISO encapsulation of IP packets on our network, I began to suspect that the NIU-180 TCP/IP software was sensitive to ethernet packets of (to it) unknown types, because the failures seemed to correlate rather well with the use of those workstations. I never made any conclusive tests to verify my theory, though.
Some time later I visited the Ungermann-Bass representatives in Stockholm to tell them what we thought of their product so far, and I mentioned the annoying hangings and my theory about what triggered them, including the "bad" test packets from the DEC-2060 systems.
"But then the fault obviously is with that other system, not with our terminal servers, right?"
I nearly began explaining at length what I had learned a few years earlier about fault tolerance in data communication protocols, but I realized I was dealing with sales people, not tech support, and rested my case. Some time later, we replaced the beta version with the official release of their TCP/IP software, and the problem was gone.
I looked at OptInBig's website, and it's very professional. It has an unsubscribe link on every page, that allows you to unsubscribe from *every* OptInBig message.
Their website may be painted by Michelangelo and their ads written by Shakespeare; what counts is whether they send unsolicited advertising or not. If that unsubscribe link is useful for anything besides unsubscribing from something you voluntarily and knowingly subscribed to, they are spammers. Do they have a corresponding subscribe link on every page too, allowing you to subscribe to every OptInBig message, before you unsubscribe from them?
Another company doesn't have to pay for the 256 bytes of space a DNS name takes up- use your own root server for it.
You are joking, right? Or are you trying to say that everyone should have their own root server, each holding a single 256-byte domain name only? It's like saying you don't need a centrally maintained telephone directory listing thousands of subscribers; you can maintain your own entry and never call anybody else.
Imaginary space is only valueable as long as you can get people to pay for it- and the tree structure is only valuable for people who limit their imaginations to fit reality instead of changing reality to fit their imaginations.
In my imagination, tree structures are among the essentials in life. Our imaginations are different, and would conflict with each other if used as a basis for changing reality. Do you still believe both of us can have it our way?
Why make such a big deal about trying to solve a problem that's already solved? Create all the TLDs that you want. I guarantee that if someone other than Kodak tries to register Kodak.blah, the registrant of Kodak.blah will be shut down. It's a non-issue.
What problem are you calling a non-issue? Tim Berners-Lee isn't trying to make the DNS resolve trademark disputes; he wants the DNS to resolve names into numbers and other data, to serve a technical rather than legal purpose. In his plea to ICANN, he argues that the proposed new TLDs are poorly motivated, and that their introduction makes for increased costs and confusion to everybody on the Internet.
The first TLDs were defined as a very general classification of the entities named under them, such as whether it was a government or business entity. That classification remains, although it has been confused by registrations not adhering to it, such as websites under.NET not affiliated with any particular network operator.
If ICANN were to allow anybody to register their own TLDs (requiring uniqueness of the name only), we would effectively be back to the flat namespace we had before the DNS, although this time with potentially millions of domains rather than just a few thousand. Besides, I doubt the root name servers would stand the load. Maybe they could be redesigned, but I don't see the cost of doing it motivated by the dubious benefit of having a "kodak" domain where before we had "kodak.com".
This would reduce the case to whether or not IBM breached their contract by contributing to Linux (based on SCO's radical definition of "derivative works"). Everybody else would be OK and it would probably kill their lawsuits against AutoZone and DC.
Regardless of what kind of image SCO tried to paint in their press releases, the lawsuit against AutoZone appeared to be about AutoZone using other software actually belonging to SCO on a Linux host, not about AutoZone using Linux. If so, the outcome in the IBM case will have no effect on the AutoZone case, although SCO may decide to drop also the AutoZone lawsuit for other reasons (such as lack of sustained funding combined with losing the media campaign).
They are essentially asking for *anything* that might be related to the GPL, the companies that use it, people that write under it, enforcement, etc, including written communications, memo, documentation, etc.
Yes, but they are asking to receive it from the FSF, which is the most significant limit of their request (since the subpoena has to be aimed at a specified person or entity, that is also a mandatory limit). Considering that the FSF was founded for the very purpose of supporting development of free software, it's hard to imagine they have anything important that is not implied by this broad request.
I doubt I will ever be asked to provide documentation in this fashion, but I try to minimize the amount of confidential information I receive in matters not concerning immediate family and friends. I like talking to others about issues of interest to me, and I don't want to waste my time absorbing information that I can't pass on to others as I see fit (I'm not Dave Null). Why fill up disk drives, book shelves and my own brain with stuff that will be destroyed anyway when I die?
Still, the information I have is not organized well enough for me to be able to provide whatever may be asked for, and I think lack of a complete index or diary is also the most important reason for the FSF to be restrictive about what they will provide in response to the subpoena. Confidentiality of correspondance sounds like a relatively minor problem; they actually need to know more specifically what is being asked for and whether they do have it before they can argue that it's confidential.
A handheld authentication device, that sounds pretty much like a pen to me...
But I agree that what you describe is probably what's needed if the general public is ever to enjoy the benefits of digital signatures. Some vendors may for a couple of years be able to maintain the notion that user authentication can be achieved on generic PC hardware, but I can't imagine a court of law upholding that view once a user is hit by a virus that finds his key and messes with his personal bank account. The sooner this happens, the better for the rest of us.
I have so far refused to obtain any kind of digital ID for my private use, be it for my bank or for filing my income tax declaration, because I lack the necessary equipment to maintain a clear and visible level of security. No way am I going to give Redmond even indirect access to my bank account by placing critical keys on a Windows system! Of course, a Linux system wouldn't be acceptable either, due to its complexity.
Thus a separate device is needed, and I expect the design to be open to public inspection (no security through obscurity, please).
But to get back to the original subject: All this fighting-spam-by-changing-the-protocol-and-calling -it-secure talking just confuses the issue. Spammers are already running in circles around our ideas; there is no point in us trying to chase them in the same circles. Better concentrate on what they keep stealing from us, and make sure to get it back: Our time and money.
However, since AOL is designed for people that are general incompetent when it comes to computers, (because they have other interests), then AOL might wisely choose not to reject any mail based solely on SPF.
Incompetent users are a fact of life, and robust systems should be designed to deal gracefully also with human errors. It seems to me that while the inconvenience may be small, SPF does actually break forwarding (in terms of no longer supporting something that was once supported).
I wouldn't mind too much myself having to give advance warning to my ISP about the mail I intend to forward (and I sometimes even want such warnings from the users I serve), provided I could see the direct benefit. However, I'm not convinced SPF yields such a direct benefit, and I'm worried that changing the protocol without said benefit may set a bad precedent for the future. Every change comes with a cost, and I don't want to pay that cost, wait a few years, and learn that the benefit turned out to be zero (or even negative).
It's difficult enough explaining to our users why we should enforce existing standards (such as requiring valid return addresses on inbound mail). When one of our business partners ended up in dsn.rfc-ignorant.org for not accepting null sender returns, their mail to us resulted in an error message saying their mail server was broken. The sender knew nothing about RFC 2821 and complained to the recipient (our user). The issue was escalated, and rather than whitelist that particular business or help them fix their MTA, we decided to drop the dsn.rfc-ignorant.org check entirely because it had demonstrated a risk of blocking legit mail (I was not involved in that decision).
As you may guess, I'm not looking forward to having to explain to our users that the reason we are blocking legit mail sent to one of their addresses is that we have begun enforcing a new protocol, not mandated by the IAB, for the purpose of forcing future spammers to forge sender addresses using the domain of the abused relay rather than some random domain.
Our 200 users aren't incompetent, they just want to spend their time at the office doing other things than tweaking our highly user-configurable junk mail prevention system until their keyboards glow.
While foo.edu didn't do anything wrong, they also could make life easier for the student by implementing SRS for mail that they forward.
Implementing SRS may be as trivial as breathing, but I still want to ask who benefits from it, and who gets to pay the cost. I suppose making SRS optional for individual users is out of the question, thus the rewriting rules will apply to any forwardings or list expansions, and many users will be affected by the change, sometimes in unexpected ways. Whether the change is announced in advance or not, those who pay the cost are generally not those who enjoy the benefit of being able to forward mail to an SPF-reliant domain, and I'd say that's a pretty small benefit even to those who enjoy it.
I have considered defining SPF records for my domains for much the same purpose (making life easier for someone else), but I have so far decided not to, simply because I see no direct benefit to myself, and I even question the potential benefit to others (yes, some of our domains are regularly abused for address forgeries, and we could do without the attempted bounces from AOL and Yahoo).
Even though I agree with you that we should aim to take out the feet on which the spammers stand, I think we should also aim to pry the tools they are using out of their hands.
We may very well do both. However, we are dealing with an enemy in cyberspace, using cyberspace tools, and there is no obvious limit to the nature, diversity or quantity of tools we may find in the hands of spammers. It's a bit like the scenes in Who Framed Roger Rabbit? where the 'toon characters bring out ridiculously large amounts of weaponry and other gadgets from under their coats (toonspace has much of the same characteristics as cyberspace). It's not like we can enumerate those gadgets, take them away, lock them into a box and be done with it, even for the next few days!
Therefore, I'd be careful about spending my time and effort on a task that I can't see the end of and may well be unable to finish, especially if there are alternative approaches around. It may be a good idea to eliminate address forgery for other reasons than spamming, but then I want those reasons specified and quantified (as in, how much money would it cost us not to fix this particular problem) before I decide whether it's worth the effort.
It also might be worth mentioning that while you can attack the perpetrators as far as spam is concerned [to some extent], I think that task is more difficult when it comes to virus which spread via email. In the case of virus I believe there needs to be a larger weight placed on removing the easy-to-use tools (our email system). I believe that implementing domain keys for our current email system is a rather un-disruptive means to this end, which should be implemented.
I'm not quite following you here. Are you saying that a virus cannot propagate by means of e-mail if sender addresses have to be authenticated?
If your computer has been infected by a virus, that virus has access to all the information you store on your computer. To an outside observer, the virus effectively becomes you, unless you have a way of communicating without using your computer. You can't even type in a password on that computer and trust that the virus won't use it to its own ends, such as authenticating an e-mail message pretending to come from you.
I haven't actually seen or even heard about such an advanced virus, and it probably doesn't exist today, but there is nothing in principle that prevents it from being developed. If e-mail becomes restricted to authenticated senders only, chances are virus authors will take this into account and use the prescribed e-mail authentication routines for their distribution mechanism. It's not like computer viruses would drop dead faced with this dubious challenge.
Actually, I think virus authors may even be quicker than spammers to adapt to this environmental change, as viruses already depend on compromising the integrity of its target host, and impersonating the victim is thus conceptually nothing new. This is in contrast to spam, which may be distributed using a working open relay without actually modifying its code.
That said, I agree that the Domain Keys proposal can probably be implemented without disrupting existing communications and may well have some important benefits. I just don't want to see it justified by the war against spam, much as I don't want to see restrictions of civil liberties justified by the war against terrorism.
Nothing hurts a good cause such as a bad argument.
If the receiver check SPF and uses a non-SRS forwarder, but configures their MTA to reject mail from that forwarder, then their incompetence will result in rejected mail.
Are you saying that the receiving site that checks SPF must keep track of every MTA that forwards mail to one of their users?
Let's say that a Foo University student forwards mail from her foo.edu address to AOL. While foo.edu doesn't implement SRS, aol.comdoes implement SPF. Some Hotmail user sends mail to the student's foo.edu address, and it's forwarded to her aol.com address, no sender rewriting. AOL finds that the foo.edu MTA is not among the permitted mail servers for the hotmail.com domain and rejects the message.
Out of the five independent actors involved here (Hotmail, Foo University, AOL, sender, student), who has acted incompetently?
I would say that being able to reliably filter out spoofed mail is significant.
Whether you want to filter it out or forward it to the authorities for investigation, I agree that identifying spoofed mail is important. How does that relate to spamming?
Spoofed mail accounts for about 70% of my incoming spam/virus messages.
Today, yes. However, the proposal is to eliminate spoofed mail by reliably (and automatically) identifying forgeries. As a result, spoofed mail will in the future account for 0% of your incoming spam/virus messages. In no way will it result in spam/virus messages accounting for 0% of your incoming mail. The spammers will simply change their methods to keep spam technically indistinguishable from legit mail, just as it is today.
This does not address spammers from signing their messages, and creating a domainkey for wherever they are sending from, but it limits them to sending it from their addresses.
I believe the first spammers did use their real sender addresses since they saw no reason not to; the threat of retaliation changed that. Since there is a near-infinite supply of domain names (and thus also sender addresses), I don't see that as much of a "limitation". Makes about as much sense as limiting SMTP clients to using real IP addresses (that limitation has already been implemented, by means of TCP and unpredictable 32-bit SYN sequence numbers). Since the spammers will adapt to the changing environment, I don't see any real benefit in blacklisting thousands of domains compared to blacklisting thousands of IP networks.
I think it would go along way to stop the Joe jobs, and the popular method of virus propagation.
If spam were delivered by means of stampeding rhinos, we would spend millions of dollars on devising new forms of rhino control, while the spammers would spend much less switching to rabid geese. Eliminating Joe jobs is fine, but it won't do squat about spamming as such.
The spam phenomenon is a moving target, and it moves in order to evade your attacks. Given the sheer time it takes for your "bullet" to reach its target (deploying a new communications protocol across the Internet, on the scale of several years at least), it doesn't help a lot to know what the exact location of the target was before you even picked up your "gun".
By fighting popular methods for doing anything, all you will accomplish is making those methods less popular, in favor of other methods. This is just as true for virus propagation as for spamming. If you want to eliminate spam, aim at the perpetrators and their objectives, not at the toys they happen to use for the moment.
However, pobox.com has theirs software up an working while Yahoo only has a working document to offer proof of concept. I would like to see Yahoo's example up and running and see how it would compare once out in the wild.
While working implementations are essential, they are by no means sufficient for estimating the effects of Internet-wide adoption of the proposed solution. Therefore the quality of the theoretical discussion matters a lot too.
When e-mail was first deployed, there was hardly any spam at all, for obvious reasons. It appeared later, not because of a change of technology, but due to a change of Internet demographics. Any proposal promising to do away with spam must be scrutinized in terms of: What if everybody does it this way, will it still work?
You can't try out new traffic regulations in a laboratory, even if you have a few actual cars at your disposal.
I admit that I haven't studied the proposal in detail, but if all it does is guarantee that the sender address isn't spoofed, then it's hardly a significant improvement over the present situation.
We have the client IP address of incoming mail already, and that address is hardly ever spoofed. Is it helpful to us? No, not as long as the client ISP refuses (or is actually unable) to disclose to the recipient who was using [123.45.67.89] at that time. Are we to believe that the ISP will react differently when asked to identify the spammer behind authenticatedsender@optin.business.tld, or is there some postal address hidden in the digital signature?
And if you think sender authentication will prevent obscuring the origin by using millions of 0wned proxies, think again. Unless the authentication process requires manual intervention by the sender for each message (say, by requesting a password), all the data necessary to authenticate a sender will be found on the machine at risk of being 0wned. Instead of seeing junk from moremoney@hotmail.com via your neighbour's IP address, you will see junk from your neighbour's authenticated e-mail address via your neighbour's IP address.
If all e-mail is required to come with a valid sender address, all spam will come with a valid sender address too, and we are back at square one.
When I first saw the article on Slashdot, I was tempted to stop buying those AXA breakfast cereals because of this litigation. Then I looked closer, and found that there is also an insurance company by the very same name! I had never heard about them before.
The AXA brand name is owned by Cerealia Foods, operating from Scandinavia. Maybe Cerealia Foods should join AXA (insurance) in their lawsuit against Google, to prevent other breakfast insurance companies from registering their unique name?
After giving it some thought, I come to the conclusion that the "blocking" need not refer to Internet traffic, but to administrative action against companies establishing themselves in Sweden, requiring them not to transfer customer data to countries outside the European Union. Such action may indeed be taken, and rightly so in my opinion.
Earlier on Slashdot, we have discussed German government efforts to block German Internet users from accessing certain websites abroad, and perhaps I was reading the passage in that context...
The UK Data Protection Act requires that personal information be purged if the person in question requests it.
You mean I can first agree to Google's terms allowing indefinite storage of my mail, but later change my mind and say that they must delete it, irrespective of what I first allowed them to do, just because the law says I cannot agree to indefinite storage?
If that's the law, then the law is in need of a good spanking. I understand that some rights are inalienable, such as freedom from slavery, but I don't consider physical destruction of all e-mail I have ever received to be an inalienable right, or I wouldn't be able to ever voluntarily hand over a copy of a single letter of mine to anybody else, not even to my own children.
What if I allow a journalist to interview me and publish my personal thoughts on some matter, then change my mind when the article eventually appears in print? Can I ask the newspaper to retract the edition? Are public libraries (and others who routinely archive papers they receive) forced to destroy their copies, upon my request? Of course not. I once gave permission to publish; I cannot retract that after publication has taken place, not even if my lawyer says I can.
Slashdot Mirror
Why, he invented, created, authored the thing, it seems to mean just the same (intellectual property you know, there is no significant difference between an invention and a work of art).
What would you think if Al Gore claimed to have written the Internet? Would that make any more sense?
However, Katu News doesn't tell who invented that news item either, only that it came via Associated Press. Maybe this particular news item is a bit short for a patentable invention, but it never hurts to provide some credit to the guy behind it...
Correct, the identity of the true copyright holder is in doubt. However, that doesn't mean Sun can do as they please with the Unix code in question; they still need approval from the copyright holder if they intend to change the licensing terms for anything that includes Unix code.
I seem to recall Novell has publicly exonerated IBM from allegations of copyright infringement made by SCO (pointing to provisions in their agreement with SCO allowing Novell to act on behalf of SCO, no less), but has Novell spoken out on the issue of others using Unix code in any way they see fit? Does Sun have a license from Novell too, just in case?
Since I don't have any actual SCO code myself, I'm tempted to write some code of my own and assign it to SCO, just to be able to distribute it without their permission. As if they would care.
It obviously depends on your jurisdiction, and I don't know which countries have enacted legislation like this, although there is certainly talk about increased logging for law enforcement purposes. In Sweden, public entities such as government agencies and universities are required to log pretty much any transactions with others and to retain those logs for at least two years, so if you see suspicious traffic from a Swedish university IP address, inquiring about it is a good idea (I work at a university). Perhaps the logs aren't always there when you want them, but if we do have any logs left, we are required by law to either provide the information sought or justify (in writing) why we cannot provide it.
Private corporations, such as your average ISP, operate under a less rigorous set of rules in Sweden, and they need to maintain logs primarily for billing purposes and to otherwise fulfil their committments towards their own customers only, normally for a couple of months. I'm sure they have some obligations towards law enforcement as well, but I don't know what those amount to.
One problem I see with enacting far-reaching legislation for what an ISP must log and for how long is, what constitutes an ISP? If I set up a free e-mail forwarding service, sponsored by advertising, does that make me an ISP even when my customers are not identical with the users of the site? I may even be the only user myself; would I have to log my own e-mail?
It doesn't matter too much whether there is a law or the ISP maintains logs of its own free will. Maintaining adequate logs is a matter of good security measures to me, and an ISP systematically failing to keep any logs would be enough for me to block traffic from said ISP.
I'm not out to do the job of law enforcement; I'm interested in protecting my property, and if my neighbour refuses to help me find out who crossed his lawn to break into my house, I'll put up a higher fence between the two of us. I don't require him to put up surveillance cameras on his driveway, but if he does nothing to keep burglars away from our common premises, I won't exactly invite him to dinner at my house. Why can't the same standard of cooperation be upheld on the Internet?
In what jurisdiction? I mentioned the cross-border situation for a particular reason (I'm not located in the United States). Don't you think I could file a civil lawsuit against someone involved in causing harm to my property, just because the harm was done by means of a computer and there is a criminal statue against computer intrusion? What about DDoS attacks that cause harm without being criminalized?
I agree with the original poster that the RIAA should not utilize criminal law enforcement resources to obtain evidence for the purpose of civil litigation, but are you saying that they do precisely that? Then who is wearing the wrong hat, me or the RIAA?
Whether the case is civil or criminal, asking for anonymity and exoneration (i.e. recognition that you did nothing wrong) at the same time doesn't work. Anonymity may shield you from litigation, but increases suspicion and encourages potential litigants to seek alternative means of action rather than "pound sand". Right or wrong, the end result isn't necessarily prettier or better for everyone involved.
"I'm Spartacus!"
That would create a legal loophole big enough to drive even SCO through it. Or perhaps, we already suffer from such a loophole. When my computer is attacked by an appearant intruder at 66.35.250.150 (using the IP from your example; I don't recall seeing it before), I conclude that someone is responsible for the intrusion. I contact the ISP to find out who, but they won't tell without a court order. Going through the paperwork to obtain a court order, especially across national borders, is something I'd like to avoid, so I'd rather sue the ISP for their involvement and let them sort it out with their customer if they want.
By requiring me to know the name and residential address of the real perpetrator before I can take any kind of legal action against them, I'm effectively prohibited from taking action against either the perpetrator (because he is anonymous) or the ISP acting as his front (because they can correctly claim that they acted on behalf of their customer only and uphold his anonymity).
I don't like being on the same side as the RIAA, and I feel their lawsuit campaign does infringe on the rights and freedoms of individuals, but it's not because those are "John Doe" lawsuits. The combined claims of "I did nothing wrong" and "I have the right to be anonymous and immune against legal action even in case of suspected wrongdoing" sound a bit hypocritical to me. I'd rather request to defend my actions in court, if I had the opportunity. If you don't trust your legal system to be fair to you, don't ask that same legal system for protection against said infairness, but ask someone else.
The appreciation is mutual.
I tried accessing your website, but it appears both your name servers (ns.globalwebpromotions.com [69.31.33.254] and ns2.globalwebpromotions.com [69.31.33.253]) are inaccessible right now. Back in the old days (early 1990's) connectivity was generally worse, and we made a bit more of an effort to set up several name servers on different networks, for backup.
Gradually, those efforts became regarded as unnecessary. Today, connectivity is generally better, but when a link goes down for whatever reason, it all too often happens that a number of domains go down with it.
It doesn't matter how much disk space you have, and I wasn't commenting on it. I was commenting on how much data you expect "some other company" to store in order to delegate a domain to your server. Again, you said:
If the domain 256bytename.com is assigned to you, the root server only needs to know that "com" is handled by the .COM server, and the .COM server needs to know that "256bytename" is handled by your server. Regardless of whether you have a name server of your own or use the services of some ISP, the .COM server still has to remember "256bytename".
If we implement a flat namespace instead and forget about the .COM level, all that happens is that the root server is now required to keep track of the "256bytename" and where your name server is located. The root server has to do the same for every other domain out there. They may well have 10 TB of disk space for that purpose, but someone has to pay for it, and that someone is you, the domain owner. You cannot avoid that cost by setting up a server of your own with 10 TB of disk, because everybody will still ask the one and only root server where your domain is. That's why your suggestion "use your own root server" sounds nonsensical to me.
I'm not saying that it's impossible to implement a flat namespace, only impractical given the benefits of a hierarchical namespace. With a flat namespace, you can't subdelegate; instead you will have to pay the root server administrators for every single domain you want. If you have hundreds of workstations, a handful of servers, a dozen printers and a few other gizmos on your office LAN, do you really want to pay Verisign $10 annually for each connected unit?
A flat namespace is not at all alien to the Internet; we had that 20 years ago, and maintaining a central list of all the hosts (the SRI-NIC HOSTS.TXT file) was an administrative nightmare already with a few thousand hosts only. That's why the DNS was introduced, allowing us to delegate entire branches of the namespace to different organizations, so you no longer had to contact SRI-NIC to connect annother server to your office LAN. Maybe you don't need to advertise every single host to the world, but you still need a way to reserve its name for your own use only.
Speaking of which... Google never forgets!
This isn't exactly about tech support (which I seldom call anyway), but here is a story from a long gone past:
In 1987, our university department had moved to a new building, and a 10base5 ethernet (yellow coax) divided into five segments had been installed to serve offices and labs on six floors. Since we brought with us a few hundred DEC VT100 terminals, we had maybe 40 Ungermann-Bass NIU-180 terminal servers (eight RS-232 ports each) distributed throughout the building, booted with software downloaded from a dedicated IBM PC.
The Ungermann-Bass TCP/IP software was still only in beta state when it was delivered to us, something I wasn't quite aware of from the start but learned the hard way. Occasionally the terminal servers would simply hang for no obvious reason, requiring us to reset them manually. This was a bit tedious (six floors, remember), and I tried unsuccessfully to find the cause by analyzing network traffic using two SpiderMonitors.
Then one day our DEC Field Service engineer arrived to install the NIA20 ethernet interfaces we had acquired for our two DEC-2060 systems. The installation procedure involved extensive testing of the equipment, some of it when connected to the ethernet, and I could see lots of funny packets with different protocol types (including ISO packets using the 802.3 protocol type field for packet length) scrolling by on the SpiderMonitor.
Minutes later I found out that pretty much every NIU-180 terminal server was now hung. Time for another walk through the building.
Given that we also had HP workstations using ISO encapsulation of IP packets on our network, I began to suspect that the NIU-180 TCP/IP software was sensitive to ethernet packets of (to it) unknown types, because the failures seemed to correlate rather well with the use of those workstations. I never made any conclusive tests to verify my theory, though.
Some time later I visited the Ungermann-Bass representatives in Stockholm to tell them what we thought of their product so far, and I mentioned the annoying hangings and my theory about what triggered them, including the "bad" test packets from the DEC-2060 systems.
"But then the fault obviously is with that other system, not with our terminal servers, right?"
I nearly began explaining at length what I had learned a few years earlier about fault tolerance in data communication protocols, but I realized I was dealing with sales people, not tech support, and rested my case. Some time later, we replaced the beta version with the official release of their TCP/IP software, and the problem was gone.
Their website may be painted by Michelangelo and their ads written by Shakespeare; what counts is whether they send unsolicited advertising or not. If that unsubscribe link is useful for anything besides unsubscribing from something you voluntarily and knowingly subscribed to, they are spammers. Do they have a corresponding subscribe link on every page too, allowing you to subscribe to every OptInBig message, before you unsubscribe from them?
You are joking, right? Or are you trying to say that everyone should have their own root server, each holding a single 256-byte domain name only? It's like saying you don't need a centrally maintained telephone directory listing thousands of subscribers; you can maintain your own entry and never call anybody else.
In my imagination, tree structures are among the essentials in life. Our imaginations are different, and would conflict with each other if used as a basis for changing reality. Do you still believe both of us can have it our way?
What problem are you calling a non-issue? Tim Berners-Lee isn't trying to make the DNS resolve trademark disputes; he wants the DNS to resolve names into numbers and other data, to serve a technical rather than legal purpose. In his plea to ICANN, he argues that the proposed new TLDs are poorly motivated, and that their introduction makes for increased costs and confusion to everybody on the Internet.
The first TLDs were defined as a very general classification of the entities named under them, such as whether it was a government or business entity. That classification remains, although it has been confused by registrations not adhering to it, such as websites under .NET not affiliated with any particular network operator.
If ICANN were to allow anybody to register their own TLDs (requiring uniqueness of the name only), we would effectively be back to the flat namespace we had before the DNS, although this time with potentially millions of domains rather than just a few thousand. Besides, I doubt the root name servers would stand the load. Maybe they could be redesigned, but I don't see the cost of doing it motivated by the dubious benefit of having a "kodak" domain where before we had "kodak.com".
Regardless of what kind of image SCO tried to paint in their press releases, the lawsuit against AutoZone appeared to be about AutoZone using other software actually belonging to SCO on a Linux host, not about AutoZone using Linux. If so, the outcome in the IBM case will have no effect on the AutoZone case, although SCO may decide to drop also the AutoZone lawsuit for other reasons (such as lack of sustained funding combined with losing the media campaign).
Yes, but they are asking to receive it from the FSF, which is the most significant limit of their request (since the subpoena has to be aimed at a specified person or entity, that is also a mandatory limit). Considering that the FSF was founded for the very purpose of supporting development of free software, it's hard to imagine they have anything important that is not implied by this broad request.
I doubt I will ever be asked to provide documentation in this fashion, but I try to minimize the amount of confidential information I receive in matters not concerning immediate family and friends. I like talking to others about issues of interest to me, and I don't want to waste my time absorbing information that I can't pass on to others as I see fit (I'm not Dave Null). Why fill up disk drives, book shelves and my own brain with stuff that will be destroyed anyway when I die?
Still, the information I have is not organized well enough for me to be able to provide whatever may be asked for, and I think lack of a complete index or diary is also the most important reason for the FSF to be restrictive about what they will provide in response to the subpoena. Confidentiality of correspondance sounds like a relatively minor problem; they actually need to know more specifically what is being asked for and whether they do have it before they can argue that it's confidential.
Computer scientology? Windowism? Buggism?
I think similar stunts may have been tried before, just look around you...
A handheld authentication device, that sounds pretty much like a pen to me...
g -it-secure talking just confuses the issue. Spammers are already running in circles around our ideas; there is no point in us trying to chase them in the same circles. Better concentrate on what they keep stealing from us, and make sure to get it back: Our time and money.
But I agree that what you describe is probably what's needed if the general public is ever to enjoy the benefits of digital signatures. Some vendors may for a couple of years be able to maintain the notion that user authentication can be achieved on generic PC hardware, but I can't imagine a court of law upholding that view once a user is hit by a virus that finds his key and messes with his personal bank account. The sooner this happens, the better for the rest of us.
I have so far refused to obtain any kind of digital ID for my private use, be it for my bank or for filing my income tax declaration, because I lack the necessary equipment to maintain a clear and visible level of security. No way am I going to give Redmond even indirect access to my bank account by placing critical keys on a Windows system! Of course, a Linux system wouldn't be acceptable either, due to its complexity.
Thus a separate device is needed, and I expect the design to be open to public inspection (no security through obscurity, please).
But to get back to the original subject: All this fighting-spam-by-changing-the-protocol-and-callin
Incompetent users are a fact of life, and robust systems should be designed to deal gracefully also with human errors. It seems to me that while the inconvenience may be small, SPF does actually break forwarding (in terms of no longer supporting something that was once supported).
I wouldn't mind too much myself having to give advance warning to my ISP about the mail I intend to forward (and I sometimes even want such warnings from the users I serve), provided I could see the direct benefit. However, I'm not convinced SPF yields such a direct benefit, and I'm worried that changing the protocol without said benefit may set a bad precedent for the future. Every change comes with a cost, and I don't want to pay that cost, wait a few years, and learn that the benefit turned out to be zero (or even negative).
It's difficult enough explaining to our users why we should enforce existing standards (such as requiring valid return addresses on inbound mail). When one of our business partners ended up in dsn.rfc-ignorant.org for not accepting null sender returns, their mail to us resulted in an error message saying their mail server was broken. The sender knew nothing about RFC 2821 and complained to the recipient (our user). The issue was escalated, and rather than whitelist that particular business or help them fix their MTA, we decided to drop the dsn.rfc-ignorant.org check entirely because it had demonstrated a risk of blocking legit mail (I was not involved in that decision).
As you may guess, I'm not looking forward to having to explain to our users that the reason we are blocking legit mail sent to one of their addresses is that we have begun enforcing a new protocol, not mandated by the IAB, for the purpose of forcing future spammers to forge sender addresses using the domain of the abused relay rather than some random domain.
Our 200 users aren't incompetent, they just want to spend their time at the office doing other things than tweaking our highly user-configurable junk mail prevention system until their keyboards glow.
Implementing SRS may be as trivial as breathing, but I still want to ask who benefits from it, and who gets to pay the cost. I suppose making SRS optional for individual users is out of the question, thus the rewriting rules will apply to any forwardings or list expansions, and many users will be affected by the change, sometimes in unexpected ways. Whether the change is announced in advance or not, those who pay the cost are generally not those who enjoy the benefit of being able to forward mail to an SPF-reliant domain, and I'd say that's a pretty small benefit even to those who enjoy it.
I have considered defining SPF records for my domains for much the same purpose (making life easier for someone else), but I have so far decided not to, simply because I see no direct benefit to myself, and I even question the potential benefit to others (yes, some of our domains are regularly abused for address forgeries, and we could do without the attempted bounces from AOL and Yahoo).
I'm happy that I'm making myself understood...
We may very well do both. However, we are dealing with an enemy in cyberspace, using cyberspace tools, and there is no obvious limit to the nature, diversity or quantity of tools we may find in the hands of spammers. It's a bit like the scenes in Who Framed Roger Rabbit? where the 'toon characters bring out ridiculously large amounts of weaponry and other gadgets from under their coats (toonspace has much of the same characteristics as cyberspace). It's not like we can enumerate those gadgets, take them away, lock them into a box and be done with it, even for the next few days!
Therefore, I'd be careful about spending my time and effort on a task that I can't see the end of and may well be unable to finish, especially if there are alternative approaches around. It may be a good idea to eliminate address forgery for other reasons than spamming, but then I want those reasons specified and quantified (as in, how much money would it cost us not to fix this particular problem) before I decide whether it's worth the effort.
I'm not quite following you here. Are you saying that a virus cannot propagate by means of e-mail if sender addresses have to be authenticated?
If your computer has been infected by a virus, that virus has access to all the information you store on your computer. To an outside observer, the virus effectively becomes you, unless you have a way of communicating without using your computer. You can't even type in a password on that computer and trust that the virus won't use it to its own ends, such as authenticating an e-mail message pretending to come from you.
I haven't actually seen or even heard about such an advanced virus, and it probably doesn't exist today, but there is nothing in principle that prevents it from being developed. If e-mail becomes restricted to authenticated senders only, chances are virus authors will take this into account and use the prescribed e-mail authentication routines for their distribution mechanism. It's not like computer viruses would drop dead faced with this dubious challenge.
Actually, I think virus authors may even be quicker than spammers to adapt to this environmental change, as viruses already depend on compromising the integrity of its target host, and impersonating the victim is thus conceptually nothing new. This is in contrast to spam, which may be distributed using a working open relay without actually modifying its code.
That said, I agree that the Domain Keys proposal can probably be implemented without disrupting existing communications and may well have some important benefits. I just don't want to see it justified by the war against spam, much as I don't want to see restrictions of civil liberties justified by the war against terrorism.
Nothing hurts a good cause such as a bad argument.
Are you saying that the receiving site that checks SPF must keep track of every MTA that forwards mail to one of their users?
Let's say that a Foo University student forwards mail from her foo.edu address to AOL. While foo.edu doesn't implement SRS, aol.com does implement SPF. Some Hotmail user sends mail to the student's foo.edu address, and it's forwarded to her aol.com address, no sender rewriting. AOL finds that the foo.edu MTA is not among the permitted mail servers for the hotmail.com domain and rejects the message.
Out of the five independent actors involved here (Hotmail, Foo University, AOL, sender, student), who has acted incompetently?
Whether you want to filter it out or forward it to the authorities for investigation, I agree that identifying spoofed mail is important. How does that relate to spamming?
Today, yes. However, the proposal is to eliminate spoofed mail by reliably (and automatically) identifying forgeries. As a result, spoofed mail will in the future account for 0% of your incoming spam/virus messages. In no way will it result in spam/virus messages accounting for 0% of your incoming mail. The spammers will simply change their methods to keep spam technically indistinguishable from legit mail, just as it is today.
I believe the first spammers did use their real sender addresses since they saw no reason not to; the threat of retaliation changed that. Since there is a near-infinite supply of domain names (and thus also sender addresses), I don't see that as much of a "limitation". Makes about as much sense as limiting SMTP clients to using real IP addresses (that limitation has already been implemented, by means of TCP and unpredictable 32-bit SYN sequence numbers). Since the spammers will adapt to the changing environment, I don't see any real benefit in blacklisting thousands of domains compared to blacklisting thousands of IP networks.
If spam were delivered by means of stampeding rhinos, we would spend millions of dollars on devising new forms of rhino control, while the spammers would spend much less switching to rabid geese. Eliminating Joe jobs is fine, but it won't do squat about spamming as such.
The spam phenomenon is a moving target, and it moves in order to evade your attacks. Given the sheer time it takes for your "bullet" to reach its target (deploying a new communications protocol across the Internet, on the scale of several years at least), it doesn't help a lot to know what the exact location of the target was before you even picked up your "gun".
By fighting popular methods for doing anything, all you will accomplish is making those methods less popular, in favor of other methods. This is just as true for virus propagation as for spamming. If you want to eliminate spam, aim at the perpetrators and their objectives, not at the toys they happen to use for the moment.
While working implementations are essential, they are by no means sufficient for estimating the effects of Internet-wide adoption of the proposed solution. Therefore the quality of the theoretical discussion matters a lot too.
When e-mail was first deployed, there was hardly any spam at all, for obvious reasons. It appeared later, not because of a change of technology, but due to a change of Internet demographics. Any proposal promising to do away with spam must be scrutinized in terms of: What if everybody does it this way, will it still work?
You can't try out new traffic regulations in a laboratory, even if you have a few actual cars at your disposal.
I admit that I haven't studied the proposal in detail, but if all it does is guarantee that the sender address isn't spoofed, then it's hardly a significant improvement over the present situation.
We have the client IP address of incoming mail already, and that address is hardly ever spoofed. Is it helpful to us? No, not as long as the client ISP refuses (or is actually unable) to disclose to the recipient who was using [123.45.67.89] at that time. Are we to believe that the ISP will react differently when asked to identify the spammer behind authenticatedsender@optin.business.tld, or is there some postal address hidden in the digital signature?
And if you think sender authentication will prevent obscuring the origin by using millions of 0wned proxies, think again. Unless the authentication process requires manual intervention by the sender for each message (say, by requesting a password), all the data necessary to authenticate a sender will be found on the machine at risk of being 0wned. Instead of seeing junk from moremoney@hotmail.com via your neighbour's IP address, you will see junk from your neighbour's authenticated e-mail address via your neighbour's IP address.
If all e-mail is required to come with a valid sender address, all spam will come with a valid sender address too, and we are back at square one.
The same goes for SPF.
When I first saw the article on Slashdot, I was tempted to stop buying those AXA breakfast cereals because of this litigation. Then I looked closer, and found that there is also an insurance company by the very same name! I had never heard about them before.
The AXA brand name is owned by Cerealia Foods, operating from Scandinavia. Maybe Cerealia Foods should join AXA (insurance) in their lawsuit against Google, to prevent other breakfast insurance companies from registering their unique name?
After giving it some thought, I come to the conclusion that the "blocking" need not refer to Internet traffic, but to administrative action against companies establishing themselves in Sweden, requiring them not to transfer customer data to countries outside the European Union. Such action may indeed be taken, and rightly so in my opinion.
Earlier on Slashdot, we have discussed German government efforts to block German Internet users from accessing certain websites abroad, and perhaps I was reading the passage in that context...
You mean I can first agree to Google's terms allowing indefinite storage of my mail, but later change my mind and say that they must delete it, irrespective of what I first allowed them to do, just because the law says I cannot agree to indefinite storage?
If that's the law, then the law is in need of a good spanking. I understand that some rights are inalienable, such as freedom from slavery, but I don't consider physical destruction of all e-mail I have ever received to be an inalienable right, or I wouldn't be able to ever voluntarily hand over a copy of a single letter of mine to anybody else, not even to my own children.
What if I allow a journalist to interview me and publish my personal thoughts on some matter, then change my mind when the article eventually appears in print? Can I ask the newspaper to retract the edition? Are public libraries (and others who routinely archive papers they receive) forced to destroy their copies, upon my request? Of course not. I once gave permission to publish; I cannot retract that after publication has taken place, not even if my lawyer says I can.