Construct a sturdy firewall your work time and personal time.
People are different, but I never found that to be necessary or useful. In fact I found it to be limiting. What was useful was to find ways to make clear when I was and was not at work to help my family know what to expect, but "firewalls" aren't necessary for me and I really liked having the flexibility to works varied hours depending on what was going on at home.
In my current job I'm generally in the office during regular-ish hours. "ish" because I tend to arrive early and leave early.
I did this quite successfully for years, with a wife who was/is a stay-at-home mom and young kids (then -- the youngest is now 10). What worked for me was just being a grouch until the kids learned to leave me alone during working hours. My wife never did really figure out that she couldn't ask me to do things, but I learned to just say "no" when I was doing something that didn't allow interruption.
Water doesn't need to be saved unless you're breaking apart the atoms.
Clean water, however, is a scarce resource in many places in the world.
And it's an abundant resource wherever grey water systems are put into place.
TFA disagrees. Note the point about potential problems for the data center in the event of drought and subsequent restrictions on data center water usage.
I'd like to use JuiceDefender, but I also use Tasker to reconfigure various settings, often based on proximity to specific Wifi access points (which provides cheap and fairly accurate geo-location), and JD turning the Wifi off and on all the time confuses Tasker.
But it will dent the low risk, low return start ups.
Low-risk borrowers have lots of other options. Like banks, for example. High-risk, low-return operations, well, they're just not going to get funded regardless. Angel investment is all about high-risk, high-return.
Since this keeps getting repeated, I will comment: the flight attendant should be instructing you to stow a large book, binder, and even your iPod sitting in the center console. They might not always do it, but that doesn't mean they aren't supposed to.
I've flown more than a million miles over the last 20 years, averaging about 40 flights per year, and including flights to dozens of countries and every continent except Antarctica. I nearly always read during takeoff and landing (and most of the flight) and I have never been asked to put anything non-electronic away.
Usually "gray" water is water from showers, sinks, etc. -- everything but toilets. Water from toilets, including human wastes, is called "black" water. Some systems keep these separate, although most municipal systems (including, it appears, Douglas County, Georgia) mix them together. So this water starts out as "black", but according to TFA, it's partially cleaned up before being sent to the data center. Apparently it's treated enough to be called "gray", but still isn't potable. Then Google finishes the water treatment and releases the result into the river which is where it would have gone after the county treatment center anyway.
In the US effectively all transactions are already on-line, so the off-line use cases don't really exist. Other approaches have been found. Given the capability, it's possible that off-line might be used... but at the same time the proliferation of Internet access is making it often just as easy to do it on-line. Even on a train.
And your ten engineers still don't do 10x the work of one engineer, because of all the time they spend working with the PM to plan and coordinate the work.
10 engineers can be 10 times as productive working for a year as 1 engineer.
No they can't.
You do gain productivity by adding more people to the project from the beginning, certainly, but the output does not scale linearly. In my experience, 2-3 good engineers may well be a little more than 2-3 times as productive as one good engineer -- at the low end more perspectives leads to better solutions which are easier to implement. But once you get much larger than that, the overhead of communicating and keeping everyone in sync becomes significant.
When you get up to about five people, at least one of them has to devote a non-trivial percentage of their time to coordinating the work of the others, and doing that sucks time away from the others as well. At 10, you're going to have a hard time if one of them isn't almost fully dedicated to project management, or unless you break into subteams and spread the PM load.
All in all, given good people, I'd say that 10 engineers are about 8x as productive as one engineer.
Each transaction is "Unique" and the card itself will sometimes request to speak directly to a Host (i.e. somewhere at your Bank's HQ), in what's called an "online" transaction. If the card chip isn't sure of a terminal, it will demand to go online before processing a transaction. Hell, sometimes it'll demand to go online just because it hasn't recently. The two then communicate in such a way that the terminal (the middle man) can't intercept in any meaningful fashion. Each message is cryptographically generated so that the host knows the card sent it and not some MITM.
I think it's likely that all transactions will be on-line for the US implementation. MasterCard PayPass, Visa PayWave and Discover Zip all go on-line all the time, I believe. These are all EMV-derived protocols, but I don't think any of them are perfectly-compliant with any of the EMV usage modes. Also, I think they're all SDA plus a per-transaction dynamic CVV.
Is there a way we could also store our encryption keys in the SE?
Potentially. The SE provides a full suite of cryptographic capabilities and can securely store and use keys. It can even generate keys, so you can have keys which are never, ever exposed outside of the SE, but use them as needed. It can further even implement access control logic to limit the ability of an attacker who gains control of the phone to use those keys. In short, it can be a micro-HSM for your phone. Which I think is very, very cool.
I'd like to see Google make SE-based security APIs generally available to all Android apps who care to use them. Unfortunately, I can't say anything about what Google may or may not be doing in this direction.
or they could just change his google password to something they can give to the FBI...
Assuming the phone does an on-line verification, rather than comparing the entered password to a locally-stored value. Based on some other comments here, and on the fact that I see potential usability and security problems with doing an on-line verification for screen unlock, I suspect it does an off-line check.
Technicians apparently mis-entered the pattern enough times to lock the phone, which could only be unlocked using the phone owner's Google account credentials.
Which Google also almost certainly doesn't have.
Why would they not have this?
Because I'm sure the phone owner's Google account credentials are stored as a salted one-way hash. But the phone will demand the cleartext be entered, because it's going to do its own hashing, using the salt stored in the phone's DB. So I doubt Google can provide any information which the phone would accept for unlock. This assumes the phone is checking the credentials against internal data, rather than going on-line to verify against Google's authentication database. I'm basing that assumption on the comments of other posters to this story, and on the fact that I can see numerous potential difficulties with doing that securely.
If, in fact, the phone does query Google's on-line authentication services to do the unlock, then Google could reset the account password and give the FBI the new one. But I don't think that's how it works.
Must they expose their lives and their families to possible retribution from those who disagree, or is it your contention that if they don't hew to some imaginary set of safe subject matter you approve of, that they don't deserve to participate in a social network?
Alternatively, they can just post their stuff only to circles of people they trust, and only read posts/comments from circles of people they trust. Google+ allows you to constrain your social networking as much or as little as you desire. I understand Facebook now allows the same, though I haven't used it for quite a while, so I can't say for sure.
Which has always been a problem, and which is why we should be getting things right with smart phones.
Google Wallet stores the credit card number and other sensitive information in the "secure element", a special-purpose high-security chip that is separate from the main system, with its own CPU, it's own OS and it's own storage. The secure element (SE) is actually a smart card chip, which has the benefit of almost 30 years of evolution, as attacks were created and countermeasures added. Nothing is 100% secure, but smart cards are pretty darned good.
Among other things, they wrap the storage in cladding layers which are physically bonded and chemically similar, so peeling or dissolving the cladding to be able to get to the EEPROM is extremely difficult, and highly likely to destroy the EEPROM. They're also careful to expose no leads which can be used to directly manipulate the memory, etc.
There have been some minor weaknesses found in Google Wallet, which Google has fixed or is fixing, but nothing that would expose the credit card number, because it's locked securely in the SE. We are getting things right with smart phones; at least Google is. I imagine ISIS is also.
(Disclaimer: I work for Google, and have even done some work around Google Wallet, though that's not my primary job. However, everything I stated above is public knowledge, filtered through 10+ years of experience working with smart cards and SEs while at IBM.)
Technicians apparently mis-entered the pattern enough times to lock the phone, which could only be unlocked using the phone owner's Google account credentials.
Which Google also almost certainly doesn't have.
What Google might be able to tell them is how to root the phone, or how to take the phone apart and read the contents of the flash directly. AFAIK, you have to use a password/passphrase, not a pattern, if you want to use whole-device encryption, so the flash should be unencrypted.
To use google (ldap) directory sync with google apps, you need to use unsalted SHA1, or cleartext passwords in the directory you wish to sync.
That doesn't mean Google stores unsalted hashes or cleartext, it just means that whatever Google stores is computable from those.
(Disclaimer: I work for Google, on security stuff, but I don't know anything about how user passwords are stored. I will say that storing unsalted hashes or cleartext would be very out of character for Google. Google tends towards great caution when it comes to security, and employs a lot of serious security experts and cryptographers.)
That depends on caliber and how long after the shot the photo is taken.
Even a lightweight.22 rifle has enough recoil to take your scope off the target. A long-barreled.223 that's well-buffered (think AR-15/M-16) doesn't jump too much, but any more powerful caliber, or any shorter barrel will jump regardless. Yeah, the camera could wait long enough for the shooter to get back on target. Maybe the best way would be to have a separate shutter release button so the shooter could take photos at any point.
Just buy a good DSLR and spend the bulk of your money on a fast long lens. A 300mm f2.8 telephoto lens will cost you a lot, but it's worth it for wildlife photography. Either that or just go to the zoo.
+1
I "hunt" with a camera from time to time, and I see no value in having a rifle-shaped camera. It's not going to be easier to carry, easier to take photos with, and certainly not going to capture images as well as a good DSLR with a good lens -- and I don't even have a 300mm f2.8, though I do have a 70-200 f2.8 with a 2x extender (140-400 f5.6).
Slashdot Mirror
Construct a sturdy firewall your work time and personal time.
People are different, but I never found that to be necessary or useful. In fact I found it to be limiting. What was useful was to find ways to make clear when I was and was not at work to help my family know what to expect, but "firewalls" aren't necessary for me and I really liked having the flexibility to works varied hours depending on what was going on at home.
In my current job I'm generally in the office during regular-ish hours. "ish" because I tend to arrive early and leave early.
I did this quite successfully for years, with a wife who was/is a stay-at-home mom and young kids (then -- the youngest is now 10). What worked for me was just being a grouch until the kids learned to leave me alone during working hours. My wife never did really figure out that she couldn't ask me to do things, but I learned to just say "no" when I was doing something that didn't allow interruption.
Tasker can also use cell location, but it's not accurate enough for my purposes.
Water doesn't need to be saved unless you're breaking apart the atoms.
Clean water, however, is a scarce resource in many places in the world.
And it's an abundant resource wherever grey water systems are put into place.
TFA disagrees. Note the point about potential problems for the data center in the event of drought and subsequent restrictions on data center water usage.
I'd like to use JuiceDefender, but I also use Tasker to reconfigure various settings, often based on proximity to specific Wifi access points (which provides cheap and fairly accurate geo-location), and JD turning the Wifi off and on all the time confuses Tasker.
Water doesn't need to be saved unless you're breaking apart the atoms.
Clean water, however, is a scarce resource in many places in the world.
Thanks.
But it will dent the low risk, low return start ups.
Low-risk borrowers have lots of other options. Like banks, for example. High-risk, low-return operations, well, they're just not going to get funded regardless. Angel investment is all about high-risk, high-return.
What is toll quality?
Since this keeps getting repeated, I will comment: the flight attendant should be instructing you to stow a large book, binder, and even your iPod sitting in the center console. They might not always do it, but that doesn't mean they aren't supposed to.
I've flown more than a million miles over the last 20 years, averaging about 40 flights per year, and including flights to dozens of countries and every continent except Antarctica. I nearly always read during takeoff and landing (and most of the flight) and I have never been asked to put anything non-electronic away.
Usually "gray" water is water from showers, sinks, etc. -- everything but toilets. Water from toilets, including human wastes, is called "black" water. Some systems keep these separate, although most municipal systems (including, it appears, Douglas County, Georgia) mix them together. So this water starts out as "black", but according to TFA, it's partially cleaned up before being sent to the data center. Apparently it's treated enough to be called "gray", but still isn't potable. Then Google finishes the water treatment and releases the result into the river which is where it would have gone after the county treatment center anyway.
In the US effectively all transactions are already on-line, so the off-line use cases don't really exist. Other approaches have been found. Given the capability, it's possible that off-line might be used... but at the same time the proliferation of Internet access is making it often just as easy to do it on-line. Even on a train.
And your ten engineers still don't do 10x the work of one engineer, because of all the time they spend working with the PM to plan and coordinate the work.
10 engineers can be 10 times as productive working for a year as 1 engineer.
No they can't.
You do gain productivity by adding more people to the project from the beginning, certainly, but the output does not scale linearly. In my experience, 2-3 good engineers may well be a little more than 2-3 times as productive as one good engineer -- at the low end more perspectives leads to better solutions which are easier to implement. But once you get much larger than that, the overhead of communicating and keeping everyone in sync becomes significant.
When you get up to about five people, at least one of them has to devote a non-trivial percentage of their time to coordinating the work of the others, and doing that sucks time away from the others as well. At 10, you're going to have a hard time if one of them isn't almost fully dedicated to project management, or unless you break into subteams and spread the PM load.
All in all, given good people, I'd say that 10 engineers are about 8x as productive as one engineer.
Each transaction is "Unique" and the card itself will sometimes request to speak directly to a Host (i.e. somewhere at your Bank's HQ), in what's called an "online" transaction. If the card chip isn't sure of a terminal, it will demand to go online before processing a transaction. Hell, sometimes it'll demand to go online just because it hasn't recently. The two then communicate in such a way that the terminal (the middle man) can't intercept in any meaningful fashion. Each message is cryptographically generated so that the host knows the card sent it and not some MITM.
I think it's likely that all transactions will be on-line for the US implementation. MasterCard PayPass, Visa PayWave and Discover Zip all go on-line all the time, I believe. These are all EMV-derived protocols, but I don't think any of them are perfectly-compliant with any of the EMV usage modes. Also, I think they're all SDA plus a per-transaction dynamic CVV.
Is there a way we could also store our encryption keys in the SE?
Potentially. The SE provides a full suite of cryptographic capabilities and can securely store and use keys. It can even generate keys, so you can have keys which are never, ever exposed outside of the SE, but use them as needed. It can further even implement access control logic to limit the ability of an attacker who gains control of the phone to use those keys. In short, it can be a micro-HSM for your phone. Which I think is very, very cool.
I'd like to see Google make SE-based security APIs generally available to all Android apps who care to use them. Unfortunately, I can't say anything about what Google may or may not be doing in this direction.
or they could just change his google password to something they can give to the FBI...
Assuming the phone does an on-line verification, rather than comparing the entered password to a locally-stored value. Based on some other comments here, and on the fact that I see potential usability and security problems with doing an on-line verification for screen unlock, I suspect it does an off-line check.
Technicians apparently mis-entered the pattern enough times to lock the phone, which could only be unlocked using the phone owner's Google account credentials.
Which Google also almost certainly doesn't have.
Why would they not have this?
Because I'm sure the phone owner's Google account credentials are stored as a salted one-way hash. But the phone will demand the cleartext be entered, because it's going to do its own hashing, using the salt stored in the phone's DB. So I doubt Google can provide any information which the phone would accept for unlock. This assumes the phone is checking the credentials against internal data, rather than going on-line to verify against Google's authentication database. I'm basing that assumption on the comments of other posters to this story, and on the fact that I can see numerous potential difficulties with doing that securely.
If, in fact, the phone does query Google's on-line authentication services to do the unlock, then Google could reset the account password and give the FBI the new one. But I don't think that's how it works.
Must they expose their lives and their families to possible retribution from those who disagree, or is it your contention that if they don't hew to some imaginary set of safe subject matter you approve of, that they don't deserve to participate in a social network?
Alternatively, they can just post their stuff only to circles of people they trust, and only read posts/comments from circles of people they trust. Google+ allows you to constrain your social networking as much or as little as you desire. I understand Facebook now allows the same, though I haven't used it for quite a while, so I can't say for sure.
Which has always been a problem, and which is why we should be getting things right with smart phones.
Google Wallet stores the credit card number and other sensitive information in the "secure element", a special-purpose high-security chip that is separate from the main system, with its own CPU, it's own OS and it's own storage. The secure element (SE) is actually a smart card chip, which has the benefit of almost 30 years of evolution, as attacks were created and countermeasures added. Nothing is 100% secure, but smart cards are pretty darned good.
Among other things, they wrap the storage in cladding layers which are physically bonded and chemically similar, so peeling or dissolving the cladding to be able to get to the EEPROM is extremely difficult, and highly likely to destroy the EEPROM. They're also careful to expose no leads which can be used to directly manipulate the memory, etc.
There have been some minor weaknesses found in Google Wallet, which Google has fixed or is fixing, but nothing that would expose the credit card number, because it's locked securely in the SE. We are getting things right with smart phones; at least Google is. I imagine ISIS is also.
(Disclaimer: I work for Google, and have even done some work around Google Wallet, though that's not my primary job. However, everything I stated above is public knowledge, filtered through 10+ years of experience working with smart cards and SEs while at IBM.)
That's exactly what happened:
Which Google also almost certainly doesn't have.
What Google might be able to tell them is how to root the phone, or how to take the phone apart and read the contents of the flash directly. AFAIK, you have to use a password/passphrase, not a pattern, if you want to use whole-device encryption, so the flash should be unencrypted.
To use google (ldap) directory sync with google apps, you need to use unsalted SHA1, or cleartext passwords in the directory you wish to sync.
That doesn't mean Google stores unsalted hashes or cleartext, it just means that whatever Google stores is computable from those.
(Disclaimer: I work for Google, on security stuff, but I don't know anything about how user passwords are stored. I will say that storing unsalted hashes or cleartext would be very out of character for Google. Google tends towards great caution when it comes to security, and employs a lot of serious security experts and cryptographers.)
That depends on caliber and how long after the shot the photo is taken.
Even a lightweight .22 rifle has enough recoil to take your scope off the target. A long-barreled .223 that's well-buffered (think AR-15/M-16) doesn't jump too much, but any more powerful caliber, or any shorter barrel will jump regardless. Yeah, the camera could wait long enough for the shooter to get back on target. Maybe the best way would be to have a separate shutter release button so the shooter could take photos at any point.
Just buy a good DSLR and spend the bulk of your money on a fast long lens. A 300mm f2.8 telephoto lens will cost you a lot, but it's worth it for wildlife photography. Either that or just go to the zoo.
+1
I "hunt" with a camera from time to time, and I see no value in having a rifle-shaped camera. It's not going to be easier to carry, easier to take photos with, and certainly not going to capture images as well as a good DSLR with a good lens -- and I don't even have a 300mm f2.8, though I do have a 70-200 f2.8 with a 2x extender (140-400 f5.6).
Nah, I would prefer to see the impact of the round rather than the before shot.
You'd see the sky/trees. Recoil.