「Google Apps」を含む日記 RSS

はてなキーワード: Google Appsとは

2019-02-16

anond:20190216231137

GNU Assemblerが何かやらかしたのかと思ったが、GoogleGoogle Apps Scriptというので名前を被らせてるのか

2016-04-26

anond:20160426145507 の続き

anond:20160426124418anond:20160426145507 の続きだゾ。てか長えよ

(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数動画アップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシSaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)

(略: 個人ユーザ向けのAPI設計ばかりで、雇用者上司アカウント管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuth活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)

(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品OAuthの面倒さのために失敗してきたことか。)

普通実装における」OAuth代替

適切な OAuth ベース設計とはどのようなもの

ここまでで「普通実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。

初期の OAuth 規格および概念におおよそ付き従っているシステム一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:

はいえ、このように設計されている OAuth ベースシステムはごくごく希少で、しか一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0概念や追加機能すべてを加えて再構築され、セキュリティユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。

他の選択肢

他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワーク必要というわけではありません。現状、OAuth とはどのようなものかについての意見サービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータ改竄を防ぐため変数署名する方法だけであり、この点に関して、ほとんどの OAuth ベース実装は一切何もしてくれません。

ウェブサービスの最大手である Amazon は、世界中企業サービス提供する一流プロバイダで、合計 30% 以上という途方もない市場シェア他者を圧倒していますAmazonアプローチは、自分アプリ認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者提供することです。この認証情報で、どの Amazon サービス作業できるか、そのサービスでどの操作を実行できるか、どの権限作業しなければいけないかを指定できます。この認証情報必要に応じて「アカウントホルダ」の人が破棄することもできます

AmazonAPI における認証承認技術には、本質的制限が多く潜在的危険性のあるリダイレクトを一切必要しません。Amazonプロトコル認証情報は、直接送ることは一切なく、データ署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。

Amazon設計アカウントの利用状況を API の利用まで適切に把握できますし、API認証承認もすべて Amazonからスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています

ひとつ言及せざるをえない短所は、Amazon権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計問題であって、承認プロセス自体の失点ではありません。さらに、Amazonコントロールパネルはかなりキビキビ使えて、それ自体API でも使えます。この点たとえば Google場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。

Amazon認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされていますGoogle 自身企業向け製品の一部でこれを利用できるようにしていますGoogle 自身純粋OAuth 設計企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています

JWT はサービス間の SSOAPI 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやす方法で一切の面倒なく達成しています。HMAC 実装ひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。

ただ Google場合典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求していますGoogleコントロールパネルではアカウント管理者自分企業サービス用に新しい鍵ペアを生成でき、API ログイン署名するために使う秘密鍵ダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Googleプロセス全体を本当に無駄に複雑化していますコントロールパネルしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例必要なら他をあたるようお勧めします。

他に使われている技術は、サードパーティがどんな権限必要としているかをある種の XMLJSON ファイル定義してウェブサイト送信できるようにするサービスのものです。ユーザがあるページを自分アカウント訪問し、ファイルURL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれ説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティアプリあるいはサービスに貼り付けますユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者おかし負担を強いることなく、すべてのアカウントAPI サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。

承認管理のためにサービスから提供してもらう必要が本当にあるのは、適切な役職 (管理者アカウント所有者など) を持つユーザ自分に割り当てられた権限や (望むなら) 期限を持つ認証情報API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報ネットに通す必要のない暗号学的テクノロジー活用した認証プログラムに基づくものなら何でも使えます特に HMAC は、承認認証実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています

こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数フレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャワンタッチで装着できるようなモジュール化の実装が可能です。ユーザアプリ認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムOAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザ認証情報要求したり他に弱点があったりするような一部の劣悪な設計システムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初存在していなかった問題まで生じさせています宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています

これからサービス設計をして API アクセス提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。

2016 年 4月 Insane Coder

http://no-oauth.insanecoding.org/

anond:20160426124418 続き

プレビューまでは全文見えるんだけどな。すまんやで。しかもまだ続く anond:20160426150324

anond:20160426124418 の続き

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくありますGoogleOAuth の使い方を多数提供しているうちで、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 攻撃というのは、自サイトへのリンクユーザが貼れる、掲示板メッセージングソフトのようなサイト自体からでもスタート可能なのです。

色々な手法CSRF に立ち向かうべく設計された数々のテクニックフレームワークがあります。これらのシステムの多くは、OAuth ベースのもの統合すると使いものにならなくなったり、サイト攻撃さらしかねない行為を促すことがあります

CSRF を防止するひとつの仕組みとして、ブラウザから送られる referer (原文ママ) が外部サイトを指していないことを確認するというものがあります。多くの OAuth 実装ユーザ特定の外部サイトから連れてくるよう要求しまから、この防御策は執行できません。OAuth サーバリダイレクトする膨大なサードパーティドメイン、また関係する URL やドメインの完全なリストは明文化されていないうえに折々で変更があるため、EVS のドメインとページ全体をホワイトリストにするのは不可能です。

また、EVS の提供者が寝返って AFCP を攻撃しようとする可能性がないかどうかも検討する必要がありますOAuth の背後にある原則ひとつOAuth ベースサービス側が利用者を信用しないことです、しかし同時に、利用者側には CSRF 回避策を見なかったことにしてサービス側を完全に信用することを要求しています理想認証システムというものがあるとすれば、一方通行ではなく相互レベルの不信を確立するでしょうに。

転送元と転送先のどちらかだけの、部分的ホワイトリストというのも難しいことがあります。使っている CSRF 対策フレームワークによりますが、機能オンオフ中間がなく、特定のページや転送元だけを無効にすることができないかもしれないので、その場合 EVS 利用者CSRF 対策フレームワークを一切使用できなくなります

OAuthCSRF 攻撃を防ぐ 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 のような場合は期限切れがあってはならないので、パスワード等を預かる

OAuthのことを1ミリも知らない俺が

OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324

http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html

OAuth がうまくいかない理由と、既存サービスゼロデイ攻撃方法

OAuth とは

