  |
はてなキーワード: Commonsとは
投票率が低いという話を聞くと、「コモンズの悲劇」を思い出す。
コモンズの悲劇（コモンズのひげき、英: Tragedy of the Commons）とは、多数者が利用できる共有資源が乱獲されることによって資源の枯渇を招いてしまうという経済学における法則。
中略
たとえば、共有地（コモンズ）である牧草地に複数の農民が牛を放牧する。農民は利益の最大化を求めてより多くの牛を放牧する。自身の所有地であれば、牛が牧草を食べ尽くさないように数を調整するが、共有地では、自身が牛を増やさないと他の農民が牛を増やしてしまい、自身の取り分が減ってしまうので、牛を無尽蔵に増やし続ける結果になる。こうして農民が共有地を自由に利用する限り、資源である牧草地は荒れ果て、結果としてすべての農民が被害を受けることになる。
——————引用ここまで。
つまり、個人レベルで行動を最適化すると、集団レベルで良い結果にならないことがある、という話だ。
専門的な言い方を許してもらえれば、自然選択とはごく限られた場合を除いて、個体または遺伝子のレベルにかかるものなので、集団にとって有利なことでも、個体にとってコストなら進化し得ない。
投票率の話に戻す。
お金はかからないが、投票先を選んだり、並んだり、時間的なコストは絶対にかかる。
また、重要な点として、このコストは個体レベルにかかっている。
一方で、投票すると言う行為によって得られるメリットは集団レベルのメリットであり、
個体レベルで見たとき、コストをペイできるだけのメリットがあるとは言い難い。
もちろん、ひとりひとりの投票がひとりひとりにとって重要な意味をもつという主張は正しいが、あくまでそれは集団レベルの話。
個体の行動を最適化すると、むしろ投票に行かないことが合理的であるように思う。
---
では、どう改善していくか。
こうした人たちに投票の集団レベルの意義を説いても意味がない。
あくまで個体レベルで議論しないと、聞く耳すらもってくれないだろう。
叩かれることは大きなコスト、それも個体レベルのコストなので、投票に行かないコストが、投票に行くコストを上回り、投票に行く方が合理的になる。
ただ、これには大きな落とし穴がある。嘘をつけばいいのだ。
すなわち最適な行動は、「投票に行かずに、行ったと主張すること」になる。
逆に言えば、嘘をつけないシステムを作ればそれでいい。
ラーメンチェーン店の一風堂は、投票済証明書を提示した人を対象に、替玉一玉もしくは半熟塩玉子をサービスするという「選挙割」をおこなっている。
タピオカドリンクを販売するTapistaでは、ドリンクが半額になる。
意外とこのようなサービスを実施する企業は多いし、増えてきているように思う。
とくに、鉄道や携帯会社など、インフラに近いサービスを提供する企業ほど、こういうことをすると効果的だろう。
実際には、投票に行かない人にもちゃんと周知させる必要があったり、さまざまな問題があるは思うが、個人レベルでのメリットを上げることができれば、投票率は上がる。
---
投票するという行為に伴う個人レベルでのコストと天秤にかけることが重要である。
最後に話は逸れるが、投票率を上げることと、国政を正しく導くことは、必ずしも同義ではないと思う。
そもそも個人の考えと支持者の考えが完全にマッチすることはかなり稀なはずなので、政策ごとに国民の意見を反映できる別のシステムを作るのも重要だ。
語源の楽しみ。家にいて、そこらへんにある言葉を拾うだけでいろいろ考えた気になる。暇なときに最適な楽しみである。
たぶん、それで得られる思索は、ほんとに言語学とかやっている人には当たり前のことなのだろうけど、まあ趣味ですから、許してほしい。逆にそういう専門の人の面白い語源の本もまた好みである。
アメリカ上院はSenate。この語源はラテン語Senatus、すなわちローマの元老院。その単語をそのまんま使っているということに僕は衝撃を受けた。つづりの違いは言語の違いに過ぎないから、たぶんアメリカ人は学校の歴史の授業で、ローマの歴史を学ぶ時とアメリカ合衆国の政治機構について学ぶ時に同じ単語Senateをもとに学習しているわけである。そこに歴史の一貫する深い流れを感じ取ることが、感覚としてあるのではないか。ちなみに下院はHouse of Representativesで、一般名詞で形成されている。
ところで、どうしてこのように名付けたのだろう。
たぶん、アメリカ民主主義が、設立当時はイギリスよりもフランスを継承している意識が強かったことに由来しているのだろう。イギリスは、貴族院と庶民院（下院）であって、それぞれHouse of LordsとHouse of Commons。それに対し、フランス上院と下院は、SénatとAssemblée nationaleであり、上院には同じ単語を使用している。フランス上院のことは日本語訳でも直接的に「元老院」の訳語をあてることもあるようで、Wikipediaはそうしている。単語としては同じなんだからアメリカ上院も時には元老院と呼んでもよさそうだ。
アメリカ上院議員はSenator。オバマ大統領が大統領選を戦っているとき、「Senator Obama」とよく呼ばれていた。
このときこのひびきは通常の日本語訳では「上院議員オバマ」であるが、原語では「元老院議員オバマ」と同じものなわけであり、これはつまり歴史を好むアメリカ人にとっては「元老院議員カエサル」と同じ響きをもって伝わっているのだろう。ここがうらやましい。
明治維新が起きてすぐのころ、明治4年の制度では正院の長は太政大臣であり、三条実美が就いていた。過去の太政大臣と言えば、藤原道長であり、平清盛であり、当然のことながら、豊臣秀吉である。なんで「太政大臣」の名前を廃したのかな、と残念に思うところ。
もちろん、より有名なところ（だが現在には継承されていないもの）として、ドイツ皇帝「カイザー」、ロシア皇帝「ツァーリ」は、それそのものがローマ皇帝または副帝の称号「カエサル」を引き継いでいる。
こういうのを見ると、欧米では歴史が単語レベルで地続きであることが多いのだなと思う。しかしもちろん日本でも、大連（おおむらじ）と大臣（おおおみ）の権力争いの末大臣家が勝ち残ったことが、現在でも内閣の大臣の名称に残っていることなどは、語源から歴史の深みを感じるところではあるのだ。
原文：https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
原題：Apache Commons statement to widespread Java object de-serialisation vulnerability
翻訳日：2015年11月12日（午後にタイトルを日本語にしました）
－－－－
Apache CommonsのJavaオブジェクトのデシリアライゼーション脆弱性に関するステートメント
著者：Bernd Eckenfels（コミッター）, Gary Gregory（Apache Commons副責任者）
AppSecCali2015 でGabriel Lawrence (@gebl) と Chris Frohoff (@frohoff) によって発表された "Marshalling Pickles - how deserializing objects will ruin your day" は、信頼されないソースからシリアル化されたオブジェクトを受け取るときのセキュリティ問題をいくつか明らかにしました。主な発見は、Java オブジェクト・シリアライゼーション（訳注：seriarization／シリアル化／直列化＝ネットワークで送受信できるようにメモリ上のオブジェクトデータをバイト列で吐き出すこと。シリアル化されたJava オブジェクトはRMIなどのリモート通信プロトコルで使用される。）を使用する際に任意のJava関数の実行や操作されたバイトコードの挿入さえもを行う方法の説明です。
Frohoff氏のツールである ysoserial を使って、Foxglove Security社のStephen Breen (@breenmachine) 氏はWebSphereやJBoss、Jenkins、WebLogic、OpenNMSといった様々な製品を調査し、(http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/) に各々の様々な攻撃シナリオを記述しています。
両者の調査活動は、開発者がJavaのオブジェクト・シリアライゼーションに信頼を置きすぎていることを示しています。認証前のシリアル化されていないオブジェクトにも。
Javaにおけるオブジェクトのデシリアライゼーション（訳注：de-serialization／非直列化＝ソフトウェアで扱うことができるように、送受信されたデータを元に戻すこと）が行われるとき、大抵は想定された型にキャストされ、それによって、Javaの厳しい型のシステムが、得られた有効なオブジェクトツリーだけを保証しています。
不幸にも、型のチェックが起こるまでの間に既にプラットホームのコードが生成されて、重要なロジックは実行されてしまっています。そのため、最終的な型がチェックされる前に、開発者のコントロールを離れた多くのコードが様々なオブジェクトの readObject() メソッドを通じて実行されてしまいます。脆弱性のあるアプリケーションのクラスパスから得られるクラスの readObject() メソッドを組み合わせることで、攻撃者は（ローカルのOSのコマンドを実行するRuntime.exec()の呼び出しを含めて）機能を実行することができます。
これに対する最も良い防御は、信頼されていないピア（通信相手）とは複雑なシリアル化プロトコルを使うことを避けることです。ホワイトリストのアプローチ http://www.ibm.com/developerworks/library/se-lookahead/ を実装するように resolveClass をオーバーライドするカスタム版の ObjectInputStream を使うと、影響を制限することができます。しかしながら、これは常にできることではなく、フレームワークやアプリケーションサーバがエンドポイントを提供しているような時にはできません。簡単な修正方法がなく、アプリケーションはクライアント・サーバプロトコルとアーキテクチャを再検討する必要があるため、これはかなり悪いニュースです。
これらのかなり不幸な状況において、エクスプロイトのサンプルが見つかっています。Frohoff氏は、 Groovy ランタイムや Springフレームワーク、 Apache Commons コレクションからのクラスを組み合わせるサンプルのペイロードに gadget chains (ガジェット・チェーン）を見つけています(訳注：provided)。これはこの脆弱性のエクスプロイトのためにより多くのクラスを組み合わせられることは完全に確実なことで、しかし、これらは今日、攻撃者が簡単に得られるチェーンです。
(Twitter画像)https://blogs.apache.org/foundation/mediaresource/ce15e57e-94a4-4d7b-914c-8eb8f026659c
この脆弱性のために利用される(訳注：blamed)ことができない確かな機能を実装するクラスができ、安全性が信用できないコンテキストにおけるシリアル化を利用されないようにするような既知のケースの修正ができたとしても、少なくとも分かったケースだけでも継続的に修正していくことが要求されます。モグラ叩きゲームを始めるだけであるかも知れませんが。実際にはこれは、オリジナルチームが Apache Commons チームに警告が必要だと考えていない理由で、それゆえに比較的、活動開始が遅れました。
Apache Commons チームは InvokerTransformer クラスのでデシリアライゼーションを無効化することによって commons-collection の 3.2 と 4.0 のブランチにおける問題に対処するために、チケット COLLECTION-580(http://svn.apache.org/viewvc/commons/proper/collections/branches/COLLECTIONS_3_2_X/src/java/org/apache/commons/collections/functors/InvokerTransformer.java?r1=1713136&r2=1713307&pathrev=1713307&diff_format=h) を使っています。議論されているやるべきことのアイテムは、変化させる仕組み毎(per-transformer basis)に、プログラマティックに有効にするような機能を提供するかどうかです。
これには前例があります。Oracle と OpenJDK JRE の一部であったり、バイトコードを挿入して実行することを許したりする com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl クラスで、セキュリティマネージャーが定義されているとデシリアライゼーションを拒否します。
これはシステムプロパティ jdk.xml.enableTemplatesImplDeserialization=true とすることで無効にできます。Apache Commons Collection は、本来よりもこの実行モデルは一般化していないため、セキュリティマネージャーの存在と独立したこの機能を無効化することを計画しています。
しかしながら、明確化のために述べておくと、この便利な"ガジェット"は、唯一知られている方法でもなければ、特に未知のものでもありません。そのため、インストールされたものを強化されたバージョンの Apache Commons Collection に置き換えることが、アプリケーションをこの脆弱性に対抗できるようにするわけではありません。
このブログポストのレビューのために Gabriel Lawrence に感謝したいと思います。
Apache Commons Collection は、Java コレクションフレームワークに加えて追加のコレクションクラスを提供する Java ライブラリです。InvokerTransformer はコレクションにあるオブジェクトを（特にリフレクション呼び出しを通じてメソッドを呼び出すことで）変換するために使うことができる Transformer ファンクションインターフェースの実装の一つです。
一般のSallyによる2015年11月10日午前10字15分にポスト | コメント[1]
コメント：
Oracle は Weblogic にセキュリティアラートを発行しています：
あなたのスマホにある写真を、ちょっとだけ役立ててみませんか?
最近、Wikipediaを運営しているWikimedia財団から、iOS(iPhone、iPod touch、iPad)およびAndroid向けに「Wikimedia Commons」なるアプリがリリースされました。これは、Wikimedia Commonsというサイトに写真をアップロードするためのアプリです。
iOS: https://itunes.apple.com/us/app/wikimedia-commons/id630901780?mt=8
Android: https://play.google.com/store/apps/details?id=org.wikimedia.commons
英語のリリースアナウンス: http://blog.wikimedia.org/2013/04/29/announcing-the-official-commons-app-for-ios-and-android/
アプリの説明の前に、簡単に前提の解説を。Wikipediaに写真がたくさんアップロードされていることは見ている人ならご存知かと思います。これらの写真は「Wikimedia Commons」というサイトに一括して集められ、ここの写真をWikipediaの日本語版や英語版、その他姉妹プロジェクトで使えるようにしています。ここに一枚に写真をアップロードすれば、様々なプロジェクトで一度に利用可能なのです。
そして、このアプリを使うと、スマートフォンで撮影した写真や、過去に撮影した写真を簡単にアップロードできます。使い方は、以下の通り。
ちょっと面倒ですが、まずはWikipedia日本語版でアカウントを作成してください。このアカウントは、全ての姉妹プロジェクトで使い回せます。もし既に持っている場合は、ここは飛ばしてください。
スマホで、アプリを選んで、インストールしてください。アプリを立ち上げると、アカウントを求められるので、上記で作成したものか、既に取得しているアカウントでログインしてください。
写真は、その場で撮影するか、スマホのアルバムの中から選択できます。
ご存知かと思いますが、Wikipediaは、データを複製したり改変したりすることができます(これは、いわゆる「著作権フリー」とは違うので、ご注意を)。写真も同様で、著作権上の問題の無いことが前提になります。従って、漫画の一ページや、CDのジャケット、ゲームの画面などは利用できません。自分の家庭内のものか、公道から撮影した写真を使ってください。
基本はどんな写真でも構いません。ただ、知人らが写っているものは、肖像権の問題などを考えると、ちょっと面倒かもしれません。大まかに推奨するものは、
といったものでしょうか。
写真を選択すると、「タイトル(iPhoneだと「タイ…」と省略されています)」「説明」と書かれた入力欄が出てくると思います。ここに、アップロードする際の名前を、説明文を書き入れます。
Wikimedia Commonsは、いわゆるWikiサイトなので、既に名前が使われている場合は、その名前を使うことができません。なので、面倒ですが、できるだけ一意になる名前を使ってください。決めるのが難しい場合は、撮影日を入れるなどすれば良いでしょう(例:富士山_20130507)。
説明文も同様に、入力してください。
いわゆる普通の写真共有サービスではないので、ちょっとだけ注意事項があります。
というわけで、面倒なことこの上ないけど、もしお暇なら、手元のスマホの写真の一二枚をあげてくれると、みんなでより良いアーカイブができると思います。ほんの5分、お手伝いくださいな。
JRuby上で動くRubyとJavaのログを同じファイルに保存したいときなど
JRuby界隈で何かいい方法ないかな～と探していたけど見つからないので
RubyのLoggerのインターフェースをcommons-loggingを使用して実装してみた
使用バージョンは以下
require 'logger' class CommonsLoggingLogger def initialize(name="ruby") @progname = nil @logger = org.apache.commons.logging.LogFactory.getLog(name) end def add(severity, message=nil, progname=@progname, &block) if message.nil? and block_given? message = yield end case severity when Logger::DEBUG debug(progname){message} when Logger::INFO info(progname){message} when Logger::WARN warn(progname){message} when Logger::ERROR error(progname){message} else fatal(progname){message} end end def debug(arg0=nil, &block) @logger.debug make_log(arg0, &block) end def info(arg0=nil, &block) @logger.info make_log(arg0, &block) end def warn(arg0=nil, &block) @logger.warn make_log(arg0, &block) end def error(arg0=nil, &block) @logger.error make_log(arg0, &block) end def fatal(arg0=nil, &block) @logger.fatal make_log(arg0, &block) end def debug? @logger.isDebugEnabled end def info? @logger.isInfoEnabled end def warn? @logger.isWarnEnabled end def error? @logger.isErrorEnabled end def fatal? @logger.isFatalEnabled end def level if debug? Logger::DEBUG elsif info? Logger::INFO elsif warn? Logger::WARN elsif error? Logger::ERROR else Logger::FATAL end end def level=(lv) #do nothing end def sev_threshold level end def sev_threshold=(lv) #do nothing end def datetime_format nil end def datetime_format=(fm) #do nothing end attr_accessor :progname private def make_log(message_or_progname, &block) if block_given? progname = message_or_progname || @progname message = yield else progname = @progname message = message_or_progname end progname_message(progname, message) end def progname_message(progname, message) progname.nil? ? message : "#{progname}: #{message}" end end
もしかしたらこうなるかもしれない未来。
「ジーク・サイバー！ --- 或る学者の演説」を読みながら、こんなことを考えていた。以下は創り出した未来予想図。こういう演説をもし実際に聞くことができるなら、Think Cの演説よりもっと興奮できる未来が、あるのかもね。たとえばこんな感じ。
ネットワーカーの国際組織 The World EFFと世界規模の主要な通信キャリア、家電メーカーなどは、WIPOに働きかけ、カリフォルニア州バークレイ市において、ベルヌ条約の全面改正を討議する国際会議を20XX年に催した。ここにおいて成立したのが、「20XX年の改正ベルヌ条約 (正式名称 20XX年のバークレイ条約)」。旧ベルヌ条約の根幹である「著作権はすなわち創作者の権利である」というドグマを捨て、創作者本人の知的労働の権利保障を中心とする第一部、文化の発展のための権利調整を中心とする第二部、商業利用される著作物の保護制度を中心とする第三部からなることが、大きな改正点である。
「ニュー・コモンズ」と発音する。Free Software Foundation (FSF) が200X年にリリースした、P2Pテクノロジーと利用者相互のコンテンツ・スクリーニングを組み合わせた情報の自由流通ネットワーク・アプリケーションの名称、およびそれが形成するオーバーレイ・ネットワークを指す。発表当時から、そのファイル転送の効率性と民主的なスクリーニングがネットワーカー達の熱狂的支持を集めたが、ただちに各メディア企業、とくに映画産業と音楽産業からの訴訟攻撃に直面し、ついに20XX年 米国最高裁判所において、著作権の間接侵害が認定され違法化された。さらに各国裁判所も同判決に追随し、主要先進国の大部分においてGnu-Commonsは違法化された。
これらの判決に反発奮起したネットワーカー達によって、関係団体への不買運動および猛烈なロビイングが開始された。さらに判決において著作権の間接侵害と指摘されたソフトウェア部分の改修改善が急ピッチで進められた。ロビイングが奏功して、20XX年に開始されたベルヌ条約の全面改正作業と平行して、Gnu-Commons の改修も進められ、Gnu-Commons Ver.3において、改正ベルヌ条約完全準拠のファイル共有ネットワークとして運用が開始された。以下の演説は、総統によって提唱された、条約や法律のオーバーレイ(上書き書換え)と、オーバーレイ・ネットワーク・テクノロジーによるコンテンツの自由流通の実現を目的とした、世界の著作権枠組みを一変させる運動、通称「オーバー・レイ作戦」の成功と、Gnu-Commons Ver.3 リリース祝う祝賀演説として配信されたものである。
我が忠勇なるネットワーカーたちよ。今や著作権絶対主義者どもが主張する"永久の知的財産"なる概念は「改正ベルヌ条約」の発効と「Gnu-Commons」のリリースによって完全に否定された。これらの成功の輝きこそ我らネットワーカーの正義の証である！
決定的打撃を受けた著作権絶対主義者の主張に いかほどの正当性が残っていようと、それはすでに形骸である。
あえていおう！力スであると！
知識は、我らのもっとも効率的な情報流通ネットワークたる「Gnu-Commons」によって流通伝達されて、はじめて最大限の自由と、最大限の効率と、最大限の幸福を達成することができる。これ以上、知識を独占させては、人類そのものの存亡に関わるのだ。
それら既得権者の集団が、金の力で「改正ベルヌ条約」を覆し、訴訟により「Gnu-Commons」を違法化することはできないと私は断言する。著作権絶対主義の無能なる者どもに思い知らせ、明日の未来のために、我らネットワーカーは立たねばならんのである！！
Inspired by Gihren Zab and GeetState
Special thanks and deep respect to...
Adolf Shirater http://orion.mt.tama.hosei.ac.jp/hideaki/indexj.htm
Lawrence Lessig http://blog.japan.cnet.com/lessig/archives/003976.html
Thank you for reading this speech...
No copyrights reserved.
Please feel free to copy and paste this speech anywhere you want.
Please feel free to create any kind oｆ stuff, like flash, picture, novel ,so on.
どうも、J-CASTニュースの記事に付いている画像は、取材の時に撮ったというわけではないらしい。
どれも、著作権的にはフリーらしいので悪いことしているわけじゃないけど、こういうのって、取材の時の様子だと考えてしまうんじゃない？ こういう場合、テレビのニュースなら「資料映像」って付くけど、週刊誌などでは関係ない写真でもばんばん使う。新聞だったら「写真と本文は関係ありません」なんて入れる（例）。
J-CASTのいう1.5次情報
*ってのは、週刊誌レベルってことか。
あと、ウェブのスクリーンショット率の高さにも言及したかったけど眠い。
おまけ。
