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

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

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年には米、加、西欧、英にて このエントリーをはてなブックマークに追加ツイートシェア

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;

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

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

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

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

2014-01-27

増田流行語を調べてみたら、やっぱりお前らは○○コンだった


きっか

増田で「増田データクラスタリングしたら面白いんじゃね?」って話になった

■暇だからリクエストされたプログラム作るけど、需要ある?

クラスタリングメタデータとか必要だったので、まずは簡単な統計をしてみた。

流れ

とりま2014/1/1〜1/26のデータ収集テキストだけで6MBという鬼畜っぷり。(データ1) それをYahoo形態素分析API単語に分解、集計(データ2) 見てもらえば分かるが、ノイズがひどい。「トラックバック」とか「こと」「それ」みたいな、意味も無い言葉が混じっている。こっからは手作業でノイズ単語を除去していく。その結果がこれ。1位から10位までを勝手に解説

結果

1位 子供 == 1030

なぞ。子連れの奴が多いのか、少年愛or少女者が多いのか。はたまた煽り文なのか。

2位 今 == 951

これは某塾講師の影響だろうな。いつ言うんだよ?

3位 日本 == 932

右翼の方々かな?島の問題で色々あったもんな。

4位 匿名 == 909

まぁそうだな。

5位 女 == 901

これは自覚症状あるだろ?

6位 問題 == 846

7位 男 == 789

8位 相手 == 754

9位 意味 == 739

10仕事 == 717

偉大なるニート先輩の言葉だな。

11位〜20位
  1. 時 == 700
  2. 結婚 == 663
  3. 奴 == 655
  4. 普通 == 639
  5. 本当 == 605
  6. 女性 == 596
  7. 時間 == 593
  8. 必要 == 567

2013-05-09

たとえ少ない分量でも漫画のページを転載すべきでは無い

マンガ画像ブログへの無断転載・掲載はみんなやっているからやってよいのか?という問題の話。

http://d.hatena.ne.jp/yarukimedesu/20130508/1367979625

要約)nanapi社長であるkensuuが漫画コマ批評目的でも無いのに転載しているけど、それってどうよ?

案の定コメント欄にkensuu御大が登場して和解しちゃってるいつものパターンだけど、俺もこの説得される前のブログ主(yarukimedesu)さんと同じ考えなんだよね。批評目的じゃないのに転載するべきじゃないと思ってる。

理由

漫画一冊のページって250ページぐらいだっけ?そのうちの一つのページを一つのブログ転載しても、「分量的にごく僅かだから批評目的じゃなくても問題無い」ってkensuuみたいな人は主張するわけだ。

でもさ、例えば同じ人間が250のブログ作ってそこに1ページづつ転載したらどうなるんだろう。

一つ一つのブログに掲載されているページはたったの1ページだから問題無い?

でもトータルで見れば全てのページがネット上にアップされてることになるから、「この漫画12ページ目のurlhttp://~~~で、13ページ目はhttp://~~、14ページ目は....」というメタデータさえあれば一冊丸々自動で取得できちゃうよね。

分量が少ないからお咎め無いだろうとか、そういう問題じゃないんだわ。ましてや「違法でもネットにアップしたら売り上げが伸びて作者も喜ぶからOK」ってどの口がそういう事を言えるんだよ。ちょっと酷い。絶句

批評目的で無ければ転載しちゃいけないっていう決まりがある以上はそれを守るべきじゃない?

nanapi投稿されているレシピがどのくらいあるのか知らないけど例えば10レシピだとして、一つのブログにつき10レシピだけ転載して、そういうブログを1万作ればnanapiコンテンツは全て丸写しできるよね。それっていいの?そういうことされて、kensuuは平然としていられる?一つのブログには10個のレシピしか転載されてないかnanapi側は抗議しようが無いってことになるよ。

 

仮にも社長としてサービスを運営している人の態度じゃないよなあ。まあブログ主amazon画像なら何に使ってもいいと思ってる時点で同じアナのムジナだけど。

2013-04-28

iTunesで曲を管理するようになってから6年くらい経つ。

最初のうちはアルバム名やトラック番号なんかのメタデータもちゃんと入れていたけれど

それが1000曲を超えた辺りからどうでもよくなり、