認証 (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 は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:

  1. ユーザサードパーティアプリ/サービス (たとえば AFCP) を訪ねて、特定のサービスと統合したいことを知らせる。
  2. AFCP は、EVS でホスティングされた特別なログインページを出してユーザに EVS の認証情報を入力させる。
  3. EVS は、その指定したアクセスレベルユーザが本当にサードパーティ (AFCP) へ与えたいのか確認する。
  4. EVS は AFCP に一種のトークン (複数の場合もある) を提供し、各種 API コールに使えるようにする。

このトークンユーザの認証情報ではありませんから、そしてひとりのユーザひとつアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。

この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。

(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)

(略: そうした詐欺を企業自体が後押ししているような風潮もある)

(略: スタンドアロンアプリなら、ログインを詐称する必要すらない)

この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザ組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は?

クライアントアプリユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザインストールするネイティブアプリすべての信頼性に自分で責任を負う。

さらに

クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。

基本的に言って、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 に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に FacebookGMail 用の 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 がたくさん見つかります。GoogleOAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローひとつあります:

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 業界によくあるやり方で、この既に猛威をふるっている問題は、パレード参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。GoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、 このエントリーをはてなブックマークに追加ツイートシェア

2016-02-16

アダルト関連ニュースサイトを構築した話

風俗店とかキャバクラに遊びに行っていると「風俗店摘発」とか「売春防止法違反」というニュースには敏感になる。

以前から、こういう風俗とか水商売関連のニュース自動で集めたいなー と思っていた。

しかしながら、具体的な手法が判らず、ちまちまと グーグルニュース検索でそれっぽいキーワードしこしこ入力していた日。

それでも自分で少しずつ手法を探してみて、プログラムを組んで… それっぽいサイトが完成したので、備忘録的に記録しておく。

1) GoogleNEWSのRSSデータを取得する。

https://news.google.com/

ここで関連キーワード風俗」とか「デリヘル」を入力して、検索すると関連ニュースがヒットする。

これをRSS形式で出力する。

参考サイト

http://so-zou.jp/web-app/tech/web-api/google/search/news/



2) RSSの内容を解析する。

RSS形式で取得したデータを、RSSパーサーを使って解析する。今回は「MagpieRSS」を使用した。

参考サイト

http://singoro.net/note/magpierss/



3) 記事概要投稿する。

今回はワードプレスを用いて自動的投稿するようにした。

ライブドアブログでも試してみたが、こちらもうまく自動投稿ができた。

※内容が内容だけにアダルトOKのライブドアブログを選定した。アメブロでは試してないが、アメブロ自動投稿は難しいらしい。



4) 一定時間毎に自動投稿させる。

今回はCRONは使わずまたまた Google先生の力を借りる事にした。

Google Apps Scriptトリガー機能を使って、CRONと同じような事を実現させた。

一番大変だったところが 3)の部分。

内容はさらりと書いているが、実際はちょっと工夫をしている(はず)

まず、記事URLを取得→ このURL過去投稿されているURLかチェック。

投稿していないURLなら、記事元へアクセス。本文の内容を取得する。

(この記事本文の取得精度が現段階での課題の一つ)

参考にしたのがこちらのクラス

http://neoinspire.net/archives/60

本人が言ってる通り、精度は7割程度の感じはする。

さらに、テキストだけだと味気ないので、googlenewsの検索結果で画像

載っていれば、画像投稿するようにした。

また、同じ内容のニュースでも配信元が違うと重複して記事投稿されてしまうが、

これは前述の通り、本文の取得クラスの精度が7割程度なので、重複させる事により

精度がUPするのではないか?と考えて特に何もしていない。

配信元が違うと同じニュースでも微妙ニュアンスが違う場合もあるので、それはそれで比較する際に

役立つかな?と思っている。

ワードプレスプラグインで購読機能を付けているので、何かニュース投稿される度に

自分メールアドレスに通知されるので、たまに役立つ時がある。

しかし、前述の通り、同じ内容で違う配信先の記事が連投されるので、あーまたこれか。。。 と思う事の方が多い。


まとめとしては、今回使ったものは以下の通り

Google NEWS検索

・MagpieRSS

ブログから本文を取得するクラス

WordPressと各種プラグイン

XML-RPCXML-RPCを使ってWordPress投稿する)

Google Apps Script


MagpieRSSインストールとか大変だったはずだけどもう忘れてしまった。

一度インストールすればこれ以上快適な環境はないので、一度苦労してでもインストールすると良いと思う。


作成したサイトがこちら

http://www.fuzokunews.net/

2015-09-27

Chromebookの使い心地

Chromebookレビュー記事を読んで、同じ機種を買ってほぼ同じ感想を持っている人がいるのだと思った。

http://dragoner-jp.blogspot.jp/2015/09/chromebook.html

購入価格、箱破損品の注記について

自分Asus Outletで、C200MAが14800円で売られている時に買った。箱が破損しているという注記があったが、届いたものは箱に傷ひとつなかった。たんに定価では売れなかったので、あたか瑕疵があるかのように書いているのだろうか。


使い心地

上記レビューに同じ。気軽でよい。テキスト入力機としてはこれで十分。

ちなみにタッチパッドの出来はかなりよい。Macbook Airより少し劣るが、慣れると、それほど変わらない。というか、かなり意識してMBAの使い心地に似せてある。

キーボード打鍵感が浅く、カチャカチャとプラスチック音がするが、打ちづらいというほどでもない。

液晶視野角は値段相応

実用

テキスト入力を含む事務作業程度ならとくに問題ない。2週間以上、Macbook Airを使わないでChromebookだけで生活しているが、それほど困ることはない。

バッテリの持ちは、よい。


開発用機としての実用

よくわからない。Sublime Textに似たZedというエディタChromeアプリとして入れているが、簡単なHTML編集程度であれば、これで事足りている。


最大の問題

オフライン環境で、なにかの拍子で再起動すると、まったく使えない。ログインすらできない。

Google Appsを使っていて、途中でネット接続が切れると、ローカルデータを保存する形で作業は継続できる。

しかし、何かの拍子で再起動がかかると、ログインができないので、いっさい使えない。ゲストとしてログインした場合、素のChromeが立ち上がるだけなので、Google Drive上の作業データはおろかアプリもいっさいない。

これを打開するためにUbuntuを入れてみたが、後述の理由で、それほど状況は変わらない。

その他の懸念

SDカードをさして逐一作業データを保存するのでなければ、原則として、作業データはすべてGoogle Driveに置かれる。

便利だが、アカウントブロックされたり乗っ取られたりした時のリスクは格段に跳ね上がる。


LinuxマシンとしてのC200MAの可能性

カジュアルユーザーには難しい。

以下の記事を参考にして、Chromebookデベロッパーモードを起動し、Croutonというものを入れると、Ubuntu普通に使える。

https://www.linux.com/learn/tutorials/795730-how-to-easily-install-ubuntu-on-chromebook-with-crouton

Asus C200MAのRAMは2GBしかないので、ちょっとでも動作が軽くなるかと思ってUnityの代わりにLXDEを入れているが、ちょっとましだという程度。

Crouton経由でUbuntuを使うやり方だと、起動時に、ChromeOSにかえてUbuntuを選ぶことができない。したがって、オフライン環境下でUbuntuを急きょ使う、という使い方はできない。

