With monthly financial risk = (P*C)/T, if each month you put away 1.483 cents, you would on average have enough money to pay your settlement fees by the time you were sued.
It's less than that. You're forgetting about interest compounding.
What if you *didn't* hire a lawyer. You just showed up in court and muddled through it? Surely there's no law against representing yourself? And without seized hard drives, it seems like the RIAA would be at a bit of a loss to prove that *you*, and not someone else that used your computer, was the person at fault. Come to think of it...are there independent logs other than those from a RIAA-sponsored P2P logging agency? I doubt it. I wonder what it would take to argue against them.
If 1k people did that, the RIAA would *never* have the legal resources to handle the situation.
This flood of names with very strong reasons to encourage companies to buy another domain name ("You're an adult entertainment company, but you *haven't* voluntarily gone under the.xxx TLD?" "You mean you let someone *else* buy the ford.biz domain?" etc) just reinforces my opinion that ICANN has become a whore to the name registrars. The idea of ICANN is that they make good engineering decisions for the Internet at large, not decisions based on how to maximize name registrar profits.
Yes, because non-root users can install software that starts at boot-time. Oh wait. No.
This is also the case on Windows. On both Linux and Windows, it is possible to run *once that user logs in* or install systemwide *if the root account is used for installation*. If a box stays up for a while, you can just *keep* running after a non-root user logs off.
And even then, your mom's dumb spyware won't affect your account. Processes running as one user can't see another user's data. Oh no. Spyware stopped by good design.
Actually, (frusteratingly) Linux does not currently provide restricted/proc functionality out of box. So processes do have an extensive degree of access to stuff running as other users, even if there are some benefits to Linux. Suppose I want to see what websites are being accessed by the current user of the machine (who may not be the user who I am running as). I run lsof and search for remote connections to port 80.
You'd have to save your X session every time, or just add the spyware to.xsession if you'd like that to happen. And I don't see myself doing that.
No, the spyware would. Most Windows users don't explicitly add spyware to their Startup folder. Or maybe it would go in your.bashrc. Or.bash_login. Or God knows what.
Windows is insecure by design. Stop thinking that because everyone uses Windows it has lots of viruses and spyware. It's ALSO because it's very poorly designed. Sad but true.
Windows isn't perfectly written. Neither is Linux. Windows' primary architectural problems (IMHO) come from the integrated MSIE, which is very difficult to regulate and provides functionality to many applications, and from the fact that the "GUI" is so fundamental to the system, exposing vulnerabilities like the one to the "shatter" attacks. Windows is not simply massively poorly designed WRT security. The kernel is actually pretty solid. Windows has its problems, but it's not as if the "everyone uses Windows and those users aren't generally technically competent" argument isn't a dominant one.
Well...I'm really not an FSF/RMS nut. I don't like the GNU/ prefix.
The problem is that the first acronym I tried using was "OS" for "Open Source". Problem is, that acronym is already commonly used to refer to an OS.
Then I tried "OSS". Well, that's dandy, except under Linux that refers to the standard sound driver system (now being phased out in favor of ALSA).
So, finally I started using FOSS. A couple of people like FLOSS (adding a "libre" in) which is also okay but requires another letter, and really, nobody confuses "FOSS" with anything but "FOSS". The "libre" is unnecessary.
The whole point is taking the distro and auto-config utils out of the equasion (e.g. ftp on by default) so you can build a secure services box and know exactly what is on it and what its purpose is. If something is insecure, it's your fault, not the fault of some distro organization who turned something on by default.
The problem I have is that currently, you really have to know your stuff WRT security to set up a secure server and no matter what, there are going to be a lot of people who don't setting up important servers.
Microsoft got together with the US government to put out a list of common misconfigurations, a sort of checklist for Windows. Sure, a Windows security guru probably doesn't need it, but *most* Windows boxes aren't set up by "security gurus". Same goes for UNIX, even if the average degree of security cluefullness might be slightly higher. There are a *lot* of things you have to know, a lot of unintuitive potential issues, and there *are* going to be people running into this.
Take screen locking for a local issue. RH and most distros provide a screensaver in X. This screensaver can provide password protection. A *lot* of people out there just assume "oh, the screensaver is running with passwords on, so nobody can get into my desktop". New Linux users often don't know that you can switch out of an X to a console, and like to start X using startx. Result? They leave something crucial on their system (which is "locked") and someone can, in a moment, walk in, switch to a virtual console, tap ^Z, and do whatever they want.
The concept of "single user mode" is not familiar to a lot of Windows admins. "But it's...*password* protected!" Microsoft has gone out of their way to *avoid* providing a way to boot into Windows from a CD, so most Windows admins w/o much security experience consider someone with local access (esp. in a lab or with a secured case somewhere that they cannot easily physically open the case and get at the drives) to be seriously inconvenienced by the Windows password. Show them that their Linux box can be booted into "single user mode" in a couple of seconds by anyone with physical access to the console, and they get this shocked look on their face. Why not? It's not intuitive to someone with their experiences. Software that must be secure or may be destructive must be intuitive. People are pretty careful to at least provide safeguards and warnings on potentially destructive software, but no such culture exists around security. For many people, it's a set of knowledge picked up by hits and tips over time. That doesn't work. It's not as if mucking up a configuration and opening a hole on a major server is like running a longer command line to locate a piece of text in a file because you don't know the "quickest way"...you have to do things *right* the first time.
Take reverse compromise from a box that uses SSH X11 tunnelling. I know a couple people that *religiously* *never* bounce through any box other than a set of trusted ones when sshing from one machine to another -- they open a new, direct connection from their original computer. Why? So that nobody compromising a second computer can grab their passwod if that computer is compromised. Problem is, they have X11 tunneling enabled by default to the first of two machines. So when they SSH in, they aren't just opening a little terminal window to that machine, where only giving that terminal focus and hitting a key exposes data, but letting that machine log their local keystrokes, dump their screen contents, do really whatever it wants.
I've found a lot of unintutive things in Linux security over the years. Moving directories is a good one. The kernel only does security checking when traversing between two directories. It doesn't check the whole path to see whether you have access to the directories or not. I had a friend using an FTP server on my computer. I moved a directory from his home directory to my home directory. He happened to be in that d
Yes, it is a troll. However, seriously, what benefits would running this on a different OS provide? I'd say that the likelihood of this being a kernel bug are pretty low...
There have been serveral major, high profile compromises of numerous FOSS servers in the past twelve months. Including a compromise of the GNU source repository.
Microsoft has not made a big deal out of these (at least as far as I've seen). Whereas every security flaw at Microsoft is treated by Slashdot as if someone got access to the crown jewels (well, admittedly the Windows source is running around all over the place...)
Microsoft has really been acting a lot nicer towards FOSS folks about security lapses.
That being said, I'm just *waiting* for a sourceforge compromise. That would be a *huge* hit, and it just plain has to happen sooner or later.
It would be nice if a couple of distributions put out basic *up-to-date* HOWTOs of best practices on how to set up minimal, secure servers using their distribution.
Well...I suppose that if this is a new vulnerability, it's better that they go after a high-profile webserver with a good admin team that can catch the attack than that they attack many poorly-adminned ones.
Maybe not carbon based like we are; but (if you believe in them) life at any rate; since they are supposedly intelligent beings?
IIRC (and honestly, precise points of dogma are not a strong point), angels (at least in the Lutheran interpretation that I've heard) are not free-willed.
Of course, that does make one wonder about Lucifer...
What does this buy me that widely-adopted SPF plus DNS blacklisting doesn't, from a spam-prevention perspective?
* A secure transport. A lot of these systems depend upon DNS for data transport currently, without adding any kind of security to said system. DNS is attackable.
* Flexibility. If someone needs to make a cert associated with two email addresses, such a system could support this.
* Decentralization. I'm comfortable with the statement that a PKI and trust system could be implemented without relying on a single potentially evil (*cough* VeriSign) source.
* Major side security benefits. PKI has major security benefits -- you roll it out and it's also easy to do end-to-end encryption of your email. Businesses need email encryption yesterday, anyway.
* Separation of entity from email address. Suppose I am Linus Torvalds and have a home address and a (new) work address. Many people trust Linus Torvalds -- he isn't going to run out and start spamming. The problem is that his *work* identity is totally different from the POV of SPF or similar systems. With PKI and trust, Linus could trust his work address's cert with his home address's cert (or possibly even just resue the cert, depending upon the system).
* Entity-level trust. I can trust a single person without having to say "if it comes from this organization's mail server, it must be good". SPF might let me know that an email came from the right mail server from the domain, but doesn't let me know that the email isn't forged -- if someone manages to compromise a single computer at IBM, my only option with most non-PKI systems is to distrust all email from the IBM domain, since they can send email "from" anyone. Entity-level trust is important to allow breaks (and any system *will* break -- if you compromise someone's system, it's hard for others to tell you from that person) to be isolated -- if my machine gets taken over and people forge email from me, the only person that email stops coming from as a couple people start marking the email as spam is me. My coworker in the next cubicle is unaffected.
* Traditional blacklisting doesn't scale to the internet. Binary "I trust" or "I don't trust" systems are just don't make sense on something the size of the Internet. Trust networks are a fuzzy form of whitelisting. As you build up associations with people, you build up trust (and yes, establishing a new trusted identity is going to be a pain at first). The reason traditional binary blacklisting doesn't work is that you have to start out whitelisted by default.
In fact, if a trusted PKI signing authority turns evil and starts issuing certs to spammers (or just refusing to revoke spammer certificates), wouldn't you be slighly worse off than you would be with SPF + DNSBL?
No. Binary trust probably wouldn't work at such a scale, for exactly the reason you just cited -- getting something to slip through the cracks is too easy. You need to have A trust signing authority B and email sender C, etc. Then just make the trust system really easy to use, tying that "spam" button in mozilla to the trust network.
It's just that if all email is signed and it takes a bit of doing to obtain a cert and ensure that enough people trust it, you can reasonably have a trust value assigned to any of the signing authorities as well, and have trust levels backpropagate.
Again, such a system is a pain in the ass to roll out. I just haven't seen anything else that handles this.
They're throwing out updates as soon as they get them because, really, this is so far beyond anyone's expectations that we're really floored.
The big deal is that if we really do find life that evolved separately from terran life, it throws a *huge* quandary for some philosophies and a lot of world religion, besides being a major psychological breakthrough for science. And the signs look *awfully* good.
Besides, NASA had a lot of bad press from Columbia, and they're hungry to be able to give good news.
And, really, aren't you even a little bit excited.
a) While I agree that it has been made impressively difficult to locate non-evil Divx codecs for Windows (thought not as bad as trying to obtain the free RealPlayer for Windows), it can be done.
b) Install said spyware, remove said spyware with Ad-Aware. Ugly, but it works.
c) Use Mplayer on Linux. While I agree that this is certainly not a "quick fix" solution, it *is* terribly nice in the long run.
As an interesting note -- ultimately, as Linux catches on, spyware for Linux will begin to appear. At that point, the value of distributor-packaged software will rise, so Red Hat, SuSE, etc may be able to make more money. Actually, it would be a good idea for distros to start making policies on applications with spyware *now*, because it will come up. Is Debian going to have an "adware" section, or simply ban evil software?
Unless, of course, you are friends or secret business partners with a congressman, in which case you may be getting a few million in grants to study the rate that ketchup flows.
I'd say that, while that does seem quite inconsequential, at one point we thought that the flow of molasses couldn't be all that crucial either, until the lives of 21 people depended upon it.
and the following philosophical objections may also apply: (x) Countermeasures should not be a profit center for a single corporation.
After VeriSign, I'd like less corporate involvement in the Internet's structure, thank you. It sounds good, people promise to do the right thing, and in the end, everything is sacrificed in the name of short-term profits. I do not want a.mail registrar with a razor blade to the Internet's wrist and demands from stockholders.
Okay, I'm dubious about the legal stuff you want to do. There are a *lot* of implications of doing something like that, including privacy issues.
However, you have one point absolutely dead-on accurate. If you want to do any kind of server-side filtering, if there is any proposal to do so, *users* should have the ability to set this filter. Server-side filtering (as opposed to client-side) has a lot of benefits -- it means that clients don't have to be maintained, that users can easily switch clients, server-to-client bandwidth is saved, etc. However, it's *tremendously* frusterating when a server operator chooses to block something that a user specifically knows he needs.
Even if a good antispam system is put in place, it makes a *lot* of sense to let users have some kind of protocol, some set of extensions to SMTP, that let them alter server-side filtering associated with their mailbox. Maybe even expose a series of complex presets that the server can provide (SpamAssassin, block Asian-originating email, etc), and let the client enable them on his account. Provide an idiot-proof GUI to interoperate with this, and you're gold.
The main issues would be added server complexity and processing load.
It seems to me on a quick skim to have all the same flaws that SPF does. Additionally, the cynic in me can't help but think that this is rather likely to have been pushed by domain name registrars, as it means that they can charge money per registration.
Ultimately, I've yet to see a long-term-workable antispam solution proposed that doesn't involve the use of PKI and a trust system of some sort (probably transparent). Yes, it's a pain to roll out, but it's going to have to be done eventually.
...and I'm sure there will be lots of negative posts about NASA here...
It'd be nice to give some credit for the people that have put in layer upon layer upon layer of safeguards to check for exactly this sort of thing and the dilligent people that find this stuff. And caught it.
The awful thing is that this is going to be just another reason for Congress to loot the NASA money bag.
Western developers' insistence that software development is some kind of magic that cannot even be remotely predicted or estimated. Nonsense!
I would be interested in hearing any links to resources that you have found really, honestly valuable when it comes to predicting time of a project, how many lines of code are involved. So far, software engineering books seem to be full of buzzwords and short on actual useful content, and I've seen only very vague rules of thumb from people that predict project time estimates.
I can understand predicting the time to build a building. All the operations that must be performed are known roughly in advance -- laying a brick is a simple, repetitive operation, and determining the time to lay a thousand bricks is hence fairly simple. Determining the time to finish a project just seems...an almost incredible art.
Businessmen have been trained to use specific management techniques and some simple models ("this task depends on that, we expose ourselves to 30% risk by doing this") and have systems that require tasks with bounded time. As far as I can tell, this just results in contractors and other people selling mostly bullshit estimates, and then if time needs to be extended, coming up with some sort of excuse for more time that doesn't put them at fault ("The interface documentation from this other contractor is incorrect, and will cost us a month to make up the time loss.").
It just seems to me that currently, time estimation on a software project is closer than anything else to time estimation on pure research -- you really *don't know* very well when you'll get someone who makes a breakthrough, but it's required to fit in a corporate world that expects time limits. I just don't see this as egotism of software developers so much as the fact that the process really is just about the most complex commissioned task that you can hire someone to do -- you don't know how it will work until you're at *least* through the full design phase. People in most "creative"-class disciplines, like painters, work in a field where their output quality is somewhat analog. If they have to, they can speed up and come up with a lower-quality output, and it's hard to call them on it. A software developer is the only profession I can think of off the cuff where you have almost no idea how the system will work initially *and* it's easy for the client to come up with a boolean "this meets requirements" or "this does not meet requirements".
He claimed to make a lot of money, and was actually quite happy... I personally think he was running dope on the side, though, so what the hell do I know?...drug runners have a higher job satisfaction level than cubicle farm workers.
Hodges meteorite. November 30, 1954, Sylacauga, Alabama. Annie Hodges was napping on her couch when an eight-pound stony meteorite crashed through her roof. It bounced off a large console radio and hit her in the arm and then the leg, leaving her badly bruised.
How's *that* for a fun one to explain to your insurance agent?
Slashdot Mirror
With monthly financial risk = (P*C)/T, if each month you put away 1.483 cents, you would on average have enough money to pay your settlement fees by the time you were sued.
It's less than that. You're forgetting about interest compounding.
What if you *didn't* hire a lawyer. You just showed up in court and muddled through it? Surely there's no law against representing yourself? And without seized hard drives, it seems like the RIAA would be at a bit of a loss to prove that *you*, and not someone else that used your computer, was the person at fault. Come to think of it...are there independent logs other than those from a RIAA-sponsored P2P logging agency? I doubt it. I wonder what it would take to argue against them.
If 1k people did that, the RIAA would *never* have the legal resources to handle the situation.
This flood of names with very strong reasons to encourage companies to buy another domain name ("You're an adult entertainment company, but you *haven't* voluntarily gone under the .xxx TLD?" "You mean you let someone *else* buy the ford.biz domain?" etc) just reinforces my opinion that ICANN has become a whore to the name registrars. The idea of ICANN is that they make good engineering decisions for the Internet at large, not decisions based on how to maximize name registrar profits.
Yes, because non-root users can install software that starts at boot-time. Oh wait. No.
This is also the case on Windows. On both Linux and Windows, it is possible to run *once that user logs in* or install systemwide *if the root account is used for installation*. If a box stays up for a while, you can just *keep* running after a non-root user logs off.
And even then, your mom's dumb spyware won't affect your account. Processes running as one user can't see another user's data. Oh no. Spyware stopped by good design.
Actually, (frusteratingly) Linux does not currently provide restricted
You'd have to save your X session every time, or just add the spyware to
No, the spyware would. Most Windows users don't explicitly add spyware to their Startup folder. Or maybe it would go in your
Windows is insecure by design. Stop thinking that because everyone uses Windows it has lots of viruses and spyware. It's ALSO because it's very poorly designed. Sad but true.
Windows isn't perfectly written. Neither is Linux. Windows' primary architectural problems (IMHO) come from the integrated MSIE, which is very difficult to regulate and provides functionality to many applications, and from the fact that the "GUI" is so fundamental to the system, exposing vulnerabilities like the one to the "shatter" attacks. Windows is not simply massively poorly designed WRT security. The kernel is actually pretty solid. Windows has its problems, but it's not as if the "everyone uses Windows and those users aren't generally technically competent" argument isn't a dominant one.
Well...I'm really not an FSF/RMS nut. I don't like the GNU/ prefix.
The problem is that the first acronym I tried using was "OS" for "Open Source". Problem is, that acronym is already commonly used to refer to an OS.
Then I tried "OSS". Well, that's dandy, except under Linux that refers to the standard sound driver system (now being phased out in favor of ALSA).
So, finally I started using FOSS. A couple of people like FLOSS (adding a "libre" in) which is also okay but requires another letter, and really, nobody confuses "FOSS" with anything but "FOSS". The "libre" is unnecessary.
The whole point is taking the distro and auto-config utils out of the equasion (e.g. ftp on by default) so you can build a secure services box and know exactly what is on it and what its purpose is. If something is insecure, it's your fault, not the fault of some distro organization who turned something on by default.
The problem I have is that currently, you really have to know your stuff WRT security to set up a secure server and no matter what, there are going to be a lot of people who don't setting up important servers.
Microsoft got together with the US government to put out a list of common misconfigurations, a sort of checklist for Windows. Sure, a Windows security guru probably doesn't need it, but *most* Windows boxes aren't set up by "security gurus". Same goes for UNIX, even if the average degree of security cluefullness might be slightly higher. There are a *lot* of things you have to know, a lot of unintuitive potential issues, and there *are* going to be people running into this.
Take screen locking for a local issue. RH and most distros provide a screensaver in X. This screensaver can provide password protection. A *lot* of people out there just assume "oh, the screensaver is running with passwords on, so nobody can get into my desktop". New Linux users often don't know that you can switch out of an X to a console, and like to start X using startx. Result? They leave something crucial on their system (which is "locked") and someone can, in a moment, walk in, switch to a virtual console, tap ^Z, and do whatever they want.
The concept of "single user mode" is not familiar to a lot of Windows admins. "But it's...*password* protected!" Microsoft has gone out of their way to *avoid* providing a way to boot into Windows from a CD, so most Windows admins w/o much security experience consider someone with local access (esp. in a lab or with a secured case somewhere that they cannot easily physically open the case and get at the drives) to be seriously inconvenienced by the Windows password. Show them that their Linux box can be booted into "single user mode" in a couple of seconds by anyone with physical access to the console, and they get this shocked look on their face. Why not? It's not intuitive to someone with their experiences. Software that must be secure or may be destructive must be intuitive. People are pretty careful to at least provide safeguards and warnings on potentially destructive software, but no such culture exists around security. For many people, it's a set of knowledge picked up by hits and tips over time. That doesn't work. It's not as if mucking up a configuration and opening a hole on a major server is like running a longer command line to locate a piece of text in a file because you don't know the "quickest way"...you have to do things *right* the first time.
Take reverse compromise from a box that uses SSH X11 tunnelling. I know a couple people that *religiously* *never* bounce through any box other than a set of trusted ones when sshing from one machine to another -- they open a new, direct connection from their original computer. Why? So that nobody compromising a second computer can grab their passwod if that computer is compromised. Problem is, they have X11 tunneling enabled by default to the first of two machines. So when they SSH in, they aren't just opening a little terminal window to that machine, where only giving that terminal focus and hitting a key exposes data, but letting that machine log their local keystrokes, dump their screen contents, do really whatever it wants.
I've found a lot of unintutive things in Linux security over the years. Moving directories is a good one. The kernel only does security checking when traversing between two directories. It doesn't check the whole path to see whether you have access to the directories or not. I had a friend using an FTP server on my computer. I moved a directory from his home directory to my home directory. He happened to be in that d
Yes, it is a troll. However, seriously, what benefits would running this on a different OS provide? I'd say that the likelihood of this being a kernel bug are pretty low...
When Microsoft undergoes a security breech, their source code spills out and leaks across the entire Internet.
When gnome.org undergoes a security breech, their source code is more *difficult* to get.
Fun, eh?
You know...honestly...
There have been serveral major, high profile compromises of numerous FOSS servers in the past twelve months. Including a compromise of the GNU source repository.
Microsoft has not made a big deal out of these (at least as far as I've seen). Whereas every security flaw at Microsoft is treated by Slashdot as if someone got access to the crown jewels (well, admittedly the Windows source is running around all over the place...)
Microsoft has really been acting a lot nicer towards FOSS folks about security lapses.
That being said, I'm just *waiting* for a sourceforge compromise. That would be a *huge* hit, and it just plain has to happen sooner or later.
It would be nice if a couple of distributions put out basic *up-to-date* HOWTOs of best practices on how to set up minimal, secure servers using their distribution.
Well...I suppose that if this is a new vulnerability, it's better that they go after a high-profile webserver with a good admin team that can catch the attack than that they attack many poorly-adminned ones.
Maybe not carbon based like we are; but (if you believe in them) life at any rate; since they are supposedly intelligent beings?
IIRC (and honestly, precise points of dogma are not a strong point), angels (at least in the Lutheran interpretation that I've heard) are not free-willed.
Of course, that does make one wonder about Lucifer...
What does this buy me that widely-adopted SPF plus DNS blacklisting doesn't, from a spam-prevention perspective?
* A secure transport. A lot of these systems depend upon DNS for data transport currently, without adding any kind of security to said system. DNS is attackable.
* Flexibility. If someone needs to make a cert associated with two email addresses, such a system could support this.
* Decentralization. I'm comfortable with the statement that a PKI and trust system could be implemented without relying on a single potentially evil (*cough* VeriSign) source.
* Major side security benefits. PKI has major security benefits -- you roll it out and it's also easy to do end-to-end encryption of your email. Businesses need email encryption yesterday, anyway.
* Separation of entity from email address. Suppose I am Linus Torvalds and have a home address and a (new) work address. Many people trust Linus Torvalds -- he isn't going to run out and start spamming. The problem is that his *work* identity is totally different from the POV of SPF or similar systems. With PKI and trust, Linus could trust his work address's cert with his home address's cert (or possibly even just resue the cert, depending upon the system).
* Entity-level trust. I can trust a single person without having to say "if it comes from this organization's mail server, it must be good". SPF might let me know that an email came from the right mail server from the domain, but doesn't let me know that the email isn't forged -- if someone manages to compromise a single computer at IBM, my only option with most non-PKI systems is to distrust all email from the IBM domain, since they can send email "from" anyone. Entity-level trust is important to allow breaks (and any system *will* break -- if you compromise someone's system, it's hard for others to tell you from that person) to be isolated -- if my machine gets taken over and people forge email from me, the only person that email stops coming from as a couple people start marking the email as spam is me. My coworker in the next cubicle is unaffected.
* Traditional blacklisting doesn't scale to the internet. Binary "I trust" or "I don't trust" systems are just don't make sense on something the size of the Internet. Trust networks are a fuzzy form of whitelisting. As you build up associations with people, you build up trust (and yes, establishing a new trusted identity is going to be a pain at first). The reason traditional binary blacklisting doesn't work is that you have to start out whitelisted by default.
In fact, if a trusted PKI signing authority turns evil and starts issuing certs to spammers (or just refusing to revoke spammer certificates), wouldn't you be slighly worse off than you would be with SPF + DNSBL?
No. Binary trust probably wouldn't work at such a scale, for exactly the reason you just cited -- getting something to slip through the cracks is too easy. You need to have A trust signing authority B and email sender C, etc. Then just make the trust system really easy to use, tying that "spam" button in mozilla to the trust network.
It's just that if all email is signed and it takes a bit of doing to obtain a cert and ensure that enough people trust it, you can reasonably have a trust value assigned to any of the signing authorities as well, and have trust levels backpropagate.
Again, such a system is a pain in the ass to roll out. I just haven't seen anything else that handles this.
Oh, for chrissake.
They're throwing out updates as soon as they get them because, really, this is so far beyond anyone's expectations that we're really floored.
The big deal is that if we really do find life that evolved separately from terran life, it throws a *huge* quandary for some philosophies and a lot of world religion, besides being a major psychological breakthrough for science. And the signs look *awfully* good.
Besides, NASA had a lot of bad press from Columbia, and they're hungry to be able to give good news.
And, really, aren't you even a little bit excited.
a) While I agree that it has been made impressively difficult to locate non-evil Divx codecs for Windows (thought not as bad as trying to obtain the free RealPlayer for Windows), it can be done.
b) Install said spyware, remove said spyware with Ad-Aware. Ugly, but it works.
c) Use Mplayer on Linux. While I agree that this is certainly not a "quick fix" solution, it *is* terribly nice in the long run.
As an interesting note -- ultimately, as Linux catches on, spyware for Linux will begin to appear. At that point, the value of distributor-packaged software will rise, so Red Hat, SuSE, etc may be able to make more money. Actually, it would be a good idea for distros to start making policies on applications with spyware *now*, because it will come up. Is Debian going to have an "adware" section, or simply ban evil software?
Unless, of course, you are friends or secret business partners with a congressman, in which case you may be getting a few million in grants to study the rate that ketchup flows.
I'd say that, while that does seem quite inconsequential, at one point we thought that the flow of molasses couldn't be all that crucial either, until the lives of 21 people depended upon it.
and the following philosophical objections may also apply:
.mail registrar with a razor blade to the Internet's wrist and demands from stockholders.
(x) Countermeasures should not be a profit center for a single corporation.
After VeriSign, I'd like less corporate involvement in the Internet's structure, thank you. It sounds good, people promise to do the right thing, and in the end, everything is sacrificed in the name of short-term profits. I do not want a
Oh, you're one of those people that likes to stifle innovation and put upstanding companies like VeriSign out of business, eh?
Okay, I'm dubious about the legal stuff you want to do. There are a *lot* of implications of doing something like that, including privacy issues.
However, you have one point absolutely dead-on accurate. If you want to do any kind of server-side filtering, if there is any proposal to do so, *users* should have the ability to set this filter. Server-side filtering (as opposed to client-side) has a lot of benefits -- it means that clients don't have to be maintained, that users can easily switch clients, server-to-client bandwidth is saved, etc. However, it's *tremendously* frusterating when a server operator chooses to block something that a user specifically knows he needs.
Even if a good antispam system is put in place, it makes a *lot* of sense to let users have some kind of protocol, some set of extensions to SMTP, that let them alter server-side filtering associated with their mailbox. Maybe even expose a series of complex presets that the server can provide (SpamAssassin, block Asian-originating email, etc), and let the client enable them on his account. Provide an idiot-proof GUI to interoperate with this, and you're gold.
The main issues would be added server complexity and processing load.
What specifically do you find *good* about this?
It seems to me on a quick skim to have all the same flaws that SPF does. Additionally, the cynic in me can't help but think that this is rather likely to have been pushed by domain name registrars, as it means that they can charge money per registration.
Ultimately, I've yet to see a long-term-workable antispam solution proposed that doesn't involve the use of PKI and a trust system of some sort (probably transparent). Yes, it's a pain to roll out, but it's going to have to be done eventually.
So ultimately, the correct social solution is to find ways to make hiring and HR cheaper and easier?
...and I'm sure there will be lots of negative posts about NASA here...
It'd be nice to give some credit for the people that have put in layer upon layer upon layer of safeguards to check for exactly this sort of thing and the dilligent people that find this stuff. And caught it.
The awful thing is that this is going to be just another reason for Congress to loot the NASA money bag.
Sorry for the previous premature post.
Western developers' insistence that software development is some kind of magic that cannot even be remotely predicted or estimated. Nonsense!
I would be interested in hearing any links to resources that you have found really, honestly valuable when it comes to predicting time of a project, how many lines of code are involved. So far, software engineering books seem to be full of buzzwords and short on actual useful content, and I've seen only very vague rules of thumb from people that predict project time estimates.
I can understand predicting the time to build a building. All the operations that must be performed are known roughly in advance -- laying a brick is a simple, repetitive operation, and determining the time to lay a thousand bricks is hence fairly simple. Determining the time to finish a project just seems...an almost incredible art.
Businessmen have been trained to use specific management techniques and some simple models ("this task depends on that, we expose ourselves to 30% risk by doing this") and have systems that require tasks with bounded time. As far as I can tell, this just results in contractors and other people selling mostly bullshit estimates, and then if time needs to be extended, coming up with some sort of excuse for more time that doesn't put them at fault ("The interface documentation from this other contractor is incorrect, and will cost us a month to make up the time loss.").
It just seems to me that currently, time estimation on a software project is closer than anything else to time estimation on pure research -- you really *don't know* very well when you'll get someone who makes a breakthrough, but it's required to fit in a corporate world that expects time limits. I just don't see this as egotism of software developers so much as the fact that the process really is just about the most complex commissioned task that you can hire someone to do -- you don't know how it will work until you're at *least* through the full design phase. People in most "creative"-class disciplines, like painters, work in a field where their output quality is somewhat analog. If they have to, they can speed up and come up with a lower-quality output, and it's hard to call them on it. A software developer is the only profession I can think of off the cuff where you have almost no idea how the system will work initially *and* it's easy for the client to come up with a boolean "this meets requirements" or "this does not meet requirements".
Western developers' insistence that software development is some kind of magic that cannot even be remotely predicted or estimated. Nonsense!
I would be interested in hearing
He claimed to make a lot of money, and was actually quite happy... I personally think he was running dope on the side, though, so what the hell do I know? ...drug runners have a higher job satisfaction level than cubicle farm workers.
Hmm...
Not always.
Note the bit on the Hodges meteorite:
Hodges meteorite. November 30, 1954, Sylacauga, Alabama. Annie Hodges was napping on her couch when an eight-pound stony meteorite crashed through her roof. It bounced off a large console radio and hit her in the arm and then the leg, leaving her badly bruised.
How's *that* for a fun one to explain to your insurance agent?