Hard sciences simply lend themselves a lot better to repeatability. Where I think we go wrong is assigning the same certainties to the claims of the soft scientists.
Granted that hard sciences are probably more reliable, but unfortunately, a lot of the research even there is shaky. I overheard roughly the following conversation between a graduate student in mathematics and his thesis adviser one summer, while I was doing undergraduate summer math research at the CUNY Graduate Center on an NSF grant (RTG):
Student: So I looked into the paper by Smith, and when I did the same computations, I got a different answer. I haven't been able to figure out what I'm doing differently. Do you think I should e-mail him?
Adviser: No. If the results are inconsistent, pretend they don't exist. Don't use them, but don't tell anyone you got different results either. If you do, then they'll just suspect that your results are wrong.
Student: Yeah, I suspect that too.
Adviser: But don't contact him, because people don't like being proven wrong. You can point out errors in people's papers once you've got tenure – it's not something you want to do as a grad student. You don't want to make this guy your enemy.
Student: Oh, okay . . .
Even if high-profile results are more reliable in the hard sciences, your average paper is still unreproducible garbage. The problem is the system, which forces everyone to publish as much as possible without heed to quality; and the journals, which publish only positive results. Researchers need to publish all their results publicly, including registering their hypotheses before they even begin the study. Universities need to take a stand by not focusing on quantity of publications. More emphasis must be placed on repeatability.
The people who treat this kind of finding as an attack on science are perpetuating the problem. We should be looking to make the scientific process ever better and more accurate as we come to understand its pitfalls better, not shrug off its inadequacies as inevitable.
As a business tool, it's all but useless. Google provides no mechanism for installing even standard Linux VPN software which most companies provide for their remote employees. Or any other software, for that matter. Also, no company with a brain in their head is going to allow employees to be storing internal data on another company's servers. This might be a little more useful if a company could customize it to use internal servers rather than Google's, but as far as I've been able to tell, that option just doesn't exist.
This was addressed in the December 7 launch event. Google has deals worked out with a number of businesses (they had a list, it was at least one or two dozen) that are extremely interested in replacing as many of their machines as possible with Chrome OS notebooks. In addition to Google Apps and internal company websites, it will support Citrix, which they had a demo of: you can log into the company's servers and run Office or any of dozens of other major corporate applications remotely. (I can't find a link to the video, sadly; I watched it live and the URL stopped working after it was over.)
The major advantage is zero maintenance burden. By design, Chrome OS notebooks are totally interchangeable. You can chuck it out the window, grab another one, enter in your Google login info, and you won't be able to tell the difference. It also will never get viruses; it updates itself without user intervention; and the lack of customizability means it's unlikely users will be able to mess it up to the point that IT has to get involved. There go all your OS-level customer support costs.
Chrome (thus presumably Chrome OS too) is also deploying features that will allow corporate admins to lock down the browser, the way IE has supported for years. The employer can require that certain extensions be installed, disable the password manager, and much more, with more features to be added as time goes on. And you can't get around it by installing another browser, because you can't install anything.
No, Chrome OS is a corporation's dream. Idiot-proof, tamper-resistant, and zero-maintenance.
Although I should add that, unfortunately, most software does use only one or two iterations of a hash function with no special tricks, so you could still brute-force even mediocre passwords on cheap hardware. But still not "superb" ones.
With an offline hash attack, you have total control over the hashes, and the only limiting factor in how fast you can attack them is your computer(and hash attacks generally parallelize really well). Here, the difference between a terrible password and a merely mediocre one will likely be less than the refresh rate of the attacker's monitor, and the difference between an OK password and a superb one will still be fairly small. Only a password so good that it is basically a nonstandardized type of private key will be of any use.
Actually, that's not true at all. If by "superb" you mean a 10-character password that uses ASCII mixed case, numbers, and punctuation, there are 95^10 ~= 6x10^19 passwords. Even if you use a fast-to-execute hash on a couple thousand dollars worth of hardware, you're only going to get in the ballpark of a billion hashes per second, which means on the order of 10^10 seconds -- i.e., centuries.
Moreover, if you choose the right hash function, brute-force becomes impractical for any but the very weakest of passwords. For instance, you can take the PBKDF approach and just iterate your hash function 10,000 times or whatnot, so that it takes (say) 100 ms to evaluate on consumer hardware instead of less than a microsecond. That knocks off two or more characters from what you can practically brute-force, without noticeably affecting user experience or server load (100 ms extra CPU time per login/registration).
If it takes 100 ms per hash, then with 16 cores you can only do 160 hashes per second. Even for passwords using only lowercase ASCII letters, it will take a day on that hardware to crack a five-character password. Want to price out even a day of computing time on 16 cores on EC2? It's called "not worth it" for most hackers. If you throw in mixed case, it's a month. If you throw in punctuation too, then even a four-character password is several days.
(GPUs can do more than an order of magnitude better here for the same price, to be fair. But if you use properly-designed hash strengthening, you can mess up GPUs too. As it happens, I'm currently working on just such a hash strengthening design for a final project in university. Looks promising so far, but I haven't gotten the current iteration of my OpenCL program to actually work yet, thanks to the vagaries of NVIDIA's OpenCL compiler. For plain SHA1, I was able to get 220 million hashes/second on an NVIDIA GTX 285. With a PBKDF scheme, it was about 10,000. I'm targeting <50 hashes/second with my design.)
Needless to say, all the above applies if you have only one password to crack. If you have a whole database of hashes, and they're salted, you need to repeat all this for every user whose password you want to crack.
I will concede that sqrt(x) means the principal square root if you will agree to always put the +/- in front of it.
I will not. That is not the conventional definition. sqrt(x) is conventionally defined as an injective, strictly increasing function from the nonnegative reals to the nonnegative reals. You can find this definition in any book on basic algebra, or in the second paragraph of the Wikipedia article, or any other source you like. If x is a positive real, then its positive square root is denoted sqrt(x), the negative root is -sqrt(x), and if you want to refer to both at once (like in the quadratic formula), you use (+/-)sqrt(x).
FTFY. There are other ways of constructing real numbers from rational numbers. You can even avoid constructing real numbers entirely, and just use an axiomatic approach (this is what is done in Aposotol's calculus text).
Although in that case you aren't proving that the reals exist and are unique in any particular set theory like ZFC, which means you can't justify set operations rigorously. If you want to be able to formally prove anything about sets of real numbers, you need to prove that such sets exist in some particular set theory. Axioms for the real numbers alone won't tell you that unions/intersections/etc. of sets of real numbers exist, let alone give you the axiom of choice (which is quite critical in analysis, at least in countable form).
As it turns out, 0.999... = 1 is true regardless of how you approach the real numbers.
As long as your definition winds up being equivalent to the conventional one. If you use a nonstandard definition, like the intuitive definition "all decimal numbers, with operations defined as you were taught in grade school", then you might wind up with something that's not even a group, let alone a complete ordered field. It's not immediately obvious to a layman why the standard definition is the most sensible one.
But even if you could not find a number between them, does it mean they have to be equal? Does your real number system (either by an axiom, or as a result of construction) require that between any two real numbers, there must be another real number?
Yes, this is a consequence of the axioms for an ordered field. One of those axioms is that for any x, y, and z, if x < y, then x + z < y + z. Thus if x < y, then x + x < x + y < y + y, applying the axiom with z = x and then z = y. Another axiom of an ordered field is that if x < y and z > 0, then xz < yz. Since 1/2 > 0, we therefore have (x + x)/2 < (x + y)/2 < (y + y)/2. But of course x = (x + x)/2 and y = (y + y)/2, so x < (x + y)/2 < y, and we've constructed a number lying strictly between them.
Of course, this doesn't help you if someone makes up a system that they want to call the real numbers but that isn't an ordered field. Like, say, "the set of all decimal expansions with finitely many digits before the decimal place and infinitely many after, with operations defined as you'd expect". In this set, 0.999... != 1, but there's no number in between. On the other hand, it's not even an additive group, since 1 - 0.999... doesn't exist.
I'm not actually sure who I'm talking to at this point. Maybe myself.
You're confusing the computer world with the mathematical world. In math, the square root of one has two solutions, +1 and -1. Square root is a short form of "Solve for x where x^2 -1 = 0." Because of the ^2, there are always two solutions, although one may be an imaginary number.
In math as well as computing, sqrt(x) is taken to be positive whenever x is a positive real number. It's known as the "principal square root". However, this convention breaks down for negative or complex numbers, and so when you're dealing with anything other than positive reals you have to be very careful when taking roots. There are many possible square root functions, and you have to specify one. Also, identities like sqrt(xy) = sqrt(x) sqrt(y) and sqrt(x^2) = x only work for positive reals. The error in the computation was assuming that sqrt(x^2) = x when x is not a positive real number (in this case x was -1).
Surely the problem is that you're assuming sqrt(1) = 1 when actually it is +- 1? You're throwing away the sign change in that step.
No, sqrt(1) is 1, and only 1. It's the "principle square root" of 1.
Had you said +-sqrt(1)=+-1, you'd be correct.
However, there is no single sensible principal square root function that works for general complex numbers. In particular, if f(z)^2 = z for all complex numbers z, f is not continuous. So as soon as you're taking the square root of anything other than nonnegative reals, you can no longer treat sqrt as a well-defined function without further specification (e.g., specifying a branch cut).
The article is nonsense. Every privacy problem mentioned either doesn't exist or predates HTML5. Every browser has a security team that carefully reviews any new features for privacy breaches and reports problems back to the standards bodies before implementation. Everyone involved in web standards is well aware of all of these issues and tries to head them off at the pass. No website can read another website's data, none can store things without the user's permission, and nothing stops users from clearing all private data at any time.
Let's look at this systematically. First of all:
The new Web language and its additional features present more tracking opportunities because the technology uses a process in which large amounts of data can be collected and stored on the user’s hard drive while online. Because of that process, advertisers and others could, experts say, see weeks or even months of personal data. That could include a user’s location, time zone, photographs, text from blogs, shopping cart contents, e-mails and a history of the Web pages visited.
Web Storage, Web SQL Database, and IndexedDB are three of the standards commonly lumped in with HTML5, and all of them do indeed allow larger amounts of data to be stored client-side than ever before. What the article doesn't mention is it's only available to the site that stored it, and users can clear it as easily as cookies. It poses absolutely no privacy threat beyond cookies: if a server wants to store data on your computer, it can already just store it on the server and store a short identifying key as the cookie.
What the unnamed "experts" here say is therefore crazy. Nothing in HTML allows advertisers to see your location or time zone without your consent, let alone shopping cart contents or e-mail. Since the article doesn't deign to specify what HTML5 technologies are supposed to be able to do this magic, I can't refute it beyond saying it's just nonsense.
The new Web language “gives trackers one more bucket to put tracking information into,” said Hakon Wium Lie, the chief technology officer at Opera, a browser company.
Hâkon knows what he's talking about – he's a notable figure in the web standards community, editing such high-profile standards as CSS 2.1. But look at what he says carefully: trackers get "one more bucket". One more just like all the others, which can be controlled and cleared along with all the others, thus no greater privacy risk. I'd bet good money that this quote of his is taken completely out of context, and that he was dismissing the reporter's fearmongering.
Then there's mention of evercookie. But nothing that evercookie does relies on any HTML5 feature. Yes, it stores things in four different types of HTML5 storage, but again, those are cleared just like cookies. Try it yourself: create an evercookie on that page, clear your cookies from your browser's menus, and then click to rediscover cookies. You'll see that the four HTML5 methods (localData, globalData, sessionData, dbData) are all cleared too.
(There is one other mention of HTML5 on evercookie's page, but it's red herring. The pngData mechanism uses HTML5 canvas, but if you look at how it works, it would work just as easily by storing a JavaScript file or even a plain text file, and retrieving it via <script> or XMLHttpRequest.)
It's worth emphasizing, by the way, that using your browser's "private browsing mode" (whatever it's called) will completely defeat evercookie. So this is not some earth-shattering problem that no one's thought of.
The browsers should come out of the box with those settings. There is no good reason for 3rd party anything (cookies, flash, images) other than bad web development, injection of bad content or tracking for nefarious purposes.
This might have been tenable if it had been the policy since day one, but now there are billions of sites that expect third-party content to work. Browsers can't just disable that, or their users will say "All my websites don't work anymore!" and switch to a competitor, or refuse to upgrade.
Same with HTML5. There is no reason that website x needs to be able to read the content of website y. It also doesn't need to access your browser settings or anything outside of the window where the website renders (that is buttons, history, other cookies, preferences or bookmarks).
I'm glad you think so, because HTML5 doesn't allow any of those things, any more than any previous web technologies did. The exceptions are minor and carefully crafted: e.g., websites can communicate using postMessage(), but only if both of them cooperate, so there's no security or privacy breach.
The browsers should let users control their data and privacy settings. Let users disable the new features just like the users who are truly concerned shut off 3rd party cookies and JS.
I'm guessing they do. If you restrict cookies, I'm going to bet that most browsers will apply the exact same restrictions to other forms of client storage that they control. The same button to clear cookies clears localStorage and so on, you can check that.
i don't have a problem with a website seeing everything i do on that website. i have a problem with a website seeing what i do on other websites
let foo.com have evercookies on my computer about everything i do... at foo.com. not a problem. but i don't ever want foo.com too see what i do at fubar.com, and visa versa
actually, now that i think about it, that's a fatal hole in any browser privacy: if a webpage is serving content from another website, such as with advertising networks, we're pretty much doomed no matter what the markup language, aren't we?
Yep. If the sites you go to can store info about you, and they include ads, the ads can also store info about you, unless the site takes efforts to stop it (which the ad companies wouldn't allow).
Browsers should no longer be allowed to frisk about in the general operating system,
scattering data willy nilly throughout your computer into wildly obscure folders.
They don't. All the ones I know about put it in one directory per user (e.g., ~/.mozilla).
You want to delete all the tracking information? Delete the sandbox.
As for "buckets to put tracking information into" why bother relying on "buckets" on the client which may or may not exist, are limited in size, may change or be emptied at any time, etc, when you can buy as many "buckets" as you want server-side and store virtually unlimited data about them?
Mainly, caching and offline access. When I access Gmail from my Android phone, I can read my e-mail offline, and browsing my inbox is instantly responsive even if my connection is very slow. This is because it just caches my whole inbox, any other tags I tell it to, and all mail from the last few days. If the Gmail website did that, which it can using localStorage, I wouldn't have to wait ten seconds sometimes to flip to the next e-mail while it retrieves it from the server.
It's also just easier to use, if you're writing an application in JavaScript, because you don't have to bother with any server-side logic. You could even store data on a page that's totally static. Of course, that's not useful for anything important, but if you're storing transient preferences (e.g., "this menu should be collapsed") that only JavaScript will care about, there's no sense in storing them in cookies – they'll have to be sent on every HTTP request then.
Folks, I thought this isn't new at all. Don't cookies do the same thing? I have a cookie that will 'never' expire unless I delete it. What am I missing?
Folks, I thought this isn't new at all. Don't cookies do the same thing? I have a cookie that will 'never' expire unless I delete it. What am I missing?
That, in combination with html5 local databases, you can create cookies that cannot be deleted. Ever.
If users attempt to protect their privacy by clearing cookies without also clearing data stored in the local storage area, sites can defeat those attempts by using the two features as redundant backup for each other. User agents should present the interfaces for clearing these in a way that helps users to understand this possibility and enables them to delete data in all persistent storage features simultaneously.
In practice, this is what browsers do. Every time you clear cookies, you clear all persistent storage that the browser controls – leaving only things like Flash storage, and of course things that are stored on the server rather than the client. If you're referring to Evercookie, that has nothing to do with HTML5.
Genuine question - if people honestly don't care, then is it really a problem?
The problem is that users are given a tradeoff: either they enable cookies and let people track them, or disable cookies and break all the sites they use. Offered that decision, most people will rationally opt for the latter. The goal is to give them a third option: let sites work properly without privacy or security problems.
Web standards try to give apps as much power as possible without hurting privacy or security more than before, so you don't have to trade off here-and-now features to fend off abstract threats. Other application frameworks, like conventional binaries, don't even try: if you run the program, you have to trust it completely.
An example of one technology that tries this and gets it wrong is Android. You can decide what privileges to give an app before you install it, but popular apps often ask for lots of unreasonable privileges, so in practice most people ignore the risks and just install the things. On the web, applications can do the large majority of useful things Android apps can do (if you count cutting-edge standards that aren't widely supported yet), but few of the harmful things. This puts users in a much better position: they don't lose many features, but they're at much lower risk.
So, yes, it is a problem, and it is fixable, and the web is the only way forward toward fixing it. Others have tried, like Bitfrost, but only the web has enough momentum to build a real application base around the idea of totally untrusted applications that are still really useful.
Is the change that there is more space for cookies? up till now its been like a few 100 kbs right?
Roughly speaking, yes. Cookies are sent on every HTTP request, so they can't be longer than a few kilobytes in practice (100 KB is unlikely to work). localStorage and friends are typically more in the ballpark of a few megabytes per site, and since it's only accessible to local JavaScript rather than being sent over the network, it can really be unlimited. It's only kept to a few megs by default so that you don't get zillions of sites each storing a bunch of data and eating up your disk space. So without the new client-side storage mechanisms, you have to store the data on the server and ferry it back and forth if it's too big to fit in cookies.
It's a very similar problem to the privacy concerns over Flash about 6 or 7 years ago. When people realized you could store a lot of information separate from standard browser cache, people started taking advantage of the situation until it was patched. Similar things with HTML5, breeches will be discovered, then much later get patched after the damage is done.
It's not similar at all. The problem with Flash is that users who clicked "Clear my cookies", or even used their browser's privacy mode, would still not clear Flash's data – because Flash is a totally separate program. The HTML5 browsers are part of the browser and integrated into it, so clearing localStorage/sessionStorage/WebDB/etc. is no additional effort when you clear your cookies.
Try it yourself and see. On Chrome, for instance, it's wrench -> Preferences -> Under the Hood -> Clear Browsing Data.... The option to clear HTML5 storage is exactly the same as for cookies: "Delete cookies and other site data". Firefox also doesn't seem to even give a separate option, it's all seamlessly integrated.
What features does HTML5 include that let one server access any data other than that created by that server, or by the client user through the HTML GUI sent by that server?
None. The new storage mechanisms use the same access control as cookies, and browsers clear them as well whenever you clear cookies. Evercookie has nothing to do with HTML5. TFA is uninformed FUD.
Alright, it seems I spoke way too fast. I did some research on HTML (checked wikipedia) and it seems that updating HTML twice a year would be reckless. However, HTML4 was published as a W3C recommendation in 1997. Just to put that in perspective Windows98 and Napster were yet to happen. This is what AOL.com looked like at the time.
I respect what we've been able to achieve on this platform, but I can't help but feel it is holding us back as well.
The reason for this is because the W3C got derailed by XHTML. Work was focused for years on impractical specs that browsers didn't want to implement, like XHTML 2 and XForms. HTML5 only started in about 2004, so that's about seven years of zero new standardized HTML features. If you look at it that way, we've seen pretty decent progress in the last few years. Most of the delay is is the implementation, not the actual standards-writing. The HTML5 editor is avoiding large additions while he waits for implementations of what's already specced – you don't have implementers twiddling their thumbs because they have no standards to implement.
...just a guy who happens to be part of the W3C stating his personal opinion. There is no official press release or publication on the W3C site itself--and, for that matter, not even any on this guy's personal web page or Twitter feed (when did he even say this?).
A guy who "happens" to be leader of the entire Interaction Domain, including HTML (and CSS, SVG, etc.). So, yes, it's not an official W3C statement, but Philippe Le Hégaret is not just "a guy who happens to be part of the W3C".
The W3C is vastly smaller and less bureaucratic than ISO, and also more open. The HTML Working Group conducts its business exclusively on Bugzilla and the public-html mailing list, so if Microsoft were trying anything, everyone would see it. Nothing is done by vote in the HTMLWG, so Microsoft can't try to buy votes secretly. All decisions are made by either the editor (employed by Google) or the co-chairs (one employed by Microsoft, one Apple, one IBM). And everything is being overseen by the W3C administration; you can literally appeal directly to Tim Berners-Lee if you have a problem with the chairs' decision, and people have done that.
Nothing underhanded is going on here. Microsoft can mainly be faulted for not participating much, not for trying to subvert anything.
Slashdot Mirror
Hard sciences simply lend themselves a lot better to repeatability. Where I think we go wrong is assigning the same certainties to the claims of the soft scientists.
Granted that hard sciences are probably more reliable, but unfortunately, a lot of the research even there is shaky. I overheard roughly the following conversation between a graduate student in mathematics and his thesis adviser one summer, while I was doing undergraduate summer math research at the CUNY Graduate Center on an NSF grant (RTG):
Even if high-profile results are more reliable in the hard sciences, your average paper is still unreproducible garbage. The problem is the system, which forces everyone to publish as much as possible without heed to quality; and the journals, which publish only positive results. Researchers need to publish all their results publicly, including registering their hypotheses before they even begin the study. Universities need to take a stand by not focusing on quantity of publications. More emphasis must be placed on repeatability.
The people who treat this kind of finding as an attack on science are perpetuating the problem. We should be looking to make the scientific process ever better and more accurate as we come to understand its pitfalls better, not shrug off its inadequacies as inevitable.
As a business tool, it's all but useless. Google provides no mechanism for installing even standard Linux VPN software which most companies provide for their remote employees. Or any other software, for that matter. Also, no company with a brain in their head is going to allow employees to be storing internal data on another company's servers. This might be a little more useful if a company could customize it to use internal servers rather than Google's, but as far as I've been able to tell, that option just doesn't exist.
This was addressed in the December 7 launch event. Google has deals worked out with a number of businesses (they had a list, it was at least one or two dozen) that are extremely interested in replacing as many of their machines as possible with Chrome OS notebooks. In addition to Google Apps and internal company websites, it will support Citrix, which they had a demo of: you can log into the company's servers and run Office or any of dozens of other major corporate applications remotely. (I can't find a link to the video, sadly; I watched it live and the URL stopped working after it was over.)
The major advantage is zero maintenance burden. By design, Chrome OS notebooks are totally interchangeable. You can chuck it out the window, grab another one, enter in your Google login info, and you won't be able to tell the difference. It also will never get viruses; it updates itself without user intervention; and the lack of customizability means it's unlikely users will be able to mess it up to the point that IT has to get involved. There go all your OS-level customer support costs.
Chrome (thus presumably Chrome OS too) is also deploying features that will allow corporate admins to lock down the browser, the way IE has supported for years. The employer can require that certain extensions be installed, disable the password manager, and much more, with more features to be added as time goes on. And you can't get around it by installing another browser, because you can't install anything.
No, Chrome OS is a corporation's dream. Idiot-proof, tamper-resistant, and zero-maintenance.
Although I should add that, unfortunately, most software does use only one or two iterations of a hash function with no special tricks, so you could still brute-force even mediocre passwords on cheap hardware. But still not "superb" ones.
With an offline hash attack, you have total control over the hashes, and the only limiting factor in how fast you can attack them is your computer(and hash attacks generally parallelize really well). Here, the difference between a terrible password and a merely mediocre one will likely be less than the refresh rate of the attacker's monitor, and the difference between an OK password and a superb one will still be fairly small. Only a password so good that it is basically a nonstandardized type of private key will be of any use.
Actually, that's not true at all. If by "superb" you mean a 10-character password that uses ASCII mixed case, numbers, and punctuation, there are 95^10 ~= 6x10^19 passwords. Even if you use a fast-to-execute hash on a couple thousand dollars worth of hardware, you're only going to get in the ballpark of a billion hashes per second, which means on the order of 10^10 seconds -- i.e., centuries.
Moreover, if you choose the right hash function, brute-force becomes impractical for any but the very weakest of passwords. For instance, you can take the PBKDF approach and just iterate your hash function 10,000 times or whatnot, so that it takes (say) 100 ms to evaluate on consumer hardware instead of less than a microsecond. That knocks off two or more characters from what you can practically brute-force, without noticeably affecting user experience or server load (100 ms extra CPU time per login/registration).
If it takes 100 ms per hash, then with 16 cores you can only do 160 hashes per second. Even for passwords using only lowercase ASCII letters, it will take a day on that hardware to crack a five-character password. Want to price out even a day of computing time on 16 cores on EC2? It's called "not worth it" for most hackers. If you throw in mixed case, it's a month. If you throw in punctuation too, then even a four-character password is several days.
(GPUs can do more than an order of magnitude better here for the same price, to be fair. But if you use properly-designed hash strengthening, you can mess up GPUs too. As it happens, I'm currently working on just such a hash strengthening design for a final project in university. Looks promising so far, but I haven't gotten the current iteration of my OpenCL program to actually work yet, thanks to the vagaries of NVIDIA's OpenCL compiler. For plain SHA1, I was able to get 220 million hashes/second on an NVIDIA GTX 285. With a PBKDF scheme, it was about 10,000. I'm targeting <50 hashes/second with my design.)
Needless to say, all the above applies if you have only one password to crack. If you have a whole database of hashes, and they're salted, you need to repeat all this for every user whose password you want to crack.
I will concede that sqrt(x) means the principal square root if you will agree to always put the +/- in front of it.
I will not. That is not the conventional definition. sqrt(x) is conventionally defined as an injective, strictly increasing function from the nonnegative reals to the nonnegative reals. You can find this definition in any book on basic algebra, or in the second paragraph of the Wikipedia article, or any other source you like. If x is a positive real, then its positive square root is denoted sqrt(x), the negative root is -sqrt(x), and if you want to refer to both at once (like in the quadratic formula), you use (+/-)sqrt(x).
FTFY. There are other ways of constructing real numbers from rational numbers. You can even avoid constructing real numbers entirely, and just use an axiomatic approach (this is what is done in Aposotol's calculus text).
Although in that case you aren't proving that the reals exist and are unique in any particular set theory like ZFC, which means you can't justify set operations rigorously. If you want to be able to formally prove anything about sets of real numbers, you need to prove that such sets exist in some particular set theory. Axioms for the real numbers alone won't tell you that unions/intersections/etc. of sets of real numbers exist, let alone give you the axiom of choice (which is quite critical in analysis, at least in countable form).
As it turns out, 0.999... = 1 is true regardless of how you approach the real numbers.
As long as your definition winds up being equivalent to the conventional one. If you use a nonstandard definition, like the intuitive definition "all decimal numbers, with operations defined as you were taught in grade school", then you might wind up with something that's not even a group, let alone a complete ordered field. It's not immediately obvious to a layman why the standard definition is the most sensible one.
But even if you could not find a number between them, does it mean they have to be equal? Does your real number system (either by an axiom, or as a result of construction) require that between any two real numbers, there must be another real number?
Yes, this is a consequence of the axioms for an ordered field. One of those axioms is that for any x, y, and z, if x < y, then x + z < y + z. Thus if x < y, then x + x < x + y < y + y, applying the axiom with z = x and then z = y. Another axiom of an ordered field is that if x < y and z > 0, then xz < yz. Since 1/2 > 0, we therefore have (x + x)/2 < (x + y)/2 < (y + y)/2. But of course x = (x + x)/2 and y = (y + y)/2, so x < (x + y)/2 < y, and we've constructed a number lying strictly between them.
Of course, this doesn't help you if someone makes up a system that they want to call the real numbers but that isn't an ordered field. Like, say, "the set of all decimal expansions with finitely many digits before the decimal place and infinitely many after, with operations defined as you'd expect". In this set, 0.999... != 1, but there's no number in between. On the other hand, it's not even an additive group, since 1 - 0.999... doesn't exist.
I'm not actually sure who I'm talking to at this point. Maybe myself.
Sqrt is assumed to be positive because it represents a magnitude, not a number.
Magnitudes are numbers.
You're confusing the computer world with the mathematical world. In math, the square root of one has two solutions, +1 and -1. Square root is a short form of "Solve for x where x^2 -1 = 0." Because of the ^2, there are always two solutions, although one may be an imaginary number.
In math as well as computing, sqrt(x) is taken to be positive whenever x is a positive real number. It's known as the "principal square root". However, this convention breaks down for negative or complex numbers, and so when you're dealing with anything other than positive reals you have to be very careful when taking roots. There are many possible square root functions, and you have to specify one. Also, identities like sqrt(xy) = sqrt(x) sqrt(y) and sqrt(x^2) = x only work for positive reals. The error in the computation was assuming that sqrt(x^2) = x when x is not a positive real number (in this case x was -1).
No, sqrt(1) is 1, and only 1. It's the "principle square root" of 1.
Had you said +-sqrt(1)=+-1, you'd be correct.
However, there is no single sensible principal square root function that works for general complex numbers. In particular, if f(z)^2 = z for all complex numbers z, f is not continuous. So as soon as you're taking the square root of anything other than nonnegative reals, you can no longer treat sqrt as a well-defined function without further specification (e.g., specifying a branch cut).
The article is nonsense. Every privacy problem mentioned either doesn't exist or predates HTML5. Every browser has a security team that carefully reviews any new features for privacy breaches and reports problems back to the standards bodies before implementation. Everyone involved in web standards is well aware of all of these issues and tries to head them off at the pass. No website can read another website's data, none can store things without the user's permission, and nothing stops users from clearing all private data at any time.
Let's look at this systematically. First of all:
Web Storage, Web SQL Database, and IndexedDB are three of the standards commonly lumped in with HTML5, and all of them do indeed allow larger amounts of data to be stored client-side than ever before. What the article doesn't mention is it's only available to the site that stored it, and users can clear it as easily as cookies. It poses absolutely no privacy threat beyond cookies: if a server wants to store data on your computer, it can already just store it on the server and store a short identifying key as the cookie.
What the unnamed "experts" here say is therefore crazy. Nothing in HTML allows advertisers to see your location or time zone without your consent, let alone shopping cart contents or e-mail. Since the article doesn't deign to specify what HTML5 technologies are supposed to be able to do this magic, I can't refute it beyond saying it's just nonsense.
Hâkon knows what he's talking about – he's a notable figure in the web standards community, editing such high-profile standards as CSS 2.1. But look at what he says carefully: trackers get "one more bucket". One more just like all the others, which can be controlled and cleared along with all the others, thus no greater privacy risk. I'd bet good money that this quote of his is taken completely out of context, and that he was dismissing the reporter's fearmongering.
Then there's mention of evercookie. But nothing that evercookie does relies on any HTML5 feature. Yes, it stores things in four different types of HTML5 storage, but again, those are cleared just like cookies. Try it yourself: create an evercookie on that page, clear your cookies from your browser's menus, and then click to rediscover cookies. You'll see that the four HTML5 methods (localData, globalData, sessionData, dbData) are all cleared too.
(There is one other mention of HTML5 on evercookie's page, but it's red herring. The pngData mechanism uses HTML5 canvas, but if you look at how it works, it would work just as easily by storing a JavaScript file or even a plain text file, and retrieving it via <script> or XMLHttpRequest.)
It's worth emphasizing, by the way, that using your browser's "private browsing mode" (whatever it's called) will completely defeat evercookie. So this is not some earth-shattering problem that no one's thought of.
The article goes on:
The browsers should come out of the box with those settings. There is no good reason for 3rd party anything (cookies, flash, images) other than bad web development, injection of bad content or tracking for nefarious purposes.
This might have been tenable if it had been the policy since day one, but now there are billions of sites that expect third-party content to work. Browsers can't just disable that, or their users will say "All my websites don't work anymore!" and switch to a competitor, or refuse to upgrade.
Same with HTML5. There is no reason that website x needs to be able to read the content of website y. It also doesn't need to access your browser settings or anything outside of the window where the website renders (that is buttons, history, other cookies, preferences or bookmarks).
I'm glad you think so, because HTML5 doesn't allow any of those things, any more than any previous web technologies did. The exceptions are minor and carefully crafted: e.g., websites can communicate using postMessage(), but only if both of them cooperate, so there's no security or privacy breach.
The browsers should let users control their data and privacy settings. Let users disable the new features just like the users who are truly concerned shut off 3rd party cookies and JS.
I'm guessing they do. If you restrict cookies, I'm going to bet that most browsers will apply the exact same restrictions to other forms of client storage that they control. The same button to clear cookies clears localStorage and so on, you can check that.
i don't have a problem with a website seeing everything i do on that website. i have a problem with a website seeing what i do on other websites
let foo.com have evercookies on my computer about everything i do... at foo.com. not a problem. but i don't ever want foo.com too see what i do at fubar.com, and visa versa
That's exactly how things work on the web, via the same-origin policy
actually, now that i think about it, that's a fatal hole in any browser privacy: if a webpage is serving content from another website, such as with advertising networks, we're pretty much doomed no matter what the markup language, aren't we?
Yep. If the sites you go to can store info about you, and they include ads, the ads can also store info about you, unless the site takes efforts to stop it (which the ad companies wouldn't allow).
Browsers should no longer be allowed to frisk about in the general operating system, scattering data willy nilly throughout your computer into wildly obscure folders.
They don't. All the ones I know about put it in one directory per user (e.g., ~/.mozilla).
You want to delete all the tracking information? Delete the sandbox.
Or just use your browser's built-in menu option.
As for "buckets to put tracking information into" why bother relying on "buckets" on the client which may or may not exist, are limited in size, may change or be emptied at any time, etc, when you can buy as many "buckets" as you want server-side and store virtually unlimited data about them?
Mainly, caching and offline access. When I access Gmail from my Android phone, I can read my e-mail offline, and browsing my inbox is instantly responsive even if my connection is very slow. This is because it just caches my whole inbox, any other tags I tell it to, and all mail from the last few days. If the Gmail website did that, which it can using localStorage, I wouldn't have to wait ten seconds sometimes to flip to the next e-mail while it retrieves it from the server.
It's also just easier to use, if you're writing an application in JavaScript, because you don't have to bother with any server-side logic. You could even store data on a page that's totally static. Of course, that's not useful for anything important, but if you're storing transient preferences (e.g., "this menu should be collapsed") that only JavaScript will care about, there's no sense in storing them in cookies – they'll have to be sent on every HTTP request then.
Folks, I thought this isn't new at all. Don't cookies do the same thing? I have a cookie that will 'never' expire unless I delete it. What am I missing?
Nothing. The article is uninformed fearmongering.
Folks, I thought this isn't new at all. Don't cookies do the same thing? I have a cookie that will 'never' expire unless I delete it. What am I missing?
That, in combination with html5 local databases, you can create cookies that cannot be deleted. Ever.
This is completely false. The Web Storage spec says:
In practice, this is what browsers do. Every time you clear cookies, you clear all persistent storage that the browser controls – leaving only things like Flash storage, and of course things that are stored on the server rather than the client. If you're referring to Evercookie, that has nothing to do with HTML5.
Genuine question - if people honestly don't care, then is it really a problem?
The problem is that users are given a tradeoff: either they enable cookies and let people track them, or disable cookies and break all the sites they use. Offered that decision, most people will rationally opt for the latter. The goal is to give them a third option: let sites work properly without privacy or security problems.
Web standards try to give apps as much power as possible without hurting privacy or security more than before, so you don't have to trade off here-and-now features to fend off abstract threats. Other application frameworks, like conventional binaries, don't even try: if you run the program, you have to trust it completely.
An example of one technology that tries this and gets it wrong is Android. You can decide what privileges to give an app before you install it, but popular apps often ask for lots of unreasonable privileges, so in practice most people ignore the risks and just install the things. On the web, applications can do the large majority of useful things Android apps can do (if you count cutting-edge standards that aren't widely supported yet), but few of the harmful things. This puts users in a much better position: they don't lose many features, but they're at much lower risk.
So, yes, it is a problem, and it is fixable, and the web is the only way forward toward fixing it. Others have tried, like Bitfrost, but only the web has enough momentum to build a real application base around the idea of totally untrusted applications that are still really useful.
Is the change that there is more space for cookies? up till now its been like a few 100 kbs right?
Roughly speaking, yes. Cookies are sent on every HTTP request, so they can't be longer than a few kilobytes in practice (100 KB is unlikely to work). localStorage and friends are typically more in the ballpark of a few megabytes per site, and since it's only accessible to local JavaScript rather than being sent over the network, it can really be unlimited. It's only kept to a few megs by default so that you don't get zillions of sites each storing a bunch of data and eating up your disk space. So without the new client-side storage mechanisms, you have to store the data on the server and ferry it back and forth if it's too big to fit in cookies.
It's a very similar problem to the privacy concerns over Flash about 6 or 7 years ago. When people realized you could store a lot of information separate from standard browser cache, people started taking advantage of the situation until it was patched. Similar things with HTML5, breeches will be discovered, then much later get patched after the damage is done.
It's not similar at all. The problem with Flash is that users who clicked "Clear my cookies", or even used their browser's privacy mode, would still not clear Flash's data – because Flash is a totally separate program. The HTML5 browsers are part of the browser and integrated into it, so clearing localStorage/sessionStorage/WebDB/etc. is no additional effort when you clear your cookies.
Try it yourself and see. On Chrome, for instance, it's wrench -> Preferences -> Under the Hood -> Clear Browsing Data.... The option to clear HTML5 storage is exactly the same as for cookies: "Delete cookies and other site data". Firefox also doesn't seem to even give a separate option, it's all seamlessly integrated.
What features does HTML5 include that let one server access any data other than that created by that server, or by the client user through the HTML GUI sent by that server?
None. The new storage mechanisms use the same access control as cookies, and browsers clear them as well whenever you clear cookies. Evercookie has nothing to do with HTML5. TFA is uninformed FUD.
Alright, it seems I spoke way too fast. I did some research on HTML (checked wikipedia) and it seems that updating HTML twice a year would be reckless. However, HTML4 was published as a W3C recommendation in 1997. Just to put that in perspective Windows98 and Napster were yet to happen. This is what AOL.com looked like at the time. I respect what we've been able to achieve on this platform, but I can't help but feel it is holding us back as well.
The reason for this is because the W3C got derailed by XHTML. Work was focused for years on impractical specs that browsers didn't want to implement, like XHTML 2 and XForms. HTML5 only started in about 2004, so that's about seven years of zero new standardized HTML features. If you look at it that way, we've seen pretty decent progress in the last few years. Most of the delay is is the implementation, not the actual standards-writing. The HTML5 editor is avoiding large additions while he waits for implementations of what's already specced – you don't have implementers twiddling their thumbs because they have no standards to implement.
...just a guy who happens to be part of the W3C stating his personal opinion. There is no official press release or publication on the W3C site itself--and, for that matter, not even any on this guy's personal web page or Twitter feed (when did he even say this?).
A guy who "happens" to be leader of the entire Interaction Domain, including HTML (and CSS, SVG, etc.). So, yes, it's not an official W3C statement, but Philippe Le Hégaret is not just "a guy who happens to be part of the W3C".
I would bet on it. Look what Microsoft did with OOXML to damage ISO
The W3C is vastly smaller and less bureaucratic than ISO, and also more open. The HTML Working Group conducts its business exclusively on Bugzilla and the public-html mailing list, so if Microsoft were trying anything, everyone would see it. Nothing is done by vote in the HTMLWG, so Microsoft can't try to buy votes secretly. All decisions are made by either the editor (employed by Google) or the co-chairs (one employed by Microsoft, one Apple, one IBM). And everything is being overseen by the W3C administration; you can literally appeal directly to Tim Berners-Lee if you have a problem with the chairs' decision, and people have done that.
Nothing underhanded is going on here. Microsoft can mainly be faulted for not participating much, not for trying to subvert anything.