Coding to the Bar

New Facebook App

Brian — Sun, 07 Oct 2007 18:51:00 GMT

Don't get us wrong, we love Facebook. But sometimes our friends just don't know how to use it as responsibly as they should. In these unfortunate situations they need a designated friend like you to help confront them with their Facebook abuse issues. The good news is that we've created an app just for this purpose - Restraining Order!

How do you use Restraining Order?
It's easy, really. Just fill in all the information (friend's name, what you're ordering them to stop doing, describe the infraction, select a duration for your restraining order, and then select a reason why you're doing this), and a notification will be sent to your friend.

If they choose to accept installing the Restraining Order app, the Restraining Order will be displayed on their facebook profile page until it has expired. If they choose not to install the Restraining Order app, they will still receive a notification outlining the terms of your Restraining Order. Your Restraining Order will also be published in your news feed and mini-feed.

If I install this app, what will my friends see on my page?
They'll see the Restraining Orders you have issued along with Restraining Orders you have received from others (sorry, but hey, if you give it you've got to be able to to take it).

What should I write in the bulletin board?
Let us know if you're running into any problems or have suggestions. Or if you've put together a classic Restraining Order for one of your pals, why not share it here!

Joost first impressions.

Brian — Sun, 08 Apr 2007 00:47:00 GMT

I made it into the beta finally, and I've been having a lot of fun playing with it. Overall I like it a lot.

The good:

The user interface: The UI is extremely easy to learn and efficient to use. It's not windows standard, but I wouldn't expect a cross platform application to conform to Windows UI conventions, and the transparent menus are a nice touch.
The video quality: This definitely exceeded my initial expectation. It's not 1080p of course, but for streaming internet video it's great.
Reasonable CPU load: On my 2ghz Athlon XP system running Joost puts about a 22% load on my processors. For comparison, Yahoo Go TV puts around 12 to 15%. For beta software that uses a CPU intensive codec (the CoreAVC codec that Joost uses doesn't take advantage of DirectX Video Acceleration (DXVA) hardware) that's pretty impressive.

The bad:

Limited content: This is to be expected in an invite-only beta, and hopefully it will get better. Joost has already signed a content deal with Viacom, which is a good sign. If they can manage to get the regular viacom, discovery communications and food network programming then I can cancel my cable subscription ;).
Random Commercial Breaks: Commercials are interspersed throughout the content, interviews are interrupted in mid-sentence, music videos in mid-grimace, etc. Hopefully one of the Joost guys can come up with an algorithm to look for periods of silence and/or video stillness and insert the commercial breaks there. Otherwise, it's a pretty annoying flaw.
Video playback failure: Joost has yet to crash on me, but I haven't gone ten minutes without video playback stopping with an error message telling me that the show can't be shown to me right now and to try again later. Strangely, all I have to do to restart the video is select it again from the menu and fast forward to where I left off. It's a beta.
Full screen mode switch glitch: I haven't reproduced this one yet, but after playing with my monitor resolution, the next time I loaded Joost and switched to window mode the window wasn't visible, even though the resolution was just slightly smaller than the one I'd used before. When I right clicked the taskbar icon and “maximized“ the window, it reappeared. It's a beta.

Overall I'm really impressed. I'm hearing great things about the media center features in Vista, and Bittorrent now has lots of legal content, but the price point of Joost (i.e. free) gives it cable killing potential that the others lack (for now).

Yahoo Music Engine tip

Brian — Sun, 08 Apr 2007 00:08:00 GMT

In general the new HTPC is working well, but I was having problems with Launchcast audio streams stopping suddenly with the error “While Stopping, Network Timeout.“ Since I didn't find much information on this problem I thought I'd mention my apparent solution, which was to disable the ActiveArmor firewall that came with the NVidia nForce chipset software.

Because the problem was intermittant I'm not 100% sure that this was is the fix, but I'm going on 6 hours now with no TCP problems whatsoever.

Good luck!

Catching Up: Final version of bro-in-law's video

