Data storage is cheap and light. Grab a copy of the latest repositories for anything you could conceivably want and play with it. You can download the stackoverflow.com question database, which ought to be able to answer the majority of newbie questions on any popular framework. A local copy of wikipedia might help, too.
Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
It places no limits on what you can do with published information.
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, 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.
 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.
Yes, you can. You can create a Twitter feed and then set it up so that only people you've explicitly allowed to follow you can see your Tweets.
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?
So in this case, if you deposit slightly less than $10,000 then that also triggers the bank to privately report you to the government. All of the people mentioned in the article deposited slightly less than the $10,000 to avoid triggering, and they knowingly avoided it, although for different reasons (some did it because they thought it was a hassle for the bank, and they were trying to be nice?). So if you need to deposit $10,000+ in an account, then fucking do it! In this case, it "triggers" an event, but that event doesn't remove your money.
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.
a CPU that can manage a trillion hashes per second (easy)
A trillion (10^12) hashes per second can still check only 100 million (10^8) passwords per second if checking each requires 5000 rounds of PBKDF2. In the common PBKDF2 built on HMAC, each round is two hashes, making a 5000-round PBKDF2 take 10,000 (10^4) hashes.
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.
Or to put it another way, your xkcd password, if the user has a vocabulary of 10k words, being cracked by a CPU that can manage a trillion hashes per second (easy) means your password can be brute forced in less than 3 hours.
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, MS doesn't give the slightest concern about any broken Java apps.
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.
for whatever reason, a lot of Java code checks the "os.name" property to determine the OS version instead of "os.version".
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?
...with Windows 100.
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?
So you're telling me that Microsoft decided/had to skip a version number because of existing Java code? Rly? Srsly?
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.
So, it basically makes no sense using a Java example of getting the OS version string, as essentially nobody uses Java for any tightly integrated desktop app where you need to know exactly what version of Windows you're on.
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.
And looking at the code examples like 90% of the cases where in the Java sources.
The problem isn't Windows, the problem is incompetent programmers. Instead of calling the proper API to get the version number, morons are doing things like
if (os.startsWith("Windows 9")
Right. And what is that proper API in Java?
Because only Java attracts bad programmers?
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.
What's more interesting is why the OS detection is being done in the first place - the cynic in me says it's probably because they're using the OS version to make assumptions about file system locations.
Most of them are trying to choose between "sh -c", "command.com