デベロッパーモードだとChromebookUSBブートONにできるはずだが、C200MAではできなかった。なので、インストールせずにUSBブートLinuxを使うことは、通常のやり方だとできないようになっているらしい。

これは出荷時のBIOS設定で、上記のような使い方をすべて禁止しているらしい。この問題を解決するため、ChromebookBIOSが焼いてあるROMのものを書き換えるスクリプトを公開している人がいる。

https://johnlewis.ie/custom-chromebook-firmware/rom-download/

が、なにかあったときに元に戻す方法を調べるのが面倒なので、自分はまだためしていない。だれかC200MAで試した人がいたら教えてほしい。

2012-10-15

http://anond.hatelabo.jp/20121015120556

エセ脳科学者の共同研究者じゃしょうがない。

目的を達成するために道具(Google apps)を使うのに

道具にこだわりすぎて、目的を忘れるアホ。

道具なんてなんでもいいか

さっさと作り慣れたアプリ使ってシステム構築すればいいのに。

2011-08-17

はてな

http://togetter.com/li/173305

から、そのコミュニティの異様な特性からはてな村」なんて呼ばれているが、2chが板ごとに全然違う文化があるように、サービスごとにユーザーの特性が違う。だからはてな村」というよりも「はてな郡」とよぶほうが実態に正しい。決してはてな州やはてな国でないのは、そこまでユーザーが多くないからだ。

#適宜追記修正しま

#リクエストを受けて色々追記。

はてなダイアリー

一応はてな郡の中心地。アメーバアメブロ市やライブドアライブドアブログ市やFC2FC2市に比べて人口も少なく、セレブ芸能人有名人)も少ないが、ブログ創世記から有る古都のため、技術ギーク系・ネット文化系社会科学系などで独特な文化を形成する。はてな郡の他の都市に比べやや教育レベルは高め。id:aurelianoid:Chikirinid:finalventなど一般人アルファブロガー化しやすい一方で、森見登美彦平野啓一郎博多華丸・大吉笑福亭鶴光の公式ブログがあることは意外と知られていない。著名人でここの市民っぽくらしく振舞っているのはid:FUKAMACHIとかid:kawangoドワンゴ州知事)ぐらい。ライブドア市やFC2市と違いスラム街2chまとめブログ)や風俗街(エログ)は殆ど無いため治安は良い。ただしまれに放火魔炎上マーケティング)がいる。

はてなキーワード

はてダ市の行政区。開設当初は喧嘩暴動炎上)や落書きが頻発しはてダ市の治安悪化の原因だったが現在は割と平和Google合衆国からはてダ市への訪問者を増やしている。Wikipedia国と競合するが、教育レベルは遠く及ばない。一時期はネット用語流行最先端であったが、近年は衰退している。近年ドワンゴニコニコ大百科町とも競合する。

はてなブックマーク市。

はてな郡最大の都市で玄関口ライブドアクリップ市やヤフーブックマーク市よりも人口が多く、delicious市やGoogleブックマーク市に迫る。かつてははてダ市と同じような人口形成と文化だったが、人口の急激な流入により治安が悪化しており、教育レベルも低め。風俗街(エロホッテントリ)、スラム街2chまとめブログ)や、ゲバルト政治関連)や暴動炎上)も有り、Twitter国と同じような問題を抱えている。

はてなブックマークニュース

はてブ市の行政区はてブ市内の流行が集まりGoogleニュース市やライブドアニュース市へ繋がる。基本的に住人ははてな郡の役人はてなスタッフ)。

人力検索

はてな郡最古の都市だが、近年Yahoo知恵袋市やOKWave市への人口流出が目立ち衰退している。最近税金が安くなった(無料化)の影響かうごメモから人口流入が目立つ。

増田町

はてな郡の中ではやや特殊な位置付け。はてダ市・はてブ市のベッドタウンであるが住民が偽名・匿名で生活している。そのため人口も不明。強いて言えば2ch国に近いが、人口も少なく地区割りも曖昧で住民の傾向もバラバラ。住民は匿名が前提のはずだが、閲覧者を集める目的で敢えて実名で生活するものもいる。

ハイク

はてな郡の中ではのどかで田園風景が広がる。ここもはてダ市・はてブ市のベッドタウン絵描きイラストキーワード)や芸人ネタキーワード)やカフェ(実況)も多く、人口の割には賑やか。近年うごメモからの若い居住者もいる。女性も多い。Twitter国と似ていると言われるが別物である

うごメモ

任天堂王国との連携京都連合)により人口が増えている村。ハイク村・人力検索町以外のはてな郡の都市への人口移動は少ない。この村だけ突出して住民の平均年齢が低い。

フォトライフ

はてダ市・ハイク村のベッドタウン写真家が多く住んでいたが、最近はもっぱらアトリエという名の倉庫街となっている。

はてなグループ

インフラが整ったオフィス街だが過疎化がすすみ空きオフィスが目立つ。オフィス街なのに村。Google Apps市と比べるまでもない。

はてなアンテナ

人力検索町と並ぶ古都で、かつてははてな郡の中心都市の一つであったが近年過疎化がすすむ。

はてなココ

ハイクから独立したハイク2村から更に分離独立した村。モバイラー向けの今風なコミュニティの割にいまいち地味な存在

モノリス商店街

住民が買ったものを並べて売る商店街モバイラー向けの今風なコミュニティの割にいまいち地味な存在

はてなアイデア自治区

はてな郡の自治体運営に唯一提言が出来る機関として設置されるが、基本的に不具合修正以外の要望はあまり通らない。

はてなポイント

はてな郡内の通貨。1P=1円だが基本的にポイントから円の両替はできない。はてな郡内での買い物や住民同士の送金に使われる。

はてなスター

はてな郡内の贈答品。基本的に黄色だが他の色のものは珍しく送ると喜ばれるが、貰ってもなにか有るわけではない。地区によって価値が違う。

はてなラボ特区

はてな郡の役人により設置された実験区。増田町も本来ここなのだが、近年人口増加により特区的位置づけが薄れてきている。増田町以外の地域過疎化がすすむ。

大字はてなボトル

はてな郡にしては珍しくカラフルで派手な地域

大字はてなコピィ

現代芸術家コピーライターが居住。

大字はてなニュース

フリージャーナリストが居住。

廃村

はてなランド

本格的な「こどもの国」として設立されたが、治安悪化しかリアルでも)が懸念され設立からわずか2週間で廃村。はてな郡の黒歴史の一つである

RSS

アンテナ町に変わり新興住宅地として開発されたが、人口減少により廃町。

はてなワールド

