Over a month back a security bug was discovered in IE that allows the address displayed in IE to be different for the actual address. Here is a description and demo of the spoof attack.
Apparently, the upcoming fix includes dropping the http://user:pwd@domain/ url format support.
This is a radical "fix" and the response by security experts (mentioned in the article) was surprising. This format isn't the root cause for the specific bug and the "fix" is going to break stuff (not to mention IE's support for standards).
In any case, I hope they correct the bug that caused the end of the url (following the %01 character) not to be displayed in the first place.
User:Pwd@Domain format:
The problem with this url format (user:pwd@domain:port) is it confuses most end-users, who don't understand it. And the url can be obfuscated even further if the domain is an IP address in decimal format (as mentioned on slashdot at least a year back).
Another factor is that this is a pretty insecure format to transmit credentials. It probably stays in the browser's history and can be sniffed over non-secured connections.
Richard offers an alternative fix: hiding the user:pwd part in the address bar. But hiding stuff is also dangerous security-wise.
Here are two other ideas:
Update: Simon Willison's take on the fix, with interesting pointers to Microsoft's KB article and a related Mozilla bug (which actually already mentions both suggestions above).
Update: The fix is now available.
Update: Both RFC 1738 and RFC 2396 mention the "userinfo" part in the generic URL scheme.
But RFC 1738 then goes into the specifics of the HTTP URL scheme and it doesn't allow the username and password in the URL:
The HTTP URL scheme is used to designate Internet resources accessible using HTTP (HyperText Transfer Protocol).
The HTTP protocol is specified elsewhere. This specification only describes the syntax of HTTP URLs.
An HTTP URL takes the form:
http://<host>:<port>/<path>?<searchpart>
where <host> and <port> are as described in Section 3.1. If :<port> is omitted, the port defaults to 80. No user name or password is allowed. <path> is an HTTP selector, and <searchpart> is a query string. The <path> is optional, as is the <searchpart> and its preceding "?". If neither <path> nor <searchpart> is present, the "/" may also be omitted.
Within the <path> and <searchpart> components, "/", ";", "?" are reserved. The "/" character may be used within HTTP to designate a hierarchical structure.
Also, the BNF for specific URL schemes clearly allows the use of a username and password in the ftp scheme, but not for http.
Here are some videos links:
A mechanical mirror with wooden pieces: Wooden mirror video.
A scary video of a driver falling asleep without a seatbelt, via Viral Marketing Blog.
Some silly flash games:
More videos are available in this previous post "Matrix-style table tennis".
Update:
More awesome robots videos (via Ned Batchelder's blog).
Update: Newer videos of the Asimo robot.
There has been a wave of posts in the blog world recently, related to Microsoft, how it is perceived and what it may be doing wrong. Sometimes the debates seem a bit absurd because of the very different values of the participants (like what is success, what is good or evil,...), but it is good to see that the communication channels are continuing to open.
I believe the Microsoft main problems to be its many coupled or conflicting interests, while being so dominant in the desktop market. For example, few (or none?) companies are in such a multi-faceted position: to develop an audio format, license it, have it supported by 95% of the end-user computers, tie it to its other products and sell online content in that format.
ISVs and developers:
Darcy recently shared her surprise about the suspicion that answers to all Microsoft moves. It reminded me of Peter's post "How Microsoft could help Tablet PC ISVs ", that mentions how ISVs may be threatened by Microsoft's attitude.
There is also the question of the Longhorn flood 2+ years before the ship date. I don't doubt that Longhorn will ship and have great advances for both users and developers, but I still remember the Hailstorm stir and fade.
Jon Udell takes a step back and announces his article project to evaluate the .NET framework against its promises.
Media formats and content:
On the media front, Scoble unleashed a much debated argument about how iPods suck and there is no way you'd want to pick Apple's DRM instead of Microsoft's. His reasoning is there is more choice in terms of hardware for WMA, more online stores, more desktops (and Windows Media Centers) to support it, amongst others.
One point that struck me is because Microsoft doesn't make hundreds of dollars off the hardware, their marketing isn't good. Well, then what about the Xbox, MS doesn't make money off the hardware does it? Also, who pays for the Xbox advertisements? It's in fact not only the Xbox customers, but the Windows customers as well. Is that any better?
My advice: the iPod and AAC have their problems, but they're successful. Take a hint. There has to be at least one thing that isn't wrong with iPods/iTune, isn't there? They may not have tons of features or tons of devices, but what they do they do pretty well.
There was another interesting article on Microsoft and the music industry (and a reply by Scoble). It tackles the conflicts of interest between Microsoft the WMA format owner and Microsoft the content provider (MSN Music), and the threat it creates for those in the industry that want to partner with it.
I think Microsoft still has a little bit of an attitude problem. Given its position in the market, it shouldn't complain about how competitors are successful, but really, its own products are way better. Open your eyes, just do it right (and do no evil, ala Google, although some debates are starting there too).
Maybe there are too many shared or conflicted interests between the various groups (Windows, Office, MSN,...), too much cash redirection between them (MSN and Xbox both had their first couple years in the red) and too much tainted history for Microsoft to ever succeed in ridding its customers from their suspicions.
Update: What's So Bad About Microsoft? and Cringely's "Now the Only Way Microsoft Can Die is by Suicide".
I recently stumbled on a nice feature in PINE (a text-mode mail client): when reading an email sent via a mailing list, PINE offered some commands to manage the subscription to the list. This means you don't need to manually send an email to <mailinglist>-unsubscribe@<domain> to unsubscribe, PINE will do it for you.
I was curious about how this integration worked. It turns out that the RFC 2369 (The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields) defines a set of mail headers that can be used by the client to conveniently expose the most common mailing list management commands.
The actions that are supported are List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner and List-Archive.
They are just urls (most often mailto: or http: ) and don't support any form of code or replacement tags.
I couldn't find an inventory of programs that support these headers, but on the server side mailman (GNU Mailing List Manager) does, as well as PINE, exmh and Eudora on the client side.
I am not sure about Majordomo. Outlook/Outlook Express for Windows doesn't seem to support this RFC either, but I wonder if it would be difficult to add with a plug-in.
Another related RFC is RFC 2919 (List-Id: A Structured Field and Namespace for the Identification of Mailing Lists).
SYNC (Scheduling Your Network Connections) is a very interesting project that attempts to improve the responsitivity (mean response time) of a web server by applying a better scheduling strategy for the bottleneck resource (the uplink bandwidth).
SYNC description:
The default policy in current servers, called PS (Processor Sharing), is that all requests get an equal access to the response queue, taking turns to send packets. In contrast, the SRPT (shortest-remaining-processing-time-first) algorithm allows the responses that are closer to completion to send their packets first.
SRPT was prooved to be the optimal scheduling policy in terms of mean response time, but the intuition is that it hurts large jobs (unfair, but unavoidable because there is "no free lunch"). The SYNC papers actually find the counter-intuitive result that SRPT actually is almost always fair (depending on job distribution and load): SRPT not only helps small jobs, it also helps large ones most of the time ("all can win" theorem).
They also provide experimental measurements in the HTTP server world, by extending the Linux kernel to support priorities in the socket/network layers and modifying the Apache web server to use this new socket option. Since the only requests considered here are for static files, the web server easily can estimate the remaining size of each of the responses.
There remains a fairness problem, since in some cases large jobs perform less well under SRPT than they would under the strictly equitable PS policy. The question is whether a scheduling strategy can be found that keeps the expected response time lower than PS, while staying in the "always fair" category (see Classifying scheduling policies wrt unfairness and performance).
File size as job size estimate:
One of the assumptions of the SYNC project is that the file size can be used as a prediction for the remaining time for a job. But from analyzing log files from a public cache proxy, the authors of "How Well Does File Size Predict Wide-Area Transfer Time?" find no correlation between the file size and the transfer time, for small files (under 30ko) and only a limited correlation for larger files.
On the other hand, the SRPT analysis done around SYNC uses a heavy-tailed (HT = "largest 1% of jobs comprise half the load") workload model, where most of the load comes from a very small portion of the request (the largest ones). This choice was supported by their analysis of traffic logs of some large web sites. Maybe this property is what helped SRPT perform well in the measurements against PS.
Conclusion:
It is hard to doubt the results of SYNC given the described experimental setup (slide 38). I don't think they made their implementation available (I couldn't find it), but I look forward to having this improvement made widely available for some more real world testing.
Some of the diagrams showing the three fairness categories mention a "FSP" policy (Fair Sojourn Policy). I haven't had time to read the "Bounds on a Fair Policy with near Optimal Performance" paper yet, but the abstract presents FSP as having both fairness and good response times properties.
Links:
More details on SYNC.
An Analysis of SRPT scheduling: investigating unfairness.
Paper on Connection Scheduling in Web Servers.
A research project that uses the same type of OS+server modifications as SYNC to test another scheduling policy called SWIFT.
After two months with my blog in a lethargic/frozen state, I finally set MovableType up again. It feels really good to be able to un-pile items/nuggets/ideas from my mind again :-)
This is my first occasion to wish everyone a happy new year!
But by now I should rather say a happy new Chinese year, since tomorrow is the first day of the year of the Monkey ;-)
The setup:
The server isn't at home anymore, I'm using a website hosting service (Pure Energy Systems' Blog Website Hosting). This service seems great so far, as the account was setup quickly and the server has everything needed for MovableType.
I did run into some problems though.
Some problems:
First, I tried to directly re-use my previous Berkeley DB directory on the new setup, but it wouldn't work. This is probably a problem with the Berkeley DB file version, not MovableType.
Second, when I first imported my exported entries into the new site, the post IDs where completely messed up, which means the permalinks don't match the original ones.
This is a known problem, encountered by Már Örlygsson (Howto: Future-proof URLs in Movable Type) and Charles Cook (Importing/Exporting Movable Type).
I opted for Charles' solution, which is to tweak the backup file by introducing bogus entries/drafts.
If you plan on moving your MT blog, you should at least do Charles' export script modification ahead of time (adds a blogid line to every post), to keep your options open.
Also, I thought of using the TypePad service from the MovableType team, but their url format has changed to something like /2004/01/progress_prompt.html, which would break my permalinks as well...
Update: The Learning Movable Type blog has a nice post on Moving your MT Blogs to a New Server or Web Host.