NAT isn't really too troublesome on phones since they rarely run servers, are usually connecting to cloud-based services
Any sort of peer-to-peer communication is problematic, if NAT is involved. Lots of the communication you want to do on phones is peer-to-peer in its nature, but actually implementations have often chosen inferior cloud based implementations, simply to work around NAT. Why else would you involve a cloud service, when what you really want to do is to move some data from one phone to another?
Additionally, even communication with cloud based services is problematic when NAT is involved.
Connecting to a cloud service in order to get a notification, once there is a new email or a new chat message is something you often want to do on a phone. But you cannot do that through a NAT, unless you a prepared to send a constant stream of packets to keep a connection tracking entry alive. Now your phone has to wake up every so often just to send another keepalive packet through the NAT. This consumes battery power, it also consumes bandwidth and if everybody does it, it consumes entries on the NAT.
If the NAT does run out of entries for connections, it will have to lower the lifetime of connections. That will lead to applications sending keepalives more frequently, and we are back in the same situation as before, only wasting more battery power and bandwidth.
and they move around so much that they'd probably have an IP change every 10 minutes if you handled them like a traditional routable IP.
NAT does not solve that problem, it actually makes it worse. You still have to keep track of the local IP you assigned to the phone if it is behind a NAT. The tracking of the IP address is not any harder just because it is a public address. But by introducing a CGN you introduce the requirement that all the traffic from the phone gets routed through that CGN even as the phone is moving. If you did not have the NAT layer, you only have the challenge of routing packets to the phone as it is moving, there is no need to get it through one particular NAT as well.
Less than two months after RIPE introduced rationing of IPv4 addresses, I one day found my internet connectivity to be totally broken. Turns out the ISP had turned on NAT in my modem (without telling me about it beforehand). They did have a self service page where I could turn NAT off again and get functional internet connectivity again. However some of my devices no longer received any reply from the DHCP server.
I called their support, who said the lack of reply from their DHCP server was due to the network interface on my computer being defective (which was obviously a lie). When I pointed out that their conclusion was directly contradicting the symptoms I had already explained them about, they just hanged up.
Calling their support one more time, I was able to get to a supporter who knew what was going on, and didn't just invent a lie. It turns out they had run out of IPv4 addresses, and were now enforcing a maximum of two devices online per customer regardless of what limit had been in effect previously.
A few days later I called them again asking for native IPv6, which I considered only fair, given that they had taken away some of the IPv4 addresses, which I were using. They promised me native IPv6 before the end of the year. That was in 2012, they still haven't delivered.
Other ISPs are putting all new customers behind CGN unless they pay an extra fee for a static IP address. You'd think they'd give you native IPv6 along with that. But alas, according to the majority of ISPs, there is no shortage of IPv4 addresses in this country, so nobody needs IPv6. And since nobody is buying IPv6 connectivity, the ISPs will not offer it (completely ignoring the fact, that the reason nobody is buying IPv6 connectivity is that the ISPs themselves aren't offering it in the first place).
From what I am told, native IPv6 plus CGN for IPv4 is already fairly common in Germany, but that's not enough to make me want to move across the border. I have yet to hear about ISPs putting customers who previously had a public IPv4 address behind NAT, but I would not be surprised if it happened.
Too bad http still works on ports other than 80. Genius plan thwarted.
Right. Cause users who don't know the difference between http and https and/or are too lazy to type https:/// in the URL are going to be typing a port number manually, when they enter a URL, just such that they can get an insecure connection. And websites, which care enough about security to support https in the first place are going to bring up a plain http server on a non-standard port number, just to ensure that users who don't want security can send all their traffic over a non-standard port - from a device where the user himself decided to block port 80 in the first place for security reasons.
Being able to run http on other ports has no implication for the security of the proposed setup. Blocking port 80 in order to enforce https is totally sensible, when it is there to protect users, who are not deliberately compromising their own security. An attacker performing a MitM attack cannot force a connection from port 80 onto a different port number, if the connection is blocked before even reaching the Internet.
Use iptables to block outgoing requests to any port 80.
Even better, use an iptables level REDIRECT to send the connection to a local http server, and have that http server do an HTTP level redirect to equivalent https URL.
They have a compromised root cert that the browser accepts as genuine, they create their own apparently valid cert for nefarious-site.com and your browser thinks all is well.
Compromising a CA certificate and compromising the certificate of an individual website is two very different situations. On average it is harder to compromise a CA certificate than that of an individual website. But for both types there is variation in difficulty. I have no doubt it is a lot easier to compromise the certificate of the most insecure CA than that of the most secure website. And if you have compromised one single CA certificate, you can use it for most of the active attacks, you want to perform. So it is mostly pointless to go for the certificates of individual websites.
MitM attacks using a compromised CA certificate done by governments is not unheard of. I think it was only a couple of months back I last saw a browser security update to get rid of a CA certificate, which was being abused by a government (in a European country AFAIR).
The point is, that sort of attack is discovered, if performed systematically. And they are mitigated as they happen, but after each mitigation there will still be easy targets among the remaining CAs.
That's why the Perspectives extension is useful, because it checks for certificate consistency.
True. Though you could achieve much of the same effect with less needs for infrastructure through certificate pinning.
I would assume all SSL certificates are compromised. Like, literally, all of them.
No amount of snooping on the network would compromise a private key, which never leaves the server in the first place. Thus the only way you could possibly compromise the certificate, would be if you put an invalid public key in the certificate in the first place. Since that would be immediately obvious to any server owner paying enough attention, it is safe to assume that compromising all certificates cannot be done without being detected. If they literally compromised all of them, it would only take one single security aware server administrator to notice it.
This is why we should focus much more on protocols that are secure against passive attacks, but not against active attacks. Systematic passive attacks can be pulled off without detection. Systematic active attacks cannot. Protection against active attacks is much harder and is the reason we have the CA system. It is not that protecting against active attacks is a bad idea, it is just that it is so hard that much communication isn't protected. Opportunistic encryption with security against active attacks could be done without needing certificates. If on top of that you do perform certificate validation on the most critical sites after you have established a connection with only the opportunistic protection, then you do get protection against active attacks. In order for this to make sense, it is important that until you do perform an active attack, you cannot know if the connection has been secured against active attacks.
Both types of connections will benefit by being indistinguishable from the other to a passive adversary.
The connections with only passive security benefits because it is now easier to do encryption, and moreover being indistinguishable from the minority of connections with active security protects you from systematic active attacks. This is because systematic attacks are bound to hit protected connections once in a while, so they cannot go undetected.
The connections with the full active security also benefits because they are now attracting less attention. They will be a minor fraction of a much larger amount of encrypted connections. A passive adversary cannot know which of the connections have active security and are likely to contain the juicy stuff.
A solution can be found with 3 generals, as long as only one is "disloyal" (fails) at a time.
I don't know what solution you are referring to. It has been formally proven, that it is impossible. The proof goes roughly like this. If an agreement can be reached in case of 1 failing node out of 3, that implies any 2 nodes can reach an agreement without involving the third. However from this follows, that if communication between the two good nodes is slower than communication between each good node and the bad node, the following can happen:
Each good node communicates with the faulty node, and since they are 2 out of 3, they can reach an agreement without communicating with the other good node. However the faulty node could be sending inconsistent messages to the two good nodes leading to each of the good nodes to believe an agreement has been made on distinct values. Two good nodes reaching a different conclusion is by definition a failure of the system.
Does this sound like an unrealistic scenario? I say it is not unrealistic. First of all, this is the sort of attack you'd perform against a system with moderate protection against inconsistencies. But even without byzantine nodes, it isn't an unlikely failure scenario. First of all assume there is a network split leaving two good nodes on different sides of the split, secondly assume the third node is hosted on a virtualization platform with some automatic recovery. The network split may have separated the host system of the virtualization from the management system, the management system assumes that host is down and spawns a new copy of the node on a different host. Now that node is cloned on both sides of the network split, and each clone is talking with a different good node in your agreement protocol.
The result stating that it is impossible to reach agreement with 1 out of 3 nodes failing can be generalized to talking about subsets of a larger number of nodes. If you take a large number of nodes and split them into three subsets, such that each node is in exactly one of the three subsets, then you cannot design a system, that can survive a failure of all nodes in one of those three subsets if the adversary gets to choose which subset.
For example, if you have a system that can tolerate 1 failure out of 4 nodes, then you could partition the nodes into 3 subsets with 1, 1, and 2 nodes in each subset. The adversary then picks the subset with 2 nodes, and the system fails. This result about subsets can used to directly show the 3t+1 bound.
It has been shown that this problem is solvable with 3 "Generals"
Correction. It has been shown that in case of up to t errors, it can be solved with 3t+1 Generals/nodes/CPUs/whatever. So if you assume 0 errors, you need only 1 node. If you want to handle 1 error, you need 4 nodes. There is a different result if you assume a failing node stops communicating and never sends an incorrect message, in that case you only need 2t+1. However that assumption is unrealistic, and the Byzantine problem explicitly deals with nodes deliberately sending false messages.
I find it interesting that they're deploying major changes during prime time.
There are advantages to deploying changes, while nobody is using the system. In the case of Google, such a time does not exist. There are also advantages to deploying changes during prime time. First of all, some problems only show up during peak load. If you deploy outside of peak load, and nothing bad happens right away, there is still a risk the system might break next time peak load hits. If the problem doesn't hit you right after making the change, but at a later time, it will not always be clear, what hit you.
There are multiple arguments for and against, the argument that eventually decided what to do was likely this: It is an advantage to deploy changes while the people who know how to fix problems are at work.
I find it interesting that they just deploy new configurations live without going to a test environment
Google does test changes in a test environment first. But you can never find every problem in a test environment. Some bugs depend on specific patterns in data and thus shows up in production, even if it worked just fine in testing. Once you know about the exact pattern to reproduce the bug, you can add it to your test data. But you couldn't test for it, before knowing about it. If a human would be able to think about every possible scenario, there wouldn't be bugs in the first place.
Assuming that just because it worked in testing, it will also work in production, would be stupid. Automatically reverting to the previously working configuration if a system starts failing within the first five minutes after updating to a new configuration isn't rocket science. But doing it at scale isn't entirely trivial either.
I have worked at Google in the past, so I know which system this might have been. But realistically at the speed Google is moving, the system I know from back then would probably have been replaced a couple of times since then. And I know some sorts of conditions, which trigger rarely enough, that you are never going to catch them in testing. I have had to debug a bug, which happened only one time out of about 10^12, because it required an unusual behaviour from the hardware, to trigger the bug.
The goal is to gradually ramp up to the point where it becomes a serious option for regular voters to consider.
The problem is, that with the number of election cycles this ramp up would take, it is hard to reach that goal within a lifetime.
A ballot with a first and second priority would cut down on the number of cycles needed and be much more democratic. The idea is that you can place your first priority vote on whoever you really believe in. From the remaining candidates find the two you think will get the highest number of votes, and place your second priority vote on one of those two candidates.
You don't have to worry about your vote being lost due to the first priority not getting near the required number of votes. If that happens, your second priority vote would be the one that counts. Now if a new candidate comes along and is preferred by the majority of voters, but nobody wants to run the risk of losing their vote by voting for the new candidate, they can all vote for him as first priority and one of the established candidates as second priority. In such a situation a new candidate can have a chance of getting elected in their first election.
In the beginning, I think a majority would vote for one of the two established candidates as their first priority, but I do not think that a majority of voters would put the other established candidate as their second priority. So there is most likely going to be a much more clear picture of which of the other candidates would be viable in the next election. So even if a new candidate isn't an obvious choice in his first election, there is almost always going to be some candidate who got a decent number of second priority votes in the previous election.
So not only is there a chance of getting elected the first time around, it will only take two elections for somebody to look like a viable candidate, and once a candidate starts looking viable it is easier to get elected without being one of the two established candidates.
The main problem is, it doesn't seem any of the established candidates want to make the system more democratic.
Historically speaking, discreetly reporting a vulnerability usually lands on deaf ears. If you make more noise about it, it you'll most likely end labeled with some malicious tag that the courts love to use to prosecute helpful people for putting a company in a bad light for their lax security.
This has indeed happened multiple times in the past. But none of the cases I know of were from a company, which was offering a bug-bounty. Has any company made such a dirty move after publicly announcing a bug-bounty program?
Not as long as people vote for the lesser evil and thinks that a vote for someone that doesn't win is "a lost vote".
A vote is not lost, just because you voted for somebody who did not win. But the vote is lost, if you by moving it from your second priority to your first priority actually cause your second priority to lose the election to your third priority. (The pattern repeats if there are more than three options, it just gets a bit more messy.)
That term is itself a symptom of broken system. The system is designed in a way where a rational voter cannot have more than two options to choose from. If you vote for one of the two established options, you have a chance of influence over which of the two will win. If you vote for anybody else, one of the two established candidates still wins, and your vote had no influence over which of them.
Usually some voters will think both options suck so much, it is not worthwhile voting for any of them. There is a tendency for those voters to converge on one third candidate. The exact mechanism causing those voters to converge on one candidate is not entirely clear to me. For a start, I don't know how many of them realize they are putting the choice of a winner in the hands of other voters, and how many of them do realize but rationalize, that they'd rather send a signal by voting for a third candidate than have a tiny amount of real influence.
The difficulty of port forwarding is entirely because of IPv4 address scarcity
I am wondering if an approach similar to what I am doing on this service, could be applied to RDP as well. If anybody with more knowledge about RDP than me would chime in, I'd love to be educated on what is possible with RDP, and what is not. Can it be deduced from the traffic an RDP client sends to an IPv4 address, which machine it wants to communicate with? If that is possible, then a listener on that port could forward it to the intended host.
Apparently, the elemental unit of Bitcoins has fallen below 70 cents.
Given that a Satoshi is 10^-8 bitcoins, what you are saying is, the value of a Bitcoin has fallen below 70 million dollars. I don't think anybody ever traded one bitcoin for such a high price.
The value of a Bitcoin has not fallen below 70 million dollars, it was never that high in the first place.
The value of a Satoshi has not fallen below 70 cents, it was never that high in the first place.
Such a high price would have implied the size of the entire Bitcoin economy was worth 1.47e15 dollars.
Not very likely. It is more likely the price will stabilize at some level, and there will still be investors buying and selling based on their best guesses about what that level will be. And regardless of what that level will be, there is a use for an electronic currency for some trades, which will keep happening regardless of what the price is.
At the very least, if they can peg the value of bitcoins so low that there's only tens or hundreds of millions of dollars in them, then it's only a fraction of the economy--it's simply not big enough to supply the economy: everyone in the US would have like a dollar.
The US is not that large a fraction of the world population. Bitcoin may very well be used for trades crossing borders. If any significant fraction of the world population has a non-zero amount of bitcoins, the price will never drop that low. People wouldn't spend their entire bitcoin account on something, they could have bought for a dollar or less. Having bitcoins spread across that many people would in itself push the price above the level you suggest. Moreover, if the entire bitcoin economy would be that small, it would be essentially risk free for any large shopping chain to accept bitcoins. That is due to the fact, that they couldn't possibly lose more money that way than the entire worth of the bitcoin economy. If they simply keep the received bitcoins and only sell them at exchanges if they can get a slightly higher rate, then in the worst case they end up holding all the bitcoins and having lost only the small value you suggest bitcoin would have at that point. But in doing so, the shopping chain would have gotten more publicity than they could possibly have bought for that amount of money.
Of course they're more interested in crashing bitcoin.
Do they have a mandate for that, and at what cost? The lower they want to draw the price, the faster their supply of bitcoins runs out. How low do they need the price to go, and for how long, in order for everybody to lose confidence in bitcoin? If they don't manage to cause everybody to lose confidence, then once their supply does run out, the price will start rising again.
Any investor who sees this as a futile attempt at crashing bitcoin is going to want to pick up some of those bitcoins in order to sell them, once the price recovers. Such investors are going to put a lower bound on how far down, they can drive the price. The more money those investors are willing to spend, the less it will be possible to drive price down.
Put differently. If whoever is responsible for selling all of those bitcoins do not attempt to maximize income from them, then that is a missed opportunity for earning money on them, which will be picked up by somebody else. So rather than crashing bitcoin, they are more likely to just hand free money to some opportunistic investors.
If they really want to cause a crash of bitcoin, they need to convert those bitcoins to cash more than once. Perform simultaneous transactions to both convert them to cash and send them through a coin shuffling service. If they manage to pull that off, then that could possibly cause a crash. But I suspect buyers of large numbers of bitcoins are too careful to allow that to happen.
Unfortunately, immigration laws that every single country has makes it almost no harder to find a method to make the jump into another universe in comparison to getting permanent residence in a country you weren't born in.
But imagine making it there only to find that you can't be granted residence anywhere in the universe.
The accretion disk (seemingly) freezes at the emerging event horizon so the black hole never has a chance to form (from the point of view of an outsider).
That still doesn't make sense to me. I get that some particles actually enter an orbit around the black hole, and that the effects of those orbiting particles could be visible. But what about particles on a trajectory, that would cross the event horizon? Their time would slow down from the view of an external observer, but their movement relative to the observer and the black hole would not. The particles would be accelerated towards the event horizon. What happens as seen from the external observer? How does the distance between such a particle and the event horizon change over time?
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you received the email, chances are it was addressed to you. If it was unintentionally addressed to you, then it was still addressed to you.
I consider disclaimers of the kind you quoted to be spam or maybe just a violation of netiquette.
I do however not consider those disclaimers to be legally binding in any way, since they have clearly not been accepted by the recipient of the email. If you have your own mailserver, and you do want to distribute such mails but are worried about the legal implications, then consider the following approach.
Before the mail server starts receiving a mail, it sends information in the human readable part of any of the previous replies to the client, that by sending mail to the server, the sender grant you rights to distribute the email as you see fit, and any legalese in the email itself is void, and by sending an email to the server, you accept the terms provided by the server.
Such a message provided by the server before the email is transferred would be at least as legally binding as the disclaimer in the email itself.
That thought occurred to me some years ago. Whoever created the simulation must have realized continuous matter couldn't be simulated. And the duality is really just a very clever hack to emulate continuous matter.
But if the universe is simulated, would our experience be any different in case the entire state of the simulation was cloned and two parallel instances would continue to produce identical results? And would we feel anything in case one of them were turned off?
If there's an alternate universe that doesn't interact with ours in any manner, by definition, it is out of the realm of science. If there is interaction of sorts, the parallel universes are suddenly part of our universe, again, by definition.
That I agree with.
By the same token, speculating about the goings-on inside the event horizon of a black hole is not science as such theories cannot possibly be tested.
That depends on what those theories say about hawking radiation. Any theory that makes predictions about hawking radiation could in principle be verified. Though in practice verifying the theory could turn out to be very difficult.
In fact, we can never even detect the formation of a black hole because of time dilation, so in a very real sense, black holes cannot possibly exist from the point of view of science.
We have more or less directly observed the gravity of black holes. There are observations of stars orbiting a black hole in this very galaxy. And there are sufficient observations that the mass of that black hole has been computed as well. This got me wondering though. Is the effect of gravity instantaneous, or is it limited by c? If it is instantaneous, that seems to contradict general relativity and causality. But if it is limited by c, then how can a black hole have gravity?
Slashdot Mirror
Any sort of peer-to-peer communication is problematic, if NAT is involved. Lots of the communication you want to do on phones is peer-to-peer in its nature, but actually implementations have often chosen inferior cloud based implementations, simply to work around NAT. Why else would you involve a cloud service, when what you really want to do is to move some data from one phone to another?
Additionally, even communication with cloud based services is problematic when NAT is involved.
Connecting to a cloud service in order to get a notification, once there is a new email or a new chat message is something you often want to do on a phone. But you cannot do that through a NAT, unless you a prepared to send a constant stream of packets to keep a connection tracking entry alive. Now your phone has to wake up every so often just to send another keepalive packet through the NAT. This consumes battery power, it also consumes bandwidth and if everybody does it, it consumes entries on the NAT.
If the NAT does run out of entries for connections, it will have to lower the lifetime of connections. That will lead to applications sending keepalives more frequently, and we are back in the same situation as before, only wasting more battery power and bandwidth.
NAT does not solve that problem, it actually makes it worse. You still have to keep track of the local IP you assigned to the phone if it is behind a NAT. The tracking of the IP address is not any harder just because it is a public address. But by introducing a CGN you introduce the requirement that all the traffic from the phone gets routed through that CGN even as the phone is moving. If you did not have the NAT layer, you only have the challenge of routing packets to the phone as it is moving, there is no need to get it through one particular NAT as well.
Less than two months after RIPE introduced rationing of IPv4 addresses, I one day found my internet connectivity to be totally broken. Turns out the ISP had turned on NAT in my modem (without telling me about it beforehand). They did have a self service page where I could turn NAT off again and get functional internet connectivity again. However some of my devices no longer received any reply from the DHCP server.
I called their support, who said the lack of reply from their DHCP server was due to the network interface on my computer being defective (which was obviously a lie). When I pointed out that their conclusion was directly contradicting the symptoms I had already explained them about, they just hanged up.
Calling their support one more time, I was able to get to a supporter who knew what was going on, and didn't just invent a lie. It turns out they had run out of IPv4 addresses, and were now enforcing a maximum of two devices online per customer regardless of what limit had been in effect previously.
A few days later I called them again asking for native IPv6, which I considered only fair, given that they had taken away some of the IPv4 addresses, which I were using. They promised me native IPv6 before the end of the year. That was in 2012, they still haven't delivered.
Other ISPs are putting all new customers behind CGN unless they pay an extra fee for a static IP address. You'd think they'd give you native IPv6 along with that. But alas, according to the majority of ISPs, there is no shortage of IPv4 addresses in this country, so nobody needs IPv6. And since nobody is buying IPv6 connectivity, the ISPs will not offer it (completely ignoring the fact, that the reason nobody is buying IPv6 connectivity is that the ISPs themselves aren't offering it in the first place).
From what I am told, native IPv6 plus CGN for IPv4 is already fairly common in Germany, but that's not enough to make me want to move across the border. I have yet to hear about ISPs putting customers who previously had a public IPv4 address behind NAT, but I would not be surprised if it happened.
Right. Cause users who don't know the difference between http and https and/or are too lazy to type https:/// in the URL are going to be typing a port number manually, when they enter a URL, just such that they can get an insecure connection. And websites, which care enough about security to support https in the first place are going to bring up a plain http server on a non-standard port number, just to ensure that users who don't want security can send all their traffic over a non-standard port - from a device where the user himself decided to block port 80 in the first place for security reasons.
Being able to run http on other ports has no implication for the security of the proposed setup. Blocking port 80 in order to enforce https is totally sensible, when it is there to protect users, who are not deliberately compromising their own security. An attacker performing a MitM attack cannot force a connection from port 80 onto a different port number, if the connection is blocked before even reaching the Internet.
Even better, use an iptables level REDIRECT to send the connection to a local http server, and have that http server do an HTTP level redirect to equivalent https URL.
Compromising a CA certificate and compromising the certificate of an individual website is two very different situations. On average it is harder to compromise a CA certificate than that of an individual website. But for both types there is variation in difficulty. I have no doubt it is a lot easier to compromise the certificate of the most insecure CA than that of the most secure website. And if you have compromised one single CA certificate, you can use it for most of the active attacks, you want to perform. So it is mostly pointless to go for the certificates of individual websites.
MitM attacks using a compromised CA certificate done by governments is not unheard of. I think it was only a couple of months back I last saw a browser security update to get rid of a CA certificate, which was being abused by a government (in a European country AFAIR).
The point is, that sort of attack is discovered, if performed systematically. And they are mitigated as they happen, but after each mitigation there will still be easy targets among the remaining CAs.
True. Though you could achieve much of the same effect with less needs for infrastructure through certificate pinning.
No amount of snooping on the network would compromise a private key, which never leaves the server in the first place. Thus the only way you could possibly compromise the certificate, would be if you put an invalid public key in the certificate in the first place. Since that would be immediately obvious to any server owner paying enough attention, it is safe to assume that compromising all certificates cannot be done without being detected. If they literally compromised all of them, it would only take one single security aware server administrator to notice it.
This is why we should focus much more on protocols that are secure against passive attacks, but not against active attacks. Systematic passive attacks can be pulled off without detection. Systematic active attacks cannot. Protection against active attacks is much harder and is the reason we have the CA system. It is not that protecting against active attacks is a bad idea, it is just that it is so hard that much communication isn't protected. Opportunistic encryption with security against active attacks could be done without needing certificates. If on top of that you do perform certificate validation on the most critical sites after you have established a connection with only the opportunistic protection, then you do get protection against active attacks. In order for this to make sense, it is important that until you do perform an active attack, you cannot know if the connection has been secured against active attacks.
Both types of connections will benefit by being indistinguishable from the other to a passive adversary.
The connections with only passive security benefits because it is now easier to do encryption, and moreover being indistinguishable from the minority of connections with active security protects you from systematic active attacks. This is because systematic attacks are bound to hit protected connections once in a while, so they cannot go undetected.
The connections with the full active security also benefits because they are now attracting less attention. They will be a minor fraction of a much larger amount of encrypted connections. A passive adversary cannot know which of the connections have active security and are likely to contain the juicy stuff.
That sounds very undemocratic.
I don't know what solution you are referring to. It has been formally proven, that it is impossible. The proof goes roughly like this. If an agreement can be reached in case of 1 failing node out of 3, that implies any 2 nodes can reach an agreement without involving the third. However from this follows, that if communication between the two good nodes is slower than communication between each good node and the bad node, the following can happen:
Each good node communicates with the faulty node, and since they are 2 out of 3, they can reach an agreement without communicating with the other good node. However the faulty node could be sending inconsistent messages to the two good nodes leading to each of the good nodes to believe an agreement has been made on distinct values. Two good nodes reaching a different conclusion is by definition a failure of the system.
Does this sound like an unrealistic scenario? I say it is not unrealistic. First of all, this is the sort of attack you'd perform against a system with moderate protection against inconsistencies. But even without byzantine nodes, it isn't an unlikely failure scenario. First of all assume there is a network split leaving two good nodes on different sides of the split, secondly assume the third node is hosted on a virtualization platform with some automatic recovery. The network split may have separated the host system of the virtualization from the management system, the management system assumes that host is down and spawns a new copy of the node on a different host. Now that node is cloned on both sides of the network split, and each clone is talking with a different good node in your agreement protocol.
The result stating that it is impossible to reach agreement with 1 out of 3 nodes failing can be generalized to talking about subsets of a larger number of nodes. If you take a large number of nodes and split them into three subsets, such that each node is in exactly one of the three subsets, then you cannot design a system, that can survive a failure of all nodes in one of those three subsets if the adversary gets to choose which subset.
For example, if you have a system that can tolerate 1 failure out of 4 nodes, then you could partition the nodes into 3 subsets with 1, 1, and 2 nodes in each subset. The adversary then picks the subset with 2 nodes, and the system fails. This result about subsets can used to directly show the 3t+1 bound.
Correction. It has been shown that in case of up to t errors, it can be solved with 3t+1 Generals/nodes/CPUs/whatever. So if you assume 0 errors, you need only 1 node. If you want to handle 1 error, you need 4 nodes. There is a different result if you assume a failing node stops communicating and never sends an incorrect message, in that case you only need 2t+1. However that assumption is unrealistic, and the Byzantine problem explicitly deals with nodes deliberately sending false messages.
There are advantages to deploying changes, while nobody is using the system. In the case of Google, such a time does not exist. There are also advantages to deploying changes during prime time. First of all, some problems only show up during peak load. If you deploy outside of peak load, and nothing bad happens right away, there is still a risk the system might break next time peak load hits. If the problem doesn't hit you right after making the change, but at a later time, it will not always be clear, what hit you.
There are multiple arguments for and against, the argument that eventually decided what to do was likely this: It is an advantage to deploy changes while the people who know how to fix problems are at work.
Google does test changes in a test environment first. But you can never find every problem in a test environment. Some bugs depend on specific patterns in data and thus shows up in production, even if it worked just fine in testing. Once you know about the exact pattern to reproduce the bug, you can add it to your test data. But you couldn't test for it, before knowing about it. If a human would be able to think about every possible scenario, there wouldn't be bugs in the first place.
Assuming that just because it worked in testing, it will also work in production, would be stupid. Automatically reverting to the previously working configuration if a system starts failing within the first five minutes after updating to a new configuration isn't rocket science. But doing it at scale isn't entirely trivial either.
I have worked at Google in the past, so I know which system this might have been. But realistically at the speed Google is moving, the system I know from back then would probably have been replaced a couple of times since then. And I know some sorts of conditions, which trigger rarely enough, that you are never going to catch them in testing. I have had to debug a bug, which happened only one time out of about 10^12, because it required an unusual behaviour from the hardware, to trigger the bug.
The problem is, that with the number of election cycles this ramp up would take, it is hard to reach that goal within a lifetime.
A ballot with a first and second priority would cut down on the number of cycles needed and be much more democratic. The idea is that you can place your first priority vote on whoever you really believe in. From the remaining candidates find the two you think will get the highest number of votes, and place your second priority vote on one of those two candidates.
You don't have to worry about your vote being lost due to the first priority not getting near the required number of votes. If that happens, your second priority vote would be the one that counts. Now if a new candidate comes along and is preferred by the majority of voters, but nobody wants to run the risk of losing their vote by voting for the new candidate, they can all vote for him as first priority and one of the established candidates as second priority. In such a situation a new candidate can have a chance of getting elected in their first election.
In the beginning, I think a majority would vote for one of the two established candidates as their first priority, but I do not think that a majority of voters would put the other established candidate as their second priority. So there is most likely going to be a much more clear picture of which of the other candidates would be viable in the next election. So even if a new candidate isn't an obvious choice in his first election, there is almost always going to be some candidate who got a decent number of second priority votes in the previous election.
So not only is there a chance of getting elected the first time around, it will only take two elections for somebody to look like a viable candidate, and once a candidate starts looking viable it is easier to get elected without being one of the two established candidates.
The main problem is, it doesn't seem any of the established candidates want to make the system more democratic.
This has indeed happened multiple times in the past. But none of the cases I know of were from a company, which was offering a bug-bounty. Has any company made such a dirty move after publicly announcing a bug-bounty program?
A vote is not lost, just because you voted for somebody who did not win. But the vote is lost, if you by moving it from your second priority to your first priority actually cause your second priority to lose the election to your third priority. (The pattern repeats if there are more than three options, it just gets a bit more messy.)
That term is itself a symptom of broken system. The system is designed in a way where a rational voter cannot have more than two options to choose from. If you vote for one of the two established options, you have a chance of influence over which of the two will win. If you vote for anybody else, one of the two established candidates still wins, and your vote had no influence over which of them.
Usually some voters will think both options suck so much, it is not worthwhile voting for any of them. There is a tendency for those voters to converge on one third candidate. The exact mechanism causing those voters to converge on one candidate is not entirely clear to me. For a start, I don't know how many of them realize they are putting the choice of a winner in the hands of other voters, and how many of them do realize but rationalize, that they'd rather send a signal by voting for a third candidate than have a tiny amount of real influence.
I am wondering if an approach similar to what I am doing on this service, could be applied to RDP as well. If anybody with more knowledge about RDP than me would chime in, I'd love to be educated on what is possible with RDP, and what is not. Can it be deduced from the traffic an RDP client sends to an IPv4 address, which machine it wants to communicate with? If that is possible, then a listener on that port could forward it to the intended host.
Given that a Satoshi is 10^-8 bitcoins, what you are saying is, the value of a Bitcoin has fallen below 70 million dollars. I don't think anybody ever traded one bitcoin for such a high price.
The value of a Bitcoin has not fallen below 70 million dollars, it was never that high in the first place.
The value of a Satoshi has not fallen below 70 cents, it was never that high in the first place.
Such a high price would have implied the size of the entire Bitcoin economy was worth 1.47e15 dollars.
The general anesthesia that gives the most reliable results, sodium thiopental, happens to be the drug the Dutch won't export.
Huh? The story didn't say anything about the Dutch.
Not very likely. It is more likely the price will stabilize at some level, and there will still be investors buying and selling based on their best guesses about what that level will be. And regardless of what that level will be, there is a use for an electronic currency for some trades, which will keep happening regardless of what the price is.
The US is not that large a fraction of the world population. Bitcoin may very well be used for trades crossing borders. If any significant fraction of the world population has a non-zero amount of bitcoins, the price will never drop that low. People wouldn't spend their entire bitcoin account on something, they could have bought for a dollar or less. Having bitcoins spread across that many people would in itself push the price above the level you suggest. Moreover, if the entire bitcoin economy would be that small, it would be essentially risk free for any large shopping chain to accept bitcoins. That is due to the fact, that they couldn't possibly lose more money that way than the entire worth of the bitcoin economy. If they simply keep the received bitcoins and only sell them at exchanges if they can get a slightly higher rate, then in the worst case they end up holding all the bitcoins and having lost only the small value you suggest bitcoin would have at that point. But in doing so, the shopping chain would have gotten more publicity than they could possibly have bought for that amount of money.
Do they have a mandate for that, and at what cost? The lower they want to draw the price, the faster their supply of bitcoins runs out. How low do they need the price to go, and for how long, in order for everybody to lose confidence in bitcoin? If they don't manage to cause everybody to lose confidence, then once their supply does run out, the price will start rising again.
Any investor who sees this as a futile attempt at crashing bitcoin is going to want to pick up some of those bitcoins in order to sell them, once the price recovers. Such investors are going to put a lower bound on how far down, they can drive the price. The more money those investors are willing to spend, the less it will be possible to drive price down.
Put differently. If whoever is responsible for selling all of those bitcoins do not attempt to maximize income from them, then that is a missed opportunity for earning money on them, which will be picked up by somebody else. So rather than crashing bitcoin, they are more likely to just hand free money to some opportunistic investors.
If they really want to cause a crash of bitcoin, they need to convert those bitcoins to cash more than once. Perform simultaneous transactions to both convert them to cash and send them through a coin shuffling service. If they manage to pull that off, then that could possibly cause a crash. But I suspect buyers of large numbers of bitcoins are too careful to allow that to happen.
But imagine making it there only to find that you can't be granted residence anywhere in the universe.
That still doesn't make sense to me. I get that some particles actually enter an orbit around the black hole, and that the effects of those orbiting particles could be visible. But what about particles on a trajectory, that would cross the event horizon? Their time would slow down from the view of an external observer, but their movement relative to the observer and the black hole would not. The particles would be accelerated towards the event horizon. What happens as seen from the external observer? How does the distance between such a particle and the event horizon change over time?
If you received the email, chances are it was addressed to you. If it was unintentionally addressed to you, then it was still addressed to you.
I consider disclaimers of the kind you quoted to be spam or maybe just a violation of netiquette.
I do however not consider those disclaimers to be legally binding in any way, since they have clearly not been accepted by the recipient of the email. If you have your own mailserver, and you do want to distribute such mails but are worried about the legal implications, then consider the following approach.
Before the mail server starts receiving a mail, it sends information in the human readable part of any of the previous replies to the client, that by sending mail to the server, the sender grant you rights to distribute the email as you see fit, and any legalese in the email itself is void, and by sending an email to the server, you accept the terms provided by the server.
Such a message provided by the server before the email is transferred would be at least as legally binding as the disclaimer in the email itself.
It'd explain wave particle duality...
Rendering optimisations.
That thought occurred to me some years ago. Whoever created the simulation must have realized continuous matter couldn't be simulated. And the duality is really just a very clever hack to emulate continuous matter.
But if the universe is simulated, would our experience be any different in case the entire state of the simulation was cloned and two parallel instances would continue to produce identical results? And would we feel anything in case one of them were turned off?
That I agree with.
That depends on what those theories say about hawking radiation. Any theory that makes predictions about hawking radiation could in principle be verified. Though in practice verifying the theory could turn out to be very difficult.
We have more or less directly observed the gravity of black holes. There are observations of stars orbiting a black hole in this very galaxy. And there are sufficient observations that the mass of that black hole has been computed as well. This got me wondering though. Is the effect of gravity instantaneous, or is it limited by c? If it is instantaneous, that seems to contradict general relativity and causality. But if it is limited by c, then how can a black hole have gravity?