It depends on what you mean by "cloud", which is sort of a catchall term. As you've pointed out, on SaaS clouds you're going to have no guarantee of consistency, even if no time passes -- you don't know that the cloud environment is homogeneous. For (P/I)aaS clouds, you can hopefully hold constant what software is running. For example, if you have your Ubuntu 12.04 VM that runs your software, when you fire up that VM five years from now, its software hasn't changed one bit. You of course have to worry about whether or not the form you have the VM in is even usable in five years. You would hope that, even with inevitable hardware changes, if none of the software stack changes, then you'll get the same results. I'd guess that if they're running all on hardware that really correctly implements IEEE floating-point numbers, than you will in fact get consistent results. But I wouldn't bet on it.
What you really need, unfortunately, is a library that abstracts away and quantifies the uncertainty induced by hardware limitations. There are a variety of options for these, since they're popular in scientific computing, but the overall point is that using such techniques, you can get consistent results within the stated accuracy of the library.
If you don't care about safety and error checking, multithreading, Atom SoCs, or C++11... what sort of new features are you really expecting in a compiler. That touches pretty much all the major functionality of a compiler.
It depends. From a technical standpoint, it's only reasonable to create MD5 collisions, and even then, it requires engineering both files. So, in many contexts, even MD5 collisions can be considered non-issues. A lot of P2P systems use SHA1 or SHA2, which alleviate even that problem.
Realistically, most jurisdictions don't actually trust that as evidence. A defense lawyer will ask exactly what you're asking, and then you'll be forced into the situation of explaining shadowy technical magic, which juries never like. Usually they find P2P-shared files by hash matches and then either download the files to confirm or pick the guy up and analyze his computers (which presumably contain the material). All of the evidence may not end up being presented in trial or in motions, though, depending on what's actually needed.
No shit. I saw this article and wondered how much this technology was and how soon I could have it -- if the lower insurance came even close to the cost of a driverless car, it's a no-brainer: I can spend my trips doing something better than driving!
There's another major difference, for large password-database leaks. Salted hashes can't be computed for all leaked passwords at the same time, they need to be computed once per salt. That means that cracking the whole password database at once is, computationally, just as hard as cracking each password individually. With unsalted hashes, cracking the whole password database is as hard as cracking a single password. With this password database, that's a difficulty difference of a factor of 30 million, which is pretty substantial.
Other way around. Special relativity deals with the behavior of fast-moving objects and is relevant to a number of engineering problems. General relativity deals with the behavior of objects in gravitational fields and for the most part can be ignored in engineering, but not in GPS.
Amazon sells large boxes of generic Legos. It also sells the same electronics and chemistry kits I played with as a kid. Beyond that, it also sells actual lab equipment, chemical reagents, breadboards, soldering kits, and electronic components.
Let's see. Everyone is run through those "programs", and only some come out as high achievers and well-paid professionals. If the program were the cause, then everyone would come out the same.
Let's put this one down in the "not scientifically literate" category.
You understand TFA, but TFA gets it wrong. The problem might be "the number of people/teams attempting to reproduce previous research". I'm not sure I can comment well on that. But the reproducibility of papers is not a problem. Failure to reproduce a first report of something is a normal and expected effect. The entire result is questionable! First publications of something are questionable, that's the point. A paper is not a statement of fact, but a report of an observation. The first time something is observed, the chance that it's false is high.
It may be true that we spend too much time doing the initial work and not replicating results. That's not what the article shows, though.
It conflates the reproducibility rate of publications with some idea of "trust" versus "verification". There's no evidence (presented) that this means that scientists believe what is published. The author seems to think that papers should be verified before they're published, but that's not the point of scientific publication. The publication reports what the authors did and what their results are. It is nothing stronger: it does not represent (despite authors' bombastic claims) that what they found is actually hard scientific fact. That's only accepted (in theory) when those results are reproduced. Papers about reproducing the experiments are (in theory) also published, so that a critical scientist can evaluate the body of literature about how a hypothetical scientific fact has been tested. For this reason, the first publication of some new potential fact is naturally before anyone has verified it.
Without some evidence that paper results are being widely accepted into the "scientific canon" without verification, this is just an author being confused about science. That's a bit fair, though, because the press tends to focus on first publications (they're more interesting) and reports them as if they are fact. A scientist knows better, but the public at large generally does not. It's very disingenuous of the press -- but it sells.
In fact, the only evidence presented sounds like the process works just fine. A first publication of a new thing in biotech is a potential huge advancement and gold mine. Investors, scientists, and engineers all seem to know that the rate of the first publication actually being something as opposed to spurious is low, so the first thing they do apparently is try to verify it and make sure it's really a thing. That's pretty much what you want to happen.
The signature is appended and contains a hash of the remainder of the file (what it's signing). If you could actually recreate the TrueCrypt binary in its state before it's signed, it is absolutely trivial to verify that it's the same as what was signed in the signed binary (and thus is strictly the same, minus the signature). That's not the hard part at all.
Here's what it's saying: * We can audit the TrueCrypt source code. * TrueCrypt for Windows is distributed as a binary. * We can't verify that the TrueCrypt for Windows binary is actually built from the TrueCrypt source code. * Thus, we can't (effectively) audit the TrueCrypt for Windows binary.
They give an example of one backdoor of concern in the sentence, but really the logic is true for any arbitrary security concern.
Slashdot Mirror
Look into "gliadin" if you do not already know.
Gliadin, one of the two major proteins in wheat (along with glutenin)? It's been around since wheat was wheat, at least. A bit longer than 1976.
It depends on what you mean by "cloud", which is sort of a catchall term. As you've pointed out, on SaaS clouds you're going to have no guarantee of consistency, even if no time passes -- you don't know that the cloud environment is homogeneous. For (P/I)aaS clouds, you can hopefully hold constant what software is running. For example, if you have your Ubuntu 12.04 VM that runs your software, when you fire up that VM five years from now, its software hasn't changed one bit. You of course have to worry about whether or not the form you have the VM in is even usable in five years. You would hope that, even with inevitable hardware changes, if none of the software stack changes, then you'll get the same results. I'd guess that if they're running all on hardware that really correctly implements IEEE floating-point numbers, than you will in fact get consistent results. But I wouldn't bet on it.
What you really need, unfortunately, is a library that abstracts away and quantifies the uncertainty induced by hardware limitations. There are a variety of options for these, since they're popular in scientific computing, but the overall point is that using such techniques, you can get consistent results within the stated accuracy of the library.
If you don't care about safety and error checking, multithreading, Atom SoCs, or C++11... what sort of new features are you really expecting in a compiler. That touches pretty much all the major functionality of a compiler.
Disturbingly, with data URIs, a URI can contain an image. Probably not what was meant in this case, though.
It depends. From a technical standpoint, it's only reasonable to create MD5 collisions, and even then, it requires engineering both files. So, in many contexts, even MD5 collisions can be considered non-issues. A lot of P2P systems use SHA1 or SHA2, which alleviate even that problem.
Realistically, most jurisdictions don't actually trust that as evidence. A defense lawyer will ask exactly what you're asking, and then you'll be forced into the situation of explaining shadowy technical magic, which juries never like. Usually they find P2P-shared files by hash matches and then either download the files to confirm or pick the guy up and analyze his computers (which presumably contain the material). All of the evidence may not end up being presented in trial or in motions, though, depending on what's actually needed.
Adblock is on the Chrome Web Store.
No shit. I saw this article and wondered how much this technology was and how soon I could have it -- if the lower insurance came even close to the cost of a driverless car, it's a no-brainer: I can spend my trips doing something better than driving!
There's another major difference, for large password-database leaks. Salted hashes can't be computed for all leaked passwords at the same time, they need to be computed once per salt. That means that cracking the whole password database at once is, computationally, just as hard as cracking each password individually. With unsalted hashes, cracking the whole password database is as hard as cracking a single password. With this password database, that's a difficulty difference of a factor of 30 million, which is pretty substantial.
The buzzword laden title
Don't forget: that's the title of the ScienceBlog article.
The title of the paper? Parameter Space Compression Underlies Emergent Theories and Predictive Models
I can't speak of the article because it's paywalled
How do people not know about arXiv?
So then don't. There's a ton of useful and interesting work in cybersecurity where the risk of that is basically zero.
Other way around. Special relativity deals with the behavior of fast-moving objects and is relevant to a number of engineering problems. General relativity deals with the behavior of objects in gravitational fields and for the most part can be ignored in engineering, but not in GPS.
People keep saying this.
Amazon sells large boxes of generic Legos. It also sells the same electronics and chemistry kits I played with as a kid. Beyond that, it also sells actual lab equipment, chemical reagents, breadboards, soldering kits, and electronic components.
But I guess it's easier to find a technical solution to a human problem than it is to fix the human problem.
You mean it's easier to produce translations of Web sites than to force a very large group of people to learn a new language?
Yes, yes it is.
For instance, outside of New York City, New York State has some of the most permissive gun laws in the country.
Hey, I didn't say that description of an engineer is actually accurate.
Ask BSCS grads who graduated in 2008 or earlier how much of what they learned in school is still relevant.
Almost all of it, because I learned computer science, not a programming language.
Engineers don't build bridges. Engineers design bridges. Construction workers build bridges.
Let's see. Everyone is run through those "programs", and only some come out as high achievers and well-paid professionals. If the program were the cause, then everyone would come out the same.
Let's put this one down in the "not scientifically literate" category.
You understand TFA, but TFA gets it wrong. The problem might be "the number of people/teams attempting to reproduce previous research". I'm not sure I can comment well on that. But the reproducibility of papers is not a problem. Failure to reproduce a first report of something is a normal and expected effect. The entire result is questionable! First publications of something are questionable, that's the point. A paper is not a statement of fact, but a report of an observation. The first time something is observed, the chance that it's false is high.
This is spot on.
It may be true that we spend too much time doing the initial work and not replicating results. That's not what the article shows, though.
It conflates the reproducibility rate of publications with some idea of "trust" versus "verification". There's no evidence (presented) that this means that scientists believe what is published. The author seems to think that papers should be verified before they're published, but that's not the point of scientific publication. The publication reports what the authors did and what their results are. It is nothing stronger: it does not represent (despite authors' bombastic claims) that what they found is actually hard scientific fact. That's only accepted (in theory) when those results are reproduced. Papers about reproducing the experiments are (in theory) also published, so that a critical scientist can evaluate the body of literature about how a hypothetical scientific fact has been tested. For this reason, the first publication of some new potential fact is naturally before anyone has verified it.
Without some evidence that paper results are being widely accepted into the "scientific canon" without verification, this is just an author being confused about science. That's a bit fair, though, because the press tends to focus on first publications (they're more interesting) and reports them as if they are fact. A scientist knows better, but the public at large generally does not. It's very disingenuous of the press -- but it sells.
In fact, the only evidence presented sounds like the process works just fine. A first publication of a new thing in biotech is a potential huge advancement and gold mine. Investors, scientists, and engineers all seem to know that the rate of the first publication actually being something as opposed to spurious is low, so the first thing they do apparently is try to verify it and make sure it's really a thing. That's pretty much what you want to happen.
The signature is appended and contains a hash of the remainder of the file (what it's signing). If you could actually recreate the TrueCrypt binary in its state before it's signed, it is absolutely trivial to verify that it's the same as what was signed in the signed binary (and thus is strictly the same, minus the signature). That's not the hard part at all.
Yes in theory, no in practice.
Of course, once you've audited it, you can compile the audited source and distribute that.
It's not like it's some huge problem. It just managed to get called out and picked apart.
That's not really auditing, that's reverse engineering. But yes.
It's not well-written.
Here's what it's saying:
* We can audit the TrueCrypt source code.
* TrueCrypt for Windows is distributed as a binary.
* We can't verify that the TrueCrypt for Windows binary is actually built from the TrueCrypt source code.
* Thus, we can't (effectively) audit the TrueCrypt for Windows binary.
They give an example of one backdoor of concern in the sentence, but really the logic is true for any arbitrary security concern.