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.