Most businesses pass those worries along to payment processors like BitPay or Coinbase. It's still better because you can always in-source if you want to, so they have little leverage over you.

But yes, Bitcoin isn't an immediate replacement for cards for all online commerce. At least not yet. Volatility is a pain, but the current price is only about 5% off where it was a year ago. Presumably as Bitcoin gets older wild press-driven hype cycles will become rarer and the bubble/burst cycle of the past few years will calm down a bit. We'll have to wait and see.

I think better warnings about not updating would be good, something in the line "there are currently X known ways of compromising your system, please update to fix".

It was tried. Doesn't work. Lots of people don't even read security alerts. They just immediately find the X or close or cancel button and click it without even reading the thing they are dismissing.

The amount of time your average user wants to spend on maintaining their computer is zero. They have no notion that a computer is a thing that must be maintained and failing to do so can damage the internet. They just want to achieve their task.

The only correct way to do auto updates is automatically, silently, and not giving the user any choice in the matter. Everyone who has failed to accept this reality has ended up with their users running obsolete and insecure versions of their apps, and getting reamed in the court of public opinion as a result. If the Java team fixed their auto updater to be entirely silent and scrapped the Ask Toolbar malarky they'd have a pretty compelling platform still. But for as long as browsers are managing themselves and Java is asking permission, it will always lose.

Yes, that seems like a remarkably common problem and I'm not sure how people manage that. Serializing objects to the database? I guess if vendors get enough customer pressure to work better with Java updates they might put some effort into it, eventually.

But then the Java security holes are all sandbox escapes. You aren't using the sandbox for some enterprise time tracking app. So the need to update is less.

The fierce competition for Google Play is the iPhone app store.

So basically, you either get to bundle the best app store and go fully Google, or you get to cause your end users issues by bundling the second best app store but get to use your own solutions for other things such as search.

I think we all see the surface parallels with Microsoft, but the problem is that all Android's competitors are significantly MORE tied and MORE bundled. Historically Apple hasn't even let people put apps on their own app store that compete with their built in apps! Don't even think about carriers shipping iPhone's with customisations, let alone Yandex - it just doesn't happen. Microsoft also don't even support alternative app stores on Windows Phone at all.

In fact, Google is unique in allowing such a huge degree of customisation and unbundling of the core components. Any outcome that results in Google getting in trouble for being dramatically more open than their competitors can only be the result of horribly broken politics, not rational and even application of law.

The card signs the transaction data once the PIN is presented (the ARQC). The PIN never goes to the bank, and a MITM should not be able to modify the signature on the transaction data. So I'm not sure why you think it's vulnerable to MITM.

That's not correct. You can tip using chip and pin.

You sort of imply that this shouldn't be the case? I'm no expert but just wondering how a crook could get a PIN other than lack of reasonable protection from the owner?

There are ways but they are all incredibly convoluted. One famous scam in the UK involved a complicated phone hack involving several actors. It worked like this.

Scammer A calls the victim and claims to be from the police department. They say that there has been an outbreak of carding fraud and the victim's card needs to be replaced. Now at this point many people's BS meters go off because fraud requiring card replacement is practically non-existent. But the scammers have a neat trick - they say, you're quite right to be skeptical, why don't you call the police department back and ask for $NAME.

So the victim hangs up the phone. But unknown to them, the other side doesn't hang up and in the UK the line only closes if both sides hang up. Now the victim picks up the phone again and hears a fake dial tone played by the other side. They dial the number of the police department and hear a fake ringing. They talk to another scammer (different voice) who pretends to be a switchboard operator, who then routes them through to yet another scammer who pretends to be a detective. All on the same phone call as the first one.

The victim is now convinced that the fraud is real, because nobody could beat the callback check right? And the switchboard sounded very convincing. The detective tells them that a courier from the bank will come round to their address and issue them a replacement card soon, and the bank will be in touch shortly. At this point they hang up, now convinced. Yet another scammer phones them and claims to be from the bank. They ask for the PIN so the replacement card can be programmed correctly. Victim gives them the PIN. Then the final scammer rocks up on a motorbike with some fake delivery company logos and hands the victim a real-looking but useless card, taking their real card (with PIN) from them. Emptying the card up to its limit via an ATM happens shortly afterwards.

