  |
はてなキーワード: プレビューとは
最近のゲームは、細かくキャラメイクしたり、さまざまに装備や衣装を変えたりできるが、それをプレビューする3Dモデルはたいてい横回転しかできない。
探せばあるのかもしれないが、俺はプレイしたことがない。
ご存知のとおりキャラメイクをするときはいろんな角度から見ないとバランスが崩れてしまう。
あるいは頭や足先の細かい部分を見たいのにズームすると胴体しか見えないなんてこともよくある。
斜めに傾けたいのに傾けられないのはものすごくストレスが溜まる。
いやそれなら、ゲーム本編で下から覗けるのも防ぐべきだし、最初からスカートの中を真っ黒にしておけばいい。
そもそも美少女の登場しないロボットゲーとかでも縦回転できないんだからゲーム開発者の怠慢としか思えない。
スマホではてブのトップとか見てると、毎日だけリストからブクマページに直接飛べない（記事本文にしか行けない）んだけど自分だけ？
999 users
本文の一部...
上のタイトルからは記事本文に、下の本文プレビューからはブクマページに飛べるのが普通の挙動だと思う
一方の毎日はこんな感じ
999 users
いやはてブに毒された悪い癖だとは思うんだけどさ、記事を読む前にまずブクマを眺めたかったりする（その結果記事を読まなかったりもする）から、毎日タイプの挙動はちょっとイヤなのよね
はてなブログでリンク機能あるじゃん？URL貼り付けると、３つくらい選択肢出るやん？プレビューって奴と、タイトルって奴と、URLそのままの奴。普通の人ってみんなプレビュー選ぶやん？だってそっちのほうが記事がリッチに見えへん？見えるやろ？だからみんなプレビュー選ぶねん。でもプレビュー選ぶとプレビューの下にもURLがリンクしたちっこい文字がひっついてくるでしょ？あれ邪魔くさいやん？なんでリンクが重複してんねんってなるやん？で毎回消してたわけ。邪魔に見えるから。でも1年後くらいに自分のブログ見返してみたら貼り付けたプレビューのリンクが全部「Not Found お探しのページは見つかりませんでした。」ってなってるわけよ。ここまでなら、ああリンク先が削除されたんだなって思うだけなんだけどね。でもそのプレビューのリンクのどの場所をクリックしてもリンク先のURLへ飛べないの。読者にはそこにあったリンクのタイトルどころかURLすら分からないの。ここでエーッ！ってなった。リンクのプレビューってこんな落とし穴があるのかよ～。URLが分かってれば魚拓やアーカイブがチェックできるやん。URLでググれば他のブログやまとめにコピペされた内容調べられるやん。プレビューの下のちっこい文字リンクってこういう時のために必要な機能だったのかって初めて気づいた。消すんじゃなかった。最初に言ってくれよ～
最初の夢は忘れた
ようつべみてた
狭い洗面所の鏡の前で全裸の女性をバックから突いてるプレビュー画像だった
遠近法でかなりイイケツしてた
動画がはじまって少ししたら女がふりむいた
男もうつった
男はなんと杉本哲太だった
流出か！？と思ったけど女は誰か知らん人だったし、ようつべコメントも全然騒ぎになってる感じではなかった
自分の中の杉本哲太は俳優というよりも笑っていいともに出てたけどいつもはしっこにいてなんでいるのかわかんない地味な人ってイメージなんだけど、
たぶん大多数の人にとっては俳優ってイメージのほうが強いんだろうな
でも多感な時期の夏休みに毎日いいとも見てたから自分にとっては地味でとりえも何もないイメージなんだよな
だからわりとドラマで見ることも多いけど、なんか不釣合いなことしてるなと思ってしまう
すげえ失礼だけど
正確には、自分含むマイノリティが共有の対象にされてなかった、って感じだけど
チームでプログラムを開発していて、時々情報が飛ぶことがあるなと思っていろいろ見ていたら、Slackの個人の分報チャンネルで他のメンバと開発の話をしていたのを見て、事態を把握した
（Slackのチャンネルプレビューは参加しなくても中身を覗き見できるので便利だ）
なるほど、他のチームメンバがチャンネルに参加しているのをいいことに、自分のいまやってることだけでなく、なんでも書いてしまう「場」と化してしまっているようだった
その馴染み深いメンバ間では、いろいろな情報が共有できているのだろう、そのローカルな機能開発では有利に働く文化だといえそうだ
ただプログラムとしての開発は、もう少し広い体制になっているので、全体に必要な情報は、もっと開発メンバが全員いるチャンネルで伝えてほしいと思った（そういう文化っぽいので、思っただけで伝えてない）
GmailやOutlookのようなウェブメールサービスを利用すれば、すべてのデバイスで簡単にメールアクセスとモバイルアプリを提供できますが、それらのメールサービスはあなたのデスクトップでの動作を保証するでしょうか？
今は、多くの人が複数のメールアカウントを持っている。これらのアカウントが異なるプロバイダを使用している場合は、一度に複数のブラウザタブを開く必要があります
便利な場所にすべてのメッセージを集約するだけでなく、優れた電子メールクライアントは、暗号化やカレンダー、RSSフィード、VoIPアプリケーションとの統合などの機能を追加できます。
デスクトップクライアントはメールをローカルに保存することもできるため、オフラインのときにアーカイブされたメッセージにアクセスしたり、貴重なバックアップを提供することができます。
さまざまな電子メールプロバイダと統合されたチャットをサポートする最高の電子メールクライアント
eM Clientは10年近く前から始まっています。その長い開発により、Windows用の最高の電子メールクライアントに発展することができたんや。
無料版は非営利目的の使用と2つの電子メールアカウントに限定されますが、それ以外の場合は有料版とおんなじ。
eM Clientには、Gmail、Exchange、iCloudおよびOutlook.com、タッチコントロール、高速検索、統合カレンダーおよび連絡先のサポートが含まれてん。JabberやGoogle Chatなどの一般的な標準をサポートする統合されたチャットアプリもあり、Outlookのような重量のあるアプリには良い選択肢ですわ。
あなたのメッセージを補う機能が満載されたすばらしいメールクライアント
Mailbird Liteは単なる電子メールアプリではなく、スケジューリング、チャット、ファイル同期、チームワークのためのアプリケーションを追加できるコミュニケーションプラットフォーム全体です。
Mailbirdをダウンロードした後は、Proバージョンの30日間試用版に対処されます。このバージョンは、月末にアップグレードしないことを選択した場合、限定版Light Editionにダウングレードされます。フリー・クライアントには時間制限はありません。
無料のユーザーは、速読、電子メールのスヌーズ、添付ファイルのクイックプレビューなどの機能を忘れていますが、Mailbird Liteは依然として優れた選択肢です。最大3つの電子メールアカウントをサポートし、スピードに合わせて最適化され、起動時に最適です。
セットアップは簡単です。電子メールの詳細を入力すると、Mailbird Liteは必要なPOPまたはIMAPの設定を自動的に見つけ、メッセージのインポートを開始します。あなたのFacebookアカウントに接続することができるので、あなたの連絡先のプロフィール写真であなたの受信トレイを活性化し、Whatsapp、Googleカレンダー、無料のタスクマネージャMoo.do、teamworking app Asanaにリンクすることもできます。
Claws Mailのシンプルなインターフェースは、より自信を持ったユーザーに適した強力な電子メールツールです
Claws Mailは使いにくくはありませんが、独自のメールフィルタリングに耐え、無制限の電子メールアカウントをサポートしたい経験豊富なユーザーに最適です。
ここの他のクライアントとは異なり、ClawsはユーザーにPOP3 / IMAP設定を手動で設定する必要があります。 Gmailを使用している場合は、Googleアカウントの設定を調整して、安全性の低いアプリケーションのアクセスを許可する必要があります。
古くは現代の電子メールクライアントでは、HTMLメッセージを送信するオプションはありません.Clawはプレーンテキストのみですが、不要な機能を省略することで、Clawは驚異的なスピードで動作します。その検索機能は特に優れており、プラグイン経由でも拡張できます。
それは最も美しい電子メールアプリケーションではありませんが、Clawsはあなたがスタイルを超えて物質を評価するならば、素晴らしい自由選択です。定期的に更新されているため、バグはすぐに除かれます。
すべてのデバイスでメールを管理するためのワンタイム設定の無料メールクライアント
Inkyの無料版はWindows、Mac OS X、およびAndroidで利用でき、ワンタイム設定は3つのプラットフォームすべてで使用するのに最適なメールクライアントになります！
電子メールクライアントをダウンロードしてインストールしたら、Inkyアカウントを作成するよう求められます。これにより、すべての電子メールアドレスがリンクされ、POPおよびIMAP設定を設定することなく、Inkyがインストールされた任意のデバイスからアクセスできるんです！
一度登録すればセットアップは簡単カンタン♪ 各アカウントのユーザー名とパスワードを入力すると、残りの部分をInkyが処理してくれちゃう。
日常的に使用されるInkyは優れた自動タグ機能、メッセージタイプ（個人、定期購読、ソーシャル、ノートなど）のインテリジェントなフィルタリング、デバイス間の非常に高速な検索とクラウド同期でわんだふるん♪。
Windows 7以降を使用していて、特定のメッセージやスレッドを見つけようと多くの時間を費やしている場合、Inkyは膨大な時間を節約できちゃうの！
優れたOperaウェブブラウザの背後にあるチームからの柔軟なオープンソース電子メールクライアント
Operaの開発者は、電子メールを常に優れたブラウザの重要な機能とみなし、無料の電子メールクライアントであるOpera Mailの開発に多大な努力を払ってきました。
その機能には、メッセージテンプレート（特に業務用に便利）、メッセージのフィルタリングとソート、タイプ別のメッセージソート、さまざまなカスタマイズオプションがあります。
クライアントはRSSフィードもインポートするので、Feedlyや欠けているGoogleリーダーなどのWebアプリケーションの代わりになります。
Mozillaから期待されるように、たくさんの機能があり、無料の拡張機能を利用することもできます
Firefoxと同様に、無料の電子メールクライアントThunderbirdはMozilla Foundationによって作成されました（しかし、2つの開発はそれ以来分離されています）。 ウェブブラウザと同様に、その機能は、サードパーティのアドオンの膨大な範囲で拡張され、強化されます。
優れたビルトイン機能には、電子メールには大きすぎるファイルと、電子メールと一緒にRSSニュースフィードを読む機能があります。
セットアップは簡単です。 ほとんどの現代の電子メールクライアントと同じように、必要なのはあなたのユーザー名とパスワードだけで、Thunderbirdは残りのものを処理します。
Windows Live Mailは、Windows 8および10のMailアプリケーションに取って代わられた2012年に最後に更新されました。ただし、Live Mailの比較的昔ながらの外観にもかかわらず、2つのプログラムはほぼ同じです。
Windows Live Mailは、私たちを含む多くの電子メールユーザーがより現代的ですが、最小限のデザインを好む3ペインのレイアウトを提供します。 RSSとクラウドベースの電子メールとPOP3をサポートし、添付ファイルを送信したり、複数のアカウントで作業したりすることが容易になります。
マイクロソフトのやり方が気に入っても、ウルトラスリムなWindows 10アプリケーションがあまりにも制限されているのを見つけたら、従来のWindows Live Mailは賢明な選択肢です。
*
その1はこちら。
We watched the first 10 minutes of Kingsglaive: Final Fantasy XV
By André Mackowiak on July 11, 2016
こちらは、最初の10分間のみの映像を観た人のレポートですが、ネタバレが含まれます。
先週フランスで行われたJapan Expoで大きな出来事となったのが、Final Fantasy XVだ。イベント中、ファンは「KINGSGLAIVE FINAL FANTASY XV」（以下キングレ）の最初の10分のワールドプレミア特別上映などの新しいコンテンツに触れる栄誉に浴した。ちょっとしたサプライズとして、映画を監督した野末武志氏による90分にもおよぶ講演もあった。
壇上で野末氏は、キングレの開発について一歩踏み込んだ解説を行い、アドベントチルドレン（FF7ACC）よりも格段に大きな役割をどのように果たしたかを語ってくれた。
以下のレポートには、ちょっとしたネタバレや、記憶を頼りにプロットを要約したために起きる矛盾が含まれる可能性がある。というのも、最初の10分間にはかなりたくさんの情報が詰まっているからだ。
映画は、いくつかのフラッシュバックから始まり、観客は、ルシス王国を守り続けてきた最後のクリスタルの魔力の概要を知ることができる。
しかし、このクリスタルが敵対するニフルハイムの嫉妬を生むこととなるのである。
開始後すぐ、ニフルハイム兵によるルナフレーナ・ノックス・フルーレの故郷であるテネブラエ自治区侵攻が描かれる。
ここで我々は、幼いノクティスが重篤なケガから回復中であり、車いす生活を余儀なくされていることを知る。
敵兵たちが空から雨のように降下してきたとき、ノクトとルーナは2人とも森におり、周りを取り囲まれてしまう。
強力な相手に二人は追い詰められ、あわや斬り殺されようかというところで、レギス国王が現れ、剣をふるい強力な炎の呪文で敵を蹴散らして彼らを救う。
レギスは素早く意思を固めるとノクトを肩に担ぎあげて、ルナフレーナと共に逃げる。
呪文による炎に逃げ道を塞がれたルーナの兄レイヴスは、倒れた母を救ってくれるようレギスに懇願するが、敵兵が背後に迫っているレギスには届かない。
このままでは逃げ切れないと判断したルーナは突然立ち止まり、引き返して自らニフルハイムに捕らわれ、友人たちが逃亡するための時間を稼ぐ。
それから月日が経過し、物語の時点ではニフルハイムの軍勢はルシス王国の首都インソムニアのすぐそばに展開している。
この「王都」はクリスタルによって維持される強力な魔法障壁によって保護されているが、どれだけそのバリアが攻撃をしのげるのかはわからない。
都市を取り囲むエリアは、すでに帝国軍に制圧されており、城壁部分は空からの攻撃にさらされている。
ニフルハイムの揚陸艇が兵士を降下させ、戦場では銃弾が飛び交い、廃墟と化した建物の周りに死体の山が築き上げられていく。
敵軍は機械や魔導アーマーだけではなく、FFシリーズでおなじみのモンスターさえも操ってルシスに攻撃を仕掛けてくる。
混沌の中をべヒモスが突進すれば、通り過ぎた場所にはルシスの兵士たちが斃れる道が残る。
そうかと思えば別の場所では、巨大な蟲の大群が戦場を横切っていく。
巨大なファイアストームが地平線のかなたに出現し、インソムニアに向かってゆっくりと近づいてくる。
壁の上では、王の剣（Kingsglaive）の魔導マスターであるクロウ・アルティウスが仲間たちと共に町を覆うバリアを維持しようと必死の努力を続けている。
主役であるニックスの親友リベルト・オスティウムは、敵に奇襲をかけようとしている。身につけた制服や装飾品は、FFシリーズのジョブ「忍者」を思わせる。
リベルトは、隠れて相手に知覚されずに複数の敵を倒す術を使う。
空襲が激しさを増すと、地面が打ち震え、建物が崩れ、足元にひびが走る。
嵐が近づく中、我々は敵軍の飛空艇がさらに増え、ケルベロスなどのより危険な敵が出現したことを知る。
嵐の向こう側には、まだ奥の手が隠されていたようである。鎖につながれ、煙に包まれた巨大なモンスターが飛空艇によってインソムニアに向かって引きずってこられる。
モンスターは暴れだし、いくつかの飛空艇を破壊すると、鎖を引きちぎって地上の兵のもとへと落ちてくる。
リベルトは、突進してくるべヒモスの首もとに強烈な一撃を放つことに成功する。一方クロウは最後の力をふりしぼっているが、もはやこれ以上バリアを維持することができそうにない。
王の剣を率いるドラットー将軍は敗北を悟り、撤退命令を下す。リベルトは炎を吐くケルベロスと遭遇し、呪文を使って気をそらそうとするが失敗に終わり、崩れたガレキに挟まれ、刃も手の届かないところに転がるというピンチに陥る。
ニックスは、ドラットーの命令に背き、倒れたリベルトを救うために走り出す。ニックスは、投げた刀のところにワープ魔法を使って移動することができる。
ケルベロスを警戒しつつ、ニックスは戦闘区域外へとワープできるようにリベルトの剣を拾う。
後方に戻った王の剣の隊員は無事を喜び合うが、ドラットー将軍はニックスの命令違反を咎め、彼の力はレギス国王から借りたものであると諫める。
たった10分間の映像だったが、おそらく何時間でもいかにキングレの映像が素晴らしかったかを語り続けられるだろう。それぐらい圧倒的な映像美だった。
何年もの昔、初めて「Final Fantasy: The Spirits Within」を劇場鑑賞したときですら、スクウェア・エニックスがCG業界でトップクラスの才能を揃えており、あの映画が写実的な表現への彼らの最初の一歩となったことは明らかだった。その数年後、アクション満載のFF7ACCでその路線はさらに深まり、ついにこのキングレですべてが結実した。信じられないほどの視覚的なクォリティを実現するために、スクウェア・エニックス内のチームであるビジュアルワークスは、「アサシンクリード」、「ジュラシックワールド」、「ゲームオブスローンズ」などで知られるDigic PicturesやImage Engineなどの欧米のスタジオにも協力を仰いだという。
映画に登場するキャラクターは、あまりにも人間らしいため、うっかりするとコンピューターで生成されているのだということを忘れてしまう。
このまとまりの良さがあるからこそ、合成用のグリーンバックの前で俳優が演技をする従来の映画に比べて映画の世界の説得力が増しているのだ。
べヒモス、ケルベロス、呪文の効果などの見慣れたFFの要素の取り入れられ方も素晴らしい。
個人的には、特にワープのエフェクトが気に入った。ゲーム本編のものと似ているが、人物のまわりに火花が散り、効果音も非常にマッチしているのでとにかくスタイリッシュなのだ。
キングレは、「現実に基づくファンタジー」というコンセプトを驚くほどうまく体現している。
建造物、衣服、技術、車などの中には現実世界を思わせるものもあるが、呪文や魔導アーマー、モンスターとの親和性もある。
2つの世界の融合が、FFXVを単にゲームとしてではなく、より広い観客を対象とした映画として非常に魅力的な存在にしている。
始めのうち、John R. Grahamが下村陽子とのコラボレーションで制作したというサウンドトラックについては不安を覚えていた。
プレビュー映像では、音楽が少し単調で陰鬱すぎるように思われたのだが、最初の10分のBGMは、控えめに言って非常に堅実な出来だった。
ほんの短い時間のうちに、キングレで展開されるストーリーが複雑でワクワクするものになることがわかった。
アクションシーンは「ゴジラ」のように素晴らしく、徐々にモンスターや召喚獣が明らかにされていく手法も良かった。
キャラクターが物語のカギを握るようなので、ニックスとルーナが映画やアニメ、ゲームの中でどのように関わっていくのかが楽しみだ。
これだけのプロジェクトである。映画館で観るのが正しいというのは明らかだ。
10分間見ただけでこの把握力。
訳者は実際に映画を観たので、ちょっと解釈が違うところもあるのですが、あえて訳注はつけないでおきます。
フランスではまだ上映館未定なようなので、彼らにも映画館で楽しんでもらえるように日本でも動員数を増やしませんか。
ほんとすごかった。こんな時代が来るとは思わなかった。
いつまでも見てられると思ったし、これは絶対に時代が来ると思った。
日本のアダルトVRフェスが行列で中止になるのもうなずける。これは流行する。
途中途中でカットが入るプレビュー用のビデオが1本20秒くらい、
それが切り変わっていく流れ。
全部は見られなかったんだけど、おそらく全部で5本～10本くらいかな。
目線の位置的には、カメラを装着して、目線の180度くらいに映像が映っている感覚で、
その中で一部分の、60度くらいの視点を移動する、という感じ。
VRを体感したことのある人は、あの視線が追従する感覚がわかってもらえると思うんだけど。
首を下に向けて少し斜め下を向いたところから、
少し上を見上げるところくらいまでの映像は表示されてた。
男優の下半身がうつっていて、それをくわえる美女3人、右を見ても左を見ても美女。
そして、映像が少し実物よりも大きめに表示されていたこともあり、
すごく迫ってくる感じがリアルで、没入感が半端なかった。
目の前の女優が腰ふってるから、疑似セックスを体感してると言っても過言じゃないくらい。
VRのせいか、外人モノが一瞬で好きになったくらいに、アダルトVRの時代を感じた。
VRをまだそれほど体験してない自分でも、これからはVRの時代が来るって感じられるような、
頭をかなずちで殴られたような、もうとにかくそれくらい衝撃的でした。
なんか論点が違う。
■とかは、これは「見出し」として見えるように目立たせているのであって、マークダウンではないし、日本人にとってのマークダウンでもない。
リアルタイムプレビューはなくてもいいけど、あった方がまー確認できるよね。いきなり投稿になるよりは確認できた方がいいわけで、それがリアルタイムプレビューでもGitHubのようにタブで見れてもいいしというだけの話
Markdownとは、はてなブログでも採用されている表記法のこと。
# こういう見出しを書いたり 1. こういうリストや 1. こういうリスト …を書くといい感じに表示されるやつね。
これをカタカタ打ち込んで投稿すれば、キレイに装飾されたブログ記事ができあがる。
似たようなものだと「はてな記法」やPukiWikiの記法も流行ってたけど、なぜだか今はMarkdown一択の時代。
なぜMarkdownだけが勝ち残ったのか？ というと諸説あるかと思うけど、Markdownには他の表記法と決定的に異なる点がある。それは「メールで慣例的に使われていた書き方そのものである点」。
第二営業部 ＊＊様 いつもお世話になっております。第一営業部 永尾です。 お忙しいことは重々承知しておりましたが、またこのようなメールをお送りすること、何卒ご容赦ください。 第二営業部の皆様にはお忙しい中、当営業部長の退職送別会にお付き合いくださり誠に感謝しております。 さて、このたび当営業部では再度同送別会を開催する運びとなりましたので、改めてご案内申し上げます。 記 ■「澤井部長を送る会２」要旨 日時：３月２５日（金曜日） １７時３０分〜 場所：801会議室（今回はご参加頂きやすいよう社内にいたしました） 会費：０円 ※アルコール有り ■ 連絡欄 ・出欠：「 」（出席または欠席） ・欠席の場合、理由：「 」（自由記入・必須） 恐れ入りますが、明日３月２４日までに返信にて出欠をお知らせください。 （重ねて申し上げますが会費は無料です） 幹事 永尾完治（第一営業部 内線１１８）
しかしこれはMarkdownではない。「日本人にとってのマークダウン」を考えるに、それは「■」や「・」、全角空白で構成された表記法のことを指すのだろう。ゆえに日本人はMarkdownの利点を享受できない──。
要するにMarkdownは「普段使いの書き方をいい感じに整える方法」であり、「覚えて使う表記法」ではなく「すでに知られている表記法に意味を持たせたもの」と言える。だから同じ見出しに書き方が二通りあったりする。他の表記法にこういった重複はない。
そういうわけで「リアルタイムプレビュー」なんて機能を欲しがるのはMarkdownの利点を理解してないというか、Markdownでさえ「意味不明な表記法」と見なすことになってしまう。そうじゃないんだけど。
プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
前掲のセキュリティ文書は、アプリの認証情報 (client_id と client_secret) を盗んだ人ができる悪行にいくつか言及しています。以下に、この攻撃と組み合わせることで (これまで筆者の知る限り公表されていない) 危険行為を実行可能にする問題をいくつか取り上げます。さらに皆様の独創性にかかれば、「秘密」のはずのものを盗んだ人が悪用できる方法は他にも発見できるはずです。
トークンベースの認証は多くの開発者にとって新しい概念です。そのため誤解も多く、EVS のようなものを設計する開発者の中にも、ただ何かの設計ガイドライン (たとえば OAuth) に従って API の動作を決めれば、あるいは他のプラットフォームのしていることをコピーすれば、自分のプラットフォームも自動的にセキュアになるはずだと考える人が少なくありません。しかし何かをセキュアにするには、その要素ひとつひとつを余さずセキュアにする必要があり、それらの組み合わせすべてをセキュアにする必要があり、全体の枠組みもセキュアにする必要があります。思い出してください、全体のセキュリティ強度はその弱点の強度に等しいのですから、何らかの大まかなフレームワークを固守することだけに頼りきって、その通りに使う限り何をやってもセキュアだ、などと安心するわけにはいきません。OAuth ベースのフレームワークそれ自体は、その内部要素のセキュリティを確保することに関しては殆ど何もしてくれません (ある種の要素で、あからさまにセキュリティを害するものだけは別)。
トークンベースのシステムで少しでもセキュリティらしさを出すには、最低でもトークン生成に暗号学的にセキュアな擬似乱数生成器 (CSPRNG) を使う必要がありますが、この話題はあまりよく理解されていません。さらに悪いことに、一般的なスクリプト言語の適切な CSPRNG 用 API は非常に少なく、しかしそうしたスクリプト言語が、人気ある最新サービスの多くを設計する際の基礎となっていることが多いのです。
もし生成されるトークンが予測可能であれば、攻撃者はトークンを推測するだけで別のユーザになりきって悪意ある行為をすることができてしまいます。筆者は、fortune 500 クラスの大企業による OAuth ベースなサービスが一種の単調増加 ID (おそらくデータベースのフィールド？) をそのままトークンに使っているのを見たことがあります。他にも、生成されるトークンがすべて単調関数の出力のようなサービスもありました。よく調べてみると、それは現在時刻に基づく非常に単純なアルゴリズムでした。こうしたシステムでは、まず自分としてログインし、現在のトークン ID を見て、その後の ID を予測すれば、続く任意のユーザになりかわってトークン交換その他の操作にそれを使うことができるでしょう。他のテクニックと組み合わせれば、もっと標的を絞った攻撃も可能です。
このクラスの攻撃は前述のセキュリティ文書で「4.5.3. オンライン推測による新規トークン取得の脅威」や「4.6.3. アクセストークン推測の脅威」に分類されています。この問題には解決策があるとはいえ、現時点でこの間違いを犯しているサービスの膨大さと、この間違いの犯しやすさを考えると、任意の OAuth ベースなサービスが外部レビューでセキュリティを証明してもらえる可能性はあまり高くありません。
本欄の主眼ではありませんが、乱数に対する攻撃の中には、セキュリティを固めた CSPRNG を使っていないと OAuth ベースのサーバを完全に破壊してしまえるものもあります。こうした問題は他のシステムでも非常に困ったものではありますが、動作のすべてが乱数のやりとりの上に成り立っている普通の OAuth 実装では、より一層この問題が際立ちます。こうしたトークンは EVS のサーバ側で生成され、「普通の実装における」OAuth がよくやる使い方ではサーバの信頼性を奪い、関連するトークンすべての予測可能性を高めていきます。最新の攻撃手法を防げるセキュリティ強化 CSPRNG が用意できないのであれば、もっとハードルの低い別のプロトコルに乗り換えたほうが良いでしょう。
一方、一部の OAuth ベースの実装は乱数の必要性をクライアント側に移すような構造になっていることも注目しましょう。色んな意味で、これは問題を別の場所に移しただけではありますが、サーバ側のアタックサーフィスを減らすのは事実です。これによって、少なくとも情報強者な利用者は、信頼できるサービスをセキュアに使うことが可能になります。ただし情報弱者は脆弱なまま放置ですが。今回の例に当てはめてみると、この種のセットアップでは AFCP の開発者が頑張って EVS をセキュアに使えるようにすることと、EVS 自体が陥落する危険を回避することは可能ですが、ABC や XYZ が EVS をセキュアに利用するかどうかは別問題です。
本論に入る前に指摘しておきたいのですが、CSRF 攻撃はその名前に反して、外部サイトからスタートする必要はありません。CSRF 攻撃というのは、自サイトへのリンクをユーザが貼れる、掲示板やメッセージングソフトのようなサイト自体からでもスタート可能なのです。
色々な手法で CSRF に立ち向かうべく設計された数々のテクニックやフレームワークがあります。これらのシステムの多くは、OAuth ベースのものと統合すると使いものにならなくなったり、サイトを攻撃にさらしかねない行為を促すことがあります。
CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装はユーザを特定の外部サイトから連れてくるよう要求しますから、この防御策は執行できません。OAuth サーバがリダイレクトする膨大なサードパーティのドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。
また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要があります。OAuth の背後にある原則のひとつは OAuth ベースのサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています。理想の認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。
転送元と転送先のどちらかだけの、部分的なホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能のオンオフに中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者は CSRF 対策フレームワークを一切使用できなくなります。
OAuth は CSRF 攻撃を防ぐ CSRF トークンを指定するようにと、オプショナルな state パラメータを定義しています。しかしながら、OAuth ベースのサービスは一般的に state の長さや文字種を制限し、要求どおりそのままで返さないことがあるようです。そこで、おかしな互換性問題が起こるため、多くの OAuth ベースサービス利用者はリダイレクトのエンドポイントにおける CSRF 防御をすべてオフにせざるをえない状況に追いこまれています。これは「10.14. コード・インジェクションと入力バリデーション」に分類されています。state パラメータの別の懸念は、EVS 側で state にアクセスのある人はだれでも、リクエストを改竄して、それ以外はまったく有効なままのパラメータを付けて AFCP にブラウザを送り返すことができるという点です。
OAuth ベース API の利用者は、自分のアプリやサービスを登録する際にひとつか複数の URI をカッチリ決めておくよう求められるという制限も課せられています。これは redirect_uri に使えるホワイトリスト URI です。この仕組みにひそむ重大なユーザビリティ問題は後述するのでひとまず措くとして、この制限のせいで開発者は、state パラメータや他の潜在的に危険の伴うアイディアで姑息な工夫をこらし、泥沼に沈んでいくはめになっています。多くの OAuth ベースなサーバは、ホワイトリスト URI をひとつしか許可していなかったり redirect_uri との完全一致のみ有効でパラメータの追加を認めなかったりしています。このせいで開発者たちは CSRF 対策フレームワークの利用をやめたり、あらゆる危険なものを state パラメータに詰めこもうとし始めたり、浅薄なシステムを自前で作り出したりしています。その結果、redirect_uri と state の組み合わせによってはユーザを不適切なページに誘導する危険性が出てきます。これは「10.15. オープン・リダイレクト」に分類されます。
こうしたリダイレクトの問題は、パラメータをしっかり認証していないせいで、それ自体が悪用可能なのですが、これを前述の「OAuth サービスへの偽装」問題と組み合わせるとユーザに大惨事をもたらしかねません。盗んだ client_id と client_secret を使えば、悪いやつらは AFCP とまったく同じ情報で認証できるので、本物の AFCP にも見ぬけないようなリダイレクトを作ることができます。また、悪意あるユーザも、本来自分の持っていない AFCP 内の権限を取得するような state パラメータの利用方法や改竄方法を見つけることができるかもしれません。その際には、おそらく盗んだ認証情報も使うことでしょう。概して、「普通の実装における」OAuth の低品質な設計のせいで、また特定の分野に関する教育レベルが低い外部開発者の直面する問題のせいで、OAuth ベースの利用者に対する攻撃はしばしば、本来あるべき状態よりもずっと容易になっています。
ここで読む意義のあるものとして、さらに「3.5. リダイレクト URI」「3.6. state パラメータ」「4.4.1.8. redirect-uri に対する CSRF 攻撃の脅威」があります。
セキュリティに関して言えば、「普通の実装における」OAuth の仕事ぶりはとてもひどいです。OAuth が目指していると思われるセキュリティ目標の多くは、達成されていません。さらに、OAuth ベースなサービスの中には、種々の攻撃に対して無防備でいることを利用者に公然と要求するものがあります。サービスをセキュアに使える場合も、そのことが知られているとは限らず (サービス側の、トークン生成手法といった重要なセキュリティ詳細が明文化されていないうえにクローズドソースなため)、OAuth は今なお多くの低品質なプログラミング習慣を招いています。OAuth は外部の開発者を守る点でほとんど何もしませんが、そうした開発者が使っている各種フレームワークの方はといえば、こちらも真のセキュリティを提供していなかったり、厳しい自制と注意がなければセキュアに使えなかったりする代物です。
この記事についていえば、個人的に蔓延していると思った問題の一部を取り上げたものに過ぎません。この中には、極度に低質な、一切 OAuth の規格で義務付けられていない慣習を、他所で OAuth に使っているのを見たまま開発者がコピーした結果というものもあります。
OAuth ベースのサービス開発者もその利用者側の開発者も、OAuth ベースのプラットフォームを実装したり利用したりするためには、ここでリンクした文書をすべて読んで理解する必要があります。挙げられている 50 クラスの攻撃も、各クラスの深刻度も完全に把握する必要がありますし、そのうえで「実装の仕様書やセキュリティ・ガイドラインには漏れがないとは限らない」ことにも留意すべきです。この記事は公式文書にない問題をいくつか取り上げているとはいえ、OAuth セキュリティ問題の表面をなでているに過ぎないことも覚えておくべきです。ここに混ざって、公式 OAuth 提案に加えられる変更点はどれもまったく新たなセキュリティ問題を引き起こすものですが、残念ながら変更はよくあることなのです。そこで各々が、乱数生成やセキュリティ調査技術といった OAuth 以外のセキュリティ関連分野も理解していなければ、OAuth でそれなりのレベルのセキュリティを実現することはできません。
真のセキュリティをお探しの方には、よそを探すようお勧めします。最後の章で OAuth の代わりになる選択肢をいくつか取り上げます。
(略: ふつうの実装では、サービス側がプラグを引き抜くようにして自由に利用者を出禁にできる。ビジネス的にもまずいし、悪意あるユーザが API 利用者を騙って出禁になるとアプリへの DoS になる。)
(略: サービス側からは API 利用者という大きすぎる単位でしか見えないので、たとえばビデオカメラのアプリ単位で利用帯域などを制限せざるを得ないが、そうするとそのビデオカメラは、一部ヘビーユーザのせいで他のユーザが締め出される事態になる。OAuth 以外のサービスならふつうユーザ単位。対策としてユーザに開発者アカウントを取得してもらうのも面倒すぎる。ていうか手動プロセスを挟んでたり。)
(略: ふつうの実装は SaaS モデルしか見ていないので、URI を持たない AFCP のような社内ソフトや、ビデオカメラのようなデスクトップアプリには使えない。アプリが cURL 的なもので API を叩こうとしても、JavaScript が必要だと言い張るサービスもある。グローバル企業が地域別にドメインを分けていたら URI が足りない。客ひとりひとりにサブドメインを与える製品だと URI が足りない。足りるとしても追加・更新がメタ API で簡単にできない。ひとつの URI ですべてのリクエストをこなすのはセキュリティ問題もあり、ロードバランス等の必要性も出るし、社内ソフトやデスクトップアプリに余計なウェブサイトへの依存性を加えることになる。httpサーバをlocalhostで立てるとかアホか。)
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認
完全に単一のHTMLファイルで動作するMarkdownエディタ作った
http://qiita.com/tatesuke/items/225b51b270faf8b10923
これ絶対単一HTMLじゃなくてAtomのプラグインで作るべきだって思ったんだよね
使ってみた感じやっぱ更新→保存周りが弱いんだよね、発想は良いんだけど
あとその他のMarkdownエディタに比べてデザインがあんまかっこよくない
エディタ部分とかほぼ単純なtextareaだし
例えばhogehoge.md.htmlみたいな名前のファイルをatomで読みこめば.mdファイルみたいな
感じ（実際はscriptとかCSSとかいろいろ書かれてるわけだけどMarkdown部分のみ）で読み込まれて、
で、それを編集した奴をそのままブラウザで開いたらJS側でレンダリングされたドキュメントとして表示される感じ
簡単にSassでスタイルを当てたりリアルタイムプレビューできればなお良い
実質完全に単一ファイルだしエディタ部分をAtomパワーに依存させることができるから
ええ感じのアイディアと思うんだけどどうやろか
今年パスポートの期限が切れるのでなかなか面倒な役所回りをしなければならず憂鬱なのですが、最近パスポート申請書フォームがダウンロードできるようになり、日本国内に先行して在外領事館がそれを受理するようになったので早速利用してみました。海外在住者にとってパスポートの更新は滞在国のビザの扱いに関わってくるので、少しでもそのプロセスが簡略化されるのは喜ばしいことです。
外務省の旅券のページにダウンロードリンクがありました。早速落としてみましょう。
https://s3.eu-central-1.amazonaws.com/mi-ubuntu/zip.jpg
おやっ？大した容量もなくファイルも1個ですけどzipですか。そうですか。
https://s3.eu-central-1.amazonaws.com/mi-ubuntu/plswait.jpg
ダブルクリックしたらMacのプレビューで開いてしまい、怒られました。私としたことがうっかりしてました。気を取り直してAdobe Readerで開きます。
https://s3.eu-central-1.amazonaws.com/mi-ubuntu/CfWKeEBW4AAJPAK.jpg-large.jpg
https://s3.eu-central-1.amazonaws.com/mi-ubuntu/keikoku.jpg
！！！！
(゜Д゜) ハア??
PDFフォームって普通クロスプラットフォームですよね。なによ警告: -- 外務省って。ちょっと信じがたくFAQを見てみました。
よくあるご質問 | パスポート申請書ダウンロード | 外務省
なにこのクソ仕様。ユーザー視点とかいうレヴェルじゃない。なんだよVistaって。PDFの普通の機能を敢えて削ってWindows専用にしてリリースしてるわけです。
あのね、まず記入したフォームを印刷して領事館に提出するっていうフロー自体そもそもダサいんですよ。電子政府はどうしたんですか。海外在住者は在留届を領事館に出しているので本人の同定はそんなに難しくないでしょう。Salesforceあたりでぱぱっと電子申請作っちゃえばいいじゃないですか。100歩譲ってAbobe製品で印刷・提出にする方式にしても、普通はWebフォームでしょ。あんたらそんなに特殊仕様入れたいんなら、いっそ一太郎形式でダウンロードさせればいいじゃん。
さて、このフォームにいくらの血税がつぎ込まれたと思いますか？
http://www.mofa.go.jp/mofaj/files/000096248.pdf/
次のとおり落札者等について公示します。 平成 27 年9月1日
[掲載順序]
1品目分類番号 2調達件名及び数量 3調達方法 4契約方式 5落札決定日(随意契約の場合
は契約日) 6落札者(随意契約の場合は契約者)の氏名及び住所 7落札価格(随意契約の場合 は契約価格) 8入札公告日又は公示日 9随意契約の場合はその理由 12予定価格
○支出負担行為担当官 外務省大臣官房会計課長 本清 耕造 (東京都千代田区霞が関2-2-1) ◎調達機関番号 014 ◎所在地番号 13
171、27 2領事業務情報システム(ダウンロード申請書、及び該当事案添付書類暗号化に関わる システム改修) 3購入等 4随意 527. 6.22 6富士通(株) 東京都港区東新橋1-5-2 7 39,492,360円 827.6.1 9b「技術的理由による競争の不存在」 39,492,360円
