話題としての面白さは２点あると思うのですが，タレコミからは両方とも抜け落ちているように思います．

まず１点目は，アマゾンのような通販を使っていると，リビジョンの違いに気付かず騙されやすい，という話です
リビジョンが違っても，製品名や商品識別コード(JANコード等)は同じものが流用されるためです．

次に２点目．リビジョン違いと言っていますが「B85M-HD3」の場合は，なんと基盤から再設計しています．
写真を見ると一目瞭然です．
マザーボードですから基盤が変われば，それはもう別の製品です．しかも部品も違う．当然性能も変わります．
これを同じ製品名で販売しちゃうのは，いくらなんでもやりすぎだと思います．

別コメントでも指摘されていますが，リビジョンに伴う軽微な仕様変更は，昔からある話です．
細かいところまで気にする人は，今でもパーツ屋さんの店頭に赴き，現物のシルク印刷等を確認してから購入しているはずです

一方，私のように，リビジョン違いなど気にせず型番だけで購入しているような人は，
「B85M-HD3」のような豪快な仕様変更を引いてしまうと…たぶん気付かずそのまま使いますね．

原材料名を示したに過ぎない商標は、「原則」商標法3条1項3号の拒絶理由を有し、登録になりません。

ここで「原則」と言ったのは、このような商標であっても、シャープによる使用の結果「IGZOっていったらシャープじゃん常考」って世間一般に認知されると、例外的に登録されるからです(商標法3条2項)。

従って、今回はこの商標登録は潰れてしまいましたが、これにめげずに「IGZO」を使用し続ければ
(登録になっていないからといって使用が禁じられるわけではないので)もしかしたら再出願して登録になるやもしれません。

#でもこれってITO基板に商標登録認めるようなもんだし、個人的には登録になって欲しくないなあ

「貴様、鉄ちゃんだな」
「いえ、違います」
「では、TDKと言えば？」
「東洋電機製造」
「連れて行け」

　数年前、SimCity2000を引き合いに出して担当の人に同様の質問をしましたが、
半径数キロの範囲で受信を行うので、マイクロ波が集中して火災を起こす事はないと言ってました。

　担当の人はSimCityを知りませんでした(笑)

これは注意しなくても分かるだろう 部門より

ファイルが復元できないようにするには、ファイルをランダム値で上書きして、０で上書きして、Ｆで上書きして、またランダム値で上書きして…を何十回もやらないといけないらしい。

残留磁気探索によるデータの析出の話ですね。

フロッピーディスク時代にはたしかに残留磁気探索によるデータ復元が可能な場合がありましたが、今の高密度HDDでは1回の上書きで復元が不可能であるとNISTもNSAも主張しています。

仮に復元が可能だとしても、日本の警察には無理でしょうから、アメリカなどと共同捜査を行う必要があるでしょうし、今の高密度のディスクから児童ポルノであることが確認できるような広範囲の残留磁気探索による復元を行うのは数千万円の費用じゃすまないでしょう。

どうしても心配ならば、国防総省などは「ある文字, その補数の文字, 任意文字」の3回で上書きしているそうですから、それに従えば良いのではないでしょうか。ただ、残留磁気より、代替セクタ処理で退避された領域とか、Windows からアクセスできない隠し領域・HDD独自のキャッシュ領域をどうするかを心配された方が良いと思います。

今のところ技術的なコメントがないのが残念ですが、簡単にSIMカード周りについて調べてみたのでツッコミください。
英語版Wikipediaの説明はGSMについてのようなので、W-CDMAでもそうなのかは不明。
製造時に書き込まれる「暗号鍵」はKiというコード。今回漏洩したとスノーデンが言ってるのはこれ。 GSMの頃はカードの脆弱性や後述のチャレンジレスポンスの暗号が弱くて抜き取れるものもあったらしい。
網にアタッチするときに端末はSIMカード内のIMSIを送信。網はそれに紐付いたKiをDBから取り出して、ランダムな値(ノンス)に署名してSRES_1を生成しておいて、ノンスを端末に返す。端末でも同様に生成したSRES_2を網に送信して、同じならコネクション確立。
この過程でお互いにKuという通信そのものの暗号鍵を生成するらしいけど、詳しいことは載っていなかった。
盗聴するにはコネクション張る時のノンスが必要そう。Diffie-Hellmanとか使わないのかな? 最近だと違うかもしれないですね

「ブランドは不滅ではない」
「ハードウェアで一時は名声を得るも、現在は見る影もない」

おっと、ソニーの悪口はそこまでだ。

ด้้้้็็็็็้้้้้็็็็็้้้้้้้้็็็็็้้้้้็็็็็้้้้้้้้ (・ω・) ด็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็็. ← Unicode 合字 の例 （IE で表示すると、本来のコメント欄の領域を多少はみ出して他の情報に重なります）

Unicode は複雑化されすぎて、普通のプログラマーが理解できる範疇を超えているように思えます。多言語に対応させる場合 Unicode を採用せざるを得ないのですから、絵文字といった余計な拡張を加えて更に複雑化させないでほしいです。合字についても、Unicode の仕様において、ありとあらゆる方向に無限に伸ばせるような仕様にせずに、個数などを限定すれば良かったのではないでしょうか。

私の場合、Unicode について勉強してみたところ、適切に validation するのは極めて難しいことが分かったので、UTF-8 といったUnicode文字集合の符号化方式 を使うのは諦め、EUC-JP を主に使っています。勿論、その場合には多言語化は諦めなくてはなりません。

Webアプリケーションで、UTF-8 などの文字コードを用いた場合、Unicode の合字や制御コードを適切に validation しないと、ページのほぼ全体を変な記号文字で上書きされてまともに表示できなくする、アクセスしただけでブラウザがフリーズする状態にするといったサービス拒否攻撃の被害に遭う恐れがあります。しかしながら、PHP などのWebアプリケーション開発言語において、PHP の制御コード等を適切に validation する関数は用意されていません。

勿論、これはユーザーから入力されたUnicode文字を第三者に出力する全てのネットサービスに言えることで、LINE ではUnicodeの制御文字によってLINEアプリがフリーズしたり起動できなくなったりする所謂「LINEウイルス」の被害が多発しています。また、Windowsの世界でも同様でUnicodeの不正な制御文字を投稿されることによって、Skype・ニコニコ動画・アメーバピグでエラーが発生するといった被害があり、UnicodeCrashGuard といった対策ソフトまで使われている始末です。

ちなみに、このコメント最上部の例は、タイ文字の上に結合用の声調符号を付けたものです。本来、タイ語の声調符号はタイ語の言語文法上複数個付くものではありませんが、Unicode ではそれが許されるので、無限に伸ばして上下のスペースを占有することができてしまうのです（IEで表示する場合）。

誰も言わないから書くけど、中華フォント問題が切実。
日本語フォントを考慮していないアプリはクッソ気持ち悪い中華フォントになる。
まぁこれはアプリが悪いというよりOSとしてフォールバックフォントを指定できないのが諸悪の根源。
あとマップがクソなのでgMaps Pro購入必須。GMailが扱えるメーラーもロクなのがないのでMetroMail購入必須。
ただどちらもiOSやAndroidのメーカー純正品よりは遙かに劣る。
ついでに言えばIMEもあまり良くないしiOSやAndroidの用にATOKに逃げられない。カーブフリックをオフにしたい。
アプリが少ないのも痛いけど、Webサービス業者の純正クライアントも一番力を入れられてないのでショボいことが少なくない。

利点は低スペックでもiOSやAndroidより快適に動くくらいかな。
あとシャッター音が普通にボリュームと連動するから音を強制されないのが割と助かる。