| March 2002 | ||||||
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
| 31 | ||||||
| Feb Apr | ||||||
This site is no longer maintained.
My current weblog.
Sunday, March 17, 2002Microsoft XP License Prohibits VNC: "Looks like the monopoly muscles are flexing. According to this article in Infoworld, the XP license prohibits products other than from Microsoft's from being used to remotely control an XP workstation. So ... guess they were having a little trouble with VNC being widely used?" [via Slashdot]
The EULA on my copy of XP Professional reads exactly as Infoworld describes. There is logic to it. XP's "Fast User Switching" feature is essentially Windows Terminal Services re-purposed for desktop console use. Microsoft has strong motivation to prevent someone from turning that functionality into something that competes with Terminal Services.
It's not the first time Microsoft has tried to to limit Desktops from being used as Servers. O'Reilly had a major beef with MS when they first imposed the "10 connections" limitation on NT 4 Workstation. Microsoft never caved on that issue, although they did remove the limitation from the TCP/IP stack that had been in some of the Betas.
Microsoft is risking a battle with bigger fish now. PCAnywhere, Timbuktu, and many other remote desktop programs are squarely aimed at the Corporate Helpdesk market. They were designed to be run on desktops being used as desktops. Microsoft is bundling competing technology (Remote Assistance), and then barring competitor's technology through licensing.
Not to mention that it would appear to disallow Telnet/SSH daemons, the use of CGIs within IIS, and countless other things that would cause a program to run in response to a remote action.
Some lawyer at Microsoft is about to lose their job...
Authentication for APIs based on XML-RPC
Evan Williams (of Prya/Blogger fame) wrote:
l.m.orchard asks why not just use HTTP basic authentication for XML-RPC? After all, "I already have a web server capable of authentication, why shoehorn that into my API?" Um, good question.
Survey says: because the web server may not be authoritative. Under IIS, a pure ASP implementation cannot intercept the basic auth process. From a security perspective, I don't want to give Web Application-only users a valid Windows login. Users on a shared NT host may not have the option of creating additional users, nor the ability to add an authentication filter to IIS.
Not that using basic authentication is a terrible idea... In many situations it can be better to leave user / password validation to an external system, such as the web server or underlying OS. However, it should be optional in the spec and implementations should allow for both methods.
And, umm, why isn't anyone trying to shoehorn secure password exchange into an XML-RPC API?
