  |
はてなキーワード: デファクトとは
いま、この転換点において、皆さまとご一緒できることを光栄に思います。同時に、私たち国内SIerにとっての責務でもあります。
本日は、世界の“秩序”の断絶、心地よい物語の終わり、そして、巨大な力を持つプレイヤーの競争がほとんど制約を受けない厳しい現実の始まりについてお話しします。
しかし同時に、国内SIerのような「中堅の担い手」は無力ではない、と申し上げたい。私たちには、信頼・安全・持続可能性・顧客の主権・データの保全といった価値を体現する新しい秩序を、実務から積み上げていく力があります。
私たちは毎日のように思い知らされています。いまは、巨大プラットフォームや巨大ベンダー、地政学リスクを背景にした技術覇権が競い合う時代であること。オープン性や互換性、フェアなルールに支えられた前提が薄れつつあること。そして、強い側が条件を決め、弱い側は受け入れざるを得ない局面が増えていること。
古典的に言えば「強い者はできることを行い、弱い者は耐えねばならない」という構図です。これは不可避だ、これが自然な競争原理だ、と片付けられがちです。そして、その論理を前にすると、私たちには「波風を立てずに合わせる」強い誘惑が生まれます。摩擦を避けるために順応する。相手に合わせれば安全が買えると期待する。
では、選択肢は何でしょうか。
1978年、チェコの反体制知識人ヴァーツラフ・ハヴェルは『無力者の力』という論考を書きました。そこで彼は、体制がなぜ維持されるのかを問いました。
彼の答えは、一人の店主の例から始まります。店主は毎朝、店先に標語を掲げる。「万国の労働者よ、団結せよ！」。本人は信じていない。周囲も信じていない。それでも掲げる。面倒を避けるため、従順さを示すため、波風を立てずに“やっているふり”をするために。そして、どの通りの店主も同じことをするから、体制は続いていく。
暴力だけではなく、人々が、内心では虚構だと知りながら儀式に参加することで、体制は維持される。ハヴェルはこれを「嘘の中で生きる」と呼びました。体制の力は真実ではなく、皆が真実であるかのように振る舞うことから生まれる。そして脆さも同じところにある。たった一人が“看板を外す”だけで、幻影にひびが入る。
いま、企業としても、業界としても、私たちは「看板を外す」時です。
---
長い間、ITの世界には「ルールや標準が機能し、相互運用性が担保され、勝者も敗者も一定のフェアネスの中で競争できる」という物語がありました。国内SIerも、その物語の上で成長してきた面があります。標準化、ベストプラクティス、認証制度、ガイドライン、そしてグローバルに広がる巨大なプラットフォーム。私たちはそれらを称賛し、活用し、その予測可能性の恩恵を受けました。
もちろん、その物語が“部分的に虚構”であることも知っていました。強い側は都合が悪いときに例外を作れること。ルールの適用が非対称になり得ること。互換性や標準が、実態としては特定のエコシステムに誘導する装置として働くこと。そして、契約条項、価格体系、APIの変更、提供地域や機能制限などが、力関係の影響を強く受けること。
それでも、その虚構は便利でした。巨大プラットフォームが提供してきた“公共財”も確かにあった。スケールする計算資源、安定した開発基盤、セキュリティ機能、グローバル展開の足場、部品としてのOSSやツールチェーン、紛争を減らす共通言語。
だから私たちは、看板を掲げ続けました。「オープン」「中立」「相互運用」「ベストプラクティス」という言葉を、実態が追いつかない場面でも口にしてきた。そして、言葉と現実のずれを大きく指摘することを避けてきた。
率直に申し上げます。いま起きているのは“移行”ではなく“断絶”です。
---
過去20年の間に、金融危機、パンデミック、エネルギー制約、半導体不足、サプライチェーン混乱、サイバー攻撃の常態化、そして地政学リスクが、極端なグローバル統合の脆さを露呈させました。
さらに近年、巨大な力を持つプレイヤーが「統合そのもの」を武器として使い始めています。値上げや課金体系変更が交渉力になる。契約や利用規約、認証・ID、クラウド管理基盤が実質的な拘束力になる。提供停止や機能制限、地域制約が、企業や組織に圧力として作用する。サプライチェーンが“突かれる弱点”になる。
「統合すれば相互利益」という前提のまま、“嘘の中で生きる”ことはできません。統合が従属の源泉になった瞬間、前提は反転します。
かつて中堅の担い手が拠り所にしてきた「みんなで決めるはずの場」も弱まっています。標準化が追いつかない。デファクトが事実上のルールになる。透明な合議より、エコシステムの都合が優先される。結果として、多くの企業が同じ結論に向かい始めています。
人材、セキュリティ、データ、クラウドの選択肢、重要部材、運用ノウハウ、AIの基盤、そしてサプライチェーンにおいて。
自分で守れない者は、交渉の選択肢がありません。ルールが守ってくれないなら、自分たちで守るしかない。
ただし、行き先を直視すべきです。全員が要塞化すれば、コストは上がり、分断は進み、脆さは増し、持続可能性は下がります。
そしてもう一つの現実があります。巨大プレイヤーが、ルールや価値の“建前”すら捨てて、露骨に取引主義へ傾けば、関係性を恒常的に収益化することは難しくなる。顧客もパートナーも、保険を買い、選択肢を増やし、分散します。これは「主権」を取り戻す動きです。かつてはルールに支えられていた主権が、これからは「圧力に耐えられる能力」によって支えられるようになる。
古典的なリスク管理はコストがかかります。しかし、そのコストは共有できます。レジリエンスへの共同投資は、各社がそれぞれ要塞を作るより安い。共通標準は分断を減らす。相補性は正の和を生む。
国内SIerにとっての問いは、「この現実に適応するか否か」ではありません。適応は不可避です。問いは、ただ壁を高くして閉じこもるのか。それとも、より野心的なことができるのか、です。
---
私たち国内SIerは、比較的早い段階で警鐘を受け止め、姿勢を変え始めました。
「日本で長く通用した前提」、つまり、既存の取引慣行や、系列的な安定、特定ベンダーとの強固な関係が、そのまま将来の繁栄と安全を保証するという前提は、もはや十分ではありません。
私たちの新しいアプローチは、いわば「価値観に基づく現実主義」です。別の言い方をすれば、理念を持ちつつ、現実に即して動く。理念と実務の両立です。
顧客と社会に対する説明責任。セキュリティとプライバシー。データの保全と可搬性。人権と安全に関わる領域での慎重さ。重要インフラを支える品質と継続性。
同時に、私たちは現実主義でもあります。進歩は多くの場合、段階的です。利害は一致しないこともある。すべてのパートナーが同じ価値観を共有するわけではない。だからこそ、目を開いたまま、戦略的に、広く関与する。世界を「あるがまま」に扱い、「こうあってほしい世界」を待たない。
私たちは、関係の“深さ”を価値観に合わせて調整します。影響力を最大化するために、関与は広く、依存は偏らせない。流動化する秩序と、その先にある賭け金を踏まえて、現実的に動く。
そして今後は、価値の強さだけに頼らず、「強さの価値」も積み上げます。
---
人材育成と採用、設計・開発・運用の標準化、サイバーセキュリティ、AI活用、検証環境、そしてミッションクリティカルを支える運用力。加えて、特定技術への過度な依存を減らし、移行可能性と可搬性を高める。
生成AI、データ基盤、ゼロトラスト、ソフトウェアサプライチェーン対策、Observability、そして重要領域の内製力強化。これらは“コスト”ではなく、交渉力と継続性を生む“資本”です。
守りは、事後対応ではなく、設計・調達・運用に埋め込みます。国内産業の裾野とも接続し、調達・開発・運用の循環を厚くする。
特定の巨大プラットフォームや単一のモデル提供者に賭け切らない。複数のクラウド、複数の実装選択肢、複数の調達経路、複数の人材パイプラインを持つ。
グローバル課題への対応も、論理は同じです。論点ごとに連携の形を変える「可変幾何学」でいきます。
データ主権では、顧客がデータの所在とアクセスを決められる設計原則を共同で整備する。
標準と相互運用では、地域・業界をまたぐ参照アーキテクチャとオープンAPIの合意を積み上げる。
AIでは、特定の覇権や特定の巨大クラウドに“二者択一”を迫られないよう、モデル、データ、評価、ガバナンスの選択肢を確保する。
これは、甘い理想論ではありません。機能不全になりつつある“建前の場”に頼り切ることでもありません。論点ごとに、動ける相手と動く。必要なら多数派を作る。そうして、将来の挑戦と機会に備える、密度の高い接続網を作るのです。技術、投資、人材、運用、文化のレイヤーで。
国内SIerのような中堅の担い手が連携しなければならない理由は単純です。設計図の会議に席がなければ、要件は上から降ってきます。席がなければ、食卓のメニューになる。
巨大プレイヤーは単独でも戦えます。市場規模、研究開発、資本、影響力がある。しかし国内SIerは違う。にもかかわらず、巨大プレイヤーと一対一で交渉し続ければ、交渉は弱い立場から始まります。提示された条件を受ける。自分たち同士で「より従順な方」を競い合ってしまう。
それは自律ではありません。従属を受け入れながら、自律しているふりをすることです。
---
「真実の中で生きる」とは何か
ここで、ハヴェルに戻ります。
私たち国内SIerが「真実の中で生きる」とは、どういうことでしょうか。
「オープンでルールに基づく、互恵的な統合」という言葉を、現実がそうでないのに唱え続けない。いまを、巨大プラットフォーム競争が激化し、統合が交渉力と拘束力の源泉として使われる時代だと認める。
第二に、一貫して行動することです。
相手が誰であれ、同じ基準で評価する。都合の良い相手の一方的変更には沈黙し、別の相手には批判する、という態度は「看板を掲げ続ける」ことになります。
第三に、自分たちが信じるものを“機能する形”で作ることです。
標準準拠を唱えるだけでなく、移行可能性を担保する設計、相互運用の実装、透明な運用ルール、監査可能なガバナンスを、合意と実装として積む。復古を待たずに、動く枠組みを作る。
強い国内基盤を持つことは、企業にとっても最優先です。分散は経済合理性であるだけでなく、誠実な姿勢を貫くための物質的基盤です。報復や圧力に脆弱な状態のままでは、理念を語る資格すら維持できない。
---
さらに、私たちは理解しています。いま起きていることを直視し、合わせて自分たちを変える決意が必要だということを。
この断絶が求めるのは、単なる適応ではありません。世界をあるがままに見て、誠実に語り、国内で強さを作り、連携して動くことです。
古い秩序は戻りません。嘆いても戦略にはならない。ノスタルジーは戦略ではありません。
しかし、断裂の先に、より良いものを作ることはできます。より強く、より公正で、より持続可能な形を。
それが、中堅の担い手である私たちの仕事です。要塞化した世界では失うものが大きい一方で、本当の協働が成立する世界では得られるものも大きい。
虚構に合わせるのをやめ、現実に名前をつけ、国内で強さを作り、連携して動く力です。
それが、国内SIerの道です。私たちはそれを、開かれた形で選びます。
この辺りの記事を読んだ感想。（これらに限らず開発環境に関する記事全般にいつも感じること）
https://blog-dry.com/entry/2026/01/02/145952
https://giginet.hateblo.jp/entry/2026/01/14/101200
と分野が変わり、
会社員→派遣→フリーランス→会社員（何度か転職）→フリーランス
と働き方も変わってきた。まだ変わるだろう。
こういうキャリアだと自分なりの開発環境をなかなか育てることができない。
会社PCである程度育ててもその設定を個人PCに移せなかったり（情報セキュリティ上）して自宅と会社の使い勝手の差が出て使う気が起きなくなってしまったりする。
いわゆるITドカタが多く多忙で個人開発などする時間などなく、仕事以外で開発環境を育てるということもなかなかできずここまできた。
こういう人多くないですか？
私はemacsのorg-modeだけは仕事/プライベート問わず使い続けています。
それ以外は、できるだけデファクトなツールを限りなくデフォルト設定で使うという戦略にするしかないかと思うのだが、emacsのキーバインドだけは譲れない（けっこうこれがネックになって面倒）。
昔は夫婦別姓に賛成だった。
「選択肢があることは良いことだ」「誰にも迷惑かけない自由なんだから」という、まぁよくあるリベラルっぽいノリで。
でも、最近になって、ふと「これはちょっと違うかもしれない」と思うようになった。
いや、別に誰かが別姓にしたいと言うこと自体を否定するつもりはない。実際、戸籍の手続きや名前の変更が面倒くさいというのは理解できるし、そういう不便さは制度の整備である程度解消できるものだと思ってる。問題の本質はそこじゃない。
「選択的」って、言葉だけ聞けばすごく良い感じがするじゃないか。
でも、その「選択肢」が社会的な圧力のトリガーになるなら、それって本当に自由か？と思う。
ここ数年、選択的夫婦別姓に否定的な意見を言うと、まるで人間性に問題があるかのような扱いを受ける。
保守的だの、頭が固いだの、時には「頭悪そう」とか「昭和脳」だの。
ああ、なるほど。選択肢が与えられた結果、選ばなかった側が吊し上げられるのかと。
で、これが怖いのは「選択できる」とされているはずなのに、結局は「別姓を選ばないと非進歩的だ」という空気がじわじわと支配してくるところ。
制度上は自由、でも社会的には強制。そういう「自由」は、自由じゃない。
現制度においても、どちらの姓を選択するかという自由はあるが、夫側の姓を採用することがデファクトで強制的であるという点が問題のはずだ。
結局のところ、社会的な要請や機運が高まったりしないといけないと、このような変更はハードルが高いのだろう。
正直に言えば、最初は賛成していた自分が、いつの間にか「同姓を選んだら何か言われるかもしれない」という圧力にストレスを感じて、気づいたら立場を変えていた。
なんというか、リベラルの皮をかぶった全体主義って、こういうのを言うんじゃないかと思った。
「でも今は同姓を強制されてる人がストレスなんだから、反対派も同じぐらいストレスを感じれば平等だよね」みたいな態度が透けて見えるのもキツい。
加えて、こういう制度が通ったあとに、「夫婦」だけじゃなくて「親子」や「戸籍制度そのもの」とか、適用範囲がどんどん拡大していく流れになるのでは？という懸念もある。
最初は「選択的」だったのに、気づいたら何も選べない社会になっていくのだろう。わりと静かに、でも確実に起こる。
夫婦別姓を推す人たちが全員そうだとは言わない。けど、「ああ、これは賛成することが“善”で、反対は“悪”とされる世界だな」と思ってしまった時点で、ぼくはもうその運動に乗る気にはなれなくなってしまった。
TypeScript ベースのフルスタックフレームワークが増えてきたね。
フロントエンドもバックエンドもTypeScript 実装できてとっても嬉しいね。
しかし、バックエンドとフロントエンドと密結合な事実はとても怖いんだ。
フロントエンドの成長速度はとても早い。
React がデファクトになりつつあるが、 React ベースのフレームワークは群雄割拠だ。
むしろ、 React を排する新しい技術も出てくるくらいの戦国時代なんだ。
フレームワークを選定時、各言語でも多くて3つ程度に絞られるのではないか。
成熟しつつあるバックエンドと成長中のフロントエンドを一緒のライブラリで運用すること。とても怖い。
特に TypeScript はフロントエンドを祖に持つので、フロントエンドの事情がフレームワークの開発ロードマップの意思決定に強い影響を与える。
フロントエンドに破壊的変更が加わった時、バックエンド側にも影響を与える。
他フレームワークにおけるフロントエンドの実装について、あの Ruby on Rails ですらバージョン上がるごとにフロントエンドに破壊的な変更が入る。
まぁ View の取り扱いの黒魔術は魔境だから極力触りたくないが、バックエンドの側面のみを切り出した API モードであれば爆速の開発体験とテスト機構により信頼性が高い。
それなら、フロントエンドとバックエンドを別々に管理にしたい。
いや俺は、TypeScript のアプリケーションが嫌いなのかもしれない。
フォルダ設計も、テスト機能の整備も、ORMの設定も、最初から設定する必要があるから。面倒なんだ。
どうせ TypeScript アプリケーションの設計は設計者の自己満足になる。
そして、設計者は運用の責任を全うせずいなくなる。ドキュメントすら残さない。
それなら、規約で縛るフレームワークの方が、後任がキャッチアップしやすい。
設計者が知識を普及もしくはドキュメントを整備して知識の移転に心を砕いてくれれば、設計方針を汲み取りやすいのだが、そうしてる設計者はいるのだろうか。
後任のために、せめてものドキュメンテーションを心がける。
あれはNTTのうんこ通信網をどうにかすると言うだけの技術で、ほとんど意味ないからだよ。
NTTは光だけでスイッチングするから低遅延で高速だと言うだろ？
でもそんなことをせずに実現しているところがある。
NTTなどのオールド通信会社のネットワークは、電話の通信網を基本にしているから、細かい基地局と基地局の間を回線でつなぐという構造をしている。
そのため、IP通信になった今でも、その通信網を一つ一つパケットがルーティングされて流れていくと言う構造になっている。
だから、低遅延にするならオールフォトニクスにして光のままでルーティングする必要がある。
けど、それって昔ながらの古いネットワークだから必要なだけだって、もっとシンプルなネットワークだったらいらないよね？
巨大なデータセンター間を専用の光回線でつなぐと言う商売をやっている専門の通信会社は、そんな面倒くさいネットワークではなく、シンプルに両端にのみ光電変換をする装置を配置する構造にすることによって、IOWNとか言わんでも高性能低遅延低消費電力のネットワークを構築しているわけです。だから、本質的にAPNでございだとか、マルチオーケストレータでございますとか言わなくても、いらないんですよねそんなの。
データセンターの中の通信技術なら既にIOWNより優れたものがある。
インターネットのトラフィックは平等にルーティングされているのではなく非常に偏っているのは周知の事実であり、高性能なネットワークが必要なのはここなのでここだけにシンプルなネットワークを適用すればIOWNなんていらないである。
今は親方電電虫が言ってるからお付き合いでやってる企業は多いが、温度差が激しい。もうすがる先がここしかないところはやっているが、そうでない所は冷めた目で見てる。
NTTが自社の環境こそがデファクトだと思い込んで、それに対応させるだけのガラパゴスな技術に名前を付けて出してしまった、それに取り巻きがやんややんやの拍手をしていると言うのが今のIOWNだよ。ISDNと同じ。
オープンソースだと、無償の名の下に自分に都合の良いものを世の中に広げて、別の稼ぎの足がかりにしたりする。
つまり例えば自社製品向けの潜在的市場を作ってたりするんだよ。
Android なんかが良い例だ。あれも無償でオープンソースのOS（一部無償プロプラ含む）をバラまいて、自社のアプリストアやOSの仕様を通じて、アプリストア税を取ったりOSのログから効果的な広告を出せるようにしてより高額な広告を売ってる。他社がアプリストアを出しても勝てないだろ？その理由は Android が先に OS ごと無償でデファクトになってしまってるからだ。
ああいう会社はいわゆる三段論法的な考えで、「無償行為AでBという環境を作る」「Bの環境で自社製品Cを売れば儲かる」と考えられるから無償行為Aをすることができる。
逆に日本の企業は、ほとんどが「製品Aを売ったら儲かる」というビジネス以外できない企業が多すぎないか？と思ってる。そういう訳なのでオレは Abema がやってることはやる価値があると思うぞ。
MS OfficeやPhotoshopからデファクトを奪うレベルのオープンソースソフトが未だに出てこないのはどういうこと？
LibreOfficeにしろGIMPにしろ、いつまで経っても業務でまともに使えるレベルにならないし。
あとGUIも、オープンソースにおける決定版がこれまた待てど暮らせど出てこない。
てかOSSって、便利である以上に複雑怪奇なUIで、ユーザを苦しめるソフトばっかり作るよね。
(Perl、sendmail、bind、TeX、gnuplotなどなど挙げてったらキリがない)
なんでユーザの使い勝手というか、そこら辺のデザインがこうも蔑ろにされるのか意味がわからん。
結局、viとemacsどっちがいいかという、傍から見たらきのこたけのこ未満のしょーもないレベルで使い勝手を言い争っていた頃から、OSS界隈は何も変わっちゃいないと。
学校ではiPadを使ってるんだけどどのパソコンを与えるかに悩んでる。
まずはWindows。なんだかんだいってまだデファクトはWindowsだよね。ただ自分が使ってないし、Excelも買い与える予定ない。必要があればSpreadSheet使わせる。あんまり直近で良いことはなさそう。
Mac。自分も使ってる。ただ高いよね。あと、何に使うんだ？ほとんどブラウザしか使わないのでは？なにかに興味を持ったら選択肢は広がるか。でもそれ言ったらWindowsも同じか
CheomeBook。大体のことはこれで済む気がする。でもいろんなことやりたくなっても選択肢が狭いよね。プログラミングとか、動画編集とか？
Linux。やりたいことはググって自分で環境構築させるスパルタ教育。うちの子はそこまでやらないとおもうからなしかな。
とりあえずChromeBookで様子見なのかなぁ。
平均がよ、平均が。
もちろん人それぞれよ。
まず驚いたのは、店員のお姉さん達が俺との会話で「sir」を付けてくれるの。
敬意を持った言葉遣いをしてくれる。
もうこの時点で他の料理屋では考えられないよね。
裏を返せばちょっと浮いた世間ズレした店とも言えるんだが、メイド喫茶のロールプレイみたいなもんで、その言葉遣いで「あっ俺日本に来たわ」って感じがする。
そんで注文してしばらくしたら料理が運ばれてきた。
「Excuse me, sirrrrrr」って。
後ろから料理が運ばれてきたからね、俺がびっくりしないようにちゃんと断り入れながら運んできてくれた訳だ。
これも感動よね。他の店でそんな気遣いないよ？チョベリグよもう。
そんで、極めつけには「Is that everything, sir?」と、ちゃんと全部の料理が来てるか確認が飛んできた。
なにそれ怖い。ここただの料理屋ですよね。ボク独りで昼飯食いに来ただけですけど。
もうどうかしてるんじゃない？良い意味で。
ゴトンと皿置かれて、なーんも言わずがデファクト。もう慣れたわ。
まあ確かに雑に「Have a good one.」とか言ってくれる店はあるけど、アジア料理店はガチのマジで無言。
React.jsを使うと、Node.jsの学習って無駄になるんでしょうか？
例えば、何か新しい機能を追加したい、となったらNodeのライブラリじゃなくて、reactのライブラリを使いますよね？ もしくは普通にJSで書くとか（？）
無駄にはなりません。
まず、「Node.js、Deno」はサーバー･サイドJavaScript、「React」はクライアント･サイドJavaScript(つまりブラウザ側)なので、役割分担が違います。
ただし日本のプロの世界では「Node.js、Deno」はイマイチ人気は無いので、プロを目指すなら無駄になるでしょう。
そうですが、Next.jsは人気は無いので、Reactを強く推奨します。
Google Trendsは、あくまでもキーワードの人気度であり、本体の人気度ではありませんが、人々の関心度と考えて良いでしょう。
https://trends.google.co.jp/trends/explore?date=2013-06-01%202022-06-01&q=jQuery,React,Vue,Angular
オープンソースソフトウェア(OSS)は、ソフトウェア開発でも長い歴史を持ち、なおかつかなり個性的な特徴がある。
ざっと挙げるなら
こうしたコミュニティから生まれてきたソフトを最も多用しているのは、他ならぬWeb系だろう。
サーバサイドプログラミングが中心になることから、Linuxを触る機会も他の開発系に比べて格段に多いだろうし。
結果、「UNIXの哲学」とかGNUの歴史とか全く意識せずとも、こうした活動を通じていつの間にかOSSのエッセンスを身に着けた人が、Web系には少なからずいそう。
その意味では、OSSがどういうわけか今のWeb系の礎になってしまったという意味で、タイトルに書いた通りになっているのかなーと。
あーーーほ
暗号化しても平分で持ってても、ようはDBにアクセスされてる時点でハッキングされてるわけ。
そんなときに暗号化しておくともしかしたらパスワード悪用される前に時間稼ぎができるかもしれん。
そして強力なハッシュ+ソルト+ストレッチングするっていう、「現代のデファクトスタンダード」な運用なら一番その時間稼ぎができるわけ。
そもそもDBが完全無欠に守れる自身があるなら平分で保存でもいいわけなんだけど、んなわけねーだろ。万が一流出したときのダメージコントロールのためにハッシュカルル訳？ソコンところ理解できてないから、
安全化どうか？みたいなアホな観点でしかものを語れないわけよ。アホたれ
だからパスワードハッシュおもらししたら、直ちにおもらししたことを報告して、その間にハッシュでパスワード解読時間を稼いでる間に、おもらしされたユーザーは万が一他のサービスで同じパスワード使ってるとかいうアホなことしてたら、対応するわけよ。わかる？
まあでも、そもそも他のサービスでもパスワード流用してるタイプのアホは、そんな事しねーよみたいな気持ちもあるな。
そしたらそもそも、平文でほぞんしててもいいような気がしてきたけど、ハッシュで管理してて、アカウントの数が何千万とかあればだよ。
自分のアカウントのパスワードの解読まで一生かかっても作業が回ってこない可能性もあるので、事実上安全っちゃ安全かもしれない。
でもハッキング対象のアカウントが決め打ちでキメられてるなら、スパコンとか使って意地でも特定アカウントのパスワードを割り出すみたいな作業は可能かもれない。
だからってそれは、平文で保存したり、暗号化していい理由には並んと思ってて、
完全に安全にパスワードを管理することは無理だけど、限りなく安全に近い形で取り扱うことのできるハッシュ化(当たり前だけどそこには強力であること+個別のソルと使うこと+ストレッチングが含まれる)をするのは当然であって、
ハッシュが安全かどうかとか言ってる時点で、そもそもの何が問題で、なぜハッシュが良いとされているのか、なぜハッシュがデファクトで使われているのかってのをまるで理解してないと思う
そうやって表面だけの技術情報をなぞっただけでわかったような気持ちで文章書いてる時点で、自分の知識に対する過剰な自信と、慢心が溢れ出してて嫌いです
オープンソースcURLの作者、某大企業から「24時間以内にこの質問に答えるように」との無礼なメールを受け取る － Publickey について思ったことをつらつらと。
log4shell と呼ばれる脆弱性が 2021 年 12 月にあった。これは Java というプログラミング言語でプログラムする際に、動作のログを記録するのに非常によく使われるライブラリ log4j にとても危険な脆弱性があった。なにがそんなに危険かっていうと
マインクラフトのサーバが乗っ取られたとか被害も有名。詳細は Piyolog さんの Log4jの深刻な脆弱性CVE-2021-44228についてまとめてみた - piyolog あたりを参照。
そんなわけで即座に影響範囲、脆弱性のない新しいバージョンになっているか調べろ！って IT 関連企業はとてもバタバタしていた。
という背景の中、オープンソースのソフトウェアである cURL の作者にとても失礼な log4j の問題に関する質問メールが送られてきて、「サポート契約すれば即座に教えてあげますよ」ってかっこいい返しをして盛り上がっている。
cURL (https://github.com/curl/curl]) はオープンソース(以下 OSS)の通信ライブラリとコマンドラインツール。 Linux などのサーバ上からファイルをダウンロードしたりするのにとてもよくつかわれるライブラリ。
C言語で書かれている。
ライセンス は MIT を参考にした独自ライセンス https://curl.se/docs/copyright.htm]
OSS は基本的に無保証で提供される。そのことはライセンスに明記されている。
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
そんな OSS に対して、
「あなたがこのメールを受け取ったのは、■■があなたが開発した製品を採用しているためです。私たちはこのメールをあなたが受け取ってから24時間以内に、お読みいただいた上でご返答いただくよう要求します」
といった上から目線のメールを開発者に送るというのは、IT 企業として無知にもほどがあるといったところ。加えて log4shell 問題、名前のとおり log4j の脆弱性なので Java でかつ log4j を使ってなければ影響はないのに、C言語でかかれた cURL に問い合わせているので問題を全く理解していない。(Java の j が消えるので log4shell という命名はどうなんだというのは個人的にある。つーか Poodle とか Spectre とかファンシーな名前つけてあそんでんじゃねーとも思う。)
なお cURL はどうやら開発者の Daniel Stenberg 氏が wolfSSL というところを通じて商用サポートを提供しているらしい。 https://curl.se/support.html]
ということで、「サポート契約を結んでいただければ、喜んですべて速やかにお答えしますよ」 というのはネタでもなんでもなく、普通の対応。
そしてブログに書いてある2回目の返信で、David と名前を間違えられたのに対して、Fotune 500 の巨人ということで "Hi Goliath," と返しているのも最高にクールですね。
こういうフローが事前に規定されていて CVE とか問題が検知されると発動する。このときに担当が大丈夫です！って回答するときにエビデンス（証拠）を求められるのだけど、クソな情セキは自社の担当の言葉を信用せず、開発会社からの言質をとれ！って命令するので、くそメールがスパムされるという背景があったりする。（担当が無知だったりイケイケだと、とにかく下請けにやらせればいいというパターンももちろんある）
そして情セキも経営層に報告するのに必要で、経営が0リスク信者だと報告が大変なのはわかる。わかるがそれを説得するのが情セキの仕事やで。
加えて担当レベルになると大手は「そんなん下請けにやらせればいいだろ」ってマインドのところが多く、上から目線かつ丸投げすることが多いように思う。
もちろん担当者はピンキリだからこうとは限らないけど比較的多い印象。
ま、これ今回 Daniel Stenberg 氏が公表したからばずってるだけで、日本でもしょっちゅう行われているし、Hacker News みると海外でも一般的なムーブのようです。 LogJ4 Security Inquiry – Response Required | Hacker News
小さいところは
とかであんまり上から目線でこない感じはするけど、これはあくまで個人の資質なのでやべー人はやべーです。オラオラ系の中小とかやっぱいます。でもこんな細かいことはあんまり聞いてこない。（個人の感想です）
この手のメールになんでカチンとくるのかって言えば
ということで、皆ちゃんと保守・サポート契約して、契約範囲で質問しような！
そして金払ってても相手は人間なんで、お互い敬意をもって接しような！
Public Key でこの件にからめて記載されている奴について
https://www.itmedia.co.jp/news/articles/2201/11/news160.html]
ちな、これ詳しくないんだけど、OSS 作者が 「もうただ働きで支援をするつもりはない。これを機に、私に6桁ドルの年間契約書を送るか、プロジェクトを分岐させて他の人にやってもらうかしてほしい」 というのもよくわからないんだよなぁ。
火事で財産失ってむしゃくしゃしてやったのかなんなのか。人気 OSS になったのに全然金にならんぜ！ってのが辛いのはわかる。が、OSS のライセンス的に支援を義務としてやる必要はないので、そんな義務的になってる報告は無視してええんちゃうんと思ってしまう。今回みたいにサポートフィーよこせみたいなスキームが必要だったのかもしれない。
あと個人開発で、善意でこれ便利だろ？って公開しているものに対して、辛辣な言葉の心ないバグ報告やら改善要望は心には刺さるので辛いのはある。それで辞めてしまう人も居る。
ブコメでフリーライドって書いている人が居るけど、MIT ライセンスでだしてんだから OSS の理念である自由なソフトウェアという意味で、再配布、改変、利用は自由でいいんだよ。イヤなら MIT 以外のライセンスでだせばよい。古くは MySQL の Dual ライセンス、最近の Redis とか Mongo みたいに。
ただ、金欲しいとか大体 Donation 募集したりするとかやってると思うんだけど、そういうのもあったのかなかったのかがよくわからにぃ。ポートフォリオになるので、採用にはつかえるんじゃないのかね？
じゃなきゃ GitHub に Public でコード公開しないと思うんだけどな。いまいちピンとこないのであんまり言及しない。
https://www.publickey1.jp/blog/19/redismongodbkafkaaws.html]
で、商用ライセンスの問題。これ今回のくそムーブの問題じゃないのここに並べられるのに非常に違和感がある。なんか OSS と大企業の対立を煽るようなミスリードを誘っているように感じてしまう。
大手クラウドベンダは OSS のライセンスに則って利用・改変するのは問題がない。つーか儲かってるから金よこせっていうのはちょっと違うんじゃないかなと思う。
オリジナルを開発した会社がリスペクトされず、商業的に儲からないってのは、心情的、道義的、人気的にどうなの？クラウドベンダも金払ってあげれば良いんじゃないの？とは思うよ。（2社は協業したけど）
ただ、オープンソースで公開するということは次のような利点を求めてするこって、それがイヤならプロプラで良いわけさね。
Apache License 2.0 とかのライセンスの OSS として公表しているものの利用をフリーライドと表現するのも、それがなんか嫌儲で Evil ってのはちょっと判断できないかなぁ。
大手が自社でメンテできてしまう（できるようにする）というのは経営戦略であり、開発元がクローズにするってのも経営戦略。罵り合い合戦はちょっとなぁという感じ。
OSS の理念的に改修した分は元のソースにもっとフィードバックしろよってのはあるけど AGPL とかで出してないんだよなぁ。
この辺は賛否両論色々あるので気になったら調べてみて。
以上。ご査収ください。
