Secrets from the Algorithm: Google Search’s Internal Engineering Documentation Has Leaked
Watch Our Google Algorithm Leak Webinar Replay Google, if you’re reading this, it’s too late. Ok. Cracks knuckles. Let’s get right to the Google algorithm leak. Internal documentation for Google Search’s Content Warehouse API has been discovered. Google’s internal microservices appear to mirror what Google Cloud Platform offers and the internal version of documentation for the deprecated Document
AI時代に起きる「デジタルカルテル」とは。 独禁法の観点から弁護士が解説 | Business Insider Japan
データ&プラットフォームに対する独禁法の執行公取委は2017年6月に「データと競争政策に関する検討会報告書」を出し、さまざまな議論が起きています。2020年になって「優越的地位の濫用」を個人にも適用しようという動きや、プラットフォームの透明化に向けた法制化への動きがまさに今起こっているところです。 ここからは、同業者間で市場価格の相場を上げる「カルテル」とAIについて話します。今後は人間ではなくAIが自分で考えてカルテル行為を行う「デジタルカルテル」が懸念されています。しかし、デジタルカルテルにもさまざまなパターンがあり、ごちゃ混ぜにして議論をすると混乱の元になるので注意が必要です。 以下、Messenger型、Hub and Spoke型、Predictable Agent型、Digital Eye型という「デジタルカルテル」の4つの類型を紹介します。 1.Messenger : ポスタ
分散ロックという名の過ち - Software Transactional Memo
 TL;DR; 「分散ロック」が分散システムの設計図に登場した時 だいたいその設計は間違っていて本当に必要なものはトランザクションだ 並行システムを実装する際にロックを用いるのはとても自然なことだ。 僕も普段はロックフリー系のアルゴリズムに詳しいと言われがちだが知識量でいったら実はロック系の方が多く蓄えているかも知れない。 分散システムは並行システムであることが多いので、その中にロックが登場するのはとても自然な発想である。 よく「分散」「並行」「並列」の言葉の定義がごっちゃになっているケースがあり、この記事の主題にしたいわけではないので深くは言及しないが、分散システムは環境などの要因で突如として参加者が音信不通になったり復活したりする点で並行システムと大きく異なる。 並行システムと同じノリで分散システムを設計しようとした際に陥る頻出の過ちが「分散ロック」である。そのアイデアはとても簡単で
