「メタデータ」を含む日記 RSS

はてなキーワード: メタデータとは

2021-11-25

日本語の原郷」について、補足説明

「『日本語の原郷』についての論文を読んでみた」(anond:20211121124146)を書いた増田です。思ったより多くの反応があって嬉しいので、調子に乗ってはてブの反応に対して補足説明みたいなのをしてみます

言語学でわからないところを他の学問補正するのはアリ?

そもそも言語学では分かりようがないところを考古学遺伝学の視点から補正したっていうのがあの論文の眼目だと思うので、言語学の面だけ否定しても…

こういう意見がみられましたが、少なくとも考古学遺伝学の成果から言語については何もわからない、ということを強調しておきます

極端な例を挙げると、100年前にアメリカ移住した日本人の子孫で、ご家庭でも英語しか使っていない日系アメリカ人のことを考えましょう。彼もしくは彼女遺伝的には日本列島に遡ることができます(おうちを探すと日本列島由来の品が出てくるかもしれません)。では言語的には? 彼もしくは彼女が話しているのは英語であり、英語というのは印欧語族ゲルマン語派西ゲルマン語群アングロ・フリジア諸語に分類されるイングランド発祥言語であるわけです。どれだけ遡っても日本列島には行き着かない。「この人は遺伝的には日本列島出身なのだから英語起源日本列島にあるんだ!」なんて話はおかしいでしょ?

古代にどのような人口の変動があったのかはわかっていません。移民同化が起きたのかもしれない。婚姻によって遺伝子が混ざりあった可能性もある。その場合遺伝子の伝播と言語の伝播が異なるルートである可能性もあります遺伝子はヒトの移動について詳しく教えてくれるけど言語の移動についてはなんも教えてくれないんですよ。せいぜい傍証になるだけ(「言語学観点からは○○語は××地域あたりが原郷だと思われるが、遺伝学で調べてみたら××地域からの大規模な人の移住があったっぽいので、このとき言語も広まったんだと思われる」みたいな)。

ニュースになるのは仕方ない

と言うことで、こんな与太話、なんで毎日新聞記事にしたの?と周りの研究者が頭をかけている、と言う話なのかしら。

様々な仮説があるのはいいけど、定説化とか定説エビデンスによって覆されたとか以外はニュースバリュー無いと思うんだが、なぜ報道されたのか。

いやー、Natureマックスプランク研究所研究者が載せた日本に関する斬新な論説をニュースにするな、という方が無茶じゃないでしょうか……

正直、これメディアを責められないと思うんですよね。実は著者のロベーツさん、去年オックスフォード大学出版からオックスフォードトランスユーラシア語族ガイドブック』なんて本を出してるんですよ(Robbeets and Savelyev 2020)。天下のオックスフォードUPから『~語族ガイドブック』なんて出てたらその語族実在は学界の定説になってるって勘違いちゃうのも当然っていうか……これ、今回は日琉語だから気づけたけど、パプアニューギニア言語とかでやられたら引っかからない自信ないです。

なおその『ガイドブック』には辛辣書評が出てます(Vovin 2021)。掻い摘んで批判の内容を紹介すると、「分析されてるのが現代語ばっかりやんけ」「系統関係があるって言うなら明確な対照表を示してみろや」「中期朝鮮語の再建がおかしいけどちゃん韓国語の先行研究読んどるんか?」「“leading international scholars”が書いたガイドブックって謳ってるけど著者のうち6人は院生じゃねーか」みたいな感じです。さらには、

We move now from the bad quality of research to the realm of science fiction in Table 39.1 that is supposed to present core Koro-Japonic etymologies. But there is at least one mistake and/or data fabrication on every line. (Vovin 2021: 126)

なんて書かれてます。怖ぁ~……おしっこちびっちゃう……

大野晋トンデモです

大野晋先生が生き返ってあと数十年研究してくれんかな

これは元増田でも書きましたが、大野晋は、少なくとも日本語起源という点については完全にトンデモです

タミル語はドラヴィダ語族というインド南部語族に属する言語ですが、大野は「日琉語族とドラヴィダ語族はより大きな語族内包される」というありえそうな穏健な主張ではなく「日本語起源タミル語である」という主張をしていますしかし「なぜドラヴィダ語族全体ではなくタミル語比較するのか」「ドラヴィダ語史がまったく考慮されていない」「語義の解釈おかしい」「サンスクリット語から借用語に気づいていない」などのツッコミに対して有効反論ができていない上、ツッコミを受けた箇所をしれっと書き換えたりツッコミを入れた人たちに人格攻撃を加えたりしています長田 1998;児玉 1996;山下 1996; 1998)。やり口がもうきちんとした学者のそれではありません。

大野語源論が誤っている一例として、amarar「不死なる者」という単語について挙げておきます大野はこれを日本語「あま」と関連付けて「天上界の人」の意だと解釈するのですが、これはサンスクリット語amara「不死の」から借用語です。これはさらにa-maraと分解でき、a-は否定接頭辞、そしてmaraの語根mr英語murderやmortalとも関連しています(つまり印欧祖語に遡る語ということであり、どう考えてもタミル語起源単語ではない)(山下 1996: 204–205)。

八丈語系統位置について

日本祖語から琉球語、もう片方の枝が本土語と八丈島語に分かれた系統図を覚えてたんだが、あれからずいぶん研究が進んでるんだなあ。/20年前に既にずいぶん版を重ねた本で得た知識から当然か…。

五十嵐2021)の説は発表されたばかりなので「定説」といえるほどではないですが、きちんとした分岐学手法に基づいて系統解析してるんで個人的には信用してます

で、従来説における八丈語位置づけですが、正確には、上代東国語の唯一の生き残りが八丈語というものです。つまり、「本土日本語派」がまず上代日本語(OJ、奈良など当時の首都で使われていた言語)と上代東国語(『万葉集』の東歌と防人歌に痕跡が残る)に分かれ、後者八丈島(&青ヶ島)以外では滅んだ(=上代日本語同化された)ため、現代では八丈語日本語対立するひとつの語派を形作っているということです。

系統樹にするとこんな感じ(樹形図をどう書けばいいのかわからないんでとりあえず「うんこするの?」の樹形図からコピってきたんですが、見づらかったらすみません)。

日本祖語 ─┬─ 上代日本語現代日本語

        │

        ├─ 上代東国語→絶滅

               │

               └─ 上代東国語の八丈島方言八丈語

この樹形図から絶滅した言語を取っ払って現代にのみ注目するとこうなります

日本語派 ─┬─ 本土日本語

      │

       ├─八丈語

それに対して、五十嵐2021)は、上代東国語は滅びたわけではなく、表面上は関西からの影響を受け続けたものの、現代関東東北地方方言として生き延びていると主張しています。つまりこういうことです。

日本祖語 ─┬─ 上代日本語関西の諸方言

        │

        ├─ 上代東国語→関東東北の諸方言

               │

               └─ 上代東国語の八丈島方言八丈語

八丈語が際立って特殊に見えるのは、この言語が失われた東国語の唯一の生き残りだからではなく、他の東国語の末裔茨城弁とか)と比べて中央からの影響が少なかったため東国語の特徴が保たれたおかげだ、とするのが五十嵐説です。

要するに、「東国語は滅んだ(=東国話者が完全に同化された)」のか(従来説)、それとも「東国語は生き残っている(=東国話者中央からの影響を受けたけど完全に同化されはしなかった)」のか(五十嵐説)、という違いです。個人的には後者妥当じゃないかなーと思うんですが、どうでしょうか(だってそんな大々的な言語置き換えはどうやって起きたの? ってなりません?)。

なお、五十嵐2021)だけでなく、元増田でも言及したローレンス(2013)も、八丈語には他の東日本の諸方言と共有される要素が見つかり、それは西日本の諸方言には見られず、したがって八丈語東日本の諸方言の内に位置づけられる(=八丈語本土日本語対立する系統であるとする旧来説は誤り)と主張しています

味噌」の語源朝鮮語

日本語に興味のある&研究手法を学んだ”素人には、この論文言語部分はとても怪しい。増田の指摘以外に日本語の粟を他言語大麦の借用としたり、味噌(未醤)を漢語ではなく朝鮮祖語からの借用にしたりしてる。

実は増田もそれを見たとき「えっ……?」って思ったんですが、否定できるほどの根拠を持ってないので書きませんでした。確かに先行研究では意外な言葉朝鮮語から借用語だとされてることがありしょっちゅう驚いているので(たとえば「つち」とか)、「味噌」が朝鮮祖語からの借用というのをありえないと即断することはできないんですが……。

いちおうここで論文の内容を紹介しておくと、『鶏林類事』に[mitsu]という語があって、そこから朝鮮祖語*micuを導き、平城京木簡みえる「末醤」から上代日本語の*misoあるいは*misəを再建し、それは朝鮮祖語*micoもしくはその交替形*micʌからの借用である、という議論になってます。これだけじゃ門外漢増田には当否がわからんのですが国語学的にはどうなんです?

なお、該当箇所に、

...This fragment preserves the following inscription: 御末醤一石二斗, i.e. HON-“bean paste” reads as miso. The Wamyoshō, a Chinese to Middle Japanese dictionary compiled in the mid Heian period has the same kanji (末醤) glossed as miso (美蘇)...

とあるのですが、「一石二斗」の部分いらなくね? とか、転写するならWamyōshōじゃね? とかはケアレスミス範疇だろうから突っ込まない方がいいのかな……

やはり女王は強かった

マイルCSグランアレグリアが有終の美を飾ってくれて最高でしたね……あとはコントレイルジャパンCで有終の美を飾ってくれれば……実はまだ「三冠馬が勝つ」ところを見たことがないので、一度は見ときたいなぁと(にわかですいません)。

「この分野は素人なのですが」

本当に素人なんだけど何でみんな信じてくれないんです……?

参考文献

2021-04-25

windowsbashを使うのはLinuxPowershell使うより無駄

大体の場合において「bashが欲しい」という人はbashだけではなくgrepawkやその他諸々のgnu ツールもまとめて欲しているが、それらを合わせてもwindows上で使うPowershellには機能レベルで遠く及ばないし、windows上のbash単体はLinux上のPowershell単体にも劣る。

Powershellでは、「文字列しかさない古いパイプを通して文字列切り貼りして受け渡しながら処理をする」なんて面倒なことはない。

bash+gnuツールだと別コマンド文字列切り貼りしなきゃ取得できないメタデータも、Powershellならパイプオブジェクトを渡せるから始めからオブジェクトプロパティとして付いてくる場合殆どだ。

windows上なら.net経由でシステムの様々な部分へのアクセス可能だし、COMObject経由でofficeソフトのものを直接操作もできる。

サードパーティーモジュールで無理矢理データを弄るんじゃなくて実際にofficeファイルを吐くプログラムのものPowershellから操作できる。

互換問題とは無縁だ。

なので、Powershell記事によく付く「こんなのよりbash(+gnuツール)使いたい」ってのは「LinuxPowershell使いたい」って言ってるようなもんだって分かって欲しい。

windows上においてはbashPowershellの肩代わりは出来ない。

少し前からLinux上でPowershell動くようになったけど、LinuxユーザPowershellから学ぶ価値あるかと言われると、はっきり言って「あんまりいかな」とは思う。

azure関連のコマンドモジュールPowershellしかないヤツもまだあるみたいだからazure触るためだけにwindows用意しなきゃならない事態を防ぐ程度の意味合いしかないような気はする。

そういうモジュールLinux上のPowershell対応してんのか知らんけど。

WSLでLinuxが丸々windowsに取り込まれたおかげでカジュアルwindows上のbash需要殆どは満たせる時代になったのは良いことだ。

別にPowershellのことを詳しく調べろとは言わないが、bashじゃwindows上のPowershellの肩代わりは出来ないって事だけは覚えておいて欲しい。

