Slashdot Mirror

You're pretty behind the times. Much if not most of the code is available now. The NASA/GISS Model E, one of the main Global Climate Models is available here. The data and code for Michael Mann's original hockey stick graph are available here.

For a comment on the code in your original code see here.

http://blog.jgc.org/2011/06/my-email-canary.html

Just to illustrate how full of bollocks Lord McNally actually is, take this example:

http://news.bbc.co.uk/1/hi/uk/4796579.stm ...or to sum up for those who can't be arsed to read the link, in 2006 we pardoned 306 World War 1 soldiers who were executed for cowardice. It was also perfectly legal action at the time. So the question is Lord McNally, why the hypocrisy?

This example displays only consistency, not hypocrisy, a point made in the well-argued article referred and linked to in the submitter's article.

Basically, the soldiers' had a medical condition which resulted uncontrollably in actions that were mistaken for cowardice. They should not have been found guilty of the law of the time, regardless of whether the law was just or not.

Turing however had a sexuality, which does not in itself uncontrollably result in actions that were illegal. Thus he did break the law of the time, even if the law was not a just one.

Also as noted in the article, the way forward would be to request a deletion under the Protection of Freedoms Bill which is nearing completion.

I started getting upset when I read the story, but your thought did occur to me. Also, the UK has legislation on the table that would "disregard" the past convictions.

This guy reasons it out pretty well: http://blog.jgc.org/2011/11/why-im-not-supporting-campaign-for.html

Even still, one good reason (and I think good enough) to pardon Turing is it gets a ball rolling and brings the issue to the public's attention. Quietly disregarding past convictions does a lot legally, but not a whole lot for the public perspective (if no one knows, no one cares, by definition).

The guy who successfully campaigned for the UK government to issue an official apology about the treatment of Turing (rather than a pardon) comments about this here:

http://blog.jgc.org/2011/11/why-im-not-supporting-campaign-for.html

"I could get behind a petition for a pardon for all those people, especially since living people are still hurt by that law, but not just for Turing. Pardoning him doesn't help the living...But even that's unnecessary...Chapter 4 of the [Protection of Freedoms Bill 2010-12 - legislation in progress and close to completion] specifically allows for the disregarding of convictions under the old law that was used against Turing. Once disregarded the law causes their convictions to be deleted. It's not quite the same thing as a pardon, but its effect is to lift the burden of a criminal record from these living men."

John Graham-Cumming has an excellent, level-headed response to Mohamed Assan's entire "research."

Also confirmed at F-Secure.

You're right. The original article I read didn't discuss exactly how the attack occurred, but once I knew what to search for I found an attribution to JavaScript pretty fast.

Still, both kinds of attacks have exactly the same defense.

It wasn't clear to me that JGC knows specifically what the vulnerability is, though it seems to be related to random number generation.

In this post: a tweet is referenced as well:

never been angrier than right now. I can't actually describe how broken @haystacknetwork is, because to do so would put people at risk.

It wasn't clear to me that JGC knows specifically what the vulnerability is, though it seems to be related to random number generation.

In this post: a tweet is referenced as well:

never been angrier than right now. I can't actually describe how broken @haystacknetwork is, because to do so would put people at risk.

---- posted in verbatim for /. proof ----

Theres been a lot of alarming but rather brief statements in the past few days about Haystack, the anti-censorship software connected with the Iranian Green Movement. Austin Heap, the co-creator of Haystack and co-founder of parent non-profit, the Censorship Research Center, stated that it had halted ongoing testing of Haystack in Iran; EFF made a short announcement urging people to stop using the client software; the Washington Post wrote about unnamed engineers who said that lax security in the Haystack program could hurt users in Iran.

A few smart people asked the obvious, unanswered question here: What exactly happened? With all that light and fury, there is little public info about why the worlds view of Haystack should switch from it being a step forward for activists working in repressive environments that provides completely uncensored access to the internet from Iran while simultaneously protecting the users identity to being something that no-one should consider using.

Obviously, some security flaw in Haystack had become apparent, but why was the flaw not more widely documented? And why now?