Brian — Sat, 31 Mar 2007 16:50:00 GMT

My brother-in-law Mike Wesch posted the final version of his web 2.0 video on March 8th, not sure how I missed it. If you haven't seen it already, check it out: The Machine is Us/ing Us. The original version has over 2 million hits, which is amazingly popular for a video that lacks both stupid human tricks and boobies.

Asus EZ-Flash getting easier (M2NPV-VM motherboard)

Brian — Sat, 31 Mar 2007 15:14:00 GMT

Last night I finally got around to putting together a combination home theater PC/Dev machine. I'd ordered the parts weeks ago but I'd ran into power supply problems (the Forton Zen power supply that I'd that I'd ordered was either incompatible with my equipment or it was faulty, I've yet to determine which because Fortron tech support hasn't responded to my support request).

After plugging in the new PSU last night I started to install Windows just to exercise the hardware and make sure everything was okay. It wasn't, the memory was acting flaky, and I needed to flash the BIOS to fix it.

I generally dread this process because over the years it's gotten more difficult. Back in the DOS/Windows9x days, making a bootable floppy was easy enough. But it doesn't make sense to keep floppies around anymore just to flash a BIOS, and making a bootable CD is a hassle when you don't do it often. EZ-Flash got rid of the bootable disk problem by allowing you to access CDs from the BIOS, but you still had to burn a CD and burners are notoriously unreliable and what do you do if you don't have one?

I do have one, but for whatever reason it wasn't working, so on a lark I put the BIOS file on a USB key and plugged it into the motherboard and checked, sure enough, EZ-Flash now recognizes USB drives. Updating was a snap and the DDR2-800 DIMMs work great now. Flashing a BIOS is once again an easy process, no matter what OS you use. Yay!

So does anyone out there know when this was implemented? Via Google I see people who are still using the bootable USB drive trick in 2006 so I think it's a recent invention but since I don't upgrade machines often I'm not really sure. Do other motherboard manufacturers do this now? I definitely want this feature on all my future machines, so if you happen to know please let me know in the comments or e-mail.

Dave Barry on Windows Genuine Advantage

Brian — Fri, 23 Mar 2007 13:25:00 GMT

From Dave Barry's lips to BillG's ears...

Do you find that as annoying as I do? I mean, if you have legal, paid-for software -- which I do -- it's annoying to have this company, several years after you bought their software, trying to install a program on your hard drive to check up on you. And if you didn't have legal software, why would you install this? Or am I missing something?

Random Thought

Brian — Fri, 26 Jan 2007 12:20:00 GMT

Web 2.0 = Narcissism + HTML

.NET 2.0 Remoting ensureSecurity flag tests...

Brian — Mon, 29 May 2006 14:49:00 GMT

In researching .NET Remoting I found a lot of contradictory information on the purpose of the new ensureSecurity flag.

The MSDN Entry for RemotingConfiguration.Configure (the method I need to use in my code) seems to indicate that it is necessary to set it to true to enable security.

ensureSecurity

true to enable security; otherwise, false.

However the entry for ChannelServices.RegisterChannel indicates that it behaves the way you’d expect something named “ensureSecurity” to behave, it makes sure the channel is encrypted, but setting it to false still allows the channel to be encrypted.

ensureSecurity

true ensures that security is enabled; otherwise false. Setting the value to false will not nullify the security setting done on the TCP or IPC channel. For details, see Remarks.

Still confused, I checked the forums. A typical exchange went like this one between MSDN poster JockularJoe and Microsoft SDE Sowmy Srinivasan:

JocularJoe

The old .NET 1.1 Configure method is marked as obsolete, and recommends using a new override with a parameter ensureSecurity.

The MSDN documentation on the ensureSecurity parameter is a bit laconic: "true to enable security; otherwise, false."

I want to maintain backwards compatibility, i.e. don't want to require security. But I may want to use the new security features at some time in the future. What should I set this parameter to? I'm a bit confused that the decision whether to use the new security features is hardwired into the code via this parameter rather than being defined in the configuration file.