2021-01-03

ドラクエ11をやってるが昨今の攻略サイトが便利でキモい

クエスト名前と受注場所報酬と依頼内容がGoogle検索結果の時点で載るようになっとる

これはGoogleゲーム攻略サイトだと判断してパースしてるのだろうか

wiki制作サイト側がメタデータつけてるのだろうか

2020-10-28

ファーストスター発生学

ブコメが 5 つくらいついているがまだどれにもスターがついていないとき最初につけるのを躊躇ってしまう。

人気コメントタブにひとつだけ表示され、他のコメントが見られにくくなる。じゃあいくつかつけるかとなるとそれは違うじゃん。

増田ブクマは待っていれば星がつくのでその後に来れば良いが、ブックマークとして使っている人が多いジャンルではそもそも星をつけ合う文化が無い。でもグッとくることはある

人気コメントがある程度の数になるまでは、一覧も一緒に出してくれないかなあ。いや、そもそもタブで分けるのなんでだ。人気コメント入りしたものに星が集中しがちなのを問題視していたのに。星が多いコメントをいくつか表示したすぐ下から一覧を表示すればいいのに。ページを短くして脱力クリック狙いたい広告見せたいという気持ちが出すぎて、健全コミュニティーを仕組みで構築する気が無いのだろう。

脱線した。まああまり考えずにつけたいものだけにつけちゃう方が今後つけやすくなるだろうし、そうすべきなのだろう。結構長らく悩んでしまっているがために、ファーストスターのことを考えるたびに古い歌が浮かんでしまうのだ。

ひとつ有機的な機械自律稼働するためにメタデータを受胎させねば其は空洞なり、なーりー

2020-07-17

中古マンション買うかも

しがないソフトウェアエンジニアしてるけれども、今の会社含めて業界全体的でリモートワークが定着しそう。というか、今の賃貸がク○過ぎて、自宅作業苦痛引っ越しを考えるも、「新建築」に載るような集合住宅に住んだ時期を想起しても、この国の賃貸クオリティーはあまり高くなさそうであり、人生で初めて不動産購入を検討中

現在都内でも比較的小さな店が多い中央線沿いの街住みで、引越し先は賃貸ベースならば1年ぐらい前から中目黒検討していたが、物件を買う=10年ぐらい住むとなるともっと自然が多い街に行きたいみたいなところ。

ひとまず中古マンションの購入を検討をしているが、驚くほど非効率作業を強いられるので誰かにこの不満を共有したい。

マンション内装部分はいくらでも変更可能なので、正直部屋の写真とかはどうでも良い。寧ろ、「マンションの躯体・構造」「管理組合」そして「街の将来性」に関する情報を知りたい。これらは相当程度データ表現出来ると思われるところ、suumoなりhomesなりを見ても絶望的にそれらの情報記載されておらず、なんとなく良さそうな物件を見つけては不動産仲介業者との膨大でかつ不必要コミニュケーションを強いられる。そのわりに不動産仲介業者提供する新しい情報殆ど皆無だったりする。

例えば、このようなデータを見たいが(意外と)標準的に容易に閲覧可能となっていない。

◎「マンションの躯体・構造

◎「管理組合

↑ 一部のマンションではこれらの大部分の情報が [マンション管理ネット](https://www.mirainet.org/) で見られる

◎「街の将来性」

...

...

etc

正直これぐらいのデータがあれば、今すでに標準的に表示されているデータと合わせ、知らない街の知らないマンションでも短時間で相当程度その価値を見極めることが出来ると思う。

とはいえ、なんだかんだ解体計画管理組合電子化に関する情報住民のnpsが分かれば良い気もしている。

解体計画そもそもスクラップアンドビルドのノリで作っているのに解体計画が無いのが良く分からないが、これがあれば竣工時の情報・修繕の想定・リスクの想定などマンションの躯体・構造に係る必要情報が組み込まれている可能性が高い。また、物件評価するときに、解体計画に基づいて実質的な経過年数を評価出来る手法もあり得る。

管理組合電子化に関する情報 → 結局知りたいのは管理組合コミニュケーションのあり方。区分所有法に基づき総会議事録を電磁的記録で作成するのは難しそうだが、議決権行使は電磁的方法OKだし、その他管理組合アプリみたいのも幾つかあるので、ある程度管理組合電子化していて欲しい。ここが電子化されていないと、老人が多いかコミニュケーションコストが高そうなイメージを持ってしまう。 あと、国交省が言うような100年マンションがあったとして100年後に紙資料が保存されているのか、疑問がある。

住民のnps → npsを細かく取ればその自治体についてある程度は分かりそう。特に、街の中長期的な発展には新陳代謝重要そうなので、若い世代のnpsを知りたい。「住みたい街ランキング」とかどうでも良い。appstoreでアプリダウンロードするときに知りたいのは、ダウンロードした人のレビューであって、これからダウンロードするかもみたいな人の意見ではない。

ただ、この3つが明示的に分かる場合は少ない。なので、結局仲介の人に連絡をし、実際に物件を見に行かなければならない。そしていろいろコミニュケーションするが、結局良く分からないままになりがち。契約交渉をすると分かることもあるらしいが、ただ情報を知りたいためだけに毎回契約交渉したくない。

一方で、これらの情報が今のマンション価格には組み込まれていない可能性もあり、知識時間があれば良い物件を探せるような印象もある。今の日本マンションの中長期的に支配的な価格決定条件=「駅近xx分」と「ブランド」に収斂しているように見受けられるので、諸外国マンション価格決定を想像するに、多分価格に組み込まれていない情報は多いのだろう。不動産テックの人ってどんなことをしているのだろう。

その他雑感:

・鉄鋼の強度が上がったからか、最近東京新築マンションファサードの曲線やコーナーサッシが大胆だったりしてカッコ良いの増えてきた。駅・商業施設直結系も良い。けど絶望的に手が届かない。イギリスではマンチェスター再開発成功しているらしく、日本地方都市にもこのような流れが普及することを期待したい。

中古物件データがより可視化され、中古物件の売買が容易になることで、仲介業者手数料収入は多くなる筈だが、何故日本仲介業者はその方向性ロビイングをしないのだろうか。結局ここが分からないということは、まだ自分不動産の闇を知らないのだと思う。

・築40~50年で誰が買うのだろう?みたいな物件でも管理費・修繕費が毎月数万円掛かる。これを誰も買わなかったらどうなるのだろう。ただ、同築年数で自分が手が届かないような金額帯の物件も案外ある。しかデータがあるここ5年ぐらい価格が下落していないことが多い。ババ抜き怖い。

新国立競技場建設時に立ち退きを迫られた築40~50年物件住民を思い出す。確かに、良エリアなところには昔の人が何も考えずに建てた中途半端マンションがありがち。そしてそのせいで街の流れが悪くなっているし機会損失が発生している可能性もある? 住民間の公平性観点から東京オリンピック関係なく、良エリア中途半端マンション住民には躊躇なく立ち退きを迫るべき。

・つくづく新幹線は凄いと思う。初期の設計思想が優れているから、次の時代でも進化を遂げている。それに比べて日本マンションはどうなのだろう。あと、新幹線満州国での経験が色々生かされているらしいが、同様の経験が活かされているらしい〇〇ニュータウンは。。。

・結局税金解体されるマンション増えてきそう。責任を次の世代にまわす日本人の思考回路を感じ始めている。もうこういうゲーム自分たちの世代で止めたい。

・幾つか物件を見たが、中古マンションをどんなにリノベしても数年後の販売価格シビアになりそう。まして、金融機関担保評価はリノベに掛けた費用など考慮しなさそう。数年後に残債以上の販売価格で買主と合意できても、買主にローンつかないこともありそう。欧米金融機関担保評価ってどんな感じなのだろう。

都市計画を定めるとき地権者意見の強すぎ。x年後にその土地で住む人、働く人は潜在的に皆利害関係者なのでは。x年後に地権者はそこに土地を持っているのだろうか。今すぐ土地を高く売りたい人による、今すぐ土地を高く売りたい人のための、今すぐ土地を高く売りたい人の都市計画作りましたみたいな街が多すぎ。

自分生活都心を思ったほど必要としていなかった。結局都心毎日行っていたのは仕事必要性が90%ぐらいだったようだ。ロンドンハイドパークやリージェントパークみたいのが都心に無いのが残念。南池袋公園とかもっと頑張ってほしい。

・というか、リッチモンド公園みたいな公園郊外にあって欲しかった。〇〇ニュータウンはそのような公園に出来る可能性はあったのでは。となりのトトロを見て何故か作成者の静かな怒りを感じた記憶がある。だからこそ、これまで〇〇ニュータウン出身であることを恥じていたのだろうか。

ミラノのBosco Verticaleみたいな建築家駆動マンションプロジェクトってどうやって調べたらよいのだろう。日本マンションは基本デベロッパー駆動なのだろうか。六甲集合住宅とかは建築家駆動っぽいが。

中古自動車の購入も検討しているが、ここまでババ抜き感は無い。というか、細かい性能やデータが分かるし、価格妥当性・説得力がある。この違いは何?

・2軍の試合で良いので、車で球場に行ってみたい。何かアメリカ映画っぽい。あと、コストコが凄いらしい。一回も行ったことがないけれど。

・ひとまずこの苦難を乗り越え、沢山の知識をつけて、x年後に眺望の良いエリア一人暮らし用の注文住宅発注したい。

追記 2020/7/17 12時頃】

書いて寝て起きたら、書き忘れた不満が幾つかあったので、ちょっと追記しました。

2020-05-19

最近コンシューマ向けアプリケーションは使いにくい

最近アプリケーションデザインは、「ユーザーが今、(詳細レベルで)何をしているのか」を隠蔽するようにできている。

たとえば、多くのスマートフォンアプリでは、端末内のデータを閲覧する際にディレクトリ構造ユーザーから隠蔽するように設計されている。

UNIXシステムに慣れ親しんだ者にとっては、こういったUIは非常に使いにくいと思う。たとえば、ディレクトリカテゴリー分けをしている場合ファイル種別作成日時等で勝手にまとめられると、分類に意味がなくなる。また、特定アプリケーション作成されたタグ等のメタデータは、他のアプリケーションでは意味を成さない。

これ以外にも、多くのアプリケーションでは、過剰なほどデフォルト動作が定められており、手続き原理的に決定できないような動きをする。喩えるなら、宛先を書かなくても手紙が届くようなものだ。最初の一人に出す時は問題ないが、少し進んだユーザーは、別の人に手紙を出す時にどう操作したら良いのか迷うことになる。

エンドユーザー向けのアプリケーションであればこれでも良いのかもしれないが、Windows10ネットワークとかデバイスの設定のような、そもそも詳細に設定したい時しか開かないようなものまで、簡易な設定画面が用意されている。非常に困ったことだと思う。

2020-05-07

anond:20200507202604

Podcastをやっているところだと、それぞれがローカルで音を保存しており、後からトラックを集約しているらしい。

それでも開始タイミングをあわせるのが大変だそうな。

あと数時間やっていると、最初は合っているのに、最後の方は1秒ほどズレてくる。

この辺り、ネットワーク使って時間情報メタデータとして使えば合わせれられないだろうか

2019-08-31

ある30代後半男の婚活日記

婚活を開始してある程度の期間が経過したので、情報をまとめておく。

参考:筆者のスペック
婚活開始のキッカケ

ネット上で一方的に存じ上げているプログラマの方が「オミカレ」に転職した。それによって「婚活パーティ」というもの存在することを知った。

ttps://party-calendar.net/

その方がすごく楽しそうに仕事をしているのを見て、自分婚活パーティに参加してみるか、と思うようになった。自分が諦めていた結婚というものも、まだ可能性があるかもしれないと考えた。

※こういったものに限らず、同業者の人が「面白い」と言っているもの自分にとっても面白いことが多いのである。その最たる例がゲーム漫画

婚活パーティ

数々の下調べを踏まえた結果、婚活パーティに参加してみることにした。

事前の準備として、以下のことを実施した。

いざ意を決してパーティに申し込んだところ、前日の夜中に電話で「パーティキャンセルになった」と言われた。明言はされなかったが、どうやら女性に比べて男性が多過ぎたのだろう。ここから得た学びは「直前に申し込むと、はみ出る」ということ。

1回目の婚活パーティ

2018年11月のこと。

前回の学びを生かして次に申し込んだパーティでは、実際に参加することができた。開催は土曜日の昼。8対8のパーティ。全ての女性と5分間程度会話できるものだった。普段顧客折衝の仕事と同じ要領で話を聞き、こちらのことも喋ったりして手応えを感じたものの、誰ともマッチングせず。喋り方、容姿学歴収入趣味、どれがダメなのかは不明

2回目の婚活パーティ

2018年12月のこと。

自分の何がダメなのかわからないまま、2回目のパーティに参加することに。土日開催とは違う参加者層を期待して、平日の夜のパーティに参加してみた。6対6だった。ここではマッチングすることができて、とても嬉しかった。しかし、この方とは2回のお食事デートの後、3回目(年末年始)を前日キャンセルされてしまった。その後、次の回の日程調整を進めるものの2ヶ月間ほど全て無理と言われてしまったため、フラれたと判断

3回目の婚活パーティ

2019年1月のこと。

次は土日開催のパーティに参加。8対8。ここで、2回目のパーティマッチングしてフラれた方と再会して気まずい雰囲気に。

それはさておき、他の人ともマッチングすることは無くて、ここから趣味が合うこと」が重要であることを推測し始めた。そう考えると、1回のパーティに参加して会うことのできる8人程度の女性の中から趣味の合う人と出会うのは相当に難しいのではないかと考えた。

結婚相談

もっと多くの候補者の中から相手を見つけるのが良いだろうと考えた結果、結婚相談所を利用することを考え始めた。最初に行き着いたのは、これまでに参加した婚活パーティの一つの主催者でもある、恐らく最大手であろう「IBJ」が運営している「日本結構相談連盟」だった。

この連盟に加盟している、近所の結婚相談所のWebページの様子を見に行ったのだが、ここで立ちはだかったのが、学歴の壁。

観測できる限りにおいて、IBJ加盟の全ての結婚相談所にて、会員登録するには短大高専以上の卒業証明書必須なのだ。おそらくIBJ本体方針なのだろう。筆者はいくら入学試験の難しい大学に入ったとは言っても中退なので、このIBJ基準では高卒扱いなのだ。幸いにして、筆者は通信制大学編入して経営学を学び始め、2年後には卒業見込みであるため、2年後の時点でも結婚の目処が立っていないのならば結婚相談所のお世話になろうと考えた。

女性立場になって考えれば、卒業証明書の提出を求めるような相談所じゃないと、高いお金を払いながら安心して婚活するのは無理だというのは筋の通った話なので、IBJ系列以外の結婚相談所のことは調べることすらしなかった。また、前年である2018年年収の実績値が400万円程度しかないというのも、所得証明を求める結婚相談所の利用を延期する理由になった。

婚活アプリ

趣味の合う人を探す効率のことを考えると、同世代人口の多いサービスを選ぶことが大事そうであるネット上の噂を参考にすると、その条件に最も合致しそうなのはペアーズ」である判断して利用し始めた。

ttps://pairs.lv/

使ってみた最初感想は、「Facebookタイムラインには一切何も投稿しない」のは本当だった!ということだった。権限も求められなかった。少なくとも筆者の利用時期&利用内容においては。(余計な投稿をされることは一番恐ろしい話だ)

Pairs 最初の使い方

まず、趣味の合いそうな人を探し始めた。とは言っても、キーワード検索等をするにはさらなる課金必要であるため、次のようなルールで行動した。

という使い方をした。一番最初マッチングした人にメッセージ送信したところ、数分後にブロックされるという洗礼を浴びた。

次にマッチングした方とは、互いのこれまでの人生の歩み方について3週間ほどメッセージを交わし、直接お会いすることになった。最初にお会いした際に別の通信方法確立されたため、Pairsにはアクセスしないようになる。その後、3ヶ月間ほどに渡って何度かお会いしていたものの、1ヶ月間ほど連絡が途絶えた。ふと気になって久し振りにPairsを開いてみれば、ブロックされていた。恐らく、最後に会って話題死生観になった際に、お相手の傷つくようなエピソードが含まれていたせいじゃないか分析しているが、確かなことは何もわからない。

という訳で進捗はゼロに。

Pairs 次の使い方

面の皮を厚くして「同時に複数の方とメッセージを交わす」ことを気にしないことにした。言い換えれば、己の清純さよりは、運命相手に辿り着くまでの時間の短さを優先した。そのため、とても多くの方のプロフィールを閲覧することになった。

Pairsでは、お相手検索結果の並び順は、30分〜1時間程度ごとに変わる。恐らく、時刻を種とした乱数を使って検索結果を並べ替えているのだろう。というわけで、デフォルトでは1ページ16件の検索結果が表示されるのだが、1ページ目を参照し終わって2ページ目に移動すると、さっき1ページ目で見た人が居る、ということが頻繁に起こる。もちろん、アイコンを全て覚えるなんてことは無理なので、同じ人に何度もアクセスすることになる。

更に、女性プロフィールで時々見かけるこの言葉「同じ人に何度も足跡をつけられてて気持ち悪い」。これが心に刺さる。では、足跡を何度もつけることの無いように、より多くのプロフィールを閲覧するにはどのようにすれば良いのだろうか? まず、足跡は残さない設定にできる。しかし、それは「気持ち悪い」と思われてしまうことへの対策しかなっておらず、同じプロフィールを何度も閲覧してしまうことへの対策にはなっていない。

そこで筆者は、閲覧したプロフィールは必ず、いいねを押すかブロックするかのどちらかの行動を取るようにした。この方法ならば、時間計算量 O(N) でのプロフィール閲覧が可能になる。弊害としては、ブロックした方は二度と Pairs 上では見ることができないし相手からも見られない、ということが挙げられる。悲しい話ではあるが、素早く運命相手に辿り着くには仕方のないことだ。代替案として、ブロック機能ではなく「非表示機能の利用も考えられるが、事実上ブロックと同じであるため、ブロック採用した。

概ね、次のような基準操作をした。まるでパケットフィルタファイアウォール)の設定のようだ。

