FLoCとはなにか - ぼちぼち日記
1. はじめに Google がChrome/89よりトライアルを開始しているFLoC (Federated Learning of Cohorts)技術に対して、現在多くの批判が集まっています。 批判の内容は様々な観点からのものが多いですが、以前より Privacy Sandbox に対して否定的な見解を示してきたEFFの批判「Google Is Testing Its Controversial New Ad Targeting Tech in Millions of Browsers. Here’s What We Know.」が一番まとまっているものだと思います。 これまで Privacy Sandbox 技術に関わってきた身としては、各種提案の中でFLoCは特にユーザへの注意が最も必要なものだと思っていました。しかし、これまでのド直球なGoogleの進め方によって、FLoCのトラ
Let's EncryptがはまったGolangの落とし穴 - ぼちぼち日記
0. 短いまとめ 300万以上の証明書の失効を迫られたLet's Encryptのインシデントは「Golangでよくある間違い」と書かれているようなバグが原因でした。 1. はじめに、 Let's Encryptは、無料でサーバ証明書を自動化して発行するサービスを行う非営利団体として2014年に設立されました。 2015年にサービス開始されると証明書の発行数はぐんぐん伸び、先月末のプレスリリースでは累計10億枚のサーバ証明書を発行したことがアナウンスされました「Let's Encrypt Has Issued a Billion Certificates」。CTLogの調査から、2020年2月末の時点では有効な全証明書の38.4%がLet's Encryptの証明書であるとみられています「Certificate Validity Dates」。 無料の証明書を提供してもらえるのは非常に嬉し
なぜChromeはURLを殺そうとするのか？ (Chrome Dev Summit 2019) - ぼちぼち日記
今年もChrome開発者の集まりChrome Dev Summit 2019 (CDS) がサンフランシスコで開催されました。 今回、私が Chrome Customer Advisory Board (CAB) に選出していただいたこともあり、CDSに初めて参加しました。 これは、CDS終了後のCAB meetingで頂いたChrome Dinosaurフィギュアです。ちなみにゲームはできません。 タイトルの「なぜChromeはURLを殺そうとするのか？」は、2日目Chrome Leadsのパネルセッションで司会のGooglerが、Chrome UX担当のProduct Managerに対して一番最初に投げかけた問いです。 PMは直ちに「そんなことはしない」と即答しました。しかしChromeは、URLの表示領域からHTTPSの緑色表示の廃止・EV表示場所の移動・wwwサブドメイン表示の削
Google Chrome EV表示の終焉 - ぼちぼち日記
1. Chrome でEV証明書の組織名表示がなくなる ついにGoogleからChromeのURLバーからEV表示を削除する正式なアナウンスが出ました。 Upcoming Change to Chrome's Identity Indicators EV UI Moving to Page Info 現在(2019年8月) StableのChrome76では、以下の様にURLバー左側にEV証明書を利用していることを示す「組織名+国名」表示が付いています。 Chrome76のEV表示 2019年9月10日Stableリリース予定のChrome77からはEV表示がURLバーから削除され、鍵アイコンをクリックして表示されるPage Infoに「組織名＋国名」が表示されるようになります。 Googleのアナウンスでは、 "on certain websites" と書いてあることから一気にではなく
Node.jsにおけるプロトタイプ汚染攻撃とは何か - ぼちぼち日記
1. はじめに 最近わけあってNodeのセキュリティ調査をしているのですが、今年の5月に開催された North Sec 2018 でセキュリティ研究者の Olivier Arteau 氏による 「Prototype pollution attacks in NodeJS applications」という面白い発表を見つけました。 この発表の論文や発表資料、デモ動画などもgithubで公開されていますし、ちょうどタイミングよくセッション動画も最近公開されました。 github.com Olivier Arteau -- Prototype pollution attacks in NodeJS applications この発表で解説されているのは、悪意のある攻撃者が、JavaScript言語固有のプロトタイプチェーンの挙動を利用して、Webサーバを攻撃する方法です。 発表者は、npmからダ
ハッシュ衝突でTLSを破るSLOTH攻撃(CVE-2015-7575)とは何か - ぼちぼち日記
0. 簡単なSLOTH攻撃のまとめ 最初に簡単なまとめを書いておきます。長文になりそうなので、読むのが大変な方はここだけ見ておいてください。 MD5ハッシュは既に安全ではなく、証明書の署名方式での利用は停止されていたが、後方互換のためハンドシェイクデータの署名方式にRSA-MD5が今でも利用できるTLS実装が幾つか存在していた(Firefox NSS, Java等)。 先週、INRIAグループからハッシュ衝突を利用して実際にTLSを破る攻撃(SLOTH)が公開された。それを受け、いくつかの実装でRSA-MD5を完全に利用不能にする修正が行われた(CVE-2015-7575)。 SLOTHでは、SHA1やTLS、IKE、SSHに対する攻撃についても評価を行い、幾つかは全く現実的に不可能なレベルではないことが示された。MD5とSHA-1でTLSハンドシェイクの完全性を担保しているTLS1.0/
OpenSSLの脆弱性(CVE-2014-3511)でTLSプロトコルの基礎を学ぶ - ぼちぼち日記
1. はじめに、 昨日 OpenSSLのバージョンアップがアナウンスされ、９つの脆弱性が公開されました。バージョンアップの数日前にOpenSSLの次期リリース予告がアナウンスされていましたが、ちょうど BlackHat 開催初日にあたることもあり、なんかまた重大な脆弱性の修正が入るんじゃないかとドキドキしていました。蓋を開けてみるとHeatBleed程の大事ではなくホットひと安心です。 昨日公開されたOpenSSLの９つの脆弱性のうち、TLS プロトコルダウングレード攻撃 (CVE-2014-3511)の修正を見ていたところ、これはTLSプロトコルを学ぶいい題材になるなぁとふと思いつき、試しにこのOpensslの脆弱性の詳細をTLSプロトコルの基礎に合わせて書いてみました。 ちょっと長いですが、TLSプロトコルの仕組み（の一部）を知りたい方はお読みください。 2. OpenSSLの脆弱性
SPDYとLinuxの間でGoogleマップがハマった落とし穴 - ぼちぼち日記
tl;dr 書いていたら思わず長文の大作になってしまいましたので、プロトコルオタ以外の方は文章の多さに退屈されるかと思います。GoogleマップサービスでSPDYの問題が発覚し、GoogleがLinuxカーネルに修正を加えて対応したというお話です。将来 Linux + nginx + SPDY を使いリバースプロキシでサービス運用を検討されている方は参考になるかもしれません。 1. はじめに、 プロトコルに執着する年寄りエンジニアの老害が叫ばれて久しい。 年甲斐もなく自分好みのパケットを追っかけるおやじエンジニアの姿を見て眉をひそめる若者も多いと聞く。 そんな批判に目もくれず、今日も一つ、プロトコルオタのネタをブログで公開したいと思いますw 今回はちょうど１年ほど前に書いたブログ記事 「GmailがハマったSPDYの落とし穴」の続編です。といっても今度の舞台は、Googleマップ。ネタ元も
Googleの新プロトコルQUICを試す - ぼちぼち日記
1.QUIC仕様の公開 以前、「Googleが仕掛ける新プロトコルQUICとは何か」のブログエントリーを書いたのが2月末の事でした。それから4か月経ち、今朝Googleが初めてQUICの公表(Chromium Blog: Experimenting with QUIC)を行いました。 IE11のSPDY/3対応が判明した直後でした。なんというタイミングでしょうか。 また、近いうち（来週？）には HTTP/2.0 の Implementation Draft が公開される予定です。8月上旬には、GoogleやMicrosoft等が集まって初めての HTTP/2.0 の相互接続試験を行う予定です。ただ今HTTP関連のプロトコルが急激に進化する真っ最中です。目が離せません。 2. で、QUICとは何なのか？ 先のChromium BlogのエントリーでQUICは、 「Quick UDP Inte
Googleが仕掛ける新プロトコルQUICとは何か - ぼちぼち日記
まずは免責事項。 1.Disclaimer 本ブログの記載内容は、筆者が独自に QUIC に関する Chromium のソースを分析し、検証した結果です。 QUICに関するGoogle からの公式な技術資料は現状公開されていません。 今後、QUICの技術仕様の公表で本ブログの記述内容が不十分だったり、誤っている可能性があります。ご理解の上お読みください。 (注： 2013年6月27日に Google は正式に QUIC 仕様を公開しました。「Experimenting with QUIC 」 本ブログの内容は大筋では間違っていませんが、当時の解析漏れやその後の開発等により、細かいところで異なっていたり、説明が大きく不足している部分もあります。お読みになる際はご注意ください。) 2. はじめに、 Googleがまたまた新しいプロトコルの実装を始めました。Web表示の高速化を目指した SPDY
GmailがハマったSPDYの落とし穴 - ぼちぼち日記
1. SPDYブーム到来 おかげさまで、ここ数日 SPDY が私の周りで非常にブームになってきています。 前回案内したSPDY＆WS勉強会は既に200名以上の申し込みがあり、今ではSPDYネタでブログを書くと非常に注目されるうれしい状況です。時代はまさに、 SPDYはハイプサイクルを順調に駆け上がっている 状況だと思います。 図１：2012年のハイプサイクル： 図はガートナー社のプレスリリース http://www.gartner.co.jp/press/html/pr20120906-01.html から引用 SPDYが、まだ黎明期に入ったばかりなのか、それとも既にピーク期に入ったのか、それは歴史が証明してくれるでしょう。 ということで勉強会までSPDY熱が冷めないよう、私もいろんなSPDYネタを出していきたいと思います。 2. GmailがハマったSPDYの落とし穴とは 先日、 Goo
FacebookがSPDYを始めました！ - ぼちぼち日記
1. SPDYが熱いです！ ちょうど先週末CROSS2013の 次世代Webセッション(プロトコル編) にパネラーとして参加させていただきました。 次世代Webの鍵となるWebSocket・SPDY・HTTP/2.0について熱い話ができとても満足しています。会場は満員で皆さんがとても興味を持って聞いていただいているのも十分感じることができました。 参加していただいた方、本当にありがとうございました。 2. LINEがSPDYを使っている セッションでは、つい最近 LINE が SPDY を使っているという発表( http://tech.naver.jp/blog/?p=2381 )について紹介し、その有用性についていくつかコメントをしました。 SPDYは、 Google が2011年より2年近くほとんどのGoogleサービスで実運用していますが、Google以外で世界的にメジャーな大規模の
次世代JavaScriptでデータバインディング： Object.observe() を試す - ぼちぼち日記
1. はじめに、 本記事は、HTML5 Advent Calendar 2012の参加（6日目）エントリーです。 当初は昨年のアドベントカレンダーでテーマにしたマイナーAPIをネタにして書こうかと考えていたのですが、探してもあまりピンとくるものがなく、いつものごとく新技術ネタに飛びついてしまう習性がでてしまったので今回次世代JavaScript(ES.harmony)ネタ(Object.observe)を書かせていただきます。 現時点では直接HTML5とは関係ありませんが、標準で利用できるようになったら皆さんがお世話になる機会が必ず増えると予感しています。今の時点で知っておいてもらっても絶対損はないと思いますのでどうかご了承ください。 （＿Ｏ＿） 2. Object.observe() とは何か？ 先日のHTML5勉強会でも取り上げられましたが、最近 JavaScript の MVC フレ
Node.js-v1.0 リリースに向けてどうなる？ - ぼちぼち日記
9/24にサンフランシスコで Dataweek2012のカンファレンスにてNodeSummit が開催されました。ちょうど今朝 Node の Gatekeeper である isaacs のプレゼンがあり、資料を見てみると今後の Node に関する話題(node-v1.0のリリースに向けて）が記載されていたので紹介したいと思います。 オリジナルの資料は http://j.mp/2012-dataweek-state-of-the-node にあります。（Keynote ファイルです。） 今回、今後の展望について述べられている後半のスライドの部分だけ意訳してみます。 （原文は後に引用しています。） API廃止について、 Node が意図的に API を変更する時代は終わった。 あなた方のプログラムが今動作しているなら、来年もきっとそれが動作するよう頑張ります。 これまでは Node がここまで
GREEが悩むNode.jsの問題を考えるヒント - ぼちぼち日記
先日 GREEを支える大規模インフラテクノロジー」-GREE Platform Summer Conference 2012 という記事が公開され、GREEのCTOの藤本さんが、 javascriptをサーバーサイドでも使うケースが多くなってきていて、必然的にnode.jsを使うことになるが、大きく３つの問題がある。 ひたすらすごい勢いでバージョンアップしているので安定しない。コストを払ってついていく覚悟を持って取り組んでいる。 メモリリークがあるので、サーバを起動しっぱなしにするとメモリが食いつぶされる。 コードをデプロイしても再起動しないと読み込まれない。 （中略) これで絶対大丈夫という解決策がなくて、node.jsで一番悩んでいる。これでバッチリ解決するというものがあれば、是非教えて欲しい。 といった話が掲載されていました。 GREEさんに限らず一般的に Node に対して同じ問題
Googleが示すJavaScriptを350倍高速化する秘訣 - ぼちぼち日記
1. はじめに、 今年も Google I/O が開催されました。一度も現地に行って参加したことはないのですが、毎年セッションの内容は技術的に高度なものばかりでいつも注目しています。今年の一つ興味深いセッションで、 「Google I/O 2012 - Breaking the JavaScript Speed Limit with V8 (Daniel Clifford)」 スライド ,ビデオ というのがありました。（ビデオ・資料をすぐ公開してもらえるのはホントありがたいです。） ご存じの通り V8 は Chrome に搭載されているばかっ速い JavaScript エンジンで Node.js でも採用されています。このセッションは、 V8 の内部実装の解説を元にどう JavaScript の実行速度がパフォーマンスチューニングができるかという内容で、もうこれは必見で見逃せないものです。
node.js Domain 時代のエラー処理のコーディングパターン - ぼちぼち日記
id:kazuhooku さんの記事 node.js におけるエラー処理のコーディングパターン (もしくは非同期 JavaScript における例外処理。 ナイスです！ なんと素晴らしいタイミングでのブログでしょうか！ 「東京Node学園 5時限目」で id:koichik さんのプレゼンで node-v0.7.8 から isaacs 版 Domain が導入されるという発表がありましたが、予定通り昨日 Domain 機能付きの node-v0.7.8 がリリースされました。 しかもDomain のドキュメント付きです。 http://nodejs.org/docs/v0.7.8/api/domain.html ちょうど id:kazuhooku さんの記事の例は node.js の新機能 Domain を教科書通りに適応するとどうなるのか紹介するのにぴったりのお題なので Node.js
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
