Actually, it does. It only allows you to process such information for certain purposes, or if you fall into an exempt category of processing. Thankfully, one of those purposes is to protect the interests of the person whom the information concerns, which is what the Samaritans are attempting to do here. And one of those categories is for personal use, which is what the users of the app are doing.

Right. Also: not illegal. The Samaritans are processing the data on behalf of the registered users of their app, not for themselves. The users determine what data is to be processed, and request the specific way in which it will be processed. Therefore, under the definitions from the Data Protection Act, the user is the data controller ("a person who (either alone or jointly or in common with other persons) determines the purposes for which and the manner in which any personal data are, or are to be, processed"). The Samaritans are acting as a data processor ("any person who processes the data on behalf of the data controller").

The act is quite clear throughout that it is the data contr-oller[1], not the data processor, who must comply with the various restrictions as to how data may be used. The users, as long as they are using the app only for the purposes for which The Samaritans describe it as having been designed, are exempt from the provisions of the Data Protection Act, because the data is "processed by an individual only for the purposes of that individual's personal, family or household affairs".

However, even if this were not the case, here is the principle that TFA interprets as stating that the processing performed should not be permitted: "Personal data shall not be processed unless at least one of the conditions in Schedule 2 is met, and in the case of sensitive personal data, at least one of the conditions in Schedule 3 is also met."

Unfortunately for this argument, schedule 2 allows processing that is "necessary in order to protect the vital interests of the data subject," which appears to me to be the case here. And, while the data in question is considered sensitive, schedule 3 allows processing which "is necessary in order to protect the vital interests of the data subject or another person, in a case where the data controller cannot reasonably be expected to obtain the consent of the data subject", which also appears to me to be true. It also allows processing of data that "has been made public as a result of steps deliberately taken by the data subject."

So, even were we to hold that The Samaritans are the data controller for the data used by the app, it seems they are entitled to perform this processing.

[1] It seems that slashdot believes the data protection act to be lame, and won't let me post accurate quotes from it. It appears especially to dislike the word that starts "cont" and ends "roller" for some reason I don't quite understand, but unfortunately that word is used very frequently in the text, so I can't really avoid it.

Right, but as this only looks at the feeds that are visible to the user who is using it, and only shares information about those feeds with that user, what's the problem?

At least one had an entirely different reason - they were banking their cash before it reached $10,000 each time because their insurance policy had a $10,000 limit on claims for cash. Another was described as depositing wildly varying amounts at regular intervals, apparently just banking their business's weekly takings (or whatever) that just happened to always be between $5k and $10k.

Yes, there were a couple of cases where the avoidance of the limit sounded to be intentional, but that wasn't the case in all of the instances presented in the article.

That, and the fact that there's no CPU on earth that can calculate 10^12 cryptographic hashes in a second using any algorithm that's ever been commonly used for password hashing. Even hardware using custom ASICs designed for the purpose struggles to approach this rate; the fastest bitcoin miner money can buy manages 4x10^11 hashes per second in each of its 15 processors. Any single chip solution can't really do much better than that, because cooling.

Err... that's rather faster than any CPU or indeed GPU I've ever heard of. Depends, of course, on your hashing algorithm, but the fastest I've ever heard of is 3.5 x 10^11 NTLM hashes, which wasn't a single CPU but a cluster of 25 GPUs, so call it 2x10^10 for a single processor, or approximately 2 orders of magnitude slower than your suggestion of what is "easy" to achieve.

Also note that this was NTLM, which is a lot weaker and easier to calculate than most of the algorithms used by web-based systems today. The same cluster only managed 71,000 hashes per second against bcrypt, which is the algorithm that is usually recommended for new systems at the current time. That's about 3,000 hashes per second per processor.

So cracking that XKCD-style password in less than 3 hours...? Not in reality it can't. That's 10^12 possible passwords. If they were hashed using NTLM and you were using all 25 nodes of the fastest password cracking cluster that has been publicly described, and they were as short as the passwords used in the original benchmark it would take about 3 hours, yes. But (1) nobody seriously uses NTLM, and (2) few attackers have that kind of hardware available, with cost estimated at around $30,000.

Used on a site complying with modern standards of password encryption against a realistic attacker (a script kiddie using a couple of high-end gaming system with 2 top-end GPUs, thus cranking out about 10^4 bcrypt hashes per second) your XKCD-style password would last about 5x10^7 seconds, or approximately 1.5 years.

Change your password every 6 months and as long as the site uses modern encryption techniques you'll be just fine.

Trust me, they do. Windows 10 won't fly if they can't get corporate types to adopt it. The corporates won't adopt it if their large number of custom (and frequently very shoddy) Java apps (in use in 90% of large corporations according to a recent survey) won't run. MS cares about making sure Java apps work OK.

Because Java's API design is fucked up.

Windows NT 4.0: os.name = "Windows NT", os.version = "4.0"
Windows 95 (= MSDOS 7.0): os.name = "Windows 95", os.version = "4.0"
Windows 98: (also MSDOS 7.0): os.name = "Windows 98", os.version = "4.1"
Windows 2000 (aka NT 5): os.name = "Windows 2000", os.version = "5.0"

Given these 4 versions as the likely target platforms, how do I determine if I'm running on Windows-the-DPMI-DOS-Extender or Windows NT?

I've seen at least one suggestion that all future versions of Windows will be Windows 10. So, that would presumably be Windows 10.90 you're looking forward to?

Yes, I can believe it. Microsoft needs to sell the latest version of Windows to all of its big corporate clients, and almost all of them run custom Java applications. Java applications are quite likely to have bugs like this because Java doesn't provide an easy way to get the operating system version number.

The code I see in almost all of the search results isn't really trying to determine an exact version: it's trying to work out which basic operating system family is in use, i.e. distinguish between Windows-which-was-a-DPMI-DOS-Extender and Windows NT.

Right. And what is that proper API in Java?

Because only Java was designed to discourage operating-system-version-dependent code and therefore intentionally lacks a way of checking the operating system version except through a string; most other languages provide an API that gives you major & minor version numbers in integers, which is much more convenient.

Most of them are trying to choose between "sh -c", "command.com /c" and "cmd.exe /c" as a way to parse & execute command lines.

Almost all of the results in the search are Java applications. Java doesn't provide access to the specified API. The only way you can do it is with System.getProperty("os.name") and System.getProperty("os.version") which both return strings.

The code that turns up in most of the search results is trying to determine the correct executable and arguments to execute a command line (i.e. it picks the right one of "sh -c", "command.com /c", or "cmd.exe /c"). How would you propose doing this without determining what operating system you're running on?