TBH, the Robert Mueller answer was run through a filter of arguable value before its summary was released. But then, it appears that TFA was also run through a filter, with the same result: the reader is left with more questions than answers. (See also: multiple disclaimers regarding methodology in TFA.)
Dropping political arguments, the core issue is how software is produced. Any programming or scripting language can be used to write unsafe and insecure code. All that's needed is sloppy design. How many developers are actually being taught how to design software, instead of just being taught the semantics of a given language? That's the crux of the issue.
...it only becomes sketchy when it's tied to a publicly-available token, such as a phone number. Tokens which don't have any public component, e.g. a Fido U2F token, are preferred...and, in fact, are in heavy use on the Facebook campus itself, by developers, moderators, etc. (Ask them why sometime.)
The only solution to the problem as described in the original article is to NOT provide them with a phone number, no matter how often they beg. And if they start forcing it, that's when the clueful will delete their accounts.
For your information, there is nothing in the US Constitution that provides for a "right to privacy".
For that matter, there is not, and never has been, any such thing as "privacy" online. If you post something ANYWHERE, expect someone unexpected to see it, and use it in a way you didn't intend.
"In the Nuts (unground), (other than ground nuts) Order, the expression nuts shall have reference to such nuts, other than ground nuts, as would but for this amending Order not qualify as nuts (unground) (other than ground nuts) by reason of their being nuts (unground)".
KeePass on a USB stick, in conjunction with a YubiKey and HOTP configuration, gives you two of the three security factors in just two USB slots. An attacker would need the master password AND both devices to gain access to your password database, and they'd have to know how you have your YubiKey configured to generate HOTPs. A preset number of failed YubiKey triggering attempts, and the database is locked. And good luck guessing the hash that generates the HOTPs. Doubly so since YubiKey configurations can't be read from the device, only written to the device. (Disclaimer: I don't work for Yubico or sell their devices. I'm just a satisfied user who's rather low on the corporate ladder.)
IMO, for the average corporate-level user, it's as good as it's going to get unless you want to delve into the expensive world of biometric authentication to gain the third security factor. And that opens up an entirely new can of worms, which will follow Zymurgy's Law of Evolving Thermodynamics.
Just my 2p worth. Save up the change for a root beer or something.
One of the biggest problems anyone sees if they look at the code being put into production is that whoever wrote the code never gave any thought to its being maintained later, after he/she departs the project. The coolest, froodiest, whiz-bang collection of libraries in use today may have been completely discarded when the next programmer comes along to fix the security hole written into the website/application/whatever, and perforce the new programmer MUST reinvent the wheel in order to repair what the first programmer never saw as a fault.
Languages such as COBOL survive because they are, in large part, self-documenting. (They also survive because no newer language is capable of accomplishing the job the original language did...but that's a separate argument.) While we slog our way through our next entry in the "Obfuscated C contest", similar code gets put into production as back-end processes for data mines, with predictably poor or unusable results, and after the programmer gets fired for not accomplishing the design goal in the PHB's time frame, the next poor sap dropped into the chair is left with trying to puzzle out what the first one was trying to do, and matching that up with whatever design specs the PHB expects to be met, and doing both in the same or shorter time frame as the first poor sap was given. Meanwhile, COBOL applications written 40 or more years ago continue to do the job they were designed to do, and do that job very well, and (provided one can still find a COBOL programmer) are maintained at comparatively low cost.
To avoid being accused of crossing Teddy Roosevelt's line (paraphrased as "Pointing out a problem without proposing a solution is called whining"), here's part of the answer: start programmers out on the KISS formula, and keep them writing code to that formula.
There is not, and never has been, any such thing as "privacy" on the Internet.
If you make your profile public anywhere, someone unexpected WILL read it..and use the information that you post in a way that you probably won't like.
We now return to our regularly-scheduled flamethrowing, already in progress...
There's absolutely nothing wrong with writing GPLv2 code in Ada. I can think of one major issue that could have been avoided entirely had Ada been the language of choice for a GPL application: the Heartbleed bug in OpenSSL.
"If software is safe, it cannot harm the world. If software is secure, the world cannot harm it."
-- John Barnes, author of several Ada programming texts
KeePass, or any other offline password manager, is a good first step. I really shouldn't need to go into the inherent issues with using an online password management system.
However, to improve the security of the database, go with two-factor authentication by adding plugins such as OtpKeyProv and configuring KeePass to use it in conjunction with a Yubikey token.
(Disclaimer: I am not associated with either the OtpKeyProv developer or with Yubico. I use them as examples based on past successes.)
"When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth."
-- Sir Arthur Conan Doyle, "The Adventure of the Blanched Soldier"
There is not, and never has been, any such thing as "online privacy". Those either unwilling to recognize that simple fact, or incapable of doing so, seem to be either businesses selling "online privacy" services or their customers.
Want a completely secure computer? Never plug it in. Ever.
It's pretty easy to guess the average age of posters in this thread. No one over eighteen cares.
Wrong. ALL photographers, no matter the age, should care about this case. School bureaucracy aside, it would set an incredibly dangerous set of precedents if left unchallenged.
I'd be willing to send that student a copy of the book The Law (In Plain English) For Photographers. Perhaps the principal should read it as well; it would show the principal exactly how wrong he is, before he has to sign off on spending a huge chunk of district money on legal fees.
Show me a chip vendor Linux toolchain or embedded building framework (buildroot, Yocto, etc.) which does NOT use GCC. There are exactly zero.
Incorrect. I can think of one right off the top, and while it's arguably a highly-specific niche market, it's still a viable market: GNAT Pro Ada. It very happily builds zero-footprint executables on a variety of embedded hardware, including the ARM M5 family. And the toolchain plays very, very well with Linux (and Windows, and Solaris, and...).
(I'll leave the argument over the relative merits of each language as a separate discussion.)
It can't be turned off by the consumer. It has to be disabled by Tier 2 tech support. And they will fight you tooth and nail to keep it on, hoping they'll wear you out before you convince them to turn it off.
True, but some languages make it more difficult to do so. Ada, for example, won't allow code to compile with (what should be) obvious logic or syntax errors that most C/C++ compilers will happily ignore, and hence allow to go undiscovered until runtime...errors that could be catastrophic in the real world.
Ada has acquired a reputation as a niche-market language, but that niche market takes heavy advantage of Ada's strengths: strong typing and a requirement that the developer properly design the software before writing code. Unfortunately, deciding to develop commercial software in Ada also comes with a fairly steep price tag, because it's a niche market...thus perpetuating the cycle.
DISCLAIMER: I am not affiliated with any company which produces or sells Ada compilers.
Slashdot Mirror
TBH, the Robert Mueller answer was run through a filter of arguable value before its summary was released. But then, it appears that TFA was also run through a filter, with the same result: the reader is left with more questions than answers. (See also: multiple disclaimers regarding methodology in TFA.)
Dropping political arguments, the core issue is how software is produced. Any programming or scripting language can be used to write unsafe and insecure code. All that's needed is sloppy design. How many developers are actually being taught how to design software, instead of just being taught the semantics of a given language? That's the crux of the issue.
...it only becomes sketchy when it's tied to a publicly-available token, such as a phone number. Tokens which don't have any public component, e.g. a Fido U2F token, are preferred...and, in fact, are in heavy use on the Facebook campus itself, by developers, moderators, etc. (Ask them why sometime.)
The only solution to the problem as described in the original article is to NOT provide them with a phone number, no matter how often they beg. And if they start forcing it, that's when the clueful will delete their accounts.
That's as far as I go.
For your information, there is nothing in the US Constitution that provides for a "right to privacy".
For that matter, there is not, and never has been, any such thing as "privacy" online. If you post something ANYWHERE, expect someone unexpected to see it, and use it in a way you didn't intend.
"In the Nuts (unground), (other than ground nuts) Order, the expression nuts shall have reference to such nuts, other than ground nuts, as would but for this amending Order not qualify as nuts (unground) (other than ground nuts) by reason of their being nuts (unground)".
KeePass on a USB stick, in conjunction with a YubiKey and HOTP configuration, gives you two of the three security factors in just two USB slots. An attacker would need the master password AND both devices to gain access to your password database, and they'd have to know how you have your YubiKey configured to generate HOTPs. A preset number of failed YubiKey triggering attempts, and the database is locked. And good luck guessing the hash that generates the HOTPs. Doubly so since YubiKey configurations can't be read from the device, only written to the device. (Disclaimer: I don't work for Yubico or sell their devices. I'm just a satisfied user who's rather low on the corporate ladder.)
IMO, for the average corporate-level user, it's as good as it's going to get unless you want to delve into the expensive world of biometric authentication to gain the third security factor. And that opens up an entirely new can of worms, which will follow Zymurgy's Law of Evolving Thermodynamics.
Just my 2p worth. Save up the change for a root beer or something.
...on the incoming number of "welcoming our insect overlords" jokes?
One of the biggest problems anyone sees if they look at the code being put into production is that whoever wrote the code never gave any thought to its being maintained later, after he/she departs the project. The coolest, froodiest, whiz-bang collection of libraries in use today may have been completely discarded when the next programmer comes along to fix the security hole written into the website/application/whatever, and perforce the new programmer MUST reinvent the wheel in order to repair what the first programmer never saw as a fault.
Languages such as COBOL survive because they are, in large part, self-documenting. (They also survive because no newer language is capable of accomplishing the job the original language did...but that's a separate argument.) While we slog our way through our next entry in the "Obfuscated C contest", similar code gets put into production as back-end processes for data mines, with predictably poor or unusable results, and after the programmer gets fired for not accomplishing the design goal in the PHB's time frame, the next poor sap dropped into the chair is left with trying to puzzle out what the first one was trying to do, and matching that up with whatever design specs the PHB expects to be met, and doing both in the same or shorter time frame as the first poor sap was given. Meanwhile, COBOL applications written 40 or more years ago continue to do the job they were designed to do, and do that job very well, and (provided one can still find a COBOL programmer) are maintained at comparatively low cost.
To avoid being accused of crossing Teddy Roosevelt's line (paraphrased as "Pointing out a problem without proposing a solution is called whining"), here's part of the answer: start programmers out on the KISS formula, and keep them writing code to that formula.
That's as far as I go.
So, what you're looking for is...
...a compiled language.
For those who may have missed the memo:
There is not, and never has been, any such thing as "privacy" on the Internet.
If you make your profile public anywhere, someone unexpected WILL read it..and use the information that you post in a way that you probably won't like.
We now return to our regularly-scheduled flamethrowing, already in progress...
The absolute defense to a charge of libel (or, if verbal, slander) is truth. FlightSimLabs should keep that in mind.
That's as far as I go.
Who builds the hardware that runs 5G infrastructure?
For that matter, are there any American companies making hardware that supports 4G infrastructure?
There's absolutely nothing wrong with writing GPLv2 code in Ada. I can think of one major issue that could have been avoided entirely had Ada been the language of choice for a GPL application: the Heartbleed bug in OpenSSL.
"If software is safe, it cannot harm the world. If software is secure, the world cannot harm it." -- John Barnes, author of several Ada programming texts
Project Blue Book.
KeePass, or any other offline password manager, is a good first step. I really shouldn't need to go into the inherent issues with using an online password management system. However, to improve the security of the database, go with two-factor authentication by adding plugins such as OtpKeyProv and configuring KeePass to use it in conjunction with a Yubikey token.
(Disclaimer: I am not associated with either the OtpKeyProv developer or with Yubico. I use them as examples based on past successes.)
There is not, and never has been, any such thing as "privacy" on the Internet.
This has been a public service announcement.
...that Edgar Allen Poe was far ahead of his time...especially when it comes to modern media.
"When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth." -- Sir Arthur Conan Doyle, "The Adventure of the Blanched Soldier"
I'm just sayin'.
There is not, and never has been, any such thing as "online privacy". Those either unwilling to recognize that simple fact, or incapable of doing so, seem to be either businesses selling "online privacy" services or their customers.
Want a completely secure computer? Never plug it in. Ever.
Anything else is bells and whistles.
...Kim Kardashian has published a book.
I'll be here all week. Tip your waiter.
It's pretty easy to guess the average age of posters in this thread. No one over eighteen cares.
Wrong. ALL photographers, no matter the age, should care about this case. School bureaucracy aside, it would set an incredibly dangerous set of precedents if left unchallenged.
I'd be willing to send that student a copy of the book The Law (In Plain English) For Photographers. Perhaps the principal should read it as well; it would show the principal exactly how wrong he is, before he has to sign off on spending a huge chunk of district money on legal fees.
Show me a chip vendor Linux toolchain or embedded building framework (buildroot, Yocto, etc.) which does NOT use GCC. There are exactly zero.
Incorrect. I can think of one right off the top, and while it's arguably a highly-specific niche market, it's still a viable market: GNAT Pro Ada. It very happily builds zero-footprint executables on a variety of embedded hardware, including the ARM M5 family. And the toolchain plays very, very well with Linux (and Windows, and Solaris, and...).
(I'll leave the argument over the relative merits of each language as a separate discussion.)
John Barnes, author of several Ada programming texts, sums it up:
I have yet to see a non-trivial application written in C++ which is both safe and secure.
And that's as far as I go.
It can't be turned off by the consumer. It has to be disabled by Tier 2 tech support. And they will fight you tooth and nail to keep it on, hoping they'll wear you out before you convince them to turn it off.
The license for GNAT GPL allows for FOSS development at no cost. Commercial development, however, typically runs around $25000US for up to five seats.
You can code sloppily in any language.
True, but some languages make it more difficult to do so. Ada, for example, won't allow code to compile with (what should be) obvious logic or syntax errors that most C/C++ compilers will happily ignore, and hence allow to go undiscovered until runtime...errors that could be catastrophic in the real world.
Ada has acquired a reputation as a niche-market language, but that niche market takes heavy advantage of Ada's strengths: strong typing and a requirement that the developer properly design the software before writing code. Unfortunately, deciding to develop commercial software in Ada also comes with a fairly steep price tag, because it's a niche market...thus perpetuating the cycle.
DISCLAIMER: I am not affiliated with any company which produces or sells Ada compilers.