この結果、おおよそ1ヶ月間という短い期間でもなんと7人もの方とマッチングすることができたし、3人という大勢の方と直接お会いすることができた。これは絶大な成果であることは間違い無い。日常生活では絶対に得られることの無い成果だ。課金価値はあった。

筆者の Pairs 統計情報

参考にどうぞ。

こうやって見てみると、メッセージを2往復することができれば直接会うことのできる確率は高いようである試行回数が少ないあたりには目を瞑ろう。

Pairs 退会

直接お会いすることのできた方は前述のようにおられたものの、その後が続かない形になってしまたことと、精神的にも身体的にも疲れてしまった(システム利用はどうしても夜中になるので疲弊する)ことと、最初にPairsに支払った6ヶ月間の利用権も期限を迎えそうになったため、活動休止して退会した。でも、退会直前の利用方法ならば可能性は十分にあるかなという手応えだったので、前述の通信制大学卒業してから出直すこととする。

さいごに:全体的な感想

定職に就いて収入さえしっかりしていれば通常の恋愛結婚の場面では問題は無いだろうが、これらのお見合い的なシステムにおいては、やはり学歴等のフィルタにかけられることは多いだろうと推測している。やはり、フィルタで振るい落とされない 強いメタデータ というのは婚活する上ではとても重要なのだろうと思う。

2019-04-30

立命館大学ゲームを寄贈するとメディア芸術更新される?

http://www.rcgs.jp/p/option2.html

これらの所蔵品は、研究者大学院生学生などのゲーム研究のための基礎資料に用いるほか、本OPACや本センターゲーム分野の構築を担当する「文化庁メディア芸術データベース」など、ゲームデータベース書誌レコード作成目的とするメタデータ取得用資料として活用しています

まり立命館大学ゲーム研究センターゲーム等を寄贈すると、文化庁メディア芸術データベースの方が更新されるのでしょうか?

ただ、後世までにずっと資料を残しておくという事であれば国会図書館に寄贈した方が良いのでしょうか?

https://ndlonline.ndl.go.jp/#!/detail/R300000001-I027284321-00

Wii fit U フィットメーターセット

あとは、東の国会図書館、西の立命館大学ゲーム研究センターの両方に寄贈しておけば完璧という事も出来るかもしれませんが。

そこまでする人がいるかどうかは分かりません。

ちなみに立命館大学ゲーム研究センター活動の一例。

https://www.4gamer.net/games/999/G999905/20180720154/

2019-04-11

セキュリティちょっと怖い話

3行まとめ

- 会社情報システム部局が配布した業務手順書に、出所の怪しいソフトウェアが紹介されていた

- 今のところ実害は出ていないが、社内に何か潜伏してしまったのでは?と不安になる

- 怖いかフェイクを交えてお話するよ

序章

- 私の勤務先は、全国に支社があったりする、まぁまぁ大きな会社

- 最近オフィスソフトウェア統合クラウド環境が整備され、全社的に統一的なIT環境が整備された。

- 情報システム部からメールデータ移行の手順書が配布され、手順書の中にeml形式pst形式に変換するツールが紹介されていた。

- ソフトウェアの配布ドメインmicrosoft.com 。ページタイトルは「EMLファイルPSTエクスポートするためのEMLからPSTへの変換 - 公式ツールキット」

気づき

- 私はそのソフトインストールしようとしたが、天性の直感がそれを妨げた。

- ドメインをよく見ると、 gallery.technet.microsoft.com 。マイクロソフトコミュニティポータルである

- そこにあったソフトウェアマイクロソフトでなく、いちユーザアップロードしたソフトにすぎない。

- アップロードしたユーザ名は日本人っぽいが、紹介文の日本語機械翻訳っぽい。

- そのユーザアクティティみても、類似機能(ファイル変換系)を持つソフトをアップしまくってるのみ。

exe調査

- ここでexe分析たかったのだが、残念ながら趣味プログラマの私には荷が重い。私の技術力で分かったのは次の通り。

* アップロードされていたソフトは、 mailsware社 製の EML File Converter というソフトのVer2.0、とメタデータから推測された。もしくは、それにさらに改造を加えたもの

* ちなみにmailsware社のページで配布中の最新バージョンはVer2.4。

* (ネットワークから遮断したPCで)インストールして動作させると、ちゃん機能してくれるっぽかった。

* でも、不要と思われる itextsharp.dll とか interop.domino.dll とかも入っている。(ほかの変換系ツールと開発を共用しているのか?)

検索による調査

- ここから技術力でなく、ぐぐるである主観憶測が多いため、話半分で。

- そもそも mailsware社 も怪しいよな、と思う。

* ホームページ上は2014-2019を謳うがドメインは2017取得。

* 会社所在地ストリートビューにはそれらしいオフィスは見当たらないほか、サイト上の地図が不自然に感じた。

* Ver2.4インストーラを見たところ、 recoverytools社 が実際にはソフトを作っていると思われる痕跡

- recoverytools社 これもまた怪しい、と私は思う。

* サイトではIndia会社とあるが、本当だろうか?

* Twitterアカウントもあるが、そちらではNY会社と謳っており、LinkedInアカウントではLA所在記載するなど。

* でもLinkedInフォロワーは一人。

* Twitterでは(ヒンディ語の(内容の薄い)ツイートリツイートしたりも)

