Hatena::Groupghost-dev

おいもさんファンクラブ

2014-01-03あけましてん

今年も良い年だといいなぁ


創作に携わるみなさまが健康でありますように

2013-12-16れしばいぬと爺さん

「サブや、家にお入り」

「」

「お前のお母さんはな、天国にいったんだよ」

「」


もともとおとなしい仔犬だったが、ますます無口になってしまった。

母犬に似て体が弱いせいもあるだろうが。


「散歩にいこうか」

「」


散歩は好きなようだ。

不自由な足を引きずってついてくる。


「」

「またボールもってきたのか、好きだな」

「」

「ほれ」


ナイスキャッチ。


  *  *  *


「わんちゃん」

「」

「この家の子?」

「」

「おじいさんね、ちょっと病院に行かなきゃいけないの」

「」

「大丈夫よ、すぐ戻ってくるって」

「」


  *  *  *


おじいさん、鼻から変な管でてるよ。

「ふー、」

おじいさん、邪魔でしょ。取ってあげるよ。

「ふー、これ、イタズラするな」

なんだよー。親切でいってるのに。

「お前ももう少し丈夫だったらな、」

おじいさん、ボール。なげてよ、ボール。

盲導犬のように、人様のお役に立てればな、」

散歩はー?ねえ散歩行こー?

「・・・これでは里親も見つからんな」

ボール。はい、ボール。

「ほれ」


ナイスキャッチ。


  *  *  *


車椅子での外出も、人の手を借りねばままならぬ。


「ほれ」

「」


ナイスキャッチ。


何のとりえもない仔犬だと思っていたが、反射神経だけは良いようだ。

年寄りが震える手であさっての方向に放るボールをしっかり捕まえる。


「」

「・・・」


ボールに夢中になっているところへ、そっと、「あれ」を投げてみた。


「」


ナイスキャッチ。


「サブ・・・」


「」


なんと、投げつけた里々の動作ログを見事にキャッチし、フォームに表示しているではないか。


「お前、ログが読めるのか・・・?」

「」


特訓が始まった。

かつて里々ゴーストマスタとして一部界隈では名を知られた爺さんと、

今ではその技を受け継ぐものがいないとされた「れしば」使いの犬。


周囲には何をしているのか伝わらなかったが、爺さんは真剣そのものだった。

犬はただ、楽しそうだった。


然るべきところでサブを預かってもらえるかもしれない。

この命があるうちに。サブが自立できるように。


  *  *  *


さくらの季節。


「いらっしゃいませ。あら、かわいいわんちゃんね。ソシレミへようこそ。」

「」

「よろしくおねがいします」

「こちらこそ、どうぞよろしく」

「」


「サブや」

「」

「よくお聞き」

「」


  *  *  *


「・・・クロ」

「」

「クロ」

「!」「・・・わん」

「どうしちゃったのさ、ボーっとして」

「わん」

「ね、あそこ見てよ。さっき、あの子に挨拶しようと思ったんだけど、うまく届かないんだ」

「わん」

友達になりたいんだけど、伝わらないんだ。どうすればいいのかな?」

「わんわん!」


  *  *  *


「サブや」

「」

「よくお聞き」

「」

「お前は、伺か盲導犬になるんだ」

「」

「この世界は目に見えぬ情報でいっぱいだ。多くの人が見えぬ恐怖に怯え、見えぬ絶望に打ちひしがれ、この世界を去ってしまう」

「」

「お前には私達に見えぬものが見える。だから、この世界の創作者たちの助けになってほしい」

「」

「誰かが迷う時、道を照らす役目を担うんだ」

「・・・」

「サブや」

「わん!」

2013-11-11SSTP NOTIFY/1.2 構想

やりたいこと

  • SSTPで相手を指定してイベントを通知したい。
  • DirectSSTPなら相手を指定できるけど非DirectなSSTPでやりたい。
  • 保険反応付きイベント通知のIfGhostヘッダを使えば相手を指定できる!けどScriptヘッダも必須。Scriptヘッダを空にするとヘッダ無しとみなされてダメ。Scriptヘッダに適当に\eとか入れればいけるけどSHIORIが204 No Contentを返すとScriptが再生されて困る。

構想

SSTP NOTIFY/1.2

  • 相手を指定してイベントを通知するための仕様。
  • イベントを通知することに主眼を置いており、Scriptの再生とか要らない。よってScriptヘッダは必須でない。
  • ブロードキャスト的なこともできるといいな。
  • あとイベントは通知したいけど喋るな!っていう場合もあると思うので\![notifyother,...]に相当するNOTIFYイベント通知もできたらいいな!

仕様

Targetヘッダの新設
  • SSTP NOTIFY/1.1の仕様に準ずる。
  • Targetヘッダに送信したいゴーストsakura.nameを指定する。
    • (Targetヘッダが無い場合はSSTP NOTIFY/1.1の仕様と同値
  • Scriptヘッダは併用してもしなくてもOK。
  • 当該ゴーストが起動していない場合は「404 Not Found」が返される。
  • Targetヘッダに複数のsakura.nameを指定可能!(得意のバイト値1区切りで?)
  • Targetヘッダに「__SYSTEM_ALL_GHOST__」でブロードキャスト
Optionヘッダの拡張
  • notifyコマンドの新設。NOTIFYイベント通知。SHIORIが何か返してもバルーンに何も表示させない。Scriptヘッダは無視。

課題

  • 複数相手に送信可能って…
    • クライアントへの戻り値どうするの?)
      • (1体起動中、1体未起動とかは1体だけに通知して200 OKで?)
  • いやいやSSTPHTTPをパクった仕様なんだしTargetはURIに相当するでしょ