セカンドライフ国に対抗すべくハイテクヴァーチャル都市として開発されたが、人口が思うように伸びずラボ特区の一時自治区格下げ。その後廃村。セカンドライフ国も規模的には市レベル(町レベル?)であるアメーバ州のアメーバピグ村は人口が増えつつある。

Rimo

Youtube国への玄関口であったが、行政機能の停止により廃村。

おまけ

2010-04-14

会社が「クラウド」に取り組み始めた時の平和適当なかわし方


ダイヤモンドオンラインの下記記事を無断転用しています。

ツイッター信者」にその素晴らしさを熱く語られたときの平和適当なかわし方|石原壮一郎「大人のネットマナー教室

http://diamond.jp/articles/-/7884


-----------------------------------------------------------------------------------------------


クラウドほど、経営層の人と現場の人との温度差が激しいIT用語はないと言えるでしょう。


経営層やCIOの人の中には、「クラウドの素晴らしいビジネスチャンスをもっとうちにも取り入れなければ!」という危機感を抱いて、

ことあるごとに現場の人への啓蒙活動に励もうとする“信者”が少なくありません。


その博愛の気持ちは尊いといえば尊いのですが、現場の人がさほどクラウドによるビジネスメリットを感じない場合は、

どう対処していいのか困ります。今日も全国各地で、クラウド信者経営層の熱い講釈を受けて、

尻を叩かれる現場の側が苦笑いを浮かべているという構図が繰り広げられていることでしょう。


自社がクラウド事業に参入することにさほどメリットを感じない側のあなたが、そういう災難にあったときはどう対処すればいいのか。

信者の勧誘に対する平和適当なかわし方を考えてみましょう。



クラウド様」を否定するのは危険

程度の差こそあれ、クラウドを熱く勧めたがる信者のみなさんは、「クラウドによってもたらされる新たなビジネスチャンス」を信じ、

そんなクラウドの知見を人より早く深めていることに、ちょっぴり優越感を抱いていると言えるでしょう。

どう見ても熱が入りすぎている人の中には、クラウドに過大な望みを託して、

いまいち不本意な会社の現状から自分達を救い出してくれる救世主のように見ているように思えるケースもあります。


いや、あくまで極端な例をあげているだけなので、「俺は違う!」とムキにならないでください。

もちろん、私の周囲のクラウド好きの経営層やCIO上司に対して、私がそういう目を向けているわけでもありません。


今後の人間関係考慮した言い訳で話がそれましたが、クラウドを熱く勧めてくる人にとって、

クラウドはまっていることが誇りであることは確か。何はさておき、そこを見逃さないようにしましょう。


たとえば、最近クラウドはまっている経営層や上司に、「うちも取組んだほうがいいだろう」と熱心に勧められたとします。

自分会社クラウド事業に参入する必要性を説かれても、いまいちピンと来ないからといって、


「うーん、よくわかんないですねえ。コアコンピタンスシステムをみんなが勝手リソースを食い合いしている共用環境に置くなんて

なんか気持ち悪い世界のようにも思えるんですが」

「柔軟にリソースを拡充できるっていっても、ハードを跨って分散処理できるシステムならともかく、

結局リソースプ-ルの上限内の話ですよね。なんか嘘っぽいですね」


などと、偉大なる「クラウド様」の仕組みを否定する言い方をしてしまうのは危険すぎます。


ムキになってさらに熱く語ってくるぐらいならまだしも、「ハァ~」と深いため息をつきながら、

救いがたいダメ社員を見るような目を向けてくるかもしれません。


まあ、わかり合えなくてもべつにいいといえばいいんですけど、経営層や上司に悪い感情を抱かれたり、

異動のきっかけになるのは避けたいところです。

向こうだって、今の時期たまたまクラウドはまっているだけで、けっして悪気があるわけじゃないし、

SOAのことを忘れてしまったわけでも、人間として何かを失ってしまったわけでもありません。


一生懸命クラウドの魅力を語ってくれたら、たとえピンと来なくても、


「なるほど、そういうふうにインフラ環境意識せずにインターネットでつながるっていうのも、ユニークな考え方ですね」


と、独自性に衝撃を受けたかのような反応をしておくのが、大人の包容力であり相手をそれなりに満足させるマナーです。

そういうふうに言えば喜ぶのはわかっていても、まるでその相手までホメるみたいで抵抗がある場合は、質問に逃げましょう。


仮想化によるサーバ統合とか、ホスティングとか、WEB2.0とか、データセンターアウトソーシングするのとはどう違うんですか?」


と、クラウドの旧称を持ち出してきて、クラウドの優位性をさらに語らせるもよし、


「なんか利用分だけ請求する従量制課金にして、結果、利益率の低くなるのをスケールメリットで吸収しないといけないんですよね?」


そんな歪んだ先入観丸出しの誤解(じゃないけどな)をわざとぶつけて、ひとしきり説明させるもよし。

いずれにせよ、無理無理と思っている気持ちを覆い隠したまま、相手にそれなりの満足を覚えてもらうことができます。



はまりっぷりを批判するのはもっと危険


まったくクラウドに興味がないわけではなく、ちょっと前に自社製品をSaaSASP化してやってみたけど、

全然受注できなくて放置してあるケースも、けっこう多そうです。


そういう状態にあるあなたに、はまっている上司経営層が例によって熱い口調で、


「まずは、機能限定の無償版をいろんなユーザーに提供してみると、フリーミアムの凄さがわかるよ」

「何でもいいからどんどん無償提供すれば、そのうち有償版にアップグレードする客がでてきて利益がでるよ」


フリーミアム教、じゃなかった、クラウド教、じゃなかった、クラウド界における定番の説得フレーズを説いてきたとします。


「ほお、そうなんですね。今期の研究課題として取組んでみます」


適当に納得しておくのはいいとして、つい勢いで、


「しかし、ずっぽりはまってますねー。クラウドの話をするときは生き生きされてますし」


などと冷やかしてしまわないように気をつけましょう。

はまっている上司経営層は、誇らしさの裏側に、多くは無自覚にですけど、


「自社の戦略に自信がなくてクラウドにすがっているように見えるんじゃないか」

競争力が欠如した製品クラウドの冠で紛らわそうとしているように見えるんじゃないか」


といった不安を抱えています。

何気ない冷やかしが引き金になって、心の奥の地雷を踏んでしまいかねません。


そこまでややこしい話じゃなくても、はまりっぷりを感心するセリフの裏側に、


「よっぽどヒマなんだな」

会社現実見ろよ」

「丸投げばっかりで、手動かしてるの外注ばっかりで、Hello Worldぐらいしかプログラム作れないうちの生産部隊が

どうやってフレームワーク備えたPaaSなんか構築するんだよ」


というつぶやきの気配を勝手に察知してしまいがち。


