PortalRunnerによる楽しい16分の動画で、こんな前提が語られています：

これは猫の写真が入った画像ファイルです。でも、拡張子を.MP4に変えれば、同じ猫の動画ファイルになります。.PDFに変えれば、この動画の台本が入ったテキスト文書になります。名前を変えるだけで、有効なウェブページにも、.ZIPアーカイブにも、PowerPointのプレゼンテーションにもなります。こうしたファイルは「polyglot（ポリグロット）」と呼ばれることもあります（もっとも、通常この言葉は複数のプログラミング言語で動作するコードを指します）。

こうしたファイルが現実に必要になることはまずありませんが、普段あまり意識することのないファイルフォーマットのヘッダーや構造に対するさまざまなアプローチを垣間見られる、面白い試みです。

動画の中には、興味深い脱線もあります。ファイルの拡張子は、ファイルを適切なアプリケーションに届けるための手段にすぎないのか、という問いです。もし.jpegを.gifにリネームして、どちらもPixelmatorで開くようにしていたら、Pixelmatorは内部でそれがJPEGファイルだとできる限り検出しようとすべきでしょうか、それとも「これはGIFファイルではないようです」というエラーを出すべきでしょうか。

ウェブにもMIMEスニッフィングという形で似たような課題があります――「MIME」はいわばウェブにおける拡張子のようなもので、「スニッフィング」とは他の情報を無視して中身だけからファイル種別を判別することを指します――そしてこれにはセキュリティ上の懸念がありました。悪意のある第三者が、一見無害なものを装って悪意あるコードを紛れ込ませることができたからです。……動画が面白半分にやっていることを、悪用したようなものです。

このブログにしてはかなりテクニカルな話ですが、MIMEスニッフィングのWikipediaの項目の中に、ふと目を引かれた一節があります：

[MIMEスニッフィングは今も一部のブラウザで使われています。しかし、]コンテンツに正しいMIMEタイプを割り当てていないサイトでも、それらのブラウザでは正しく表示されてしまうことで、正しいラベル付けが促されなくなります。その結果、そうしたサイトを動作させるためにコンテンツスニッフィングが必要となり、ウェブ標準やセキュリティのベストプラクティスとの間に互換性の悪循環が生まれるのです。

MIMEスニッフィングより何十年も前に、ジョン・ポステルはポステルの法則という言葉でこの考え方の本質を言い表しました――「送信するものは保守的に、受け取るものは寛容に」――。魅力的な考え方ではありますが、これも上記の引用と似たような問題を抱えています：

欠陥が事実上の標準として定着してしまうことがある。プロトコルのあらゆる実装は、その異常な振る舞いを再現しなければ相互運用性を保てない。[…]このような環境で相互運用性を確保することは、しばしば“バグごとの互換性（bug-for-bug compatible）”を目指すと表現される。

ポステルの法則はコンピュータシステムに出入りするデータを対象としたものですが、私にとってその前提は、より普遍的で、さまざまな場面に当てはまるデザイン上の問いです。「受け取るものは寛容に」という姿勢は親切に思える一方で、ユーザーに悪い習慣を植え付け、より大きな影響を及ぼす可能性もあります。これが当てはまるようなプロジェクトでは、こう自問する価値があります。ユーザーが間違えても、わざわざ手を貸して助けるべきなのか。それとも、将来のためになると考えて、より厳格にルールを守るよう教えるべきなのか。

Command Line Interface Guidelinesに、以前紹介したものですが、この点をよく示す例がありました：

提案したコマンドを実行するかどうかを尋ねることはできますが、強制すべきではありません。例えば：

$ heroku pss
› Warning: pss is not a heroku command.
Did you mean ps? [y/n]:

修正した構文を提案するのではなく、最初から正しく入力されていたかのように、代わりに実行してあげたくなるかもしれません。ときにはそれが正しい対応であることもありますが、常によいとは限りません。

まず、無効な入力が必ずしも単純なタイプミスを意味するとは限りません――多くの場合、ユーザーが論理的な間違いをしたり、シェル変数を誤用していたりすることを意味します。ユーザーの意図を推測することは危険な場合があり、とりわけその結果として状態が変更されるような操作ではなおさらです。

次に、ユーザーが入力したものを勝手に変更してしまうと、ユーザーは正しい構文を学べなくなることに注意してください。実際上、ユーザーが入力した方法が有効で正しいと認めたことになり、それを無期限にサポートし続けることになります。その決定は意図を持って行い、両方の構文を文書化してください。