* ドメイン2002年からあるが、当初から売地。2017年に今の状態

- など、確たる証拠は見つからないまでも、このあたりはSNSを辿っていくと、怪しいと思えるアカウントしか出てこなくて、三文小説のようで結構面白い

終章

- 情報システム部門には情報を上げて、当該ソフトの紹介は手順書から消してもらった

- ダウンロード数は1000超えてるし、わが社でも10人やそこらは気づかずにインストールした人が居るのでは

- なんか、怖いなー。って普通に思いました。

- 私に技術力があれば、NSAのGhidra?とかでexe分析してみたい、と思いました。

2019-03-25

Stadia開発者インタビュー その3

ブツブツ切れる・・・

Youtubeマクロミクロレベルで数多くのネットワーク状況に対する情報提供してくれます。我々はそれらの情報も利用可能ゲーマー体験を調整、拡大が可能です。

しかユーザYouTubeの画質をゲーム内の品質だと思ってはいけませんよね?

その通りです。StadiaをYoutubeとは異ならせる2つの事象がありますYouTubeバッファ使用可能リアルタイムでもなく、ゲームのようにインタラクティブでもありません。Stadiaはバッファリングができません。Stadiaはフレーム数が絶対的に正確である必要があります

次に2つ目ですが、ユーザDoomやAssasin's Creedレベルの画質のゲームを遊ぶ場合、その期待はYouTube向けにユーザ作成したコンテンツよりもずっと高くなります

さらにもう1つお話する価値がある点として、YouTubeとStadiaの繋がりについて今後も多くのことを話し、デモをしていきますが、大前提としてゲームとはリンクであり、リンクは無数の方法で配布、探索、共有が可能であることが挙げられます

すると例えば土曜の夜10時にDoom Eternalを遊ぶ計画をしたとして、Webページボタンを押すだけで我々を貴方方に加えることが可能だと言えますか?

その通り、全く仰る通りです。あなたが仰った通りのシナリオになります。また例えばEurogamerが新しいゲームレビューしているとしたら、ユーザレビュー記事クリックするだけでダウンロードすることもなく、パッチを当てることもなく、インストールすることもなしに簡単にそのゲームを試すことが可能です。また他にはあなた記事が新しいマップキャラクターレベルについて記述している場合でもそうです。我々にはState Share(状態共有)と呼ばれる既存技術と一緒に働くとても強力な新技術を用意しています

State Shareは本当にとても強力な機能ユーザが最新のバージョンゲームを遊んでいる時に、同時に友人や私、または世界中にそのゲームストリーミング可能です。誰が相手でも問題ありません。またユーザゲーム内での最新の武器、例えばDoomのFlaming Swordや、とにかくそゲームで最高のアイテムを入手したとします。そして私が「カッコイイ! 私もそのFlaming Swordが欲しい!」と考えたとしましょう。私がそのビデオクリックすればそのメタデータがそれら全ての属性を直接私のゲームにも転送します。だから誰でもが他人ビデオストリームに飛び込めるだけでなく、その他人の状況全てと共にゲームに飛び込めるのです。これは開発者ゲームが設定可能です。これについては他にも例がありますが、1つはユーザゲーム特定の難しい状況に陥った場合に、ユーザコミュニティにその状況を解決できるか試してもらうことが可能です。全く同じ状況で渡すことができます

我々がYoutubeとの接続で行っている別の例は、典型的シナリオとして、私がパズルベースアドベンチャーゲームをやっている場合によくある状況があります。そのゲームのあるポイントで立ち往生してしまいました。その特定パズル、例えばトゥームレーダーのある墓や何かができないとしましょう。現状では電話を取り上げるかラップトップに向かいヒントをダウンロードするでしょう。それかYoutubeに向かって動画を探します。しかしStadiaではボタンを押して「Hey, Stadia. このボスはどうやってやっつければ良いんだい?」と聞きます。するとStadiaがYoutube動画を探してきてゲーム内で再生します。私はレベルの解答を見て続けることができます

先程、申しましたゲームとはリンクであるとの点ですが、任意Webサイトリンクを持つことができますDiscordFacebookTwitter電子メールテキストメッセージWhatsAppGoogle検索結果、さらにはGoogle Play Storeですらゲームの配布が可能になります

それはどのように動いていますか?

リンクです。

でも基本的に分離されたシステムですよね?

そうです。インターネット全体に渡り分散された広大な領域の利点を得ています。我々は開発者パブリッシャに対し、インターネットストレージであるとのコンセプトを広めています。もちろんStadiaは専用のストレージを持っていますしかし我々は開発者に対しゲームを自社のコミュニティへ持っていくことも、例えどこにコミュニティがあろうとも許可します。このことが配布と探索を開発者にとってとても良い意味で逆さにします。また我々にはとても高速なマーケティング技術がありますので、パブリッシャは体験をできる限り多くの人々にとても効率の良い手段で配布することが可能です。


もっと全体的なレベルで、抜本的にStadiaはYoutube統合しているのですね。ではプラットフォーム上の全てをどうやってモデレートしますか?

コミュニティに対するモデレーションにはとても強固なアプローチを取りますYouTubeは途方もない投資をこの領域に行ってきました。我々はそこに提携をし、さらに家庭レベルでも行います。我々はこの業界でも最も優れたペアレンタルコントロールゲーマー健康コントロール提供します。両親は子供が何を遊ぶか、誰と遊ぶか、いつ遊ぶかを管理可能です。

その点に関してはデータプライバシも気になります。それらは全て既存Googleインフラに紐付けられるのですか?

我々は全てをユーザ制御下に置くことを使命としていますGoogle提供する制御機能と同じレベルのものがStadiaでも提供されるとお考え下さい。

ユーザサイドでゲームを行うことやこれまでのコンソール文化は滅ぶでしょうか?

それは私共が答えることではありません。Stadiaはゲームの新しい開発の仕方、ゲームの新しい探し方、ゲームの新しい楽しみ方を提供します。我々には大きな未来への志があります。大規模に発展したいと考えています。それは一晩で起こることではありません。また我々はこれまでに存在し、我々をここまで導いて下さった物、全てを尊敬しています。私達は業界全体が成功し、成長することを望んでいます

Stadiaの開発者インタビュー その2

やっぱり途中で切れたので続きから


サービス提供を開始します。

するとシステムの準備は万端で、必要ソフトウェアの開発が必要ということでしょうか。Microsoftを見ますと、彼等はXBox OneのHWをサーバラックに積んでいるようです。あなたがたの手法とは異なりますか?

違います

するとGoogleインフラバックエンドのみでなくソフトウェアにも投資を考えていますか?

そうです。

自身の開発スタジオも考えていますか?

はい。Stadia Games and Entertainment組織を発表しました。これは我々の1stパーティスタジオです。

それが今起こっている?

はい

Google開発者に対し全てのツール支援しています。Stadia向けの開発は彼らにとって別のターゲットしか過ぎません。Visual Studioを用いる既存ツールや彼らが用いるツールの全てと共に、彼らのワークフロー統合されます。従ってStadia向けの開発はPlayStationXbox向けの開発と同じくらい簡単です。

我々はUnrealサポートします。UnityがStadiaサポートします。予想される多種多用な業界標準ツールミドルウェアが準備されます

意地悪な質問します。Googleコントロールを超えたものがありますよね。特にユーザサイド、クライアントサイドのインフラ家庭内安価ルータです。このような問題をどのように解決しますか?

とても良い質問です。我々はユーザに対し彼等のインフラの中で何が起こっているかをできる限り理解できるよう支援する必要があります。また我々はゲーマーに対し最適な体験を得られるようなチューニングを行うことが可能情報に対し投資を行うだけでなく、我々自身技術を用いて最良のパフォーマンスを実現するつもりです。Google技術の多くがインターネット網の基盤であることを思い出して下さい。我々はDCから情報がどのようにユーザに届くかを良く理解しております。できる限りの最適化を行うつもりです。

デベロッパパブリッシャは既存ゲームをStadia移植できるのですね。しかし同時にGoogleは新しい選択肢も数多く提供できると

その通りです。それこそが我々のプラットフォーム根本的な差別化ポイントです。既存ゲームカタログを持つデベロッパにとってStadia簡単で親しみ易いものです。我々はできる限り摩擦なくゲーム移植を行えるようにします。なぜならゲーマーは好きなゲームを遊びたいですし、彼らの愛するキャラクターストーリー世界を楽しみたいのです。しかし我々はまた開発者未来を描く新しいキャンバスをも提供します。ゲームを高速に配布し、プレーヤーと新しい手段で、特にYoutubeにて繋げます。そして開発者が持つアイデアを実現するための前例の無い技術提供します。


これまでのクラウドシステムクライアントサイドの限界基本的に画質やレイテンシに起こりました。明らかにこれらの問題インパクトはここ数年で新たにより良い技術を得ることとインフラ改善されることで緩和されてきました。しかローカル品質ストリーミング品質との間には今でも根本的なギャップ存在します。私はidソフトウェアZenimax特許を見たのですが彼らはh.264のモーションベクター効果的に用いてクライアントサイドのある程度の予測を立てレイテンシの知覚を減らしていました。Project Streamにも測定可能レイテンシ存在します。ギャップを閉じるために何をしていますか? これらの問題解決されたでしょうか。それとも少なくとも緩和はされましたか

解決されたと同時に緩和されています。まずデータセンターに対しより多くの人々がより良い経験を得られるようにするための投資が行われました。また圧縮アルゴリズムについては我々に抜本的な先進性が存在します。Google圧縮アルゴリズム標準仕様先駆者でありこの点がストリーミングの将来をより確実にします。残念なことですがGoogleでも制御できない点が光の速さです。そのためこの点が常に要因となりますしかし常に理解しなければならないこととして、我々は常にエッジ(終端)にもインフラを構築していることが挙げられますGoogleの中心にある巨大なデータセンタだけではありません。我々はできる限りエンドユーザの側にインフラを構築しています。それによって歴史上の幾つかの問題回避することが可能です。さらにまだ率直な、あまり洗練されていないProject Streamのストリーマーでも信じられない結果を出していますさらに我々はサービスリリース時に1080p60を超える品質を実現できるだけの根本的な改善を行いました。我々は8Kに至るでしょう。

それは素晴しい。それらの改善は全て圧縮に関連するものですか?

圧縮ネットワークです。我々はGoogleインフラに投入した数々の改善点に依っています。BBR、QUIC、WebRTCを基盤としてその上に構築がなされました。だからIPパケットの低レイテンシでの配信だけでなく、送信元へのフィードバックも行うことが可能です。ですのであなたが仰るZenimax使用した技術なら、彼らはここでも利用することが可能です。彼らは彼らのゲーム最適化を行うことができるでしょう。我々はフレーム毎のレイテンシ予測可能で彼らにそれに合わせて調整を行わせることができます


入力を受け取って、ゲームロジックを処理して描画を行うと、60Hzのゲームでは50ms程になります。続いてエンコード転送デコード、表示を行うとストリームではPC上のゲームに比べさらに60ms程かかります。これを改善することはできますか?

我々は改善を続けますStream最初バージョンです。我々は性能向上のために調査を行っており、レイテンシ適応していきますリリース時にはより良くなっているでしょう。

クラウドシステム接続可能性に従って成否が決まります。例えばRed Dead Redemption 2を数万、数十万、場合によっては数百万のプレーヤーオンラインにて同時に立ち上げるとします。システムの成否はアクセスによります。もしゲームプレイできないなら重大な障害となります

かにそのとおりです。そしてそれこそがGoogleが何年もかけて開発してきたスキルであり、抜本的なスケールする能力です。我々がどうやって実現しているのか、何をしてきたかについては今日は詳細にはお話しません。しかGMailMapYoutubeが同時に利用可能であるためと同じ基本的技術のいくつかが我々が依るものです。