なんせ今までビジネスセンスではなく社内の空気を読む根回しセンスで出世してきた経営層や上司だけに、

社員の心のつぶやきに対してもきっと敏感です。

仮にビジネスセンスのないことに対してカケラも自覚がなかったとしても

カケラも思っていないケースは稀ですがビジネスセンスがないことは稀ではないでしょう)、

相手はそう受け取るでしょう。


はまりっぷりに対しては、ひたすら、


「うちも早くクラウドサービス始めたいですねえ」


と前向きな返事をすることが無難であり、相手に対する大人のやさしさ。単なるおためごかしではなく、

そのセリフを聞いたときの上司の満足そうな表情を見ることで、社畜としての深い喜びも味わえるでしょう。


クラウドをきっかけに相手と仲良くなる方法


仮に、クラウドの話題をきっかけに経営層や上司との距離を縮めたいなら、その場の口先だけではなく、次に顔を合わせたときに、


「あれから、SalesForceとかGoogle AppsとかAzureとかAmazon WSとか、試験導入してPythonJavaHello World作ってみましたよ」


と具体的な実績を話せばバッチリです。

熱く勧めてきた上司経営層が、特に自分の進級昇格を左右する人物だったりした場合は、

とりあえず勧められたとおりにやってみて、クラウドの魔力に魅せられたフリをしましょう。


「やってみると使えますねー。勧めてもらってよかったです」


とまで言っておけば、さらに完璧

たとえ動機が不純でも、それをきっかけに部内から企画をあげたという実績ができればこっちのものだし、

上司としてはこの上ない喜びを……おっと、結局、経営層へのご機嫌取りという本音が出てしまいました。




曖昧な立場で書いてきましたが、私は何を隠そう、嫌々クラウド事業に取組んでいる社畜のひとりです。


この記事は、いまいち熱くなれない己の愚痴であり、

スケールメリットなんか出せねえんだから競争力ある価格設定なんか無理、

無理矢理仮想化しなくても安いサーバで提供すりゃいいんじゃねーの?

そもそも高い人件費プロパー使ってレンタルサーバ屋と競争してどうすんのよ?

とかいう会社じゃ言えない本音に悶々としながら、仕事中にこっそり書かせていただきました。


そんなことを踏まえつつ、それぞれの立場や環境に応じてお役立ていただければ幸いです。



                   ※

次回も、引き続きクラウドテーマにしてみたいと思います。(嘘)

今期の事業戦略などで、「クラウド事業への取組み」なんつーキーワードが出始めた場合対処法や、

自分に企画立案を振られた場合の振る舞い方について考えてみましょう。


■今回のマナー

クラウド信者」が抱える誇らしさと不安――その両方を見逃すべからず






全然かわせてねー!なんか立案しないとマズい

明日から本気出す

2009-11-09

http://anond.hatelabo.jp/20091109144954

短い期間、無料ドメイン登録したいのなら、co.ccおすすめ

http://www.co.cc/

厳密にいうと、サブドメインなんだが、お試しにはいいかもしれない。

Google Appsと組み合わせると自分サブドメイン無料メールアドレスを作れる。

参考

http://www.cronousbrain.com/blog/?p=838

2009-08-31

クラウドデータを預けたい

うちの会社よりはGoogleのほうが信用できる。

会社IDだとメールIM社長に筒抜けだし、電話IP-PBXなんで全部聞かれてるかも。

Googleのmailとtalkを使ったほうがよっぽど安心。電話は、個人携帯Google voiceで。

木を隠すなら森の中っていうし。しかも、社長から見えない遠い森。

Google Appsがんばれ。

2008-12-17

[][]アカウントデータ削除できないっすよ。

あぁーなるほど、全般的にそういうポリシーなのね。

あー、なーるほーど、ねー。ギークに乗っ取られてる会社っていう意味が分かったわ。

2007-04-08

Google Apps(Remember The Milk) VS サイボウズ(cybozu) 4776.t

スケジュール管理・日報・業務報告・顧客管理

グーグルスプレッドシートによる業務報告が便利すぎる

コピペでOK!Googleフォームで送信された内容をメールで自動通知してくれるスクリプトと設定方法を公開します

google spreadsheet で簡単データベース 名簿を管理しよう! - YouTube

スプレッドシート サイズ: 最大 200 万セル。

Google カレンダー

Google サイト - ビジネスに社内ポータル・ホームページ作成

Google CalendarにRemember The Milkのタスクを表示する2種類の方法を理解する - Forgot the Milk.

Google フォーム - アンケートを無料で作成、分析できます。

Windowsシステム管理者のためのGoogle Apps入門:第2回 無償版GmailとGoogle Apps for Businessの違いを知る (1/2) - @IT

Google Apps for Business - Google のパワフルなツールをあなたのビジネスに

シンプルで明快な料金プラン - Google Apps for Work

ドライブ ストレージ

サイボウズ Office - サービス | サイボウズ クラウドサービス「cybozu.com(サイボウズドットコム)」

価格・オプション | ファストシステムを実現したクラウドサービス「kintone」

.

コモディティ化 - Wikipedia

破壊的技術 - Wikipedia

[全体最適][ボトルネック][仕組み]

ニュース - 「こんなもの、おもちゃだ」と批判されるのが破壊的イノベーション:ITpro

スタートアップの始め方

テクノロジーの世界では、常にローエンドがハイエンドを食っている。

安価な製品をより強力にするほうが、強力な製品を安くするよりも簡単なのだ。

だから安価でシンプルというところから始めた製品は徐々に強力なものへと成長していき、水が部屋に満ちるように、

ハイエンド」の製品を天井の方へと押し込めることになる。

Sunはこれをメインフレームに対して行い、IntelはSunに対して行っている。

イノベーションのジレンマ - Wikipedia

Google Apps for Businessの利用企業数は全世界で500万社

ANAがGoogle Appsを採用、4万9000IDの契約で日本最大規模のユーザーに

サイボウズ、クラウドサービス「cybozu.com」ご契約社数が5000社を突破

米Google、情報共有サイト作成サービス「Google Sites」を発表

誰でも簡単に編集を始められるように、

5種類のテンプレート(Webページ、ブログ、ファイル共有、ダッシュボード、リスト)を用意。

企業が部内プロジェクトを遂行したり、

学校行事や宿題の共同作業を行なうためのサイトなどを簡単に作ることができる。

 Google Sitesは、Google Appsに統合されているため、

Google Docs」「Google Calendar」「Picasa」「YouTube」など、

Googleの他のサービスで利用しているコンテンツも簡単に埋め込むことができる。

また、動画や画像、Microsoft Officeファイルなどをアップロードして、

グループ内で共有することも簡単にできる。


