The cert I got was good. Maybe they repurposed some servers around in the pool of servers behind load balancers, and one or more didn't get their certs updated for the new purpose (e.g. changed from "onlinebanking" to "servicing"). Or maybe the OP really did have a MitM attack.
It worked for me. The server certificate I got was valid (issued 2008-10-02, expires 2009-10-15, for "servicing.capitalone.com"). There could be many problems causing this.
One is that the actual server (of many servers they are running through load balancing port redirectors) you connected to doesn't have the right certificate (e.g. they didn't install the new one on all servers... maybe new servers coming online and the update of renewed certificate crossed paths).
Another is that you really are subjected to a man-in-the-middle attack that passed everything through, actually updating your real account. In the mean time your username, password, and financial information, are all recorded (if you have a big enough balance now, you might not have it next week).
Ext4, on the other hand, has another mechanism: delayed block allocation. After a file has been closed, up to a minute may elapse before data blocks on the disk are actually allocated. Delayed block allocation allows the filing system to optimise its write processes, but at the price that the metadata of a newly created file will display a size of 0 bytes and occupy no data blocks until the delayed allocation takes place. If the system crashes during this time, the rename() operation may already be committed in the journal, even though the new file still contains no data. The result is that after a crash the file is empty: both the old and the new data have been lost.
Ext4 developer Ted Ts'o stresses in his answer to the bug report that Ext4 behaves precisely as demanded by the POSIX standard for file operations.
If that is true, then to the extent that is true, POSIX is "broken". Related changes to a file system really need to take place in an orderly way. Creating a file, writing its data, and renaming it, are related. Letting the latter change persist while the former change is lost, is just wrong. Does POSIX really require this behavior, or just allow it? If it requires it, then IMHO, POSIX is indeed broken. And if POSIX is broken, then companies like Microsoft are vindicated in their non-conformance.
If people didn't post those things, we would be no worse off. But the issue isn't about whether they are posted. It isn't even about what is posted. The real issue is that a government can make decisions about what gets blocked, with no transparency, no review, and no acceptance of responsibility. This is the most extreme danger, because it gives a government so much arbitrary power that cannot be challenged.
So they say this is about protecting children. Yet the mechanism they use goes beyond that... far, far beyond that. So clearly, "protecting children" is a mere excuse. This is about government trying to take control over people... adult people.
A proper system would provide for a means of review, including by anyone that chooses to be a reviewer. Clearly, anyone choosing to review this better not be squeamish. There also needs to be a process to challenge this. Anyone reviewing, or impacted, must have a means to have each entry reviewed, with a public openness of the challenge process.
A proper system for protecting children would be focused on children. For example, parents could be required to restrict children to a special internet connection reserved for children, while as adults, they personally can choose to bypass that protection. Mandating these filters for schools is understandable. But for every adult, too? Something is very rotten down under.
How about 12MP for the 4/3 format, 24MP for the APS-C format, and 48MP for the full frame 36x24mm format? And 12 bits per pixel-color for 4/3, 16 bits per pixel-color for APS-C, and 24 bits per pixel-color for 36x24? And how about better video at up to 120 fps in 1920x1080 resolution?
They could interleave cells with ND filters, just as they do with color filters, and use software to un-interleave it. That could help the dynamic range. But using 16-bit per color sensors could help, too. A combination with a 4 stop ND filter might be nice.
Translation: our puny 4/3 format and lens line just can't compete against pro-grade cameras, so we're shifting our focus to the low end consumer cameras.
I have no problem with such a bridge being put in. But Microsoft could pay for the whole thing. They have the cash. So if they won't cover the other $11M, then they should hire as many American software developers as that $11M would pay for, for one year.
This algorithm is effectively to queue up data and let a trigger from a clock decide when to unleash it to the hardware drive. A better way would involve the same queuing, but let the drive going into an idle state trigger unleashing it. Also, don't unleash it all at once; just unleash a bunch of writes that are close to each other. If the drive is idle when a process does write() then the drive starts immediately for that write. In the mean time the process continues unblocked. When the drive is done, if there are any more writes now queued from that process or any others, select something for writing, using a good selection algorithm (elevator, for example), and proceed to write it and keep the drive busy. By the time the clock would have triggered 45 to 120 seconds later, many if not most of the writes processes did via write() calls are now done.
Additionally, there needs to be limits on the number of write pages queued per device and queued overall total. If processes are writing a lot, beyond a certain point, there is little if any gain to massive queuing. Let the writes be blocked for lack of buffers and unblock as soon as a buffer is available (n the order blocked). If the write queue is too large, these small queuing gains will be exceeded by I/O demands forced elsewhere due to memory being taken for use in write queuing. If you force out too much read cache or virtual memory mapping, you drive those I/O rates up in excess of the small gains of massive write queuing.
... working for you if they won't voluntarily follow policies. Sure, you need to make sure someone else doesn't take control of the computer from you and them. But Linux doesn't (yet) have any significant virus issue. If your staff do things against policy, there's plenty of other people out there that would be glad to be doing that job, probably for less.
Self-encrypting hard drives would be a great thing IF they have a flexible and open firmware, with interchangable open source modules for algorithms. After a simple command to pass the key its accessed as a regular drive with no additional overhead for the computer.
With a closed proprietary approach those who need it will be too skeptical to use it, and it may just cause more trouble than it is worth.
And you won't know what else it does with the key, such as encrypting it with the public half of some PKC pair that some non-existing agency generated, and saving that in some unreachable parts of the platter.
If the key or passphrase is coded into the system configuration, the perp can see the data, anyway. So surely they would set up these systems so it is required for the assigned user to enter a passphrase for access, perhaps even periodically instead of just when booting or waking up. Then we are back to the weakness of people. Just flip the laptop over and get the key written on the bottom, or just find out the person's spouse's mother's dog's name.
How do you deal with the key in memory problem? That's right you can't without a hardware keystore, hardware is the only way to get true unbreakable encryption.
However, the hardware could encrypt the key with the public half of a PKC pair, store it in flash, making all your data available without needing to do any breaking at all, to whoever (agencies that don't exist) generated that pair and kept the private half.
You don't even know that your CPU isn't doing that today. It could have some circuitry, or parallel acting firmware, that detects certain common instruction patterns that indicate software encryption is happening, and grab the key just like described above.
How can a security-conscious end-user verify that my data is encrypted on one of these drives, as opposed to simply being stored in the clear and the drive just refusing to read it? Sure seems it'd be cheaper if they just left out the crypto and had the drive lie, taking only a few hundred bytes of extra firmware and no extra processing power to implement the new "encryption" command set. Who's going to know?
This can be done by making the actual encryption completely open, with open source reference implementations in software. The disk drive would have two operating modes. Without a set key, it would write and read the data bits in the raw. With the key set (and stored in the drive controller only in SRAM that's designed to instantly lose the key upon power loss), the drive encrypts writes and decrypts reads. The verification is to set the drive key, write some data, then erase the key, read it back, and decrypt it with the reference software. The reverse verification is to encrypt some data with the reference software, write it when the drive has no key, set the key, read it back, and see if the data is the same as the original.
What cannot be verified is if the drive actually saved the key somewhere in some inaccessible spot on the platter, encrypted by a public key hard coded in the controller ROM, which can be decrypted by whoever has the private half of that PKC pair. THIS is the big risk of using these devices. It is a risk present in any sealed encryption hardware device, even if just a separate encryption core in a CPU or GPU. Government agencies with no names wouldn't care about that, as it would be their key.
65 terabytes of files? Storage space of that magnitude is unfathomable! How many full length movies would that be? 16000 you say? That is still too large for me to process. If I wrote down all the files in 1s and 0s, how many football fields would that occupy?
At the standard Moore's Law rate, if applied to storage, you'll be able to carry all that around in your pocket in 15 years.
Slashdot Mirror
By who?
He's watching Aussies masturbate.
He's watching the Aussies masturbate!
The cert I got was good. Maybe they repurposed some servers around in the pool of servers behind load balancers, and one or more didn't get their certs updated for the new purpose (e.g. changed from "onlinebanking" to "servicing"). Or maybe the OP really did have a MitM attack.
It worked for me. The server certificate I got was valid (issued 2008-10-02, expires 2009-10-15, for "servicing.capitalone.com"). There could be many problems causing this.
http://skapare.ipal.org/servicing.capitalone.com.cert.general.png
One is that the actual server (of many servers they are running through load balancing port redirectors) you connected to doesn't have the right certificate (e.g. they didn't install the new one on all servers ... maybe new servers coming online and the update of renewed certificate crossed paths).
Another is that you really are subjected to a man-in-the-middle attack that passed everything through, actually updating your real account. In the mean time your username, password, and financial information, are all recorded (if you have a big enough balance now, you might not have it next week).
So is this why we can't have voting (where correctness is paramount over performance) systems developed on Linux?
Ext4, on the other hand, has another mechanism: delayed block allocation. After a file has been closed, up to a minute may elapse before data blocks on the disk are actually allocated. Delayed block allocation allows the filing system to optimise its write processes, but at the price that the metadata of a newly created file will display a size of 0 bytes and occupy no data blocks until the delayed allocation takes place. If the system crashes during this time, the rename() operation may already be committed in the journal, even though the new file still contains no data. The result is that after a crash the file is empty: both the old and the new data have been lost.
Ext4 developer Ted Ts'o stresses in his answer to the bug report that Ext4 behaves precisely as demanded by the POSIX standard for file operations.
If that is true, then to the extent that is true, POSIX is "broken". Related changes to a file system really need to take place in an orderly way. Creating a file, writing its data, and renaming it, are related. Letting the latter change persist while the former change is lost, is just wrong. Does POSIX really require this behavior, or just allow it? If it requires it, then IMHO, POSIX is indeed broken. And if POSIX is broken, then companies like Microsoft are vindicated in their non-conformance.
Yeah, I bet you are disturbed ... all that traffic now slowing down your favorite servers.
If people didn't post those things, we would be no worse off. But the issue isn't about whether they are posted. It isn't even about what is posted. The real issue is that a government can make decisions about what gets blocked, with no transparency, no review, and no acceptance of responsibility. This is the most extreme danger, because it gives a government so much arbitrary power that cannot be challenged.
So they say this is about protecting children. Yet the mechanism they use goes beyond that ... far, far beyond that. So clearly, "protecting children" is a mere excuse. This is about government trying to take control over people ... adult people.
A proper system would provide for a means of review, including by anyone that chooses to be a reviewer. Clearly, anyone choosing to review this better not be squeamish. There also needs to be a process to challenge this. Anyone reviewing, or impacted, must have a means to have each entry reviewed, with a public openness of the challenge process.
A proper system for protecting children would be focused on children. For example, parents could be required to restrict children to a special internet connection reserved for children, while as adults, they personally can choose to bypass that protection. Mandating these filters for schools is understandable. But for every adult, too? Something is very rotten down under.
How about 12MP for the 4/3 format, 24MP for the APS-C format, and 48MP for the full frame 36x24mm format? And 12 bits per pixel-color for 4/3, 16 bits per pixel-color for APS-C, and 24 bits per pixel-color for 36x24? And how about better video at up to 120 fps in 1920x1080 resolution?
They could interleave cells with ND filters, just as they do with color filters, and use software to un-interleave it. That could help the dynamic range. But using 16-bit per color sensors could help, too. A combination with a 4 stop ND filter might be nice.
Translation: our puny 4/3 format and lens line just can't compete against pro-grade cameras, so we're shifting our focus to the low end consumer cameras.
I have no problem with such a bridge being put in. But Microsoft could pay for the whole thing. They have the cash. So if they won't cover the other $11M, then they should hire as many American software developers as that $11M would pay for, for one year.
How can Microsoft be expanding their campus when some of the 5000 people they are letting go are in the Seattle area?
This netbook and these development boards are based on the ARM architecture. You can also get ARM on a SODIMM form factor. And this little box looks nice.
This algorithm is effectively to queue up data and let a trigger from a clock decide when to unleash it to the hardware drive. A better way would involve the same queuing, but let the drive going into an idle state trigger unleashing it. Also, don't unleash it all at once; just unleash a bunch of writes that are close to each other. If the drive is idle when a process does write() then the drive starts immediately for that write. In the mean time the process continues unblocked. When the drive is done, if there are any more writes now queued from that process or any others, select something for writing, using a good selection algorithm (elevator, for example), and proceed to write it and keep the drive busy. By the time the clock would have triggered 45 to 120 seconds later, many if not most of the writes processes did via write() calls are now done.
Additionally, there needs to be limits on the number of write pages queued per device and queued overall total. If processes are writing a lot, beyond a certain point, there is little if any gain to massive queuing. Let the writes be blocked for lack of buffers and unblock as soon as a buffer is available (n the order blocked). If the write queue is too large, these small queuing gains will be exceeded by I/O demands forced elsewhere due to memory being taken for use in write queuing. If you force out too much read cache or virtual memory mapping, you drive those I/O rates up in excess of the small gains of massive write queuing.
You mean this?
P = Personal
I = Information
F = File
T = Transfer
S = System
... working for you if they won't voluntarily follow policies. Sure, you need to make sure someone else doesn't take control of the computer from you and them. But Linux doesn't (yet) have any significant virus issue. If your staff do things against policy, there's plenty of other people out there that would be glad to be doing that job, probably for less.
Self-encrypting hard drives would be a great thing IF they have a flexible and open firmware, with interchangable open source modules for algorithms. After a simple command to pass the key its accessed as a regular drive with no additional overhead for the computer.
With a closed proprietary approach those who need it will be too skeptical to use it, and it may just cause more trouble than it is worth.
And you won't know what else it does with the key, such as encrypting it with the public half of some PKC pair that some non-existing agency generated, and saving that in some unreachable parts of the platter.
If the key or passphrase is coded into the system configuration, the perp can see the data, anyway. So surely they would set up these systems so it is required for the assigned user to enter a passphrase for access, perhaps even periodically instead of just when booting or waking up. Then we are back to the weakness of people. Just flip the laptop over and get the key written on the bottom, or just find out the person's spouse's mother's dog's name.
Remember, no matter what the name, if they have to tell you something in the name, the opposite is the reality.
How do you deal with the key in memory problem? That's right you can't without a hardware keystore, hardware is the only way to get true unbreakable encryption.
However, the hardware could encrypt the key with the public half of a PKC pair, store it in flash, making all your data available without needing to do any breaking at all, to whoever (agencies that don't exist) generated that pair and kept the private half.
You don't even know that your CPU isn't doing that today. It could have some circuitry, or parallel acting firmware, that detects certain common instruction patterns that indicate software encryption is happening, and grab the key just like described above.
How can a security-conscious end-user verify that my data is encrypted on one of these drives, as opposed to simply being stored in the clear and the drive just refusing to read it? Sure seems it'd be cheaper if they just left out the crypto and had the drive lie, taking only a few hundred bytes of extra firmware and no extra processing power to implement the new "encryption" command set. Who's going to know?
This can be done by making the actual encryption completely open, with open source reference implementations in software. The disk drive would have two operating modes. Without a set key, it would write and read the data bits in the raw. With the key set (and stored in the drive controller only in SRAM that's designed to instantly lose the key upon power loss), the drive encrypts writes and decrypts reads. The verification is to set the drive key, write some data, then erase the key, read it back, and decrypt it with the reference software. The reverse verification is to encrypt some data with the reference software, write it when the drive has no key, set the key, read it back, and see if the data is the same as the original.
What cannot be verified is if the drive actually saved the key somewhere in some inaccessible spot on the platter, encrypted by a public key hard coded in the controller ROM, which can be decrypted by whoever has the private half of that PKC pair. THIS is the big risk of using these devices. It is a risk present in any sealed encryption hardware device, even if just a separate encryption core in a CPU or GPU. Government agencies with no names wouldn't care about that, as it would be their key.
65 terabytes of files? Storage space of that magnitude is unfathomable! How many full length movies would that be? 16000 you say? That is still too large for me to process. If I wrote down all the files in 1s and 0s, how many football fields would that occupy?
At the standard Moore's Law rate, if applied to storage, you'll be able to carry all that around in your pocket in 15 years.