3000曲を超えたいまではもうタイトルですら適当になった。

常にランダム再生で聴いている。

でもそれで充分だと思えるようになった。

誰が歌っているか演奏しているかに左右されない、本当の意味音楽を聴いているような気がする。

2012-08-08

Web上の図書館存在感と図書館情報学用語の存在

例えばCiNii Articlesみたいに図書館系のDBGoogleが乗り入れるようになった結果、そのデータつーかメタデータレコード自体はWebで容易に目にできるようになったし、その先にあるフルテキストとか資料のアクセシビリティもある程度向上した。

んだけど、これって一方で、図書館情報学系の用語で探す時のノイズを爆発的に増加させたんですよね。

例えば"機関リポジトリ"+hoge検索すると、機関リポジトリとは関係ないCiNiiに収録されてる論文レコードがことごとく上位にヒットするようになってしまった。なんでかってとレコードのページにJAIRO(機関リポジトリポータル)へのリンクが必ず含まれてるから

普通図書館OPACレコードでも、Googleが拾ってくる館では同様の状況があって、「タイトル」とかの書誌的事項というか項目名が明示されている=OPACが返すHTML文字列として含まれてるせいで、"[書誌的事項]"+hogeとかで検索してもそうなる。

これって、site指定やinurl使っての除外検索すればなんとかならなくはないんだけど、それだと図書館DBリソース別に検索をしなきゃならないっつうね。

こういう図書館のもってるリソース存在感が増したせいで(語の)図書館情報学用語(として)の存在感が減ったのって、Web屋と図書館屋のどっちかが責をおうべきものなんですかね。負うならどっちがより重いんですかね。

2012-03-28

http://anond.hatelabo.jp/20120328113149

膨大なメタデータを準備して、添付して、っていうだけでも、かなりのコストがかかるよね。

まあ大半をプログラムで処理するにしても、そのプログラムの開発にもコストがかかるわけで、

まだ電子書籍がロクに売れていない状況で、そうした投資をするのは難しいんじゃね。

メタデータにしても、

独自規格でやると汎用性が無くなるから世界的に規格を統一して、

とかやってると時間がかかりそう。

徐々にやっていくしかないんじゃないの。

電子書籍について -- 一万冊を支えるために

電子書籍議論が華々しいけど、どうしても僕は納得がいかない。なので、一度某所に名前付きで書いたものを、少しでも騒ぎになってくれる事を願って、編集してここに掲載する。僕が誰かわかった人は、黙ってくれるとありがたい。

まず、今の電子書籍に対する不満は、そもそも今の電子書籍環境じゃ、生涯付き合えないということ。iBooks程度のインターフェイスだって100冊もあれば面倒な事が多い。検索機能も無い、それ以外のツールはもっと酷い。生涯付き合うなら一万冊の管理をこなせるようになってほしい。一万冊というのは、読書家の一生を考えれば、決して無謀な数字じゃない。数代続く学者一家ならそれくらい書庫にあったりしてもおかしくないし、図書館で借りたりすれば、10から60歳までで一万というのはあり得る数字マンガを買い込めば、普通の人でも数千冊は読破可能。

一万冊の読書を支えるためには、以下の機能が必要と考える。

これくらいでも、一万冊と付き合うのは難しいだろうけど、ひとつひとつ機能は決して難しいとは思わない。

また、書籍自身も単なる複製で終わってしまっているので、これも不満。例えばこんな機能があってもいいはずだ。

要するに、紙だと必然的に対処せざるを得ないものを排除して、今まで頭を使ってこなしていた事を電子側でこなしてほしいのだ。

特に歴史物だと、今自分が読んでいる箇所がどこの場所で、いつの年代かがわからなくなる。紙の場合は、巻頭または巻末に資料があるけど、電子であれば、読んでいる場所からその場で呼び出せるようになってほしい。もし小説ネタバレをするようなら、進行状況に合わせて内容を変化させれば良い(既出地名だけを表示する、など)。

こうした機能ゲームならおなじみで、主人公の位置をマップで示したり、あらすじが進行中に挟まって後から確認すると言った事が出来るけど、今の電子書籍は全くそういうことを学んでいない。これじゃ、値段を下げるくらいしか売り方が無い。こうした機能がつけば、同額か、値段を上げたって問題ないと思うくらい。元々文庫マンガは安いので、これ以上値段を下げる議論なんてしていたら、業界自体が死んでしまう。付加価値で勝負してくれた方がよっぽど良い。