Google Apps Google カレンダー Gmail TODO リスト ゲームもできる!iGoogleの使い方!(Googleパーソナライズド・ホームページ)


Move rows and columns - Docs editors Help

もっと便利にGoogleカレンダーを使う7つのTips - ITmedia エンタープライズ

一度設定した予定はドラッグドロップで移動ができる。

「11時から会議」の予定を入力する時、11時のセルをクリックしてはいないだろうか。

実はGoogleカレンダーでは適当にクリックして、簡易入力の吹き出しに「11時に会議」と入力すれば時間を自動的に調整してくれる。

Google Calendar

オンラインサービスなのに、オフラインでも操作できる

Googleカレンダーをオフラインで使う 〜同期ソフト一覧〜

Google Gears (ウェブアプリをオフラインで利用可能に) : ワークスタイル・メモ


Google Calendar の使い方 | グーグル・カレンダーの便利な機能や特徴を紹介します

Outlookもサイボウズも窓から投げ捨てよう!

Gmailとの連携でデキルあなたを創る!

話題のAjaxインターフェースサクサク使える次世代型Webスケジューラ「Google Calendar」の使い方!!

デスクトップアプリケーションのように、ドラッグドロップイベント(予定)を移動させることが可能。

Google カレンダー


Ajaxに控えめ対応、「サイボウズ Office 7」が登場 − @IT

Office 7のようにWebブラウザクライアントとするソフトウェアではAjax採用がトレンドだ。

サイボウズもそのトレンドに乗ったといえる。

ただ、青野氏は「Ajaxを使ったドラッグドロップなどは一部の人しか喜ばない」と話し、

メインユーザーの実務的な使い勝手の向上に的を絞って、Ajaxを導入していく考えを示した。


また、一つプロジェクト用のアカウントを取っておいて、

皆でスケジュールを登録し合うというような使い方も可能です。


Gmail英語版はメールからカレンダーへスケジュールが投稿できる(再) | G Mania - グーグルの便利な使い方

Gmailは現在1億アカウント、1日数百万ペースで増加

かつて電力に起こったのと同じことが起ころうとしています。

20世紀初頭には、企業は電力会社の副社長を雇わなければならないと考えたものですが、今は壁にプラグを差せば電気はやってきますよね。

ITも同じです。ビジネススタートするときに、なぜITプロフェッショナルの“大部隊”を雇う必要があるでしょうか。

Gmail


Remember The Milk 


remember the milkに感動

何をする道具か、というと、タスク管理らしい。

やりたいことを書いて、それを管理する道具。期日で並び替えてくれたり、Tagで絞り込めたり、優先度をつけられたり、字数無制限のメモが書き込めたり、一定期間毎にリピート出来たり、「今日が期日」のものをRSSで取得出来たり、時間毎にGoogle talkで話し掛けてくれたりする。


Google CalendarにRemember The Milkのタスクを表示する2種類の方法を理解する - Forgot the Milk.


Stuff the monkey says

ページの一番下の Google Calendar のボタンをクリックするだけで

Google Calendarの中に Remember The Milk のタスクリストが表示されます。

「Remember The Milk」カレンダーを追加


clmemo@aka: Google Calendar に Remember the Milk の ToDo リスト情報を読ませる


慧眼

「ドリルを買う客はドリルが欲しいのではなく穴が欲しいのだ。」

マイクロソフト・ジョークス/先見の迷惑

「将来コンピュータの重量は、1.5トン以下になるかも知れない。」

Popular Mechanics誌、科学の果てしなき進歩を予測して、1949

「恐らく世界中のコンピュータ市場の規模は、5台だろう。」

トーマスワトソン、IBM会長、1943

「家庭にコンピュータを欲しいと思う人などいる訳がない。」

ケン・オルソン、Digital Equipmentの創設者・社長・会長、1977

「石油を掘るだって? 地面にドリルで穴を開けて、石油を探すっていうのかい? あんた頭がおかしいよ。」

エドウィンドレイクが、石油採掘プロジェクトに協力を要請したドリル業者たち


生き残る種とは、

もっとも強いものではない。

もっとも知的なものでもない。それは、

変化にもっともよく適応したものである。

ダーウィン



勝てない提督や卑怯な司令官をすぐさま更迭した米軍 ( 哲学 ) - 仕事の流儀 【哲学編】 - Yahoo!ブログ

ザ・ゴール ― 企業の究極の目的とは何か | エリヤフ・ゴールドラット, 三本木 亮 | 本 | Amazon.co.jp

最小の努力で最大の効果を得るには、全体最適が常に優先されるべきである。

正しい仕事は何かが正しく定義され、評価されなければ、誰も正しい仕事などするはずがない。

会社に損失を与えてきたのは、人間が正しい仕事を行わない「仕組み」をつくりあげた会社組織そのものである。

ゴールドラット博士


サイボウズ・ラボ

KFS(Key Factors for Success)

Amazon.co.jp: 企業参謀―戦略的思考とはなにか: 本: 大前 研一

「物事には、その結果に影響を与える主要因というのがかならずいくつか存在する。

これらをうまく管理あるいは応用すれば戦略が成功する」

「戦略思考家とは、みずからの担当する職務(役職、業種、業務)において、

つねにKFSがなんであるかという認識を忘れない人のことであろう。

そして、彼は全面戦争ではなく、

KFSに対する限定戦争に”挑戦的”に挑むのである。」


http://bitsized.wordpress.com/2007/12/25/saas%E3%81%A8%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E5%B1%8B%E3%81%95%E3%82%93/

インストーラブル・ソフトウェアを作るとすると、

多大なお金と時間をテクニカルサポートに費やし、より多くのドキュメントを作成し、開発スピードを遅らせ、

そして最終的には私達のアプリケーションカスタマーエクスペリエンス

うまくコントロールできなくなってしまうでしょう。

Webベースのソフトウェアは顧客側の作業を必要とせず、たちどころにすべての顧客に対してアップデートを行うことができます。



組織も人も最適化の果てにあるのは緩やかな死 | @masuidrive blog

http://wordpress.rauru-block.org/index.php/1587

Google にとってユーザの PC はブラウザさえ動けばよい。

Google にアクセスしさえすれば、メールもカレンダーも表計算アプリケーション

全てサーバ上で動いてブラウザ上に表示される。

ユーザが自分のPC上にアプリケーション

インストールしたりアップグレードしたりといったPC管理の必要はほとんど無くなる。



http://satoshi.blogs.com/life/2007/09/post-8.html

1. サイレント・マジョリティの声は聞こえてこない

 これはMicrosoftで実際にあったことだが、

Outlookのチームではユーザーから寄せられる機能追加のリクエストに従って色々な機能を足していた時期があったが、