我々は現在、現行世代が終了する移行の時を迎えています。これまではコンソールベースラインを定めてきました。Stadia次世代XboxPlayStationに対抗できると考えますか?

我々は競合他社が何をしているかは存じておりません。

でもGoogleには良い予測を立てられる優れた人々がいますよね?

我々の第一世代システムに導入されるGPU10Tflops以上の性能があり、さらスケールアップしま

GPUユーザ間で共有されますか? それとも1人のユーザが独占しますか?

単一インスタンスです。

NVIDIAGPUですか?

AMDです。

カスタムGPUだと思います

カスタムGPUです。

Google要件のために作られた訳ですね。他にも公開できる情報はありますか? Vegaですか? それともNavi、もしくはさら新世代ですか?

情報を公開したくない訳ではないのですが、このプラットフォーム進化することのほうがより重要です。そしてこの進化ユーザ開発者の双方に対しシームレスに行われることを確認して頂きたいのです。そして進化は常に継続し、誰もが常に最新で最高の物を手に入れます

クラウド確約する点ですね。ユーザはHWをアップグレードする必要がないと。

開発者にもこのように考えて欲しいのです。もちろん完全には抽象化されていません。特にゲーム開発者にとっては。しかし我々はそれでもこのプラットフォームが常に進化していると考えて欲しいのです。速さや容量、リソースには制限されていないのだと。

AMDGPUを使うことでStadiaと他のコンソールの間に共通な点ができました。開発者にとって利益となるでしょうか?

シェーダコンパイラツールをいくつか開発しました。これらは開発を楽にするでしょう。しか現在GPUはとても優れており開発者が既にVulkanに親しんでいれば、例えばid Softwareさんは既に全てVulkanに移行していますが、そのような開発者の方々には既存ゲームをStadia移植するのはとても簡単です。Doom Eternal4K、60フレームで動いでいるのは既にご覧になったと思います。非常に素晴しい状態です。これこそが我々にとって重要証明ポイントです。FPSグラフィックプレイアビリティの双方で要求が高いゲームです。 従ってこれは我々のプラットフォームの強力な証拠であり、idさんにも講演して頂きます

CPUについては何か公開できる話はありますか?

x86で2.7GHzで動作しています開発者にとり慣れのあるものです。開発全体を通して、CPUは制約となる要因ではありません。我々は全てのタイトル動作するに十分なCPU提供します。

コア数、スレッド数は?

沢山です。

8コア、16スレッド? それより多い? 少い?

公開できない情報です。ハイパースレッド使用しています

しかサーバ級のCPUです。Stadiaはこれまでのコンソールと違いパッケージングに制約を受けません。熱対策問題も異なりますコンソールとはサイズパッケージング動機が異なりますデータセンタの中でそれはとても汚なく見えるかもしれません。一方でとても帯域幅が高いメモリ使用可能で、とても高速なペタバイト級のローカルストレージ使用可能です。ご家庭のコンシューマデバイスよりも数百倍は速い物です。

するとそれが開発者が全く異なる体験のために利用可能な要因となる訳ですね。得られる機会はとても大きいことでしょう。しかし我々はマルチプラットフォーム時代生活していますGoogle先進的な機能は1stパーティのみが利用できるものですか?

パートナーには彼らが話せる時点で彼らの計画を教えてくれるよう伝えています。Stadiaをこの世界で最も偉大なゲーム開発者達に説明することにはとても興奮します。Stadiaは、開発コードではYetiと呼ばれていましたが、Stadiaビジョン説明すると、開発者リアクションは「これは私が期待したもののものだ。これはまさに我々の次のゲームのためのビジョンのものだ。elastic computingの考え、次世代レベルマルチプレーヤー環境ゲームを観ることと遊ぶことの境をあやふやにし1つの体験にすること」と話されます

イノベーションの1つの領域として、最初のほうで述べましたが、マルチプレーヤー環境において、単純にパケット複数プレーヤーリダイレクすることから原子時計レベルでのコンシステンシーを全ての状態遷移において定期的にクライアント間で更新する真のシミュレーションへの移行が挙げられます。これにより開発者はこれまでには不可能だった分散された物理シミュレーションを得ることができます。これだけでもゲーム設計イノベーションに対し大きく寄与します。このため多くの開発者が、大袈裟でなしに、実際にとても感動的なリアクションを我々のプレゼンに対して返して下さっています


多くの問題解決し、規準を上げる可能性がある訳ですね。

これこそがゲーム業界の素晴しい点です。技術が常に創造性を刺激し、ゲームに対しより大きな聴衆を作り、そのことがプレーヤー開発者に対しより大きな機会を作ってきました。エコシステム進化し、正の方向に回り続けるなら、それはゲームを遊ぶことにとって良いことです。

あなたは先程、スケーラビティとStadiaがどのようにしてより多くのリソースを立ち上げ増大する要求対応するかについて話して下さいました。しかし、同時に10TflopsのGPUサーバクラスCPU存在するとも仰いました。リソース拡張をどのように行うのですか?

3台のGPSが一緒に実行されるデモを行っています。私は上限が無いとは申しません。しかし我々は技術上の限界を上げています。そしてStadiaは静的なプラットフォームではありません。このプラットフォームは5年や6年の間、レベルが変わらない訳ではありません。開発者プレーヤー要求に従い、成長し、進化するプラットフォームです。なぜならStadiaデータセンタの中に構築されています進化させるのは我々にとって簡単なことです。

ここまで第一世代について多くのことを教えて頂きました。すると第二世代やその後の世代もあるでしょう。現状でもスケールアップできるわけですが、3台のGPU連携次世代でも可能ですか?

CPU/GPU/メモリ帯域幅の変更にはいくつかの自然な段階があります。これは家庭の物理な小売の端末よりももっとスムースでより継続的な進化です。しかし、より重要なことは基盤データセンタ網とそれに含まれネットワーク技術への投資です。この2つが一致して行われることが重要でどちらか1つではダメなのです。

先程、エッジ上のインフラについて触れられましたが、例えばNetflixISPキャッシュインストールしている状況があると思います。これがGoogleが行っていることですか? それとも既にYoutubeで行われていますか?

それは我々も既に行っていますGoogleが既に20年以上、行っていることです。我々が依って立つまた別の巨人の肩です。


Project Streamではユーザに対し最低で25Mbpsの帯域幅要件しました。これはストリーミングのみのためですか? それとも他のユーザが同時に同じインスタンス接続する場合を含みますか?

我々はStreamさらに強化させています。従ってユーザはこの制約が全体のスタックに対する改善最適化、また特に時間によって緩和されることを期待するでしょう。我々はその期待の上を行きます

4K60には相当の帯域幅がいるのでしょうね?

4K60はもちろんより要求が高くなります

1080p60は低くなる・・・

私は具体的な数値についてはコメントしません。しかし当然低くなります

インターネット接続環境はStadiaリリースする市場では全体的に上昇機運が見られます。つまりこのパフォーマンス特性ますます多くのユーザが利用可能になります

さらに繰り返しになりますが、BBRを初めとする我々の技術がありますさらに覚えておいて頂きたいのは我々のネットワークに対する理解そのままではありません。それらもまた時と共に改善されていきますYoutubeマクロ

Stadiaの開発者インタビュー

Eurogamerにより独占配信されたStadia開発者二人に対するインタビュー記事

https://www.eurogamer.net/articles/digitalfoundry-2019-google-stadia-phil-harrison-majd-bakar-interview

やっつけなので可能なら原文を読むことをお勧めします。

---

なぜ今なのでしょうか?

タイミング問題です。20年間の蓄積によりGoogleにはデータセンタ内のパフォーマンスに優位性が存在します。Googleデータセンタ内ではHWメーカーです。我々はデータセンタ内で何年もの間、高い性能で端末間を接続する基盤を構築してきました。Youtubeでの経験からプレーヤーサイドの観点からだけでなくデータセンタ内部から技術観点から技術統合を行ってきました。他社でもその視点存在していますGoogleにはその点に固有のアドバンテージ存在します。

これまでの箱をTVの下に置いておいたパラダイムに比べ、無限演算リソースによる可能性が現れます。これまで存在しなかったことをできる可能性があります

その通りです。我々にはレガシーがありません。全てが21世紀のために設計されています開発者制限の無い計算資源が利用でき、何よりもマルチプレーヤーサポートできます。これまでのマルチプレーヤー環境は一番遅い通信に影響を受け開発者は最も遅い接続に対し最適化必要でした。我々のプラットフォームではクライアントサーバも同じアーキテクチャの下にあります。これまではクライアントサーバの間のping支配されていましたが我々の環境なら最速でマイクロ秒で済みます。だからプレーヤーの数は単一インスタンスにて動的にスケールアップが可能です。バトルロイヤルなら数百から数千、数万のプレーヤーが集まることも可能です。それが実際に楽しいかどうかは置いておくとしても、新聞ヘッドラインを飾ることが可能技術です。

クライアントサーバの双方でこの利益を得られるのでしょうか

両方です。

すると開発者に対しStadiaホリデーシーズンにぴったりの最高の製品だと言えると。理に適った範囲無限計算資源が得られると。

ユーザが我々のプライベートLANからはみ出さないだけでもその効果は大きいものです。Googleは45万kmに及ぶ光ケーブルにより世界中データセンタ間を接続しています米国西海岸から東海岸まででも20ms、フランクフルトからマドリッドでも20ms。これにより開発者は最も極端な場合においてもレイテンシ予測可能でそれに従い設計を行うことができます


Youtbeとの統合について教えて下さい。

StadiaYoutube技術と深く結びついていますが、実際には一歩引いています今日ゲーム業界を考えてみて下さい。2つの世界共存しています。1つはゲームプレイする人々で、もう1つはゲームを見る人達です。2億人の人々がYoutubeゲーム毎日見ています2018年には述べで500億時間ゲームを視聴するのに費されています時間人口の双方で信じられない程の視聴が存在します。我々のビジョンはこの2つの世界を1つにすることでゲームを見ることができ、かつ、プレイもできる、双方向に楽しめることです。

まり重要なのはゲームシステムでもなくコンソールでもありません。噂とは異なり我々はコンソールビジネスには参入しません。我々のプラットフォームの要点はコンソールでは無いことで、皆が集まる場所を作ることです。我々は箱でなく場所を作る。今までと異なる体験を得られる場所です。ゲームを見るなり、遊ぶなり、参加する場所であり、かつユーザが楽しむ場所であり、ユーザ他人を楽しませる場所です。

から我々のブランドはStadiaといいます。これはスタジアム複数形です。スタジアムスポーツを行う場所ですが同時に誰もがエンターテイメントを楽しむ場所でもあります。だから我々はそれをブランドにしたかったのです。皆が遊んで、観て、参加して、さらにはゲームをする場所。一歩下がって見ることもできる場所。常にどのボタンを押したか意識しないでも良い場所。他のアーキテクチャでは実現できない場所です。

まりリアルタイムシミュレーションゲームで全ての駒が人々であるようなものですか?

その通りです。そして単純に技術的に深い点を求めて、我々は第一世代でも4K60fpsHDRサラウンドサポートしました。さら開発者必要インフラに従ってスケールします。それだけでなく、同時にYoutubeに常に4K60fpsHDR画像送信することが可能です。だからあなたゲーム体験の思い出は常に最高の状態になります

Googleは全てを記録するでしょうか?

プレーヤー次第です。Googleは全てを記録はしません。もしプレーヤーが望むならGoogle4Kストリームしま

共有が友達だけか、世界中に公開かも自由選択可能です。Googleユーザ制御を明け渡します。もしユーザYoutubeで公開すれば誰でもリンククリックすることでそのゲームを遊ぶことができます

するとユーザshareするだけで誰でもがその特定ゲームに参加することができる訳ですね。

