Did he "willingly" show evidence? Or was he compelled to by a border guard during a border search?
If the encryption key is so analogous to the keys to a safe as everyone seems to think, I'm pretty sure you can't go across the border and refuse to open your safe, can you?
In this case, the court pointed out the police know the location of the evidence they seek and can describe it with reasonable particularity. Elsewhere, I argue that the decryption key to encrypted data is more analogous to the physical location of an object than the key to a safe.
Your argument is nonsense. You say it "could never be incriminating by itself", which is word salad. Something is "incriminating" if together with other things it establishes guilt. The notion of something being "incriminating by itself" is word salad.
By this logic, if a 7-11 is robbed at 8:30PM on 2/11/08, I can be compelled to testify that I was at that 7-11 at 8:30PM on 2/11/08. After all, that can never be incriminating by itself. There's no law against being at a 7-11.
Something is incriminating if it adds to the evidence against you.
Right, but this analogy only works because the keys don't change the contents of the safe. Different keys don't produce different contents.
To make the analogy work, you'd have to make it like this: You show the police what's in your safe. They think they see something that might be drugs and ask to look more closely. You slam the safe shut and throw it on a huge pile of identical safes. The police not only don't know exactly what's in your safe but they don't know which one is yours.
They want you to try your combination on every safe to see which one you can open, so they can prove the contents of that particular safe are yours.
No matter how you open a safe, you find the same contents. But the decryption key changes the contents.
All I'm trusting them to do is verify the domain. They do that.
Making it harder to get any certificate at all just means that less traffic will be encrypted. That's a much worse problem than man-in-the-middle attacks.
Hehe, yeah. I mean RAID 1. But then, the same is true for RAID 5, RAID 6, RAID 10, and on down the line. In fact, I can put it this simply -- RAID is not backup. It's fault-tolerance.
The whole point of a backup is that it is *stable*. Neither copy is stable, so there is no "backup on the hardware level". There are two active systems.
If you cannot restore an accidentally-deleted file from it, it's not a backup.
It is a serious mistake to use the term "backup" in relation to a RAID 0 array. There is only one correct way you can do that, "either disk can serve as a backup for the other, should its media fail".
Either disk can serve as a backup for the other *drive*. However, there is no backup copy of the data. It is *not* a backup solution. There is no backup.
There is, however, fault-tolerance. A media fault can be tolerated. But if the active copy of the data is corrupted, there is no backup.
"WTF ? A transaction is either committed or not comitted... how can a transaction be "half-comitted", while other users are trying to access the same data supposedly under the impression that they are seeing the state of the database either before or after (but NOT in the middle) of any other transaction ?"
By "committed", he means written to the main database, rather than just log or journal files. Since it will take more than one write to the main database to complete a typical transaction, there can always be transactions that are "half-committed" in this sense.
What makes transactional databases reliable is that they use multi-phase commits. And they can overlap the phases of multiple commits.
It sounds counter-intuitive, but because the commit is done in multiple phases, the database can fully recover from a crash that occurs in, at, or between any phase or phases.
"The problem is that there is no reason why the vast majority of HTTP communications should be unencrypted as they are today."
The problem is that HTTPS is not cache-friendly. Is there really a reason why every single one of my 8 computers should download its own copy of a 100MB operating system update? (I live in the mountains and have lousy Internet access.)
This is not SSL's fault. But unfortunately, SSL and HTTP are not well-integrated. There is no way to tell what encrypted data is public and what isn't -- you can only secure your bank transactions by assuming all data is private, and that's horribly inefficient.
"Would you care to elaborate on how a private company is supposed to compete for trust and profit at the same time, without sacrifying one for the other?"
You can't sacrifice trust for profit if you're in the trust business. All you have to sell is the trust people have in you. Give that away and you have nothing to sell.
"I've always treated drive mirroring as fail-over redundancy. If the primary drive fails, use the mirrored copy..."
No, you've got it wrong. There is no "primary drive". RAID 0 treats both drives precisely the same. Reads are distributed evenly over both both drives and all writes go to both drives.
Because there is no primary, it follows that there is no backup. A backup would be the one that you weren't using or changing constantly.
RAID 0 does not create a primary and backup. It creates a dual-active system. It provides fault tolerance (if one drive fails, data can still be read from and written to the other), but it doesn't provide any backup at all.
If this is them, it could definitely be an LS60 bug. GMT time went from 23:59:59 to 23:59:60, which can cause some software to think there are -1 seconds left in the year.
When the SAN supports snapshotting and remote synchronization. However often you want, you snapshot the SAN and synch the image to a remote SAN over your WAN.
If mirroring is a backup solution, which copy is the backup? Dual-active is not backup, it's fault tolerance. But thanks for playing.
Re:That's what you get... for not using FedEx
on
USPS Server Meltdown
·
· Score: 1
"To be fair, what sort of "backup" calculation would you have done here, short of reverse-engineering the USPS algorithm for calculating shipping rates?"
I'm sorry, we are unable to calculate your USPS shipping cost at this time. Would you like to: 1) Accept the shipping without knowing the cost. 2) Select a different shipping option. 3) Have us contact you when we know your shipping cost. 4) Accept shipping up to a selected amount and have us contact you if the actual amount is higher? 5) Cancel your order for now, leaving these items in your shopping cart so you can order them later.
"While in principle I agree with that, what are they supposed to do? They are quoting you a price for a service they don't provide themselves."
Fail gracefully. For example, state that they are unable to price that shipping option at that time. Offer you to accept the option without knowing the price, select another type of shipping, or get an email when they know.
Designing software to gracefully handle external failures is a vital real-world programming skill.
"Looks like you misread. I said routers drop packets (before total congestion), TCP endpoints detect and react by cutting speed in half which gives slower TCP streams a chance to rise to equilibrium."
I understand that, and I agree with this. However, this says nothing whatsoever about UDP. In this case, the exact same thing will happen with UDP. The routers will drop the packets early (because they do not treat UDP differently from TCP) and the UDP endpoints will backoff (because they will be programmed to do so).
"Yes it can backoff; if the routers dropped UDP packets the same way they dropped TCP packets. But they don't, so there's your problem."
Yes, they do. At least, they should. RED is not as effective for UDP as it is for TCP (as many UDP flows are not responsive) but that is not a good reason to exempt UDP from RED just because it might not be responsive.
If there are people out there who exempt UDP from RED, independent of any QoS indication that the packets are precious and not in limited internal networks where it is known that UDP traffic is precious, they should fix their networks.
"There's another good reason to do this because it balances out the load between single-flow TCP applications. When a TCP end-point backs off to 50%, it's giving a new TCP flow a chance to take up the slack and speed up until the two TCP flows reach a state of equilibrium. UDP end points lack this behavior."
You have this completely backwards. TCP endpoints can only detect congestion through packet loss on the connection. UDP endpoints are free to back off for *any* reason, including but not limited to packet loss.
Because every TCP connection is basically independent, you cannot use information gained from one connection to backoff on another. With UDP you can.
A UDP application can backoff as aggressively as TCP, less aggressively, or more aggressively. Nobody yet knows how BT will rig its backoff algorithm.
They've hinted that it will backoff even more aggressively than TCP does, using congestion information from one connection to increase how severely they treat congestion information from other connections.
They've also hinted that they'll rig BitTorrent to act *in* *total* much like as single TCP connection, rather than like hundreds. This is good for the user, as using BT won't make his web pages and games get 1/100th of his bandwidth but 1/2, like they should. But it's also good for Internet's core, as one BT client looks more like one connection than hundreds there too.
"As for Richard Bennett's claim that UDP isn't generally dropped by routers,..."
I don't even see where Bennett claimed that. And I've counter-claimed that routers generally treat UDP and TCP precisely the same. I believe this is a mis-statement of Bennett's claim. Can you cite any public claim of his to this effect?
I think Bennett was simply assuming that their motive was evil -- to get around congestion control -- rather than benign -- to fix a defect in TCP that it treats each connection as the distribution unit rather than each application. (Which is bad when an application with 100 connections tries to live on the same connection as one with two.)
The reason you drop TCP or UDP packets is not to produce a response from the end-points. It's because the link is congested and you simply can't carry all the traffic. Well-behaved applications, both TCP and UDP, respond to packet loss by reducing their bandwidth consumption.
"I know the man we have spoken by phone and in person."
Well, you've now set the bar impossibly high. In order to satisfy you, I have to refute a claim to which I have no access based on evidence and argument to which I have no access.
The truth is, so long as a protocol layered on top of UDP detects congestion and responds with appropriate backoff, it will be just as Internet core friendly as TCP.
Richard Bennett never said that Internet core routers do not treat UDP and TCP the same. You are misunderstanding what he is saying.
I am not asking you to trust me over Richard Bennett. I am asking you to not misrepresent Richard Bennett's argument.
*Your* statement -- "The client application can't know about congestion in the core of the network, so it breaks control at the core of the Internet where there's less management. If you read the article fully, this would have been apparent." -- is a misrepresentation of Bennett's argument. In fact, the client can know about congestion in the core of the network with UDP the same way it does with TCP, by inferring congestion when there is packet loss. TCP's congestion control is implemented by the endpoints, not the network core. (With the exception of ECN, but that's so rarely used that it doesn't really matter.)
"Routers and other network devices typically don't drop UDP packets because UDP end points don't respond like TCP end points which halve their bandwidth whenever a packet isn't delivered."
That's simply not true. Routers and other network devices typically treat UDP and TCP precisely the same.
"It's also hasn't been necessary to drop UDP packets because traditional UDP applications are typically small bursts of data or low/fixed bandwidth applications like VoIP and online gaming."
Nevertheless, they've dropped them the same way they've dropped TCP packets. They do this simply because there has not been (and still is not) any good reason to treat TCP packets differently from UDP packets.
"Now this is all about to change when you get a huge bulk transfer application like BitTorrent which accounts for a significant portion of the Internet's traffic."
Nothing will change. The traffic will be UDP instead of TCP, and routers won't care one way or the other, just as they never have.
The only devices that will be affected are unusual "invasive" devices, such as those specifically used to throttle P2P.
You're just making that up, and it makes no sense. The "core of the Internet" can regulate TCP traffic and UDP traffic precisely the same way, by dropping packets. And that's exactly what it can and will do with no changes.
The "core of the network" treats each packet as its own universe. It looks at the source, destination, and perhaps packet size and type of service, and that's it. It doesn't care if it's TCP or UDP.
Slashdot Mirror
Did he "willingly" show evidence? Or was he compelled to by a border guard during a border search?
If the encryption key is so analogous to the keys to a safe as everyone seems to think, I'm pretty sure you can't go across the border and refuse to open your safe, can you?
In this case, the court pointed out the police know the location of the evidence they seek and can describe it with reasonable particularity. Elsewhere, I argue that the decryption key to encrypted data is more analogous to the physical location of an object than the key to a safe.
Your argument is nonsense. You say it "could never be incriminating by itself", which is word salad. Something is "incriminating" if together with other things it establishes guilt. The notion of something being "incriminating by itself" is word salad.
By this logic, if a 7-11 is robbed at 8:30PM on 2/11/08, I can be compelled to testify that I was at that 7-11 at 8:30PM on 2/11/08. After all, that can never be incriminating by itself. There's no law against being at a 7-11.
Something is incriminating if it adds to the evidence against you.
Right, but this analogy only works because the keys don't change the contents of the safe. Different keys don't produce different contents.
To make the analogy work, you'd have to make it like this: You show the police what's in your safe. They think they see something that might be drugs and ask to look more closely. You slam the safe shut and throw it on a huge pile of identical safes. The police not only don't know exactly what's in your safe but they don't know which one is yours.
They want you to try your combination on every safe to see which one you can open, so they can prove the contents of that particular safe are yours.
No matter how you open a safe, you find the same contents. But the decryption key changes the contents.
All I'm trusting them to do is verify the domain. They do that.
Making it harder to get any certificate at all just means that less traffic will be encrypted. That's a much worse problem than man-in-the-middle attacks.
Hehe, yeah. I mean RAID 1. But then, the same is true for RAID 5, RAID 6, RAID 10, and on down the line. In fact, I can put it this simply -- RAID is not backup. It's fault-tolerance.
"Either can do the job so one is a backup..."
Which one is the backup?
The whole point of a backup is that it is *stable*. Neither copy is stable, so there is no "backup on the hardware level". There are two active systems.
If you cannot restore an accidentally-deleted file from it, it's not a backup.
It is a serious mistake to use the term "backup" in relation to a RAID 0 array. There is only one correct way you can do that, "either disk can serve as a backup for the other, should its media fail".
Either disk can serve as a backup for the other *drive*. However, there is no backup copy of the data. It is *not* a backup solution. There is no backup.
There is, however, fault-tolerance. A media fault can be tolerated. But if the active copy of the data is corrupted, there is no backup.
"WTF ? A transaction is either committed or not comitted ... how can a transaction be "half-comitted", while other users are trying to access the same data supposedly under the impression that they are seeing the state of the database either before or after (but NOT in the middle) of any other transaction ?"
By "committed", he means written to the main database, rather than just log or journal files. Since it will take more than one write to the main database to complete a typical transaction, there can always be transactions that are "half-committed" in this sense.
What makes transactional databases reliable is that they use multi-phase commits. And they can overlap the phases of multiple commits.
It sounds counter-intuitive, but because the commit is done in multiple phases, the database can fully recover from a crash that occurs in, at, or between any phase or phases.
So what do you do? You have two choices:
1) Quit.
2) Go down with the ship.
If you pick 2, you're just as responsible.
"You may think it is your job to convince the boss, but often the boss either doesn't care, doesn't have a clue, or can't do anything about it."
Yes, it is your job. And if you can't do your job (whether it's your fault or not) you're in the wrong job.
"The problem is that there is no reason why the vast majority of HTTP communications should be unencrypted as they are today."
The problem is that HTTPS is not cache-friendly. Is there really a reason why every single one of my 8 computers should download its own copy of a 100MB operating system update? (I live in the mountains and have lousy Internet access.)
This is not SSL's fault. But unfortunately, SSL and HTTP are not well-integrated. There is no way to tell what encrypted data is public and what isn't -- you can only secure your bank transactions by assuming all data is private, and that's horribly inefficient.
"Would you care to elaborate on how a private company is supposed to compete for trust and profit at the same time, without sacrifying one for the other?"
You can't sacrifice trust for profit if you're in the trust business. All you have to sell is the trust people have in you. Give that away and you have nothing to sell.
"The only entity that doesn't have to make money--your governments." It's also the entity that suffers the least for its mistakes.
"I've always treated drive mirroring as fail-over redundancy. If the primary drive fails, use the mirrored copy..."
No, you've got it wrong. There is no "primary drive". RAID 0 treats both drives precisely the same. Reads are distributed evenly over both both drives and all writes go to both drives.
Because there is no primary, it follows that there is no backup. A backup would be the one that you weren't using or changing constantly.
RAID 0 does not create a primary and backup. It creates a dual-active system. It provides fault tolerance (if one drive fails, data can still be read from and written to the other), but it doesn't provide any backup at all.
If this is them, it could definitely be an LS60 bug. GMT time went from 23:59:59 to 23:59:60, which can cause some software to think there are -1 seconds left in the year.
When the SAN supports snapshotting and remote synchronization. However often you want, you snapshot the SAN and synch the image to a remote SAN over your WAN.
If mirroring is a backup solution, which copy is the backup? Dual-active is not backup, it's fault tolerance. But thanks for playing.
"To be fair, what sort of "backup" calculation would you have done here, short of reverse-engineering the USPS algorithm for calculating shipping rates?"
I'm sorry, we are unable to calculate your USPS shipping cost at this time. Would you like to:
1) Accept the shipping without knowing the cost.
2) Select a different shipping option.
3) Have us contact you when we know your shipping cost.
4) Accept shipping up to a selected amount and have us contact you if the actual amount is higher?
5) Cancel your order for now, leaving these items in your shopping cart so you can order them later.
It's that simple.
"While in principle I agree with that, what are they supposed to do? They are quoting you a price for a service they don't provide themselves."
Fail gracefully. For example, state that they are unable to price that shipping option at that time. Offer you to accept the option without knowing the price, select another type of shipping, or get an email when they know.
Designing software to gracefully handle external failures is a vital real-world programming skill.
"Looks like you misread. I said routers drop packets (before total congestion), TCP endpoints detect and react by cutting speed in half which gives slower TCP streams a chance to rise to equilibrium."
I understand that, and I agree with this. However, this says nothing whatsoever about UDP. In this case, the exact same thing will happen with UDP. The routers will drop the packets early (because they do not treat UDP differently from TCP) and the UDP endpoints will backoff (because they will be programmed to do so).
"Yes it can backoff; if the routers dropped UDP packets the same way they dropped TCP packets. But they don't, so there's your problem."
Yes, they do. At least, they should. RED is not as effective for UDP as it is for TCP (as many UDP flows are not responsive) but that is not a good reason to exempt UDP from RED just because it might not be responsive.
If there are people out there who exempt UDP from RED, independent of any QoS indication that the packets are precious and not in limited internal networks where it is known that UDP traffic is precious, they should fix their networks.
"There's another good reason to do this because it balances out the load between single-flow TCP applications. When a TCP end-point backs off to 50%, it's giving a new TCP flow a chance to take up the slack and speed up until the two TCP flows reach a state of equilibrium. UDP end points lack this behavior."
You have this completely backwards. TCP endpoints can only detect congestion through packet loss on the connection. UDP endpoints are free to back off for *any* reason, including but not limited to packet loss.
Because every TCP connection is basically independent, you cannot use information gained from one connection to backoff on another. With UDP you can.
A UDP application can backoff as aggressively as TCP, less aggressively, or more aggressively. Nobody yet knows how BT will rig its backoff algorithm.
They've hinted that it will backoff even more aggressively than TCP does, using congestion information from one connection to increase how severely they treat congestion information from other connections.
They've also hinted that they'll rig BitTorrent to act *in* *total* much like as single TCP connection, rather than like hundreds. This is good for the user, as using BT won't make his web pages and games get 1/100th of his bandwidth but 1/2, like they should. But it's also good for Internet's core, as one BT client looks more like one connection than hundreds there too.
"As for Richard Bennett's claim that UDP isn't generally dropped by routers, ..."
I don't even see where Bennett claimed that. And I've counter-claimed that routers generally treat UDP and TCP precisely the same. I believe this is a mis-statement of Bennett's claim. Can you cite any public claim of his to this effect?
I think Bennett was simply assuming that their motive was evil -- to get around congestion control -- rather than benign -- to fix a defect in TCP that it treats each connection as the distribution unit rather than each application. (Which is bad when an application with 100 connections tries to live on the same connection as one with two.)
The reason you drop TCP or UDP packets is not to produce a response from the end-points. It's because the link is congested and you simply can't carry all the traffic. Well-behaved applications, both TCP and UDP, respond to packet loss by reducing their bandwidth consumption.
"I know the man we have spoken by phone and in person."
Well, you've now set the bar impossibly high. In order to satisfy you, I have to refute a claim to which I have no access based on evidence and argument to which I have no access.
The truth is, so long as a protocol layered on top of UDP detects congestion and responds with appropriate backoff, it will be just as Internet core friendly as TCP.
Richard Bennett never said that Internet core routers do not treat UDP and TCP the same. You are misunderstanding what he is saying.
I am not asking you to trust me over Richard Bennett. I am asking you to not misrepresent Richard Bennett's argument.
*Your* statement -- "The client application can't know about congestion in the core of the network, so it breaks control at the core of the Internet where there's less management. If you read the article fully, this would have been apparent." -- is a misrepresentation of Bennett's argument. In fact, the client can know about congestion in the core of the network with UDP the same way it does with TCP, by inferring congestion when there is packet loss. TCP's congestion control is implemented by the endpoints, not the network core. (With the exception of ECN, but that's so rarely used that it doesn't really matter.)
"Routers and other network devices typically don't drop UDP packets because UDP end points don't respond like TCP end points which halve their bandwidth whenever a packet isn't delivered."
That's simply not true. Routers and other network devices typically treat UDP and TCP precisely the same.
"It's also hasn't been necessary to drop UDP packets because traditional UDP applications are typically small bursts of data or low/fixed bandwidth applications like VoIP and online gaming."
Nevertheless, they've dropped them the same way they've dropped TCP packets. They do this simply because there has not been (and still is not) any good reason to treat TCP packets differently from UDP packets.
"Now this is all about to change when you get a huge bulk transfer application like BitTorrent which accounts for a significant portion of the Internet's traffic."
Nothing will change. The traffic will be UDP instead of TCP, and routers won't care one way or the other, just as they never have.
The only devices that will be affected are unusual "invasive" devices, such as those specifically used to throttle P2P.
Mod this up. This is dead on.
You're just making that up, and it makes no sense. The "core of the Internet" can regulate TCP traffic and UDP traffic precisely the same way, by dropping packets. And that's exactly what it can and will do with no changes.
The "core of the network" treats each packet as its own universe. It looks at the source, destination, and perhaps packet size and type of service, and that's it. It doesn't care if it's TCP or UDP.