That's a good point. If a game on Steam is $20 and I think it's worth $5, I don't pay $20 for it, I wait for a sale when it's $5. So if it was 'pay what you want' I'd pay $5 for it and they'd get my money straight away rather than having to wait for a sale.
Odds are the RSO wouldn't be able to fire the charges in the 100 mS it takes to exceed load limits due to an asymmetrical SRB firing.
Doesn't really matter, because everyone dies either way: the shuttle will crash and burn if it's on the pad with one SRB missing. All you have to do is ensure you destroy the SRB before it goes flying off across Florida and crashes into a bus full of nuns and orphans on their way to Disneyland.
The LOX/LH2 in the shuttle's external tank costs far less than the two SRBs on the side. It's the liquid-fuelled engines that are expensive, if you throw them away after each flight.
We don't invade privacy and remove freedoms because so many people die in traffic accidents.
But we will.
Some politcos are reportedly trying to force auto manufacturers to include rear-view cameras on every new car sold in America. Once that's in place, how long do you think it will be before they're required to install cameras on all four sides of the car, and record video 24/7? 'If it saves only one life', etc.
Now, as someone who does his best to drive safely, I can see that having video of some tailgating idiot crashing into my car could be a good thing when I want to prove the accident wasn't my fault, but I still wouldn't want to be spied on in that way all the time.
Morons, sometimes we are saved because the idiot with an islamist terrorist idea is not that smart - like the timsquare bomber. This moron has made the perfect equipment for them and is now going to sell it as well. This is not so funny.
Absolutely. No-one should be allowed to sell anything that might be useful to a terrorist.
Were they to be used widely, it would be a matter of months before huge numbers of people had their biometric data skimmed with enough resolution that fakes could be constructed with relative ease(imagine the problem of ATM card skimmer devices, already cheap and common, spreading to biometric verification systems: is that "broken" biometric verification setup on the door/atm/whatever actually broken, or transmitting high resolution scans of your fingerprints to some gang even now?) If you do get skimmed, what are you going to do about it?
Don't forget that the US government now has a database of millions of travellers' fingerprints, so they can trivially break online fingerprint biometrics for those people.
As you say, the rush to 'biometric ID' is making 'biometric ID' useless.
The backdoor in question might simply be a guaranteed or determinable byte-sequence in a stream, which could aid in the decoding of said stream. It need not be a simple --with-backdoor option passed on the command line...;)
Except the output of the IPSEC stack has to interoperate with other IPSEC stacks. IPSEC basically takes TCP/IP data, encrypts it and sticks on some headers.... if it doesn't do that the correct way then it's not going to be able to talk to machines using a different stack. Even if it only corrupts a small number of packets, someone's eventually likely to notice that some are getting dropped.
Certainly it could generate poor random keys, or somehow leak private key bits into the key or random padding so that the other end of the connection could extract them. But creating a hole that would allow a third party to easily tap into IPSEC while remaining interoperable and not being obvious wouldn't be easy... of course that means that if it existed it wouldn't be easy to find either.
Read this for an idea, someone hacked in some well crafted code that appeared innocent, had the machine not been hacked it probably would have stayed
That code is neither innocent nor well-crafted. Setting uid to zero is not 'innocent' and using '&& (x = 0)' is not well-crafted since it will always evaluate to false. I don't know whether the compiler will generate a warning in that case, but it should, and while a brief look through the code might miss that it's using = instead of ==, any kind of code review worthy of the name would spot it and flame the developer who wrote it.
Re:The only question I have is
on
Firefox 4 Beta 8 Up
·
· Score: 3, Insightful
Then why doesn't it happen with other browsers?
IE writes to individual files per bookmark, whereas Firefox used to write to one big flat text file which could be several megabytes in size. Chrome presumably learned from Firefox and writes to some kind of database?
Also, any database Firefox might be using it still going to be sitting on top of NTFS and thus prone to the same problem if it really is the fault of the file system.
Sqlite syncs three times every time you update the database, and uses its own journaliing to allow it to recover from corruption.
Sounds more like a bug in Firefox than one with NTFS.
Then why didn't it happen on other file systems? It happened to me often enough that I switched that partition to FAT32 in the end, which could recover from a crash without randomly deleting files.
In the real world it's an interaction between how Firefox was updating its bookmarks file with poor design on Microsoft's part. Firefox would be writing the file numerous times while you were browsing the web, and somehow NTFS would truncate the file to zero bytes if it crashed at the wrong time during that process.
And I'd also add that one time I had NTFS delete a _two gigabyte_ file that I was downloading from the Internet when the power went out. I suspect the problem is somehow related to files which have been created but not closed when the operating system crashes.
Yeah... or implement some sort of signing for a list of allowed extensions.
And how do you plan to do that?
If Mozilla can sign an arbitrary list of extensions automatically, then any other application can, even if it has to go poking around inside the Mozilla executable to extract the signing key.
In other words, it's Mozilla's fault that this is possible, and we're still waiting for a Firefox release that fixes the bug.
How do you plan to allow Mozilla to install per-user addons without allowing other programs to install addons when logged in as the same user?
If Mozilla runs addons in ~/.addons, then anyone can put one there. If Mozilla reads a list of addons from ~/.addons.list, then any program can add one to it. You can only prevent programs from adding addons by preventing users from changing that configuration, which then means they have to be root or some other privileged user in order to install the addons that they want to install.
And the program installer probably runs as root anyway, so that won't make any difference.
Re:Javascript is not the problem, it's the interfa
on
Firefox 4 Beta 8 Up
·
· Score: 1
This is not the interface, it's the SQLite database. Every time you access a page, it has to write to the database.
It doesn't _have_ to write to the database, it chooses to write to the database. I believe it's updating things like the time you last visited the page, which I totally don't care about.
There's more to a browser than rendering and Javascript performance. Firefox has become a hard disk hog. It almost continually writes to disk, which can be very slow
Isn't that because they moved to using sqlite to store bookmarks because NTFS used to eat your entire bookmarks file if Windows crashed? Whereas sqlite syncs multiple times every time you update the database?
Try reading a few more sentences. He states the windows virus problem is mostly resulting from its dominance as a monoculture. That mac or linux would have much more malware than they do now if they had 90% market share.
More than basically nothing, yes. There are sure to be some security holes which would be exploited on unpatched machines.
But Windows has always been insecure by default, whereas Unix has at least tried to be secure by default. Most obviously that any Flash exploit on Windows could own your entire system because you were almost certainly logged in as an admin user, whereas on Unix you need a Flash exploit _and_ a local priviledge exploit to do the same thing.
We could add minor little issues like loading DLLs from the current directory in order not to break some old applications which require it, thereby allowing attackers who can get a DLL into your system in some way to get you to execute it. Deliberately supporting backward compatible security holes is not really a good plan.
Directors, these things don't lend "immediacy" to the shot, they distract us and take us *out* of the moment, and it makes some of us slightly nauseated after a while! Probably not the intended effect.
Indeed. Mel Gibson may be batshit insane, but if you listen to his DVD commentaries he does at least know what he's doing when shooting a fight scene.
It always surprises me upon re-watching to realize just how many computer graphics were used.
What surprised me on watching the movie with the DVD commentary were just how many of what, as a kid, I thought were CG effects were actually hand-drawn in Korean sweatshops.
Self signed certificates are ALWAYS more secure if you can trust the issuer.
How do you trust the issuer when you don't have any way to know who the issuer is?
For instance if I went to my local bank branch and the manager there handed me a key in person and told me to go home and install it to validate their online site, that would be better than the Verisign cert they use now.
Dude, that key was created by an Elbonian hacker who's now going to steal your bank account thanks to his friend at the bank handing it out to customers who are dumb enough to trust a random self-signed certificate that's handed to them.
Ideally, browsers should have three SSL security levels:
Self-signed SSL cert. For the average user, it shouldn't bring up a lock icon, but something different saying the site is using some basic, untrusted cryptography to communicate.
'Average users' are precisely the kind of people who have to be beaten over the head with the fact that they're connecting to a site with a self-signed certificate. Average users typically don't check for a lock icon in the first place, so they're sure as hell not going to check for a self-signed certificate icon.
The real problem is that the entire CA model is fundamentally broken, not that browsers give warnings for certificates that might be OK or might be an Elbonian hacker trying to steal your bank account.
Every browser insisting that a self-signed certificate is less secure than non-encrypted http would probably play a big role in why router manufacturers have chosen hard-coded keys rather than auto-generated ones.
Yeah, because we should allow our browsers to accept a self-signed key for www.mybank.com in order to make life easier for router manufacturers.
Strange. I have three Atoms here and they work fine. I'm going to replace one with an i3 or i5 eventually, but only because it's the MythTV server and the Atom is a bit slow for transcoding.
Of course I'm not trying to use it for playing modern games or editing H.264 HD video.
Slashdot Mirror
That's a good point. If a game on Steam is $20 and I think it's worth $5, I don't pay $20 for it, I wait for a sale when it's $5. So if it was 'pay what you want' I'd pay $5 for it and they'd get my money straight away rather than having to wait for a sale.
Odds are the RSO wouldn't be able to fire the charges in the 100 mS it takes to exceed load limits due to an asymmetrical SRB firing.
Doesn't really matter, because everyone dies either way: the shuttle will crash and burn if it's on the pad with one SRB missing. All you have to do is ensure you destroy the SRB before it goes flying off across Florida and crashes into a bus full of nuns and orphans on their way to Disneyland.
Something I've always wondered, if one of the shuttle's SRBs fails to lit and the other one starts up, what happens?
Everyone dies. And the launch pad is probably destroyed.
This is why the SRBs have multiple (three I think) independent igniters so that only an extremely unlikely failure could make them not ignite.
They are also notoriously simple and inexpensive.
The LOX/LH2 in the shuttle's external tank costs far less than the two SRBs on the side. It's the liquid-fuelled engines that are expensive, if you throw them away after each flight.
We don't invade privacy and remove freedoms because so many people die in traffic accidents.
But we will.
Some politcos are reportedly trying to force auto manufacturers to include rear-view cameras on every new car sold in America. Once that's in place, how long do you think it will be before they're required to install cameras on all four sides of the car, and record video 24/7? 'If it saves only one life', etc.
Now, as someone who does his best to drive safely, I can see that having video of some tailgating idiot crashing into my car could be a good thing when I want to prove the accident wasn't my fault, but I still wouldn't want to be spied on in that way all the time.
Morons, sometimes we are saved because the idiot with an islamist terrorist idea is not that smart - like the timsquare bomber. This moron has made the perfect equipment for them and is now going to sell it as well. This is not so funny.
Absolutely. No-one should be allowed to sell anything that might be useful to a terrorist.
Like cars. Or gas canisters.
Or underwear.
Were they to be used widely, it would be a matter of months before huge numbers of people had their biometric data skimmed with enough resolution that fakes could be constructed with relative ease(imagine the problem of ATM card skimmer devices, already cheap and common, spreading to biometric verification systems: is that "broken" biometric verification setup on the door/atm/whatever actually broken, or transmitting high resolution scans of your fingerprints to some gang even now?) If you do get skimmed, what are you going to do about it?
Don't forget that the US government now has a database of millions of travellers' fingerprints, so they can trivially break online fingerprint biometrics for those people.
As you say, the rush to 'biometric ID' is making 'biometric ID' useless.
The backdoor in question might simply be a guaranteed or determinable byte-sequence in a stream, which could aid in the decoding of said stream. It need not be a simple --with-backdoor option passed on the command line... ;)
Except the output of the IPSEC stack has to interoperate with other IPSEC stacks. IPSEC basically takes TCP/IP data, encrypts it and sticks on some headers.... if it doesn't do that the correct way then it's not going to be able to talk to machines using a different stack. Even if it only corrupts a small number of packets, someone's eventually likely to notice that some are getting dropped.
Certainly it could generate poor random keys, or somehow leak private key bits into the key or random padding so that the other end of the connection could extract them. But creating a hole that would allow a third party to easily tap into IPSEC while remaining interoperable and not being obvious wouldn't be easy... of course that means that if it existed it wouldn't be easy to find either.
Hah, that's just like the government contractor -- write a backdoor into a system that doesn't actually work.
Does this mean that the government can demand their money back?
Read this for an idea, someone hacked in some well crafted code that appeared innocent, had the machine not been hacked it probably would have stayed
That code is neither innocent nor well-crafted. Setting uid to zero is not 'innocent' and using '&& (x = 0)' is not well-crafted since it will always evaluate to false. I don't know whether the compiler will generate a warning in that case, but it should, and while a brief look through the code might miss that it's using = instead of ==, any kind of code review worthy of the name would spot it and flame the developer who wrote it.
Then why doesn't it happen with other browsers?
IE writes to individual files per bookmark, whereas Firefox used to write to one big flat text file which could be several megabytes in size. Chrome presumably learned from Firefox and writes to some kind of database?
Also, any database Firefox might be using it still going to be sitting on top of NTFS and thus prone to the same problem if it really is the fault of the file system.
Sqlite syncs three times every time you update the database, and uses its own journaliing to allow it to recover from corruption.
Sounds more like a bug in Firefox than one with NTFS.
Then why didn't it happen on other file systems? It happened to me often enough that I switched that partition to FAT32 in the end, which could recover from a crash without randomly deleting files.
In the real world it's an interaction between how Firefox was updating its bookmarks file with poor design on Microsoft's part. Firefox would be writing the file numerous times while you were browsing the web, and somehow NTFS would truncate the file to zero bytes if it crashed at the wrong time during that process.
And I'd also add that one time I had NTFS delete a _two gigabyte_ file that I was downloading from the Internet when the power went out. I suspect the problem is somehow related to files which have been created but not closed when the operating system crashes.
Why do you need to tell me you're completely pathetic?
Yeah... or implement some sort of signing for a list of allowed extensions.
And how do you plan to do that?
If Mozilla can sign an arbitrary list of extensions automatically, then any other application can, even if it has to go poking around inside the Mozilla executable to extract the signing key.
You know, you really need to do more work on your slashbot, because what it's posting here makes little sense to a human.
NTFS is a journaling file system. It is unlikely that a system crash would cause data loss on anything that has already been written to disk.
Perhaps you should tell that to the many, many, many people Cc-ed on the infamous 'Windows crashed and ate my bookmarks' Mozilla bug.
And yes, it happened to me several times: any time XP blue-screened with Firefox running I'd find my bookmarks had gone after the reboot.
In other words, it's Mozilla's fault that this is possible, and we're still waiting for a Firefox release that fixes the bug.
How do you plan to allow Mozilla to install per-user addons without allowing other programs to install addons when logged in as the same user?
If Mozilla runs addons in ~/.addons, then anyone can put one there. If Mozilla reads a list of addons from ~/.addons.list, then any program can add one to it. You can only prevent programs from adding addons by preventing users from changing that configuration, which then means they have to be root or some other privileged user in order to install the addons that they want to install.
And the program installer probably runs as root anyway, so that won't make any difference.
This is not the interface, it's the SQLite database. Every time you access a page, it has to write to the database.
It doesn't _have_ to write to the database, it chooses to write to the database. I believe it's updating things like the time you last visited the page, which I totally don't care about.
There's more to a browser than rendering and Javascript performance. Firefox has become a hard disk hog. It almost continually writes to disk, which can be very slow
Isn't that because they moved to using sqlite to store bookmarks because NTFS used to eat your entire bookmarks file if Windows crashed? Whereas sqlite syncs multiple times every time you update the database?
Try reading a few more sentences. He states the windows virus problem is mostly resulting from its dominance as a monoculture. That mac or linux would have much more malware than they do now if they had 90% market share.
More than basically nothing, yes. There are sure to be some security holes which would be exploited on unpatched machines.
But Windows has always been insecure by default, whereas Unix has at least tried to be secure by default. Most obviously that any Flash exploit on Windows could own your entire system because you were almost certainly logged in as an admin user, whereas on Unix you need a Flash exploit _and_ a local priviledge exploit to do the same thing.
We could add minor little issues like loading DLLs from the current directory in order not to break some old applications which require it, thereby allowing attackers who can get a DLL into your system in some way to get you to execute it. Deliberately supporting backward compatible security holes is not really a good plan.
Directors, these things don't lend "immediacy" to the shot, they distract us and take us *out* of the moment, and it makes some of us slightly nauseated after a while! Probably not the intended effect.
Indeed. Mel Gibson may be batshit insane, but if you listen to his DVD commentaries he does at least know what he's doing when shooting a fight scene.
It always surprises me upon re-watching to realize just how many computer graphics were used.
What surprised me on watching the movie with the DVD commentary were just how many of what, as a kid, I thought were CG effects were actually hand-drawn in Korean sweatshops.
Self signed certificates are ALWAYS more secure if you can trust the issuer.
How do you trust the issuer when you don't have any way to know who the issuer is?
For instance if I went to my local bank branch and the manager there handed me a key in person and told me to go home and install it to validate their online site, that would be better than the Verisign cert they use now.
Dude, that key was created by an Elbonian hacker who's now going to steal your bank account thanks to his friend at the bank handing it out to customers who are dumb enough to trust a random self-signed certificate that's handed to them.
Ideally, browsers should have three SSL security levels:
Self-signed SSL cert. For the average user, it shouldn't bring up a lock icon, but something different saying the site is using some basic, untrusted cryptography to communicate.
'Average users' are precisely the kind of people who have to be beaten over the head with the fact that they're connecting to a site with a self-signed certificate. Average users typically don't check for a lock icon in the first place, so they're sure as hell not going to check for a self-signed certificate icon.
The real problem is that the entire CA model is fundamentally broken, not that browsers give warnings for certificates that might be OK or might be an Elbonian hacker trying to steal your bank account.
Every browser insisting that a self-signed certificate is less secure than non-encrypted http would probably play a big role in why router manufacturers have chosen hard-coded keys rather than auto-generated ones.
Yeah, because we should allow our browsers to accept a self-signed key for www.mybank.com in order to make life easier for router manufacturers.
Totally.
Atom is rubbish. Stay away.
Strange. I have three Atoms here and they work fine. I'm going to replace one with an i3 or i5 eventually, but only because it's the MythTV server and the Atom is a bit slow for transcoding.
Of course I'm not trying to use it for playing modern games or editing H.264 HD video.