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.
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[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.
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.
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.
Exactly.
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
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/c" and "cmd.exe/c" as a way to parse & execute command lines.
No.... this really comes down to not knowing, and not using, the API provided to you by the OS for handling version detection.
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.
This is exactly why all modern Javascript libraries do feature detection instead of relying on User-Agent 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?
more porn, which will continue to destroy families and relationships by commoditizing sex, spreading promiscuitity, and creating unreal expectations of sex.
It isn't terribly surprising that adding a cartoonish rendering effect to both real and virtual objects would make them more difficult to discern as such. I certainly wouldn't call it more immersive - quite the opposite, in fact. It is extremely obvious that what you are looking at has been altered and that you are not looking at "reality".
Right, but "immersive" doesn't mean "difficult to distinguish from reality" but rather "easy to treat as if it were real". I mean, I used to find playing Elite on my Sinclair Spectrum "immersive", but there's not a chance I'd ever fail to know it wasn't real. Being immersive means allowing people to retain what's often called "willing suspension of disbelief" -- as long as the system I'm looking at behaves consistently, I can treat it as if it were real, so I can (at least sort-of) believe in its existence as a real thing. And maintaining that sense of existence is what people mean when they say immersion.
The filters they applied in the video make the scenes look less realistic overall, but they make them more consistent, and that lets me believe in them as real in a way I can't easily believe in the unfiltered scene.
Or, at the very least, sue Google for something that actually makes sense, such as allowing Google Drive accounts to be accessed by hackers as part of this attack. Dropbox, Google, Apple, Microsoft, and others were all compromised during these attacks.
Unfortunately for somebody contemplating such an action, AIUI these attacks were based either on guessing weak passwords, or using passwords that were leaked in hacks on other sites and were used on multiple sites. As all of these companies have a requirement to keep your password secure as part of their TOS, they can't be held responsible as the clients are in breach of contract.
It doesn't matter because "nude" is not porn. Porn is sometimes defined inexactly by that "you know it when you see it" trope, but usually it entails being created for prurient interest - and nude selfies don't count as porn.
Really? Do you have any kind of reference to back that assertion up, or are you just making this shit up as you go along? Why is a "selfie" classified any differently to, say, a photo taken to be included in an adult magazine, e.g. Playboy, which I think most people would classify as "soft porn"?
I'll completely agree that nude and porn are not equivalent, but there's a significant overlap, and at least some photos of the type we're talking about is included in that.
The flip side is the rights of say Blogger users. If I post photo X as a blogger user, it should be up to me to decide if I want to take it down or not, not Google (except maybe in extreme cases, of which this doesn't seem to fall into).
The Blogger user (poster) should be the legal entity responsible for a given blog's content, not Google. Sue the Blogger user if you don't like their content, not Google.
Unfortunately, the DMCA only extends immunity from such actions to Google if they take the content down on receipt of a properly formatted request. That is, legally speaking, an ISP is only considered a common carrier as long as nobody has asked for it not to be. The Internet needs stronger protections of hosting providers, but unfortunately the IP industry has too much lobbying power to let that happen.
#2, Silver Mining. It turns out mountains don't come labelled as "gold" and "silver-only". As world affluence increases, demand for gold and silver increases.
Don't worry. It turns out that the cost of mercury is rising much faster than the cost of gold. Another decade or so of this, and it will be more economical for the gold miners just to sell their mercury stocks straight back to us.
Slashdot Mirror
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.
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[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.
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.
Exactly.
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 /c" and "cmd.exe /c" as a way to parse & execute command lines.
No.... this really comes down to not knowing, and not using, the API provided to you by the OS for handling version detection.
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.
This is exactly why all modern Javascript libraries do feature detection instead of relying on User-Agent 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?
more porn, which will continue to destroy families and relationships by commoditizing sex, spreading promiscuitity, and creating unreal expectations of sex.
[citation needed]
It isn't terribly surprising that adding a cartoonish rendering effect to both real and virtual objects would make them more difficult to discern as such. I certainly wouldn't call it more immersive - quite the opposite, in fact. It is extremely obvious that what you are looking at has been altered and that you are not looking at "reality".
Right, but "immersive" doesn't mean "difficult to distinguish from reality" but rather "easy to treat as if it were real". I mean, I used to find playing Elite on my Sinclair Spectrum "immersive", but there's not a chance I'd ever fail to know it wasn't real. Being immersive means allowing people to retain what's often called "willing suspension of disbelief" -- as long as the system I'm looking at behaves consistently, I can treat it as if it were real, so I can (at least sort-of) believe in its existence as a real thing. And maintaining that sense of existence is what people mean when they say immersion.
The filters they applied in the video make the scenes look less realistic overall, but they make them more consistent, and that lets me believe in them as real in a way I can't easily believe in the unfiltered scene.
"The only way to stop it, is to shut down the internet. Basically cut power to every networked hard drive on Earth." - _Transcendence_
And even then you'll fail. Ever heard of offline backups? :)
Or, at the very least, sue Google for something that actually makes sense, such as allowing Google Drive accounts to be accessed by hackers as part of this attack. Dropbox, Google, Apple, Microsoft, and others were all compromised during these attacks.
Unfortunately for somebody contemplating such an action, AIUI these attacks were based either on guessing weak passwords, or using passwords that were leaked in hacks on other sites and were used on multiple sites. As all of these companies have a requirement to keep your password secure as part of their TOS, they can't be held responsible as the clients are in breach of contract.
It doesn't matter because "nude" is not porn. Porn is sometimes defined inexactly by that "you know it when you see it" trope, but usually it entails being created for prurient interest - and nude selfies don't count as porn.
Really? Do you have any kind of reference to back that assertion up, or are you just making this shit up as you go along? Why is a "selfie" classified any differently to, say, a photo taken to be included in an adult magazine, e.g. Playboy, which I think most people would classify as "soft porn"?
I'll completely agree that nude and porn are not equivalent, but there's a significant overlap, and at least some photos of the type we're talking about is included in that.
The flip side is the rights of say Blogger users. If I post photo X as a blogger user, it should be up to me to decide if I want to take it down or not, not Google (except maybe in extreme cases, of which this doesn't seem to fall into).
The Blogger user (poster) should be the legal entity responsible for a given blog's content, not Google. Sue the Blogger user if you don't like their content, not Google.
Unfortunately, the DMCA only extends immunity from such actions to Google if they take the content down on receipt of a properly formatted request. That is, legally speaking, an ISP is only considered a common carrier as long as nobody has asked for it not to be. The Internet needs stronger protections of hosting providers, but unfortunately the IP industry has too much lobbying power to let that happen.
#2, Silver Mining. It turns out mountains don't come labelled as "gold" and "silver-only". As world affluence increases, demand for gold and silver increases.
Don't worry. It turns out that the cost of mercury is rising much faster than the cost of gold. Another decade or so of this, and it will be more economical for the gold miners just to sell their mercury stocks straight back to us.
Good news! Slashdot Beta now live for all users!
Extraordinary! Wave Of Geek Suicides Has Investigators Perplexed!
What has being British got to do with anything?
I suspect OP was being ironic. British English tends to include words in sentences that US English usually omits.