It's not clear to me how using brackets would have helped. The code would have failed even if there were brackets around one or the other or both of the offending statements. And it's not clear if the additional brackets would have increased the likelihood that the mistake would have been noticed.
Brackets around the entire IF would have caused it to work as expected, the second `goto fail;' would simply never get used. Brackets around only the first would have caused the second to look a lot more out of place, at least as much more as two identical lines on identical indents could. Where is the indent regime on this issue anyway? Isn't that even more of a style atrocity than foregoing brackets? Nothing like intentionally making your code look like assembly spit from a debugger to make it easy to maintain.
I've been in this field for 20+ years now, and I don't necessarily (in fact, I usually don't) agree with whatever the current trend is (which is probably why my karma is negative). One underlying trend, has been to make software something that can be made by anyone - to remove the requirement of having a special mind that is able to think through algorithms and code. This has generally been accomplished through process, and abstraction. Process - if we can describe a method well enough, then anyone should be able to follow it to it's logical conclusion. Abstraction - we keep adding layers upon layers in an effort to simplify and streamline that which is a complex thing (lots of numbers in sequence to control a microprocessor and it's accompanying hardware). You can probably tell that I'm not a great fan of either - though I'm really really trying to not be a negative type, and to go with the flow more. But I can't help my fundamental feelings that there is just no substitute for a smart individual with a gift of understanding the logic of code. I'm always against process because it takes the gift that i was given and neutralizes it. Personal feelings aside, I just don't think that all the process in the world is ever going to get ahead of the curve that is the battle between perfectly functional software and bugs.
If you make brilliant code that only you can understand, sorry to be harsh but you aren't that brilliant. We definitely need to value people who can generate and perfect algorithms, but do you think anyone would remember/value the Pythagorean Theorem if it was 40 steps long? No, he thought of a (then brilliant) way to do it simply and easily so that one only needs to understand basic math to pull it off. This is what we need more of; a single elegant algorithm that is so short it is hard to misuse is better than 1,000 algorithms that are all so hard to understand that only the author knows exactly how it works and will be forgotten as soon as the particular language or application fades into the past.
If you're selling that you coulda/woulda caught all X for X that haven't happened yet, you're selling snake oil. The reality is that this computer stuff is a little harder than it looks to do properly, and if all you have to offer is marketing bullshit and a History of Art degree, maybe you should leave it to the professionals, and push for budget to do things correctly rather than just do them.
But PC-Lint has been successful at finding _every_ bug in Dr Dobbs...
They are comparing the test methods that might have cought the Apple SSL "goto fail" bug vs the Heartbleed openssl bug (which was unchecked memory access). How do we know there isn't another SSL bug in either? That's right, we don't. And we won't until testing (automated or otherwise) gets better in both places. Ideally we would have a way to find (and fix) lots of worms in both.
The basic premise of this discussion was users who are expecting security (face it, if you are clueless you won't give a shit if your linksys router is compromised or not and will live life in bliss) so yes, there is a (really low) bar for the expectation of the user in this premise.
Those aren't "traditional" e-readers in the sense of having an eInk display. Both are LCD based tablets with Android.
So the requirement is what? "you can have an e-reader as long as it has an e-ink display and doesn't run android" ? Hell no, "no e-readers" is what gets mandated.
I have thrown away 4 or 5 routers in the past 2 years (and gotten a nice service call fee for doing so) thanks to guys like you saying that shit only for OpenWRT to totally brick the router...thanks, keep up the good work!
Anyone who can't spend 5 minutes on a forum finding out what will/wont work on their router deserves to part with their money, so, enjoy your work! As for me, I have reflashed at least a dozen different embedded devices (with OpenWRT and other open packages) with 0 bricks. Cheers!
OpenWRT is so fucking easy to install and configure (easier than some consumer out-of-the-box experiences, even) that there really is no excuse if you expect a secure local network.
No. It's not. To you, or the typical computer tech-savvy/. reader, maybe; but we're not average consumers. My father-in-law is well above average in that he bought a Linksys router rather than depend on the FIOS installed default, and he actually changed the password, but he's not going to reflash it any more than I'm going to rebore my car engine's cylinders with a hand drill. And the various older neighbors who I assist with network stuff, who think the Internet is broken if a web site changes its format, would have no clue whatever.
The REAL question we should all be asking is, If OpenWRT can be so much better, then why is the commercial stuff *not* better?
Step 1, find out what runs on your router (at wikidevi or similar) step 2, download the firmware image (there are even multiple forums with helpful folks to ask if you arent 100% sure) step 3, flash it the same way you would a normal firmware update, step 4 change the default password, and enjoy your new LAN! The only excuse is not knowing... there is no actual technical knowledge required, just basic keyboard/mouse skills, and reading comprehension.
If a device does not have a way to keep track of time (eg. in built real time clock, with backup battery that will last for the duration of the device's 'lifetime'), then it becomes vulnerable to permanent denial of service when something spoofs a fake future date and time. What happens when a hundred thousand devices go offline because someone spoofed an NTP response?
You may as well force every device to have a kill switch and remotely shut it down when it's too old. At least that'll probably require some kind of public key signature from an authenticated service (in the same way you'd authenticate a remote firmware update).
What I'm trying to say is this is one of those 'management ideas' that sounds great in the philosophical sense, but fails in technical merit.
That's easy, let it count the hours it runs (as most devices already do) irrespective of time. After 3 years (or whatever) of operation, it stops or creates an annoying ass alarm buzz or something.
And more to the point, you have probably hit on the real "solution" to the security issue, a remote kill switch. If a vulnerability gets in the wild, simply kill all the affected devices until they can be reflashed with a fixed version (and a new timer). That's what you want to have happen anyway, right? 10 million silenced PLCs instead of 10 million nodes of some new botnet, attacking and putting at risk the other 10 billion devices on the net.
Or to put it another way, why the hell should I, as a manufacturer, be forced to pay, pay, and pay again for people to make updates for a cheap piece of hardware that barely covered its own cost in the first place?
If you want eternal support, you should buy from a vendor that offers eternal support at a suitably expensive price. If there isn't such a vendor, you should re-engineer your solution to include only components that have such support, or build those parts yourself.
You are presuming that humans are any good at all at assessing the risk of something as nuanced as purchasing something with no (meaningful) support. Does it work when I install it? No, ok take it back and get a new one. Yes, ok great leave it there until it stops working. Wait, there are two versions I can buy, they both do the exact same thing, but this one is twice as much because it comes with a 3 year service warranty? Fuck that I won't need it 3 years from now anyway, that is someone elses problem.
What could possibly go wrong ? A PLC controlling a plant stopping at some random date is perfectly acceptable, right. I'm sure manufacturers will love this. A guaranteed replacement market is a wet dream for any market.
Obsolescence is already planned for every single product, no matter what, period. If done properly (imho) then a guarateed fail-by date would cause the realization that the true cost of ownership per year for a system would include the cost of scrapping it when it's too old to work right. Today, what happens is a system is bought because it fit in the budget this year, and it's held on to for as long as possible, long after security and failure risk have climbed way way up past an acceptable point, because "it still works, don't it?" This "let me keep it as long as I want" mentality is exactly what causes many poor decisions and big big problems. If a part in a plant isn't being tracked right down to the date/time of manufacture, of installation (and who installed it and what software it had) then you are already Doing It Wrong. A rolling plan of "here are 10 cards we need to replace this month" is perfectly workable in any modern operation. If not, you deserve for your plant to shut down sooner rather than later.
Which assumes there's still someone around releasing updates
What about an EOL date that's calculated from the date of the last update?
No update for 12 months = EOL.
In an enterprise that sort of management would be fine, but I for one would be pissed to hell if I came home one day and my smart TV refused to turn on because it had gone 12 months with no updates. Like most things, the expectations of performance and security differ in every application, so no single rule will ever solve this.
Because not everyone can be arsed to buy a commercial product to fill a specific need, choosing one designed for that need, and then removing core software or hardware in order to make it "open". Some people like to buy things without having to re-engineer them when they get home.
Don't get me wrong. I rooted both my cellphones shortly after purchase, and I have a Linksys home router running custom firmware. I mod things for performance reasons or because it's interesting or enlightening. But not everyone can or should do so. In an ideal world*, the routers would have sane security by default.
I'll take off my rose-tinted specs now and go back to yelling at the kids on my lawn.
OpenWRT is so fucking easy to install and configure (easier than some consumer out-of-the-box experiences, even) that there really is no excuse if you expect a secure local network. If not, just plan on replacing your firewall/router every year or so to counter the threat of unpatched bugs. To each their own.
200 a day is _very_ ambitious, and you may get close to that when sprinting (figuratively... or literally if you adhere to Agile) but your daily average per quarter will be MUCH lower, in just about any language. That is, unless your goal is not good code but instead to have a high LOC/day metric.
Contract COBOL programmers can make 250+ an hour, just so you know.
All my friend who do Java make 150K a year+
"HTML 5, iOS, CSS 3, jquery" iOS isn't a programming language, the others trivial.
How long is the average Cobol contract? I am doubtful that a career can still be cobol-based given that pretty much all organizations are in break-fix mode on any systems that run it. You might get 250/hr today but tomorrow when the problem is gone, so are you.
So we all know that computer programming jobs are hot right now.
Only if you have an H1-B visa.
This is the exact reality today. If you are an American expecting a programming job, the question to ask is "how many overseas programmers would it take to do my job" and if the answer is less than 4 you are toast; 5 and you are on shaky ground; 6 and above and you should have no problem finding work.
It certainly depends on the language and the accountability for the functionality. If you are hacking together PHP or Ruby to run a web application you can probably turn out a few dozen lines a day of good code (on average) but on the other end, for embedded projects that require each line have a very important meaning (because space is at a premium) 2 to 5 lines/day is typical. Remember, being a good programmer means spending a lot of time understanding requirements, researching the best approach to a problem, and documenting the results. If you value "Fast" programmers who just throw code together, test it as they go, and call it a day once the code met whatever the generic objective is, you will end up with a very low quality result.
Lines/day and other very general metrics are OK for benchmarking an individual's performance (i.e. you turned out 5 lines/day this week, but last week you turned out 2 lines/day... what happened that was good/bad) but they are terrible for comparing programmers, and downright worthless for ranking an organization among others.
I think people are actually reacting with skepticism based on a long history of huge military orders which clearly are not the best value for taxpayer dollar.
Why the fuck should we start now? $2B for a bomber whose primary capability is nuking vast portions of a continent is a poor "Value" according to many, many taxpayers yet there are a few dozen of those things and we don't have slashdot discussions on it. An e-reader that they are procuring a few hundred of? This surely is not the low hanging fruit when it comes to wasted money.
Nellie Moffitt is a clueless person who shouldn't be quoted on technical manners.
"their GPS... can give away their position to the enemy"
A GPS receiver in a traditional e-reader (ARE there any traditional e-readers with a GPS?) can't give away your position on a sub because: 1) A GPS receiver is only a receiver 2) It doesn't know your position because it is in a metal tube 100's of feet below the water.
Kindle fire? B&N Nook? Yep both of those "e-readers" have GPS. And you know submarines occasionally do spent time at the surface, where their whereabouts are still a good thing to keep secret? Clearly instead of a more detailed policy they simply exclude any device that might resemble one with such capabilities, as a safeguard.
It's highly unlikely they will care, but try to make it fun and use lots of specific numbers, management types like that.
I was going to say roughly the same thing. Dazzle them with different, huge numbers. Tell them how much business data your SAN is currently backing up to protect it from loss. In bytes. Tell them how much bandwidth your firewall safely filters on average. In bits/second. Sure, after a few rounds they will start to ignore those reports too since they will all look alike, but you will have fun doing it right?
Disclaimer: I am not a corporate drone, this might be a totally bad idea, luckily I don't have to find out.
To my knowledge, the limitations of pseudo random number generators are not the weak point in encryption.
To my mind, the most pressing problem are caused by Moore's law (and similar effects). Whatever encryption is worthwhile now, is worthless in 5 years.
Not to mention the human sized holes in encryption caused by human limitations.
Having a true random number stream is very valuable since one of the key weaknesses in PRNGs come when you gather enough output and can guess what random numbers the algo will use next. This compromises forward secrecy. If you can use a stream of constantly random numbers, one weakness is gone entirely leaving you more time to worry about other issues (like human weakness, processing bottlenecks, etc). Also, see the issue of a PRNG with a backdoor allowing perfect guessing of the pattern hence making the encryption useless (thanks to the NSA, no less).
I can see how it will be awkward to carry a green LED around to wave in front of your smartphone to maintain the stream but more advancement may miniaturize that part to the point where it's barely noticable [/snark]
I'm no McAfee advocate by any means, but the span of time between the initial sales consultation and the unauthorized scraping indicates that the person involved with the scraping might not have been involved with the sales process and was ignorant of the need for a PO. The clumsy way they scraped without even trying to conceal their user agent indicates incompetence, rather than malice. Of course, McAfee's size and influence holds them to a higher standard that should preclude anyone running rogue like this.
Agreed, this is definitely a case where incompetence is more likely than malice. For fuck's sake, if it were malice they would at LEAST do it from an AWS, Azure, or [insert huge anonymizing cloud provider here] instance instead of from an IP directly registered to McAfee.
I noticed that convenient typo, too. It's amazing how much of a difference one little d at the end of a word can make. Makes me almost want actual editors on slashdot instead of these uneducated rogues.
Yes, dropbox used to mention this in the documentation (don't know if they still do), but if you put it in your public folder, it is public. I believe they used to say that it was even accessible without a link, if someone knew (or guessed) the specific folder+filename. One reason why I keep everything inside subject folders (within the public area) and not just plopped into the public folder en-mass, as it makes it harder to guess as you would have to guess the folder-name as well.
On another note, another think I do when I send a document (like applications or forms with personal data on them), is I upload the file to a custom folder, then send the link to the recipient with the specific instructions that they let me know once they've downloaded it, so I can delete it off dropbox. That way, in most cases, it's only available for a few minutes to maybe a couple hours at most, and if anyone happens to intercept the URL, the chances of the file still being there are slim, as it's deleted as soon as the intended recipient gets it. The only way it can be stolen, is if someone intercepts the email AND tries to download the file faster than the recipient does. While it's not fool proof, it's not a bad idea completely. Surely it's better than attaching the file to an email that gets passed through several servers along the way and copies are kept at each of those points.
For actual documents that can be PDFed the password based encryption function (set to aes128 or better, with a long password) is highly effective. You just need a pre-agreed password, or simply give the recipient a phone call and deliver the password verbally. For information that can't be PDFed, sadly there isn't anything as standard as PDF so obfuscation techniques may be the most effective approach.
Slashdot Mirror
It's not clear to me how using brackets would have helped. The code would have failed even if there were brackets around one or the other or both of the offending statements. And it's not clear if the additional brackets would have increased the likelihood that the mistake would have been noticed.
Brackets around the entire IF would have caused it to work as expected, the second `goto fail;' would simply never get used. Brackets around only the first would have caused the second to look a lot more out of place, at least as much more as two identical lines on identical indents could. Where is the indent regime on this issue anyway? Isn't that even more of a style atrocity than foregoing brackets? Nothing like intentionally making your code look like assembly spit from a debugger to make it easy to maintain.
I've been in this field for 20+ years now, and I don't necessarily (in fact, I usually don't) agree with whatever the current trend is (which is probably why my karma is negative). One underlying trend, has been to make software something that can be made by anyone - to remove the requirement of having a special mind that is able to think through algorithms and code. This has generally been accomplished through process, and abstraction. Process - if we can describe a method well enough, then anyone should be able to follow it to it's logical conclusion. Abstraction - we keep adding layers upon layers in an effort to simplify and streamline that which is a complex thing (lots of numbers in sequence to control a microprocessor and it's accompanying hardware). You can probably tell that I'm not a great fan of either - though I'm really really trying to not be a negative type, and to go with the flow more. But I can't help my fundamental feelings that there is just no substitute for a smart individual with a gift of understanding the logic of code. I'm always against process because it takes the gift that i was given and neutralizes it. Personal feelings aside, I just don't think that all the process in the world is ever going to get ahead of the curve that is the battle between perfectly functional software and bugs.
If you make brilliant code that only you can understand, sorry to be harsh but you aren't that brilliant. We definitely need to value people who can generate and perfect algorithms, but do you think anyone would remember/value the Pythagorean Theorem if it was 40 steps long? No, he thought of a (then brilliant) way to do it simply and easily so that one only needs to understand basic math to pull it off. This is what we need more of; a single elegant algorithm that is so short it is hard to misuse is better than 1,000 algorithms that are all so hard to understand that only the author knows exactly how it works and will be forgotten as soon as the particular language or application fades into the past.
If you're selling that you coulda/woulda caught all X for X that haven't happened yet, you're selling snake oil. The reality is that this computer stuff is a little harder than it looks to do properly, and if all you have to offer is marketing bullshit and a History of Art degree, maybe you should leave it to the professionals, and push for budget to do things correctly rather than just do them.
But PC-Lint has been successful at finding _every_ bug in Dr Dobbs...
They are comparing the test methods that might have cought the Apple SSL "goto fail" bug vs the Heartbleed openssl bug (which was unchecked memory access). How do we know there isn't another SSL bug in either? That's right, we don't. And we won't until testing (automated or otherwise) gets better in both places. Ideally we would have a way to find (and fix) lots of worms in both.
Reading comprehension... Is a hell of a drug.
The basic premise of this discussion was users who are expecting security (face it, if you are clueless you won't give a shit if your linksys router is compromised or not and will live life in bliss) so yes, there is a (really low) bar for the expectation of the user in this premise.
Those aren't "traditional" e-readers in the sense of having an eInk display. Both are LCD based tablets with Android.
So the requirement is what? "you can have an e-reader as long as it has an e-ink display and doesn't run android" ? Hell no, "no e-readers" is what gets mandated.
I have thrown away 4 or 5 routers in the past 2 years (and gotten a nice service call fee for doing so) thanks to guys like you saying that shit only for OpenWRT to totally brick the router...thanks, keep up the good work!
Anyone who can't spend 5 minutes on a forum finding out what will/wont work on their router deserves to part with their money, so, enjoy your work! As for me, I have reflashed at least a dozen different embedded devices (with OpenWRT and other open packages) with 0 bricks. Cheers!
OpenWRT is so fucking easy to install and configure (easier than some consumer out-of-the-box experiences, even) that there really is no excuse if you expect a secure local network.
No. It's not. To you, or the typical computer tech-savvy /. reader, maybe; but we're not average consumers. My father-in-law is well above average in that he bought a Linksys router rather than depend on the FIOS installed default, and he actually changed the password, but he's not going to reflash it any more than I'm going to rebore my car engine's cylinders with a hand drill. And the various older neighbors who I assist with network stuff, who think the Internet is broken if a web site changes its format, would have no clue whatever.
The REAL question we should all be asking is, If OpenWRT can be so much better, then why is the commercial stuff *not* better?
Step 1, find out what runs on your router (at wikidevi or similar) step 2, download the firmware image (there are even multiple forums with helpful folks to ask if you arent 100% sure) step 3, flash it the same way you would a normal firmware update, step 4 change the default password, and enjoy your new LAN! The only excuse is not knowing... there is no actual technical knowledge required, just basic keyboard/mouse skills, and reading comprehension.
If a device does not have a way to keep track of time (eg. in built real time clock, with backup battery that will last for the duration of the device's 'lifetime'), then it becomes vulnerable to permanent denial of service when something spoofs a fake future date and time. What happens when a hundred thousand devices go offline because someone spoofed an NTP response?
You may as well force every device to have a kill switch and remotely shut it down when it's too old. At least that'll probably require some kind of public key signature from an authenticated service (in the same way you'd authenticate a remote firmware update).
What I'm trying to say is this is one of those 'management ideas' that sounds great in the philosophical sense, but fails in technical merit.
That's easy, let it count the hours it runs (as most devices already do) irrespective of time. After 3 years (or whatever) of operation, it stops or creates an annoying ass alarm buzz or something.
And more to the point, you have probably hit on the real "solution" to the security issue, a remote kill switch. If a vulnerability gets in the wild, simply kill all the affected devices until they can be reflashed with a fixed version (and a new timer). That's what you want to have happen anyway, right? 10 million silenced PLCs instead of 10 million nodes of some new botnet, attacking and putting at risk the other 10 billion devices on the net.
Or to put it another way, why the hell should I, as a manufacturer, be forced to pay, pay, and pay again for people to make updates for a cheap piece of hardware that barely covered its own cost in the first place?
If you want eternal support, you should buy from a vendor that offers eternal support at a suitably expensive price. If there isn't such a vendor, you should re-engineer your solution to include only components that have such support, or build those parts yourself.
You are presuming that humans are any good at all at assessing the risk of something as nuanced as purchasing something with no (meaningful) support. Does it work when I install it? No, ok take it back and get a new one. Yes, ok great leave it there until it stops working. Wait, there are two versions I can buy, they both do the exact same thing, but this one is twice as much because it comes with a 3 year service warranty? Fuck that I won't need it 3 years from now anyway, that is someone elses problem.
What could possibly go wrong ? A PLC controlling a plant stopping at some random date is perfectly acceptable, right. I'm sure manufacturers will love this. A guaranteed replacement market is a wet dream for any market.
Obsolescence is already planned for every single product, no matter what, period. If done properly (imho) then a guarateed fail-by date would cause the realization that the true cost of ownership per year for a system would include the cost of scrapping it when it's too old to work right. Today, what happens is a system is bought because it fit in the budget this year, and it's held on to for as long as possible, long after security and failure risk have climbed way way up past an acceptable point, because "it still works, don't it?" This "let me keep it as long as I want" mentality is exactly what causes many poor decisions and big big problems. If a part in a plant isn't being tracked right down to the date/time of manufacture, of installation (and who installed it and what software it had) then you are already Doing It Wrong. A rolling plan of "here are 10 cards we need to replace this month" is perfectly workable in any modern operation. If not, you deserve for your plant to shut down sooner rather than later.
Which assumes there's still someone around releasing updates
What about an EOL date that's calculated from the date of the last update?
No update for 12 months = EOL.
In an enterprise that sort of management would be fine, but I for one would be pissed to hell if I came home one day and my smart TV refused to turn on because it had gone 12 months with no updates. Like most things, the expectations of performance and security differ in every application, so no single rule will ever solve this.
Because not everyone can be arsed to buy a commercial product to fill a specific need, choosing one designed for that need, and then removing core software or hardware in order to make it "open". Some people like to buy things without having to re-engineer them when they get home.
Don't get me wrong. I rooted both my cellphones shortly after purchase, and I have a Linksys home router running custom firmware. I mod things for performance reasons or because it's interesting or enlightening. But not everyone can or should do so. In an ideal world*, the routers would have sane security by default.
I'll take off my rose-tinted specs now and go back to yelling at the kids on my lawn.
OpenWRT is so fucking easy to install and configure (easier than some consumer out-of-the-box experiences, even) that there really is no excuse if you expect a secure local network. If not, just plan on replacing your firewall/router every year or so to counter the threat of unpatched bugs. To each their own.
200 a day is _very_ ambitious, and you may get close to that when sprinting (figuratively... or literally if you adhere to Agile) but your daily average per quarter will be MUCH lower, in just about any language. That is, unless your goal is not good code but instead to have a high LOC/day metric.
Contract COBOL programmers can make 250+ an hour, just so you know.
All my friend who do Java make 150K a year+
"HTML 5, iOS, CSS 3, jquery"
iOS isn't a programming language, the others trivial.
How long is the average Cobol contract? I am doubtful that a career can still be cobol-based given that pretty much all organizations are in break-fix mode on any systems that run it. You might get 250/hr today but tomorrow when the problem is gone, so are you.
So we all know that computer programming jobs are hot right now.
Only if you have an H1-B visa.
This is the exact reality today. If you are an American expecting a programming job, the question to ask is "how many overseas programmers would it take to do my job" and if the answer is less than 4 you are toast; 5 and you are on shaky ground; 6 and above and you should have no problem finding work.
It certainly depends on the language and the accountability for the functionality. If you are hacking together PHP or Ruby to run a web application you can probably turn out a few dozen lines a day of good code (on average) but on the other end, for embedded projects that require each line have a very important meaning (because space is at a premium) 2 to 5 lines/day is typical. Remember, being a good programmer means spending a lot of time understanding requirements, researching the best approach to a problem, and documenting the results. If you value "Fast" programmers who just throw code together, test it as they go, and call it a day once the code met whatever the generic objective is, you will end up with a very low quality result.
Lines/day and other very general metrics are OK for benchmarking an individual's performance (i.e. you turned out 5 lines/day this week, but last week you turned out 2 lines/day... what happened that was good/bad) but they are terrible for comparing programmers, and downright worthless for ranking an organization among others.
I think people are actually reacting with skepticism based on a long history of huge military orders which clearly are not the best value for taxpayer dollar.
Why the fuck should we start now? $2B for a bomber whose primary capability is nuking vast portions of a continent is a poor "Value" according to many, many taxpayers yet there are a few dozen of those things and we don't have slashdot discussions on it. An e-reader that they are procuring a few hundred of? This surely is not the low hanging fruit when it comes to wasted money.
Nellie Moffitt is a clueless person who shouldn't be quoted on technical manners.
"their GPS ... can give away their position to the enemy"
A GPS receiver in a traditional e-reader (ARE there any traditional e-readers with a GPS?) can't give away your position on a sub because:
1) A GPS receiver is only a receiver
2) It doesn't know your position because it is in a metal tube 100's of feet below the water.
Kindle fire? B&N Nook? Yep both of those "e-readers" have GPS. And you know submarines occasionally do spent time at the surface, where their whereabouts are still a good thing to keep secret? Clearly instead of a more detailed policy they simply exclude any device that might resemble one with such capabilities, as a safeguard.
It's highly unlikely they will care, but try to make it fun and use lots of specific numbers, management types like that.
I was going to say roughly the same thing. Dazzle them with different, huge numbers. Tell them how much business data your SAN is currently backing up to protect it from loss. In bytes. Tell them how much bandwidth your firewall safely filters on average. In bits/second. Sure, after a few rounds they will start to ignore those reports too since they will all look alike, but you will have fun doing it right?
Disclaimer: I am not a corporate drone, this might be a totally bad idea, luckily I don't have to find out.
To my knowledge, the limitations of pseudo random number generators are not the weak point in encryption.
To my mind, the most pressing problem are caused by Moore's law (and similar effects). Whatever encryption is worthwhile now, is worthless in 5 years.
Not to mention the human sized holes in encryption caused by human limitations.
Having a true random number stream is very valuable since one of the key weaknesses in PRNGs come when you gather enough output and can guess what random numbers the algo will use next. This compromises forward secrecy. If you can use a stream of constantly random numbers, one weakness is gone entirely leaving you more time to worry about other issues (like human weakness, processing bottlenecks, etc). Also, see the issue of a PRNG with a backdoor allowing perfect guessing of the pattern hence making the encryption useless (thanks to the NSA, no less).
I can see how it will be awkward to carry a green LED around to wave in front of your smartphone to maintain the stream but more advancement may miniaturize that part to the point where it's barely noticable [/snark]
I'm no McAfee advocate by any means, but the span of time between the initial sales consultation and the unauthorized scraping indicates that the person involved with the scraping might not have been involved with the sales process and was ignorant of the need for a PO. The clumsy way they scraped without even trying to conceal their user agent indicates incompetence, rather than malice. Of course, McAfee's size and influence holds them to a higher standard that should preclude anyone running rogue like this.
Agreed, this is definitely a case where incompetence is more likely than malice. For fuck's sake, if it were malice they would at LEAST do it from an AWS, Azure, or [insert huge anonymizing cloud provider here] instance instead of from an IP directly registered to McAfee.
open "sourced", not "open source."
http://osvdb.org/about
I was confused about how someone could be charged for access to "open source" information...
Here's the NPO, with two officers, backing it:
http://opensecurityfoundation....
I noticed that convenient typo, too. It's amazing how much of a difference one little d at the end of a word can make. Makes me almost want actual editors on slashdot instead of these uneducated rogues.
"McAfee Grabbed Data Without Paying, Says Open Source Vulnerability Database"
Smash and grab? I bet he is hiding out in Ecuador.
Yes, dropbox used to mention this in the documentation (don't know if they still do), but if you put it in your public folder, it is public. I believe they used to say that it was even accessible without a link, if someone knew (or guessed) the specific folder+filename. One reason why I keep everything inside subject folders (within the public area) and not just plopped into the public folder en-mass, as it makes it harder to guess as you would have to guess the folder-name as well.
On another note, another think I do when I send a document (like applications or forms with personal data on them), is I upload the file to a custom folder, then send the link to the recipient with the specific instructions that they let me know once they've downloaded it, so I can delete it off dropbox. That way, in most cases, it's only available for a few minutes to maybe a couple hours at most, and if anyone happens to intercept the URL, the chances of the file still being there are slim, as it's deleted as soon as the intended recipient gets it. The only way it can be stolen, is if someone intercepts the email AND tries to download the file faster than the recipient does. While it's not fool proof, it's not a bad idea completely. Surely it's better than attaching the file to an email that gets passed through several servers along the way and copies are kept at each of those points.
For actual documents that can be PDFed the password based encryption function (set to aes128 or better, with a long password) is highly effective. You just need a pre-agreed password, or simply give the recipient a phone call and deliver the password verbally. For information that can't be PDFed, sadly there isn't anything as standard as PDF so obfuscation techniques may be the most effective approach.