You write about my humorous post as if you'd read someone else's post, or are replying to the voices in your head. Get some help, or at least some perspective.
Wow, in one post you managed to present both the common sense notion that MS shouldn't care if they break insecure applications, and the most common objection to that notion - that people will blame MS even if it's the other guy's bad application at fault.
People do run applications from network shares. But if you want to keep people on your machine from running executables from remote locations, I think you can set up a software restriction policy with an appropriate path rule and with the global settings set to check DLLs too.
I would guess that the problem isn't that reading a data file causes a DLL to be automatically "sucked in" from that location, but that the application sets the current working directory to that location, causing subsequent DLL loads to potentially happen from that location.
XP SP2, Vista, and above have a somewhat safer search path by default, checking system directories before the working directory. Earlier versions checked the working directory second, after the application directory. Windows 2000 SP4 and XP prior to SP2 can also be set to use the safer search path. But if the application attempts to load a DLL that doesn't exist elsewhere, or one that only exists somewhere else in the user's PATH, it can still be tricked into loading one from the working directory.
Applications that change the current working directory based on user input should be calling SetDllDirectory, on Windows versions that support it, to remove the current working directory from the search path. I'm not surprised that there are many applications that do not.
Verizon doesn't block SMB on residential connections anyway? I know Comcast does. As far as disabling WebDAV, the article links to a Microsoft security bulletin that - among other things - contains instructions for doing that.
The sad truth is that most people won't even know the security problems exist, even after there are fixes available for them. People who actually care about these things are already a rarefied group among Windows users.
Slight self-correction: blocking SMB at the router and disabling the WebDAV client on all Windows machines. Still, there's a mitigation that should work for most people.
The article does mention that blocking WebDAV and SMB at your perimeter router will at least prevent the exploit coming from outside your network, though I agree that in general it seems long on FUD and self-congratulation and short on useful content.
Where were you when I was trying to decide between the 6350 and 6650 a week ago?
Seriously, most people in the US have never heard of Symbian or even Android. The only words they know are "iPhone", "Droid", and "Blackberry."
And, honestly, it's not like you're going to find the information that S40 and S60 aren't actually related anywhere obvious on Nokia's website. Even finding out which are S40 and which are S60 is a matter of clicking several links, even on Nokia's site. AT&T doesn't generally put that information in their "technical" specs.
Still, the original poster's point holds: AT&T has at least one other Symbian phone, the 6650. (The Mural is another S40 phone.)
That'd be Fortran. Code generally had to start in column 7. But that had nothing to do with loops or conditional structure. Fortran code isn't generally indented to show structure. After all, it was hard to write; it should be hard to read. (More reasonably, since code is limited to columns 7-72, there's not much space to be wasted on frills like indentation.)
Perhaps the OP wants something more trustworthy than a black box labeled "trust us" and signed by people whose deviousness is pretty well substantiated by this here story.
Again, the warrant should only give MLB an out on the promise of confidentiality. "Anonymous and confidential" means anonymous AND confidential. They're two different things; you can't say "this is anonymous because we'll just never tell anyone whose name is attached to it." That's just confidentiality. The only way it's anonymous is if nobody - not just "nobody but a privileged few" - can determine whose it is.
That's the whole point of "anonymous and confidential": if the confidentiality is breached, either legally (as in this case) or not, the anonymity is supposed to be the backup.
They're suing over the loss of confidentiality. As near as I can tell, the fact that the loss of confidentiality was able to have any effect on them at all is because there never was any of the promised anonymity. The government is not the only party who did something wrong here.
A promise that information will remain anonymous is not a promise to destroy all information relating to identity.
Well, yeah, actually, it kinda is. That's what anonymous means.
There are protocols that could allow for retesting without the testing or collecting parties needing to know anything about the identity of the party being tested. The simplest one I can think of off the top of my head: randomly issue a sheet of identically numbered labels to each participating player, without tracking which player gets which labels, and have each player apply one of their labels to each test sample. Obviously, there might need to be additional protocols in place to prevent correlation of labels with players after the fact, but the point is that it's a solved problem, and one that the medical testing community has dealt with before.
I'm not saying the players should sue for the breach of confidentiality; there's really nothing that can be done about that. But there was never any serious attempt made at anonymity, despite promises that the data would be both anonymous AND confidential, and that should be a concern.
The players were assured that the results would remain anonymous and confidential
So the question is, why isn't the players' union suing Major League Baseball for breach of contract? Anonymous and confidential is not the same as identifiable but confidential; if the results actually had been anonymous as promised, this breach never could have happened.
But the context of the discussion was that the object code should be flawless. In that case, whether the tools that turn source code into object code have bugs turns out to be relevant.
And I didn't say int main(void) was wrong or bad; what I intended to imply was that some compiler might have only been properly tested for the more common argc/argv prototype. Heck, it might not have been tested at all; as another poster mentions it might be a bug in all code the compiler generates.
It can be, depending on the cable and the motherboard.
Some IDE cables have a filled hole in the female connector that aligns with a missing pin on the male connector. Some cables have a bulge on the female connector body that aligns with a slot in the male connector body. Some cables have neither, and some motherboards (especially cheap ones) don't have the plastic shroud surrounding the male connector, allowing the cables with bulges to be plugged in either way (and potentially off by one or more pins in either direction, too.)
Slashdot Mirror
Sad, isn't it?
No, it only does suns serif.
But what we really want to know is, do you own a television set?
Relatedly, just because somebody replies to the tweet doesn't mean people are reading it.
You write about my humorous post as if you'd read someone else's post, or are replying to the voices in your head. Get some help, or at least some perspective.
You mean "Also, the Republicans will...." Fish gotta swim, Republicans gotta screw us, Democrats gotta screw up.
Wow, in one post you managed to present both the common sense notion that MS shouldn't care if they break insecure applications, and the most common objection to that notion - that people will blame MS even if it's the other guy's bad application at fault.
People do run applications from network shares. But if you want to keep people on your machine from running executables from remote locations, I think you can set up a software restriction policy with an appropriate path rule and with the global settings set to check DLLs too.
I would guess that the problem isn't that reading a data file causes a DLL to be automatically "sucked in" from that location, but that the application sets the current working directory to that location, causing subsequent DLL loads to potentially happen from that location.
XP SP2, Vista, and above have a somewhat safer search path by default, checking system directories before the working directory. Earlier versions checked the working directory second, after the application directory. Windows 2000 SP4 and XP prior to SP2 can also be set to use the safer search path. But if the application attempts to load a DLL that doesn't exist elsewhere, or one that only exists somewhere else in the user's PATH, it can still be tricked into loading one from the working directory.
Applications that change the current working directory based on user input should be calling SetDllDirectory, on Windows versions that support it, to remove the current working directory from the search path. I'm not surprised that there are many applications that do not.
Verizon doesn't block SMB on residential connections anyway? I know Comcast does. As far as disabling WebDAV, the article links to a Microsoft security bulletin that - among other things - contains instructions for doing that.
The sad truth is that most people won't even know the security problems exist, even after there are fixes available for them. People who actually care about these things are already a rarefied group among Windows users.
Slight self-correction: blocking SMB at the router and disabling the WebDAV client on all Windows machines. Still, there's a mitigation that should work for most people.
The article does mention that blocking WebDAV and SMB at your perimeter router will at least prevent the exploit coming from outside your network, though I agree that in general it seems long on FUD and self-congratulation and short on useful content.
Where were you when I was trying to decide between the 6350 and 6650 a week ago?
Seriously, most people in the US have never heard of Symbian or even Android. The only words they know are "iPhone", "Droid", and "Blackberry."
And, honestly, it's not like you're going to find the information that S40 and S60 aren't actually related anywhere obvious on Nokia's website. Even finding out which are S40 and which are S60 is a matter of clicking several links, even on Nokia's site. AT&T doesn't generally put that information in their "technical" specs.
Still, the original poster's point holds: AT&T has at least one other Symbian phone, the 6650. (The Mural is another S40 phone.)
And another data point: T-Mobile has the 5130, another S40 phone. So even the "only AT&T has any Symbian phones" part is wrong.
And the 6350 (S40) and the 6650 (S60, same as the e71x.)
I sure haven't noticed that, as I first heard it floated as a potentially usable term back in 1999 or so.
That'd be Fortran. Code generally had to start in column 7. But that had nothing to do with loops or conditional structure. Fortran code isn't generally indented to show structure. After all, it was hard to write; it should be hard to read. (More reasonably, since code is limited to columns 7-72, there's not much space to be wasted on frills like indentation.)
For values of "works" equal to "appears to work while looking a hell of a lot like malware" anyway.
Perhaps the OP wants something more trustworthy than a black box labeled "trust us" and signed by people whose deviousness is pretty well substantiated by this here story.
Again, the warrant should only give MLB an out on the promise of confidentiality. "Anonymous and confidential" means anonymous AND confidential. They're two different things; you can't say "this is anonymous because we'll just never tell anyone whose name is attached to it." That's just confidentiality. The only way it's anonymous is if nobody - not just "nobody but a privileged few" - can determine whose it is.
That's the whole point of "anonymous and confidential": if the confidentiality is breached, either legally (as in this case) or not, the anonymity is supposed to be the backup.
They're suing over the loss of confidentiality. As near as I can tell, the fact that the loss of confidentiality was able to have any effect on them at all is because there never was any of the promised anonymity. The government is not the only party who did something wrong here.
Well, yeah, actually, it kinda is. That's what anonymous means.
There are protocols that could allow for retesting without the testing or collecting parties needing to know anything about the identity of the party being tested. The simplest one I can think of off the top of my head: randomly issue a sheet of identically numbered labels to each participating player, without tracking which player gets which labels, and have each player apply one of their labels to each test sample. Obviously, there might need to be additional protocols in place to prevent correlation of labels with players after the fact, but the point is that it's a solved problem, and one that the medical testing community has dealt with before.
I'm not saying the players should sue for the breach of confidentiality; there's really nothing that can be done about that. But there was never any serious attempt made at anonymity, despite promises that the data would be both anonymous AND confidential, and that should be a concern.
From the article:
So the question is, why isn't the players' union suing Major League Baseball for breach of contract? Anonymous and confidential is not the same as identifiable but confidential; if the results actually had been anonymous as promised, this breach never could have happened.
But the context of the discussion was that the object code should be flawless. In that case, whether the tools that turn source code into object code have bugs turns out to be relevant.
And I didn't say int main(void) was wrong or bad; what I intended to imply was that some compiler might have only been properly tested for the more common argc/argv prototype. Heck, it might not have been tested at all; as another poster mentions it might be a bug in all code the compiler generates.
So even the embedded OS hasn't managed to avoid a malware infection, then?
Are you sure your compiler doesn't have any bugs that might be exacerbated by, say, a main that doesn't take any arguments?
It can be, depending on the cable and the motherboard.
Some IDE cables have a filled hole in the female connector that aligns with a missing pin on the male connector. Some cables have a bulge on the female connector body that aligns with a slot in the male connector body. Some cables have neither, and some motherboards (especially cheap ones) don't have the plastic shroud surrounding the male connector, allowing the cables with bulges to be plugged in either way (and potentially off by one or more pins in either direction, too.)