Samsung have patched nearly all the bugs in the October online update and the rest will be done in this months update. So your anger is misplaced: Samsung have joined the monthly update cycle Google is pushing. I see no reason to believe the Nexus team would be doing things any faster.
Do you have any evidence of this sort of abuse? Any? At all?
It's not exactly unheard of in other projects. Gerrand stating outright that meta-discussion is "noise" represents the camel's nose under the tent - once communities start down this direction pretty quickly almost anything can become banned.
The Bitcoin community is going through this right now. Some of the developers who work on Bitcoin Core have decided they don't think the block chain should be able to grow in future, and a temporary 1mb block size limit should become.... less temporary. But of course limiting the block chain in this way is wildly unpopular, so they implied they could only raise the limit when there was consensus (of everyone). Not surprisingly this led to a LOT of debate, threads, discussion, some of it heated. Their response was to announce that the dev list had been flooded with "noise" and impose draconian moderation in which anything that might upset anyone was forbidden - which included discussion of technical topics that somebody found upsetting.
BTW it's a bit ironic that your sig says "Safety is a tyrant's tool; no one can oppose safety" on a post that's arguing for an incredibly large and complex moderation policy. Elsewhere it was suggested that be courteous and professional is the only policy needed and I'm minded to agree. There's nothing wrong with moderation to kick out genuinely problematic people, but any policy that forbids "microaggressions" (whatever the hell that means) is rightly going to be flamed for being wildly over the top.
Certificate Transparency is a Google-driven initiative taking place at the IETF to design a system to increase trust in the public key infrastructure (PKI).
The basic issue is this. The simplest way to design a public key infrastructure is to have a bigass central database that maps names to public keys. If you navigated to foobar.com, your browser would go consult the Bigass Database and look up the public key there in some secure way, then check it matched what the foobar.com server was using.
This design has a lot of downsides and a couple of upsides. The downsides are that it scales horrible, that an outage of the Bigass Database would mean an outage of the entire secure internet, that nobody is really incentivised to pay the huge costs of running it, whoever ran it would be a monopoly, and that the owners of the database would get a record of everyone's browsing sessions. The big upside is that all public keys are transparent: nobody can insert a fake mapping without being spotted, assuming there are people paying attention. And additionally, if someone lost control over a private key, the key can be revoked by just deleting it from the database.
So there are tradeoffs, but in practice the PKI (largely designed in the 1990's) doesn't use a Bigass Database. It uses certificate chains instead. Browsers and other SSL clients choose to trust a number of certificate authorities which issue certificates to servers, and those servers present their certificate chain during connection setup. Then the client can check that the public key/identity binding is valid by checking the chain of digital signatures. This scales, is robust, avoids monopolies (adding a new trusted CA is easy) and has great privacy.
That leaves the two upsides of the Bigass Database approach: revocation and transparency. Revocation is easy, you use something called OCSP stapling. CA's run a server that issues a short, signed, time limited statement of the form "certificate ABC is not revoked". Traditionally it was supposed to be the clients that did the server call, but that brought back the privacy and outage problems, so in modern setups it's the server that requests this statement and caches it for a while, then hands it to the client along with all the rest of the data.
Finally, there's the issue of transparency. CT fixes transparency. The plan is to require CAs to publish every certificate they sign in a global audit log. The log is structured somewhat like a block chain. To enforce that CAs can't sign certificates in secret, and to avoid the CT logs being hammered with privacy-sensitive traffic, a stapling approach is used again: the certificates themselves contain a mathematical proof that they exist in the global logs. Thus clients (like Chrome) can check that a certificate was published and eventually stop accepting any cert that lacks the proof.
So we end up with a PKI design that is very complicated, but lets us have our cake and eat it - we've been able to get all the major features we'd like (scalability, privacy, reliability, provider competition, agility, revocability) without compromises.
Yeah, that's how Chrome does it, that's actually how Java has done it for a long time already (JREs "expire" around the dates of scheduled security updates and refuse to run applets until you upgrade), it's how Apple should do it too.
Modern Java's aren't actually that bad, security wise. The problem is there's a massive long tail of old Windows machines that are still running ancient JVMs before even things like expiry were added.
I don't believe GCHQ gives a shit about the rule of law, seeing as how they're basically a subsidiary of the NSA (to the extent that they seem to share internal networks no less).
But nonetheless, the fact that governments are passing or trying to pass such laws is STILL a big improvement over the previous state of affairs, where their intelligence agencies are/were building these databases covertly whilst lying about doing so. At least this way the regular democratic processes have a chance to work, regardless of how flawed they might be.
I think the British government is going to lose this one (practically, not legislatively). The issue they have is that the UK isn't China: it doesn't have a home grown internet industry. The UK contributes to the global tech industry in big ways: virtually all consumer electronics are using ARM chips, the UK built one of the first computers, and there are tons of Brit's doing great work in the computing field today.
But when it comes to the giant cloud services that store everyone's data there's only really two places in the world that matter, and that's Silicon Valley and Seattle. All that data is entering and leaving the UK in encrypted form: all they and the ISPs can see is which companies are being interacted with. That trend will continue and probably even accelerate now LetsEncrypt is here. So the govt can legislate whatever the hell they like, but the data that results is going to be of low quality.
I suspect they know this and they're going to try and introduce laws that force Facebook/Google/Apple/etc to act as extensions of GCHQ. To what extent these companies go along with it will be the most fascinating fight of the coming years.
Errr.... that analogy is, I would say, not excellent.
Orwell primarily wrote about what was happening in other countries. Animal Farm was a wafer-thin allegory about the events happening inside Soviet Russia and what Stalin was doing in particular. Orwell found it hard to get published because at the time, Stalin wasn't understood as the monster he truly was: rather the USSR was still seen as the ally against the Nazi's that made huge sacrifices to win, the ally that rolled into Berlin.
1984 was Orwell's attempt to imagine what a Soviet-style totalitarian regime would look like if implemented in the UK. It's full of references to "Ingsoc" because it was another book about the evils of communism as practiced elsewhere.
Orwell wrote those books because, at the time, he felt very pessimistic about the future of his homeland. He felt sure that a communist/fascist takeover was going to happen. Towards the end of his life he admitted he had been entirely mistaken about that and England hadn't worked out the way he thought it would.
Ironically, Orwell was a committed socialist himself. He didn't write about the evils of communism because he was a capitalist. Rather, he saw communism as practiced abroad as a corruption of true democratic socialism, and he believed the right way to bring about a hard-left government was through the ballot box rather than through a fascist uprising.
I think the study seems to be suffering from this problem. Reading the methodology section, they basically measured whatever speeds the users encountered whilst just 'doing their thing'. The problem being that this isn't really evidence of ISP dishonesty: it's measuring the overall speed of the internet and assuming there are no bottlenecks beyond the last miles.
I suspect what's happening here is that people in Europe are more often connecting to websites that are far away and have to transit many networks to get to them, for example, trans-Atlantic. Then the bottleneck moves out of the ISPs own network. For instance, because many Europeans speak good English and so can benefit from American websites, whereas Americans typically don't speak European languages (beyond maybe Spanish) so get less benefit from browsing far away European websites.
OpenJDK is Oracle's JDK, minus a few commercial features.
Bear in mind that the 154 holes is for all Oracle products. They have a unified update release schedule which Java follows. There were actually "only" about 25 (I think) security holes fixed in the latest Java release. Of those, a lot were in components like CORBA or JAXRS, stuff that most code doesn't really need access to. And of course these only matter for sandboxing; I think only one affected server apps and that was a partial denial-of-service issue.
Unfortunately one of the problems applets have isn't so much that Java the language or design itself is insecure, but simply that the provided functionality is so enormous that bugs in relatively unimportant subsystems can end up compromising security. I think if you were to try and define an Applets2 standard these days you'd be waaaaay more aggressive with locking off access to big chunks of functionality. Applets don't need access to CORBA or SOAP or Kerberos or RMI or TIFF decoding or many other bits and pieces that Java exposes to them. You'd have way fewer vulnerabilities if mobile code had access to less privileged code.
Doubly unfortunately, the web guys don't seem to have learned this lesson. They didn't hesitate before trying to kill off Java applets back when the Java team were asleep at the wheel (they aren't any more), but since they decided everyone has to write stuff in HTML and Javascript they've been adding... yup, massive new chunks of functionality, implemented in C++. WebGL, the P2P video chat stuff, multimedia codecs, etc. Every Chrome update contains a bazillion security fixes and it's only the huge effort put into the native code sandbox that stops this being a total disaster. Firefox doesn't even have that!
Merchants can pick what level of card security they use online. The best possible is 3D-Secure and friends which involve the user authenticating to their bank when a card transaction is made. But some merchants don't like the additional complexity and overhead it adds to the purchasing process, they prefer to do their own risk analysis and bug the user less.... possibly swallowing the fraud if they let it through. Amazon famously doesn't ask for the CVV code because they think they can sell more if they avoid it, and they are confident in their own fraud detection abilities.
Criticising EMV for not preventing skimmed Target details from being used online is kind of dumb, given that it wasn't designed to protect internet transactions at all.
It is important to underline that, as we write these lines, the attack described in this paper is not applicable anymore, thanks to the activation of a new authentication mode (CDA, Combined Data Authentication) and network level protections acting as a second line of defense. Until the deployment of CDA, this fraud was stopped using network-level counter-measures and PoS software updates.
Hognoxious didn't say he was American - nice assumption though. Many cable TV providers around the world provide subscription access to the UK BBC channels. I live in Switzerland and get BBC+ITV through my cable subscription.
It makes perfect sense within their very limited and garbled world view. GCHQ fight terrorists, which could be "anyone". But MPs are not terrorists. Therefore, it makes sense to protect MPs (no false negative risk) whilst spying on everyone else.
Where this perception parts with reality is that of course, once GCHQ has the tools, of course they're going to spy on MPs if they convince themselves than an MP is sufficiently dangerous e.g. threatens their budget. Corbyn offers much potential for this type of hilarity ensuing. And their mandate is anything that's in "the British interest", not at all limited to terrorism investigations. Blackmailing MPs can absolutely be squared with defending The British Interest, it doesn't take much in the way of mental gymnastics there at all.
The fundamental issue to all of this is that most MPs are technically illiterate and can't/don't want to understand what it is that modern intelligence agencies really do. A lot of them seem to think that there's a difference between bulk collection and analysis, for example, apparently not realising that much analysis is automatable these days.
Yeah, or the teenagers that enjoy fucking with him so much will get the picture and stop doing so. Krebs is a journalist, not a cop - he wants to write stories. Nonetheless he has developed quite the track record of winning in the various conflicts forum-dwellers engage in. He's not a guy anyone should mess with lightly.
There seems to be an assumption that nobody can do "real coding" if they don't have a degree. But all the information taught in degrees is available online to anyone who wants to study it themselves.
Although it's likely that if you ask both of these developers to develop an efficient algorithm/data structure to do something novel, the one with the traditional four year degree is more likely to come up with a better solution
You're assuming the self study guy somehow mysteriously can't read up on algorithm design.
But here's a much more realistic scenario:
You ask the two guys to solve a new problem. You don't actually specify "you must design your own algorithm" because that's not a business or product requirement. The guy fresh out of university wastes a huge amount of time fucking about with designing his own ad-hoc data structures and ends up producing a crappy, inefficient solution that's poorly documented, buggy and probably contains his own reimplementation of a hash table. The self study guy spends a couple of hours on Google and finds a pre-written library that he can adapt to the particular circumstances of the issue.
The UK has a first-past-the-post system had had a coalition government between 2010-2015. It has also seen the complete wipeout of the two main parties in Scotland in favour of a third nationalist party.
The idea that a two-party system under FPTP is inevitable, is not backed by the facts.
People rage about it because it is an idiotic waste of valuable time.
Yes, in this case changing a file extension of a new file format is not a big deal, and three more letters won't kill anyone. Heck, I'd rather have a command be called "brotli" than "bro" just due to fewer chances of random conflicts.
But the justification is completely illogical, and once engineering decisions start being made on the basis of stuff that doesn't even TRY to be logical but is purely emotional, the amount of wasted time can become unreal.
As an example, I am familiar with one case where a company had an internal tool for mapping internal dependencies called "Octopussy". You know, like Octopus but with James Bond connotations, because the graphs it drew looked a bit like an octopus. Well, guess what happened next.... someone threw a hissy fit and demanded it be renamed. Only problem was, the tool wasn't maintained anymore. And over time it had become an internal data source for other tools, which at that point had the name hard-coded into them (network endpoints etc). Some of those tools were also only sporadically maintained. So people had to be dragged off existing projects to spend time on "fixing" a non-existent problem that existed only in someones mind. Many, many hours were wasted and of course all the people who had to work on that learned an abiding hatrid of radical feminism.
THAT is why people get mad about shit like this story. Give an inch and suddenly the amount of money, time and mental energy being burned can become insane.
Hunch correct. I've met Jyrki. He's a great guy. Also - a Finn who lives in Switzerland, not an American.
Jyrki is very smart, not prone to bullshit or nonsense. He surely knows this issue is ridiculous, which is why they moved on so fast with only a minor comment about "not understanding why people are upset". There are more important things to do in life than argue with people who are wrong on the internet.
(irony of me posting this to slashdot well understood)
Let me summarise the key findings of the paper. The headline figure is stunning: over 70% of all sites they tested leaked their origin IP in some way.
But. It's not quite as simple as that. Virtually all websites that are DDoS protected are using CloudFlare, probably because it's a free service. The vast majority of the times they were able to find the origin IP address, it was due to basic oversights by the website admin, typically, having subdomains that resolve to the origin IP or simply never moving the server after signing up for CloudFlare at all. The most common subdomain that leaked the IP was called "ftp".
Who the heck actually still runs an FTP server as part of their website, in this day and age? No big websites do that's for sure.
And sure enough the paper concludes, not surprisingly, that bigger more important websites are much less likely to leak their origin IPs than smaller ones.
I think all this paper really says is that CloudFlare have a lot of small non-paying customers who aren't really playing in the big leagues and aren't being attacked by sophisticated attackers... or possibly aren't being attacked at all.... and as a result are more likely to have made simple errors.
So when the headline says these protections are "easily" bypassed, all it's really saying is that if someone using a defensive system makes mistakes, they can still be attacked. That's not really news and doesn't tell us anything about the efficiency of these services when the people using them have done their homework.
You realize this sort of attack was entirely expected, and that the system is engineered to withstand it, and did, trivially?
Expected, yes. Engineered to withstand - no. Bitcoin Core nodes accept as many transactions as they can with no memory limit until eventually they bloat up so much the operating system kills them. The official "solution" for this is to babysit your node and if you see it running out of memory, change a command line flag to make it ignore any transactions with lower than the given fee. Unfortunately of course, this also ignores all end user transactions paying lower than that fee as well.
I maintain a fork of Core called Bitcoin XT. It has a flag that lets you set a maximum number of transactions to keep in memory at once (and in a future version it'll change to be a max number of bytes, as that's the actual resource that's limited). The node will randomly remove a transaction from the pool to make room for a new one when out of space. As during an attack the memory pool is mostly full of spam, obviously this logic mostly involves kicking out spam to make room for {more spam, actual legit transaction} as opposed to just falling over and dying.
And from the other Slashdot discussion, a picture of Linus and Greg sitting together. Wow, Linus wasn't kidding. Greg KH is enormous! I don't mean fat, I mean, literally he does appear to be a giant. Unless there's something weird about that camera perspective it's not totally surprising that Linus may have made a joke along the lines of "you should be scared of Greg".
Now, I'm all for professional communication, and emails can be easy to misinterpret, but this looks like a bit of an over-reaction. Someone commented that they send patches to Greg KH because Linus scares him, but added a winkey smiley afterwards, i.e. not really all that scary. Then Linus made a joke about Greg being big and squishing people that may or may not be playful or insulting, without knowing much about the relationship between these guys it's hard to say. Squish is hardly a word you use when you're really angry though.
And then Linus and Ingo gently tick off Greg and says he should be tougher, Linus says Greg is acting like a "door mat" and says "You may need to learn to say no to people". Ingo says "be frank with contributors and sometimes swear a bit". Probably this discussion would be held off list in a more traditional corporate environment to avoid embarrassing Greg (though "you are too nice" is not that embarrassing), but he takes it in his stride and agrees to be tougher.
OK, so far, just another day in open source land? Well, then Sarah Sharp flies off the handle and says:
Seriously, guys? Is this what we need in order to get improved -stable? Linus Torvalds is advocating for physical intimidation and violence. Ingo Molnar and Linus are advocating for verbal abuse.
Not *fucking* cool. Violence, whether it be physical intimidation, verbal threats or verbal abuse is not acceptable. Keep it professional on the mailing lists.
What the heck? The only thing she could be referring to this thread so far has been Linus talking about Greg being a giant who might "squish you without even noticing". Nobody could seriously interpret that as advocating for violence unless you were so unbelievably literal you'd be unable to handle ordinary conversations.
And then there's the conflation of "verbal abuse" with "violence". These are two words that mean very different things. And finally the assertion that by trying to make jokes (perhaps not very well), Linus and Ingo were being unprofessional. Not surprisingly, Linus had a problem with this claim.
Now I don't know, probably this could have been avoided if the discussion with Greg had been private. But it seems Sharp would have let rip at some other point if someone else made an off-colour joke. I can believe LKML is a tough environment, but this isn't the best evidence possible. Perhaps there have been other incidents, but as Sharp doesn't list any, it's hard to say.
Slashdot Mirror
Well, did you read the article?
Samsung have patched nearly all the bugs in the October online update and the rest will be done in this months update. So your anger is misplaced: Samsung have joined the monthly update cycle Google is pushing. I see no reason to believe the Nexus team would be doing things any faster.
It's not exactly unheard of in other projects. Gerrand stating outright that meta-discussion is "noise" represents the camel's nose under the tent - once communities start down this direction pretty quickly almost anything can become banned.
The Bitcoin community is going through this right now. Some of the developers who work on Bitcoin Core have decided they don't think the block chain should be able to grow in future, and a temporary 1mb block size limit should become .... less temporary. But of course limiting the block chain in this way is wildly unpopular, so they implied they could only raise the limit when there was consensus (of everyone). Not surprisingly this led to a LOT of debate, threads, discussion, some of it heated. Their response was to announce that the dev list had been flooded with "noise" and impose draconian moderation in which anything that might upset anyone was forbidden - which included discussion of technical topics that somebody found upsetting.
BTW it's a bit ironic that your sig says "Safety is a tyrant's tool; no one can oppose safety" on a post that's arguing for an incredibly large and complex moderation policy. Elsewhere it was suggested that be courteous and professional is the only policy needed and I'm minded to agree. There's nothing wrong with moderation to kick out genuinely problematic people, but any policy that forbids "microaggressions" (whatever the hell that means) is rightly going to be flamed for being wildly over the top.
Certificate Transparency is a Google-driven initiative taking place at the IETF to design a system to increase trust in the public key infrastructure (PKI).
The basic issue is this. The simplest way to design a public key infrastructure is to have a bigass central database that maps names to public keys. If you navigated to foobar.com, your browser would go consult the Bigass Database and look up the public key there in some secure way, then check it matched what the foobar.com server was using.
This design has a lot of downsides and a couple of upsides. The downsides are that it scales horrible, that an outage of the Bigass Database would mean an outage of the entire secure internet, that nobody is really incentivised to pay the huge costs of running it, whoever ran it would be a monopoly, and that the owners of the database would get a record of everyone's browsing sessions. The big upside is that all public keys are transparent: nobody can insert a fake mapping without being spotted, assuming there are people paying attention. And additionally, if someone lost control over a private key, the key can be revoked by just deleting it from the database.
So there are tradeoffs, but in practice the PKI (largely designed in the 1990's) doesn't use a Bigass Database. It uses certificate chains instead. Browsers and other SSL clients choose to trust a number of certificate authorities which issue certificates to servers, and those servers present their certificate chain during connection setup. Then the client can check that the public key/identity binding is valid by checking the chain of digital signatures. This scales, is robust, avoids monopolies (adding a new trusted CA is easy) and has great privacy.
That leaves the two upsides of the Bigass Database approach: revocation and transparency. Revocation is easy, you use something called OCSP stapling. CA's run a server that issues a short, signed, time limited statement of the form "certificate ABC is not revoked". Traditionally it was supposed to be the clients that did the server call, but that brought back the privacy and outage problems, so in modern setups it's the server that requests this statement and caches it for a while, then hands it to the client along with all the rest of the data.
Finally, there's the issue of transparency. CT fixes transparency. The plan is to require CAs to publish every certificate they sign in a global audit log. The log is structured somewhat like a block chain. To enforce that CAs can't sign certificates in secret, and to avoid the CT logs being hammered with privacy-sensitive traffic, a stapling approach is used again: the certificates themselves contain a mathematical proof that they exist in the global logs. Thus clients (like Chrome) can check that a certificate was published and eventually stop accepting any cert that lacks the proof.
So we end up with a PKI design that is very complicated, but lets us have our cake and eat it - we've been able to get all the major features we'd like (scalability, privacy, reliability, provider competition, agility, revocability) without compromises.
Yeah, that's how Chrome does it, that's actually how Java has done it for a long time already (JREs "expire" around the dates of scheduled security updates and refuse to run applets until you upgrade), it's how Apple should do it too.
Modern Java's aren't actually that bad, security wise. The problem is there's a massive long tail of old Windows machines that are still running ancient JVMs before even things like expiry were added.
The latter is better.
I don't believe GCHQ gives a shit about the rule of law, seeing as how they're basically a subsidiary of the NSA (to the extent that they seem to share internal networks no less).
But nonetheless, the fact that governments are passing or trying to pass such laws is STILL a big improvement over the previous state of affairs, where their intelligence agencies are/were building these databases covertly whilst lying about doing so. At least this way the regular democratic processes have a chance to work, regardless of how flawed they might be.
I think the British government is going to lose this one (practically, not legislatively). The issue they have is that the UK isn't China: it doesn't have a home grown internet industry. The UK contributes to the global tech industry in big ways: virtually all consumer electronics are using ARM chips, the UK built one of the first computers, and there are tons of Brit's doing great work in the computing field today.
But when it comes to the giant cloud services that store everyone's data there's only really two places in the world that matter, and that's Silicon Valley and Seattle. All that data is entering and leaving the UK in encrypted form: all they and the ISPs can see is which companies are being interacted with. That trend will continue and probably even accelerate now LetsEncrypt is here. So the govt can legislate whatever the hell they like, but the data that results is going to be of low quality.
I suspect they know this and they're going to try and introduce laws that force Facebook/Google/Apple/etc to act as extensions of GCHQ. To what extent these companies go along with it will be the most fascinating fight of the coming years.
Errr .... that analogy is, I would say, not excellent.
Orwell primarily wrote about what was happening in other countries. Animal Farm was a wafer-thin allegory about the events happening inside Soviet Russia and what Stalin was doing in particular. Orwell found it hard to get published because at the time, Stalin wasn't understood as the monster he truly was: rather the USSR was still seen as the ally against the Nazi's that made huge sacrifices to win, the ally that rolled into Berlin.
1984 was Orwell's attempt to imagine what a Soviet-style totalitarian regime would look like if implemented in the UK. It's full of references to "Ingsoc" because it was another book about the evils of communism as practiced elsewhere.
Orwell wrote those books because, at the time, he felt very pessimistic about the future of his homeland. He felt sure that a communist/fascist takeover was going to happen. Towards the end of his life he admitted he had been entirely mistaken about that and England hadn't worked out the way he thought it would.
Ironically, Orwell was a committed socialist himself. He didn't write about the evils of communism because he was a capitalist. Rather, he saw communism as practiced abroad as a corruption of true democratic socialism, and he believed the right way to bring about a hard-left government was through the ballot box rather than through a fascist uprising.
I think the study seems to be suffering from this problem. Reading the methodology section, they basically measured whatever speeds the users encountered whilst just 'doing their thing'. The problem being that this isn't really evidence of ISP dishonesty: it's measuring the overall speed of the internet and assuming there are no bottlenecks beyond the last miles.
I suspect what's happening here is that people in Europe are more often connecting to websites that are far away and have to transit many networks to get to them, for example, trans-Atlantic. Then the bottleneck moves out of the ISPs own network. For instance, because many Europeans speak good English and so can benefit from American websites, whereas Americans typically don't speak European languages (beyond maybe Spanish) so get less benefit from browsing far away European websites.
OpenJDK is Oracle's JDK, minus a few commercial features.
Bear in mind that the 154 holes is for all Oracle products. They have a unified update release schedule which Java follows. There were actually "only" about 25 (I think) security holes fixed in the latest Java release. Of those, a lot were in components like CORBA or JAXRS, stuff that most code doesn't really need access to. And of course these only matter for sandboxing; I think only one affected server apps and that was a partial denial-of-service issue.
Unfortunately one of the problems applets have isn't so much that Java the language or design itself is insecure, but simply that the provided functionality is so enormous that bugs in relatively unimportant subsystems can end up compromising security. I think if you were to try and define an Applets2 standard these days you'd be waaaaay more aggressive with locking off access to big chunks of functionality. Applets don't need access to CORBA or SOAP or Kerberos or RMI or TIFF decoding or many other bits and pieces that Java exposes to them. You'd have way fewer vulnerabilities if mobile code had access to less privileged code.
Doubly unfortunately, the web guys don't seem to have learned this lesson. They didn't hesitate before trying to kill off Java applets back when the Java team were asleep at the wheel (they aren't any more), but since they decided everyone has to write stuff in HTML and Javascript they've been adding ... yup, massive new chunks of functionality, implemented in C++. WebGL, the P2P video chat stuff, multimedia codecs, etc. Every Chrome update contains a bazillion security fixes and it's only the huge effort put into the native code sandbox that stops this being a total disaster. Firefox doesn't even have that!
"I used my card in the old insecure mode several times and then am surprised when the card got skimmed"? Really?
Merchants can pick what level of card security they use online. The best possible is 3D-Secure and friends which involve the user authenticating to their bank when a card transaction is made. But some merchants don't like the additional complexity and overhead it adds to the purchasing process, they prefer to do their own risk analysis and bug the user less .... possibly swallowing the fraud if they let it through. Amazon famously doesn't ask for the CVV code because they think they can sell more if they avoid it, and they are confident in their own fraud detection abilities.
Criticising EMV for not preventing skimmed Target details from being used online is kind of dumb, given that it wasn't designed to protect internet transactions at all.
Yes, it's fixed properly. From the paper:
Hognoxious didn't say he was American - nice assumption though. Many cable TV providers around the world provide subscription access to the UK BBC channels. I live in Switzerland and get BBC+ITV through my cable subscription.
It makes perfect sense within their very limited and garbled world view. GCHQ fight terrorists, which could be "anyone". But MPs are not terrorists. Therefore, it makes sense to protect MPs (no false negative risk) whilst spying on everyone else.
Where this perception parts with reality is that of course, once GCHQ has the tools, of course they're going to spy on MPs if they convince themselves than an MP is sufficiently dangerous e.g. threatens their budget. Corbyn offers much potential for this type of hilarity ensuing. And their mandate is anything that's in "the British interest", not at all limited to terrorism investigations. Blackmailing MPs can absolutely be squared with defending The British Interest, it doesn't take much in the way of mental gymnastics there at all.
The fundamental issue to all of this is that most MPs are technically illiterate and can't/don't want to understand what it is that modern intelligence agencies really do. A lot of them seem to think that there's a difference between bulk collection and analysis, for example, apparently not realising that much analysis is automatable these days.
Yeah, or the teenagers that enjoy fucking with him so much will get the picture and stop doing so. Krebs is a journalist, not a cop - he wants to write stories. Nonetheless he has developed quite the track record of winning in the various conflicts forum-dwellers engage in. He's not a guy anyone should mess with lightly.
What makes you think that?
There seems to be an assumption that nobody can do "real coding" if they don't have a degree. But all the information taught in degrees is available online to anyone who wants to study it themselves.
You're assuming the self study guy somehow mysteriously can't read up on algorithm design.
But here's a much more realistic scenario:
You ask the two guys to solve a new problem. You don't actually specify "you must design your own algorithm" because that's not a business or product requirement. The guy fresh out of university wastes a huge amount of time fucking about with designing his own ad-hoc data structures and ends up producing a crappy, inefficient solution that's poorly documented, buggy and probably contains his own reimplementation of a hash table. The self study guy spends a couple of hours on Google and finds a pre-written library that he can adapt to the particular circumstances of the issue.
The UK has a first-past-the-post system had had a coalition government between 2010-2015. It has also seen the complete wipeout of the two main parties in Scotland in favour of a third nationalist party.
The idea that a two-party system under FPTP is inevitable, is not backed by the facts.
People rage about it because it is an idiotic waste of valuable time.
Yes, in this case changing a file extension of a new file format is not a big deal, and three more letters won't kill anyone. Heck, I'd rather have a command be called "brotli" than "bro" just due to fewer chances of random conflicts.
But the justification is completely illogical, and once engineering decisions start being made on the basis of stuff that doesn't even TRY to be logical but is purely emotional, the amount of wasted time can become unreal.
As an example, I am familiar with one case where a company had an internal tool for mapping internal dependencies called "Octopussy". You know, like Octopus but with James Bond connotations, because the graphs it drew looked a bit like an octopus. Well, guess what happened next .... someone threw a hissy fit and demanded it be renamed. Only problem was, the tool wasn't maintained anymore. And over time it had become an internal data source for other tools, which at that point had the name hard-coded into them (network endpoints etc). Some of those tools were also only sporadically maintained. So people had to be dragged off existing projects to spend time on "fixing" a non-existent problem that existed only in someones mind. Many, many hours were wasted and of course all the people who had to work on that learned an abiding hatrid of radical feminism.
THAT is why people get mad about shit like this story. Give an inch and suddenly the amount of money, time and mental energy being burned can become insane.
Haha, you got off easy my friend. More than one file format uses as its magic number 0xCAFEBABE
Hunch correct. I've met Jyrki. He's a great guy. Also - a Finn who lives in Switzerland, not an American.
Jyrki is very smart, not prone to bullshit or nonsense. He surely knows this issue is ridiculous, which is why they moved on so fast with only a minor comment about "not understanding why people are upset". There are more important things to do in life than argue with people who are wrong on the internet.
(irony of me posting this to slashdot well understood)
Let me summarise the key findings of the paper. The headline figure is stunning: over 70% of all sites they tested leaked their origin IP in some way.
But. It's not quite as simple as that. Virtually all websites that are DDoS protected are using CloudFlare, probably because it's a free service. The vast majority of the times they were able to find the origin IP address, it was due to basic oversights by the website admin, typically, having subdomains that resolve to the origin IP or simply never moving the server after signing up for CloudFlare at all. The most common subdomain that leaked the IP was called "ftp".
Who the heck actually still runs an FTP server as part of their website, in this day and age? No big websites do that's for sure.
And sure enough the paper concludes, not surprisingly, that bigger more important websites are much less likely to leak their origin IPs than smaller ones.
I think all this paper really says is that CloudFlare have a lot of small non-paying customers who aren't really playing in the big leagues and aren't being attacked by sophisticated attackers ... or possibly aren't being attacked at all .... and as a result are more likely to have made simple errors.
So when the headline says these protections are "easily" bypassed, all it's really saying is that if someone using a defensive system makes mistakes, they can still be attacked. That's not really news and doesn't tell us anything about the efficiency of these services when the people using them have done their homework.
Expected, yes. Engineered to withstand - no. Bitcoin Core nodes accept as many transactions as they can with no memory limit until eventually they bloat up so much the operating system kills them. The official "solution" for this is to babysit your node and if you see it running out of memory, change a command line flag to make it ignore any transactions with lower than the given fee. Unfortunately of course, this also ignores all end user transactions paying lower than that fee as well.
I maintain a fork of Core called Bitcoin XT. It has a flag that lets you set a maximum number of transactions to keep in memory at once (and in a future version it'll change to be a max number of bytes, as that's the actual resource that's limited). The node will randomly remove a transaction from the pool to make room for a new one when out of space. As during an attack the memory pool is mostly full of spam, obviously this logic mostly involves kicking out spam to make room for {more spam, actual legit transaction} as opposed to just falling over and dying.
And from the other Slashdot discussion, a picture of Linus and Greg sitting together. Wow, Linus wasn't kidding. Greg KH is enormous! I don't mean fat, I mean, literally he does appear to be a giant. Unless there's something weird about that camera perspective it's not totally surprising that Linus may have made a joke along the lines of "you should be scared of Greg".
It took a hell of a lot of digging, but it seems to have started with this thread, way back in 2013.
Now, I'm all for professional communication, and emails can be easy to misinterpret, but this looks like a bit of an over-reaction. Someone commented that they send patches to Greg KH because Linus scares him, but added a winkey smiley afterwards, i.e. not really all that scary. Then Linus made a joke about Greg being big and squishing people that may or may not be playful or insulting, without knowing much about the relationship between these guys it's hard to say. Squish is hardly a word you use when you're really angry though.
And then Linus and Ingo gently tick off Greg and says he should be tougher, Linus says Greg is acting like a "door mat" and says "You may need to learn to say no to people". Ingo says "be frank with contributors and sometimes swear a bit". Probably this discussion would be held off list in a more traditional corporate environment to avoid embarrassing Greg (though "you are too nice" is not that embarrassing), but he takes it in his stride and agrees to be tougher.
OK, so far, just another day in open source land? Well, then Sarah Sharp flies off the handle and says:
What the heck? The only thing she could be referring to this thread so far has been Linus talking about Greg being a giant who might "squish you without even noticing". Nobody could seriously interpret that as advocating for violence unless you were so unbelievably literal you'd be unable to handle ordinary conversations.
And then there's the conflation of "verbal abuse" with "violence". These are two words that mean very different things. And finally the assertion that by trying to make jokes (perhaps not very well), Linus and Ingo were being unprofessional. Not surprisingly, Linus had a problem with this claim.
Now I don't know, probably this could have been avoided if the discussion with Greg had been private. But it seems Sharp would have let rip at some other point if someone else made an off-colour joke. I can believe LKML is a tough environment, but this isn't the best evidence possible. Perhaps there have been other incidents, but as Sharp doesn't list any, it's hard to say.
It's not just Europe. Many parts of the world do this. America is one of the few that's been left behind.