I don't recall who ended up being considered liable in this case, but I think the banks covered it just to avoid the bad PR. IIRC the crooks got caught anyway.

Will some Internet payment service please, please spring up and actually give Mastercard/Visa some real competition? Paypal has been largely co-opted, Bitcoin is a joke - we need something that your average Joe can and will use. So far, nothing...

You might think Bitcoin is a "joke" but it's all you're gonna get. PayPal wasn't co-opted - they settled down into the state you would expect given that they have little competition and ultimately still rely on the banking / credit card infrastructure. Why do you think any other outcome would be different? Apple isn't going to help. They aren't exactly famous for aggressively passing along cost savings to their customers, or being flexible with their policies.

The reason lots of people are working on Bitcoin, myself included, is that when you examine the problems underlying the current financial system it becomes clear that a slightly better credit card processor isn't going to cut it.

The reason you can't secure an NFC card, is that you can't generate enough power using an antenna to power up a chip which can do crypto. The most you can do is read/write a ROM, so it's not much better than an magnetic stripe.

Your info is a couple of generations out of date. Contactless EMV cards do ECDSA on chip.

So to answer your question: No, Javascript isn't really dangerous. Poorly written browser plugins are.

No, what's dangerous is software that doesn't silently auto update.

JavaScript vs Java vs ActionScript is largely irrelevant. Web browsers routinely ship fixes for dozens of JS sandbox escapes in every update they release. Web sandboxes aren't made of magic that is unavailable to other technologies. The reason most exploit kits still target Flash and Java is that modern web browsers keep themselves up to date a lot more aggressively than those plugins do/did - typically not asking for permission any more. If you dig in you'll usually find these exploit kits are exploiting bugs that were found and patched years ago. But they still work because some non-trivial fraction of the userbase always dismisses auto update requests.

In case you don't believe me, consider that in 2014 Java had no zero day exploits at all. But some people are still vulnerable to bugs from 2012. The ask forgiveness not permission auto update policy was pioneered by Google and unfortunately took a long time to become accepted as the standard due to the old mindset, especially amongst tech geeks, of "my computer is my castle".

Yes, async/await is pretty good. The primary problem with writing totally async callback driven code is the mess it makes of the readability. Rewriting code that looks blocking to be totally non-blocking with a smart compiler is a good way to resolve that weakness. Then you just have the issue of old APIs and libraries that aren't non-blocking capable. Microsoft has done a good job of trying to drive async/await through their whole standard library. Java not so much.

8mb! Wow, I didn't realise anyone was going that high. That's a lot.

I didn't know what the JVM used but just looked it up - seems it used to vary haphazardly between platforms but when they moved to 64 bit they standardised on 1mb by default. Still pretty big. I remember when the Linux kernel guys moved to 4k stacks. It broke a whole lot of drivers. 4k is pretty aggressive but still a lot larger than a compactly serialised closure.

Node is slower than a modern typed VM like the Java on the JVM or C# on .NET. Let's get that out of the way right now - Java is faster than Javascript. The reason is that Javascript source lacks a lot of info needed to efficiently map it to machine code, so V8 and other fast JSVM's all have to rely heavily on speculation. That's a fancy way of saying they guess what the code might do, compile that, and then recompile it again if it turns out they were wrong (or if the code actually changes itself at runtime which is not uncommon for dynamic languages).

Now to be clear, Java itself is actually a kind of hybrid static/dynamic language. For example all code is lazy linked and you can generate and load new code at runtime as well, if you want. All method calls are virtual by default etc. The JVM requires tons of complexity and machinery to make all that work with acceptable performance ... but it's still able to do a better job than with Javascript because the code contains more static type info up front.

