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.
How many unauthenticated remote exploits in a HTTP stack does it take to lose a customer?
Not many, I should imagine, but your comment is irrelevant because there were no such bugs fixed in this Java update. The way Oracle describes these bugs is horribly confusing. Normally we expect "remotely exploitable without authentication" to mean you can send a packet across the network and pwn the box. If you actually check the CVEs you will see that there's only one bug like that, and it's an SSL downgrade attack - doesn't give you access to the box. All the others are sandbox escapes. If you aren't trying to sandbox malicious code then they don't affect you.
Java doesn't have security holes like C or C++.... or so I was told.
Then again, I haven't seen too many security patches for gcc or libstdc++ or glibc
You're comparing apples and oranges. The "remotely exploitable bugs" in this Java update, like all the others, are assuming you download and run malicious code in the sandbox. GCC and glibc don't have protecting you from malicious code as a goal, in fact Linux typically requires all software to be installed as root no matter what. Obviously if you never even try, you cannot fail.
The interesting story here is not so much that sandboxes have holes (look at the Chrome release notes to see how many security holes are fixed in every update), but rather than the sandbox makers seem to be currently outrunning the sandbox breakers. In 2014 Java had security holes, but no zero days at all - all the exploits were found by whitehat auditors. Same thing for Chrome, people found bugs but they were found by the good guys.
I'm not sure if this means the industry is finally turning a corner on sandboxing of mobile code or not, but it's an interesting trend.
GC tuning can do a lot, but yes, huge heaps where the GC cannot keep up with the rate of garbage requires a full stop the world collection. However, if your application is really keeping a 15 gigabyte working set, I suspect you'd hit problems with fragmentation and memory leaks using something like Rust long before scaling to such sizes.
Actually I'll just summarise it for you. If you run a lot of Tor nodes you will eventually get picked to host a hidden service directory. Then you can measure lookups for the entries of hidden services to measure their popularity, and crawl them to find out what's on them.
[Java took a very different approach to the problem of "how to we get rid of segfaults and memory corruption". Java basically banned all interesting use of the stack, forcing everything onto the heap, and barred developers from using RAII. Nowadays, with more advanced compilers able to do advanced lifetime analysis, we can reconsider languages - such as Rust - that take a less draconian approach.]
I think it's rather misleading to state that more advanced compilers have obviated the need for Java's approach.
Firstly, Rust doesn't solve automatic memory management like garbage collection does. Their solution appears to be basically smart pointers with move semantics + reference counting for the cases where data doesn't have a lifetime cleanly tied to scope. Well, great. It's back to the 1990's and COM. Reference counting notoriously cannot handle cycles, which are very common in real programs. Any tree structure where you want to be able to navigate both up and down, for example.
In addition to the difficulty of breaking reference cycles and preventing memory leaks in complex programs, refcounting also has poor performance especially if you want threads involved. Garbage collection has now been optimised (in good implementations like HotSpot) to the point where it's faster than refcounting.
If we start seeing teams of non-expert programmers writing large programs in Rust, you will see programs with memory leaks all over the place.
Additionally, you realise that Java compilers have got smarter over the years too, right? HotSpot can stack allocate objects in a bunch of different circumstances, when analysis reveals that it'd be safe.
Basic Income is welfare, not something that sounds like it. The difference between it and normal welfare is, everyone gets a basic income whether they want it or not. It's meant to be enough to live off.
The idea of a BI is a very old one. It has nothing to do with cryptocurrency, and I'm not sure what relevance cryptocurrency has (and I say that as a Bitcoin developer, so I'm a fan of CC in general). In theory a society rich enough to afford it would have moved to the oft-fictionalised post work utopia that you sometimes see in things like Star Trek. Because everyone gets it whether they want it or not, unconditionally, the basic income would be supposedly stigma free. Thus if you want to pursue things that are not very profitable but are beneficial to society nonetheless (production of art, charity, etc) then you could do that and not have to worry about being seen as a welfare sponger.
I love the concept in theory, but a society rich enough to afford one is pretty unimaginable in today's world. Western societies are clearly incapable of even providing the current levels of welfare let alone a vastly larger level. I see a BI as a useful goal to inspire people about the future rather than something practical for today.
They aren't allowed to impersonate another company, I suspect that's rather the point. Look at the screenshot: the HTTPS indicator was crossed out. I guess you have to click through a big fat warning to get there..... and I'm surprised it's even possible at all. I thought YouTube was SSL pinned. Maybe it's just google.com
In all of my years of being a network engineer, I've never heard of managing bandwidth that way and can't think of why someone would mange bandwidth that way.
Me neither but we have no idea what kind of filtering system you can install onto a plane.
My guess is that they can't filter by DNS lookup for some reason (people's devices have cached answers?) but they can do SSL rewriting, and for big sites like anything Google runs IP address blocking isn't useful because all their sites share IPs. They know browsers and apps won't accept their fake certs, it's just a way to create an unbypassable error.
You're not thinking like someone who has to deal with the general public.
People who read slashdot can easily rattle off some semi-accurate estimates for how much bandwidth a particular online activity consumes. Load BBC News? Less than 1mb (I hope). Listen to a streamed MP3 of a pop hit? Probably 3-4mb. Watch a 40 second video? Maybe 5-8 megabytes. Windows update? Errrmm..... maybe 20-30? Stream a full TV episode. Multiple gigabytes.
None of this means anything to your average flyer. They don't think in units of bits. Telling them they have 300 megabytes of transfer quota is just meaningless nerd speak to them. What they understand is watching youtube, browsing the web, downloading TV episodes, etc. This is the fundamental problem all brokers of bandwidth have: their customers don't really understand what they're buying.
So now we come to the question of why GoGo is serving bogus SSL certs. The most obvious reason I can think of is that doing so breaks both websites and apps in such a way that they will stop immediately, rather than switching to alternative hostnames or IP addresses or constantly hammering away and retrying stuff. If you're trying to selectively kill off YouTube and other video sites so you can tell people "Sure, browse the web and play with your phone, have fun" in a massively bandwidth starved environment, causing unbypassable errors for specific websites is probably not the worst way to do it. People will be happier this way than thinking they're gonna surf for an hour before going to sleep, and then getting a quota exceeded error after five minutes because they accidentally clicked on a YouTube vid.
Obviously a ban is not the same thing as a well enforced ban.
Note that the most recent comparable incident in the UK involved two Muslim men hacking a soldier to death with a machete. But there was only one death. It's much easier to kill people, much faster, with guns than with machetes. The UK has been very serious about gun control though, so the lack of guns in the last attack wasn't a huge surprise.
1) when a new OS comes out, some apps designed for the old OS have problems. This works out over time as most apps are updated. Some old unsupported apps are left in the dust and no longer work under new OS versions. this has been true since DOS.
That's a weird example given that Microsoft have always been religious about backwards compatibility and app-compat testing, to the point where you can in fact run apps written for DOS in Windows and have them work 20 years later.
Apple, on the other hand, have managed to ship software updates that break Chrome in recent times - that's not exactly some obscure hard to test for app. Yosemite was/is riddled with insanely obvious bugs that show me Apple just doesn't care or make time for OS upgrade testing. It's not some fundamental thing.
For example after the upgrade the IntelliJ UI is flickering and broken for no obvious reason, presumably something related to their new transparency everywhere. If you disabled said transparency in the accessibility prefs window, beyond being incredibly ugly, the corners of rounded popover windows like the volume indicator went black! They weren't even doing transparency blending right! Come on guys, whoever implemented the "no transparency" feature must have realised it was unfinished, but they shipped it anyway (fixed in 10.10.1 I think). Yosemite also trashed support for my USB smart card stick for, like, 4 months. The manufacturers were eventually able to make it work again, but it now comes with a list of stupid glitches that are due to new bugs in Apple's libraries - one of them is literally "if you use app X Y or Z, then apps A and B won't work until you restart your Mac". WTF? Apple didn't even make any upgrades in smartcard support in recent times. How did they manage to break it so much?
Yosemite is full of crap like this. I'm ignoring the subjective things like I think it looks worse. Yet, I cannot identify a single feature or improvement that I've benefited from post-upgrade. I had to do it to test the software I'm writing and keep up with security updates, but if I'd known and had free choice, I'd have stayed on 10.9
But this has been a trend ever since iOS. As was pointed out elsewhere on this thread, it's an open secret that Apple basically have one team of their best people that Jobs kept moving around between the most important projects. OS X has suffered for years because of this.
The point of Bitcoin is you don't need to put your money on deposit with someone else.
Lots of day traders and people who want to hold bitcoin for speculative purposes, but not actually use it, choose not to do this and keep their money at an exchange. But are they really Bitcoin users at that point? Or are they banking users who happen to have a BTC denominated account?
If Bitstamp did get hacked, then what regulation do you have in mind? "Don't get hacked" is not something you really need a regulation for.
Maybe you meant regulations in general that make it hard for new/small companies to handle money. Assuming there's a correlation between bigness and competence is...... optimistic.
I think the main reason we don't see this happening so much in the banking space is that banks will work together to reverse transactions when possible, and all accounts are ID verified, whereas the Bitcoin community doesn't do that.
Well, it is a "surprise" in the sense that the connection between intelligence agencies sniffing wire traffic and stopping DDoS attacks is tenuous at best and non-existent at worst. I do not recall any intelligence agency stopping a DDoS attack, ever. That's up to the companies and network operators handling the traffic.
Slashdot Mirror
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.
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.
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.
Not many, I should imagine, but your comment is irrelevant because there were no such bugs fixed in this Java update. The way Oracle describes these bugs is horribly confusing. Normally we expect "remotely exploitable without authentication" to mean you can send a packet across the network and pwn the box. If you actually check the CVEs you will see that there's only one bug like that, and it's an SSL downgrade attack - doesn't give you access to the box. All the others are sandbox escapes. If you aren't trying to sandbox malicious code then they don't affect you.
You're comparing apples and oranges. The "remotely exploitable bugs" in this Java update, like all the others, are assuming you download and run malicious code in the sandbox. GCC and glibc don't have protecting you from malicious code as a goal, in fact Linux typically requires all software to be installed as root no matter what. Obviously if you never even try, you cannot fail.
The interesting story here is not so much that sandboxes have holes (look at the Chrome release notes to see how many security holes are fixed in every update), but rather than the sandbox makers seem to be currently outrunning the sandbox breakers. In 2014 Java had security holes, but no zero days at all - all the exploits were found by whitehat auditors. Same thing for Chrome, people found bugs but they were found by the good guys.
I'm not sure if this means the industry is finally turning a corner on sandboxing of mobile code or not, but it's an interesting trend.
GC tuning can do a lot, but yes, huge heaps where the GC cannot keep up with the rate of garbage requires a full stop the world collection. However, if your application is really keeping a 15 gigabyte working set, I suspect you'd hit problems with fragmentation and memory leaks using something like Rust long before scaling to such sizes.
Why don't you watch the talk and find out?
Actually I'll just summarise it for you. If you run a lot of Tor nodes you will eventually get picked to host a hidden service directory. Then you can measure lookups for the entries of hidden services to measure their popularity, and crawl them to find out what's on them.
I think it's rather misleading to state that more advanced compilers have obviated the need for Java's approach.
Firstly, Rust doesn't solve automatic memory management like garbage collection does. Their solution appears to be basically smart pointers with move semantics + reference counting for the cases where data doesn't have a lifetime cleanly tied to scope. Well, great. It's back to the 1990's and COM. Reference counting notoriously cannot handle cycles, which are very common in real programs. Any tree structure where you want to be able to navigate both up and down, for example.
In addition to the difficulty of breaking reference cycles and preventing memory leaks in complex programs, refcounting also has poor performance especially if you want threads involved. Garbage collection has now been optimised (in good implementations like HotSpot) to the point where it's faster than refcounting.
If we start seeing teams of non-expert programmers writing large programs in Rust, you will see programs with memory leaks all over the place.
Additionally, you realise that Java compilers have got smarter over the years too, right? HotSpot can stack allocate objects in a bunch of different circumstances, when analysis reveals that it'd be safe.
Basic Income is welfare, not something that sounds like it. The difference between it and normal welfare is, everyone gets a basic income whether they want it or not. It's meant to be enough to live off.
The idea of a BI is a very old one. It has nothing to do with cryptocurrency, and I'm not sure what relevance cryptocurrency has (and I say that as a Bitcoin developer, so I'm a fan of CC in general). In theory a society rich enough to afford it would have moved to the oft-fictionalised post work utopia that you sometimes see in things like Star Trek. Because everyone gets it whether they want it or not, unconditionally, the basic income would be supposedly stigma free. Thus if you want to pursue things that are not very profitable but are beneficial to society nonetheless (production of art, charity, etc) then you could do that and not have to worry about being seen as a welfare sponger.
I love the concept in theory, but a society rich enough to afford one is pretty unimaginable in today's world. Western societies are clearly incapable of even providing the current levels of welfare let alone a vastly larger level. I see a BI as a useful goal to inspire people about the future rather than something practical for today.
That was true 10 years ago. These days browsers make them un-ignorable and in some cases like with HSTS unbypassable.
They aren't allowed to impersonate another company, I suspect that's rather the point. Look at the screenshot: the HTTPS indicator was crossed out. I guess you have to click through a big fat warning to get there ..... and I'm surprised it's even possible at all. I thought YouTube was SSL pinned. Maybe it's just google.com
Me neither but we have no idea what kind of filtering system you can install onto a plane.
My guess is that they can't filter by DNS lookup for some reason (people's devices have cached answers?) but they can do SSL rewriting, and for big sites like anything Google runs IP address blocking isn't useful because all their sites share IPs. They know browsers and apps won't accept their fake certs, it's just a way to create an unbypassable error.
You're not thinking like someone who has to deal with the general public.
People who read slashdot can easily rattle off some semi-accurate estimates for how much bandwidth a particular online activity consumes. Load BBC News? Less than 1mb (I hope). Listen to a streamed MP3 of a pop hit? Probably 3-4mb. Watch a 40 second video? Maybe 5-8 megabytes. Windows update? Errrmm ..... maybe 20-30? Stream a full TV episode. Multiple gigabytes.
None of this means anything to your average flyer. They don't think in units of bits. Telling them they have 300 megabytes of transfer quota is just meaningless nerd speak to them. What they understand is watching youtube, browsing the web, downloading TV episodes, etc. This is the fundamental problem all brokers of bandwidth have: their customers don't really understand what they're buying.
So now we come to the question of why GoGo is serving bogus SSL certs. The most obvious reason I can think of is that doing so breaks both websites and apps in such a way that they will stop immediately, rather than switching to alternative hostnames or IP addresses or constantly hammering away and retrying stuff. If you're trying to selectively kill off YouTube and other video sites so you can tell people "Sure, browse the web and play with your phone, have fun" in a massively bandwidth starved environment, causing unbypassable errors for specific websites is probably not the worst way to do it. People will be happier this way than thinking they're gonna surf for an hour before going to sleep, and then getting a quota exceeded error after five minutes because they accidentally clicked on a YouTube vid.
I don't think people wielding guns in Gaza has much to do with them being Muslim.
Obviously a ban is not the same thing as a well enforced ban.
Note that the most recent comparable incident in the UK involved two Muslim men hacking a soldier to death with a machete. But there was only one death. It's much easier to kill people, much faster, with guns than with machetes. The UK has been very serious about gun control though, so the lack of guns in the last attack wasn't a huge surprise.
That's a weird example given that Microsoft have always been religious about backwards compatibility and app-compat testing, to the point where you can in fact run apps written for DOS in Windows and have them work 20 years later.
Apple, on the other hand, have managed to ship software updates that break Chrome in recent times - that's not exactly some obscure hard to test for app. Yosemite was/is riddled with insanely obvious bugs that show me Apple just doesn't care or make time for OS upgrade testing. It's not some fundamental thing.
For example after the upgrade the IntelliJ UI is flickering and broken for no obvious reason, presumably something related to their new transparency everywhere. If you disabled said transparency in the accessibility prefs window, beyond being incredibly ugly, the corners of rounded popover windows like the volume indicator went black! They weren't even doing transparency blending right! Come on guys, whoever implemented the "no transparency" feature must have realised it was unfinished, but they shipped it anyway (fixed in 10.10.1 I think). Yosemite also trashed support for my USB smart card stick for, like, 4 months. The manufacturers were eventually able to make it work again, but it now comes with a list of stupid glitches that are due to new bugs in Apple's libraries - one of them is literally "if you use app X Y or Z, then apps A and B won't work until you restart your Mac". WTF? Apple didn't even make any upgrades in smartcard support in recent times. How did they manage to break it so much?
Yosemite is full of crap like this. I'm ignoring the subjective things like I think it looks worse. Yet, I cannot identify a single feature or improvement that I've benefited from post-upgrade. I had to do it to test the software I'm writing and keep up with security updates, but if I'd known and had free choice, I'd have stayed on 10.9
But this has been a trend ever since iOS. As was pointed out elsewhere on this thread, it's an open secret that Apple basically have one team of their best people that Jobs kept moving around between the most important projects. OS X has suffered for years because of this.
The point of Bitcoin is you don't need to put your money on deposit with someone else.
Lots of day traders and people who want to hold bitcoin for speculative purposes, but not actually use it, choose not to do this and keep their money at an exchange. But are they really Bitcoin users at that point? Or are they banking users who happen to have a BTC denominated account?
If Bitstamp did get hacked, then what regulation do you have in mind? "Don't get hacked" is not something you really need a regulation for.
Maybe you meant regulations in general that make it hard for new/small companies to handle money. Assuming there's a correlation between bigness and competence is ...... optimistic.
I think the main reason we don't see this happening so much in the banking space is that banks will work together to reverse transactions when possible, and all accounts are ID verified, whereas the Bitcoin community doesn't do that.
Well, it is a "surprise" in the sense that the connection between intelligence agencies sniffing wire traffic and stopping DDoS attacks is tenuous at best and non-existent at worst. I do not recall any intelligence agency stopping a DDoS attack, ever. That's up to the companies and network operators handling the traffic.