We had plenty of choices for dial-up too, what we lacked particularly in the UK was free local calls, that made modem calls expensive compared to the US. Since then everything has been going our way.

However, the issue of free vs metered local calls hasn't been relevant for a long time. I don't think government intervention is a great explanation either, given that the UK telecoms network was privatised.

For large parts of Europe I think there's a simpler explanation - a combination of population density and more regional competition with ISPs. Whereas in the USA you have a handful of nationwide ISPs. There's no equivalent of Verizon or Comcast in Europe that serves the entire continent.

There will -always- be flaws. However, part of a company selling security is how they respond to issues, and here, BlackPhone has performed quite well. There was a problem, they fixed it, and that is what matters.

I agree that how a company handles incident response is important and the BlackPhone guys have apparently handled this well.

However, there are several things that are troubling about this story which lead me to not trust BlackPhone and question the security experience of the people designing it.

The first thing we notice about this exploit is that the library in question appears to be written in C, even though it's newly written code that is parsing complex data structures straight off the wire from people who might be attackers. What is this, 1976? These guys aren't programming smartcard chips without an OS, they're writing a text messaging app that runs on phones in which the OS is written in Java. Why the hell is the core of their secure messaging protocol written in C?

The second thing we notice is that the bug occurs due to a type confusion attack whilst parsing JSON. JSON?! Yup, SCIMP messages apparently contain binary signatures which are base 64 encoded, wrapped in JSON, and then base64 encoded again. A more bizarre or error-prone format is difficult to imagine. They manage to combine the efficiency of double-base64 encoding binary data with the tightness and simplicity of a text based format inspired by a scripting language which has, for example, only one kind of number (floating point). They get the joy of handling many different kinds of whitespace, escaping bugs, etc. And to repeat, they are parsing this mess of unneeded complexity .... in C.

Compare this to TextSecure, an app that does the same thing as the BlackPhone SMS app. TextSecure is written by Moxie Marlinspike, a man who Knows What He Is Doing(tm). TextSecure uses protocol buffers, a very simple and efficient binary format with a schema language and compiler. There is minimal scope for type confusion. Moreover, the entire app is written in Java, so there is no possibility of memory management errors whilst trying to read messages crafted by an attacker. By doing things this way they eliminate entire categories of bugs in one fell swoop.

So yes, whilst the BlackPhone team should be commended for getting a patch out to their users, this whole incident just raises deep questions about their design decisions and development processes. The fact that such a bug could occur should have been mind-blowingly obvious from the moment they wrote their first line of code.

Indeed. I once read that the limiting factor on how high we can build skyscrapers is not structural engineering but the explosion in space occupied by elevator shafts as you try and go higher and higher whilst preserving reasonable wait times.

No, if you read the article they clearly state the keys were fraudulently obtained. If you obtain keys via fraud, they are almost by definition not "good keys".

RedPhone is free and open source end to end encrypted telephony that works OK (not amazingly, but as well as a typical commercial VoIP app does). People authenticate each other using their voices.

This is very true. However, WhatsApp appears to be a counter-example. They are deploying full end to end encryption and instead of ads, they just ..... charge people money, $1 per year. WhatsApp is not very big in the USA but it's huge everywhere else in the world.

The big problem is not people sharing with Facebook or Google or whoever (as you note: who cares?) but rather the last part - sharing with a foreign corporation is currently equivalent to sharing with its government, and people tend to care about the latter much more than the former. But that's a political problem. It's very hard to solve with cryptography. All the fancy science in the world won't stop a local government just passing a law that makes it illegal to use, and they all will because they all crave the power that comes with total knowledge of what citizens are doing and thinking.

Ultimately the solution must be two-pronged. Political effort to make it socially unacceptable for politicians to try and ban strong crypto. And the deployment of that crypto to create technical resistance against bending or breaking those rules.

That's not what the second link says is happening though.

My reading of the second article is that there is the following problem. Website G2A.com allows private re-sale of game keys, whether that's to undercut the retail prices or avoid region locking or whatever is irrelevant. Carders are constantly on the lookout for ways to cash out stolen credit card numbers. Because fraudulent card purchases can be rolled back and because you have to go through ID verification to accept cards, spending them at their own shops doesn't work - craftier schemes are needed.