その結果不必要な機能ばかり増えて、単純な作業が逆にやりにくくなってしまった(たとえばカスタム・フォームが良い例)。



http://www.chikawatanabe.com/blog/2007/05/flickrcaterina_.html

ユーザーは既にある機能をもっと欲しがるだけなので、新機能をどうしたらよいかをユーザーに聞くのは不毛。

それより、既に計画中の機能を複数ユーザーに投げて、どれが優先順位が高いかを聞くのがよい。



「Ajaxを使ったドラッグ&ドロップなどは一部の人しか喜ばない」

Evernoteを苦しめる「5%問題」は本当に取り組むべきことを照らす道しるべになる - GIGAZINE

Google Calendarはサイボウズにとって悪夢か追い風か?:Speed Feed:オルタナティブ・ブログ

正直なところサイボウズとしてはあまり気にする必要が無い。

Googleはいまだファイアウォールを越えて、企業システムには入り込んだ実績がほとんどないし、

これからもそれは彼らにとって高すぎる壁になると僕は思っている。


サイボウズの場合どのようなシナリオを想定するかといえば、やはり

「無料のグループウエア ASP の登場」です。

しかしこれは二つの側面から見て、サイボウズに対して直接的な影響を及ぼす可能性は低いと個人的には見ています。

Google Calendar


http://blog.cybozu.co.jp/aono/2006/04/google_calendar.html

Google Calendar は、サイボウズが提供したい価値とは違うように感じました。

私たちが提供したい価値は、情報共有による知の創造であり、誰でも使える大衆化であり、チームワークの醸成です。

私たちは、私たちなりのアプローチで、世界に価値を提供していきたいと思います。


http://blog.cybozu.co.jp/aono/2007/09/post_c821.html

今後、新たな破壊的イノベーションによって、私たちサイボウズ存在意義を失う恐れがあります。

私たちも、時代に合わせて変化していかなければなりません。



[k] kam.iokan.de: Googleカレンダーから始まる?イントラネット2.0

サイボウズイントラネット1.0)にGoogleカレンダーウェブ2.0

一方でサイボウズからすれば、Googleの破壊的な活動の1つGoogle Apps for Your Domainの動向も気にしているはずですだったりもします。

(おそらく、サイボウズを導入している企業でGoogle Apps...に乗り換える企業は少なく、直接競合することはないんじゃないかと考えてますが)

Google Calendar


ちぎっては投げ:ドリコム 下方修正 - livedoor Blog(ブログ)

会社に必要なのは

共有フォルダ

電子メール

スケジュール機能を備えたグループウェア

あれば事足りるわけで。

大きな企業だと

掲示板や

ワークフロー

ほしくはなるけど、

社内ブログ/社内SNSはそれよりも優先度低いと思う。

何しろなくても仕事できるし、そういうものがあることで、

逆に生産性落としそうだし。

つまり、サイボウズは成功するでしょうが


Gmailは現在1億アカウント、1日数百万ペースで増加

かつて電力に起こったのと同じことが起ころうとしています。

20世紀初頭には、企業は電力会社の副社長を雇わなければならないと考えたものですが、今は壁にプラグを差せば電気はやってきますよね。

ITも同じです。ビジネススタートするときに、なぜITプロフェッショナルの“大部隊”を雇う必要があるでしょうか。

Gmailの容量が最大250GBまで拡張可能に、実際に増やしてみた

はてなブックマーク - Google カレンダーは113台のサーバで動いている - GIGAZINE

Gmail同士でPOPアクセスする方法

Gmail同士で外部POP(Mail Fetcher)でメールを取り込む裏技

Gmail⇔Google Apps 間の移行やGmailバックアップに!

基本的にGmailも、Google Appsも同じ操作性になっているので、相互のメールの移行に便利です。この機会にGoogle Apps(有料版もあり)へメールを統合するのも良いかもしれません。

 先日Google Appsに対応した日本大学東京女子大学嘉悦大学リアルコムに入る人、

au oneメール利用者、新Livedoorメール利用者などは、自分のGmailデータをひっさげて簡単に移行できる事になります。

その逆もしかり。

 また、いざアカウントが消失した時のバックアップとして別のアカウントに溜め込むのもオススメです。

 バックアップに関しては、送信済みメールも受信されるので便利。


グーグル、日本大学にGoogle Appsを提供--50万人規模での利用も検討 - CNET Japan

Google Apps Education Editionは教育関係者向けの無償サービス

最終的には卒業生を含め約50万人へのサービス提供

2.0の世界に挑んだ人と組織 - 無料でも可用性は低くない:ITpro

大学のOB/OGなど50万人

[N] 日本大学が「Google Apps Education Edition」採用

Gmailの時代到来? - これでも大学職員のブログ

魅力はなんといっても「2GB以上」の大容量です。

また、情報センターの視点で見ると大学の計画停電などに左右されないのも魅力です。そして何より無料!

両校のログイン画面を見ると、非常に似ています。

 ●日本大学Gmail  ●東京女子大学Gmail

どうやら日本大学に続いてGoogle Appsを導入する大学が現れたらしい - Clear Consideration(大学職員の教育分析)

ネットワークリプレイスに関するお知らせ(出典:嘉悦大学 2007/08/20)

●嘉悦大学Gmail

Google Apps

Google Apps Education Edition は、無料のコミュニケーション/コラボレーション ツールと

学校ドメインのメール アカウント (student@your-school.edu など) を提供


ピクサーが社内システムを「Google Apps for Your Domain」に乗り換え - GIGAZINE

トップページ

Google Apps Premer Editionを迎え撃つ必要がなくなったことに安堵する。:Speed Feed:オルタナティブ・ブログ

Google Apps Premer Editionが登場したことで、

Web型グループウェアおよび法人向メールサーバーの提供企業は、かなり深刻なダメージを受けることは間違いない。

MSエクスチェンジやノーツのように業務システムに深く食い込むシステムであれば別だが、

多くのベンチャー中小企業にとって、グループウェアやメールシステムはライトなもので十分だし、

日本版SOX法の施行が目前である以上、社内にサーバーをおいて管理する必要のないSaaSモデルはやはり都合がいい。


Gmail、カレンダーをSaaS形式で--Google Apps製品版、日本の料金は年間6300円/人に - ZDNet Japan

editions.html - www 無料 or 年額6300円/ユーザ

Standard Edition & Premier Edition

iGoogleにYahoo!も表示できる!好きなページをタブいっぱいに表示するガジェット「Your Page Here」 | G Mania - グーグルの便利な使い方

例えば、

Googleカレンダーを表示してもいいし(iGoogle用のミニカレンダーでは物足りないですね)、