たまに「やっぱり紙の方が良い」という議論があるけど、決してそんな事無い。引っ越しダンボールの中に蔵書がまぎれたり、本棚を二重に組んで取り出せないとか、紙の不便さは山のようにある。問題は、それを電子書籍が解決していない事だ。イノベーションでも、顧客需要でもなく、惰性で電子書籍に取り組んでいるからいけないのだけど。読書家の皆さんは、もっと声を大にして「紙は不便」と言おう。

2011-03-08

ネット既存メディアについて最近考えてる事

うまくまとまらないので、箇条書きにする。思考メモたいなもんなので、結局何が言いたいのになってるかもしれない。

情報への価値付け

価値付け→目新しさ、ためになる、需要のある事実歴史的に重要事実リスペクトしてる発信者から情報etc、色々な価値があるけど、まとめて「情報の重さ」ということにする。

何が情報を重くするのか

時事問題災害等、事実自体が重いケースは除き、情報の一次発信者によってある程度重さの初期値が左右される。

既存メディアでは、大手マスコミなど、情報を加工し提供している所で重さが操作される。

ネットでは、情報の受け取り手がバズによって重さを加算していく。

情報の重さが簡単に操作されないための仕組み

http://anond.hatelabo.jp/20110307103006 自分の書いたものから一部

TL に出てきたものを RT するとき自分がフォローしている人が回してきた情報→フォローしてるってことは信用や友好や情報価値などがあるということ→情報価値や精査の連鎖がある

 

工作アカウントが RT する→こういうアカウントスパムっぽかったりするのであまりフォローされない(単純につまらん)→フォローするのはフォロワー数が欲しいだけの人や自動フォロー→そういう人のツイートはまたつまらないのであまり有意義なツイートをする人にフォローされて無い→情報価値が上がらない連鎖

 

てな感じで、Twitter場合ツイートが RT されて自分の TL に来るまでに「信用の連鎖」や「情報の精査」がある。だれが RT したか調べなくても TL という経路を伝わってくる以上、それがあるわけ。

 

ところが、はてぶのような仕組みにはそれがない。数字しか意味が無いのがまずい。クソみたい工作員の3ブクマでも、3ブクマなわけよ。これが Twitter なら全然フォロワーいない奴の 3RT には意味ないじゃん。そうはならないのがはてぶ。

人間フィルタだな。

人間フィルタのいきつくところ

情報を重くする。情報メタデータをつける。情報に信用度をつける。または下げる。色々が処理がされて、再発信される。受け取り手は発信者でもある。発信者と受信者の区別がなくなっていく。ゆるやかな情報の共有。

ゆるやかな情報の共有が滑らかに行われるためには

同時性が必要。

情報を重くするには人の判断が必要→判断をするにはリテラシーだけでなく感情もかかわる。同じ瞬間に共有していることで一気に意思や感情がかかわりやすくなる。

リアルタイム中東からの声を聞いた人達が、国内の発信者と同じ距離感でそれを捉えて、革命自体を身近に感じたように。

さらに同時性がどれだけ高いかということ自体が情報に重みを加算する。

シーケンシャルなメディアとそうでないメディア

シーケンシャルなメディアって他に言い方わからないので俺俺用語。

シーケンシャルでないメディア検索エンジン過去ログWikipedia書籍等。いつでもどれでもどこからでも見れるメディア。これらは人の好奇心や知識欲がある限り、ずっと生き残るだろう。

例えば、アニメは初放送の時はシーケンシャルなメディアで、放送後に発売された DVD はシーケンシャルじゃないメディア

問題はシーケンシャルなメディア

最大のシーケンシャルなメディア現実世界現実世界は万人と共有している。

現実世界時間軸とリンクした仮想世界も同等の同時性がある、MMORPG など。

ニコニコ動画は、動画の中にコメント時間軸を入れる事で、仮想的に同時性を演出している。ニコニコ動画のどの動画をいつ見ているかというのは、現実世界時間軸での同時性だし、これにも大きな価値があるが。(世界の新着動画生放送など)

