Microsoft Locking Out Anti-Virus Makers?
twitter writes "Anti-virus makers have more to fear than stonewalling by Microsoft if a report by Agnitum, maker of Outpost Personal Firewall, is right about recent trusted computing changes. All the problems were summarized in a choice Register quote, 'In addressing the potential problem of not being able to install Outpost on new versions of Windows, we have discovered that it is possible to drill past the new security measures introduced by Microsoft - if we use the same techniques used by hackers.'"
It is called "Designed for Windows" program. Yes, applications have to be signed. And yes, you have to send a copy to MS so they can verify if you follow guidelines when they get 1000s of core dumps from your application. Or complaints about spyware and crap.
http://www.microsoft.com/winlogo/default.mspx
Yes, it costs money because you have to buy a digical certificate from Verisign. And send the software on a CD to MS, so a postage stamp there too.
And yes, MS will probably start treating software from unknown vendors differently than those that have registered. But afterall, how can you blame them with all the spyware screensavers and other crap.
We already see digital signatures in Linux like Debian. Untrusted repositories get flagged as "WARNING!! Untrusted source. WARNING!!". Microsoft should be doing the same to protect its user base.
If the user can choose on who he trusts, then it is okay. In my fedora computer I can easily install install a new source to my software and say that all packages signed by this source is okay to go in. I can also de-install a default source if they show that they are not trustworthy.
If the windows user has the same set of choices, then it is okay, but if MS is the only one who can bless application to install or run without warnings in the windows plataform and there is nothing I joe user can do to change this, then I believe it is a problem.
Just imagine if MS will give its blessing to all the open source software that is available now for windows. The answer is no, and the author will probably naver even ask for such bless for the simple fact the it will cost money. Now if the windows user could just say to his system that the software package with the signature of that John Doe who happen to signs all kinds of open source software and distributes them in his site, then it is fine. Just like I can install software from Livna that packages software that redhat simply don't want, and will never do, to distribute due to legal problems.
[]'s Victor Bogado da Silva Lins
^[:wq
WTF? I understand what you're getting at, but please think about what you've just written for a second.
It's not at all silly to give developers full access to your system internals, as long as you're clear about the repercussions of using them. In fact, there's a whole bunch of developers using this stuff called FOSS, which is based entirely on this principle.
I know, I know; your point is that if developers depend on a certain implementation, then the vendor is forced to continue supporting it forever, which, according to your reasoning, leaves them with no further room to grow or innovate. Unfortunately, that perspective is just bollocks. FOSS developers deal with this every day, and they've found a perfectly workable process:
Supported APIs are marked as such. Deprecated APIs are marked, too, with the clear warning that past this version, you're on your own. Unsupported interactions with the internals are marked - not fenced, but simply labled Here Be Dragons. You're welcome to venture there if you want, but don't go asking for help if something goes wrong. Most developers benefit from a better understanding of how the whole system works, and can in fact suggest or offer improvements in upstream functionality as well as better implementing their own.
I'd be fascinated to know why you think that things are somehow different for Microsoft than they are for IBM or Novell.
Crumb's Corollary: Never bring a knife to a bun fight.
Part 1 of his answer was that normally if a developer requires access to a system process that is not currently exposed via an API then he must request that interface from the development team responsible for that particular system process. This is normally the long way to get something done as this new interface must be documented.
Part 2 of his answer was that MOST undocumented APIs in Windows are actually APIs that were never intended to be included in the released product. A common way for an undocumented API to make it to release would be that a developer requires access to a system process for testing purposes so they have an alternate way to access that process. The interface is designed with the full intention of removing it. Application Developer B finds out about this new interface and actually uses it for the next release of Media Player (or any other Windows application). When the time comes to remove the interface, Developer B informs the group that the interface is being used in a production application and can't be removed.
Do what thou wilt shall be the whole of the Law - Aleister Crowley