Alpha Zeroの衝撃と技術的失業｜山本一成🚗TURING
2016年、Google DeepMind社から恐ろしい論文が出された、AlphaGoその名を冠した囲碁プログラムが既存の囲碁ソフトに勝率99％を叩き出したのだ。AlphaGoは強化学習とDeep Learningを組み合わせた囲碁プログラムで、その年に最強の囲碁棋士の一人である李世ドルさんに4勝1負で勝利した。その後も進歩を続けて今のAlphaGoの強さは人類が体感できるレベルを超えるほど強くなったと予想される。 2017年も終わりのころ、Google DeepMind社からまた途方もない論文が発表された。囲碁とほぼ同じ手法で最強レベルのチェスや将棋プログラムを超えたということだった。実際のところ正確に超えたのかどうかちょっとだけ疑問もあるのだが、まず前提として彼らの新手法が途方もない成果をあげたこと素直に祝福したい。彼らは自分たちのプログラムをAlpha Zeroと名付けた。 コンピュ
Google、TCPのスループットとレイテンシを改善する輻輳制御アルゴリズム「TCP BBR」をGoogle Cloudで利用開始
Google、TCPのスループットとレイテンシを改善する輻輳制御アルゴリズム「TCP BBR」をGoogle Cloudで利用開始 Googleは、同社が開発したTCPの輻輳制御アルゴリズム「TCP BBR」をGoogle Cloud Platformで利用可能にしたと発表しました。 インターネットにおける通信にはTCPを用いる場合とUDPを用いる場合に分かれますが、BBRはTCPにおける輻輳制御アルゴリズムを改善したもの。すでにGoogleはTCP BBRをYouTubeのネットワークで利用しており、従来のパケットロスをベースにした輻輳制御アルゴリズムであるCUBICを用いた場合と比較して、スループットが平均で4％、最大で14％以上改善したことを明らかにしています。 TCP BBRは現在の高速なネットワークに適した輻輳制御アルゴリズム TCP BBRのBBRは「Bottleneck Ba
GoogleのSHA-1のはなし
5. • その暗号技術がどのぐらい安全かを表す大雑把な指標 • nビットセキュリティは2 𝑛 回攻撃が必要 • 1回あたりの攻撃コストはあまり気にしない • 𝑂 2 𝑛 という表記 セキュリティビット 𝑛 直線 :𝑂(𝑛) 3次関数 : 𝑂(𝑛3 ) 指数関数 : 𝑂(2 𝑛) 𝑂(log 𝑛) 5 / 21 6. • 第二原像計算困難性（弱衝突耐性） • 𝑚1に対して𝐻 𝑚2 = 𝐻 𝑚1 となる𝑚2 ≠ 𝑚1が分からない • 同じじゃなくてもいいから何か一つ見つけるのが困難 • 𝑂(2 𝑛 )回トライ ; nビットセキュリティ • 衝突困難性（強衝突耐性） • 𝐻 𝑚1 = 𝐻(𝑚2)となる𝑚1 ≠ 𝑚2を見つけるのが困難 • 𝑂(2 𝑛/2 )回トライ ; 𝑛/2ビットセキュリティ • 第二原像を見つけるのは単なる衝突より2
GoogleがTLSでの採用を提唱している共通鍵暗号方式「ChaCha」についてまとめた - sonickun.log
ChaCha（チャチャ）という一見ふざけた名前の暗号が最近（自分の中で）話題ということで，勉強がてらに記事にしてみました． 背景 ChaChaの構造 Salsa20 Chacha 初期状態 ラウンド操作 ChaChaの安全性 実装してみた 参考 背景 2016年4月現在，TLSの新しいバージョンとしてTLS 1.3が提案されており，ドラフトが公開されている． draft-ietf-tls-tls13-11 - The Transport Layer Security (TLS) Protocol Version 1.3 TLS 1.2からの大きな変更点として，以下の2つがある． ハンドシェイクの省略によるRTT（Round Trip Time）の削減 危殆化した暗号の廃止 「危殆化した暗号」とは，Forward SecrecyでないCipher Suite（RSAのみを用いたもの）や，認証
Google Chromeが採用した、擬似乱数生成アルゴリズム「xorshift」の数理
2015年12月17日、Google Chrome の JavaScript エンジン（処理系）である V8 の公式ブログにて、 JavaScript の標準的な乱数生成APIである Math.random() の背後で使われているアルゴリズムの変更がアナウンスされました。 Math.random() 関数は JavaScript を利用する際には比較的よく使われる関数ですので、親しみのある方も多いのではないかと思います。 新たなバグの発見や、従来より優秀なアルゴリズムの発見によってアルゴリズムが変更されること自体はそれほど珍しくはないものの、 技術的には枯れていると思われる Math.random() のような基本的な処理の背後のアルゴリズムが変更されたことに驚きを感じる方も少なくないかと思いますが、 それ以上に注目すべきはその変更後のアルゴリズムです。 実際に採用されたアルゴリズムの原
ブラウザ上で画像処理 ～漫画のコマを領域分割する～ - pixiv inside [archive]
はじめに こんにちは、pixiv でアルバイトをしていた arayuji です。 今回はこれまでやってきたことのまとめとして、漫画やイラストに対する画像処理についてご紹介します。 一口に画像処理といっても様々なものがありますが、ここでは漫画のコマや白黒のイラストを簡単に領域分割する手法についてお話しします。 基本的な画像処理から高度な最適化処理まで、すべての処理をブラウザ上で 実現しました。 実際のコードも、pixiv/manga-segment · GitHubにあるので、興味がある方は見てみてください。 デモ トップに載せた画像が動作イメージなのですが、わかりにくいと思うのでデモを用意しました。（Chrome 40 / Firefox 35 / IE 11 で動作確認しましたが、IE では非常に遅いので注意してください） 右側のパレットで色をひとつ選んで、左側の画像の上にマウスで線を描
2 段階認証は本当に安全なのか調べてみた | はったりエンジニアの備忘録
このブログを読んでいる人なら Google や AWS の 2 段階認証（マルチファクタ認証）を有効にしていると思います。もしパスワードが漏れてしまってもワンタイムパスワードを入力しないと認証されないので安心です。 有名どころのサービスでは使えるところが増えてきましたが、2 段階認証を有効にしていれば万全なのでしょうか。エンジニアである以上、その仕組みを理解したうえで自信を持って安全と言いたいところ。 というわけで、2 段階認証は本当に安全なのか仕様を紐解きながら調べてみました。 ワンタイムパスワードの仕様 ワンタイムパスワードを生成する仕様は HOTP と TOTP の 2 つがあり、RFC の仕様になっています（TOTP はドラフト段階）。 HOTP (HMAC-Based One-Time Password Algorithm) TOTP (Time-Based One-Time P
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Announcing SyntaxNet: The World’s Most Accurate Parser Goes Open Source