And you believe the TSA version of events? He was detained, turned over to local police who escorted him from the screening area, after which, he was forced to book another flight and we eventually allowed to enter after being screened again (which is what he requested in the first place).
USDA & FDA labeling requirements state: "...consumers buying organic products, whether produced in the United States or imported, can be assured that the foods are produced without antibiotics, hormones, pesticides, irradiation or bioengineering.
If the employee does not accomplish the amount of work the manager wanted done in the shift, the employee gets bad ratings. Full stop. If the employee does, and the manager gives the employee something else to do, the employee will either get the previously-determined amount of work done AND the extra something, or the employee will get bad ratings. Have you never worked with this sort of manager?
Have you never worked for a government agency or a unionized shop?
I didn't say it was wrong, however, there are 3 flaws with the advice to write down your password:
1. It based upon the premise that many/most systems are implemented using the currently in-vogue policies of complex, hard to remember passwords, and that you should/must use different passwords for each system. Both Schneier and the MS researcher (Jesper Johansson) whose comments at a conference inspired Schneier's blog post mention those limitations as the basis for writing them down.
2. Both of those posts are very light on the topic of actually securing the written down passwords. Something which some other security experts have stressed, but which is frequently overlooked.
Unless you give complete instructions, including tips on protecting the written down password, then writing down passwords is not materially more secure than choosing easy to guess passwords. A far better recommendation is to use a password manager such as 1Password, KeePass or LastPass with a long, but easy for THAT user to remember pass-phrase.
TL;DR: Writing down passwords is a recommendation about how to cope in a world of bad password policies, and it's an incomplete recommendation because users will leave their written passwords in easily found locations. A far better recommendation is to use a password manager such as 1Password, KeePass or LastPass with a long, but easy for THAT user to remember pass-phrase. Long term, we need sane password/pass-phrase policies.
It doesn't work that way. If the employee was salaried and exempt, then it might. But you can bet the people doing the counting are hourly, and that the person didn't clock out until it was counted and in an envelope and in the out-box to go to the finance office. So, it did cost extra (and it comes out of that managers department budget), or less work was done. And it cost something for the envelope and to transport/send/mail it to finance. When it gets to the finance office, it has to be counted again, and included on a bank deposit. So, any way you look at it, it cost extra.
As a previous counter pointed out, it's an average of less than $2.50 per airport per day, which means less than $1.25/shift. It's nearly impossible for it to be a net gain, even if it only take 3-5 minutes to count it, address the envelope, and put the change in it, and send it to the finance office. And that's before counting the costs at the finance office.
Contrary to the headline, they didn't make $400k, they lost money accounting for $400k is spare change.
Given that the DNS provisions were seriously flawed, so much that they're simultaneously ineffective and would break many things on the internet, what other serious flaws are in the bill? If something that major "slipped past" all the sponsors and people promoting the bill, I have no faith that the rest of it is any better. Until the whole thing has been thoroughly reviewed for technical feasibility and constitutionality, the whole bill needs to be put on indefinite hold.
Anything that bypasses or takes shortcuts on due process is absolutely unacceptable. And, there must be severe civil penalties and recourse, and possibly criminal penalties for false allegations.
To the GP, hiding passwords as they're typed is a great paradigm. Displaying them is a security risk. See below for a better option.
To the PP, they should be hidden by default. However, outside of high-security environments, having a check box to display the password is a reasonable compromise. Not simply because people learn and memorize better with a combination of visual and kinesthetic feedback, but because lengthy and/or complex passwords are more prone to typing errors, so allowing a user to see the password when he suspects he's made a typo, or when he's having trouble logging in will reduce the number of invalid login attempts and the number of password resets required.
However, such a feature needs to be implemented carefully, so there is no chance that the next user (or next login attempt) can click to see the previous password attempt. Done properly, it's a fairly minor security risk, because it's normally hidden, and the user can determine if there are people who may be able to see the screen before displaying it. Done improperly, it's a major flaw.
Actually, the example is based upon a 2k (2^11) word vocabulary.
And those calculations are without using any capitalization, numerals, punctuation, or symbols. That means it's nearly the minimum entropy of the pass-phrase. If many (a statistically significant number greater than 1/vocabulary_size) people choose the same word, and that is known (e.g. hackers publish a list of the 1000 words most commonly used in pass-phrases), then the entropy for a statistical attack will be somewhat lower, but it would have to degenerate significantly (by 11 to 16 bits, that is, by more than one word of the pass-phrase)) to be as week as the example password. Even if all 4 words were from the 512 (2^9) most common words, it's ~36 bits of entropy. To approach the level of the example password, the pass-phrase would have to contain something like one word from the 4 most common, plus one from the 64 most common, plus two more from the top 512. That yields 28-30 bits of entropy (since you don't know the relative positions of the common words). While that's not particularly unlikely given human nature, it's still comparable to a much harder to remember (and hard to type) password.
Users can create even stronger pass-phrases by choosing at least one word from a larger vocabulary. And if you assume trivial capitalization may be used (first and/or last letter of each word), that's an extra 1.5-2 bits entropy per word, for an extra 6-8 bits entropy on a 4 word pass-phrase. If you allow (but don't require) non-trivial capitalization, mispelling(sp), numbers, punctuation, symbols, foreign words, made-up "words", and/or additional word counts, then users can create pass-phrases with much greater entropy that are still easy for that user to remember.
According to studies, pre-school aged children in the US are exposed to 620-2150 words depending upon socio-economic factors, so even pre-schoolers have sufficient vocabularies for the above.
Then you're not doing it right. I use NAT with VoIP all the time in many locations, with multiple concurrent connections. It's not a problem and it's trivial to setup.
You don't need to have NAT to have those addresses non-routable. You just need your firewall to drop all traffic to those addresses.
You're confusing "non-routeable" with "non-routed". Reserved IP addresses are non-routeable on the public internet, they will be dropped by routers outside your organization because they're not assigned to any single entity and are almost certainly duplicated somewhere else. Setting your firewall to not route to assigned public IP addresses that are internal to your network just makes them non-routed, they're still routeable. Traffic to non-routeable addresses won't even make it to the public IP of your router/firewall, but traffic to routeable public IPs will. There are subtle, but important differences between the two. For most purposes, private non-routeable addresses with NAT provides slightly greater security than having public IPs and a firewall that doesn't route incoming traffic. In theory, they're the same, but in practice, NAT with reserved IPs internally adds one additional layer of security from external attack. Granted, it's a very slight difference, but there is a difference.
I agree that the pressure of deadlines and unrealistic scheduling are part of the problem. However, functional documentation of code should be written before the code. If you aren't clear what it is you're intending to accomplish, you shouldn't be writing code yet. And if you do know what you intend to accomplish, what the input and output (e.g. API) should look like (or a rough draft of it), then that should be documented at the start of the procedure/method before you've written a single line of code. Failure to document before you code is a developer failure, not a management failure. Failure to set and enforce policies supporting such practices is a management failure.
Some things may change as you write it and find that you need more information, or that there is a better way, etc. Because of this, the documentation may need to be updated as you code, or after you finish, but that doesn't change the fact that the preliminary documentation should be written before the code. Management can implement policies that require approval of documentation before coding begins, and in extreme cases that may be necessary, but that's micromanaging and should be avoided and used only as a last resort before terminating a developer who isn't documenting his/her code (see my recommended practices below).
Where management and scheduling frequently fail is in not allowing time to update the documentation after the code is written, and not having a second developer and/or a qualified QA person read the documentation to determine if it accurately describes the purpose/intent of the procedure/method, the input/output, and the function/operation of the procedure/method. If the documentation and code don't match, then one or both must be changed so they do match.
Recommended practices: I have found the following to be the most effective way to get developers to document their code:
1. Have a written policy that functional documentation including the purpose/intent of the procedure/method, expect input & output, and a brief narrative describing the operation must be written before coding. Until someone has repeatedly violated this (as evidenced by lack of documentation in finished or partially finished code), there is no requirement to verify or approve the documentation before coding.
2. Do not require detailed documentation of every line or loop. Require documenting the basic flow/intent, and documenting any direct use of hardware, use of obscure libraries/functions, or "clever tricks"/shortcuts.
3. Have a written policy that preliminary documentation must be complete before submitting the project to QA and that all documentation must be complete and up-to-date before it can pass QA.
4a. Have someone other than the person who wrote the code perform unit testing/QA.
4b. Have someone other than the person who wrote the code review the documentation. Many developers do not communicate clearly, so clarifications may be necessary. If your QA dept doesn't have people qualified to validate the documentation, or doesn't have access to view the source code, have another developer verify the documentation is complete and matches the code before it can pass unit testing/QA. Unit testing/QA and documentation review may occur concurrently.
5. Make developers maintain some significant portions of code they wrote at least 6 months prior, and make them maintain some significant portion of code that other developers wrote. Having new developers study/maintain code written by more experienced developers is a good practice to ensure that documentation is clear and complete, and shows the value of good documentation. This step alone should make the value of good functional documentation evident to each developer. When you have trouble understanding code you (or another developer wrote) 6+ months ago, the value of good/bad/insufficient documentation will be obvious.
6. Take corrective action with developers who fail to follow your documentation policies and guidelines. This may b
How much did they pay in salaries to count it and handling to send it to the financial office, where it's undoubtedly counted again, then deposited in a bank. If they're doing that at the end of each shift, in over 100 airports, 2-3 shifts per day. It might be cheaper to just tell the TSOs to put it in their pocket.
1. The ads do not interfere with reading the content. They're at the top and off to the side. 2. Try viewing slashdot without flash installed. The ads aren't animated (you may encounter an occasional animated gif)
I gave slashdot as an example simply because it was stupid to ask for examples when we're on just such a site. There plenty of other examples, but I'm not going to spend time listing them.
The problem is that one is less likely to notice unobtrusive ads on sites with interesting content. This means that such sites can't get good ad rates unless the ads blare somewhat.
Flawed premise. Plenty of sites with good content have been operating successfully without intrusive ads.
I mean, three law firms have dropped him, FB or their lawyers planted forged evidence on his computer. Why does no one believe him? Sure, he has a history as a con-man, and he presented an original 8 yr old contract in court, but even the forensic analysts are against him and they claim the ink is less than 2 years old. Can't a guy get a break?
Anyone who looks at this case can see he's being cheated out of his half of FB.
Medfield with 2.6W idle, and 3.6W playing 720p video? Numbres they they "hope" to get down to 2W and 2.6W early this year. If they haven't had a breakthrough in their power consumption, expect those phones and tablets to fail in the market as quickly as the Kin & TouchPad, or, if they're persistent, maybe they'll be out as long as the Original Xoom or PlayBook.
Putting more ads on the page won't make me read or click more ads. Putting them inline with the content won't do that either. What will make me read or click more ads is showing me ads relevant to me, AND doing so in a non-intrusive manner. The sooner you understand and implement this concept, the more money you stand to make from me clicking on ads.
I have no objection to non-intrusive ads. I will NEVER click on Flash (or other video ads the play automatically) ads. Not once, not ever. If you use an animated ad that "flashes" or "flickers", I will never click on it, and if I happen to notice who that ad is from, I will never purchase a product from that company.
If a site has content I want, and the ads are non-intrusive, I don't object to them. My karma on slashdot is good enough that I have the option to turn off ads, but I haven't because it meets these criteria.
There are some good ones, but even with 200 cable channels, finding 4 hours worth of programming worth watching daily is difficult. 24hrs * 200 channels, and still a challenge. It's a much more vast wasteland than it was in 1959 when that was first stated.
It's the lousy content. TV still a "vast wasteland", and no amount of technology or gimmicks will make up for that. First get quality programming in 2D, then we can look at technologies like 3D. Technological solutions to non-technical problems don't actually solve the problem.
Slashdot Mirror
Not even close. Do some research before posting BS.
And you believe the TSA version of events? He was detained, turned over to local police who escorted him from the screening area, after which, he was forced to book another flight and we eventually allowed to enter after being screened again (which is what he requested in the first place).
USDA & FDA labeling requirements state: "...consumers buying organic products, whether produced in the United States or imported, can be assured that the foods are produced without antibiotics, hormones, pesticides, irradiation or bioengineering.
So, yes, you can bet on "organic" being non-GMO.
There is no GMO popcorn.
If the employee does not accomplish the amount of work the manager wanted done in the shift, the employee gets bad ratings. Full stop. If the employee does, and the manager gives the employee something else to do, the employee will either get the previously-determined amount of work done AND the extra something, or the employee will get bad ratings. Have you never worked with this sort of manager?
Have you never worked for a government agency or a unionized shop?
I didn't say it was wrong, however, there are 3 flaws with the advice to write down your password:
1. It based upon the premise that many/most systems are implemented using the currently in-vogue policies of complex, hard to remember passwords, and that you should/must use different passwords for each system. Both Schneier and the MS researcher (Jesper Johansson) whose comments at a conference inspired Schneier's blog post mention those limitations as the basis for writing them down.
2. Both of those posts are very light on the topic of actually securing the written down passwords. Something which some other security experts have stressed, but which is frequently overlooked.
3. People who do write down their passwords are not good at securing them.
Unless you give complete instructions, including tips on protecting the written down password, then writing down passwords is not materially more secure than choosing easy to guess passwords. A far better recommendation is to use a password manager such as 1Password, KeePass or LastPass with a long, but easy for THAT user to remember pass-phrase.
TL;DR: Writing down passwords is a recommendation about how to cope in a world of bad password policies, and it's an incomplete recommendation because users will leave their written passwords in easily found locations. A far better recommendation is to use a password manager such as 1Password, KeePass or LastPass with a long, but easy for THAT user to remember pass-phrase. Long term, we need sane password/pass-phrase policies.
It doesn't work that way. If the employee was salaried and exempt, then it might. But you can bet the people doing the counting are hourly, and that the person didn't clock out until it was counted and in an envelope and in the out-box to go to the finance office. So, it did cost extra (and it comes out of that managers department budget), or less work was done. And it cost something for the envelope and to transport/send/mail it to finance. When it gets to the finance office, it has to be counted again, and included on a bank deposit. So, any way you look at it, it cost extra.
As a previous counter pointed out, it's an average of less than $2.50 per airport per day, which means less than $1.25/shift. It's nearly impossible for it to be a net gain, even if it only take 3-5 minutes to count it, address the envelope, and put the change in it, and send it to the finance office. And that's before counting the costs at the finance office.
Contrary to the headline, they didn't make $400k, they lost money accounting for $400k is spare change.
Given that the DNS provisions were seriously flawed, so much that they're simultaneously ineffective and would break many things on the internet, what other serious flaws are in the bill? If something that major "slipped past" all the sponsors and people promoting the bill, I have no faith that the rest of it is any better. Until the whole thing has been thoroughly reviewed for technical feasibility and constitutionality, the whole bill needs to be put on indefinite hold.
Anything that bypasses or takes shortcuts on due process is absolutely unacceptable. And, there must be severe civil penalties and recourse, and possibly criminal penalties for false allegations.
To the GP, hiding passwords as they're typed is a great paradigm. Displaying them is a security risk. See below for a better option.
To the PP, they should be hidden by default. However, outside of high-security environments, having a check box to display the password is a reasonable compromise. Not simply because people learn and memorize better with a combination of visual and kinesthetic feedback, but because lengthy and/or complex passwords are more prone to typing errors, so allowing a user to see the password when he suspects he's made a typo, or when he's having trouble logging in will reduce the number of invalid login attempts and the number of password resets required.
However, such a feature needs to be implemented carefully, so there is no chance that the next user (or next login attempt) can click to see the previous password attempt. Done properly, it's a fairly minor security risk, because it's normally hidden, and the user can determine if there are people who may be able to see the screen before displaying it. Done improperly, it's a major flaw.
Actually, the example is based upon a 2k (2^11) word vocabulary.
And those calculations are without using any capitalization, numerals, punctuation, or symbols. That means it's nearly the minimum entropy of the pass-phrase. If many (a statistically significant number greater than 1/vocabulary_size) people choose the same word, and that is known (e.g. hackers publish a list of the 1000 words most commonly used in pass-phrases), then the entropy for a statistical attack will be somewhat lower, but it would have to degenerate significantly (by 11 to 16 bits, that is, by more than one word of the pass-phrase)) to be as week as the example password. Even if all 4 words were from the 512 (2^9) most common words, it's ~36 bits of entropy. To approach the level of the example password, the pass-phrase would have to contain something like one word from the 4 most common, plus one from the 64 most common, plus two more from the top 512. That yields 28-30 bits of entropy (since you don't know the relative positions of the common words). While that's not particularly unlikely given human nature, it's still comparable to a much harder to remember (and hard to type) password.
Users can create even stronger pass-phrases by choosing at least one word from a larger vocabulary. And if you assume trivial capitalization may be used (first and/or last letter of each word), that's an extra 1.5-2 bits entropy per word, for an extra 6-8 bits entropy on a 4 word pass-phrase. If you allow (but don't require) non-trivial capitalization, mispelling(sp), numbers, punctuation, symbols, foreign words, made-up "words", and/or additional word counts, then users can create pass-phrases with much greater entropy that are still easy for that user to remember.
According to studies, pre-school aged children in the US are exposed to 620-2150 words depending upon socio-economic factors, so even pre-schoolers have sufficient vocabularies for the above.
"please generate a good password for me and I'll write it down because I won't be able to remember it."
FTFY
It wreaks havoc on VOIP for instance.
Then you're not doing it right. I use NAT with VoIP all the time in many locations, with multiple concurrent connections. It's not a problem and it's trivial to setup.
You don't need to have NAT to have those addresses non-routable. You just need your firewall to drop all traffic to those addresses.
You're confusing "non-routeable" with "non-routed". Reserved IP addresses are non-routeable on the public internet, they will be dropped by routers outside your organization because they're not assigned to any single entity and are almost certainly duplicated somewhere else. Setting your firewall to not route to assigned public IP addresses that are internal to your network just makes them non-routed, they're still routeable. Traffic to non-routeable addresses won't even make it to the public IP of your router/firewall, but traffic to routeable public IPs will. There are subtle, but important differences between the two. For most purposes, private non-routeable addresses with NAT provides slightly greater security than having public IPs and a firewall that doesn't route incoming traffic. In theory, they're the same, but in practice, NAT with reserved IPs internally adds one additional layer of security from external attack. Granted, it's a very slight difference, but there is a difference.
I agree that the pressure of deadlines and unrealistic scheduling are part of the problem. However, functional documentation of code should be written before the code. If you aren't clear what it is you're intending to accomplish, you shouldn't be writing code yet. And if you do know what you intend to accomplish, what the input and output (e.g. API) should look like (or a rough draft of it), then that should be documented at the start of the procedure/method before you've written a single line of code. Failure to document before you code is a developer failure, not a management failure. Failure to set and enforce policies supporting such practices is a management failure.
Some things may change as you write it and find that you need more information, or that there is a better way, etc. Because of this, the documentation may need to be updated as you code, or after you finish, but that doesn't change the fact that the preliminary documentation should be written before the code. Management can implement policies that require approval of documentation before coding begins, and in extreme cases that may be necessary, but that's micromanaging and should be avoided and used only as a last resort before terminating a developer who isn't documenting his/her code (see my recommended practices below).
Where management and scheduling frequently fail is in not allowing time to update the documentation after the code is written, and not having a second developer and/or a qualified QA person read the documentation to determine if it accurately describes the purpose/intent of the procedure/method, the input/output, and the function/operation of the procedure/method. If the documentation and code don't match, then one or both must be changed so they do match.
Recommended practices: I have found the following to be the most effective way to get developers to document their code:
1. Have a written policy that functional documentation including the purpose/intent of the procedure/method, expect input & output, and a brief narrative describing the operation must be written before coding. Until someone has repeatedly violated this (as evidenced by lack of documentation in finished or partially finished code), there is no requirement to verify or approve the documentation before coding.
2. Do not require detailed documentation of every line or loop. Require documenting the basic flow/intent, and documenting any direct use of hardware, use of obscure libraries/functions, or "clever tricks"/shortcuts.
3. Have a written policy that preliminary documentation must be complete before submitting the project to QA and that all documentation must be complete and up-to-date before it can pass QA.
4a. Have someone other than the person who wrote the code perform unit testing/QA.
4b. Have someone other than the person who wrote the code review the documentation. Many developers do not communicate clearly, so clarifications may be necessary. If your QA dept doesn't have people qualified to validate the documentation, or doesn't have access to view the source code, have another developer verify the documentation is complete and matches the code before it can pass unit testing/QA. Unit testing/QA and documentation review may occur concurrently.
5. Make developers maintain some significant portions of code they wrote at least 6 months prior, and make them maintain some significant portion of code that other developers wrote. Having new developers study/maintain code written by more experienced developers is a good practice to ensure that documentation is clear and complete, and shows the value of good documentation. This step alone should make the value of good functional documentation evident to each developer. When you have trouble understanding code you (or another developer wrote) 6+ months ago, the value of good/bad/insufficient documentation will be obvious.
6. Take corrective action with developers who fail to follow your documentation policies and guidelines. This may b
How much did they pay in salaries to count it and handling to send it to the financial office, where it's undoubtedly counted again, then deposited in a bank. If they're doing that at the end of each shift, in over 100 airports, 2-3 shifts per day. It might be cheaper to just tell the TSOs to put it in their pocket.
Because no tech wants to touch it after you've sneezed on it.
1. The ads do not interfere with reading the content. They're at the top and off to the side.
2. Try viewing slashdot without flash installed. The ads aren't animated (you may encounter an occasional animated gif)
I gave slashdot as an example simply because it was stupid to ask for examples when we're on just such a site. There plenty of other examples, but I'm not going to spend time listing them.
Slashdot.org
The problem is that one is less likely to notice unobtrusive ads on sites with interesting content. This means that such sites can't get good ad rates unless the ads blare somewhat.
Flawed premise. Plenty of sites with good content have been operating successfully without intrusive ads.
I mean, three law firms have dropped him, FB or their lawyers planted forged evidence on his computer. Why does no one believe him? Sure, he has a history as a con-man, and he presented an original 8 yr old contract in court, but even the forensic analysts are against him and they claim the ink is less than 2 years old. Can't a guy get a break?
Anyone who looks at this case can see he's being cheated out of his half of FB.
PS. In case you missed it, yes, that's sarcasm.
Medfield with 2.6W idle, and 3.6W playing 720p video? Numbres they they "hope" to get down to 2W and 2.6W early this year. If they haven't had a breakthrough in their power consumption, expect those phones and tablets to fail in the market as quickly as the Kin & TouchPad, or, if they're persistent, maybe they'll be out as long as the Original Xoom or PlayBook.
Putting more ads on the page won't make me read or click more ads. Putting them inline with the content won't do that either. What will make me read or click more ads is showing me ads relevant to me, AND doing so in a non-intrusive manner. The sooner you understand and implement this concept, the more money you stand to make from me clicking on ads.
I have no objection to non-intrusive ads. I will NEVER click on Flash (or other video ads the play automatically) ads. Not once, not ever. If you use an animated ad that "flashes" or "flickers", I will never click on it, and if I happen to notice who that ad is from, I will never purchase a product from that company.
If a site has content I want, and the ads are non-intrusive, I don't object to them. My karma on slashdot is good enough that I have the option to turn off ads, but I haven't because it meets these criteria.
It's better than most of the country, and the world.
In Texas, the legislature only meets ever other year. The less often the legislature is in session, the better is it for the people.
There are some good ones, but even with 200 cable channels, finding 4 hours worth of programming worth watching daily is difficult. 24hrs * 200 channels, and still a challenge. It's a much more vast wasteland than it was in 1959 when that was first stated.
It's the lousy content. TV still a "vast wasteland", and no amount of technology or gimmicks will make up for that. First get quality programming in 2D, then we can look at technologies like 3D. Technological solutions to non-technical problems don't actually solve the problem.