We assume that di-hydrogen monoxide is not a chemical the AC and his/her ancestors either did not grow up or did not evolve with. So you are changing the subject.

We are also pretty sure that non-dangerous levels of H2O are used in the production of organic foods, and non-dangerous levels are contained in them, as well.

I don't believe in trusted environments, not when the end-user can change his IP and/or MAC, etc.

The effort you have to go through to set up the certificates the chain-of-trust, the execution context, constantly checks, etc., and I tend to think the out-of-band solutions work better.

You know, you seem to waste a lot of energy on misguided attempts at social engineering.

If you don't recognize the references I made in my posts, you have not looked at the data yourself.

Which makes your assertions of hypocrisy rather ironic.

Either that or you wouldn't recognize the data, which is a different kind of irony. (And it would be wiser to let you learn how to recognize such things for yourself, because you would likely be more responsible with knowledge you had to work for.)

But, if you really understand what you mean about security flaws being known in any system, why do you complain that anyone would mention the fact? That would rather suggest a cynical kind of hypocrisy on your part -- as if you were trying to shut people like me up so you would have more vulnerable systems to attack.

As I said, it's a speed bump, to be used in combination with other techniques, not a perfect solution.

Relative to X11, the attack has to be aware that the user that the browser is running under is restricted and not a login browser, and decide to attack X11 instead of just dropping a keylogger and adding a line to the user's .bashrc to invoke it. Just buys you a little time, but that's not a bad thing.

I think the gp was talking about perlscript.

.. Remote Method Invocation ..

I simply cannot imagine what Sun was smoking when they added this to Java. Even without an exploit, setting up the security manager/context is not something the end-user is going to do, so it is going to get left to the server-side, which is basically offering root to the vm to the server.

Well, I've been recommending a sort-of simple procedure for *nix users, where you call your browser through a restricted, dedicated user account with no login privileges.

By no means is it a perfect solution, but every speed bump and low wall helps a bit.

One could (should?) basically set up such pseudo-users for specific required processes that will run a java vm, and refrain from using Java otherwise.

Of course, any architecture that allows a server to feed a client a class that the client's machine will instantiate is going to be vulnerable.

We know that the license (for Oracle's release) is a charade.

Isn't the whole problem here derived from Oracle's attitude that they own this thing?

I don't think it's possible to keep a closed/proprietary attitude and make secure software. I don't mean that the form of the license guarantees anything, there are always exceptions where the license and the community attitude are out of sync, but I think it's clear that software products have to be open to the end user to be secure.

I took time to dig into the data, before I posted that rant.

Did you?

Like I said, when I make random test addresses I do not bother going to the effort that would have been required if those lists of addresses were fabricated. Maybe someone did go to the trouble, but the data did not look that way to someone who thinks about what the data should look like.

Pointing too much out would be helping wannabee script kiddies, so that's about as far as I'm gonna say here. (It's bad enough to confirm to the spammers who lurk here that there are probably live addresses in those lists.)

I also took time to dig into Intel's, Microsoft's, and now Apple's non-efforts at security.

And I refrain from being more specific about that for similar reasons, but it is precisely because of the no-brainer holes that the market leaders leave in their security that more than half of that load of data was harvested. And it is the market leader wannabees in the Linux communities, trying to "be like the big boys", that have produced similar holes in many of the Free/Open systems available..

Now, who's unreal here?

Aluminum Oxide.

Alzheimer's here we come.

Some lazy assumptions in your analysis, but I will address your positing fabrication.

When I make test addresses, I tend to let randomness do more work and focus mostly on the corner cases for testing the parse.

I'm strongly leaning towards something a combination of your #2 and #3 possibilities, some crappy sites, some other stuff, and they seem to have more, but not enough time to figure out what to do with it all.

I'm not going to explain why because I'd rather have some more time to get ready for the current internet to crater.

(Condemn Intel for insinuating their under-baked IP into all the pipes. Condemn Apple, for joining Intel and Microsoft. More condemnation on Microsoft for taking too long to go under, but how do you make secure systems with Intel's junk in everything, and pushing the features so hard that no one dares focus on building properly securable information systems.)

Sure, it's semi-random data from a bunch of semi-random databases.

There are e-mail addresses in there to be harvested. (I'd hesitate to say even that much, but I'm sure the spammers have already jumped all over those.)

There are passwords. Even though at least some are encoded, that still gives crackers something to run rainbow tables against.

I'd mention more, but I really don't want to give random wannabee social engineers too many clues. (Even dead simple ones.)

There are real security issues here, and pretty much every company on-line in the world had better be tightening up ship, asking users to change their passwords, and combing through that data to see what visible dangers there are.

What, you're suggesting somebody here get out and run for office or something?

Gotta cite for that?

How was it that they were found not to be infringing? Under what argument? Just because they were not Android or something?