As someone who knows a bit of the back story, Ill give as much information as I can. Firstly, let me say I am frustrated that I cannot provide all the details. After all, I believe the problem with Haystack all along has been due to explanations denied, either because its creators avoided them, or because those who publicized it failed to demand one. I hope I can convey why we still have one more incomplete explanation to attach to Haystacks name.

(Those whod like to read the broader context for what follows should look to the discussions on the Liberation Technology mailing list. Its an open and public mailing list, but it with moderated subscriptions and with the archives locked for subscribers only. Im hoping to get permission to publish the core of the Haystack discussion more publicly.)

First, the question that I get asked most often: why make such a fuss, when the word on the street is that a year on from its original announcement, the Haystack service was almost completely nonexistant, restricted to only a few test users, all of whom were in continuous contact with its creators?

One of the things that the external investigators of Haystack, led by Jacob Appelbaum and Evgeny Morozov, learned in the past few days is that there were more users of Haystack software than Haystacks creators knew about. Despite the lack of a public executable for examination, versions of the Haystack binary were being passed around, just like unofficial copies of Windows (or videos of Iranian political violence) get passed around. Copying: its how the Internet works.

We were also told that Haystack had a centralized, server-based model for providing the final leg of the censorship circumvention. We were assured that Haystack had a high granularity of control over usage. Surely those servers could control rogue copies, and ensure that bootleg Haystacks were exc

John Graham-Cumming wrote an article today complaining about how a computer system he was working with described his last name as having invalid characters. It of course does not, because anything someone tells you is their name is--by definition--an appropriate identifier for them. John was understandably vexed about this situation, and he has every right to be, because names are central to our identities, virtually by definition.