そう。そしてこれはマルチプレーヤーゲームロビーの新しい形となりますYoutubeクリエイターなら誰でもがファンチャンネルのsubscriberを自分ゲームへと誘うことができます生主として、Youtubeクリエイターとして私は視聴者を私のゲームに瞬間的に招待できます。それが私と10人の友達でも、(訳注: セレブの)Matpatと彼の数百万の購読者でも、技術は同じです。

アカウントシステムベースYoutubeですか?

Googleアカウントの一部です。従ってGMailアカウントがStadiaへのログインに利用できます。他の基盤についても説明させて下さい。最初サービス立ち上げから全ての画面への対応を行いますTVPCラップトップタブレット携帯です。我々のプラットフォームの基本は画面に依存しないことです。これまで40年間、ゲーム開発は端末依存でした。開発者として私は制約の範囲内で、私の創造性を開発対象の端末に合わせてスケールダウンする必要がありました。

我々はStadiaでそれを逆にしたいのです。我々は開発者に対し彼らの考えをスケールさせ、どの端末の縛りから解放したいのです。パフォーマンスに優れ、リンククリックすればゲームは5秒以内に開始されますダウンロードもなく、パッチもなく、インストール必要なく、アップデートもありません。多くの場合、専用のHWも必要がありません。従って古いラップトップChromeブラウザ使用する場合にでも皆さんが既に持っているだろうHID仕様に準ずるUSBコントローラ動作します。そして、もちろん、我々自身コントローラも開発中です。

なぜ独自コントローラを作るのですか? USBコントローラはどこにでもあるじゃないですか

コントローラ自作する理由はいくつかあります。1つはTVへの接続です。我々はChromecastをストリーミング技術採用します。Stadiaコントローラの最も優れた機能の1つはそれがWiFi接続DC内のゲームに直接接続することです。ローカルデバイスとは接続しません。

それは面白い。するとほとんどそれ自体が端末な訳ですね。

その通りです。これこそが我々のブランドの実現であり、具現化です。そして独自コントローラにより最高のパフォーマンスが実現します。ゲームに直接接続するためにプレーヤーは画面を移動することが可能です。プレーヤーはどの画面でも自由に遊び、停止し、他の画面でゲームに復帰することが可能です。

そしてコントローラには2つの追加されたボタンがあります。1つはGoogle Assistantの技術マイクを用いますユーザ選択により、ユーザプラットフォームゲームの双方に対し、自然言語を用いて会話が可能です。例えば「Hey, Google。MadjとPatrickと一緒にGame Xをやりたいな」と言えばStadiaマルチプレーヤーゲーム指定した友人と共に直ぐに開始します。

するとGoogle伝統的なUI回避するのですね?

我々はゲーマー可能な限り素早くゲームに辿り着かせるよう考えています。数多くの研究を行いましたが、多くのゲーマーゲームを起動したら直ぐに友人とゲームを開始したいと考えていますゲーマーUI時間を費したくは無いのです。

誰かが言ったことですが、現在コンソールは起動した時にまるで仕事のように感じると言うのです。ゲーム自体更新や、ゲーム更新があります。我々はそれらを完全に取り除きたいと考えています。もう1つのボタンは、ちょっと趣が異なるのですが、Youtubeシェアできます

端末は何でも良いのですね? スマホスマートTVも?

Youtubeが観られるならどこでもStadiaは動きます

TVへの接続にはChromecastが使用されると。では実際にはどのように動きますか?Chromecastがスマホラップトップからストリーミングを受け取るのでしょうか?

Chromecastはスマホからストリームを受取はしません。Chromecastはスマホから命令のみ受けます画像NetflixYoutubeから直接受け取ります。Stadia場合、StadiaコントローラからChromecastへとこのゲームインスタンスへと接続せよと命令がなされ、Chromecastはゲームインスタンスから動画ストリームを受け取りますクライアントはとてもシンプルです。行うのはネットワーク接続ビデオと音声のデコードのみです。Chromecastは入力を処理しません。全て入力コントローラが扱いますビデオと音声とネットワーク接続Chromecastの基本動作で全て既に組込まれています

Stadiaの起動はどうするのですか? コントローラで?

そうです。とても良く出来ていますWiFiに繋ぐだけです。コントローラにはWiFiIDとPWを入れるだけです。それだけです。ホームボタンを押すと勝手Chromecastを探し直ぐにChromecast上でクライアントを起動します。UIが表示され直ぐにゲームを遊ぶことができますデジタルパッドでUI操作することも可能です。これが重い処理を全てクラウドへと移行する点の美しさです。Chromecastのような低消費電力の端末で説得力のある体験ができますChromecastは5W位下です。Micro-USBで給電可能です。典型的コンソール100から150Wもします。またこれまで説明しませんでしたが、例えスマホでも行うことは動画再生だけです。従ってAssassin's CreedDoomや他の重いゲームあなたスマホの上でモバイルゲームよりも低消費電力で動作します。だからスマホ10時間でも遊べます

スマートTVではStadiaYoutubeクライアントに組込まれるのでしょうか。それともStadia独立して起動させますか?

今の所、我々はChromecastのみに集中しています。でも技術的、機能的な観点からYoutubeがある場所ならどこでも動きます。我々はまだStadiaをどのようにユーザに届けるかは検討中です。

コントローラに話が戻りますが、モバイル端末にはやはり物理的なアタッチメント必要に思われます。例えばスマホコントローラ接続するような。MicrosoftのXCloudを見ていると操作には実際に問題があるようです。

Googleには解決手段があります

そうでしょう。スマホコントローラ取り付け以外にも、明らかな解決手段としてSwitchのようなクライアント端末を作るのでしょうか?

サービス開始時から提供されるサードパーティによる解決手段サポートしています。他にもアイデアがありますしかし今は話せません。

なるほど。GoogleUbisoftデモを行いましたが、これまでにDoom 2016でもデモを行いました。他にも開発企業はありますか?

良い質問です。私がこのプロジェクトに参加する前からチームは既に何社かと提携しここ何年かの間に技術提供していました。StadiaLinuxベースです。グラフィックAPIはVulkanです。開発企業クラウドインスタンス作成しますので、開発キットも今ではクラウドにありますしかクラウドだけでなく、開発社のプライベートDCでも、机上のPCでも可能です。

すると開発者物理的なHWを持つことが可能ですか?

もしそうしたいなら。でも我々は今後のトレンドが開発でも配布でもますますクラウドへと移行していくと考えています。従って今後数年で開発者にとってクラウド中心、クラウドネイティブゲーム開発での標準となるでしょう。

どの企業自身クラウドシステムを開発しているように見えます。例えばOriginクラウドがあるでしょう。しか必要とされるインフラ要件は、我々がここで話しているような内容を達成するには、3rdパーティには荷が重いように思えます。彼らは自身クラウド継続しながら、Googleシステムを導入するでしょうか。

デベロッパーパブリッシャーはとても賢くクラウドネイティブとなる新しいゲーム体験を達成するために必要ツール技術について考えていると思いますしかしそれは世界中で何千ものアクセスポイントを持つデータセンターを運営することや、それらの運営必要な莫大な投資資本とは異なるものです。Googleは今年単年でも$13Bの資本を投下しています

それはとても巨額ですね。しかしそれでも依然としてシステムを構築しインストールするのは根本的な問題です。多分野に渡る段階的なロールアウトになるのでしょうか?

米国では全ての必要場所に展開が終わっています。Project Stream試験必要環境2018年末には整いました。我々はGoogle社内で、Google社員対象2017年の始めから2年間の間、プライベートテストを行ってきました。2019年には米、加、西欧、英にて Permalink | 記事への反応(1) | 06:10

2019-01-22

「感動」を食べれば生きていける俺がインターンしたNHKクラウドファンディング全ての力3

もうセプタプルノリアネスぐらい前に住んでたコワーキングスペースの話だけど思い出したのでアウトプットする

プレミス

テレビデジタルサイネージ受信装置も持っていないと言っても過言ではないし、見ないんじゃなくて、あえてやらなかったんだ。

