Sometimes reporting, or history, distorts the focus or some aspect of an event. For instance most of us were led to believe that Sputnik was an effort of a cold-war space-race instead of being part of an international geophysical year. (analysis of how the U.S. and others perceived it and what response followed is another matter)
Hehe, bad choice of examples. Yes, Sputnik was launched during an IGY year of "cooperation"... but that doesn't mean it wasn't a cold war space race from the beginning. The USSR announced their intention to launch an artificial satellite nine days after the US announced the same intention. Then the USSR went forward with designing the satellite, only to discover that their original planned machine was going to take too long. Afraid that the US might beat them to it, they stepped back and focused on a simpler design so they could get it into space faster, and beat the US. As soon as their launch vehicle was good to go, they launched, pushing back some planned military test launches to do it.
The last Uber driver I had, was also a comedian/writer (Los Angeles). He didn't need a living wage, he wanted a part time job with a ton of flexibility to supplement income.
Makes perfect sense to me. There are lots of people whose lifestyles don't permit a regular job, but could use a flexible income supplement.
The next time someone says "that doesn't make a living wage" the correct response is to punch them in the mouth.
That's a rather violent, not to mention criminal, response. I think not.
First, my comment was not a "defense" of anything.
Second, you seem to have missed the sentence "It's not quite as good if the smartphone is also providing the fingerprint scanner and camera, because in the event of an attempted fraudulent transaction that means the attacker is in control of those components."
Also, you seem to have missed the last paragraph. In fairness, I suppose I wasn't quite clear enough. When I said that the security is in the same ballpark as a four-digit PIN, I was comparing to a system using phone-mounted sensors. With sensors provided by the retailer, in a staffed checkout lane, it's unambiguously stronger.
You seem to acknowledge that the good guy with a gun, most likely, cannot kill or fully disable the shooter in this situation.
zerofoo said nothing of the sort. He said that killing or fully disabling the shooter isn't necessary, not that it's not possible, or even unlikely.
The history of mass shooting violence in the US bears out both zerofoo's point that killing or disabling the shooter often isn't necessary, since mass shooters tend to suicide as soon as they meet armed resistance, and even those who don't are clearly going to have to shift their focus from mass murder to self-defense or be an easy target. There are plenty of cases in which shooters have been killed, disabled or otherwise stopped by citizens, though they tend to get less press for the simple reason that fewer people die.
So now you have to calculate, how many people could potentially be saved in that scenario, versus how many people would be killed if handguns are more widespread. If 5% of the populace is armed now, what happens to the death by gun rates when its 10%, 20%, 75%, 100%?
Interestingly, the US has conducted this experiment over the last 40 years or so, as the number of concealed carry permit holders went from basically zero to up to 15% in some areas of the country. What happened? Not much. Violence declined, and there is some weak statistical evidence that it declined faster in areas where more people began carrying guns on a daily basis. There is no evidence that violence increased.
Will the number of random shootings go down by allowing anyone, including the mentally ill, to have easier access to guns without waiting periods?
I suspect it won't change at all. What would reduce the number of shootings is removing all of the guns, but that is impossible.
P.S. Several school shootings (like Columbine) have taken place at schools with an armed police presence.
This is something of an unrelated point, but I think it's worth noting that police did not respond quickly at Columbine High School, and that the experience dramatically changed police doctrine for responding to active shooters, across the nation. After-action analyses showed that as soon as the shooters faced aggressive armed response, they killed themselves, but that happened many minutes, and several deaths, later than it could have. At the time standard procedure was to cordon the area, isolate the shooters and wait for enough backup to arrive -- preferably SWAT -- that the police could enter in overwhelming force. But Columbine changed that, and most police departments now train their officers that if they have good reason to believe it's a lone shooter then the very first officers on the scene should enter immediately.
Immediate entry, without overwhelming force or special weapons, seems like it significantly increases the risk to the officers, but in practice it doesn't, much. And, of course, waiting tends to give shooters time and space to rack up massive body counts.
It takes a couple weeks to get used to standing. Stick with it.
Or just change positions several times per day. I stand until I'm tired of it then sit for 30 minutes, repeat. I set a timer for the sitting periods, otherwise I find that when I'm focused on something I forget to stand up again. I've thought about hacking and arduino into the controls on my desk and automating that, so that after 30 minutes my desk automatically returns to the standing position, but haven't gotten around to it.
I have a motorized desk from VersaTables. Nice desk and the company was great to work with. Not cheap, though, not at all.
You have to be able to float that much money to wait for the rebate, correct?
Not if you lease. If you lease, it's the lessor that gets the rebate, so when they calculate the financing they just take it off the top. The federal credit, anyway. This is one of several reasons why more EVs are leased than purchased.
He also says he had to install a 240V socket it in his garage because apparently though you can charge it on 120V in a pinch, apparently it can cause damage to the batteries. That's according to Nissan.
This is incorrect. Charging on 120V doesn't do any damage to the batteries, in fact it's probably a little bit better for them. The problem with level 1 charging is that it's slow. Assuming the LEAF's battery is empty it takes about 21 hours to charge it to full on the 120V adapter included with the car.
I actually charged my car regularly on 120V and it wasn't as bad as you might think -- as long as I only needed to make one trip into town per day (from my house to the city is about a 40-mile round trip). The car was almost always fully-charged by morning, but if I went somewhere in the morning and came back home, there was no possibility of making a second trip in the afternoon or evening. Not without stopping off at the level 3 charger in town, anyway. Which I did from time to time -- it's free, and recharges the car from empty in about an hour, but it means having to kill an hour, and there isn't much of interest within walking distance of the charger.
So, I installed a 220V "level 2" charger. With it, the car recharges from empty in a little under four hours. In practice, that means that when I pull into the garage and plug in, it's generally full again in a couple of hours. Most of the time the flexibility that provides doesn't matter, but sometimes it's very handy. The level 2 charger cost me about $400. Was it worth it? Maybe, maybe not.
Both of you are wrong and so is Dustin Kirkland (whoever he is). The core of your error is in this statement:
Only secrets can be used as token for authentication.
That sentence is true, as stated, but only because it includes the word "token". Yes if you're using secret tokens for authentication, then the tokens must be secret. But exchanging secrets (or proof of possession of secrets, which is what most cryptographic authentication protocols do) is not the only way to do authentication. Not by a long shot. In fact, humans hardly ever use secrets for authentication.
How do you identify and authenticate your mom? Do you ask her for a secret password? Of course not. You use the same tools for both identifying and authenticating her, and those tools are a set of biometric markers. The same set of tools are also used in high security situations. Back when I was a security guard in the Air Force, I was trained that personal recognition is the very best form of authentication. Not only is it not necessary to check the badge of an individual you know personally, badge-checking is inferior to personal recognition for authentication (note that badge-checking may still be important for authorization, verifying that the person who has been identified and authenticated actually has permission to enter. Thus I was trained to always check the access control list before allowing someone near nuclear weapons).
With respect to user authentication in electronic contexts we generally use secrets because computers don't (or at least haven't) had the ability to use the sorts of biometric authentication that humans use quite effectively. But, when we equip them with biometric sensors, they can.
HOWEVER, this does not mean that biometrics are useful for authentication in all circumstances.
Secret-based authentication has the advantage that -- assuming the secret has sufficient entropy and can be assumed not to have leaked nor been intercepted and cannot be rerouted (note that that's a pretty long list of criteria, some of which are hard to establish) -- you don't have to worry about the possibility that the authentication could be spoofed. An attacker who doesn't know the secret can't fake knowing the secret.
Biometrics, though, are not secrets. They are public knowledge. This means that an attacker must be expected to have access to copies of our fingerprints or faces. The biometric authentication process is different, though. It does not rely on secrecy of the authenticator, but instead on non-replayability. If we can be certain that (for example) the fingerprint placed on the scanner belongs to the person we wish to authenticate, and that the stored template we match against belongs to the person we wish to authenticate, then we can perform a good authentication. The fact that the fingerprint is not secret does not matter.
Where biometrics fail is if (a) we can't be certain that the livescan data acquired from the sensor belongs to the person trying to authenticate or (b) the stored template belongs to the person we wish to authenticate. Part (a) is particularly difficult to validate in many contexts because faking the input isn't necessarily hard to do, and in some cases an attacker can even bypass the sensor entirely and simply inject a digital copy.
This doesn't mean biometrics are worthless, it just means they're only useful in certain contexts. And, again, their utility for authentication has nothing to do with their secrecy. And rotation is likewise irrelevant and silly to discuss. You need to rotate secrets because you can't be certain they have stayed secret and because if they have low-ish entropy they may have been brute forced. None of that applies to biometrics because they're not secrets and their utility as authenticators does not depend on secrecy.
Can we please kill this incorrect meme about biometrics as identifiers, not authenticators? They can be either, o
I tried Inbox, but wasn't impressed. It strips so much of gmail away that it is basically "Gmail for beginners". You want filters, labels, etc, then it is worthless.
Actually, Inbox is Gmail for power users, for people who have massive volumes of e-mail to manage. It takes a little bit of work to figure it out and set it up, but once you have, it's awesome. There are some features it lacks, like complex filters (simple filters are very easy to set up; you just move a message to a label and Inbox asks if you want to always do that. Click "yes" and you have a new filter rule), vacation auto-responder and the like, but you can always use the Gmail UI when you need to set stuff like that up.
The Inbox features that that make it great for heavy e-mail users are:
Snooze.
Many people use their e-mail inbox at least partially as a task list, especially their work e-mail. This results in having to keep e-mails that for you can't work on yet sitting in your inbox, cluttering it up and making it harder to process new e-mail. When you snooze an e-mail, it goes away until some point in the future. You can pick a date and time, or even a location (requires using the Inbox app on your mobile device). Heavy application of snooze with well-chosen times/locations lets you clear all of the stuff you can't do yet out of the way, knowing it will come back later when you can handle it.
Bundles.
Bundles are just Gmail labels, but with an additional setting that tells Inbox to group them in the inbox. This is fantastic for high-volume mailing lists. With Gmail you can get almost the same effect by setting a filter to apply a label and skip the inbox, but then you have to remember to actually go look at the label from time to time. With bundles, you get the same grouping effect but the bundles show up in your inbox so you don't forget to go look. The reason that grouping (by whichever mechanism) is useful is because when you have large volumes of email, most of which you don't actually need to read, it's much faster to scan through a list of subject lines and evaluate what's important and what isn't when you already know the context.
My process for plowing through a busy mailing list is to scan the subject lines and click/tap the "pin" icon on the few that are interesting, then "sweep" the rest. A single click or gesture archives all unpinned items in a bundle. Then I handle (or snooze until I can handle) the pinned items.
I also have a bundle (label) called "Me" that is applied by a filter that looks for my name or username in the To line or the body of the message. This helps me to be sure that I notice e-mails where people are mentioning me or asking me questions. It's the first bundle I look for every time I check my e-mail. Similarly, I have a bundle that extracts e-mails that reference my project's name. That's the second bundle I look at. Other high priority bundles are e-mails from the code review system and e-mails from the bug tracker.
Obviously there are many e-mails that mention both my project and me. That's fine; bundles are labels not folders, and it's perfectly reasonable for an e-mail to be in more than one of them. When I archive a message in one bundle, it disappears from the others. So, often I'll look at Inbox and see the "Me", project, code review and bug tracker bundles displayed, but by the time I've processed everything in the "Me" bundle, the other three have disappeared.
Delayed Bundles.
I think this vies with snooze as the killer feature of Inbox. By default, a bundle appears in the inbox whenever you receive new mail with that label. But there's lots of stuff, at least in my inbox, that I don't need to see immediately. Having low-priority stuff displayed instantly distracts me from my work, or obscures truly urgent e-mail. Also, it's more efficient to handle low-priority e-mail in bulk. So, you can specify that a bundle should only appear once per day, or once per week.
Not to be sexist, but most women prefer jobs that include more interaction with people and less time spent in solo problem solving, so it's not terribly surprising that she does't love coding. This isn't to say there aren't women who really like coding, or even introverted women who find working with people all day to be unpleasant. There are all kinds... but on average my observation is that women prefer more human interaction.
So, assuming that your wife falls into that category, there are lots of roles in and around software development that are more people-focused. Project management requires an additional set of skills, both people skills and management skills, but it's eminently learnable, and having a technical background is very valuable -- as long as it doesn't cause her to second-guess what the developers are telling her (always a risk with PMs, and even more with those whose technical background is shallower than they think it is. There's a tendency to assume that everything they don't know how to do is easy.)
Business Analyst is another good one. It, again, requires some additional skills she probably doesn't have but can learn. Industry knowledge tends to be important, but most companies are okay with analysts learning that context on the job. She also needs to learn how to gather and document requirements. A technical background is useful there because good requirements need quite a bit more precision than most non-technical people are used to. There's also a risk; formerly-technical BAs have a tendency to overspecify. An important skill for this role which isn't so easy to learn is writing. Good BAs are excellent writers, able to concisely and accurately boil complex issues down to simple statements.
Another option that might be excellent if she can swing it is Systems or Application Architect. Companies generally want experienced, senior developers to move into these roles, but smart but less-experienced people can do it as well. Architects take the business requirements and convert them into high-level technical plans/architectures. Architects tend to spend less time interacting with people than PMs or BAs, but still quite a bit since they provide the primary interface between the technical and business teams. Architects need to have good technical skills and good "taste", meaning a good feel for what sorts of structures are easy to build, easy to maintain and flexible, and for how to intelligently trade those issues off. They also need to be good at translating technical issues into language the business people can understand. Honestly I expect that your wife probably doesn't have the depth of experience needed to make a good architect, but I thought I'd throw it out.
Another that might be good if she's a good writer and enjoys writing is technical writing. Good tech writers have greater need for writing skill than they do technical skill, but the latter is very valuable because it enables them to more quickly and accurately understand the information that needs to be documented.
In smaller companies a lot of these roles get mixed and combined with other business roles, so another good option is to look for a position that isn't necessarily directly related to software development, but could benefit from having a deeply IT-literate person.
Finally, the option that I've long thought I'd take if I ever got tired of writing code is the law. It's a lot of additional training, but I think there is a deep and growing need for attorneys who understand technology. This is especially true in the areas of patent and copyright law, but I think it applies in many areas. Of course, the law may not have any attraction whatsoever for your wife.
Whatever, I'd really encourage her to take the time to figure out what she wants to do, and do that, rather than settling for something she doesn't really like. We so much of our lives working that it's really a waste to spend it doing something we don't like.
This is completely untrue. The electorate is pretty divided, and whether you can find a majority depends which poll you look at, and which week. The fact is that there is a significant part of the electorate that thinks bulk surveillance is fine because they have nothing to hide and it keeps us safe. That they're wrong on both counts doesn't change their opinion, or their votes
Congress mostly agrees with him.
And yet they passed the USA Freedom Act which, although better than the PATRIOT Act, still authorizes way too much surveillance. And in the process they failed to do anything to curtail article 702 of the FISA, which is the basis for the FISA court's ruling -- as was completely predictable before passage of USA Freedom. The argument is that while article 702 authorizes only surveillance of foreign people, the court considers it perfectly reasonable for the NSA to hoover up ALL the data and then figure out later what they can and cannot look at. This all comes back to the NSA's choice to define "collect" as "look at", since the law hadn't defined the term.
Congress had a perfect opportunity to define "collect" as "collect", and chose not to.
Yeah, we have a problem here. And the "democratically elected government" ain't it.
The problem is fundamentally the electorate, which isn't sufficiently convinced that bulk data collection is a bad thing. If 80% of the voters wanted it shut down, enough to make it a major election issue, it would be shut down. But as is Congress knows that with a slim majority (at best) concerned about data collection, if they shut it down and then Something Bad happened the voters would turn on them like a rabid dog.
The system isn't perfect, but it is basically working as intended. We just need to convince more of our fellow Americans that surveillance is bad.
... it's just a little more than 1% the size of OpenSSL...Notably, s2n does not provide all the additional cryptographic functions that OpenSSL provides in libcrypto, it only provides the SSL/TLS functions....
So then, aren't size comparisons between OpenSSL and s2n at best useless, and at worst intentionally misleading?
No, but this particular comparison is. Besides all of the stuff s2n doesn't provide, s2n actually uses OpenSSL's libcrypto to provide the implementations of all of its crypto algorithm. A useful comparison could be made between OpenSSL's TLS layer and s2n, with some caveats listing the TLS features s2n doesn't provide.
Note that none of this means that s2n doesn't have value. If you don't need the other OpenSSL features, it's a lot less code to audit.
you've also never had a mini-gun pointed at him by private "security" personal
There are private security personnel with miniguns? Are they accepting applications? I don't actually want the job, I just want to go through training and shoot the guns.
Like most of the up-voted posters here, I think you're missing the point. This new service isn't a Google Code replacement or a Github competitor. It's an add-on for cloud-based hosting, so people who are hosting systems on Google App Engine or Compute Engine can keep their source there as well, with nice tools for working with the code online, managing releases and even live debugging... if there's a problem with your running app you can debug it instantly. The system snapshots the live system so it's not interrupted and then gives you an online debugger so you can examine the state, step through the code, etc.
It's a value-added feature on a paid cloud hosting service, not a place to host your latest open source project. That's what Github is for.
But one of the vulnerabilities I've pointed out recently to proxy maintainers is that it's become quite commonplace to host SSL based traffic on an external router or load balancer, and carry it entirely unencrypted between that load balancer and the local server. It often eases maintenance of SSL keys and allows far less expensive, small servers to handle the actual traffic and allows the cost of robust SSL services to be shared more effectively.
Google's encryption is end-to-end. It's also not SSL-based, but instead much simpler and more robust (and more efficient), though there's nothing proprietary or custom about the encryption ciphers or protocols used (Google employs lots of cryptographers who would quickly stomp on any questionable designs). I work for Google and used to do stuff related to internal network encryption though I worked on a different aspect of it, focused on securing payments data (credit card numbers, etc.).
I think it would be awesome if Google were to publish the details of its security infrastructure, which is dramatically better than anything I saw in my 15 years as a security consultant, but AFAIK that hasn't been done so I have to keep my comments vague and high-level.
I'll also point out, since I know it has been mentioned publicly, that Google didn't actually start doing all of the link encryption in response to Snowden's revelations. It was a project that was already well under way. Snowden's information did cause the project to be accelerated, though.
From what I saw, the main effect was that the tolerance for exceptions to the encryption requirement dropped basically to zero. In an enormous and complex infrastructure like Google's there are always dozens of corner cases where anything you'd like to do is really hard for one reason or another, and so big infrastructure changes tend to take years to fully deploy, to avoid requiring project teams to drop all their productive work in order to avoid breakage from the change. Snowden's data changed the encryption mandate from "You need to get this done as soon as you can" to "Encryption will be on 100% by date X, no exceptions. If you can't see how to make it work, come talk to us and we'll help." (X was single-digit weeks away).
I know one team who had to deploy a spit-and-baling-wire construction to enable their protocol to be encrypted, and then had to fight with serious performance degradation until they got a well-designed and tested replacement in place. They begged for permission to turn off encryption for a while so they could focus on building the solid replacement rather than spending their time fighting production fires caused by the interim solution... and they were denied. This was for an important production service related to financial systems, too, which gives you a good idea of how serious Google was about the encryption mandate.
Thank you, Edward Snowden!
(I want to be sure no one thinks that last line is sarcastic. It's not. At all. I think Edward Snowden is one of the great American heroes, and I think that history will eventually give him his considerable due. I don't know anyone on the team I mentioned who would disagree, either, even though it caused them some weeks of long hours and stress.)
I'm not sure what encryption is useful for. If my servers get hacked, they're able to read encrypted files.
You mention laptops and mobile devices, and claim that they get hacked way more often than they get lost/stolen. This is absolutely not true. Look at the many, many instances of laptops being lost or stolen with sensitive databases on them, and the ones that get reported publicly are just a tiny fraction.
It's also not necessarily the case with ext4 encryption that a box getting hacked reveals all of the data on it. Ext4 encryption allows each user account -- or even various subdirectory, IIRC -- to have its own keys. So a hacker can only get access to the directories whose keys have been loaded into memory. So the attacker has to own the box and then maintain ownership and connectivity until the data he's after has been unlocked.
You're also ignoring implementations which use hardware-based keys (HSM or similar) with other access controls on key usage, potentially even including rate limiting. So even if an attacker manages full privilege escalation and fully owns the box, he can't get access to anything encrypted unless he can satisfy the other access control requirements, and may also be rate-limited.
Malware on my Android device can read my encrypted files as soon as I get the phone properly booted.
Only if said malware can manage a privilege escalation attack. Granted that this issue is orthogonal to disk encryption, which is all about protecting against attackers with physical access to a powered down (or, to a lesser extent) locked device.
It should be pretty hard to obtain an expendable human in the countries where the remaining rhinos live. C4 is very stable and won't go off on impact, but a stable and long-lasting detonator would be needed.
Expendable humans are easy to find anywhere, and much easier in Africa than most places.
It's not about the stability of the explosive, or even the detonator, it's about the mechanism for triggering the detonator. It has to be sufficiently sensitive that it is certain to go off when the horn is removed, but cannot be triggered accidentally even by the enormous forces rhinos put on their horns. For that matter, getting the fake horn attachment to withstand those forces may not be trivial.
New idea: Give the rhinos an authentic-looking prosthetic horn with some C4 in it and a tensioned trigger wire running to the old horn stump. If some fucker cuts the horn off, BOOM.
Just means the poacher needs an expendable human, too. Those aren't particularly hard to obtain, unfortunately. And you also have to be very careful to ensure that the bomb won't go off when the rhino smacks something with its horn. Though I suppose blowing up all the rhinos will stop the poaching...
Heck, some European countries are beginning to get fairly concerned about population decline. Denmark has gone so far as to to run PSAs encouraging people to have children. Globally, it seems pretty clear that we've already passed the peak birthrate and it seems that we can expect it to continue dropping. Although births are declining the total population will continue to rise for a while because right now the world demographics are heavily weighted to the young end, so population will rise as the age distribution is "filled out". We're on course to hit a peak of about 10 billion people, sometime around 2040-2050. This assumes we don't make great breakthroughs in life extension.
Slashdot Mirror
Best new addition in Android is regions on the lock screen that can simply be tapped to unlock the phone and open the app.
Actually it takes a double tap, quick and fairly well-targeted.
Sometimes reporting, or history, distorts the focus or some aspect of an event. For instance most of us were led to believe that Sputnik was an effort of a cold-war space-race instead of being part of an international geophysical year. (analysis of how the U.S. and others perceived it and what response followed is another matter)
Hehe, bad choice of examples. Yes, Sputnik was launched during an IGY year of "cooperation"... but that doesn't mean it wasn't a cold war space race from the beginning. The USSR announced their intention to launch an artificial satellite nine days after the US announced the same intention. Then the USSR went forward with designing the satellite, only to discover that their original planned machine was going to take too long. Afraid that the US might beat them to it, they stepped back and focused on a simpler design so they could get it into space faster, and beat the US. As soon as their launch vehicle was good to go, they launched, pushing back some planned military test launches to do it.
The last Uber driver I had, was also a comedian/writer (Los Angeles). He didn't need a living wage, he wanted a part time job with a ton of flexibility to supplement income.
Makes perfect sense to me. There are lots of people whose lifestyles don't permit a regular job, but could use a flexible income supplement.
The next time someone says "that doesn't make a living wage" the correct response is to punch them in the mouth.
That's a rather violent, not to mention criminal, response. I think not.
First, my comment was not a "defense" of anything.
Second, you seem to have missed the sentence "It's not quite as good if the smartphone is also providing the fingerprint scanner and camera, because in the event of an attempted fraudulent transaction that means the attacker is in control of those components."
Also, you seem to have missed the last paragraph. In fairness, I suppose I wasn't quite clear enough. When I said that the security is in the same ballpark as a four-digit PIN, I was comparing to a system using phone-mounted sensors. With sensors provided by the retailer, in a staffed checkout lane, it's unambiguously stronger.
You seem to acknowledge that the good guy with a gun, most likely, cannot kill or fully disable the shooter in this situation.
zerofoo said nothing of the sort. He said that killing or fully disabling the shooter isn't necessary, not that it's not possible, or even unlikely.
The history of mass shooting violence in the US bears out both zerofoo's point that killing or disabling the shooter often isn't necessary, since mass shooters tend to suicide as soon as they meet armed resistance, and even those who don't are clearly going to have to shift their focus from mass murder to self-defense or be an easy target. There are plenty of cases in which shooters have been killed, disabled or otherwise stopped by citizens, though they tend to get less press for the simple reason that fewer people die.
So now you have to calculate, how many people could potentially be saved in that scenario, versus how many people would be killed if handguns are more widespread. If 5% of the populace is armed now, what happens to the death by gun rates when its 10%, 20%, 75%, 100%?
Interestingly, the US has conducted this experiment over the last 40 years or so, as the number of concealed carry permit holders went from basically zero to up to 15% in some areas of the country. What happened? Not much. Violence declined, and there is some weak statistical evidence that it declined faster in areas where more people began carrying guns on a daily basis. There is no evidence that violence increased.
Will the number of random shootings go down by allowing anyone, including the mentally ill, to have easier access to guns without waiting periods?
I suspect it won't change at all. What would reduce the number of shootings is removing all of the guns, but that is impossible.
P.S. Several school shootings (like Columbine) have taken place at schools with an armed police presence.
This is something of an unrelated point, but I think it's worth noting that police did not respond quickly at Columbine High School, and that the experience dramatically changed police doctrine for responding to active shooters, across the nation. After-action analyses showed that as soon as the shooters faced aggressive armed response, they killed themselves, but that happened many minutes, and several deaths, later than it could have. At the time standard procedure was to cordon the area, isolate the shooters and wait for enough backup to arrive -- preferably SWAT -- that the police could enter in overwhelming force. But Columbine changed that, and most police departments now train their officers that if they have good reason to believe it's a lone shooter then the very first officers on the scene should enter immediately.
Immediate entry, without overwhelming force or special weapons, seems like it significantly increases the risk to the officers, but in practice it doesn't, much. And, of course, waiting tends to give shooters time and space to rack up massive body counts.
It takes a couple weeks to get used to standing. Stick with it.
Or just change positions several times per day. I stand until I'm tired of it then sit for 30 minutes, repeat. I set a timer for the sitting periods, otherwise I find that when I'm focused on something I forget to stand up again. I've thought about hacking and arduino into the controls on my desk and automating that, so that after 30 minutes my desk automatically returns to the standing position, but haven't gotten around to it.
I have a motorized desk from VersaTables. Nice desk and the company was great to work with. Not cheap, though, not at all.
You have to be able to float that much money to wait for the rebate, correct?
Not if you lease. If you lease, it's the lessor that gets the rebate, so when they calculate the financing they just take it off the top. The federal credit, anyway. This is one of several reasons why more EVs are leased than purchased.
He also says he had to install a 240V socket it in his garage because apparently though you can charge it on 120V in a pinch, apparently it can cause damage to the batteries. That's according to Nissan.
This is incorrect. Charging on 120V doesn't do any damage to the batteries, in fact it's probably a little bit better for them. The problem with level 1 charging is that it's slow. Assuming the LEAF's battery is empty it takes about 21 hours to charge it to full on the 120V adapter included with the car.
I actually charged my car regularly on 120V and it wasn't as bad as you might think -- as long as I only needed to make one trip into town per day (from my house to the city is about a 40-mile round trip). The car was almost always fully-charged by morning, but if I went somewhere in the morning and came back home, there was no possibility of making a second trip in the afternoon or evening. Not without stopping off at the level 3 charger in town, anyway. Which I did from time to time -- it's free, and recharges the car from empty in about an hour, but it means having to kill an hour, and there isn't much of interest within walking distance of the charger.
So, I installed a 220V "level 2" charger. With it, the car recharges from empty in a little under four hours. In practice, that means that when I pull into the garage and plug in, it's generally full again in a couple of hours. Most of the time the flexibility that provides doesn't matter, but sometimes it's very handy. The level 2 charger cost me about $400. Was it worth it? Maybe, maybe not.
Both of you are wrong and so is Dustin Kirkland (whoever he is). The core of your error is in this statement:
Only secrets can be used as token for authentication.
That sentence is true, as stated, but only because it includes the word "token". Yes if you're using secret tokens for authentication, then the tokens must be secret. But exchanging secrets (or proof of possession of secrets, which is what most cryptographic authentication protocols do) is not the only way to do authentication. Not by a long shot. In fact, humans hardly ever use secrets for authentication.
How do you identify and authenticate your mom? Do you ask her for a secret password? Of course not. You use the same tools for both identifying and authenticating her, and those tools are a set of biometric markers. The same set of tools are also used in high security situations. Back when I was a security guard in the Air Force, I was trained that personal recognition is the very best form of authentication. Not only is it not necessary to check the badge of an individual you know personally, badge-checking is inferior to personal recognition for authentication (note that badge-checking may still be important for authorization, verifying that the person who has been identified and authenticated actually has permission to enter. Thus I was trained to always check the access control list before allowing someone near nuclear weapons).
With respect to user authentication in electronic contexts we generally use secrets because computers don't (or at least haven't) had the ability to use the sorts of biometric authentication that humans use quite effectively. But, when we equip them with biometric sensors, they can.
HOWEVER, this does not mean that biometrics are useful for authentication in all circumstances.
Secret-based authentication has the advantage that -- assuming the secret has sufficient entropy and can be assumed not to have leaked nor been intercepted and cannot be rerouted (note that that's a pretty long list of criteria, some of which are hard to establish) -- you don't have to worry about the possibility that the authentication could be spoofed. An attacker who doesn't know the secret can't fake knowing the secret.
Biometrics, though, are not secrets. They are public knowledge. This means that an attacker must be expected to have access to copies of our fingerprints or faces. The biometric authentication process is different, though. It does not rely on secrecy of the authenticator, but instead on non-replayability. If we can be certain that (for example) the fingerprint placed on the scanner belongs to the person we wish to authenticate, and that the stored template we match against belongs to the person we wish to authenticate, then we can perform a good authentication. The fact that the fingerprint is not secret does not matter.
Where biometrics fail is if (a) we can't be certain that the livescan data acquired from the sensor belongs to the person trying to authenticate or (b) the stored template belongs to the person we wish to authenticate. Part (a) is particularly difficult to validate in many contexts because faking the input isn't necessarily hard to do, and in some cases an attacker can even bypass the sensor entirely and simply inject a digital copy.
This doesn't mean biometrics are worthless, it just means they're only useful in certain contexts. And, again, their utility for authentication has nothing to do with their secrecy. And rotation is likewise irrelevant and silly to discuss. You need to rotate secrets because you can't be certain they have stayed secret and because if they have low-ish entropy they may have been brute forced. None of that applies to biometrics because they're not secrets and their utility as authenticators does not depend on secrecy.
Can we please kill this incorrect meme about biometrics as identifiers, not authenticators? They can be either, o
I tried Inbox, but wasn't impressed. It strips so much of gmail away that it is basically "Gmail for beginners". You want filters, labels, etc, then it is worthless.
Actually, Inbox is Gmail for power users, for people who have massive volumes of e-mail to manage. It takes a little bit of work to figure it out and set it up, but once you have, it's awesome. There are some features it lacks, like complex filters (simple filters are very easy to set up; you just move a message to a label and Inbox asks if you want to always do that. Click "yes" and you have a new filter rule), vacation auto-responder and the like, but you can always use the Gmail UI when you need to set stuff like that up.
The Inbox features that that make it great for heavy e-mail users are:
Snooze.
Many people use their e-mail inbox at least partially as a task list, especially their work e-mail. This results in having to keep e-mails that for you can't work on yet sitting in your inbox, cluttering it up and making it harder to process new e-mail. When you snooze an e-mail, it goes away until some point in the future. You can pick a date and time, or even a location (requires using the Inbox app on your mobile device). Heavy application of snooze with well-chosen times/locations lets you clear all of the stuff you can't do yet out of the way, knowing it will come back later when you can handle it.
Bundles.
Bundles are just Gmail labels, but with an additional setting that tells Inbox to group them in the inbox. This is fantastic for high-volume mailing lists. With Gmail you can get almost the same effect by setting a filter to apply a label and skip the inbox, but then you have to remember to actually go look at the label from time to time. With bundles, you get the same grouping effect but the bundles show up in your inbox so you don't forget to go look. The reason that grouping (by whichever mechanism) is useful is because when you have large volumes of email, most of which you don't actually need to read, it's much faster to scan through a list of subject lines and evaluate what's important and what isn't when you already know the context.
My process for plowing through a busy mailing list is to scan the subject lines and click/tap the "pin" icon on the few that are interesting, then "sweep" the rest. A single click or gesture archives all unpinned items in a bundle. Then I handle (or snooze until I can handle) the pinned items.
I also have a bundle (label) called "Me" that is applied by a filter that looks for my name or username in the To line or the body of the message. This helps me to be sure that I notice e-mails where people are mentioning me or asking me questions. It's the first bundle I look for every time I check my e-mail. Similarly, I have a bundle that extracts e-mails that reference my project's name. That's the second bundle I look at. Other high priority bundles are e-mails from the code review system and e-mails from the bug tracker.
Obviously there are many e-mails that mention both my project and me. That's fine; bundles are labels not folders, and it's perfectly reasonable for an e-mail to be in more than one of them. When I archive a message in one bundle, it disappears from the others. So, often I'll look at Inbox and see the "Me", project, code review and bug tracker bundles displayed, but by the time I've processed everything in the "Me" bundle, the other three have disappeared.
Delayed Bundles.
I think this vies with snooze as the killer feature of Inbox. By default, a bundle appears in the inbox whenever you receive new mail with that label. But there's lots of stuff, at least in my inbox, that I don't need to see immediately. Having low-priority stuff displayed instantly distracts me from my work, or obscures truly urgent e-mail. Also, it's more efficient to handle low-priority e-mail in bulk. So, you can specify that a bundle should only appear once per day, or once per week.
Also, don't give your SSID
I meant password, of course. Sorry, not fully awake.
Or, just don't use windows 10. I think I may have found the answer there.
Also, don't give your SSID to anyone who does or might in the future use Windows 10, or have a Windows phone.
+1
Not to be sexist, but most women prefer jobs that include more interaction with people and less time spent in solo problem solving, so it's not terribly surprising that she does't love coding. This isn't to say there aren't women who really like coding, or even introverted women who find working with people all day to be unpleasant. There are all kinds... but on average my observation is that women prefer more human interaction.
So, assuming that your wife falls into that category, there are lots of roles in and around software development that are more people-focused. Project management requires an additional set of skills, both people skills and management skills, but it's eminently learnable, and having a technical background is very valuable -- as long as it doesn't cause her to second-guess what the developers are telling her (always a risk with PMs, and even more with those whose technical background is shallower than they think it is. There's a tendency to assume that everything they don't know how to do is easy.)
Business Analyst is another good one. It, again, requires some additional skills she probably doesn't have but can learn. Industry knowledge tends to be important, but most companies are okay with analysts learning that context on the job. She also needs to learn how to gather and document requirements. A technical background is useful there because good requirements need quite a bit more precision than most non-technical people are used to. There's also a risk; formerly-technical BAs have a tendency to overspecify. An important skill for this role which isn't so easy to learn is writing. Good BAs are excellent writers, able to concisely and accurately boil complex issues down to simple statements.
Another option that might be excellent if she can swing it is Systems or Application Architect. Companies generally want experienced, senior developers to move into these roles, but smart but less-experienced people can do it as well. Architects take the business requirements and convert them into high-level technical plans/architectures. Architects tend to spend less time interacting with people than PMs or BAs, but still quite a bit since they provide the primary interface between the technical and business teams. Architects need to have good technical skills and good "taste", meaning a good feel for what sorts of structures are easy to build, easy to maintain and flexible, and for how to intelligently trade those issues off. They also need to be good at translating technical issues into language the business people can understand. Honestly I expect that your wife probably doesn't have the depth of experience needed to make a good architect, but I thought I'd throw it out.
Another that might be good if she's a good writer and enjoys writing is technical writing. Good tech writers have greater need for writing skill than they do technical skill, but the latter is very valuable because it enables them to more quickly and accurately understand the information that needs to be documented.
In smaller companies a lot of these roles get mixed and combined with other business roles, so another good option is to look for a position that isn't necessarily directly related to software development, but could benefit from having a deeply IT-literate person.
Finally, the option that I've long thought I'd take if I ever got tired of writing code is the law. It's a lot of additional training, but I think there is a deep and growing need for attorneys who understand technology. This is especially true in the areas of patent and copyright law, but I think it applies in many areas. Of course, the law may not have any attraction whatsoever for your wife.
Whatever, I'd really encourage her to take the time to figure out what she wants to do, and do that, rather than settling for something she doesn't really like. We so much of our lives working that it's really a waste to spend it doing something we don't like.
The electorate fully agrees with him.
This is completely untrue. The electorate is pretty divided, and whether you can find a majority depends which poll you look at, and which week. The fact is that there is a significant part of the electorate that thinks bulk surveillance is fine because they have nothing to hide and it keeps us safe. That they're wrong on both counts doesn't change their opinion, or their votes
Congress mostly agrees with him.
And yet they passed the USA Freedom Act which, although better than the PATRIOT Act, still authorizes way too much surveillance. And in the process they failed to do anything to curtail article 702 of the FISA, which is the basis for the FISA court's ruling -- as was completely predictable before passage of USA Freedom. The argument is that while article 702 authorizes only surveillance of foreign people, the court considers it perfectly reasonable for the NSA to hoover up ALL the data and then figure out later what they can and cannot look at. This all comes back to the NSA's choice to define "collect" as "look at", since the law hadn't defined the term.
Congress had a perfect opportunity to define "collect" as "collect", and chose not to.
Yeah, we have a problem here. And the "democratically elected government" ain't it.
The problem is fundamentally the electorate, which isn't sufficiently convinced that bulk data collection is a bad thing. If 80% of the voters wanted it shut down, enough to make it a major election issue, it would be shut down. But as is Congress knows that with a slim majority (at best) concerned about data collection, if they shut it down and then Something Bad happened the voters would turn on them like a rabid dog.
The system isn't perfect, but it is basically working as intended. We just need to convince more of our fellow Americans that surveillance is bad.
... it's just a little more than 1% the size of OpenSSL...Notably, s2n does not provide all the additional cryptographic functions that OpenSSL provides in libcrypto, it only provides the SSL/TLS functions....
So then, aren't size comparisons between OpenSSL and s2n at best useless, and at worst intentionally misleading?
No, but this particular comparison is. Besides all of the stuff s2n doesn't provide, s2n actually uses OpenSSL's libcrypto to provide the implementations of all of its crypto algorithm. A useful comparison could be made between OpenSSL's TLS layer and s2n, with some caveats listing the TLS features s2n doesn't provide.
Note that none of this means that s2n doesn't have value. If you don't need the other OpenSSL features, it's a lot less code to audit.
you've also never had a mini-gun pointed at him by private "security" personal
There are private security personnel with miniguns? Are they accepting applications? I don't actually want the job, I just want to go through training and shoot the guns.
Like most of the up-voted posters here, I think you're missing the point. This new service isn't a Google Code replacement or a Github competitor. It's an add-on for cloud-based hosting, so people who are hosting systems on Google App Engine or Compute Engine can keep their source there as well, with nice tools for working with the code online, managing releases and even live debugging... if there's a problem with your running app you can debug it instantly. The system snapshots the live system so it's not interrupted and then gives you an online debugger so you can examine the state, step through the code, etc.
It's a value-added feature on a paid cloud hosting service, not a place to host your latest open source project. That's what Github is for.
But one of the vulnerabilities I've pointed out recently to proxy maintainers is that it's become quite commonplace to host SSL based traffic on an external router or load balancer, and carry it entirely unencrypted between that load balancer and the local server. It often eases maintenance of SSL keys and allows far less expensive, small servers to handle the actual traffic and allows the cost of robust SSL services to be shared more effectively.
Google's encryption is end-to-end. It's also not SSL-based, but instead much simpler and more robust (and more efficient), though there's nothing proprietary or custom about the encryption ciphers or protocols used (Google employs lots of cryptographers who would quickly stomp on any questionable designs). I work for Google and used to do stuff related to internal network encryption though I worked on a different aspect of it, focused on securing payments data (credit card numbers, etc.).
I think it would be awesome if Google were to publish the details of its security infrastructure, which is dramatically better than anything I saw in my 15 years as a security consultant, but AFAIK that hasn't been done so I have to keep my comments vague and high-level.
I'll also point out, since I know it has been mentioned publicly, that Google didn't actually start doing all of the link encryption in response to Snowden's revelations. It was a project that was already well under way. Snowden's information did cause the project to be accelerated, though.
From what I saw, the main effect was that the tolerance for exceptions to the encryption requirement dropped basically to zero. In an enormous and complex infrastructure like Google's there are always dozens of corner cases where anything you'd like to do is really hard for one reason or another, and so big infrastructure changes tend to take years to fully deploy, to avoid requiring project teams to drop all their productive work in order to avoid breakage from the change. Snowden's data changed the encryption mandate from "You need to get this done as soon as you can" to "Encryption will be on 100% by date X, no exceptions. If you can't see how to make it work, come talk to us and we'll help." (X was single-digit weeks away).
I know one team who had to deploy a spit-and-baling-wire construction to enable their protocol to be encrypted, and then had to fight with serious performance degradation until they got a well-designed and tested replacement in place. They begged for permission to turn off encryption for a while so they could focus on building the solid replacement rather than spending their time fighting production fires caused by the interim solution... and they were denied. This was for an important production service related to financial systems, too, which gives you a good idea of how serious Google was about the encryption mandate.
Thank you, Edward Snowden!
(I want to be sure no one thinks that last line is sarcastic. It's not. At all. I think Edward Snowden is one of the great American heroes, and I think that history will eventually give him his considerable due. I don't know anyone on the team I mentioned who would disagree, either, even though it caused them some weeks of long hours and stress.)
Really, Google can't undo a change made by a fucking algorithm? Bullshit!
My guess is that there's a lot more to this story than what we're seeing.
(Disclosure: I work for Google, but know nothing about it beyond what's in the article.)
Do you train it? GMail will learn. It's basically flawless for me.
I'm not sure what encryption is useful for. If my servers get hacked, they're able to read encrypted files.
You mention laptops and mobile devices, and claim that they get hacked way more often than they get lost/stolen. This is absolutely not true. Look at the many, many instances of laptops being lost or stolen with sensitive databases on them, and the ones that get reported publicly are just a tiny fraction.
It's also not necessarily the case with ext4 encryption that a box getting hacked reveals all of the data on it. Ext4 encryption allows each user account -- or even various subdirectory, IIRC -- to have its own keys. So a hacker can only get access to the directories whose keys have been loaded into memory. So the attacker has to own the box and then maintain ownership and connectivity until the data he's after has been unlocked.
You're also ignoring implementations which use hardware-based keys (HSM or similar) with other access controls on key usage, potentially even including rate limiting. So even if an attacker manages full privilege escalation and fully owns the box, he can't get access to anything encrypted unless he can satisfy the other access control requirements, and may also be rate-limited.
Malware on my Android device can read my encrypted files as soon as I get the phone properly booted.
Only if said malware can manage a privilege escalation attack. Granted that this issue is orthogonal to disk encryption, which is all about protecting against attackers with physical access to a powered down (or, to a lesser extent) locked device.
It should be pretty hard to obtain an expendable human in the countries where the remaining rhinos live. C4 is very stable and won't go off on impact, but a stable and long-lasting detonator would be needed.
Expendable humans are easy to find anywhere, and much easier in Africa than most places.
It's not about the stability of the explosive, or even the detonator, it's about the mechanism for triggering the detonator. It has to be sufficiently sensitive that it is certain to go off when the horn is removed, but cannot be triggered accidentally even by the enormous forces rhinos put on their horns. For that matter, getting the fake horn attachment to withstand those forces may not be trivial.
New idea: Give the rhinos an authentic-looking prosthetic horn with some C4 in it and a tensioned trigger wire running to the old horn stump. If some fucker cuts the horn off, BOOM.
Just means the poacher needs an expendable human, too. Those aren't particularly hard to obtain, unfortunately. And you also have to be very careful to ensure that the bomb won't go off when the rhino smacks something with its horn. Though I suppose blowing up all the rhinos will stop the poaching...
Heck, some European countries are beginning to get fairly concerned about population decline. Denmark has gone so far as to to run PSAs encouraging people to have children. Globally, it seems pretty clear that we've already passed the peak birthrate and it seems that we can expect it to continue dropping. Although births are declining the total population will continue to rise for a while because right now the world demographics are heavily weighted to the young end, so population will rise as the age distribution is "filled out". We're on course to hit a peak of about 10 billion people, sometime around 2040-2050. This assumes we don't make great breakthroughs in life extension.
I'm not sure about older versions (I just don't remember) but with L it asks you if you want to sync your apps.