Isn't it the other way around? The people who say the Internet is a house of cards just waiting for a stiff breeze to bring it down are the ones underestimating the blood, sweat and tears that go into keeping networks alive. It's like saying banks would be trivial to rob if there weren't those pesky guards there to stop you.
Does the US constitution even have a sovereignty clause that forbids allowing foreign sovereignty (for instance, by the UN), or is that just an interpretation?
If the US weren't sovereign, what the Constitution says wouldn't matter because the sovereign entity could override it. It does say this, though:
This Constitution, and the laws of the United States which shall be made in pursuance thereof; and all treaties made, or which shall be made, under the authority of the United States, shall be the supreme law of the land;
There's no reason there can't be a single standard that can even incorporate binaries for multiple platforms when available.
The problem referenced earlier in the thread is not caused by having multiple container formats. You could stuff the platform-specific installers into a single package file if you really wanted to. But no one wants to waste bandwidth downloading stuff that doesn't apply to them, so we're all pretty much used to getting just the file we need, whether or not the file we don't need is in the same format.
The problem is when binaries for multiple platforms aren't available. The author of TFA and the OP of this thread seem to expect that a package compiled and tested for one Linux platform should work easily with other Linux platforms. That's not a reasonable expectation and not one people have when they talk about different non-Linux operating systems.
Because no one believes Microsoft would be willing to go along or play nice if they did.
You don't think there might be some compatibility issues? I don't think OS X ships with msblahblah.dll...
What makes platforms incompatible is what makes them unique. You could mandate a specific architecture, like Java does, but there's no deviating from that standard if you want to stay compatible. If you have a different idea about what makes your platform better than the others, then it's inevitable that you're going to design your system in a way that isn't compatible with the others.
I think I've never seen a PKG installer for Windows; I don't know what that is.
It's the package format for OS X. Why isn't anyone clamoring for Microsoft and Apple to adopt a unified package format? It sure would be less confusing if every operating system used the same format. They both use x86 processors, right?
Same deal with Linux. Just because two operating systems use the same kernel doesn't mean you can expect a binary package from one to work on the other. When it does work, you should count yourself lucky that the process is as easy as it is and you don't have to use something like Parallels.
Stop thinking of Linux distros like different Windows versions. As much as they have in common, they're run by different people with different ideas about what they want their OS to be, just like Apple and Microsoft.
Joe's repository with his self-signed certificate is really no better than downloading random tarballs off the internet from a security point of view.
Uh, and the alternative is... going to Joe's completely unsigned website and downloading the EXE installer? Whenever you download and install software from someone, you are giving them your trust and opening yourself up to a security breach if they violate that trust. There's no way around that. Installing the repository is just a way of remembering that you trust Joe. Whether or not you should trust Joe is another question, one that users have to decide on a case-by-case basis.
Repository selection will never be as good as the internet. Google will always beat your repository, no matter how many people you hire to keep your repository up to date.
What does that even mean? Google doesn't notify you of updates. Google can't resolve dependencies. Google can't ensure that a package is compatible with your computer. Google can't authenticate packages.
Some are more up to date than others, but less popular packages are often neglected; Ubuntu let my wireless driver rot for over a year, and it never worked to begin with.
I don't think it's any surprise that Canonical would triage packages because of limited resources. If the manufacturer of your wireless card were really on the ball, they'd have their own repository that could push updates immediately.
(As an aside, I've never received a driver update from Microsoft for third party hardware at all. This sort of thing has become an OS responsibility on Linux out of sheer necessity, not because it makes sense to do it that way.)
I've used.deb files on Ubuntu before and that seems to be pretty simple to use, but not every project releases in that format - the author of the article mentions that he was trying to use RPMs, which is why he couldn't make it work, of course.
If there isn't a package in the native format for your distro, then your distro is not supported. When it is supported, your own experience tells you that it actually works well. The solution then is to increase adoption of the current system, not to invent another new "standard".
Novice users should not expect to use the software any more than a Windows user should expect to use Mac software. If you know enough about Linux to get it to work, count yourself lucky. If not, bitch at the developers to get them to support your distro.
And here we come to the crux of the problem. RPM, DEB, TAR; I really don't care how you do it, but any installer we did would have to be an agreed-upon format.
Why not include exe, msi, zip, pkg in that list? If it's such a problem to have more than one package format for Linux, why isn't it such a problem to have more than one package format, period?
Another thing we learned is that "Apply Changes" isn't the correct button text, because ordinary users have no clue what that means. The right button text is "Install", "Upgrade", "Remove", or possibly "Go!" or "Do it".
I can understand that it might not be the best possible phrasing, but I'm a bit incredulous that users can't figure it out. "Apply" buttons are all over Windows configuration dialogs. If the same dialog can be used install one package, upgrade another, and remove a third in one step, as Synaptic can, then your first three options are no good. "Go" and "Do it" strike me as being too vague, but I could be wrong. I do notice that neither phrasing is all that common in commercial software, where they test more frequently with clueless users.
Old hardware that's not worth selling on eBay isn't exactly hard to come by. If the high school is lucky enough to have a computer engineering program, they probably have better equipment than what you're about to throw away. Not to mention the storage rooms full of old equipment they're trying to get rid of.
The intersection of people who find The God Delusion hateful and the people who have actually read The God Delusion is probably less than 1% of the total population.
Dawkins holds that he is correct, as does everyone else with a position on any given issue. It's hardly his fault that the logical consequence is that people who disagree with him are incorrect.
If this were, say, a political discussion, Dawkins' message and tone would positively mild compared to partisans like Rush Limbaugh. Political partisans don't bother with implication. They directly insult the other side's intelligence all the time and no one really bats an eye. I don't seem to Dawkins ever telling someone from the opposition to go fuck himself, for example.
They're not going to commit any more than they absolutely have to. The revisions are just going to be snapshots of the bill at the various points where they are required to submit it to the record, as is the case now. Plus, the commits are all going to come from the same low-level staffer, who conveniently has a bad memory for who asked him to add what at the last hour.
...which is pretty much what THOMAS gives you already. A diff function might be useful, provided the structure of the bill doesn't change much. Slashdotters are kidding themselves if they think legislators are going to track intermediate changes to draft versions.
I think you are taking the concept of "ownership" of intellectual "property" too literally. If I have a car in my possession that is owned by someone else, they can take me to court to force me to turn it over. If I have the only extant copy of an obscure piece of software, the copyright owners can't force me to give that copy to them. That's because they don't own the copy, I do. They "own" the exclusive right to copy the software. If I'm not trying to copy the software, what I do (or what I don't do) with my copy is none of their business. I can lock it away in a vault and never let anyone see it ever again.
Now, maybe there's some other legal rationale for why the company could compel me to give them my copy, but it wouldn't be based on copyright. Perhaps I agreed to some contract or EULA that says I have to give it up on demand. Perhaps the company can show that I obtained the copy illegally and it was never really mine.
In this case, Childs doesn't even possess a copy of the supposedly copyrighted material and surely isn't trying to make copies of it. Copyright creates no obligations for him to do anything, not to "perform" or copy or whatever. "Nah, I don't feel like it" is a perfectly acceptable response from a copyright perspective. DavidTC may be right that the terms of Childs' employment carry some implicit obligation that isn't discharged even when he's fired. I don't know. Regardless, whatever that obligation is, it does not come from copyright.
Well, no, at worse they could sue you and get the court to order you to produce said work and hold you in contempt when you didn't.
Really? If Sony lost the master recording to "Beat It", you think a court is going to tell Michael Jackson to head back into the studio to re-record it?
What part of the work for hire laws impose a criminal penalty for refusing to recreate the work on demand? If I compose a song for my employer and my employer loses the only copy, then they can't put me in jail if I don't feel like producing a new copy. At worst, they can fire me.
It's the employer's responsibility to ensure that their property is stored safely. If Childs had died in a car accident they'd be in the same situation. If you can't figure out a better way to store passwords than in one person's head, you're just asking for trouble.
P.S. Let's not pretend that anyone is basing their legal decisions on the say-so of a random Slashdotter, whether or not he is a lawyer.
This has nothing to do with partisanship. It's amazing that people don't realize how this will negatively effect exposure of the candidates to the people. If your state does this, and they have less than 1 million votes, the state will almost certainly be passed over in the election.
California is the epitome of a big state with everything to gain and nothing to lose with this measure. California is consistently ignored by both parties, except when it comes to fundraising behind closed doors. Moving to a popular vote would certainly increase the exposure of candidates to Californians.
Democrats generally support the measure and Republicans generally oppose it because the big states are generally blue and the small states are generally red. More power to the big states means more power to the Democrats. That's why it passed in a small blue state like Hawaii and got vetoed by a Republican governor in the state with the most to gain.
Those letters were written in response to a creationist opinion piece that used the term first. Just for good measure, here's a choice quote from something that I presume was printed in a prominent newspaper:
A dedicated Darwinian would welcome imperialism, genocide, mass deportation, ethnic cleansing, eugenics, euthanasia, forced sterilisations and infanticide.
- Uninstaller bugs, I remember a number of games which were mistakenly coded to wipe out the root folder of the drive you installed them to instead of the actual app folder.
Use a standard uninstaller. IIRC, in Windows the installer/uninstaller is a separate program that gets updated with the OS.
- Security bugs, or did you forget that there are online and sharing components to Google Earth? What sort of fun could you do with a malformed KML file if Google's parser was fucked up enough to allow buffer overflows? - Accidental file corruption. "Whoops, we were supposed to just load that Window's DLL, but we accidentally got it caught up in a write operation to save your KML file." - Many other screw ups that are possible with ANY program you run regardless of its intent, if it was written poorly or has a mistake coded in.
None of these are going to hurt anything if the program isn't running. Despite your disparaging comments, I did read the thread. Gizzmonic's premise is that this is an app you run very rarely.
When you finally do run the program, the first thing it should do is check for updates. The risk is limited to a catastrophic bug that gets triggered immediately upon execution before the program can notify you of the update.
Now consider that any of these bugs could happen in the updater itself, a program designed to fetch and execute arbitrary code that runs 24x7. A bug in an program on your hard disk is one thing. A bug in a constantly running application is quite another.
Did I ever say that wouldn't work? No. I said having an updater is a more reliable and stable option.
And my retort is that the worst case scenario is acceptably reliable and stable. It's not reason enough to warrant a separate client just for updating.
I agree with you that there needs to be a standard update daemon. That's why I didn't quibble on that point. Where we disagree is the comparative utility of running per-application daemons versus just checking for updates on startup. You seem to think the former is always better. I think the latter is perfectly acceptable, especially for rarely used apps. I've explained why. There's no need to get angry about it.
If the latest version of the app includes bug fixes which correct issues that could cripple your OS, don't you think it'd be best to get them?
What kind of Google Earth bug is going to cripple my OS, especially when I'm not running it? Presuming I used it at least briefly after I installed it, then it's probably not going to cause my computer to explode the next time I open it. And the next time I open it, it can bug me about updates.
But the point is if you build the update checking into the app itself, then regardless of the necessity of the update, they won't get it unless the way the update check works now is the same as it was the last time they opened it. That locks you into supporting that method forever, assuming that you as the app developer consider having people use the most recent version of the app important.
It should be easy enough to have maintain a file at specific address on your website that contains a link to the latest version. Worst case scenario, if the software can't access that address, pop up a dialog and tell the user to go find the update themselves.
If, on the other hand, you split that out into a separate program, one 'small enough' to run 24/7, or at least regularly in the background, it doesn't matter if you change the update methods as long as you leave the old method up long enough for all the updater apps to update.
The problem is when every Tom, Dick, and Harry software company decides they need an update client of their own. "Small enough" times a few dozen stops being so small. Plus, the odds that any one client is buggy or insecure goes up by the same factor. We are talking about daemons running 24x7 that can remotely fetch and execute arbitrary code here.
Then the only people missing your updates are the ones who voluntarily and consciously went out of their way to disable the updates and thus 'made their own bed'.
Except it would appear you can't do that with the Google update client.
It's very simple. The sort of people who will be the targets of cold boot attacks want absolute security.
It's very simple. First, you set up an impossible standard that no security system could ever meet and no practical system even attempts to meet. Then you go on to define several use cases that are completely irrelevant and ignore the obvious one:
Assistant Secretary of State for East Asian and Pacific Affairs Jane Doe is traveling to China for trade negotiations. Her laptop contains various briefing documents related to the negotiation and uses full disk encryption to protect the files and the OS itself. She only needs access to review or edit the documents and does not need to perform long computational tasks. Knowing that the Chinese intelligence service regularly attempts to acquire such confidential data through clandestine means but is never so brazen as to use force on a visiting diplomat, Jane always makes sure to keep the laptop locked when she is not using it.
In any case, if the computer needs to do any work the key is in RAM with this solution. If that task takes a while then you have the key in RAM for a long time.
The CPU cache can be addressed as memory, so execution continues, just at a slower pace.
Doesn't unmounting the encrypted volume and zeroing the keyspace in RAM when the user locks the screen solve this same problem anyway?
From what I understand, this is difficult because the boot volume is encrypted and unmounting the boot volume causes all sorts of trouble.
I haven't even touched on the fact: if you have the volume mounted and opened a few files then there is likely residue of those files in RAM.
"Doesn't [closing the file] and zeroing the [buffers] in RAM when the user locks the screen solve this same problem anyway?"
Are you so naive to assume that the user will actually follow secure practice all of the time?
Are you so pessimistic to say that there's no value to making security more effective if it isn't 100% effective?
Are you so naive to believe that physical lockdown will save you from an invasion by the feds/rival drug dealers/etc?
Are you incapable of seeing the benefits for someone who isn't a drug dealer (who needs to do hours of data computation for some reason)?
I don't know what's so hard to understand about this. No, this is not something you, personally, would ever need or want. No, it won't work in every case. But it does offer some additional protection to some users who aren't you.
Just because the screen is locked doesn't mean the encrypted volume is not in use.
It will if you want to use access highly sensitive information on that machine.
The cold boot attack is also more useful against desktop machines because it's much easier to freeze up the memory good because you usually have unrestricted access to most of its surface area.
Desktop machines are typically covered by site security. Traveling diplomats, CEOs, dissidents, etc. want to be able to access their sensitive data in situations where they don't completely control site security. This gives them some additional protection if implemented with secure user practices (i.e. locking your workstation whenever you are not present).
I leave my computer calculating possible attack vectors for that exhaust port and lock the screen while I go make a coffee; it's going to take a couple of hours to compute, you see.
You do that on a separate server under physical lockdown. Obviously this only makes sense for interactive user sessions rather than anything computationally intensive.
Sure, if you were 250% paranoid you wouldn't walk away from your computer without first ensuring the key space in RAM was DoD wiped, but find me someone _that_ paranoid.
How about, I dunno, the DoD? I don't ever plan to use this on my box. I don't use full disk encryption either, but I can understand why other people would.
The scenario is that someone steals a running, but locked laptop, and wants to read your encryption keys stored in RAM. If it's not running, then the encryption keys aren't in RAM. If it's not locked, then you're SOL anyway.
So the idea is to move the keys out of RAM and into the cache temporarily while the machine is locked. When you log back in, the cache gets re-enabled so you won't notice any difference in performance.
So it's quite possible that indeed a layout pretty close to the most efficient layout won out in the competition.
"Pretty close to the most efficient layout" is not the same as the most efficient layout. The point is there's effectively no competition anymore and no incentive to make marginal improvements. Saying that path dependence leads to solutions that are "pretty close" does not disprove path dependence.
Slashdot Mirror
Sounds like a plan to me. There would be an economic incentive to monitor your system carefully and ensure that it isn't taken over.
Isn't it the other way around? The people who say the Internet is a house of cards just waiting for a stiff breeze to bring it down are the ones underestimating the blood, sweat and tears that go into keeping networks alive. It's like saying banks would be trivial to rob if there weren't those pesky guards there to stop you.
Does the US constitution even have a sovereignty clause that forbids allowing foreign sovereignty (for instance, by the UN), or is that just an interpretation?
If the US weren't sovereign, what the Constitution says wouldn't matter because the sovereign entity could override it. It does say this, though:
This Constitution, and the laws of the United States which shall be made in pursuance thereof; and all treaties made, or which shall be made, under the authority of the United States, shall be the supreme law of the land;
The modern Fahrenheit scale is based on the freezing and boiling point of water. Fahrenheit just puts them at 32 and 212 instead of 0 and 100.
P.S. The freezing and melting point of water are the same thing.
There's no reason there can't be a single standard that can even incorporate binaries for multiple platforms when available.
The problem referenced earlier in the thread is not caused by having multiple container formats. You could stuff the platform-specific installers into a single package file if you really wanted to. But no one wants to waste bandwidth downloading stuff that doesn't apply to them, so we're all pretty much used to getting just the file we need, whether or not the file we don't need is in the same format.
The problem is when binaries for multiple platforms aren't available. The author of TFA and the OP of this thread seem to expect that a package compiled and tested for one Linux platform should work easily with other Linux platforms. That's not a reasonable expectation and not one people have when they talk about different non-Linux operating systems.
Because no one believes Microsoft would be willing to go along or play nice if they did.
You don't think there might be some compatibility issues? I don't think OS X ships with msblahblah.dll...
What makes platforms incompatible is what makes them unique. You could mandate a specific architecture, like Java does, but there's no deviating from that standard if you want to stay compatible. If you have a different idea about what makes your platform better than the others, then it's inevitable that you're going to design your system in a way that isn't compatible with the others.
I think I've never seen a PKG installer for Windows; I don't know what that is.
It's the package format for OS X. Why isn't anyone clamoring for Microsoft and Apple to adopt a unified package format? It sure would be less confusing if every operating system used the same format. They both use x86 processors, right?
Same deal with Linux. Just because two operating systems use the same kernel doesn't mean you can expect a binary package from one to work on the other. When it does work, you should count yourself lucky that the process is as easy as it is and you don't have to use something like Parallels.
Stop thinking of Linux distros like different Windows versions. As much as they have in common, they're run by different people with different ideas about what they want their OS to be, just like Apple and Microsoft.
Joe's repository with his self-signed certificate is really no better than downloading random tarballs off the internet from a security point of view.
Uh, and the alternative is ... going to Joe's completely unsigned website and downloading the EXE installer? Whenever you download and install software from someone, you are giving them your trust and opening yourself up to a security breach if they violate that trust. There's no way around that. Installing the repository is just a way of remembering that you trust Joe. Whether or not you should trust Joe is another question, one that users have to decide on a case-by-case basis.
Repository selection will never be as good as the internet. Google will always beat your repository, no matter how many people you hire to keep your repository up to date.
What does that even mean? Google doesn't notify you of updates. Google can't resolve dependencies. Google can't ensure that a package is compatible with your computer. Google can't authenticate packages.
Some are more up to date than others, but less popular packages are often neglected; Ubuntu let my wireless driver rot for over a year, and it never worked to begin with.
I don't think it's any surprise that Canonical would triage packages because of limited resources. If the manufacturer of your wireless card were really on the ball, they'd have their own repository that could push updates immediately.
(As an aside, I've never received a driver update from Microsoft for third party hardware at all. This sort of thing has become an OS responsibility on Linux out of sheer necessity, not because it makes sense to do it that way.)
I've used .deb files on Ubuntu before and that seems to be pretty simple to use, but not every project releases in that format - the author of the article mentions that he was trying to use RPMs, which is why he couldn't make it work, of course.
If there isn't a package in the native format for your distro, then your distro is not supported. When it is supported, your own experience tells you that it actually works well. The solution then is to increase adoption of the current system, not to invent another new "standard".
Novice users should not expect to use the software any more than a Windows user should expect to use Mac software. If you know enough about Linux to get it to work, count yourself lucky. If not, bitch at the developers to get them to support your distro.
And here we come to the crux of the problem. RPM, DEB, TAR; I really don't care how you do it, but any installer we did would have to be an agreed-upon format.
Why not include exe, msi, zip, pkg in that list? If it's such a problem to have more than one package format for Linux, why isn't it such a problem to have more than one package format, period?
Another thing we learned is that "Apply Changes" isn't the correct button text, because ordinary users have no clue what that means. The right button text is "Install", "Upgrade", "Remove", or possibly "Go!" or "Do it".
I can understand that it might not be the best possible phrasing, but I'm a bit incredulous that users can't figure it out. "Apply" buttons are all over Windows configuration dialogs. If the same dialog can be used install one package, upgrade another, and remove a third in one step, as Synaptic can, then your first three options are no good. "Go" and "Do it" strike me as being too vague, but I could be wrong. I do notice that neither phrasing is all that common in commercial software, where they test more frequently with clueless users.
Old hardware that's not worth selling on eBay isn't exactly hard to come by. If the high school is lucky enough to have a computer engineering program, they probably have better equipment than what you're about to throw away. Not to mention the storage rooms full of old equipment they're trying to get rid of.
The intersection of people who find The God Delusion hateful and the people who have actually read The God Delusion is probably less than 1% of the total population.
Dawkins holds that he is correct, as does everyone else with a position on any given issue. It's hardly his fault that the logical consequence is that people who disagree with him are incorrect.
If this were, say, a political discussion, Dawkins' message and tone would positively mild compared to partisans like Rush Limbaugh. Political partisans don't bother with implication. They directly insult the other side's intelligence all the time and no one really bats an eye. I don't seem to Dawkins ever telling someone from the opposition to go fuck himself, for example.
They're not going to commit any more than they absolutely have to. The revisions are just going to be snapshots of the bill at the various points where they are required to submit it to the record, as is the case now. Plus, the commits are all going to come from the same low-level staffer, who conveniently has a bad memory for who asked him to add what at the last hour.
...which is pretty much what THOMAS gives you already. A diff function might be useful, provided the structure of the bill doesn't change much. Slashdotters are kidding themselves if they think legislators are going to track intermediate changes to draft versions.
I think you are taking the concept of "ownership" of intellectual "property" too literally. If I have a car in my possession that is owned by someone else, they can take me to court to force me to turn it over. If I have the only extant copy of an obscure piece of software, the copyright owners can't force me to give that copy to them. That's because they don't own the copy, I do. They "own" the exclusive right to copy the software. If I'm not trying to copy the software, what I do (or what I don't do) with my copy is none of their business. I can lock it away in a vault and never let anyone see it ever again.
Now, maybe there's some other legal rationale for why the company could compel me to give them my copy, but it wouldn't be based on copyright. Perhaps I agreed to some contract or EULA that says I have to give it up on demand. Perhaps the company can show that I obtained the copy illegally and it was never really mine.
In this case, Childs doesn't even possess a copy of the supposedly copyrighted material and surely isn't trying to make copies of it. Copyright creates no obligations for him to do anything, not to "perform" or copy or whatever. "Nah, I don't feel like it" is a perfectly acceptable response from a copyright perspective. DavidTC may be right that the terms of Childs' employment carry some implicit obligation that isn't discharged even when he's fired. I don't know. Regardless, whatever that obligation is, it does not come from copyright.
Well, no, at worse they could sue you and get the court to order you to produce said work and hold you in contempt when you didn't.
Really? If Sony lost the master recording to "Beat It", you think a court is going to tell Michael Jackson to head back into the studio to re-record it?
What part of the work for hire laws impose a criminal penalty for refusing to recreate the work on demand? If I compose a song for my employer and my employer loses the only copy, then they can't put me in jail if I don't feel like producing a new copy. At worst, they can fire me.
It's the employer's responsibility to ensure that their property is stored safely. If Childs had died in a car accident they'd be in the same situation. If you can't figure out a better way to store passwords than in one person's head, you're just asking for trouble.
P.S. Let's not pretend that anyone is basing their legal decisions on the say-so of a random Slashdotter, whether or not he is a lawyer.
This has nothing to do with partisanship. It's amazing that people don't realize how this will negatively effect exposure of the candidates to the people. If your state does this, and they have less than 1 million votes, the state will almost certainly be passed over in the election.
California is the epitome of a big state with everything to gain and nothing to lose with this measure. California is consistently ignored by both parties, except when it comes to fundraising behind closed doors. Moving to a popular vote would certainly increase the exposure of candidates to Californians.
Democrats generally support the measure and Republicans generally oppose it because the big states are generally blue and the small states are generally red. More power to the big states means more power to the Democrats. That's why it passed in a small blue state like Hawaii and got vetoed by a Republican governor in the state with the most to gain.
Those letters were written in response to a creationist opinion piece that used the term first. Just for good measure, here's a choice quote from something that I presume was printed in a prominent newspaper:
A dedicated Darwinian would welcome imperialism, genocide, mass deportation, ethnic cleansing, eugenics, euthanasia, forced sterilisations and infanticide.
- Uninstaller bugs, I remember a number of games which were mistakenly coded to wipe out the root folder of the drive you installed them to instead of the actual app folder.
Use a standard uninstaller. IIRC, in Windows the installer/uninstaller is a separate program that gets updated with the OS.
- Security bugs, or did you forget that there are online and sharing components to Google Earth? What sort of fun could you do with a malformed KML file if Google's parser was fucked up enough to allow buffer overflows?
- Accidental file corruption. "Whoops, we were supposed to just load that Window's DLL, but we accidentally got it caught up in a write operation to save your KML file."
- Many other screw ups that are possible with ANY program you run regardless of its intent, if it was written poorly or has a mistake coded in.
None of these are going to hurt anything if the program isn't running. Despite your disparaging comments, I did read the thread. Gizzmonic's premise is that this is an app you run very rarely.
When you finally do run the program, the first thing it should do is check for updates. The risk is limited to a catastrophic bug that gets triggered immediately upon execution before the program can notify you of the update.
Now consider that any of these bugs could happen in the updater itself, a program designed to fetch and execute arbitrary code that runs 24x7. A bug in an program on your hard disk is one thing. A bug in a constantly running application is quite another.
Did I ever say that wouldn't work? No. I said having an updater is a more reliable and stable option.
And my retort is that the worst case scenario is acceptably reliable and stable. It's not reason enough to warrant a separate client just for updating.
I agree with you that there needs to be a standard update daemon. That's why I didn't quibble on that point. Where we disagree is the comparative utility of running per-application daemons versus just checking for updates on startup. You seem to think the former is always better. I think the latter is perfectly acceptable, especially for rarely used apps. I've explained why. There's no need to get angry about it.
If the latest version of the app includes bug fixes which correct issues that could cripple your OS, don't you think it'd be best to get them?
What kind of Google Earth bug is going to cripple my OS, especially when I'm not running it? Presuming I used it at least briefly after I installed it, then it's probably not going to cause my computer to explode the next time I open it. And the next time I open it, it can bug me about updates.
But the point is if you build the update checking into the app itself, then regardless of the necessity of the update, they won't get it unless the way the update check works now is the same as it was the last time they opened it. That locks you into supporting that method forever, assuming that you as the app developer consider having people use the most recent version of the app important.
It should be easy enough to have maintain a file at specific address on your website that contains a link to the latest version. Worst case scenario, if the software can't access that address, pop up a dialog and tell the user to go find the update themselves.
If, on the other hand, you split that out into a separate program, one 'small enough' to run 24/7, or at least regularly in the background, it doesn't matter if you change the update methods as long as you leave the old method up long enough for all the updater apps to update.
The problem is when every Tom, Dick, and Harry software company decides they need an update client of their own. "Small enough" times a few dozen stops being so small. Plus, the odds that any one client is buggy or insecure goes up by the same factor. We are talking about daemons running 24x7 that can remotely fetch and execute arbitrary code here.
Then the only people missing your updates are the ones who voluntarily and consciously went out of their way to disable the updates and thus 'made their own bed'.
Except it would appear you can't do that with the Google update client.
It's very simple. The sort of people who will be the targets of cold boot attacks want absolute security.
It's very simple. First, you set up an impossible standard that no security system could ever meet and no practical system even attempts to meet. Then you go on to define several use cases that are completely irrelevant and ignore the obvious one:
Assistant Secretary of State for East Asian and Pacific Affairs Jane Doe is traveling to China for trade negotiations. Her laptop contains various briefing documents related to the negotiation and uses full disk encryption to protect the files and the OS itself. She only needs access to review or edit the documents and does not need to perform long computational tasks. Knowing that the Chinese intelligence service regularly attempts to acquire such confidential data through clandestine means but is never so brazen as to use force on a visiting diplomat, Jane always makes sure to keep the laptop locked when she is not using it.
In any case, if the computer needs to do any work the key is in RAM with this solution. If that task takes a while then you have the key in RAM for a long time.
The CPU cache can be addressed as memory, so execution continues, just at a slower pace.
Doesn't unmounting the encrypted volume and zeroing the keyspace in RAM when the user locks the screen solve this same problem anyway?
From what I understand, this is difficult because the boot volume is encrypted and unmounting the boot volume causes all sorts of trouble.
I haven't even touched on the fact: if you have the volume mounted and opened a few files then there is likely residue of those files in RAM.
"Doesn't [closing the file] and zeroing the [buffers] in RAM when the user locks the screen solve this same problem anyway?"
Are you so naive to assume that the user will actually follow secure practice all of the time?
Are you so pessimistic to say that there's no value to making security more effective if it isn't 100% effective?
Are you so naive to believe that physical lockdown will save you from an invasion by the feds/rival drug dealers/etc?
Are you incapable of seeing the benefits for someone who isn't a drug dealer (who needs to do hours of data computation for some reason)?
I don't know what's so hard to understand about this. No, this is not something you, personally, would ever need or want. No, it won't work in every case. But it does offer some additional protection to some users who aren't you.
Just because the screen is locked doesn't mean the encrypted volume is not in use.
It will if you want to use access highly sensitive information on that machine.
The cold boot attack is also more useful against desktop machines because it's much easier to freeze up the memory good because you usually have unrestricted access to most of its surface area.
Desktop machines are typically covered by site security. Traveling diplomats, CEOs, dissidents, etc. want to be able to access their sensitive data in situations where they don't completely control site security. This gives them some additional protection if implemented with secure user practices (i.e. locking your workstation whenever you are not present).
I leave my computer calculating possible attack vectors for that exhaust port and lock the screen while I go make a coffee; it's going to take a couple of hours to compute, you see.
You do that on a separate server under physical lockdown. Obviously this only makes sense for interactive user sessions rather than anything computationally intensive.
Sure, if you were 250% paranoid you wouldn't walk away from your computer without first ensuring the key space in RAM was DoD wiped, but find me someone _that_ paranoid.
How about, I dunno, the DoD? I don't ever plan to use this on my box. I don't use full disk encryption either, but I can understand why other people would.
The scenario is that someone steals a running, but locked laptop, and wants to read your encryption keys stored in RAM. If it's not running, then the encryption keys aren't in RAM. If it's not locked, then you're SOL anyway.
So the idea is to move the keys out of RAM and into the cache temporarily while the machine is locked. When you log back in, the cache gets re-enabled so you won't notice any difference in performance.
So it's quite possible that indeed a layout pretty close to the most efficient layout won out in the competition.
"Pretty close to the most efficient layout" is not the same as the most efficient layout. The point is there's effectively no competition anymore and no incentive to make marginal improvements. Saying that path dependence leads to solutions that are "pretty close" does not disprove path dependence.