このCSSおかしいしテーマ変えよう近いうち

2013-01-01新年とか

ブラウザゴーストが動くっぽいのは動くっぽいんだけど(色んな実装あるし)

普及させるまでの壁がドーン!って感じだろうか。

見たいなー。Webを根城にするゴーストたち。

願わくば、歴史に縛られない、自由な姿で。


今年も良い年でありますよう。

2012-09-15残暑の候

SSTPのお勉強

13:49

SSTP周辺の仕様について、特にここ数年のSSPの拡張仕様についてあまり詳しくないので色々調べてみた。

descript.txtのsstp.allowunspecifiedsendに至ってはmateria時代からサポートされている由緒正しき仕様なのだけれども、以前色々揉めた時にあまり知られていないことがわかったりして、正しい知識を身に着けておくことは重要だと思ったので。

sstp.alwaystranslate,1

SSPが数年前にサポートした仕様。

SSTP SENDはどのベースウェアでも普通にOnTranslateを経由する。

しかしSSTPにはOptionヘッダにnotranslateというものを付けることが可能で、これによってSSTP送信者はOnTranslateを経由させなくすることができる。

notranslate は,IfGhost により既に対象ゴースト最適化されたスクリプトを送信する際に,トランスレートによりセリフが不自然になるのを防ぐため,などに使用します。

http://www.ooyashima.net/db/sstp.html#option

トランスレートの用途としては語尾変化や、句読点や疑問符などにウェイトを自動挿入するというのがメジャーな使い方だと思う。

これがSSTP送信者にとっては致命的な事態になり得る。

NSPで歌わせようとした時にウェイト入れられたらズレまくるし、語尾変化も歌詞を台無しにする。

そういう事態を避けるために導入された仕様なのだろうと思う。


一方、OnTranslateは文字通りトランスレートするための仕様なのだけれども、全てのリクエストが経由するエンドポイントであることを利用して、ここでまとめて特定のSenderから投げられたSSTP SENDを無効化するために利用しよう、というアイディアが生まれた。

しかし上記で説明した通り、notranslateオプションが付けられたSSTPはこのイベントを経由しない。

そこでnotranslateオプションが付いていてもOnTranslateを経由させたいという要望が生まれた。

上記要望SSPによってdescript.txtのsstp.alwaystranslateという形で実現された。


materiaが更新終了してかなりの年月が過ぎてからの話である。

このためmateriaCROWなど、SSP以外のベースウェアSSTP SENDを拒否することは事実上不可能となっている。

OnTranslateのReference拡張

これは最近の更新。

OnTranslateのReference1にSSTP SENDかどうかの情報が付加されている。

前述の通り、SSPでは既にSSTP SENDを拒否するための仕組みは提供されていたのだけれども、「SenderがSSPかどうか」ではなくReference1の「SSTP SENDかどうか」で拒否判断できるようにしよう、というもの。

SSTP SENDのSenderが"SSP"に偽装されていた場合に対抗できるようになる(SenderはSSTP送信者の自己申告であるため、簡単に偽装できる)。

逆に言うと、それ以外の効用は無い。

2.2.86でより対応が容易になりました。

http://d.hatena.ne.jp/ponapalt/20120904/1346770589

これはウソだ。少なくとも「SSTP SENDをすべて拒否する」という目標に対しては。

まずSSP以外ではSSTP SENDを拒否することはできないのだからSSP以外での起動を不能にしておく必要がある。

そのあとはSSP以外を考慮する必要がない(SSP以外のSenderはSSTP SENDと考えて良い)。

*OnTranslate
>トランスレートSSTPSEND【タブ】!(compare、(Sender)、SSP)
(R0)
*トランスレートSSTPSEND
:何か電波が飛んできたね。
:ワイらはSSTPには対応しとらんで。

*OnTranslate
>トランスレートSSTPSEND【タブ】(count、(R1)、sstp-send)>0
(R0)
*トランスレートSSTPSEND
:何か電波が飛んできたね。
:ワイらはSSTPには対応しとらんで。

になっただけだ。容易でも何でもない。

Senderを確認することで特定のアプリケーションのみパスする実装は可能です。

http://d.hatena.ne.jp/ponapalt/20120904/1346770589

NSP等をSenderを確認して許可などしようものならSender偽装に対抗できなくなるため何の意味もなくなる。

自らセキュリティホールを開けて待っているようなものだ。

あくまでSender偽装にも対抗できるようSenderなどという不確かなものに頼らずにSSTP全拒否を確実にするための仕様が今回の追加仕様だと思っている。


SSTP SENDかどうかの判定ができるようになったというだけで、善いSSTP Senderか悪いSSTP Senderかの判定などできるはずもない。

SSTPに善いも悪いも無い。善悪はそのスクリプトを再生させた人の主観にすぎない。


今回のアップデートで何かが便利になったとか、今までできなかったことができるようになったとか、そういう宣伝がなされているとしたらちょっと危険な兆候なんじゃないかと思う。

テキトーな表現で煙に巻こうという意志が感じられる。

その他

SSTP SENDと、SSTP NOTIFYの「保険用スクリプト」についての話ばかりが話題にされているけれど、NOTIFYのイベント部分は、使いようによっては上記のものと同等かそれ以上に危険な状況を引き起こすケースというのを個人的には想定しているのだけれども、この余白はそれを書くには狭すぎる。


また何か問題が起きてからでも遅くはないし、そうそう起こるものではないし。