So what they do is go online and buy game activation keys in bulk with stolen cards. They know it will take time for the legit owners of the cards to notice and charge back the purchase. Then they go to G2A.com and sell the keys at cut-down prices to people who know they are obtaining keys from a dodgy backstreet source, either they sell for hard-to-reverse payment methods like Western Union or they just bet that nobody wants to file a complaint with PayPal saying they got ripped off trying to buy a $60 game for $5 on a forum known for piracy and unauthorised distribution.

Then what happens? Well, the game reseller gets delivered a list of card chargebacks by their banks and are told they have a limited amount of time to get the chargeback problem under control. Otherwise they will get cut off and not be able to accept credit card payments any more. The only available route to Ubisoft or whoever at this point is to revoke the stolen keys to try and kill the demand for the carded keys.

If that reading is correct then Ubisoft aren't to blame here. They can't just let this trade continue or it threatens their ability to accept legitimate card payments.

In this case UBISOFT has a dispute with gray marketeers and decides to take it out on the customers instead of taking it to the courts

Ubisoft might not be able to take them to the courts. For example if these resellers are in China or developing countries where the local authorities don't care about foreign IP cases. Technically speaking, it's actually the customers who have a dispute with the resellers, because those resellers knowingly sold them dud keys. It's not much different than if you buy a fake branded Mac, take it to an Apple repair centre and they tell you to go away. Your dispute is not with Apple. Your dispute is with the entity that sold you the fake goods.

Look at it another way. What if these "resellers" were actually selling you random numbers instead of game activation keys. When you try them out and discover they don't work .... your dispute is not with Ubisoft. They would be totally correct to deny activation of the game. Your dispute is with the fraudster who sold you the invalid keys.

Legally speaking that would be a dispute between you and the bogus reseller. They sold you something that was effectively counterfeit. There's lots of well established law in this area.

That's actually what it's like at "Mojave Spaceport". Hangers of small aviation practicioners and their junk. Gary Hudson, Burt Rutan, etc. Old aircraft and parts strewn about. Left-over facilities from Rotary Rocket used by flight schools. A medium-sized facility for Orbital. Some big facilities for BAE, etc. An aircraft graveyard next door.

SS2 has not completed testing and it is probable that there will be a need for redesign of one or more components. So, this is a really bad time to have the hand-off. Publicity isn't a good reason.

the nice thing about a modular system is that just as the modules may be discarded from the phones and re-purposed (in this case the idea is to re-purpose them in compute clusters), so may, when there are better more powerful processors available, the modules being used in the compute clusters *also* discarded... and re-purposed further once again down a continual chain until they break.

now, you may think "phone SoC equals useless for compute purposes" this simply is *not true*. you may for example colocate raspberry pi's (not that i like broadcom, but for GBP 25 who is complaining?) http://raspberrycolocation.com... - cost per month: $EUR 3. that's $EUR 36 per year because the power consumption and space requirements are so incredibly low.

another example: i have created a modular standard, it's called EOMA68. it re-uses legacy PCMCIA casework (which you can still get hold of if you look hard enough). the first CPU Card is a 2gb RAM dual-core 1.2ghz ARM Cortex A7, which as you know is based on the A15 so may even do Virtualisation. i did a simple test: i ran Debian GNU/Linux on it, installed xrdp, libreoffice and firefox. i then ran *five* remote sessions from my laptop, fired up libreoffice and firefox in each, and that dual-core CPU Card didn't even break a sweat.

so if you'd like to buy some compute modules *now* rather than wait for google project ara (which will require highly specialist chipsets based on an entirely new and extremely uncommon standard called MIPI UniPro) the crowdfunding campaign opens very shortly:

https://www.crowdsupply.com/eo...

once that's underway, i will have the funding to finish paying for the next compute module, which is a quad-core CPU Card. after that, we can see about getting some more CPU Cards developed, and so on and so forth for the next 10 years.

to answer your question about "interconnect", you have to think in terms of "bang-per-buck-per-module" in terms of space, power used as well as CPU. a 2.5 watt module like the EOMA68-A20 only takes up 5mm x 86mm x 54mm. i worked out once that you could get something like 5,000 of those into a single full-height 19in cabinet - something mad, anyway. you end up using something like 40kW and you get such a ridiculous amount of processing power in such a small space that actually it's power and backbone interconnect that become the bottlenecks, *not* the Gigabit Ethernet on the actual modules, that becomes the main problem to overcome.

bottom line there's a lot of mileage in this kind of re-useable modular architecture. help support me in getting it off the ground!
https://www.crowdsupply.com/eo...