サッカーの放送を見ている、今人気アニメの第何話を見ているという同時性。それと相互に依存する情報の重み付けと共有。

ネットと今のテレビの決定的な違い

今の日本テレビの一番のネックはこの情報の重み付けと共有が外部依存していること。

ネットでは境目がない。内包されている。

テレビでは、分離されている。テレビで発せられた情報ネットで重みを加算されることも多い。

(俺俺メモ。そー考えると、昔ながらのライブイベントというのは、テレビよりむしろネットにずっと性質が近い気がする。いや、もっと昔ながらの口コミや言い伝えにはネットと同じように情報を重くする仕組みが受け取り手自身にあった。テレビというメディアが逆に異質なんじゃないか?)

その差がなにを生むのか

情報の重み付けと共有は、同時性によって加速されるから同時性のないシーケンシャルなメディアは段々価値がなくなっていくか、ウケが悪くなっていくだろう。

海外メディアでは新聞局や通信社テレビ局ネットの利点を生かした発信をしている。ライブブログなど、ほぼリアルタイム更新される情報群。テレビ側では、ネットのゆるやかな共有、重み付け、同時性を放送の中に取り込む動き。

http://wiredvision.jp/news/201103/2011030719.html wiredvision アルジャジーラの「ソーシャルネットTV

この差を解決できないメディアはただのインフラになっていくと考えている。(百年スケールだろうが)

まともな考えなら、それもメディアに取り込もうとするからアルジャジーラのような取り組みはとめられないだろう。(日本国内はしらん)

テレビ価値

この差を解決できないメディアはただのインフラになっていくと上で書いたけど、そのインフラこそがテレビの強さ。同時性、共有、これが巨大になっていくと今のネットワークでは帯域幅が足りない。テレビにはそういう問題がない。

そう考えると、ネットインフラとしてテレビを利用するようなものが今後増えてくる。アルジャジーラの取り組みはまさしくそれ。

俺らが情報価値をつける

ネット情報は信用できない、だからネットはと言われるが、情報に重みをつけるのは俺ら自身だ。そのために出来る事は、リテラシーを育てること。

http://anond.hatelabo.jp/20110307054102 俺の書いたもので申し訳ないけど、伝えたいことは大体書いてある。

2010-05-27

同人誌をePub化する作業メモ(メタデータ編)

今後iPadWWWを見る人が増えるかも知れないので、サークルWWWサイトで公開しているパロディ同人誌をsigilでePub化しようかと思ったんだが、メタデータの取り扱いがよくわからないので色々考えてみたメモ

まず前提として、同人誌のePub化を行うにあたり、各種メタデータを書く必要がある。その際、一部同人界隈で使われている、暗喩、符丁、伏字の類は一切使わないこと。それに抵抗があるコンテンツはePub化しないほうがいい。(そもそもそんな内容のものをWWWで公開すんなって話でもある。mixiでやっとけ。pixivは他人に見られることが前提のサービスだからやめとけ。)

メタデータを読むにあたり参考にしたのはこれ http://ryoji.sakura.ne.jp/references/rfc2413-j.txt

何がどこまで決まっているのかさっぱり分からないので、的外れな使い方をしているかも知れない。特に著者名とサークル名の扱いの違い(AuthorとPublisherに分けるべきか、どちらもAuthorにすべきか)と、Rightsが怪しい。

メタデータ登録(必須事項)

Title
同人誌タイトル
Author
著者を書く(サークル名ではない)。合同誌の場合責任を持てる著者を書く。この欄は後で増やせる。
Language
Japanese だと思う。大抵は。

