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).

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 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.

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.

Magnitudes are numbers.

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).

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 article goes on:

Each browser has different privacy settings, but not all of them have obvious settings for removing data created by the new Web language. Even the most proficient software engineers and developers acknowledge that deleting that data is tricky and may require multiple steps.

Again, this is patent nonsense. All browsers clear the new data sources whenever you clear cookies. The Web Storage spec explicitly advises this: "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." But if you don't believe it, just try the evercookie test I suggested above and see for yourself.

There's really nothing to see here.

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.

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.

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.

That's exactly how things work on the web, via the same-origin policy

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).

They don't. All the ones I know about put it in one directory per user (e.g., ~/.mozilla).

Or just use your browser's built-in menu option.

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.

Nothing. The article is uninformed fearmongering.

This is completely false. The Web Storage spec says:

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.

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.