This would be a great time for Microsoft to get rid of 1001 compatibility fixes for applications that still rely on misfeatures DOS for x86 and will never be recompiled for ARM anyway. Maybe Windows will be able to become stable and secure in this iteration.
No, it wouldn't be easier. Not if the goal is to give people a serious warning about serious security issues. Having such a lowering of the warning level for self-signed certificates would allow for the easiest hacks in the book -- you wouldn't even need a rogue CA to generate a fake key.
Challenge/response authentication using a credit card number and PIN as the encryption key. Let the bank issue the challenge, have the e-commerce site pass that right on to the browser. Let the browser do the encryption, and pass it all back to the bank via the site.
It would help if people didn't protect their email list archives behind self-signed SSL certificates. It's a waste of peoples' energy to force them through 3 clicks to allow access to a site when nobody cares if that site is secure or not. And it cuts down on the number of times real security is in order too.
Offtopic? I think I should clarify. I may very well be that the thing that makes OpenBSD's process work in six-month intervals is not only the release management practices, but also whatever they do to avoid security problems in the first place.
There's also a fourth category to consider: embarassing or legally problematic, for example, something like a diary. This is data that, though important, is less important than the damage it can cause if it gets out, and you may prefer to lose it over letting it out of your one primary computer). Though you seem to have that covered by encrypting your backups, there may be data that's too sensitive for that.
We must lay out the kinds of failures and goals of a backup to determine how best to back up.
1. We would like to protect against mechanical drive failure. This can be done with a RAID.
1.5. We may also want to protect against the failure of other components of the computer. I recently had a computer die because its motherboard died, and it took about two weeks to get a new computer, and the new computer was a significant upgrade so it had SATA instead of IDE. In the mean time, I needed my data on other systems, and when the new computer came, I needed to borrow a USB-IDE bridge to recover some stuff that I wasn't backing up.
2. We would like to protect against accidental deletion of files, file corruption, or edits to a file that we have now reconsidered. This can be done with snapshotting. In source code, to reconsider and edit to a file is fairly common, and is the reason why most programming projects use revision control systems. Other options like nilfs or ZFS snapshots can also fill this goal. This goal is accomplished more easily if the backups area automatic and the backup device is live on the system.
Depending on your needs, this goal may be counterbalanced by a need to not retain the history of files for legal or other reasons, and this should inform your choice of backup strategy.
3. We would like to protect against filesystem corruption, whether by an OS bug, or by accidentally doing cat/dev/random >/dev/hda. This can be done by having an extra drive of some sort that isn't normally hooked up to the computer. Tape drives, CDs, and DVDs have traditionally fulfilled this purpose, and this is where the use of additional hard drives is being suggested. Remote backups, via rsync can also accomplish this. For this I use git.
4. We would like to protect against natural disasters. For someone living in New Orleans, it would be nice to have a backup somewhere outside the path of Hurricane Katrina. Remote backups may be pretty much the only way to accomplish this, unless you're a frequent traveler and can hand-deliver backup media to remote locations.
5. In addition to any of the above, the code you use create said backup may be buggy, or may become buggy or misconfigured over time. Checking the integrity and restorability of your backups after creating them, and keeping several (independent) previous versions of a backup may help here.
You may not be concerned with the various modes of failure described here occuring simultaneously. For example, it may be unlikely that you need to deal with file system corruption at the same time that you regret one of the edits you made on your file. In that case, your offline backup device doesn't need to hold all of your snapshots.
This sounds a lot like Debian's release process. Debian's primary release delays in the past have been infrastructure issues rather than software stability issues -- things like getting the right set of architectures on their mirrors, or getting security infrastructure set up for the new release.
I may very well be that the thing that makes this work is not only the release management practices, but also whatever they do to avoid security problems in the first place.
In any election that lets people vote from anywhere, votes can be coerced with a gun, and people can show their actual vote to whatever corrupt mafioso wants to force their vote. These things are not possible (or at least they're more difficult) if the only places to vote are properly run, properly secure polling places.
I use a constellation of git repositories, and Joey Hess' mr tool to synchronize all of them. I have no automated commits -- I just remember to commit and update manually daily.
What if they just invented the list of machine names as a hoax, how would anyone know that these hackers have been successful? What kind of proof is there that this was an actual computer hack, and not just a consumer panic hack by someone who has no access to T-Mobile's network?
Microsoft's strategy lately has been to create a product, with the expectation that it will succeed big, but undermine it by using their product as a way to enforce the will of some authority (rightly or not) against the consumer's will.
Remember the Zune and "Music the way it wants to be", which would enforce DRM on even freely downloaded songs when sharing them with other users? They never did figure out that "music the way you want it to be" would be a better selling point.
I'm going to venture to guess that even if it doesn't, but it's close enough, we can consider that passing. Remember, the Acid1 test gave an explicit exception "All 100%-conformant CSS1 agents should be able to render the document elements above this paragraph indistinguishably (to the pixel) from this reference rendering, (except font rasterization and form widgets)." While I imagine the font rasterization requirements for Acid3 are more stringent (since a font is provided), close-enough counts when dealing with patented portions of TrueType font specifications.
This might be a case where we need to get to copyright reform one step at a time. To approve Google's deal would transform the way society relates to books, and transform the way people relate to dealing with orphaned copyrights. This could make the next step either be a competitor securing the same rights, or legislative changes to allow competitors to do the same thing.
At least in the US, the house and senate typically assume the presence of a quorum unless someone calls for quorum and demonstrates that there isn't a quorum. However, any one congressman can do that. I wonder why one of the opponents didn't do that in France.
No, no, no... The first computer to have true AI was the Descartes 1. It thought therefore it was. When you turned it off, it stopped thinking, therefore it wasn't, and you had to go out and buy a new one the next time you wanted to use it.
But the Anonymous Coward has so many different posts on so many subjects that it's hard to understand what his motive would be in posting all of them....
Oh, never mind. They just discovered that it was contaminated cotton swabs.
Slashdot Mirror
Please patent it, Apple. Then I can buy my cell phone from someone else and know that this technology isn't included.
They were just trying to make Spot the Fed a little easier!
This would be a great time for Microsoft to get rid of 1001 compatibility fixes for applications that still rely on misfeatures DOS for x86 and will never be recompiled for ARM anyway. Maybe Windows will be able to become stable and secure in this iteration.
No, it wouldn't be easier. Not if the goal is to give people a serious warning about serious security issues. Having such a lowering of the warning level for self-signed certificates would allow for the easiest hacks in the book -- you wouldn't even need a rogue CA to generate a fake key.
Challenge/response authentication using a credit card number and PIN as the encryption key. Let the bank issue the challenge, have the e-commerce site pass that right on to the browser. Let the browser do the encryption, and pass it all back to the bank via the site.
It would help if people didn't protect their email list archives behind self-signed SSL certificates. It's a waste of peoples' energy to force them through 3 clicks to allow access to a site when nobody cares if that site is secure or not. And it cuts down on the number of times real security is in order too.
Offtopic? I think I should clarify. I may very well be that the thing that makes OpenBSD's process work in six-month intervals is not only the release management practices, but also whatever they do to avoid security problems in the first place.
There's also a fourth category to consider: embarassing or legally problematic, for example, something like a diary. This is data that, though important, is less important than the damage it can cause if it gets out, and you may prefer to lose it over letting it out of your one primary computer). Though you seem to have that covered by encrypting your backups, there may be data that's too sensitive for that.
We must lay out the kinds of failures and goals of a backup to determine how best to back up.
1. We would like to protect against mechanical drive failure. This can be done with a RAID.
1.5. We may also want to protect against the failure of other components of the computer. I recently had a computer die because its motherboard died, and it took about two weeks to get a new computer, and the new computer was a significant upgrade so it had SATA instead of IDE. In the mean time, I needed my data on other systems, and when the new computer came, I needed to borrow a USB-IDE bridge to recover some stuff that I wasn't backing up.
2. We would like to protect against accidental deletion of files, file corruption, or edits to a file that we have now reconsidered. This can be done with snapshotting. In source code, to reconsider and edit to a file is fairly common, and is the reason why most programming projects use revision control systems. Other options like nilfs or ZFS snapshots can also fill this goal. This goal is accomplished more easily if the backups area automatic and the backup device is live on the system.
Depending on your needs, this goal may be counterbalanced by a need to not retain the history of files for legal or other reasons, and this should inform your choice of backup strategy.
3. We would like to protect against filesystem corruption, whether by an OS bug, or by accidentally doing cat /dev/random > /dev/hda. This can be done by having an extra drive of some sort that isn't normally hooked up to the computer. Tape drives, CDs, and DVDs have traditionally fulfilled this purpose, and this is where the use of additional hard drives is being suggested. Remote backups, via rsync can also accomplish this. For this I use git.
4. We would like to protect against natural disasters. For someone living in New Orleans, it would be nice to have a backup somewhere outside the path of Hurricane Katrina. Remote backups may be pretty much the only way to accomplish this, unless you're a frequent traveler and can hand-deliver backup media to remote locations.
5. In addition to any of the above, the code you use create said backup may be buggy, or may become buggy or misconfigured over time. Checking the integrity and restorability of your backups after creating them, and keeping several (independent) previous versions of a backup may help here.
You may not be concerned with the various modes of failure described here occuring simultaneously. For example, it may be unlikely that you need to deal with file system corruption at the same time that you regret one of the edits you made on your file. In that case, your offline backup device doesn't need to hold all of your snapshots.
This sounds a lot like Debian's release process. Debian's primary release delays in the past have been infrastructure issues rather than software stability issues -- things like getting the right set of architectures on their mirrors, or getting security infrastructure set up for the new release.
I may very well be that the thing that makes this work is not only the release management practices, but also whatever they do to avoid security problems in the first place.
Could you share more information about this cheapo legal insurance plan, or others like it?
In any election that lets people vote from anywhere, votes can be coerced with a gun, and people can show their actual vote to whatever corrupt mafioso wants to force their vote. These things are not possible (or at least they're more difficult) if the only places to vote are properly run, properly secure polling places.
I use a constellation of git repositories, and Joey Hess' mr tool to synchronize all of them. I have no automated commits -- I just remember to commit and update manually daily.
What if they just invented the list of machine names as a hoax, how would anyone know that these hackers have been successful? What kind of proof is there that this was an actual computer hack, and not just a consumer panic hack by someone who has no access to T-Mobile's network?
Microsoft's strategy lately has been to create a product, with the expectation that it will succeed big, but undermine it by using their product as a way to enforce the will of some authority (rightly or not) against the consumer's will.
Remember the Zune and "Music the way it wants to be", which would enforce DRM on even freely downloaded songs when sharing them with other users? They never did figure out that "music the way you want it to be" would be a better selling point.
http://libboard.sourceforge.net/
And the source documents for Islam are out of copyright, available for free, and written in a language that's isn't dead.
So, I'd say Islam has you beat.
The same could be said for Judaism.
Judaism, where all of the really fundemental texts (Such as the Talmud and Zohar) are in Aramaic.
I'm going to venture to guess that even if it doesn't, but it's close enough, we can consider that passing. Remember, the Acid1 test gave an explicit exception "All 100%-conformant CSS1 agents should be able to render the document elements above this paragraph indistinguishably (to the pixel) from this reference rendering, (except font rasterization and form widgets)." While I imagine the font rasterization requirements for Acid3 are more stringent (since a font is provided), close-enough counts when dealing with patented portions of TrueType font specifications.
Why is it at all interesting that an incomplete JS implementation has gotten less incomplete? Don't bother us until they reach 100%.
This might be a case where we need to get to copyright reform one step at a time. To approve Google's deal would transform the way society relates to books, and transform the way people relate to dealing with orphaned copyrights. This could make the next step either be a competitor securing the same rights, or legislative changes to allow competitors to do the same thing.
At least in the US, the house and senate typically assume the presence of a quorum unless someone calls for quorum and demonstrates that there isn't a quorum. However, any one congressman can do that. I wonder why one of the opponents didn't do that in France.
You beat me to the punch. I was just going to point out that SGI is also in on the joke.
No, no, no... The first computer to have true AI was the Descartes 1. It thought therefore it was. When you turned it off, it stopped thinking, therefore it wasn't, and you had to go out and buy a new one the next time you wanted to use it.
But the Anonymous Coward has so many different posts on so many subjects that it's hard to understand what his motive would be in posting all of them. ...
Oh, never mind. They just discovered that it was contaminated cotton swabs.
But wouldn't he make a great detective?