  |
はてなキーワード: カレンダーとは
○朝食：なし
○夕食：袋麺、パン四つ（カスタード、クロワッサン、明太チーズポテト、ソーセージとタマネギ）
○調子
むきゅー？
偉い人たちが出張アンド早めのゴールデンウィーク休暇で軒並み居なくなり、
僕が一番古株でかつ、一番仕様を理解していないといけない立場、という絶妙なポジションになってしまった。
そのせいでメンバの、水曜日、木曜日、来週の月曜日、金曜日の四日間のスケジュールを組むお仕事をした。
まあ、とりあえず水曜日と木曜日は単純作業を振って、そのうちに僕が色々準備をして……
と段取りを立てつつ、自分自身に振られてる作業をこなすのはどう考えても無理そうだったので、
自分に振られてる作業をバラして、適度にメンバに振れるようにして、となんか普段使わない頭の部位を使って、滅茶苦茶疲れた。
っていうか、作業工数の見積もりってどうやってすんの！？ ってかなりテンパって、仕方ないから一つ自分で実際にやってみて時間計ったりしてた。
○ゴールデンウィークの予定
金、土、日。
火、水、木。
土、日。
と飛び石な感じ。
とりあえず、最初の三連休は、パンチラインとEVEのリメイクと新作ゲームをやることにして、
次の三連休は、ずーーーっと積みっぱなしの「吹雪の山荘」っていうリレー小説があって、
OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324
http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。
OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。
前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法で OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。
言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたのお気に入りの OAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。
また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法で OAuth を使っているサービスの利用者であっても、また自ら OAuth ベースのサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。
この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。
この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。
この前書きのあとは、まず OAuth のセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティのコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。
その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。
最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。
いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーが OAuth ベースのサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースのシステムの主要なセキュリティ欠陥は非常に蔓延しています。
筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。
というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。
ここで言及されている情報やリンクされている情報は今のところ既存のサービスに悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のものを破壊するのではなく改善することを目指してください。この記事は、自社サービスを不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。
この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。
まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。
ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッション・グループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。
ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザがビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。
ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的に営業部門のメンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。
トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティのアプリやサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:
上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。
さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:
このトークンはユーザの認証情報ではありませんから、そしてひとりのユーザとひとつのアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。
この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。
(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)
(略: そうした詐欺を企業自体が後押ししているような風潮もある)
(略: スタンドアロンのアプリなら、ログインを詐称する必要すらない)
この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザや組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は？
クライアントアプリがユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザはフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザはインストールするネイティブアプリすべての信頼性に自分で責任を負う。
さらに
クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。
基本的に言って、OAuth のセキュリティガイドラインは、OAuth を利用する開発者がユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。
私の知る主要な OAuth ベースのサービスはほぼすべて、ここに概説した手法で攻撃可能です。
OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください！ 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者や管理者に「OAuth はもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。
OAuth ベースのサービス設計でよく見かける間違いは、ブラウザ用に、パラメータのひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティのプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザのブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリやサービスのユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローを OAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。
「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつのサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザがブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。
EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に Facebook が GMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebook のユーザは全員 GMail に対して Facebook そのもののふりをすることができてしまうということです。
この問題は、OAuth エンドポイントがユーザのウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザをログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザのブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。
ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。Google は OAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローがひとつあります:
client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)
Citrix もこんな間違いをしています:
(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)
Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータをリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースのサービス開発者でさえも似たような状況で潜在的にヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。
サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービスは一般的にいって独自の「SDK」を提供しており、サードパーティの開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。
この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアントの機密情報を取得する脅威」に分類されています。しかしサーバがウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者は OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームが OAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレードの参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
男が女の生理に関することに関わるのはなんとなくタブー的でキモい行為に思われるが
まあ自分の周囲の女性全員の生理周期を記録するのは現実的に困難だし
万が一そんな記録をしていることが外に漏れたら社会的に抹殺されるリスクもある
なのでまずは自分のパートナーの生理周期だけでも把握するようにしよう
パートナーであれば生理が始まったことを知るのは比較的容易だろう
それがわかったらすぐにスマートフォンのカレンダーに記録するんだ
女性はホルモンバランスによって体調、メンタルが大きく変化する
特に生理一週間前にもなると普段は明るいあの子が超絶メンヘラになり、些細なことでキレたりすることが多々ある
にも関わらず意外と自分の生理周期を正確に認識している女性は少ない
たいてい体調などの主観的なフィーリングで生理周期を管理している
そうすれば
と仏の心で許すことができるだけでなく
場合によっては本人に
「今の気持ちは生理前でホルモンバランスが乱れているせいなんだよ」
と伝えてやれば、ホルモンによって乱された感情による短絡的な言動を抑制することもできる
たいていカップルでどこか出かける場合は男の側が予定を組むことが多いのでこれはかなり有効だ
さらにそれだけではない
生理周期を把握するということは排卵周期を把握することでもある
嫁は普段あまり積極的でない俺が稀にセックスを求めるのことがあることを不思議に思っているが
ちなみに逆に避妊に利用することも可能だが
生理周期(≒排卵周期)が不規則になることもあるのであまりおすすめはしない
お金のことに対して、ある分でそこそこ楽しく生きる癖がついているのか、単にあるだけ浪費する癖があるのか、
いっそある分をいかにうまいこと使い切るかをコスト配分ゲーム的に楽しんでいるような節すらあるけれど、
「明日の食費に困ったりしてないし現状維持が最大の目標かなあ？」ぐらいにしか興味が持てなくて、
頑張って給料上げるとか、給料低くてつらいとかあんまり考えたことがなかった。
既に結婚してるのに自分の経済観念の薄さとか貯蓄能力ゼロとかに対して漠然とした不安はあるけど、
何年か前にプロジェクトが忙しくて慢性的に22時超えるぐらいまで残業してたらもらった源泉徴収票で年収が400万越えてて、
おおー、これがいわゆるサラリーマンの平均年収的なやつか、と思ってたら、嫁が一人で家にいる時間が長すぎて軽い鬱状態になった。
会社の人は「ウチの会社は頑張ったら頑張った分だけ給料(残業代)が出るからとてもいい会社だよ」と面談で言ってきていたけど、
どっちかというとそこまでいらないから休みと夜の自分の時間をくれよって思ってしまうタイプだったからミスマッチだったのか、
そのあと自分まで体と心を壊して、ついでに医者からあなたはADHDとなんかが複合してますとか言われて、
しばらく休職して復帰したら、今年は給料の半分ぐらいを占めてる推進手当とやらが3分の2か半分かくらいになってた。
ふーん、まあそんなもんか。ぐらいに思ってたんだけど、この間会社でなんかここ数年とこれから1年分の給料の予定みたいな書類をもらって、
そこの総額を見たら300万ぐらいになってて、「うわー減ったなー」と思ってびっくりした。
一度400万越えした時のイメージで「大体自分は年収400万ぐらい」と思ってたけど、
そのあとの年とか割とプロジェクトに余裕があってあまり残業してなかったから一気に360万ぐらいになってたらしい。知らなかったなあ。
まあ、「うわー減ったなー」と思っただけでだからどうだこうだとか何も思わないし、
まあ300万もあればどうとでもなるだろうと思ってしまうからイマイチ危機感みたいなのが沸かない。
会社の人が随分申し訳なさそうだったり気をつかう感じで額を説明してくれたけど、？って感じだった。
なんとなく、嫁もいるのに20%ぐらい減ってるんだからなんかもっと危機感とか持った方がいいのかな？
不安になっとかないといけないのかな？ってなことを思うんだけど、どうにもこうにもピンとこない。
なんかヤバいっぽいらしいっぽいっぽいぜって知識としては知ってるけど実感がない感じというか。
親が実家で年収120万とかで普通に幸せそうに、なんなら自分より不自由なく暮らしてるの見てるから、
家賃が余分にかかるとしても300万もあれば余裕に思えてしまうというのもあるんだろうなあ。
過去の感じだと「ヤベェ、明後日ぐらいの引き落としの分口座にお金が足りないような気がしてきた！」ってならないと危機感が沸かないので、
自分の未来認識は3日ぐらいが現実感のある最長距離なのかもしれない。
っていうか「ぐらい」とか「気がしてきた」とかの現状をまったく把握してない感も相まってだいぶヤベぇなコレ。
それにしてもカレンダーとかに書き込んでみたりするけど、なんか現実味がなくてうまく想像できない。
そんなわけで、老後がーとか言われてサイトとか本とか見てもひとつもピンとこない。マジでこない。
まあいいや、今日も納豆おいしかったし。晩御飯の材料も家にあるし。
雨だから早く帰ってご飯食べて寝たいなあ。
http://anond.hatelabo.jp/20160331141519
最近巷で東京カレンダーはやってますけど、あれって全部作り話だというのは良くてもちょいと下品というか下賎すぎませんかね。
友達経由で知ったけど、これとか地方出身者としてどこが「錦」なのかわからねえって話なわけですよ。
https://tokyo-calendar.jp/article/5976
どこがパワフルなのかというよりは、見た目以外なんもねーんだなこいつという感。
フリーランスって結局モデルじゃねえかよ、という素敵なオチ芸まで披露頂き涙を禁じえません。
http://ameblo.jp/aricherababy/
東カレがらみだと、下記の通りしょぼい嘘っぱちを並べていると。
http://blogos.com/article/170047/
そんなわけで、友人に言わせるところ「上京カレンダー」というの概して同意するし、
何かに寄りかからなければ自分を証明できない迷える子羊ちゃんにとって光り輝くメディアなのでしょうね。
個人的な所感としてましては、登場人物(書き手の自己投影だろうけど)の特徴は･･･
・潔いほどセックス以外興味ない
・バカ舌
なんというか、作り話としては面白いんだけど、その裏にある作り手の下衆顔とその人の自覚のない心の虚無に少しばかり想いを馳せた4月1日。
ちょっと前にセディールを褒めちぎった直後だけど、セディールをやめようとしている。
やめてみようと思った理由もメモしておきたくなったのでメモしようと思う。
正直なことをいうと、いつから断薬したのかそろそろ覚えてない。
ただ、自分で書いていても思ったのだけれども、
セディールにそんな薬効があると俄に信じがたいのだった。
というわけで、せっせと断薬して
本当に前の記事で褒めたようなことが起きてるのか確認しようと思った。
あともういっこ。
料理が大好きだ。
まずレシピブックを読んで忠実に作るのが好きだ。
いかに効率的に、美味しいものを作るか考えるとテンションが上がる。
作ることへの感心が、と言ってもいいかもしれない。
大ざっぱに作って、食べられればそれでいいやという気分になる。
まずくても我慢すればいいし、食べられなければ捨てればいいわけだ。
……つまらない。
ついでにやたらお金がかかるようになった。
あと部屋も汚くなった。
とっちらかっていても気にならない。
という訳で、創作意欲の減退というか、
果たして結果は。
本屋も好きだ。
興味がなかったせいで。
…。…………あれ？
部屋はまだちょっと散らかっている。
たとえ話になるが、服薬中は丸いものを見たら
最近は「ところで丸ってなんだろう」とか
「実はこれは四角だったりしないだろうか」とか
「上に球体が浮かんでいてその影だったりしないだろうか」とか
色んな事が頭をよぎるのだ。
わかっているのだけど、ものすごい勢いなのでどうしようもない。
反対に、ハンガーにかけられている服を見ても
「布だ」「服だ」「どんな型紙だろう」という方向以外、思考がストップする。
「着てみよう」につながらないのだ。不思議なことに。
タンスの前で立ちすくむところに退行するのだろうか。
昼ご飯に食べた社員食堂の定番メニューの竜田うどんの竜田揚げ、
小麦粉をそのまま食べると苦しいので
料理ってすごいなあと思いながら、
こんな風にものを考えるのは久しぶりだと思う。
私だけかなあ。
○朝食：なし
○昼食：中華丼
○調子
むきゅー。
今日はお仕事はお休み、カレンダーは三連休なのでむきゅむきゅダンスを踊るぐらいテンションアーップ。
なんだけど、なんか職場カレンダーを見ると20日が振り替え休日に設定されてて、21日が出勤日になってる。
十中八九ケアレスミスなんだけど、念のため確認したくて会社の人と連絡とったりしてた。
よかったむきゅー。
夕飯にビールを飲んだので、べろべろです。
ベロクロンです。
ぐへへ、イーブイ可愛いよお、バッジとれ〜るセンターに課金するの楽しいよおおおあ。
○Miitomo
こういうリアル交流ゲームを楽しめないのは、ゲームのせいじゃなくて、自分の交友関係のせいって気がするから、
なんか楽しくないって言いづらいんだけど、
言いづらいんだけど、楽しめないなあ。
マジックオンラインアイコンさんとか、バビディに洗脳されたデフォルトアイコンさんとかと繋がれたら楽しそうだけどなあ。
あの二人、TwitterかFacebookやってるのかなあ。
・夫婦共働き（夫 比較的激務 妻はホワイトだが土日に勤務有）
・2歳になった男児1名
引き続きよろしくお願いします。
一般名はタンドスピロンクエン酸塩で、1996年に発売された大日本住友製薬の抗不安薬である。
このセディールはggったらわかるのだけれども、びっくりするほど評判が悪い。
私はセディールに丸２年ちかく、１日３回世話になり続けた。
途中何度か油断して断薬したりもしたが、
その度に「やっぱりセディールがないとだめなんだ」と反省して飲み直した。
どれくらい飲んだんだろう。700日間飲んだとしたら2100錠だから、21箱？
私はセディールが好きだ。人生を救ってくれたと思っている。とても感謝している。
できれば1日3回の用法が煩雑なので徐放とか開発してくれないかと思っているのだが、
というわけで、ネットにセディール万歳記事が見当たらないと悔しいので、
どうせこの記事も埋もれるんだろうけど、それでも書きたい。自己満足です。
長くなるけど自己満足っていうことで許してほしい。
セディールの話をしているからには、私は抗不安薬を飲まなくちゃいけないような人間だ。
幼い頃はADHDのクラスメイトとセットで爪弾きにされて、彼女の失禁の面倒ばかりみていた。
その後不登校になって自殺未遂して、……まあ波乱万丈に鬱々と生きてきた。
受験生のときに、駿台模試の数学で偏差値103とったことがあるくらい。
他人にはほぼ無関心を貫いていた私も、さすがに驚いた。
「こんなに簡単な問題を解けない人がいるらしい」という方向に。
別に数学自慢をしたい訳ではなく、抗不安薬の薬効を褒めるに当たって
どういったバックグラウンドの患者であるかを説明したいのだが、
数学ができそうなことを書いてみたが、私は基本的にテストが苦手だ。
知らない場所へ行くのも大嫌いで、場所が変わったらただ硬直するだけの人になる。
たまたま前述の模試は知っている予備校の知っている部屋で開催されただけで、
別の部屋で開催していたら多分偏差値なんて40とかその程度に落ちていたと思う。
たとえば「月末に試験がある」とか、いつもと違う予定になってしまったら
食事も食べられないし、部屋の片隅でずっと猫のように丸まっている。
両親はいつも「私に物事を意識させない」ように気遣ってくれていた。
幸か不幸か、観察眼もないし日付や時間もよくわからない人間だったので
騙し騙し手を引けば、何にも気付かずいつも通りに過ごしていた。
「今日は一緒に出掛けよう」←よくあること
「この席に座って問題を解いてね」←よくあること
で、誤魔化すことが可能だった。
子供だましのようだが、子供だましが看破できないからASDなので仕方がない。
しかし、そんな風に一から十まで他人に面倒を見させる訳にもいかないだろう。
大学受験の段階で、かなりムリがあったと思う。
一般企業で働くのは無理だと気づいて、手に職をつけさせようとしたのだと思う。
という訳で、向不安薬の存在をはじめて意識したのは、大学の教科書の上だった。
そのとき、私はまだ精神科や心療内科の世話になったことはなかったのだが
セディールが、セロトニン5-HT1A自己受容体に部分アゴニストとして作用するとか、
受容体が脱感作してダウンレギュレーションを起こすことは何となく印象に残った。
他の多くの抗不安薬はGABAa受容体のCl-透過性をどうの、という作用点なので
「あー全然違うのが混ざってる、へー」程度だったと思うが。
まあいろいろあって、職場を追い出され、実家でもちょっとトラブルが起き
元々神経過敏であった私は、あっという間に鬱っぽくなった。
あくまで「鬱っぽく」だ。
適応障害と言われたが、私の問題は適応障害云々とは別のところにあった。
そりゃ何もなくても泣き出したりしたりしたけど。
ご存知の方もたくさんいらっしゃると思うが、
物音も人間の気配も何もかもが耐えられなくて、
外出してみたものの、机の下に隠れて出られなくなるような有様だった。
ちなみに、この時点でカウンセリングやテストを受けて、ASDが正式に発覚した。
また、これもよく知られていることだが、
私もその系統で、鬱や適応障害に投与される抗不安薬がほぼ使い物にならなかった。
たとえば、メイラックス（ロフラゼプ酸エチル）という薬がある。
成人なら1回2mgで1日1回服用の、長時間作用型の穏やかな抗不安薬だ。
高齢者などで1mgで投与されることもある。
1mg飲んだところ、2日間に渡って朦朧状態、ほぼ40時間ぶっ通しで爆睡した。
メイラックスは比較的コントロールできるので今も世話になることがあるが
初日に0.5mg（1mg錠を半分に割る）、以降1日おきに0.25mg（1/4に割る）。
この使い方は、自分の体感を頼りに半減期などを考慮して自分で計算して決めたものなので、
他の薬の感受性が高い人が同じ容量で効果を得られることなどを保証するものではない。
飲んだら千鳥足、からの爆睡。半日以上目が覚めない、そればっかりで、
とてもじゃないけれども、外に出ることを前提に使えたものではなかった。
なお、三環系や四環系、SSRI、SNRIなどは未経験である。
かろうじて大学だけは卒業したものの、卒業したところで私は立ち止まった。
そのまま部屋の外に出られなくて引きこもって終わる可能性も覚悟した。
そんな時に処方されたのがセディールだった。
効果は薄いかもしれないけれど、と抑肝散と共に処方されたそれを見て、
そして、こいつに即効性はないはずだ、と引きこもりの頭で考えた。
知らない。知らないけど、俗に作用発現に２週間と言われているということは、
とりあえず長く見積もって１ヶ月、高コンプライアンスを維持しよう。
とかなんとか。
目標は抗不安効果ではなく、セロトニン受容体を殴ることだと割り切り、
効果の体感がほぼない分、服薬忘れに細心の注意を払ったと思う。
で、２ヶ月くらい飲んだ頃、正直、「あんまり効果ないな」と思った。
依然として不調な時は不調だったし、
そこで面倒になった私は、薬のなくなるタイミングで勝手に断薬した。
２週間くらい放ったらかして、何だかイライラする頻度が増した。
落ち着かない感じというのだろうか。
その時にはすっかり忘れていた強迫行動がぶり返した気がした。
ベンゾジアゼピン薬の消費が増えかけたので、
その時即効性を感じた訳ではないが、数日後にぴたりと強迫行動は止まった。
日付感覚がないので、カレンダーにメモする癖がついていたせいだ。
そして、しばらくして十分に安定した頃合いに、
その直後はなんともないのだが、
数日するとまた覚えのある強迫行動がぶり返す。
退薬症状でいきなり強迫行動のような特徴的なものが発現したら、
何度か間をあけて飲んでは止め、を繰り返し、
たまに本気で飲み忘れる日も挟んで
カレンダーに出来上がった記録を見て、思った。
なんていう内容をやっていたので、熱心に信じることにした。
頻度は減り続け、今では月に１度も必要ない。
そのうち周囲の環境が変化してよくなったこともあってか、
こだわりも飛躍的に軽減した。
もちろん、今日も私は時計が読めないし、日付はよくわからない。
試験とか言われると倒れそうにはなる。
数字が大好きで、統計データを眺めてひとりでテンションを上げている。
でも、もしかして……？と思うことがある。
数年前より格段に増えた気がする。
「今は『じゅうしちすなわちごじじゅうにふんという時間』なんだなあ〜」と素直に受け入れて、
気にせずスルーすることができるようになった。
思えば、私はずっと怖かったのかもしれない。
歩く時は地面しか見ていなかった。
気づいたら増えていて、気づいたら減っている変なものによって
だから見なかったし、感心を払わなかった。
何歳になってもずっとポケモンを見ていた。
私はたいへん臆病だったのだ。
ところが、その恐怖心が、なんだかこの数年でスーッと、静かに
砂の山がいつの間にか溶けてなくなっているような感じで、小さくなっていた。
全てセディールのおかげかもしれないとまでは言わない。
私が単純に成長しただけかもしれない。図太くなったのかもしれない。
世の中に怖いものが増える、という感覚はやっぱり戻ってくると思う。
最近の私が服薬を忘れる時というのは、何かに熱中している時だ。
慣れ親しんだ恐怖心が平行するように顔を覗かせるのだ。
楽しい気分の時に忘れた時なんて、完全に意識の外へゆくはずだ。
でもそうじゃない。
ということは薬効は100%気のせいではないのではないか、と思う。
私はASDで、薬物過敏だし、普通の抗不安薬で昏倒する体質なので、
ベンゾジアゼピン薬を飲んでも普通に起きていられる人には、セディールは弱すぎるのかもしれない。
セディールは、私のような誰かにとって救世主になり得る良い薬だ。
読んでくれた人がいる気がしないが、もしここまでスクロールしてくださった方が
いたのだとしたら、ありがとうございます。
大日本住友製薬さん大好きだよ。
パナマで逼迫これから桃太郎。丸型の赤ペン＆スピーカーとティッシュ箱ちりくずホコリ溜まって白い円柱形のアルコールティッシュは中身重曹水。黄色い垢噴き出る。簿記の教科書が薄い髪に透ける。ベビーオイルたれてるけど一週間放置で蒸発しない。つまみ付きUSBDAC日本製です。閂型USBメモリ。USBコンセントは黒くて小さくて安い中国製。黒いプラケースでケーブル隠す。上が透けてる。茶色のクッションが2つある。椅子はロココ調でダンボールにゴミが入ってる。プリンターは白い。プリンターと歯垢。ジョンソン・アンド・ジョンソンの歯フロスはノンフレーバーでタブ開きすぎ。コップにニューヨークの町並み。リモコンは東芝製。高校生の声が聞こえる。たぶんメス型。蛍光ペンを2本使い潰した。こすって消える。摩擦は得意じゃない。カーテンの汚れが気になるけどもう少しで引っ越しだから見ないふり。カレンダーは3ヶ月分。マウスパッドに汗が染みる。ニトリ製のロールカーテンの向こう側にカゴがあってミカンが入って。イシュトバーン1世とヒラメ筋の緊張で踏み合い昇降運動。電熱器と電気代は合格体験記の上にあるA4プリント紙は後ろ向き。油の風がべたつく。空腹とハンドソープでケンタッキーフライドチキンが食べたい。チロシン。ドパミン。電話がベージュ色鳴らない。コーヒー何杯目かおかわりして空気清浄機が反応した。暖炉に真鍮の窓。ホームセンターで売ってる白いカゴ。青いカゴ。黄色いカゴ。ゴミを出す日は金曜日は昨日に終わった。香味焙煎。電源コードが乱れ飛ぶ。ネズミ色で格好わるい。テレビの音はFOSTEX。日常生活をレイプ。私も以前は中学生で幼稚園児でした。オシャレな低音が強いBluethoothスピーカー。ピンポーン。あの子が好き。表面の皮が好き。メロンパンみたいな女の子。メロンパンの皮焼きました。レイプしましょう。洗濯ネットとファブリーズを使います。書類バインダーは使いふるしで臭い。無印良品のウィーンブレンドは飲み終わった。黄色い封筒の中にイケメン。焼肉屋の香りがする夕暮れのスーツ店で喪服を買う。夢がある。夢がない。希望がある。希望がない。猫は動かない。最初から死んでるマネキンだ。女子高生をコタツで縛り上げる。冷蔵庫の振動が心地いい。豆板醤にニンニクは入ってない。嬉しなってしまいます堺。招き猫2匹いる。黒と白。薄汚れて時計の針は無音で母のお気に入り。小学校高学年とおっぱいの独立性。自由民主党設立の意義とは母乳の噴出。初恋のミルク。鼻からあふれる精液がグルタミン酸に反応する。スリッパ内部の湿度は限界だ。皮膚アレルギーはビタミンで治る。巨乳発電の開発。大きな褐色の乳首が体操着から透けて見える乳輪と競泳水着の薄さの限界に挑戦する陸上ブルマ収集家たち。僕の友達レイプしました。テレビ線に突っ込みました。味の素でレイプしました。味噌汁にトマト入れます。キーボードとの対話、五本指で奏でるQ.W.E.R.T.Y. マグロ漁船でチカンします。置換は果敢。ご機嫌斜めは打ち出す。エロイこと出す。五代ロス。写真術の世界にようこそ。第三の道。再放送の見過ぎ。安禄山の乱。日本人とみられる16歳の女子高生は性的関心の範囲外。40代が好き。しわくちゃババア。支給機能の停止。預貯金は約15万。ぽっちゃり店なら20回遊べる。キスが臭い。口が臭い。口が臭くない女の子がほしい。みんな臭い。魚臭い。磯臭い。タバコ臭い。電池臭い。電池の臭いがするフリー要因。きつい顔して誤解されるマリア様。ドナルドダック石巻。野々市。階段したから見えるパンツ。盗撮してないから合法ロリ。かつての栄光は変態が増えすぎた後遺症で退屈だ。セーラー服は夏服。パジャマでおじゃま。千とグレナディーン諸島と神かくし。畢竟第六天魔王。好きです頬骨とたこ焼きの青のり臭いエステ嬢。オイルはイランイラン。香りがイランイラン。無香料なら既婚者は偏見だ。マツダBE A DRIVER！パチンコ大好き。彼氏と喧嘩してパチンコして楽しかった。ハマった。今はおちんちん擦ったコストでパチンコ三昧。ラーメン屋にはいかない。デブだけど外食しない。魚はイケアの近くで買う。手作り麻婆豆腐。顔面偏差値は高いけど脂肪過多。女子中学生がアナルオナニーしてローション水増し事件発生。母が浮気を疑って夫婦喧嘩するアナルオナニストJC。リズリサを着るピッコロ大魔王はたぶん市立商業だ。青森石原さとみ自称似てるって似てない。今はキャバクラ嬢やってるの？ブライダル専門学校やめてマンコくさすぎパンティ脱いだら5秒で悪臭。でも本番あり。最上階で窓開けっぱなし。是非もなし。すべてはスリナムとニューアムステルダムの交換のために。
珍しく朝早く目が覚めてスマホで、はてブの新着チェック。4時間前に見たばかりだったので目新しいものはなく。いつも「人気」カテゴリしか見ていなかったのだが、その並びに「日めくり」というのがあることを初めて知った。見れば「○年前の今日」のはてブランキングが見れるらしい。あれ、PC版の画面でンなもん見たことないと思ったらモバイル用にリリースしたものなのか、ぎぎぎ。
個人的に「日めくり」という名前が微妙にしっくりこない。たぶん命名者はちゃんと紙のカレンダーに予定なんかを書いたりそういう日めくる文化があったんじゃないかな。俺には無い(恥 ふつーだけど「振り返り」でええんじゃない？って、恐らく捻った上での話なんだろうけど。あとfacebookとかgoogleフォトみたいに
なんてな邪魔い通知機能とかあると「んだょ、ウザぁ！」と思いながら観るんだと思う(w
「日めくり」機能で、2015/3/5のはてブランキングNo.1が以下
あー、読んだわー。読んだのに完全に忘れてるわー(赤面 結局、災害時応援の声がかからないと世間の目の前には出てこないのか。微妙に欲しいのよねぇ。それにしても、たちこぎさんに始まり、協力した段ボール屋さんや興味を示した自治体さんなど、前向きな人たちがちゃんといるんだと勝手に元気をもらった気になった。
