I really wish a bank supported me giving them a public cert to encrypt use for all communications to me — and published a public cert that I could use to validate all communications from them.

They all handle SSL in the browser and they all support some kind of email-based notifications.

Then, ideally, I could configure my mail client to binfile anything from their domain that isn’t signed with the right key and encrypted to me.

On the other hand, it may be dangerous to stop training people that clicking on a link in email is never a good idea.

2.10. Robustness Principle

TCP implementations should follow a general principle of robustness:
be conservative in what you do, be liberal in what you accept from
others.

RFC 1122 elaborates with section 1.2.2.:

1.2.2 Robustness Principle

At every layer of the protocols, there is a general rule whose
application can lead to enormous benefits in robustness and
interoperability [IP:1]:

“Be liberal in what you accept, and
conservative in what you send”

Software should be written to deal with every conceivable
error, no matter how unlikely; sooner or later a packet will
come in with that particular combination of errors and
attributes, and unless the software is prepared, chaos can
ensue.
[...]

For anything expected to inter-operate “in the wild” with other implementations of a given standard or API this approach is optimal as both competitive advantage (how successful would a browser that only accepted valid HTML have been in a world with Netscape 1.0?) and user experience (always working as best as possible increases the chance of something working).

However, when an API is internal to a component, department, or a company it might well be better for implementations to reject fast invalid or malformed requests with informative error messages rather than attempting to proceed.

Within an organization the chances of integration testing catching an error before it affects user experience is much higher and failing immediately helps reduce the chances of future revisions of software needing to be “bug compatible” with easily avoided problems. It’s not a competitive advantage to try to muddle along with bad input in a world where there are no competitors. The entire system is more robust if each side of every API is careful that they are producing only valid requests and responses.

For example, if a company has standardized on UTF-8 as a wire format for text it is probably best if all new implementations of services validate that their input is correct UTF-8 at every edge and refuse to process anything that is invalid. Otherwise eventually some system is going to end up having to try and guess the correct encoding in order to proceed and serve valid data that came in an API that didn’t validate and has to go out an API that must be valid.

This only applies, of course, when both sides of an integration are new enough to be tested together but this applies to a lot of new development within an organization — a new capability is being added to an entire “stack” resulting in API revisions at each layer.

It’s dramatically easier to catch problems at the first opportunity and requiring the source of the incorrectness to correct it before proceeding than ending up years later with tons of special compatibility hacks where an API is versioned based on the different clients foibles rather than by design.

Internal APIs should be designed to be as easy as possible to use correctly — but once designed they should only work when used correctly.

A clear improvement, however. I particularly dig the new search. Once I figured out I could configure the Archive function to put archives from all my accounts into my local Linux box’s IMAP server I also liked the new Archive function. It nearly matches the system I maintained by hand anyway (manually periodically moving a bunch of mail into suitably named folders on my local Linux box).

Also nice is the “smart” Inbox — a feature I’ve liked in Mail.app and kind of missed in Thunderbird.

I’m not yet sure if I like the rest of the UI changes but I’m going to try them out for a bit before trying to reconfigure them back from whence they came.

Suppose further that you have purchased Cineform Neoscene to transcode that video into a nice-to-edit format.

Further suppose that this workflow was working fine on your old Vista 64-bit machine.

Now, you’ve installed CS4, Cineform, and transcoded some video. Then you import it into Adobe Premiere Pro CS4 and prepare to edit!

And PPro crashes. With an error referring to Timecode.cpp. Around line 930.

You are sad. You scour the entire internet in tens of milliseconds and find several posts talking about crashes in that location, but they have nothing to do with importing files created by NeoScene.

You try to play the files in Windows Media Player and they do not crash but they also are not playing at the right speed. Ah ha! That does rather smell timecode related.

Cutting this story short, install Quicktime 7. This workflow requires Quicktime to be installed or crazy broken things will happen. The requirements page for NeoScene does not talk about needing Quicktime on Windows.

With Quicktime installed, you re-run NeoScene and birds burst into song. Or rather, the output files are right and can play back in Quicktime and WMP. They can also be imported into PPro without mysterious crashing.

The day is saved.

I decide to do a clean install. The Windows 7 installer works great right up until it won’t accept the product key that came in the package. The “Upgrade” Win7 cannot install to a clean disk and then take the Vista product key to satisfy the upgrade. It’s not even clear how to get a clean install of Win7 now, since it seems the ONLY valid path is to have a copy of Vista installed already. Furthermore, it puzzles me why Win7 Pro Upgrade can’t tell me this instead of offering to do a clean install and then failing 45 minutes in.

It does work with a clean, unactivated Vista install immediately followed by a Win7 Pro upgrade. This was a needlessly frustrating introduction to Windows 7.

Once it is installed Win7 seems nice enough — an incremental upgrade from Vista. It’s not at all clear why Microsoft decided to inconvenience such a small population of people. The vast majority of users will get Win 7 with a new machine purchase. Very few, relatively, will buy Win 7 as an upgrade, but those are exactly the users Microsoft can least afford to make frustrated. These are the users most likely to be the people advising their friends and family about what to buy.

I wonder if this letter is entirely legitimate since it seems pretty desperate to convince me to sign up for a “free credit monitoring” period — but that doesn’t seem like a useful response to a single card number being compromised. Furthermore, I’d expect that the credit card issuer was also notified and their usual response to this kind of thing is “cancel all the cards and issue new ones” and that didn’t happen. Though maybe they didn’t bother because that card had already expired by the time “Network Solutions LLC” reported the breach.

Nevertheless I’m looking over statements since that date more carefully than usual to see if there’s any fishy transactions.

It’s not the same card as the one a credit card provider recently replaced mysteriously due to “a security breach with a merchant” that they naturally didn’t explain. That is the kind of behavior I expect from a bank.

I suspect that credit card companies aren’t interested in increasing the security of cards because paying for the fraud is cheaper than the lost sales due to lower convenience.

Of course, every time I get a new card number I would have to go change the umpty-jillion places that have the card number for automatic billing if most of those places didn’t have single-merchant numbers. This is a case where the issuer with the capability to issue single-merchant card numbers wins. I’ll probably switch the rest of them over next time the card number from the company that doesn’t support single-merchant numbers gets compromised.

Finally just before giving up and working on something else for a while, I try to run it as an admin on a whim. It starts. !!!

So I go and check “this program wants to run as an administrator” in the properties of the start menu shortcut. Perhaps now it will actually work.

I did have to tweak the voicemail settings so the WAV files were actually audible without turning the PC speakers waaay up.  In /etc/asterisk/voicemail.conf, I set volgain to 8.0 (and installed sox).

Asterisk has “taken care of” 358 calls (callers with no CID or CID identifying them as toll free numbers) since I set it up early last month.  They went straight to voice mail without ever ringing my phone.  Very few of them left messages.

(Yes, I still plan to post something more descriptive with configs describing as much of my setup as seems reasonable.)

Despite being on all the “do not call” lists I still get too many (= some) unsolicited calls representing entities rather than people I know. My new crazy complicated answering machine can now route them straight to voicemail where they will not leave a message but also not ever ring my actual phone.

I don’t just blacklist them outright because once and a while one of those suspicious looking numbers is actually a call I want (“Dear Ken, Is it really you buying all this shiny? –your credit card”) but all of those DO leave messages.

Several Ubuntu updates later I noticed libyahoo2 had been upgraded and, sure enough, this version worked.

I updated the Git repository mentioned in that post but it is likely if I continue to work on it it will go to python-yahoo2 on GitHub.

Pyrex’s blindness where “const” is concerned is pretty annoying.