I have lived in Japan for several years, programming in a professional capacity, and I have broken many systems by the simple expedient of being introduced into them. (Most people call me Patrick McKenzie, but I'll acknowledge as correct any of six different "full" names, any many systems I deal with will accept precisely none of them.) Similarly, I've worked with Big Freaking Enterprises which, by dint of doing business globally, have theoretically designed their systems to allow all names to work in them. I have never seen a computer system which handles names properly and doubt one exists, anywhere.

So, as a public service, I'm going to list assumptions your systems probably make about names. All of these assumptions are wrong. Try to make less of them next time you write a system which touches names.

1. People have exactly one canonical full name.
2. People have exactly one full name which they go by.
3. People have, at this point in time, exactly one canonical full name.
4. People have, at this point in time, one full name which they go by.
5. People have exactly N names, for any value of N.
6. People's names fit within a certain defined amount of space.
7. People's names do not change.
8. People's names change, but only at a certain enumerated set of events.
9. People's names are written in ASCII.
10. People's names are written in any single character set.
11. People's names are all mapped in Unicode code points.
12. People's names are case sensitive.
13. People's names are case insensitive.
14. People's names sometimes have prefixes or suffixes, but you can safely ignore those.
15. People's names do not contain numbers.
16. People's names are not written in ALL CAPS.
17. People's names are not written in all lower case letters.
18. People's names have an order to them. Picking any ordering scheme will automatically result in consistent ordering among all systems, as long as both use the same ordering scheme for the same name.
19. People's first names and last names are, by necessity, different.
20. People have last names, family names, or anything else which is shared by folks recognized as their relatives.
21. People's names are globally unique.
22. People's names are almost globally unique.
23. Alright alright but surely people's names are diverse enough such that no million people share the same name.
24. My system will never have to deal with names from China.
25. Or Japan.
26. Or Korea.
27. Or Ireland, the United Kingdom, the United States, Spain, Mexico, Brazil, Peru, Russia, Sweden, Botswana, South Africa, Trinidad, Haiti, France, or the Klingon Empire, all of which have "weird" naming schemes in common use.
28. That Klingon Empire thing was a joke, right?
29. Confound your cultural relativism! People in my society, at least, agree on one commonly accepted standard for names.
30. There exists an algorithm which transforms names and can be reversed losslessly. (Yes, yes, you can do it if your algorithm returns the input. You get a gold star.)
31. I can safely assume that this dictionary of bad words contains no people's names in it.
32. People's names are assigned at birth.
33. OK, maybe not at birth, but at least pretty close to birth.
34. Alright, alright, within a year or so of birth.
35. Five years?
36. You're kidding me, right?
37. Two different systems containing data about the same person will use the same name for

Who are these pro-warming scientists who won't release their data?

I don't know, who they are, but I do know, that no full, raw, unedited and "uncalibrated" series are nowhere to be found. The recent "leak" of the materials from East Anglia's CRU contained e-mails and programs (some showing obvious attempts to apply bogus corrections), but not the data files.

Worse — whatever raw data this particular CRU had before, was dumped "to make room", and only the result of their "calibration" is preserved. Whether they sincerely believed, the original data will never be needed, or maliciously thought to hide imperfections in their calibration algorithm is a hot topic. But what's clear, is that it is not available — to anyone.

But, again, even if the calibration were perfect (or, at least, sincere) — we can't get it. And so, there is no way to reproduce the results — for example, a highly-moderated poster (mrsquid0) claimed to have discerned from the leaked IDL-programs, that the correct, rather than bogus version of the script was used to produce a chart published in Nature. However, when asked, where he got the data to run the program for himself, he posted no response... Because he never has... Have you?

It is easy enough to tell by looking at the Nature paper. Hint, the plot in the paper does not have this correction applied.

Actually, the above statement implies, you've reproduced their results successfully yourself. Have you? Where did you get the data and how did you run the IDL-interpreter (or the GDL-clone of it)? I don't think, you'd be able to, because the data used for this chart(s), apparently, comes from /cru/u2/f055/data/obs/grid/surface/lat_jones_18511998.mon.nc, which is not included in the leaked archive...

The thread you pointed to is inconclusive on the matter, but you are sure, there is nothing to look at here, and we should move along. What did you do to confirm that?

On that same blog you link to, there is an "Update": Read the comments below. It's been pointed out to me that there's a later version of code in the archive in which similar correction code is not commented out. Details and link below.

Well, then it should be easy to find the published plot coming from exactly that file. I'm waiting. Or is it harder to find published data than "hidden data"?

On that same blog you link to, there is an "Update": Read the comments below. It's been pointed out to me that there's a later version of code in the archive in which similar correction code is not commented out. Details and link below.

The "VERY ARTIFICIAL correction" you describe is never actually used. It's commented out. You can plot that array, but I'm not sure what you think you're demonstrating.

If only it were as simple as getting one adapter cable. John Graham-Cumming explains the situation -- with the recent proliferation of standards, you need a bundle of adapters to handle all the combinations.

Let's start with an apology to Alan Turing and a public recognition for the grave injustice dealt to him for being homosexual.(PERIOD)

There, fixed that for you. Whether or not he did his country and the world an enormous service - which he undeniably did - does not enter into it. The injustice he suffered was wrong, regardless of his merits. And the same goes for any less known individual who suffered similar injustice.

Let's start with an apology to Alan Turing and a public recognition for the grave injustice dealt to him for being homosexual, despite his enormous service to his country, the allies, philosophy, and, of course, computer science.

There's another interesting method for detecting "photoshopped" images that were manipulated using the clone tool.

The procedure uses a Discrete Fourier Transform on a bunch of little sections of the image and tries to find groups of matching sections that are displaced in the same way. There're a few discussions and papers about the copy-forge detection procedure and there's also source for the proof-of-concept application.

TFA says this is a service SELLING captcha breaking

In no case do not enter random characters!

We pay only correctly recognized pictures!

I'd expect it to do much better than the 20% they cite.

It's also true that _average_ people only break CAPTCHAs successfully about 80% of the time. Here's a relevant experiment

Then there's possible issues with firewalls etc. Some bots are hosted on a zombified PC which could have any kind of restrictions, and it might have trouble dialing one of the the servers, or maybe the server can't respond properly due to inbound filtering.

The term-of-art within the anti-spam community is "Bayes Poison". Generally its appended to an actual spammy offer, but some spammers have in the past used the technique with web-bugs to determine whether they are able to deliver to particular boxes with non-spammy content, so that they can evaluate whether their later more-spammy content was excessively spammy or whether it hit the sweet spot on the blocked vs. effective-sales-pitch continuum. Most people in the anti-spam community report that garden variety Bayes Poison is ineffective at either de-spamming spammy messages or causing your corpora to be skewed to the effect that they are unusable. One major reason for this is that corpora are so specific to individual users. For example, poisoning my inbox with copies of Huckleberry Finn is rather ineffective because nobody I talk with on a regular basis writes like Mark Twain. For you to do actual damage, you would have to know enough my habits to guess subjects and words which appeared very commonly in legitimate mail -- for example, the names of my family members, keywords relating to my job or extracurricular interests, etc. It is very difficult for spammers to get this information, but some academics have reported that it is theoretically possible, although in practical terms very difficult, to use web bugs to extract the "secret sauce" needed to land in one particular inbox. http://www.jgc.org/SpamConference011604.pps

Greylisting was predicted to work for only a short time and that's how it worked out. Greylisting works only against zombies who try to send mail directly to your server via port 25. As more and more ISP's get smart and start blocking outbound 25 from their dynamic pools, greylisting (and relying on rDNS pattern matching to filter for dynamic pools) is becoming less and less effective. I am a mailing list owner for a large free open source operating system project. This project uses greylisting on its mail server. I get a lot of spam from zombies relayed through their ISP's mail relays, that has bypassed greylisting. In short, enjoy greylisting while it lasts. It will be almost completely inaffective inside of a year. Spammers are learning how to route through the mail relays they find configured in the users' mail client. They're also learning how to authenticate with those mail relays using your credentials. They're learning how to adapt to rate limiting enforced by your ISP's mail servers. I predict within a few years, those of us on broadband, will only be able to relay mail to our ISP's port 587, using authentication, be limited to 20 emails per day, no more than 2 per hour, and only from a set of 4 pre-configured sender addresses. I predict there will be an RBL to identify those ISP's who do not implement such a sane policy.

There are lots of you with little pet techniques for filtering spam that you think are effective. Some of you claim to be able to rid yourself of 90% of all spam using one single technique. You should consider that any moron can get easily get rid of 90% of spam. Probably even 95% for lesser morons. Especially on personal mailboxes where you can arbitrarily choose to cut out huge geographical regions and don't care about a few false positives. All the work is in that last 5% while still offering useful mail service to a large and diverse user community.

John Graham Cumming has been tracking anti-spam tool spam/ham strike/hit rates according to published studies that meet certain dataset criteria. You can find it here: http://www.jgc.org/astlt/

John Graham-Cumming says that the Travelocity email at the bottom of the his blog essay "really is a genuine message from Travelocity and not a spam."

I beg to differ. I have no problem believing that it "really is a genuine message from Travelocity."

But spam doesn't mean "phony," it means "unsolicited commercial email." (And in my own opinion that includes "unknowingly 'solicited' commercial email.")

In order for Graham-Cumming or anyone else to say that Travelocity email is not spam, they would need to know whether it was solicited. You can't tell by any examination of the message itself.

If it was actively solicited by someone specifically checking a box requesting to be notified of offers, then, sure, it's not spam. If it was opt-out spam with the opt-out option hidden... or implicit... then it darn well is spam.

Mostly likely this particular email is in a grey area... quite likely an opt-out was plainly visible, but needed to be actively chosen, at some point in the travel booking process where a customers thoughts are likely to be elsewhere (where IS that security code on the back of my credit card?).

But it is absolutely wrong to stay that the Travelocity message is "not spam," just because it is really from Travelocity

Spam is spam, even if it is a genuine email from a reliable company informing me of some truly valuable opportunity... _if I didn't ask the company to send me those emails._

• no attempt at validation
• no analysis of statistical significance
• almost[1] no attempt at common-sense analysis
• irritating typos

Salting the message with random words thwarted Bayesian filtering.

John.

Maybe this would help?
The Spammer's Compendium