メタデータ登録(Add Basic

Subject
いわゆるキーワードを書く。同人誌場合は Dojinshi, というキーワードを必ず登録するようにしたらいいと思う。Fanjine よりも通りがいいかもしれない。複数登録することが出来るので、元とした作品名とかを書くといいかも。レーティング情報もここに書くべき? pixivにおけるタグのような使われ方をしそうな気がする。
Publisher
サークル名を書くとよいだろう。合同誌の場合は主たる発行サークル名(コミケで見本誌登録しているサークル)のみを書く。
Description
電子書籍の説明(100文字程度)。オリジナルなら問題なく書けるだろう。パロディ同人誌場合、何の二次創作物であるのかをここで示しておくことで、変な誤解を回避出来る。例えば東方場合、お決まりの『この同人誌は、東方Project二次創作物です。』の文言をここに書く。東方以外の場合適当アレンジすること。
Date of publication
書籍の発行日。同人誌なら本誌を発行した日を書く。
Date of creation
ePubを作った日を書く。同人誌をePub化した日になるだろう。
Rights
著作権や各種権利に関する事項を書く。正確には以下のような定義である。

2.2.15: <rights> </rights>

権利に関する表明や、ある権利への参照を表す。本仕様では著作権表示やさらなる諸権利についての説明は直接的に示されるべきである(should)。本仕様ではコンテンツ供給者が、購読権や販売用コンテンツの複製などのライセンス用語を、安全な販売業者に向けて指定する方法を定義していない。

http://lost_and_found.lv9.org/opf/opf_2.0_final_spec_ja.html

完全なオリジナルであれば、堂々と

>(c) 作家(自分の)名 出版

と書けばよい。もっとも、日本場合オリジナルだろうがパロディだろうが、電子書籍としてこれが世に出た時点でメタデータの Title/Author/Date of publication を元に著作権が発生する(無方式主義)ので、わざわざ明記する必要はない気もする。

パロディ同人誌場合、『元の作品タイトル』を書き、それに対応する著作権情報を書くのがやはり礼儀であろう。複数年続いている作品の場合、年は省いて書いたほうがいいのかもしれない。

  1. 漫画小説場合は、オリジナル作品のタイトルと、奥付で(c)表記で示されている著者名などを書く。稀に著作権表示に出版社が入っている場合があるので注意が必要。(c)表記がが無ければ著者と出版社を書いておく。
  2. アニメ場合公式サイトなどで大抵著作権に関する記述が見受けられるので、それを書く。
  3. ゲーム場合公式サイト情報が役に立つ。ゲーム公式サイト、もしくはゲームマニュアルから著作権に関する表示を見つけることが出来るだろう。明記されていない場合ソフトハウス名などを書いておく。
  4. スピンオフ作品や別メディアで展開している作品が対象の場合、準拠した作品の権利関係を書く。
  5. 東方場合、お決まりの『東方Projectは「上海アリス幻樂団」さまの作品です。』をここに書く。
  6. (c)表記がはっきり無い場合でも、東方場合と同様、オリジナル作品のタイトルと、それが本来誰のものかを書いておけばよい。対象が作品ではない(芸能系など)場合権利関係を書くのが大変難しいので、Description:に一体何の本なのかを書いておくべきだ。
  7. 複数の作品をクロスオーバーしている同人誌場合、1作品あたり Rights を1つ使い、複数登録する。

例:『バクマン。』であれば、

バクマン。 (c) Tsugumi Ohba (c) Takeshi Obara

となる。この場合、(c)表記に出版社がないので書かなくてよいだろう。複数連名の場合漏れなく書くこと。

例:『ろりぽ∞』 の場合

ろりぽ∞ (c)仏さんじょ/一迅社

となる。

例:アニメストライクウィッチーズ』の本であれば、

ストライクウィッチーズ (c) 第501統合戦闘航空団

例:『WORKING!!』のアニメ版足湯後日談本などを出した場合は俺に教えてくれ、じゃなくて、

WORKING!! (c)高津カリノスクウェアエニックス・「WORKING!!製作委員会

メタデータ登録(Add Adv.)大量にあるが使いそうなものを挙げる

Author
同人誌を複数の著者が書いている場合、ここで書く。複数登録出来る。合同誌の場合権利関係(責任関係)も対等であると見なせる人はここに書く。必須メタデータの Author と同じ扱いになる。サークル名を書いてもよい(?)
Collaborator
ゲスト原稿を書いてくれた人などはここに書く。合同誌の場合責任を負うところまでいかない場合はここに書く。
Director
編集者がもしいるなら書いておくとよい。昔はそういうサークルもありました。

その他

自分サークルでわざわざePub化するとこなんてほとんどないと思う。どこかが同人誌をePub化するサービスを始めたとき、これらのメタデータがどう使われるのか?にとても興味がある。ツッコミとか、自分とこのブログで取り上げて修正とか自由にやってほしい。誰か規格を作ってくれたらそれに乗っかりたい。

2009-09-29

iPhoneの位置情報に関するまとめ(暫定版)

iPhoneで撮影した写真に位置情報が付加され云々ということで、先週あたり盛り上がっていたのでまとめておく。

iPhoneには、位置を決める方法をGPSを含め3つもっている

iPhoneスペック表( http://www.apple.com/jp/iphone/specs.html )には以下のように記されている。

位置情報

このうち、デジタルコンパスは、(静止画のExifには含まれるけど)位置情報ではないので省く。

携帯基地局情報

http://www.fdma.go.jp/neuter/topics/jouhou/190126unyou.html にあるとおり、現在携帯電話からの緊急電話では位置情報を通知する義務がある。それに対しSoftbankでは、http://mb.softbank.jp/mb/support/2G/protect/report_position/ に示されているように、GPSあるいは携帯基地局情報を用いて知らせるとある。これがiPhoneでも使用されている。その精度は、数100mから10,000m程度で、もちろん電波圏外では使用することができない。

Wi-Fi

これは、Wi-Fi機器MACアドレスとその位置をひも付けすることにより、Wi-Fiを搭載した携帯機器(今回はiPhone)からのWi-Fi機器の見え方から位置情報を推測する方法で、iPhoneでは、Skyhook( http://www.skyhookwireless.com/ )と提携することによりこの機能を実現している。http://www.skyhookwireless.com/howitworks/coverage.php を見れば分かるとおり、日本でも都市圏ではそこそこの範囲がカバーされている。精度に関しては http://www.skyhookwireless.com/howitworks/performance.php に、10m円で99.8%(つまりほぼ10mの精度が出る)と書いてあるけど本当かなー。

余談だけれども、Skyhookの中の人は少々ビッグマウスなようす。

GPS

説明はいらないと思うけどいちおう。詳しい話はWikipediaを参照してもらうとして、GPSの精度は10m円80%というのがさっきの所に書いてあったけど、現在民生用ではだいたいそのとおり。屋内に関しては、最近では窓から数mであれば測位できるものも多い。GPSはその特性上、移動体での測定に強く(というか、加速度から位置を出すので静止状態だと精度があまりでないGPSは等速直線運動時にいちばん精度が出る。高速移動体はその運動の一部をみると等速直線移動と見なせるため)電車飛行機(ベルトのランプが消えてから使ってね!)でも使用することができる。AGPSというのは、測位初期に必要な衛星そのものの情報を他の通信手段により取得するもので、精度には本質的には関わらない。

方式精度備考
基地局情報数100mから10,000m程度圏外では使用不可
Wi-Fi(Skyhook)約10mほぼ都市圏のみ
GPS約10m屋内使用不可

iPhone GPS問題関連のブックマークで「iPhoneGPSは精度でない」と書いている人がいるけど、たまたまその時がそうだっただけで、そんなことないよ。

静止画とGPS

静止画にメタデータを埋め込むフォーマットとしてExifというのが策定されていて、GPS情報もここに含まれる。現在発売されているデジタルスチルカメラはだいたい対応しているよ。

んで、iPhoneでは、デフォルトではONの設定を切らない限り、上の3つの方式のうちで取得できた精度のいいものを自動的に静止画に付加しているじゃないかな。

問題点ってなにさ

ここからが本題。一番の問題は、ユーザに知らされずに位置情報が付加され、それが外部に出てしまう可能性があることだと思う。これまでのGPSに対応した静止画撮影可能な通信端末(つまりいまどきのGPS搭載携帯電話)はGPS情報自動的に付加されることはなく、かならずユーザ操作を必要とする。これは、GPSが常時ONでないと測位に数10秒かかるという制限からきているという側面もあるけれど、ユーザに位置情報がついているということを意識付けするという意味でも必要な操作なのだと思う。

どうすればいい?

まずは位置情報が付加されることを認識すること。アップルは静止画に位置情報を付加するかどうかのオプションつけてデフォルトOFFにするくらいした方がいいと思う。

で、データを外部に出す際に位置情報を出してはまずいものだったら位置情報を削除。iPhoneで削除できるかは知らないので教えてください。PCでやるなら手段はいろいろあるけど、Picasaなら、静止画を選んで、[ツール]-[ジオタグ]-[ジオタグクリア]で削除できる。Picasaではサムネイルの一覧で位置情報の有無がアイコンで表示されるのでわかりやすい。

蛇足

はてなフォトライフでは、オプションで位置情報の表示のON/OFFを選択(デフォルトOFF)できるんだけど、位置情報付きの写真を表示して「名前をつけて保存」すると、位置情報ON/OFFに関わらず、位置情報がついたまんまだよ。これってまずくない?

(追記)そういえば、はてなフォトライフでは機種で検索できる(これもExifにふくまれている)よなーということで実験http://f.hatena.ne.jp/model/iPhone%203GS から写真適当に保存して、Picasaにつっこむと…。

2008-11-30

On File Systems

(http://www.kev009.com/wp/2008/11/on-file-systems/)

訳した。分からなかったところは英語のまま。ファイルシステムについて完全な素人なので変な所があるかも。

Introduction(前置き)

ファイルシステムOS重要な要素だが最近ではあまり関心を払われていない。ビットが入ってきてビットがでていく……デスクトップシステムにとっては、たいてい十分に働いてくれる……ただし、電源が落ちるまでは。しかし、そんな状況ですら近頃ではあまり困ったことにはならない。

Linuxファイルシステムの分野には競合製品が多い。ext2が長い間標準とされてきたが、2001年辺りから他の選択肢も主流となった。あまり歴史に深入りせずに要約すると(順番は適当)、ext2進化してext3となり、ジャーナリング機能が付いた。ReiserFSがリリースされた。SGIはXFSを移植した。IBMはJFSを移植した。

いくつかの理由があって(主に政治的な理由で)ext3Linuxデファクトファイルシステムとなった。

Classic File Systems(古典ファイルシステム)

私が古典ファイルシステムと呼ぶとき、基本的にいつも同じ概念を指している。つまり古典的なUnixレイアウトファイルシステムジャーナリング機能を追加したものだ。ここに述べるのは、それら古典ファイルシステムハイライトである。

これは後知恵だが、JFSやXFSが牽引力を持たずに、ext3が人々を古典的時代に停滞させたのは一種の悲劇だった。しかしながらext3は信頼性を証明し、きちんと動くように一貫として保守されてもいる。

NextGen File Systems(新世代ファイルシステム)

2005年SunZFSという爆弾リリースした。ZFSは私が次世代ファイルシステムと呼ぶ時代への案内人である。

ハードディスクが大きくなるにつれて、バックアップ戦略、完全性(integrity)の検証、巨大なファイルサポートは前より遥かに重要になってきている。

ここあげるファイルシステム古典的なVFS lineを曖昧にしたりLVMとRAIDを強固な結合することによって管理を楽にする事を目的としている。

ダメハードウェアで起きる静かな(観測されない)データの破損も心配の種である。これに対抗するために、次世代のファイルシステムチェックサムを供えている。

いろんな意味Linuxコミュニティーは完全に油断しきっており、多くの開発者ZFSリリースされるまで次世代ファイルシステムについて真剣に考えてこなかった。Reiser4はいくつかの新しいアイデアを持っていてキラーファイルシステムとなろうとしたが、Hans Reiserは、他のカーネル開発者との著しく酷い関係を楽しんでいたのだった。ただ幸運な事に、いまではいくつかの、より先進的なファイルシステムが登場しようとしている。

Conclusion(結論)

kernel 2.6.28と一緒にext4がリリースされるが、BtrfsやTuxs3が安定するのを待った方がよい。Btrfsの開発陣は短距離走開発を行っているので、Linuxカーネルの開発サイクルに次か、あるいはその次で取り込まれると思われる。

SSDが普及するのは明白だ。理論的に速度の面で磁気ストレージより圧倒的に早く、現実にも既に書き込み速度が追い付きはじめている。最新のIntelランダムアクセスやIOPSは非常に印象的である。Btrfsは当初からSSDへの最適化を取りいれようとしている。しかし、これらの新しいデバイスは、更に速度の早い新しいファイルシステムを生むだろう。

私自身の考えでは、ウェアレベリングやFATエミュレーションSSDの性能を押し止めているため、 新たなファイルシステムが登場すればパフォーマンス改善できるだろう。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん