Now, finally, you said "some people have argued... shouldn't even be actively be contacting candidates." The question is ... why is this justified?

I don't know if it is justified. But enough people have taken that position, that we need to at least acknowledge, that there is a group of people with that opinion.

It is not hard to understand why some people have that opinion. Nobody want to see their own inbox filled up with offers from loads of companies they'd never want to work for. But of course a few unwanted offers per year is better than a situation where you couldn't apply for those jobs even if you want to.

Did you read the article? It seems that the only reason such a situation did not occur is because Sandberg told Google to pound sand. During the time in question, these emails clearly show that a very senior Google executive was directly asking Facebook not to hire Google employees, even if they employees in question wanted to go work there and what's more, good corporate relations were being pegged to that demand.

The article didn't come across as entirely clear to me. That particular point I missed on the first reading. I see that Rosenberg did go too far. The position facebook took did mean that in this particular case there was probably no harm done by Rosenberg's move. That doesn't make it acceptable though.

I wouldn't mind seeing facebook taking a small step towards Rosenberg's position. But Rosenberg was going even further off in the other direction. I'd certainly rather see facebook being a bit too aggressive in their search for candidates than I'd see facebook enter the agreement Rosenberg was suggesting.

There is a major difference between agreeing not to hire from each other, and just not actively going after each other's employees. I have worked at Google in the past, and while I was working there I was actively being approach by facebook recruiters. I was not the only person being approach like that. I heard from multiple colleagues that they too were being contacted by facebook recruiters. I am aware of multiple of my former colleagues who actually did get jobs at facebook.

To me facebook felt too aggressive in their pursuit of Google engineers. There was a real practice among facebook recruiters to search through linkedin and any other source, where they could identify Google engineers and contact them. I saw enough evidence pointing towards those people being contacted simply because they were currently working for Google. Personally I had zero interest in switching from Google to facebook, I don't think I even bother answering, when I was approached by facebook.

If Google and facebook had reached an agreement under which facebook would be a little less aggressive in their pursuit of Google engineers, I would not have feared this would have a negative impact on my salary. And it would have felt a bit more reasonable to me. The recruiters could still look for talented employees, and if by chance they end up finding Google employees, they could still approach them just like they would have, if they had not been Google employees. As long as they weren't directly picking candidates based on them working for Google, I would call it an improvement.

Some people have argued those companies shouldn't even actively be contacting candidates. Instead they should wait for interested candidates to submit a resume on their own. Even that would not even get close to not hiring each other's employees.

Employees could still move from Google to facebook, they just had to take initiative to submit a resume. I would only consider there to be a real problem, if facebook would reject resumes submitted by candidates, just because they happened to work for Google. I have seen no evidence of such a practice existing.

Certificate pinning is not possible in any real-world scenario. The problem is that certificates change too often.

There is a fairly simple fix for that, but it requires a bit of standardization. The idea is simply to not only have a certificate chain from a CA to the server certificate, but also have a secondary chain going through the server certificates over time. If the client has already stored a previous certificate, the server need to provide a chain from that old certificate to the new certificate.

And worse, there is no working signature authority _available_ for SSH host keys. This makes spoofing an SSH server for new users much simpler.

In many cases communicating the host public key out-of-band is simpler and more secure than using a certificate. Consider what happens in those cases where an SSL certificate is considered too much work or too expensive. Sites go with http instead. If the out-of-band communication of an ssh host key is too much work, you still go with ssh, you just trust the key exchanged the first time around. That may not give perfect security but it is still better than the completely unprotected communication channel. With ssh you get the additional benefit of the client remembering the key as well as simple to configure key based authentication. If the server is spoofed when the client uses key based authentication, the attacker does not learn any password or secret key. And though the attack may go undetected at first, it won't go undetected forever.

Also it isn't entirely true that there isn't any authority available for ssh. You could make use of RFC 4255 or RFC 6187.

And most envornmnets are not careful to tie the SSH private keys to a specific exposed server or service: they wind up resetting the host keys when they rebuild the host, and pay no attention to a client's confusion about changing keys.

When sysadmins pull such a stunt, users need to tell them to go fix it. If they have no other way to fix it, they need to communicate the new public key to the users in a secure fashion.

Sysadmins and IT supporters convincing users that some insecure practice is acceptable is probably the largest IT security threat we are facing today. Everybody who see that happening need to fight it.

An IT supporter may very well be saving a minute every now and then due to ignoring security. We need enough users giving those IT supporters a hard time, when they pull such a trick, that it isn't worthwhile to ignore security in the first place.

In fact SSH has done something that SSL will never do: it has completely replaced the corresponding unencrypted protocol

You surely know the reasons ssh was able to achieve this and SSL isn't. But for the benefit of others it is worthwhile spelling out the reasons. First of all SSL certificates means there is some additional difficulty to getting started with SSL, which isn't there for ssh. Switching from telnet, rsh and rcp to ssh really was as simple as installing the server and client and then start using it as a drop-in replacement.

It was that easy to get started, and you may not get the full security benefit, but even with this tiny effort in getting started you got much better security than the old scheme.

There is an additional reason why ssh was so successful in replacing the older alternatives, that was that ssh also added some useful new features. And features which run as the user you log in as - after you have authenticated - cannot as easily have exploitable security problems. So even with those added features, security was better than what it replaced.

I thought all planetary orbits were 1 year; it's sort of the definition of a year. Did they mean 11,400 Earth years?

If you want to use that sort of definition, then how old would you say the universe is? The universe doesn't orbit the sun or any other star. And you can't say it is 13800 million earth years old either, since the earth hasn't been orbiting the sun for that long. And how far is a lightyear, if the duration of a year depends on where you are?

When a year is mentioned without any other context, it means the time it currently takes the earth to orbit the sun.

NASA announced that Voyager 1 entered interstellar space, when it was about 127 AU from the sun. It is believed that it was travelling in the direction where the distance to interstellar space is shortest. It is significantly longer distance going in the opposite direction. So this newly detected dwarf planet may be spending most of its time in interstellar space, but not all of it.

Maybe we need a name for the region of space in which there are stable orbits around the sun. At some distance the gravity of other stars would cause a trajectory turning away from the sun. But what is that distance? More than 1000 AU it seems.

Metered internet billing + ISP-side customer-controlled firewall: what we need.

Sounds like a good idea. But I don't expect to ever see it happen.

plane flies on under auto-pilot until it runs out of gas.

That sounds like a suboptimal algorithm. Wouldn't it almost always make more sense for the auto pilot to attempt a landing in that case? The odds for survival may not be good in that case, but it seems like attempting to land would still give better odds than attempting to keep flying.

The last 30 minutes will be no voices on the cockpit voice recorder and nominal engine and performance data until the plane ran out of fuel and crashed.

That is speculation for now. The recordings from the black box can either confirm that hypothesis or potentially reveal new information. Either way the recording would be useful for the investigation.

metered internet would be fairer

The problem is that you do not have complete control over what amount of traffic flows over your line. Paying according to the amount of traffic which other parties could be driving up, is not an acceptable situation to most customers.

No neutrality rules have been broken because the ISP isn't shaping or filtering.

But the ISP would be failing to deliver the promised bandwidth. If the ISP would always deliver the bandwidth they had promised to the customer, there wouldn't be an issue. Unfortunately the ISPs will always pull the disclaimer about not guaranteeing, that the server you are accessing has spare capacity. Though this disclaimer makes sense, it isn't necessarily true in all cases, where the ISP would apply it.

If A want to send packets to B, and if A is not using all of the upstream that A has purchased from their ISP, and if B is not using all of the upstream that B has purchased from their ISP, then packets from A to B must get through with no packet loss caused by congestion. If there happen to frequently be congestion between the two ISPs preventing packets from being delivered even though neither endpoint is using all their capacity, then the ISPs are simply not delivering, the capacity they sold. And the ISPs should be required to make arrangements to upgrade capacity to match what they sold.

I only consider application of the disclaimer about the capacity of the other endpoint of the communication to be valid, if the other endpoint is actually using all of their purchased capacity. Simultaneously using that disclaimer against both endpoints of a communication smells like fraud.

There are other aspects to communication than the bandwidth. Packet loss and latency are just as important, but they are rarely advertised. The latency between two endpoints must never exceed the sum of the latency advertised to each endpoint and the latency inherent to the physical distance between the endpoints. AFAIK you can expect about 1ms/100km of roundtrip latency with the speed of light in optical fibers. In other words, if A has bought a connection with an advertised 5ms roundtrip latency, and B has bought a connection with an advertised 10ms roundtrip latency, and if the distance between A and B is 10000km, then the overall roundtrip latency must be not more than 5+100+10 milliseconds. Exceeding a roundtrip latency computed this way is not acceptable, not even due to buffering. Additional buffering would be acceptable if the sender explicitly picked a ToS specifying a desire for additional buffering, but it is not acceptable on the default ToS.

Finally packet loss should not exceed the sum of packet loss specified on the connection for each endpoint, unless either or both endpoint is exceeding their purchased capacity.

Otherwise why do they use "scrubbers" in closed systems

Because whatever "closed" system you are referring to is not really closed. It is only temporarily closed, and likely not entirely closed, due to receiving some amount of energy through light from the outside. But more importantly, just because a system is closed, it doesn't mean it is self-sustaining. If you had an entire balanced eco-system, you would only need light from the outside, and it could go on for millions of years without needing scrubbers. But if you do not have a balanced eco-system, you need to compensate. For example, if you remove plants from the eco-system, you need a supply of food, which will only last a finite amount of time, and you will build up waste products, including CO_2, which you'll need to contain.

As soon as you have waste products, that don't get recycled, you limit the lifetime of the system. If the waste would build up indefinitely, eventually every single atom in this closed system would be part of the waste products. Of course it doesn't end exactly like that, because the system is likely going to break down before you reach that point. So extrapolating to calculate when the mass of your waste reaches the full mass of the system will give you an upper bound on the lifetime, the lower bound will obviously be lower.

So responsible disclosure works because even if the threat is never disclosed fully by the person who found it, it might be discovered by some one else independently.

Not all companies think this way. Some seem to think that threats about legal action against the finder, will keep not only the finder from publishing, but everybody else as well. Or they seem to think that such threats can give the finder sufficient incentive to ensure, that nobody else will find the problem.

I am not entirely sure how such companies think, but they do try to cover up security vulnerabilities, which were found by outsiders by threatening those outsiders.