Thursday, February 27, 2014

C programming: you are teaching it wrong

It's been three decades. There is no longer an excuse for the fail way colleges teach "C programming". Let me help.


Chapter 1: the debugger


C programming starts and ends with the debugger. Before they write a line of code of their own, students need to be comfortable single stepping line-by-line through source, viewing local variables, and dumping memory.

A good first assignment is run the following program, and have the student report the values for 'a' and 'b', which can only be gotten by stepping through the code in a debugger.

int main() {
    int a = rand();
    int b = rand();
    printf("a + b = %d\n", a + b);
    return 0;
}

The "printf()" function is not a debugger. If that's how you debug your code most of the time, you are doing it wrong.

GDB is not an adequate debugger. The reason people rely upon "printf()" is because GDB is too difficult. Even the "TUI" interface is inadequate.

The debugger is not your "last resort", the thing your struggle with when there is no other way to fix a bug. Instead, the debugger is the "first resort": even when your program works correctly, you still use the debugger to step through your code line-by-line, double checking variables, making sure that it's behaving the way you expect.

Wednesday, February 19, 2014

If anything, Bitcoin is inflationary

Bitcoin fails as a form of "money" according to how economists look at money. This has lead many economists to conclude that Bitcoin will fail. What it really means is that economists need to change how they look at money.

The Internet is the history of disruptive innovation. The telephony system had evolved slowly for over a 100 years, then the Internet came along and changed everything. The old engineers, steeped in telcom lore, unwilling to challenge old assumptions, claimed that the Internet would never work. And, according to their principles, it doesn't. For example, when I use Facetime with my brother who lives in Japan, there is a lot of "latency" or "lag" between when I say something and I see my brother react. That's what the old telcom engineers warned us about: the "packet switching" nature of the Internet would cause unpleasant lag in telephone calls.

But did I mention my free video call, in high definition, from my iPhone in the United States, to his iPad in Japan? That this works at all, and so cheaply, is inconceivable according to old telcom principles. No matter how right the old telcom engineers were, they were still obsolete. Nobody cares about their old principles; the Internet is a whole new set of principles of free, world-wide, high-speed connectivity.

The thing to know about JavaScript

Here's what happens to lots of people: they start learning JavaScript because it's easy, the same syntax as C and Java, but then when trying to read the source of web pages, they encounter bizarre syntax that looks nothing like the language they learned.

For example, the JavaScript in a webpage might look like the following:

$(
    function () {
        $(document).keydown(
            function (event) { 
               Typer.addText(event);
            }
        );
    }
);

This doesn't look like any JavaScript you learned, much less like a language from the C/C++ family. None of these languages has a '$' operator, for example.

But here's what's going on.

(1) The '$' isn't an operator like '+' or '&&'. Instead, it's just a letter of the alphabet, like 'a', '9', or '_'. Replace it with the letter 'x' and the syntax becomes more comprehensible. Better yet, replace with the string "JQuery", because that's a well-known JavaScript library that uses '$' as a function name.

(2) The above code is just using pointers-to-functions, a concept you know from C/C++. It's just that in JavaScript, instead of defining a function separately, then passing it as a parameter, the function can be declared in-place right there in the parameter list.

(3) JavaScript has dynamic objects. A function can query an input variable and ask "what type are you", and do something different depending on the type. In this case, if you passing in a function pointer as the parameter 'z' to "$(z)", JQuery does the equivalent had you called "$(document).ready(z)". This is the JQuery syntax for delaying calling the function 'z' until after the document has been fully loaded.

Thus, the above code can be decomposed as the following, where everything labeled "foo_..." is a name I just came up with:

var foo_query = $;
function foo_handle_keystroke(event)
{
    Typer.addText(event);
}
function foo_callme_maybe() 
{
    foo_query(document).keydown(foo_handle_keystroke);
}
foo_query(document).ready(foo_callme_maybe);

This code now looks like comprehensible C++ code. What it does is register a function for handling keystrokes once the web page has been loaded.


Coming from C/C++ or Java, you might've learned that it's possible to define anonymous functions this way, but since that's something you never did in your own language, you ignored this. When looking at your existing code, you might think that you'd use this feature rarely if at all. Then you read existing code in web-pages or NodeJS and find that this isn't a rarely used feature, and that if anything, most of the code exists in anonymous functions.

It's not just 'anonymous functions', though. What this example is really showing is that there are a lot of language-on-languages inside JavaScript. JQuery is essentially it's own programming language written in JavaScript. Likewise, NodeJS is it's own language inside JavaScript. Thus, saying that code is JavaScript doesn't fully communicate what language it's actually written in. (C++ has this problem, too, where "boost" is a fully separate language).


Since we all have to become JavaScript experts (because it's taking over the world), I thought I'd mention this quirky bit of the language.

Tuesday, February 18, 2014

No, Bitcoin value hasn't dropped to $250

My Twitter feed is full of people crowing over the fact that the value of Bitcoin has plummeted from a recent value around $1000/coin to only $250/coin. This is wrong,. They are quoting the MtGox price, not the market price. The market price is currently around $600, the MtGox price is $250.

MtGox is one of the oldest and most popular Bitcoin trading sites. The reason the MtGox price and the market price differ is because MtGox recently shut down external trading of Bitcoins. If you've got bitcoins in a MtGox account, you cannot do anything with them, except sell them to other MtGox users (internal trading). While MtGox can't externally trade the bitcoins, they can still do money transfers in dollars, euros, yen, etc.. Customers anxious to get their money out of MtGox has caused the price to plummet, as they sell bitcoins and transfer their money out of the site.

Since the coins on MtGox are useless (at the moment), the only people buying them there are speculators -- people who hope to profit $350 per coin once trading resumes at MtGox in the next few days. The moment trading resumes, speculators can transfer all their coins to a different exchange, and cash out. Speculators plan on doubling their money, betting both that MtGox will resume external trading of bitcoins and that the market price of bitcoins doesn't plummet before then.

This $350/coin MtGox risk premium is astonishing. Normally it would mean that a substantional part of the market is betting that MtGox goes out of business and steals everyone's bitcoins. But I suspect an alternate explanation: speculators can't get money into MtGox fast enough. If I were to create an account now and transfer money, it'd be a week before the funds were available to start buying bitcoins there -- by which time they'll likely to have fixed their problem. It's something I should've planned for a long time ago.


Update: Many have pointed out that you can't really get hard currency out of MtGox as well, and that the current speculators betting there is a 58% (350/600) chance the site goes bankrupt is, if anything, unrealistically low.


Monday, February 17, 2014

That "trollers are sadists" story is bogus

Some psychologists have published a study that "proves" Internet trolls are sadists. The study is nonsense. As Wikipedia says on trolls: "media attention in recent years has equated trolling with online harassment". That appears to be what happened here -- the study is really about "harassers" not "trolls". That sadism would correlate with Internet harassment is unsurprising.

The study was done through self-identification. Participants were given a questionnaire asking "What do you enjoy doing most on these comment sites?", with the choices being: "debating issues that are important to you", "chatting with other users", "making new friends", "trolling other users", and "other (specify)".

In other words, rather than objective measures based upon participants online activity, it's wholly subjective.

There are two flaws with this approach, one with how people self-identify with "trolling" and the other with how they self-identify with "debate". Those who enjoy harassing would likely describe their activity as "trolling" rather than "other". Conversely, those who objectively do the most trolling are likely to believe their activities qualify as "debate".

The word "troll" was originally coined to refer to those who did so accidentally. Pick any forum with back-and-forth comments, and you'll find lots that is incendiary, off-topic, and emotional -- from people you think what they do is "debate". Few discussions on the Internet qualify as serious debate with reasoned arguments citing unbiased sources. In other words, a discussion on taxes will be filled with emotional appeals such as "the rich don't pay their fair share" rather than citing hard fact, such data from the CBO, on precisely what share of taxes the rich pay. A more rational study would be a blind study that would identify trolls by the statements they make in online forums. And only then would the study try to correlate trolls with personality defects.

Nowadays the word "troll" also refers to people who do so intentionally. Some of these are undoubtedly sadists. The well know troll "Weev" is an example of somebody who seems to be on the harassing side of trolling. But there are also those who do so on the comedic side. For example, the twitter feed of @AnyLevy is full of humorous trolling design to provoke humorous reaction.

I can't predict what a correct study of trollers (both accidental and intentional ones) would find. I just know that the above study is wholly incorrect.



By the way, what trolls me? Bad science.


Thursday, February 13, 2014

Bitcoin QT weirdness

The "Bitcoin-QT" wallet software (the standard written by the core developers) does weird stuff underneath. Instead of directly paying from your account to recipients, it first mixes some payments with intermediate addresses that it creates inside the wallet.

It looked to me like the software was doing something malicious, secretly siphoning off extra money with each transaction it makes. Instead, it's siphoning off that money into separate accounts within your wallet.

I noticed this looking at my last transactions. It appears that Bitcoin-QT secretly siphoned off $220 worth of Bitcoin from transactions I made last month. Here is what the wallet software claims:


Here is the matching screenshot from BlockChain.info for bitcoins sent from my address 15fsz.... Notice how for each transaction there is an addition amount of money paid to these secret accounts.


Another thing to notice is that BlockChain.info sees only 5 transactions, not the 7 reported by the Bitcoin-QT software on my desktop. This requires some investigation. The following are the 7 transactions reported by Bitcoin-QT, and a link to the transaction ID on the Blockchain.info site:
  • 2014-01-23 - 0.10001000 - 6fcf3a... (Logo #2)
  • 2014-01-23 - 0.10001000 - a6e45... (Logo #1)
  • 2014-01-11 - 0.05187626 - 8f121... (Flowers)
  • 2013-06-04 - 0.83311000 - d2fb9... (Manning)
  • 2013-05-30 - 0.01050000 - 938da... (DemoDemons)
  • 2013-05-30 - 0.00550000 - 2ace7... (DemoDemons)
  • 2013-01-21 - 0.30832200 - 1be45... (don't remember)
Going back to my first debit transaction in Jan 2013, the transaction 1be45... didn't send any coins to the desired targets. Instead, it first sent the coins to two intermediate addresses, one of which is 1Ebum.... It also sent more than I requested, almost 1 full bitcoin instead of a third of a bitcoin. Later, in June 2013, when I sent the money for Manning's stenographer, instead of transfering money from my public Bitcoin address 15fsz..., it used the hidden 1Ebum... address instead.

This proves that indeed Bitcoin-QT is siphoning off money into secret accounts when you do transactions, but these are accounts in your "wallet", which it may then use later to make payments.

So why does the Bitcoin-QT wallet mix addresses this way? Maybe they think it's good for anonymization? It isn't -- it's quite easy to see the chain of payments in the blockchain.

For whatever reason they are doing this, it's a bad idea. It means I'm tied to their software. In theory, your "wallet" is just your "private key", which could be ported anywhere. This nonsense makes your wallet a complex entity, tying you to this one software. In order to extract your money from this wallet and put it into another wallet, you can't simply transfer the private keys, but instead have to put a transaction in the blockchain to a new address.



Update: Apparently, this is a "change" address, and is a feature in the Bitcoin protocol rather than Bitcoin-QT.

The protocol doesn't maintain a running balance for your address. Instead, each transaction forms it's own chain. When you spend coins, it has to chain the outgoing transaction based on previous incoming transactions. Moreover, if those incoming transactions add up to more than the outgoing transaction (which is almost always the case), it's going to have left over "change". It's got to stuff that change into another transaction somewhere. Hence, it create an internal address to send that money to.

I guess this is one of the many details I've ignored about the Bitcoin protocol. I really ought to implement my own client and play with it more.









Tuesday, February 11, 2014

You should probably call your senator

As a citizen, the most influence you have on laws is taking the time to speak with your congressional representative. The more effort you spend, the more your representative will listen. Sure, you won't actually get to talk them in person, but you will be able to talk to their staffers, which in some cases is even better.

Today, there is a widespread campaign by leftist groups asking you to inundate your representatives with robotic calls and emails. They use code to make this really easy for you. Sadly, your representatives will see it as easy, that you didn't care enough to take the effort yourself.

Instead of following the crowd, I suggest you spend the effort. Look up your representative's information (or senator) and call them or write them a handwritten (to show effort on your part) letter. Instead of repeating the phrases fed to you by activists, say in your own words what troubles you. This is especially true since the activists are feeding you misleading information (no, the NSA cannot monitor 75% of Internet traffic).

That's what I'm going to do today, speak in person with my representatives, partly to influence them to stop NSA surveillance of citizens, but mostly so that I jam the line preventing the robotic callers from getting in.


By the way, the issue that is important to me is the same sort of issue that provoked the Boston Tea Party of 1773. Britain had repealed the onerous taxes, all except the insignificant tax on tea. The reason the colonists rebelled was not because of the amount of money, which was tiny, but because "taxation without representation" was an intolerable philosophical idea. It meant that the colonists were "subjects" to be exploited by Britain, and not "free citizens" of the realm.

The same thing is true here with the Section 215 collection of phone records. In truth, the impact on citizens is insignificant and there are extensive safeguards to prevent this from being abused. None of that matters to me, as it's still surveillance of innocent citizens suspecedt of no crime. It subjugates us, and is an intolerable infringement on a free person's rights.


Anyway, those are my words. Call your representative and give them your words.




Monday, February 10, 2014

FirstLook.org fails at security so far

The new venture from Glenn Greenwald and Pierre Omidyar, "FirstLook.org", has launched with their first news articles. It has technical flaws in its security.

To start with, the website violates your privacy and tracks your behavior -- even when you have DoNotTrack set in your web browser. This is sort of an unforgivable lapse for a website setup to report on the violation of privacy by the NSA. In my browser, they send the cookie contents of "initial_referrer: http://t.co/241PQdNjwr", which tracks the fact that I came to their website by following a link from this tweet by Pierre Omidyar. (If you haven't yet gone to their site, please click on the link above so that they'll track you coming from this blogpost -- for the lulz).

Some are praising them for being the first news site based on SSL, meaning that whatever you do on their site is safe from the prying eyes of the NSA. This praise is undeserved, as the SSL is not quite working yet. 

The most noticeable flaw is that when you visit the homepage you get a warning: "this page contains other resources that are not secure". Sometimes this warning means you can be hacked. In other cases it doesn't. Here it looks relatively safe, as it's just the video downloaded from Vimeo player. But no matter how safe, it's breaking the promise of an encrypted connection, and teaches users to ignore crypto warnings.

The Qualys "ssllabs.com" site has a great tool for assessing a site's SSL security. The results for FirstLook.org are a failing grade, at least in light of the adversary (the NSA). The site supports TLS_RSA_EXPORT_WITH_RC4_40_MD5, meaning the NSA can downgrade the connection into something they can crack. The site fails to support "forward secrecy" for many browsers, meaning the NSA can either get a court order demanding encryption keys, or crack eavesdropped data over many years. They don't support SNI for some browsers, meaning that some browsers will get nasty warning messages about the domain name being wrong.

The site has scalability problems. People are already reporting getting "503" error codes and the site has only been live for a few hours. One problem may be that they use Apache, which is well-known to be hard to scale (competing software like lighthttpd and nginx are easier to scale). The Chrome "audit" tool also gives poor grade, showing that many resources on the site are not cached, and thus, must be re-requested. These scalability issues aren't necessarily an SSL concern, but exacerbate problems with SSL.


I don't know if the site is just "security washing" (just giving the appearance of security) or are really committed to the idea. Assuming they are committed, and that these are transient problems, I would hope that they document their efforts. Security is a tradeoff -- there are good reasons why competing media sites don't go to this level of effort. A commitment to SSL means a guy in Yemen can't access the website, both because of his export controlled 40 bit browser and his satellite connection causing SSL problems. A commitment to "do not track" disrupts how the business earns money and prevents some otherwise cool features you'd get with tracking the reader. Documenting all these issues, both the good and bad, would be a great boon to security for everyone.


For your reading pleasure, here is the full HTTP request headers from one of my queries. As you can see, DNT:1 is enabled, and the cookie is tracking me nonetheless:

GET /assets/javascripts/underscore-min.js HTTP/1.1
Host: firstlook.org
Connection: keep-alive
Cache-Control: no-cache
Accept: */*
Pragma: no-cache
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36
DNT: 1
Referer: https://firstlook.org/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: mp_ce2f59c033d995c677576fc3e9758d98_mixpanel=%7B%22distinct_id%22%3A%20%221441a8fb2157f0-0eb4ceedf-404c0028-3e8000-1441a8fb216a3e%22%2C%22%24initial_referrer%22%3A%20%22http%3A%2F%2Ft.co%2F241PQdNjwr%22%2C%22%24initial_referring_domain%22%3A%20%22t.co%22%7D; __utma=238902935.1222969571.1392015029.1392015029.1392015029.1; __utmc=238902935; __utmz=238902935.1392015029.1.1.utmcsr=t.co|utmccn=(referral)|utmcmd=referral|utmcct=/241PQdNjwr; _ga=GA1.2.1222969571.1392015029

Friday, February 07, 2014

I tried but could not get my phone hacked (without cheating)

In this post, I try to replicate the NBC story where their new phone got hacked in a Russian cafe even before they were finished with coffee. Two new points to add to my previous blog post on the subject:
  1. Richard Engel had to first disable the security settings that would block unknown hostile Android apps, something few users do.
  2. The Google search engine downranks hostile sites, making them hard to find. It's extraordinarily unlikely Richard Engel would've found a virus on his own without being fed specific search terms or a URL.
Knowingly disabling security, then hunting for viruses, rigs the test to the same extent as that Dateline NBC gas tank controversy where they rigged a gas tank to explode.


Here's what I did.

Thursday, February 06, 2014

That NBC story 100% fraudulent

Yesterday (Feb 5 2014) On February 4th, NBC News ran a story claiming that if you bring your mobile phone or laptop to the Sochi Olympics, it'll immediately be hacked the moment you turn it on. The story was fabricated. The technical details relate to going to the Olympics in cyberspace (visiting websites), not going to there in person and using their local WiFi.

The story shows Richard Engel "getting hacked" while in a cafe in Russia. It is wrong in every salient detail.
  1. They aren't in Sochi, but in Moscow, 1007 miles away.
  2. The "hack" happens because of the websites they visit (Olympic themed websites), not their physical location. The results would've been the same in America.
  3. The phone didn't "get" hacked; Richard Engel initiated the download of a hostile Android app onto his phone. [update here] and he had to disable the security on the phone to do it
I had expected the story to be about the situation with WiFi in Sochi, such as man-in-the-middle attacks inserting the Blackhole toolkit into web pages exploiting the latest Flash 0day. But the story was nothing of the sort.

Instead, the hacking in the story was due to the hostility of Olympic themed websites. The only increased danger from being in Russia is geolocation. Google uses your IP address to increase the of rank local sites, so you'll see more dodgy Russian sites in the results. You can disable this feature in your Google account settings.

Absolutely 0% of the story was about turning on a computer and connecting to a Sochi network. 100% of the story was about visiting websites remotely. Thus, the claim of the story that you'll get hacked immediately upon turning on your computers is fraudulent. The only thing that can be confirmed by the story is "don't let Richard Engel borrow your phone".

That leaves us with the same advice that we always give people:
  1. don't click on stuff
  2. patch your stuff (browser, Flash, PDF)
  3. get rid of the really bad stuff (Oracle's Java)
  4. don't click on stuff
  5. oh, and if you really are in Sochi, use VPN over the public WiFi
I gleaned these details from Kyle Wilhoit, the expert quoted in the story, and his Twitter feed. He's working on a blog with the full technical details. I'm sure it'll be great, with lots of details about what hackers can find with Maltego, the dangers of hostile websites, and so on -- the sort of great information totally lost in the nonsense that is the NBC story.



By the way, the easy way to figure out where journalists commit fraud is by watching for "passive voice". Journalists normally avoid passive voice, preferring stronger language. But, when they need to hide things, they passive voice to cover up details. Saying "was hacked" covers up the fact that Richard Engel hacked himself by knowingly downloading a hostile Android app. In other word, active voice wouldn't have worked, because it would have required identifying who put the virus on the phone. He couldn't report that a "hacker put the virus on the phone" because the hacker didn't, Richard Engel did. He couldn't very well have reported, in the active voice, "I downloaded the virus". Thus, the passive voice, "the phone was hacked", avoiding this inconvenient detail of who did what.



Some forums with lots of comments on this story:







Wednesday, February 05, 2014

DoS is not DDoS

Here is the thing about the Snowden Affair: however untruthful the NSA, the press has been worse. General Alexander is a liar, Glenn Greenwald is a worse liar. Every leaked article I read has gaping technical flaws.

The latest example is this story by Glenn Greenwald and NBC News claiming British intelligence performed a "DDoS" on Anonymous. To quote the article

"According to the documents, a division of Government Communications Headquarters Communications (GCHQ), the British counterpart of the NSA, shut down communications among Anonymous hacktivists by launching a “denial of service” (DDOS) attack – the same technique hackers use to take down bank, retail and government websites – making the British government the first Western government known to have conducted such an attack." -- NBC News and Glenn Greenwald

This is wrong. The acronym "DDoS" doesn't stand for "denial of service" but "distributed denial of service". The extra 'D' in added to DoS is not an insignificant detail that can be glossed over in the article, escape a fact checker, or be reported without confirmation. DDoS would result in enormous collateral damage, but a mere DoS might not.

DoS, minus the extra D, means disabling the victim's computer. An example DoS is a "syn-flood", which is apparently the attack used in this story. A syn-flood can surgically disable just a single computer without affecting nearby computes.

DDoS, with the extra D, means using a network of many attacking machines, often in the thousands, to flood a victim. It's orders of magnitude worse, with two significant problems.

The first is that the attack computers are not owned by the attacker, but are instead computers spread throughout the Internet that the attacker has infected with a virus. When nation states to use this technique, it would mean that they would not only be hacking the "legitimate" target of the DDoS, but also thousands of innocents. It's possible for a nation state to invest a lot of money and rent thousands of instances throughout the Internet, and avoid infecting innocents with viruses, but the accusation of "DDoS" implies infecting the innocent -- it's not a detail the article could have glossed over.

The second problem is that the flood of traffic is so large hat it impacts intervening networks. If I compromise computers in Tajikistan (or simply rent instances in their data centers) to use as part of my DDoS against Anonymous, I'm going to slow down that entire country's Internet connection. If I'm targeting a member of Anonymous who is using a Comcast connection, I'm going to disable the Internet for everyone in that neighborhood. It's not the computers that are damaged by the DDoS, but all the intervening links. Everyone sharing those links will be effected.

The reason the word "DDoS" appeared in the NSA document is not because it was in fact a DDoS, but because the hacktivists described it as such. That's because hacktivists are largely unskilled teenagers with a very narrow range of expression. These kids do not know how to perform surgical DoS attacks themselves, but only know large-scale DDoS.

Assuming the target was an IRC server in a colo, then it's trivially easy to DoS with a syn-flood without effecting nearby machines. I can do it form my home network on Comcast that has 10-mbps upstream. The DoS would take down IRC but with zero collateral damage.

These PowerPoints that Snowden has been leaking were themselves written by non-technical people exaggerating the actions. With so many layers of non-technical people involved (the authors and the press) it's hard to say exactly what happened. It does appear that the GCHQ takes credit for syn-flooding irc.anonops.li, but everything else is speculation. The remainder of the Greenwald/NBC article is bunk.

As a technical expert, I question every Greenwald article I've read. He seizes every opportunity to exaggerate the vague breadcrumb's found in these leaked NSA powerpoints.




Disclaimer: I think I've created the world's fastest syn-flood tool. Here's how you'd run my port-scanner masscan to do a syn-flood at 15-million packets/second. You'd need to run it from an ISP that has a 10-gbps link but no egress filtering.

# masscan 192.0.2.65 -p6667 --spoof-ip 8.0.0.0/4 --source-port 0-65535 --rate 15000000

This would cause a lot of collateral damage, since you'd be running it from a 10-gbps link targeting networks with much slower links. You can run it slower in a method like the following:

# masscan 192.0.2.65 -p6667 --spoof-ip 172.28.209.0/24 --source-port 0-65535 --rate 10000 --banners

This second command assumes you own the entire subnet address space. With the "--banners" option, instead of sending just a SYN packet, it'll hold open the entire TCP connection, leaving it open for 30 seconds. Masscan can hold open more TCP connections (in this case, 16 million) than most servers. Thus, it wouldn't be the level of traffic that would cause the DoS, which causes collateral damage, but memory/CPU, which only effects the target server.

I point out these features of my tool to point out the vast difference between the 'experts' Greenwald could consult (hackers), and the type of 'experts' he actually consults (anthropology professors).

Monday, February 03, 2014

JavaScript: the one true language

Mozilla has an excellent guide "A Reintroduction to JavaScript". It's a good read, I even found a couple points that I'd been unclear on.

The thing about JavaScript is this. It was created back in the late 1990s as a non-serious scripting language, as the little cousin to "real" languages like Java. But something strange happened, it grew up to become a real programming language. It's now the preferred language for writing apps in the browser, overtaking Java. It's also a great server-side language. JSON, meaning data structures formatted in JavaScript, is replacing XML as the standard interchange format -- even when neither side is written in JavaScript.

JavaScript is the one language you can't avoid. No matter how much you hate the language, no matter how much you prefer a different language, you are going to end up dealing with JavaScript in some form.

Thus, instead of resisting the change, you have to come up to speed on it. The above Mozilla document is excellent at this. It doesn't waste time with concepts you already know. Instead, it assumes you are already a competent programmer in some language, and that you already have a familiarity with JavaScript, and then targets the meat of the matter.