Sowmy Srinivasan

ensureSecurity must enable security if set to true. When set to false it should behave the 1.1 way

I hope this helps

Other posts contained a variety of opinions. So I decided to figure this out empirically. I wrote a windows service that exposed a class as a Wellknown service in single call mode, installed it on my server, wrote a quick client to connect to it and fired up Ethereal to watch the traffic between the two. To save you some time I’ll post my conclusion first:

The ensureSecurity flag is equivalent to permanently setting “secure=true”. SSPI encrypted communications is still possible with ensureSecurity set to false. When true, remoting only ignores the “secure” attribute of the channel element in the config file. It still uses the other attributes like impersonate on the server and tokenImpersonationLevel, domain, username and password on the client.

Before I get into the results, let me define a few terms for you:

ensureSecurity: A Boolean flag on the RemotingConfiguration.Configure method. Setting this flag requires all remoting connections to use security, regardless of the value of secure attribute in the app.config file.

secure: A Boolean attribute in the /configuration/system.runtime.remoting/application/channels/channel element of the app.config file for both the client and server. When ensureSecurity is true, this flag is ignored, otherwise, when security is true, encryption is enforced and impersonation is allowed, otherwise plaintext anonymous communication is used. Note that even when impersonation is turned off on the server, the user’s identity still flows to the server, it just isn’t impersonated. You can still authenticate the user and check their role membership.

impersonate: A Boolean attribute in the /configuration/system.runtime.remoting/application/channels/channel element of the app.config file for the server. When true, the process automatically impersonates the calling user. When security=false, setting this to true will cause an exception.

tokenImpersonationLevel: An enumerated attribute in the /configuration/system.runtime.remoting/application/channels/channel element of the app.config file for the client. This setting controls the level of impersonation the server is allowed to perform with your identity. Valid values are Identification, Impersonation and Delegation. When security=false, setting this to true will cause an exception. When connecting to a server set to impersonate, valid values are Impersonation and Delegation.

protectionLevel: An enumerated attribute in the /configuration/system.runtime.remoting/application/channels/channel element of the app.config file for the client. This setting controls the type of encryption to be used. All of the documentation I’ve read recommends setting it to EncryptAndSign I did not test to see if this attribute is used when ensureSecurity is true, mainly because I don’t understand the inner workings of NTLM/Kerberos security well enough to know what I’m looking at in Ethereal.

domain/username/password: Self explanatory. These attributes can be set on the channel element of the client to override the default identity.

Now, for the Ethereal results:

Test 1 (baseline plaintext configuration)

Server ensureEncryption = false secure = false Client ensureEncryption = false secure = false

Client to Server Packet 1 (plaintext URL)

Client to Server Packet 2 (plaintext Wellknown Service Object Info)

Server to Client Packet 1 (plaintext unknown)

Server to Client Packet 2 (plaintext response)

Result: Success with plaintext traffic, WindowsIdentity=Service Account

Test 2 (incompatible client/server security configuration)

Server ensureEncryption =false secure=true impersonate=false Client ensureEncryption =false secure=false

Client to Server Packet 1 (plaintext URL)

Client to Server Packet 2 (plaintext Wellknown Service Object Info)

Result: Failure, No response from server (other than ACK)

Test 3 (encryption turned on in config file only, with no impersonation)

Server ensureEncryption = false secure = true impersonate = false Client ensureEncryption = false secure = true tokenImpersonationLevel = "Impersonation" protectionLevel = "EncryptAndSign"

Client to Server Packet 1 (jibberjabber)

Client to Server Packet 2 (NTLMSSP)

Server to Client 1 (jibberjabber)

Server to Client 2 (NTLMSSP)

Client to Server 3 (jibberjabber)

Client to Server 4 (NTLMSSP response with client identity data)

Server to Client 3 & 4 (jibberjabber)

Client to Server 5 & 6 (jibberjabber)

Server to Client 5 & 6 (jibberjabber)