Yahooカレンダーを表示してもいいし(Google以外でもOK!)、使い道は無限大です。

Google Readerを表示

LivedoorReaderを表示

デフォルトではGoogleカレンダーが設定されています。

別のページを表示させるには、タブ右側の矢印をクリックして、「設定を編集」を選択します。

Google

【iGoogle】 任意のページを追加するガジェット 「Your Page Here」: ぴっくあっぷ。

Google Apps グーグル アプリ

Google Google Picasa からの移行

Blogger

ブログの投稿ユーザー 1 人のユーザーがこのブログに投稿できます  投稿ユーザーを追加

ブログの閲覧ユーザー すべてのユーザー  選択したユーザーのみ  ブログの投稿者のみ

  Google Packに「更新無料」のセキュリティツールが追加 - ITmedia ニュース

Sign in - Google Accounts

Gmail (メール) Gmail

Google トーク 

Google カレンダー https://www.google.com/calendar/render Google Calendar

Docs (ワープロ) & Spreadsheets (表計算) Redirecting...

Google Apps for Work - Google のクラウド型グループウェア  無料

Google Apps

www

editions.html - www 無料 or 年額6300円/ユーザ

Standard Edition & Premier Edition

Google Apps for Your Domain を使ってみました! : サインアップ編 - WebOS Goodies

Google Apps for Your Domain を使ってみました! : 管理機能編 - WebOS Goodies

Google カレンダー

test カレンダー

Google Calendar

今日から始める「Google カレンダー」特集(前編)

はてなブックマーク - 今日から始める「Google カレンダー」特集(前編)

予定をドラッグで移動できるのは偶然気づいた。びっくり。

Google Calendar

Google Calendar

日本の祝日 アメリカ合衆国の祝日


もっと便利にGoogleカレンダーを使う7つのTips - ITmedia エンタープライズ

一度設定した予定はドラッグドロップで移動ができる。

「11時から会議」の予定を入力する時、11時のセルをクリックしてはいないだろうか。

実はGoogleカレンダーでは適当にクリックして、簡易入力の吹き出しに「11時に会議」と入力すれば時間を自動的に調整してくれる。

オンラインサービスなのに、オフラインでも操作できる

Google Calendar


日本語化されたGoogleカレンダーを使ってみました - ITmedia エンタープライズ

ログイン方法

カレンダーの入力方法

公開カレンダーの参照方法

Google Calendar


今日から始める「Google カレンダー」特集(後編)

スケジュールごと共有設定が可能。出欠確認やコメント機能も

 Google カレンダーの共有機能は大きく分けて2つある。

1つはカレンダーに登録されたスケジュールごと個別に共有する機能、

もう1つはカレンダーごと共有する機能だ。

また、共有とは少し異なるが、スケジュールの内容をインターネットやブログに公開できる機能も備えている。

ユーザーごとにカレンダーを共有する場合は、空き時間もしくは予定の詳細を閲覧させるだけでなく、

カレンダーの編集権や、さらに他のユーザーと共有する権利を与えることも可能。

1つのカレンダーに対して、複数のユーザーが同等に編集し、その結果をそれぞれのカレンダーに反映することが可能だ。

Google Calendar


Google Calendar の使い方 | グーグル・カレンダーの便利な機能や特徴を紹介します

Outlookもサイボウズも窓から投げ捨てよう!

Gmailとの連携でデキルあなたを創る!

話題のAjaxインターフェースサクサク使える次世代型Webスケジューラ「Google Calendar」の使い方!!

一日の予定を指定時間にメールで送信することができる。

⇒ リマインダーとの組み合わせで予定を忘れることも皆無。

イベントに登録できるのはイベント名、日時、場所、詳細情報。さらにコメントを書いたり招待状を送ったり。

イベントの招待状をメールで送信できる。

⇒ 参加・不参加の回答は招待状のリンクをクリックするだけ(Gmail、Google Calendarユーザーでなくても可能)。招待状への回答もGoogle Calendarで確認できる。イベント主催者の強力な味方!

Google Calendar


Googleカレンダーをもっと便利に使うための13のツール&Tips | POP*POP

天気予報アイコンを表示する

GoogleカレンダーでToDoリストを管理する

ブログ上で予定を確認する

Google Calendar


Googleカレンダーのリマインダー機能を活用しよう - ITmedia エンタープライズ

携帯電話で受け取るには

多様な通知機能がGoogleカレンダーの特徴の1つだが、

携帯電話向けの通知機能はデフォルトで無効になっている。

携帯電話メールアドレス向けの通知機能を有効にするには、

「国名(デフォルトで日本になっている)」「ユーザー名」「モバイルメールのドメイン」「確認コード」をそれぞれ入力する必要がある。

Google Calendar


Googleカレンダーを携帯で見る方法:補足 - fixture.jp

カレンダーを公開にしなくても携帯から見ることができる方法を発見。


Googleカレンダーを携帯から完全コントロール!:Gmailer

個人用PIMツールとして、とても評価の高いGoogleカレンダー

直感的に操作できるユーザーフレンドリーインターフェースの完成度は、

もはやGmailの域をも完全に超えてしまっていますね。

そのGoogleカレンダーを携帯から完璧にコントロールできるシステムを発見しましたので、ご紹介したいと思います。

Google Calendar


Googleカレンダーで見るスケジュール管理の方法

あなたは、会社の部下と1時間のミーティングをするとしたら、いつこの予定を入れますか。


Google Calendar を便利に使う 20 の最新 Tips - オンライン快適仕事術

Docs (ワープロ) & Spreadsheets (表計算)


日報

クレーム管理

Excel(エクセル)、Word(ワード)のテンプレート

Excel(エクセル)、Word(ワード)のテンプレート集

「Google Spreadsheets」、順番待ちを避ける裏技は"共有" | マイナビニュース

「閲覧のみ」、「編集を許可」というように相手の権限を設定する。

グループテキストチャットをしながら共同作業を進められる。正に"リアルタイム"コラボレーションである。

このような複数ユーザーによるコラボレーションは、すでにGoogle Calendarで実現しているが、用途はスケジュール管理に限られる。

表計算ソフトならば、スケジュールはもちろん、伝言板、住所録、経費管理など、アイディア次第で様々な目的に利用できる。

Redirecting...

ToDoリスト、スケジュール在庫管理クレーム管理、日報、労務管理、勤怠管理、FAQ、経費管理、予約管理、設備予約、住所録、伝言板、アポイント調整

チャットをしながら作業ができる表計算「Spreadsheets」

「Spreadsheets」の「Formulas」画面。B12~H12のセルをマウスで選択、

画面右上の「Sum」を このエントリーをはてなブックマークに追加ツイートシェア

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