So why do people think Node is fast? A couple of reasons. Partly it's because the sorts of people who are attracted to Node are the sorts of people who were previously using languages like Python, Ruby and PHP. Compared to the interpreters for those languages, V8 and thus Node really is very fast. Python/Ruby/etc don't speculate or produce machine code at all (though their JVM versions do). So, for people who code in the dynamic languages space, Node is a big step up.

Secondly, Node apps have a nasty habit of being built on NoSQL-ish database layers like MongoDB. These databases were being developed and getting hip around the same time that Node was becoming popular, so there are asynchronous database drivers for them. "Nasty" because they seem to be very frequently applied in cases where they aren't appropriate. BTW I say that as a former professional BigTable administrator, so I'm not a n00b when it comes to NoSQL databases.

In contrast most of the people developing Java/.NET web apps are usually developing business apps of various kinds and have older code bases, so they are using MySQL, PostgreSQL, Oracle, etc ..... more traditional relational databases which have only blocking drivers. That means for any web app that does database work i.e. all of them, the Java web servers will spend most of their time waiting around for the database. Whilst doing so they are holding thread stacks in memory. Thread stacks generally have to be sized at creation time for the worst case scenario, which means they tend to be large. 1mb stacks are not unheard of. Node, in contrast, requires asynchronous code at all times because V8 is not thread safe. It doesn't give you any choice in the matter. A callback closure held on the heap tends to require much less memory than a thread stack, thus, you can suspend many more computations at once when programming in this style.

If you can suspend a lot more computations simultaneously for the same amount of RAM, then you can force more traffic through a single server before it runs out of memory and falls over. And though people tend to talk about tens of thousands or hundreds of thousands of threads not scaling, actually since a bunch of major upgrades many years ago (NPTL, constant time scheduler etc) Linux has been actually able to handle bazillions of threads. The problem is that requires a very unusual programming style to achieve due to the tiny stacks, and Java/.NET aren't really designed with it in mind, so in practice nobody makes servers that work this way.

All this is a long winded way of saying that the programming style Node forces you into is genuinely more memory efficient than the thread-per-request style, and if you can fit more requests into memory at once then it will appear that a single server can "go faster" .... even if technically the code executes slower.

But here's the catch. Is it worth it? You've been able to do asynchronous programming for a loooooong time, even in Java or C#. The reason most APIs and SQL database drivers in particular don't tend to support this model well is because it imposes high costs and many people feel it isn't worth it, so the demand for better library isn't there. The biggest problem is it results in a spaghetti-like jungle of callbacks which makes for very hard to read code. I used to work at Google and the callbacks-vs-threads debates had been running there a long time. The core web search servers were all C++ and async/callback based, partly because a web search cluster is an insanely expensive thing due to the fact that the index is held in RAM, so having 10,000 queries in flight in a single server was well worth the programming pain. But that sort of thing is rare. Most web apps are not web search or WhatsApp or Facebook thumbnail serving. Most web apps can tolerate requiring more RAM if the gain is straight line code that clearly spells out the order and control flow of what's happening, because ability to debug the code and hire non-wizard programmers is worth more than some incremental throughput gain.

And if you DO want to do entirely async programming, then .NET and the JVM have tools for you to do that. C# has the async/await keywords and the JVM has Quasar. You might have to give up your nice MySQL ORM to get them, or use a simple custom driver, but the same is true in the Node world anyway. Basically Quasar/.NET async perform clever compile-time bytecode rewriting tricks to let you write code that looks blocking and straight-line but is mangled behind the scenes into the necessary callback mess. Then you only suspend the minimal needed state onto the heap instead of having a full blown thread stack per operation, and you can get Node style scalability with better-than-Node style speed.

However lots of people don't know about these options. Hence "epic battles".

Sounds like you don't enjoy Tomcat much. Me neither, though it has a lot of features. But running a Java web app doesn't require Tomcat. There's a whole market of servlet containers out there, and some of them are embeddable resulting in standalone servers if you don't like the "run the app in a big web server" model.

For example, a popular embedded servlet engine is Jetty, which has pretty good performance, easily handling hundreds of thousands of requests per second for a simple plaintext file, and seems to have better scalability than the others as concurrency ramps up.