There have been quite a few. My favourite relates to the Java security model, which requires that methods that call out of the JVM perform checks on the current security manager. The security manager will then throw an exception if called from code that doesn't have the required permission. Unfortunately, the JVM was speculating the code that performed the action before the code that performed the check, because it wasn't correctly modelling the possible flow-control implications of the privilege check. This was exploitable, allowing any code running with reduced privileged (e.g. untrusted plugins) to run with the privilege of the JVM process.
It is possible to write memory safe code in C. There are three problems. The first is that it's quite hard. The second is that a single memory safety bug violates invariants that the entire program depends on and so can cause non-local problems. The third is that C is the lingua franca for library interfaces and so it's likely that your program is using C libraries with bugs that can completely destroy the program's security.
Now here's the kicker: Most of the languages listed are implemented in C. Not only in C, but often using some of the pointer manipulation tricks that make C both powerful and dangerous. On top of that, they're providing standard libraries that are mostly both written in C and using third-party libraries written in C. Even if your Ruby (for example) code is entirely bug free, you have so much C code in your address space that it's astonishing anything works at all.
Read down to the approximations solution. As with many NP-hard problems, getting the optimal solution is computationally infeasible, but getting a good-enough solution is fairly easy.
Your argument is 'this problem exists, therefore this must be the solution'. It is no different from arguing 'I am not paid enough, therefore I should work with my feet in a bucket of cold water'. Why a bucket of cold water? I don't know, as with systemd it has very little to do with a real solution to the problem.
I think most of us can agree that traditional SysV service management has a lot of problems, most notably in more dynamic situations (i.e. when you don't have a fixed static set of services that you only ever start and stop on boot). I think both Launchd on XNU and SMF on Solaris improved this situation hugely, though in quite different ways (and ignoring the truly horrible Java tool that Solaris provides for managing the SMF configuration). Unfortunately, as with most Poetteringware, systemd identifies a real problem and then completely fails to solve it, while arguing that the existence of the problem is proof that it must be a solution.
Okay, please point to one single piece of off-the-shelf software that anyone has audited well enough to stand up in public and assert that it is bug free. The closest I can think of is seL4, which was not just published, it was written with formal verification in mind: if you just had the C sources for it (and not the accompanying proofs) then verification would be a many man-year project. Oh, and it was less than a day between the public release of seL4 and the first security vulnerability being found.
Publication of source makes it easier to determine that a product contains flaws, but for anything more than a thousand lines of code that can pretty much be taken as given. It does have other benefits, most notably that third parties can fix it, but being able to vet it will at best let you say 'yup, this thing that I'd previously assumed to be insecure crap turns out to be insecure crap'.
Not being able to vet it doesn't mean much. I doubt that there are 100 people in the world who can audit software of this complexity and be confident that it is free from security bugs. For anyone else, it should be assumed to be insecure whether you have the code or not.
Remember how when iPhones came out Apple fans claimed Apple was more secure and also that the iPhone being locked down wasn't a problem because you could jailbreak it by visiting a site with a malformed TIFF
And almost 10 years after that, Android phones were shipping with a vulnerability in the media framework, which ran in a separate process with root privilege (WTF?!?) that allowed any web site to run malicious code as root and then compromise the kernel. And it took over six months between the vulnerability being made public (and even given the buzzwordy name StageFright) and more than 50% of Android phones being patched, in spite of the Android developers having the experience of the iOS vulnerability to learn from. In the same time, iOS split various core services into over a hundred different processes that all run with minimal privilege.
Apple security is still close to the best in the business, but that's a pretty low standard.
It's not just about security, it's about visibility. The easiest way to break into my house is to throw a brick through the window. The problem with doing that, as a burglar, is that the lawful owner of the house would probably not do that and so it's likely that someone else would call the police. It also leaves evidence of unlawful entry, so even if no one sees you throw the brick, someone might notice the big hole in the window and report it.
A better thief might buy a set of lockpicks, learn how to pick the locks, and then do that. I have a fairly good lock, so it would probably take about a few minutes to pick. If someone is kneeling in front of my door poking at the lock, then there's a reasonable chance that my neighbours would notice. Even if they didn't call the police, they'd probably remember what the person looked like and be able to give their description to the police. If you rob a few houses, then the chance of being caught increases a lot.
Now, imagine that you have an app that you bought from a criminal site that will identify 'smart' appliances in homes that you walk past, let you know the ones that have appliances in modes that indicate that they're unoccupied and will unlock the doors as you walk up to them. You can simply walk around a neighbourhood and walk into an unoccupied house, have a look around, and if it looks like there's stuff worth stealing then call a friend with a van. If anyone accosts you before your friend with the van turns up, then you tell them that the front door was open and you thought that someone might have broken in and were checking before you called the police.
Speculators make money out of the volatility of bitcoin. They need its value to fluctuate a lot because they sell when it's high and buy when it's low, and if its value is going up and down by 20% a day then there's a huge opportunity to make money. As such, they have a vested interest in both positive and negative hype, as long as there isn't enough negative for everyone to try to cash out at once. A story like this may panic people into selling, letting them buy low and then sell again when the price peaks after the next bit of positive hype.
First, as others have pointed out, 'actual competition' is rare for ISPs. You typically have at most, one phone company and one cable company owning the last mile. Everyone else who wants to run a decent speed / latency connection to your house will lease the last mile from one of these two. When that's 90% of the total price and is subject to so little competition (at most one other competitor), there isn't much the competing ISPs can do.
Second, this assumes no collusion. Most companies are run by people who understand what 'race to the bottom' means and realise that if they cut their profits in half and doubled their customer numbers, they wouldn't make more money. If they cut their profits in half and so did their competitor, then they'd both be making less money. The best strategy for them is to only put their prices down if their competitor does so first.
Third, this assumes that price is the only factor on which they compete. For example, Apple hasn't lowered their iPhone price to compete with cheaper Android phones. Part of the goal of network neutrality is to restrict the number of things on which ISPs can compete: they are all providing access to the same services in the same way, so they can compete either on price, speed, or both.
PayPal seems to have put their prices up now, but it looks as if they're charging about the same amount as Patreon. The entire point of Patreon; however, is to make micropayments affordable by aggregating the processing charges. If I want to spread $10/month between a few dozen people, then it's pretty hard to do that with existing payment processors because the fees will eat most of that. If I pay a single intermediary then they'll get something like $9.50 after fees and can then distribute this evenly, aggregating the amounts so that when the recipients take the money out then the bank transfer fees are minimal (or nonexistent).
With Patreon now charging about the same amount as a payment processor, there's little advantage to using them.
Basic Income would mean I could try to play in the street full time to bring in extra cash above Basic Income... However I wouldn't have the harsh realities of not making a living to tell me how bad actually I am.
Around here, at least, you need a license to be a busker, which includes a minimum quality standard. It's not amazingly high, but at least it is good enough that it's not actively painful to listen to them. If you meet this threshold (and if you play in a community band, you almost certainly do), then most people would probably rather have you playing on the street than no one playing.
And, personally, I'd rather live in a society where you were able to survive doing something that you enjoy and that brings other people pleasure than one in which you're forced to do something that you don't enjoy. Maybe after a few months you'd get bored and only busk an hour or two a week, and maybe get another part-time job to give you something interesting to do. Maybe after a few weeks you'd decide that you hated performing and never do it again. Maybe the practice of playing solidly for a few weeks would improve your standard to the point where people would pay to see you on stage. The point of UBI is to give you the opportunity to find out.
It also seems like the calculation is assuming a full-time job. A blogger who spend a couple of hours a week writing articles, or someone who spends half an hour a week recording a YouTube video as a hobby may be getting a hundred or so dollars per hour of work that they put in, which is pretty good, but this calculation might show them making $200/month and sound very bad.
Perhaps the headline should read 'people being paid for their part-time hobby make less money than at their full-time job', at which point it doesn't sound so much like news.
The difference is that 512KB isn't enough to do things like WYSIWYG rendering of vector fonts, spell checking with a decent-sized dictionary (well, WordStar could, but only by storing most of the dictionary on disk and it was slow), and so on. The computer I had with 640KB of RAM did a lot less than the one with 512MB of RAM. In contrast, I did far more with the machine with 512MB than I do on my phone, yet 512MB is considered ultra low end for a phone.
Other web sites, including this one, don't invite people to 'friend' me, use that information (as well as my email address in any Facebook user's address book on a smartphone) to build a social graph, place tracking cookies to associate my account with other web pages that I visit that show ads, and so on.
Some of this worked out well for US corporations. For example, South Korea developed an ActiveX control that implemented crypto and required all banks to use it. If you wanted to use online banking, you had to use IE on Windows.
As I understand it, they're basically web apps that support offline use. HTML5 supports local storage and so it's possible to write apps that run in a browser but still work when the web site is down. They also adopt a bunch of ideas from Java Web Start (remember that?) where they'll quickly download the code required to get the core UI working and then download the rest on demand. If the network isn't present, then some features may not work (or may not work if you don't use them the first time when you're connected), but in theory you shouldn't lose any data. Unlike Google's office suite, where if they install an update on the server while you're offline then when you reconnect you'll get a nice dialog telling you that you'll lose all data when you hit okay, with no other buttons.
Brighton is basically the hipster capital of the UK.
When did that happen? I thought Brighton was still a wasteland pining for the days before Brits could afford international travel when it was a major holiday destination.
I don't believe that either should care about me, but I know which one is likely to cause more negative consequences for me if I end up being a false positive in their big data inference engines. I have a friend who had the same name as someone on the now-fly list (he doesn't anymore, because after a few years that added middle initials to the list) who can attest for how inconvenient it is to have even a low level of interest from the intelligence agencies in a country that you regularly visit or live in.
In contrast, if the FSB decided I was a person of interest, then it would likely have no impact on my life at all unless it escalated all of the way up to polonium time, and hopefully there's some human oversight at that level.
The radio coprocessor in cell phones typically has full "back door" access to the resources used by the main CPU and OS you interact with
This is not true on iOS devices. The connection between the baseband processor and main memory is quite restricted, because Apple's hardware team doesn't trust third-party IP cores and so locks them down. It's also not true for a few other SoCs, where the baseband core has its own private memory and communicates with the host via an on-chip serial interface. This was a very common way of implementing smartphone SoCs, because it meant that you could trivially validate that there was no way for the application core to modify the baseband core's state and so you could use the same baseband core on a bunch of SoCs without needing FCC approval for each one.
Compared to the level of security that you need from an organisation holding information that, if public, could cripple your company. Most companies are fairly good at keeping their own secrets, because they understand the cost of not doing so.
Bruce Schneier's book, Applied Cryptography, showed precisely how stupid these export restrictions were. They didn't limit algorithms, they limited key length. You could export RSA with short keys, but not with longer ones. His book had source code for them where the algorithms were compile-time constants. If you typed them in as-is, the resulting code was export-legal. If you changed a 128 to a 1024 (or whatever - I forget the exact allowed vs not-allowed numbers), it wasn't. Because of this, it was completely legal to ship the book anywhere in the world, and anyone in a country where it wasn't allowed simply had to change a constant when they typed in the code.
If I don't like Facebook, which I don't, at-least I don't have to use it.
The problem, as always, is network effects. It was easy to avoid Microsoft too, right up until the point where you wanted to bid for a lucrative contract where the customer would only accept submissions using their complex Word template. Asking them for a copy in an open format would just have you marked as uncooperative and you'd lose automatically.
The same is increasingly true for Facebook. I don't use it, but an increasing number of companies use Facebook and Twitter as their primary method of providing customer support and provide discounts for people who like them on these platforms.
Slashdot Mirror
There have been quite a few. My favourite relates to the Java security model, which requires that methods that call out of the JVM perform checks on the current security manager. The security manager will then throw an exception if called from code that doesn't have the required permission. Unfortunately, the JVM was speculating the code that performed the action before the code that performed the check, because it wasn't correctly modelling the possible flow-control implications of the privilege check. This was exploitable, allowing any code running with reduced privileged (e.g. untrusted plugins) to run with the privilege of the JVM process.
x86 is a horribly complex ISA, but MIPS JIT'd on MIPS was around 10-20% faster when the Dynamo project did it a couple of decades ago.
It is possible to write memory safe code in C. There are three problems. The first is that it's quite hard. The second is that a single memory safety bug violates invariants that the entire program depends on and so can cause non-local problems. The third is that C is the lingua franca for library interfaces and so it's likely that your program is using C libraries with bugs that can completely destroy the program's security.
Now here's the kicker: Most of the languages listed are implemented in C. Not only in C, but often using some of the pointer manipulation tricks that make C both powerful and dangerous. On top of that, they're providing standard libraries that are mostly both written in C and using third-party libraries written in C. Even if your Ruby (for example) code is entirely bug free, you have so much C code in your address space that it's astonishing anything works at all.
Read down to the approximations solution. As with many NP-hard problems, getting the optimal solution is computationally infeasible, but getting a good-enough solution is fairly easy.
Your argument is 'this problem exists, therefore this must be the solution'. It is no different from arguing 'I am not paid enough, therefore I should work with my feet in a bucket of cold water'. Why a bucket of cold water? I don't know, as with systemd it has very little to do with a real solution to the problem.
I think most of us can agree that traditional SysV service management has a lot of problems, most notably in more dynamic situations (i.e. when you don't have a fixed static set of services that you only ever start and stop on boot). I think both Launchd on XNU and SMF on Solaris improved this situation hugely, though in quite different ways (and ignoring the truly horrible Java tool that Solaris provides for managing the SMF configuration). Unfortunately, as with most Poetteringware, systemd identifies a real problem and then completely fails to solve it, while arguing that the existence of the problem is proof that it must be a solution.
Okay, please point to one single piece of off-the-shelf software that anyone has audited well enough to stand up in public and assert that it is bug free. The closest I can think of is seL4, which was not just published, it was written with formal verification in mind: if you just had the C sources for it (and not the accompanying proofs) then verification would be a many man-year project. Oh, and it was less than a day between the public release of seL4 and the first security vulnerability being found.
Publication of source makes it easier to determine that a product contains flaws, but for anything more than a thousand lines of code that can pretty much be taken as given. It does have other benefits, most notably that third parties can fix it, but being able to vet it will at best let you say 'yup, this thing that I'd previously assumed to be insecure crap turns out to be insecure crap'.
Not being able to vet it doesn't mean much. I doubt that there are 100 people in the world who can audit software of this complexity and be confident that it is free from security bugs. For anyone else, it should be assumed to be insecure whether you have the code or not.
Remember how when iPhones came out Apple fans claimed Apple was more secure and also that the iPhone being locked down wasn't a problem because you could jailbreak it by visiting a site with a malformed TIFF
And almost 10 years after that, Android phones were shipping with a vulnerability in the media framework, which ran in a separate process with root privilege (WTF?!?) that allowed any web site to run malicious code as root and then compromise the kernel. And it took over six months between the vulnerability being made public (and even given the buzzwordy name StageFright) and more than 50% of Android phones being patched, in spite of the Android developers having the experience of the iOS vulnerability to learn from. In the same time, iOS split various core services into over a hundred different processes that all run with minimal privilege.
Apple security is still close to the best in the business, but that's a pretty low standard.
A better thief might buy a set of lockpicks, learn how to pick the locks, and then do that. I have a fairly good lock, so it would probably take about a few minutes to pick. If someone is kneeling in front of my door poking at the lock, then there's a reasonable chance that my neighbours would notice. Even if they didn't call the police, they'd probably remember what the person looked like and be able to give their description to the police. If you rob a few houses, then the chance of being caught increases a lot.
Now, imagine that you have an app that you bought from a criminal site that will identify 'smart' appliances in homes that you walk past, let you know the ones that have appliances in modes that indicate that they're unoccupied and will unlock the doors as you walk up to them. You can simply walk around a neighbourhood and walk into an unoccupied house, have a look around, and if it looks like there's stuff worth stealing then call a friend with a van. If anyone accosts you before your friend with the van turns up, then you tell them that the front door was open and you thought that someone might have broken in and were checking before you called the police.
For anyone wanting to follow this advice, I'd recommend the Rolling Stone article The Great American Bubble Machine as a good introduction.
Speculators make money out of the volatility of bitcoin. They need its value to fluctuate a lot because they sell when it's high and buy when it's low, and if its value is going up and down by 20% a day then there's a huge opportunity to make money. As such, they have a vested interest in both positive and negative hype, as long as there isn't enough negative for everyone to try to cash out at once. A story like this may panic people into selling, letting them buy low and then sell again when the price peaks after the next bit of positive hype.
First, as others have pointed out, 'actual competition' is rare for ISPs. You typically have at most, one phone company and one cable company owning the last mile. Everyone else who wants to run a decent speed / latency connection to your house will lease the last mile from one of these two. When that's 90% of the total price and is subject to so little competition (at most one other competitor), there isn't much the competing ISPs can do.
Second, this assumes no collusion. Most companies are run by people who understand what 'race to the bottom' means and realise that if they cut their profits in half and doubled their customer numbers, they wouldn't make more money. If they cut their profits in half and so did their competitor, then they'd both be making less money. The best strategy for them is to only put their prices down if their competitor does so first.
Third, this assumes that price is the only factor on which they compete. For example, Apple hasn't lowered their iPhone price to compete with cheaper Android phones. Part of the goal of network neutrality is to restrict the number of things on which ISPs can compete: they are all providing access to the same services in the same way, so they can compete either on price, speed, or both.
PayPal seems to have put their prices up now, but it looks as if they're charging about the same amount as Patreon. The entire point of Patreon; however, is to make micropayments affordable by aggregating the processing charges. If I want to spread $10/month between a few dozen people, then it's pretty hard to do that with existing payment processors because the fees will eat most of that. If I pay a single intermediary then they'll get something like $9.50 after fees and can then distribute this evenly, aggregating the amounts so that when the recipients take the money out then the bank transfer fees are minimal (or nonexistent).
With Patreon now charging about the same amount as a payment processor, there's little advantage to using them.
Basic Income would mean I could try to play in the street full time to bring in extra cash above Basic Income... However I wouldn't have the harsh realities of not making a living to tell me how bad actually I am.
Around here, at least, you need a license to be a busker, which includes a minimum quality standard. It's not amazingly high, but at least it is good enough that it's not actively painful to listen to them. If you meet this threshold (and if you play in a community band, you almost certainly do), then most people would probably rather have you playing on the street than no one playing.
And, personally, I'd rather live in a society where you were able to survive doing something that you enjoy and that brings other people pleasure than one in which you're forced to do something that you don't enjoy. Maybe after a few months you'd get bored and only busk an hour or two a week, and maybe get another part-time job to give you something interesting to do. Maybe after a few weeks you'd decide that you hated performing and never do it again. Maybe the practice of playing solidly for a few weeks would improve your standard to the point where people would pay to see you on stage. The point of UBI is to give you the opportunity to find out.
It also seems like the calculation is assuming a full-time job. A blogger who spend a couple of hours a week writing articles, or someone who spends half an hour a week recording a YouTube video as a hobby may be getting a hundred or so dollars per hour of work that they put in, which is pretty good, but this calculation might show them making $200/month and sound very bad.
Perhaps the headline should read 'people being paid for their part-time hobby make less money than at their full-time job', at which point it doesn't sound so much like news.
The difference is that 512KB isn't enough to do things like WYSIWYG rendering of vector fonts, spell checking with a decent-sized dictionary (well, WordStar could, but only by storing most of the dictionary on disk and it was slow), and so on. The computer I had with 640KB of RAM did a lot less than the one with 512MB of RAM. In contrast, I did far more with the machine with 512MB than I do on my phone, yet 512MB is considered ultra low end for a phone.
Other web sites, including this one, don't invite people to 'friend' me, use that information (as well as my email address in any Facebook user's address book on a smartphone) to build a social graph, place tracking cookies to associate my account with other web pages that I visit that show ads, and so on.
Some of this worked out well for US corporations. For example, South Korea developed an ActiveX control that implemented crypto and required all banks to use it. If you wanted to use online banking, you had to use IE on Windows.
As I understand it, they're basically web apps that support offline use. HTML5 supports local storage and so it's possible to write apps that run in a browser but still work when the web site is down. They also adopt a bunch of ideas from Java Web Start (remember that?) where they'll quickly download the code required to get the core UI working and then download the rest on demand. If the network isn't present, then some features may not work (or may not work if you don't use them the first time when you're connected), but in theory you shouldn't lose any data. Unlike Google's office suite, where if they install an update on the server while you're offline then when you reconnect you'll get a nice dialog telling you that you'll lose all data when you hit okay, with no other buttons.
Brighton is basically the hipster capital of the UK.
When did that happen? I thought Brighton was still a wasteland pining for the days before Brits could afford international travel when it was a major holiday destination.
I don't believe that either should care about me, but I know which one is likely to cause more negative consequences for me if I end up being a false positive in their big data inference engines. I have a friend who had the same name as someone on the now-fly list (he doesn't anymore, because after a few years that added middle initials to the list) who can attest for how inconvenient it is to have even a low level of interest from the intelligence agencies in a country that you regularly visit or live in.
In contrast, if the FSB decided I was a person of interest, then it would likely have no impact on my life at all unless it escalated all of the way up to polonium time, and hopefully there's some human oversight at that level.
The radio coprocessor in cell phones typically has full "back door" access to the resources used by the main CPU and OS you interact with
This is not true on iOS devices. The connection between the baseband processor and main memory is quite restricted, because Apple's hardware team doesn't trust third-party IP cores and so locks them down. It's also not true for a few other SoCs, where the baseband core has its own private memory and communicates with the host via an on-chip serial interface. This was a very common way of implementing smartphone SoCs, because it meant that you could trivially validate that there was no way for the application core to modify the baseband core's state and so you could use the same baseband core on a bunch of SoCs without needing FCC approval for each one.
Compared to what?
Compared to the level of security that you need from an organisation holding information that, if public, could cripple your company. Most companies are fairly good at keeping their own secrets, because they understand the cost of not doing so.
Bruce Schneier's book, Applied Cryptography, showed precisely how stupid these export restrictions were. They didn't limit algorithms, they limited key length. You could export RSA with short keys, but not with longer ones. His book had source code for them where the algorithms were compile-time constants. If you typed them in as-is, the resulting code was export-legal. If you changed a 128 to a 1024 (or whatever - I forget the exact allowed vs not-allowed numbers), it wasn't. Because of this, it was completely legal to ship the book anywhere in the world, and anyone in a country where it wasn't allowed simply had to change a constant when they typed in the code.
If I don't like Facebook, which I don't, at-least I don't have to use it.
The problem, as always, is network effects. It was easy to avoid Microsoft too, right up until the point where you wanted to bid for a lucrative contract where the customer would only accept submissions using their complex Word template. Asking them for a copy in an open format would just have you marked as uncooperative and you'd lose automatically.
The same is increasingly true for Facebook. I don't use it, but an increasing number of companies use Facebook and Twitter as their primary method of providing customer support and provide discounts for people who like them on these platforms.