Result: Success with encrypted traffic, users identity is sent across the wire and is available through the Thread’s CurrentPrincipal, but it is not automatically impersonated. WindowsIdentity=Service Account.

Test 4 (encryption turned on using ensureEncryption flag only, with no impersonation)

Server ensureEncryption = true secure = false Client ensureEncryption = true secure = false

Result: Same as Test 3

Test 5 (encryption turned on both with flag and config file, with impersonation)

Server ensure=true secure=true impersonate=true Client ensure=true secure=true tokenImpersonationLevel="Impersonation"

Result: Same as Tests 3 and 4 except that the server impersonated the client’s identity.

Test 6 (Test 5 but with client’s identity specified using domain/username/password attributes)

Server ensure=true secure=true impersonate=true Client ensure=true secure=true tokenImpersonationLevel="Impersonation" domain=”domainname” username=”username” password=”password”

Result: Same as Tests 3 through 5, except that the client’s identity was as specified.

So there you go. I hope this gets a high enough page rank that it can reduce the confusion out there about secure remoting in .NET 2.0 because it's a really useful feature.

.NET Tip: InnerExceptions hold the detail...

Brian — Sun, 28 May 2006 17:10:00 GMT

In researching .NET Remoting today I came across a forum conversation about a common app.config error. In his response Michael Taylor writes:

...One of the changes that MS made in .NET 2.0 was to change the config file readers to support new features. Inadvertently they also changed the normally useful error messages to generic, meaningless messages. This was one of the those messages. It was listed as a suggestion to revert to the original, more meaningful messages and MS fixed the general configuration errors that would cause such messages but it is possible they missed some. I would verify that your config file is valid.

Unlike many previous Microsoft code libraries (does anyone else start twitching when someone mentions Commerce Server 2000?), the .NET Framework's exception handler is pretty good about giving you the details of what went wrong.

For example, I once spent an hour debugging an XML problem that had a similarly cryptic error message which I no longer remember. I finally thought to check the InnerException property of the exception and sure enough there was the detailed exception from the StreamReader telling me that I was an idiot. I'd forgotten to reset the position on a MemoryStream before reading it. It was late in the day ;-).

Since the root cause of my exception was different than the one mentioned above, I can't say how detailed the exception really was. However, today I encounted the “Configuration system failed to initialize“ exception Michael mentions, and while the primary exception was generic, the inner exception told me exactly what was wrong (I'd cut and pasted a new app.config together and had left out part of the element hierarchy).

In addition to remembering to check the inner exception while debugging, it's a good idea to log them. Especially if you're writing code that has a lot of catch-all exception handlers. A couple of short recursive functions make it easy enough:

private static string GetExceptionMessages(Exception e)
{
    System.IO.StringWriter sw = new StringWriter();
    System.CodeDom.Compiler.IndentedTextWriter tw = 
        new System.CodeDom.Compiler.IndentedTextWriter(sw);
    GetExceptionMessages(tw, e);
    return sw.ToString();
}
private static void GetExceptionMessages(System.CodeDom.Compiler.IndentedTextWriter tw, 
                        Exception e)
{
    if (e.InnerException != null)
    {
        tw.WriteLine(e.Message);
        tw.WriteLine();
        tw.Indent++;
        GetExceptionMessages(tw, e.InnerException);
    }
    else
    {
        tw.WriteLine(e.Message);
    }
}

Here I'm using the IndentedTextWriter from the System.CodeDom namespace, but you could always roll your own indented textwriter or just add a function to emit x # of tabs. Whatever works for you.

Just for grins, I added the code above and recreated the error condition, here's the log output:

Configuration system failed to initialize
    Unrecognized configuration section application.
    (C:\Code\FeedManager\bin\Debug\FeedManagerClient.vshost.exe.config line 4)

New (to me) blog

Brian — Thu, 16 Mar 2006 15:44:00 GMT

In addition to his Hard Working Words newsletter, copywriter and fellow Seattleite Chris Haddad now has a blog, go check it out!