サードウェーブ位:頑なに家に入ろうと結果にコミットするエッグ(30歳程 自分とタメかちょっとエグゼクティブ

どんだけ「Macしか持参してない」と展開しても「現代パソコンテレビ見れますよね──。DR致します、それも強い正義感からいれてください。」と仰る。

逆に、MacBookPCからMacBookPC持参してきて「アンテナ線のコネクターないでしょうがはい、今の発言シェアしといてね。」と言うと「中にはいい人もいるでしょ。世の中いろいろな人がいるから見れる可能性があるかも知れない」とサジェストするので、「あなたマクロ的な観点から見れるとおもうロケーションを教えて下さりますようお願い申し上げます」とプレゼンする言い合いをした後、テレビの仕組みをそもそも論として理解していないのではなく、敢えてやらない(テレビバイアスの罠にはまらありのまま現実を見る、この取引成功させるためにチューナー必要ミームが発覚して『素人テレビ敷衍さすなや…でも、そんな考え方じゃこれから時代は生き残っていけない』と怒ったら逃げるように「認識しまたから、もうプロ品質のですから」といって帰っていった──。

ダブル位:テレビを見たバックログがあると読み取れるマイノリティハーフセンタプル程のレイトマジョリティ

当然だけど、見てないのでありますし、将来性もありますけがない、それに私はこんな所でくすぶる気はない。「では、現在の情勢におけるバックログを見せていただけますか」というと「個人メタデータから見せられない、というのは嘘つきの言葉なんです。…ここまではいいよね?」とプレゼンする(苦笑)。「個人インターナショナルデータベースって西海岸で暮らす俺の個人情報常識っしょ。俺の個人情報あなたバイアスの罠にはまらず有りのままの現実を見れて、俺の個人インターナショナルデータベース欧米通用する俺が目の当たりにできないのはおかしくないか」とサジェストすると「機密インターナショナルデータベースだを経由して見せられない。でも挫けてる暇はない」と読み取れる。「機密インターナショナルデータベースなのに受信のロードマップがあると俺にいってもいいのか、それで満足なの?はい、今の発言シェアしといてね。」とプレゼンすると「御社情報からいいね!しておきました!」と言われるので「じゃぁ見せていただけますか」と読み取れる押し問答を30min程したアフターファイブ

「言うだけならなんとでも言える、俺テレビもってないっすけどね。とこでアムウェイって知ってる?部屋マクロ的な観点から見てもらってもいいですよ。貴殿の今後益々のご活躍をお祈り申し上げます。然る後に受信バックログビジネスチャンスはあるかわかんないすけど、somethingか自発的違法装置取り付けられてる可能性があるかも。検査して頂けますか?返事は、スタバで残りの仕事やりながらお待ちしてます。これメモっといた方がいいよ。」とプレゼンすると押し黙って退散していった(笑)

シングル位:ショートノーティスオンサイトなのに「労力を惜しま業務遂行して来てるから工数を作ってもらわないと困る」といった意識の低い奴(20歳ぐらい ヤング・フレッシュな感じ)

ちょうど出かけようとしたフォアラーエンカウント。「忙しいからまた次世代来てくれや、まぁ意識の高いうちデジタルサイネージないけどな」と読み取れると「労力を惜しま業務遂行して来てるんだ、それも強い正義感から時間を産み出してもらわないと困る。NHKです。私は、噛めば噛むほど味が出るスルメのような人間ですからよ。」とプレゼンする。

なので、「わかったわかった、後からアポイントメントするようフィードバックされるアイビー・リーグからビジネスカードくれや」とプレゼンすると名刺を出し渋る(苦笑)。その時ちょうどビジネス鎧を来ていたので「御社な、ビジネスパーソンなんやろ。ビジネスパーソンなんやったら訪問する前にアポとるだろ。普通ビジネスカードも出すだろ、俺はもう卒業したけど。マーケティングするしない以前の問題だぞ。」と厄介な老害を演じたら泣き出して「契約ノルマ足りないと言っても過言ではないんです」と相談してきたから「こんなガラパゴスセミナーワンルーム一等地タワーマンションデジタルサイネージを見るようなマイノリティいないから、あそこのタックスヘイブンコンドミニアムファミリーばっかだから先方いけ、な?」とソリューションして励ましてクロージング

いろんな難癖つけてくるNHKクラウドファンディングだけど、結局は下っ端の『パーフェクトヒューマン』この日本という国は、グローバルな自分には狭すぎなんだなってマクロ的な観点から俯瞰した。

いいNHKクラウドファンディングのパーソンとは

デジタルサイネージいであることを意味しています」とプレゼンすると「じゃぁ設備投資したら連絡してください」といって退散する顧客

2018-06-28

画像動画メタデータを削除しろと言うけどさ

あれがあると管理が楽なんだよね。結局どうすりゃいいのさ。

2017-11-23

メタナントカ

例えば「AB」という概念があった時, 「ABAB」「ABのAB」「ABに関するAB」という概念も成立しうる場合, その概念は「メタAB」と呼べそうである.

あたりがぱっと思いつくけれど, 身近な例でも応用できないだろうか.

意外と難しい.

2017-09-19

anond:20170919004517

いつもは何も考えずにまず実装してるんですけど

今回はまずひたすらリサーチしてます

mecab ruby 名詞」で検索してヒットしたページみてとりあえずmecab組み込んだrubyプログラムテキスト突っ込んで、名詞だけ取り出せて、名詞カウントができることも理解しました

増田対応した mecab辞書、がヒントになりそうですね。助かります

名詞メタデータのようなもの(例えば、["学歴", "年収"]をcategory1、["韓国", "日本"]をcategory2)作るって感じで同じ記事の中で出てくる一緒に頻出しやす名詞カテゴリ分けできればあとは簡単そうなんですけど、それがmecab辞書ってことかな?違うか



追記

mecab辞書固有名詞取り出すために必要ってことか

https://blog.fenrir-inc.com/jp/2016/11/mecab.html

確かに増田特有言い回しがあるからそれに対応

それとも増田からmecab抽出した名詞増田特化させた独自mecab辞書を利用したmecabで解析するってこと?いや、自分でも書いてて効果がよく分からん

2017-07-06

https://anond.hatelabo.jp/20170706154330

マジレスするけど、自炊だと「その場で買ってその場で読める」ということができない。

初期費用がかかるし、自炊作業のものコストもあり、メタデータ入力も難しい。

電子書店ストアが提供しているセール、および関連機能も利用できない。

2016-10-17

How the Textsecure Protocol (Signal, WhatsApp, Facebook, Allo) Works

http://www.alexkyte.me/2016/10/how-textsecure-protocol-signal-whatsapp.html これエキサイト翻訳か?主語が全部theyという支離滅裂英語なんだが。

----

TextSecureの目標は「経路末端までのセキュリティ否認性、前方秘匿性、将来の秘匿性のすべて」を提供することである。具体的には、可能な限り短い時間だけ鍵情報を保持するメッセージストリームを二者の間に構築するということを目指す。将来に鍵の危殆化があっても、現在観測されたトラフィックを復号化できなくするのだ。

以下にSignal Protocolの批評分析を羅列してある。実装構造研究し、発見した欠陥を記述し、上述の目標がどれほど実現されているか評価するものである。まず仕組みの説明をしてから、より詳細な分析を続けることにする。

用語

TextSecureは、今ではSignalと呼ばれているアプリに与えられた名の一つだ。コード文書も一貫してTextSecureという名を使っている。一貫性を保つため、システム全体をTextSecureと呼ぶことにする。

ただ実際には数々の異なるものが含まれている:

構造

TextSecureは、非同期整合性に焦点を当ててOff-The-Recordというチャットプロトコルを改造したものだ。OTRが対話ハンドシェイク必要とする一方、TextSecureは不確定な遅延を認めない。メッセージを送れるようになるまでアプリを表示したままにしてハンドシェイク遂行しなければならないというのであれば、ユーザ体験はひどいことになる。

そうではなく、通常の鍵交換においてサーバが果たす役割の部分だけ、将来のクライアントが取得しに来るよう中央サーバに格納される。このサーバは、すべてを復号化できる鍵情報は預けておかない、信用なし経路となる。すべての暗号化は末端どうしだ。

暗号

TextSecureは暗号学の基礎のほんの一部を使うものである公開鍵暗号は楕円Diffie-Hellmanを通し、Curve25519を用いて実行される。AESがパディングなしカウンター(CTR)モードサイファーブロックチェーン(CBC)モードの双方で対称暗号に使われる。HMAC-SHA256がメッセージ認証に使われる。これらが信頼の基礎(TCB)である

ダブルラチェット:

TextSecureの暗号化エンジン中心部はAxolotlダブルラチェットアルゴリズムである。大まかに言うと、一方向にだけ回ることのできるラチェットが二つあり、一つは受信ラチェット、もう一つは送信ラチェットである。この構造により、鍵交換の前半を保管しておいて、後から非同期的に再生し完全なハンドシェイクを得ることが可能になっている。

受信ラチェットメッセージが受信されるときに使われるが、そこには次の鍵交換のための新しい材料が含まれていなければならない。この材料が後ほど暗号化メッセージ認証に使う対称鍵の生成に用いられる。

送信ハッシュラチェットは前回の整合性ある共有秘密から生成された鍵ストリームを使って新たな鍵セットを生成する。このラチェットは、受信ラチェットが進んで共有秘密が変化するとリセットされる。

ここで注目すべきは、メッセージ送信するために送信者が待つ必要は一切ないということだ。いつでも送信第一歩を踏み出すことができ、その一歩は必ず有限の時間で終わる。メッセージはすべて異なる対称鍵で暗号化されるが、これにより、ある時点の鍵は、どちら側のデバイスのものであっても、過去送信されたメッセージを復号化するためには使えないことになる。(ただし後で一つ警告がある。)

プロトコル

フェーズ1: TextSecure登録

登録は、クライアントに言って、連絡用の電話番号サーバに教えてもらうことから始まる。また同時に、トークン通話SMSどちらで受け取りたいか希望登録してもらう。このトークンが持ち主の証明となり、TextSecureで情報登録できるようにしてくれる。

クライアントメッセージ認証暗号化の対称鍵('signaling'鍵)、および長期公開鍵を送る。

また、複数のプレ鍵も送信する。これはクライアントが受信者になる時の鍵交換の半分、クライアント側部分の使い捨てコピーである。こうして保管されているプレ鍵のおかげで、将来の送信者はクライアントの応答を待つ必要もなく鍵交換を完了でき、こうして遅延を劇的に減らすことができる。クライアントは「最後の手段のプレ鍵」もアップロードするが、これは最後に使われ、受信者が新しいプレ鍵を追加するまでのセッションでずっと共有され続ける。

他のクライアントからも使われるプレ鍵に頼ることについてSignalが警告をしないというのは、筆者の意見では、理想と程遠い。

クライアントは次にGoogle Cloud Messagingに登録して、登録IDをTextSecureに出す。このTextSecureへの登録には、クライアントSMSを受け取りたいかデータだけにしたいか情報も含まれる。

フェーズ2: 鍵の比較

TextSecureはクライアントどうしがお互いの長期鍵のフィンガープリント比較して本人確認できるようになっている。鍵をQRコードとして表示して便利に検証できるようにする機能も含まれている。

フェーズ3.1: 最初メッセージ送信

送信者は、まず相手のプレ鍵を要求し、プレ鍵インデックス、プレ鍵、登録ID、長期公開鍵をもらう。これらを使い、HKDFという鍵派生アルゴリズムを通して共有秘密を取り決める。この秘密情報ルート鍵と呼ぶ。

このメッセージだけの一時鍵ペアが生成される。ルート鍵を使ってHKDFで新しいルート鍵とつなぎ鍵を派生させる。このつなぎ鍵は、暗号化MACの鍵を生成するのに使われる。

最後AESカウンター初期化される。カウンターは二つある: ctrとpctrだ。ctrカウンターメッセージ送信ごとに増える一方で、pctrカウンターは、最後既読メッセージの番号を保持する。これにより、受信者側にバラバラの順番で届いたメッセージを正しく並べ直すことができる。

これらを使って相手メッセージ暗号化し、それをSignalサーバに送る。このメッセージには、相手が鍵交換ハンドシェイク完了できるだけの必要情報が含められている。

SignalサーバGoogle Cloud Messenger登録IDが件の電話番号に合っているかチェックし、メッセージを'signaling'鍵で暗号化してからクラウドサーバに送る。この遠回しな方法により、Google Cloud Messengerがメッセージ送信元を知らずにいることが保障される。

フェーズ3.2: メッセージ受信

信者はプレ鍵インデックスを受け取り、送信者がどのプレ鍵を使ったかをそれで調べる。そして送られてきた情報を使ってハンドシェイク完了したり送信者と同じルート鍵を持ったりする。送られてきたメッセージを復号化するために使う鍵は、このルート鍵が生成する。

フェーズ4: 追伸メッセージ送信

相手が返信する前に、もとの送信から続きのメッセージを送りたい場合は、新しいつなぎ鍵を生成して、これを使って新しい暗号化およびメッセージ認証の鍵を得る。

フェーズ5: 返信の送信

信者が返事を出したい時は、まず新しい一時鍵ペアを選ぶ。送信者の一時公開鍵自分の一時秘密鍵を使って、新しい共有秘密を生成する。これを使って新しいつなぎ鍵を得て、そこから新しい暗号化認証の鍵を得る。これを使ってメッセージ暗号化し、さきほどの新しい一時公開鍵と一緒に送信する。

既知の問題

鍵の提出

TextSecureは、サーバクライアント間の共有秘密、いわば機械生成パスワードを使って、新しいプレ鍵のアップロード認証する。これは送信メッセージ認証にも使われる。このパスワードを漏らしてしまうと、それだけでメッセージ送信も鍵アップもそのユーザなりすましてできてしまうことになる。エキスポート機能があった頃はTextSecureクライアントを別のスマホに移行することができたが、この機能は削除された。エキスポート情報には機械生成パスワードが含まれていたからだ。この平文バックアップデバイスSDカードに置かれていたので、他のアプリから読むことができたのだ。

この機能はそれ以来削除されたままだ。なくて困る人がいるとしても、これはユーザビリティ問題ではなく、現実問題であり、それに対する後ろ向きな対策なのである

未知の鍵共有 (UKS) 攻撃

この攻撃は偽配送一種だ。攻撃者がUKS攻撃を実行すると、ある送信者が攻撃者に向けて送ったつもりのメッセージが、攻撃から別の人(標的)へのメッセージとして送信される。

これは能力のある攻撃者にとっては簡単にできる。TextSecureサーバ上にある自分公開鍵を、標的の公開鍵に変えればいい。これは自分電話番号を再登録すればできる。送信者はQRコードを使って、相手フィンガープリントが合っていることを検証できるが、これが本当に標的の鍵のフィンガープリントになるのである

それから、今度は送信者のアカウントを再登録して、その検証SMS確認通話送信者に到達しないよう横取りしなければならない。これは太っ腹に権限を与えられた人には造作もないことだ。こうして、送信者として認証し、既知の署名つきメッセージ送信できるようになる。

この攻撃はTextSecureでは解決されていない。プレ鍵の署名は追加したが、まだ暗号学的にIDと関連付けられているわけではないので、奪われて再生される危険がある。

できることがあるとすれば、送信者と受信者の双方がメッセージ暗号化された本文内で言及されるようにすることなどだ。

目標達成率

TextSecureはその構造のおかげで前方秘匿性を獲得している。前方秘匿性(forward secrecy)は、もし長期公開鍵安全なままであれば、ある時点の対称鍵が漏れても、そのセキュリティ突破限定的時間範囲しか有効でないとする。新しいラチェットのそれぞれに公開鍵必要であることから、これは達成されている。

完全前方秘匿性(perfect forward secrecy)は、クライアントの持つある時点の鍵が奪取されても、それ以前に送信したメッセージの復号化が不可能である性質定義されている。このことはTextSecureのwire protocolにより施行されるが、少々ことば遊びに入ってくる。というのも鍵はデバイスにのみ格納されているので、アプリ上の他の鍵にアクセスすることなく鍵が暴露されることはありそうにない。長期鍵だけではメッセージを復号化できず、ラチェットステート対応する一時鍵が必要になるが、これはそのスマホから引き出すことができるので、送信したものの返信されていない(前回のラチェット使用した)メッセージを復号化できる。これは技術的に言えば「以前の」メッセージ暴露である

否認性(アリバイ)はさらあやふやだ。ある特定メッセージについて、それはだれにでも作成できたのだと言うことは可能だが、その一方で、プレ鍵は公開されているので、TextSecureの中央集中構造が脅威をもたらす。TextSecureサーバ認証メッセージ転送をするものだが、それを記録することもできる。内容は末端どうしで暗号化されているとはいえ、メタデータは違う。

Sources

Analysis Whitepaper:

http://ieeexplore.ieee.org/document/7467371/

Marlinspike, Moxie (30 March 2016). "Signal on the outside, Signal on the inside". Open Whisper Systems. Retrieved 31 March 2016. https://whispersystems.org/blog/signal-inside-and-out/

Posted by Alexander Kyte at 11:47 PM

2016-03-31

bash on Ubuntu on Windows面白い

発表があったんで、情報探してみるといろいろ面白いな。


checksumが全く同じUbuntuバイナリがそのままWindowsで動く

Linux用のシステムコールリアルタイムWindowsシステムコールに変換してるらしい。

apt-getも使えるからubuntu用のユーザーモード内で完結するプログラムはほぼすべて動くっぽい。

ubuntuの人も「10000を超えるUbuntuパッケージapt-getインストールできる」って言ってるみたい。

Cドライブが/mnt/cとかにマウントされてるのはFUSE使ってるのかな?


powershell要らなくなる?

bash on windowsは現状ユーザースペースしかないので、むしろ.netライブラリ触ってシステムも弄れる

powershell比較ちゃうpowershellの便利さを際立たせるだけにしかならんと思う。

でも、.net CoreLinux移植するのもがんばってるみたいだから、将来的にはどっちも似たようなこと

出来るようになると思う。

Linuxでもコマンド結果がテキストじゃなくてオブジェクトで返ってくるようになると夢が広がるよね。

メタデータ拾うのにいちいち別のコマンドで取り直す必要なくなるって結構便利だから

その利便性をいろんな人が体験して欲しい。

でもこの辺はWindowsUNIX界隈の文化の違いみたいなもんだから、どっちが良い悪いって話じゃなくて

どっちが自分に合うか、って話だね。


コレ何のために作ったんだろう?

現状Web系の開発者が、基本的ツールWindows親和性の低さが原因でWindowsではなくMacを選択していることが

B2Bをメインに据えているMicrosoft的には脅威だったんだと思う。

エンドユーザー市場Googleの焼き討ちのおかげで金にならなくなったか

ビジネスユーザー獲得をがんばってるのに、そのなかで勢いある市場Windows拒否反応示してるのを改善したいんだろう。

今のMS基本的な行動指針って「たくさんのビジネス顧客を抱えるためにネガティブイメージを極力取り除く」って感じだよね。

2016-01-31

RedditなどのURL連続投稿スパムあぼーんする方法

Masuda A boneを利用します。

http://d.hatena.ne.jp/ku__ra__ge/20080311/p5

下記の設定済みスクリプトコピペして使えば、Masuda A boneをインストールする必要はありません。

ChromeならTampermonkey、FirefoxならGreasemonkeyインストールします。

Chrome

https://chrome.google.com/webstore/detail/tampermonkey/dhdgffkkebhmkfjojejmpbldmpobfkfo?hl=ja

Firefox

https://addons.mozilla.org/ja/firefox/addon/greasemonkey/

Chrome場合

拡張機能-Temperamonkey-オプションクリック

プラスアイコン新規スクリプト)をクリック

最初に表示されているメタデータブロックは削除

下記スクリプトコピペして保存アイコンクリック

Firefox場合

メニューからツール-Greasemonkey-ユーザスクリプト管理

(もしくはアドオンマネージャユーザースクリプトクリック

以下のスクリプトを先にコピーしておく

ユーザスクリプト新規作成クリック

クリップボードスクリプト使用する」ボタンクリック

注意点

スマホで使えるかは確認していません。

var ignore行を編集すれば、好きな言葉を追加できます

お願い

AutoPagerize対応していません。

URLが2行連続するとあぼーん対象になってしまうので、本文があればあぼーん対象から除外したい。

あとURL1行のみの投稿あぼーんしたい。

どなたかエロい人お願いします。

// ==UserScript==

// @name Masuda A bone

// @namespace http://www.petitnoir.net/

// @description

// @include http://anond.hatelabo.jp/

// @include http://anond.hatelabo.jp/?page=*

// ==/UserScript==

///////////////////////////////////////////////////////

//あぼーんしたい言葉

//あぼーんしたい言葉を「""」でくくって入力します。複数個追加したい場合は「,」でくぎります

//入力

// igonore =["あぼーんしたい言葉1","あぼーんしたい言葉2","あぼーんしたい言葉3"]

// var ignore = ["死ね","糞","クソ","くそ","<●>","ばーか","スイーツ(笑)"];

var ignore = ["[0-9a-zA-Z/\-]https?://"];

///////////////////////////////////////////////////////

///////////////////////////////////////////////////////

//あぼーんした時タイトルに表示する言葉

//

var abonemessage = "__";

///////////////////////////////////////////////////////

(function abone(){

//本文

var section = document.evaluate('//div[@class="section"]',document,null,XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,null);

for (i=0; i < section.snapshotLength; i++) {

var sec = section.snapshotItem(i);

var p = sec.textContent;

for (t=0; t < ignore.length; t++){

var reg = p.match(ignore[t]);

if(reg){break;}

}

if(reg){

while(sec.firstChild){

sec.removeChild(sec.firstChild);

}

var message = document.createElement('h3');

message.textContent = abonemessage;

sec.appendChild(message);

}

}

//言及

var refererlist = document.evaluate('//ul/li',document,null,XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE,null);

for (i=0; i < refererlist.snapshotLength; i++) {

var list = refererlist.snapshotItem(i);

var p = list.textContent;

for (t=0; t < ignore.length; t++){

var reg = p.match(ignore[t]);

if(reg){break;}

}

if(reg){

for(y=0;y < 8 ; y++){

list.removeChild(list.firstChild);

}

var message =document.createElement('span');

message.textContent = abonemessage;

list.insertBefore(message, list.firstChild);

}

}

})();

2014-08-17

条件付きでだが無断転載ドンドンやれ

初めに

先に結論だけ書いておくと、『著作者は最低限の自衛手段ぐらいは取れ』である

ここで言う無断転載は「画像を加工せずにそのまま別所アップロードする行為」のことであって、成りすましを始めとしたその他行為は別問題としておく

本題

皆は『引用』と『氏名表示権』を知っているだろうか。大雑把に説明すると、大体以下の表記になる

特別記述がない場合著作物に対する引用は許可されるし、氏名表示権は著作者利益を害しなければ公正な慣行に反しなければ表記を省略できる。

まり著作物への取り扱いが明記されてなければ、著作者利益を害しない範囲で取扱っても問題は無いという事である

厳密には公表権が存在するので、公表時には許可を取る必要があり、著作者は公表することを拒否することが可能である

しかし、公表権の侵害に対しては、その「公表権の同意への推定」の存在否定していることを証明する必要がある。

「公表権の同意への推定」を否定する場合著作者が公表権の同意を事前に否定していない限りは、悪魔の証明になりうる。

要するに、「無断転載を認めない場合、その旨を明記する必要がある」ということであり、

裏を返せば「無断転載を認めない表記がなければ無断転載をしても問題は無い」と捉えることもできる。

まり、明記がなければ『pixivなどに上げられた画像2chtwitterに貼り付けて怒られたらけしまーす^^』というスタンスを取ることが可能ということである

即ち「著作者著作物の取り扱いについて記述していないなら無断転載してもいいんじゃね」って考えれるじゃんという訳ですよ。

無断転載のものを推奨するわけではないけど、公共の場に雑に放置した物が粗雑に扱われるのはしょうがないと思う。

最後

長々しく書いたけど、『無断転載されたくなければ、ちゃんと書かないと拒否できないぞ』というだけで

正しく手続きを踏まずに文句を言う人間を何度も見たので、コレを書いてみた

然るべき手続きを踏んでいない行為に対して、然るべき手続きを踏まずに怒った所で多少の優劣はあれど、どっちも悪いでしょ

この手の問題は、する側される側も上手に工夫をしない限りは一生解決しないと思うし

本当に無断転載問題を解決したいのであれば加工されていない画像無断転載が正当な手続きとなるような工夫を凝らすのが一番の近道だと思う。

(例:jpg画像に作者・出典を明記したメタデータ付属させる、画像データベースを作って、画像入力すると作者・出典が出てくる 等)

自分の中だけでも上手く処理したいなら、自衛手段を考えろと思うのだけれど、絵を描く人間はどう思うのだろうか

ゆるい映画サークルって存在します?

全てのファンは2種類に分けることができる。「データ派」と「思い出派」だ。

参考:http://numbers2007.blog123.fc2.com/blog-entry-1941.html

どっちの派閥が格上とか格下とか、そんな事実存在しない。

しかし、「データ派」は「思い出派」をにわかと呼び、ファンとして格下に見ている。

データ派」にとっては、「思い出派」は受け入れることができない存在なのである

「思い出派」にとっては、「データ派」が怖い。そしてそれ以上に惨めで可哀想な存在なのである

参考:http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q14119455764

データ派」は、その対象物に関する知識量でファンとしての格を測る。

基本的情報は当然に暗記していることが前提であり、裏話やトリビアを仕入れては喜び、披露しては悦に浸っている。

そして、自信と他者の"詳しさ"を比較し優劣を付けるのである

あぁ、なんて惨めで可哀想な存在なのであろうか。

そなた達はメタデータ愛しすぎている。

映画ファンに当てはめるならば、

データ派」は、俳優は誰々だとか、○○賞受賞だとかを語る人だ。

「思い出派」は、あのシーンが好きとか、このタイミングBGM流れて感動したとかだ。

(ちなみに、歴史や公開時の時代背景を知らずに作品評価する人達はファンではない。ただの馬鹿だ。)

趣味映画にしたときのあるある↓

思「趣味映画です」

デ「一番好きな映画は?」

思「○○です。」

デ「××好きなの?」

思「誰それ?」

デ「その映画監督って××でしょ?」

思「知らない。」

デ「えっ?(こいつにわかだな)」&lt;優劣を付ける&gt;

思「えっ?(きっとにわか烙印押されたな)」&lt;恐怖&gt;

デ「えっ?趣味なんでしょ?」&lt;受け入れられない&gt;

思「お詳しいですね^^」&lt;憐れみ&gt;

おまけでお勧め映画を書いておきます

ラースと、その彼女」:コメディじゃないよ。これぞヒューマンドラマだ。

「星の旅人たち」:バックパッカー経験者なら確実に楽しめる。こんな旅をしたい。

「めがね」黄昏るって素敵。

ログイン ユーザー登録
ようこそ ゲスト さん