パスワードを忘れた? アカウント作成

beroさんのトモダチの日記みんなの日記も見てね。 みんなの日記はここから一覧を見ることができます。

13253106 journal
日記

beroの日記: アカウント/PASSを入れるということ(mymail) 3

日記 by bero

俺はとあるメールサーバの管理者をしてるのだが、
あるユーザから「メールが届かない」というクレームがあった。
詳しく聞くと「特定の人からのメールが届かない」ようだ。
ログを見ると、メールサーバには届いているものの、そのユーザが自分で削除している。
「迷惑メール扱いで自動削除とかの設定になってるんでは?」と聞いても「してない」と言い張る

さらに調べると、collector3.my.com というところ(ロシア)からアクセスされてる
すわアカウントが漏れたか、と思ったが

my.com てなんぞ? と調べたら
mymail というメールアプリ(android/iOS)を出してる会社だった。

で「これこれのアプリ入れてる?」と聞くと、
普段はPCでメールチェックしてるがスマホでも見ることがあり、「(PCでは)何もしていない」と言い張っていたのであった。

おそらく操作ミスかなんかで迷惑メール扱いにしてしまい、以後その人からのメールは届き次第、スマホアプリのローカルの迷惑メールフォルダに入り、同時にメールサーバから削除されていたため、PCからは「届かない」ように見えるのであった。

つまりこのメールアプリは、単なるメールクライアントではなく、

メールアカウント/PASSを会社に預け、
会社サーバが利用者の代理でメールサーバにアクセスする、
メールフィルターサービスのクライアントであった。

検索で引っかかる日本語の紹介ページでは「複数アカウントが使えて便利」「プッシュ通知が便利」と評価が高い。
アプリが全アカウントを定期的にメールチェックするより、会社サーバが代理でチェックして、メールが届いたときのみプッシュ通知する、
というのは利便性も高く電池も長持ちし通信料も減るといいことづくめだが、

一方で会社はメール内容を見放題ということでもある。
実際に見てるかどうか、プライバシーポリシーがどうなってるかは、俺は入れてないので不明。

gmailとかhotmail(今だとoutlook.com?) とかだと、サービス企業及び米政府は見放題、ということはある程度周知されてて利便性とプライバシーを天秤にかけて利用するだろうが、アプリを利用するときも同様である。

.. ということを Orario の件で思い出した

13252511 journal
日記

beroの日記: 「Orarioガラミで取得した単位は取り消す場合がある」のコメント 8

日記 by bero

yasuokaの日記: 「Orarioガラミで取得した単位は取り消す場合がある」

長いのでコメントでなく日記に書く
記事や元の日記では、中の人疑惑で話が発散してるので、単位取り消しに話を絞る

そもそも単位取り消しの前提がわからない

1. 本当かネタかわからない

スラドの日記で

>今後「Orarioガラミで取得した単位は取り消す場合がある」ので、受講生はそのつもりで。

と書いたからといって、本当に受講生に伝えたかどうかもわからない。私的な日記に愚痴を書いただけかもしれない。
いくらなんでも「スラドの日記で禁止したのに気づかず使う奴が悪いので単位取り消し」とはならないだろ

過去の日記でも(welqが話題になる以前から) このサイトはこんないい加減なこと書いてけしからん、みたいなこと書いてるからこの件も単にその一つかもしれない

2. 講義分野がわからない

「仮にセキュリティの専門講義であれば、セキュリティ上怪しげなソフトを使うのは講義を理解できてないことになるので、単位は取り消す場合がある」
という論は正しいが、「仮に」が確定しないとその後の論も空論になる。

yasuoka氏の日頃の投稿や日記(やそこからリンクされる自著記事等)を見るに文字コードとか分野の研究者と思われるので(調べたらその通りだったが)、
スラド読者としてはそういう分野の講義は想像できても、セキュリティの専門分野の講義とは想像しにくい。

例えば教養で情報全般を扱うような講義であれば、専門からちょっと離れた分野の先生も講義するのかもしれないけど、
セキュリティ分野の得点が低くなることはあろうが、単位全部なくなるほどのマイナスかと疑問に思う。

これに関しては、 教授の「好み」で単位を出さないのは許されるのか が参考になった。
大学の論理としては、マイナスと判断してもいいらしい。

3. 学内規約がわからない

少なくともyasuoka氏の日記だけでは、「学内の規約に反する」という理由は出てこない。
まあ本人含む学内の人には自明だから日記には書かなかったのかもしれないけど
(その後のコメント には出てくる)

しかしそれが理由なら「私の講義に関しては」とか限定した話ではなく全学的な問題であるはずで、別の先生の同分野の講義で同得点の片方は通って片方は落ちるのだとしたら不憫すぎる。

これらの前提情報が不明の第三者(スラド読者)から見て、「俺が気に入らないソフト使ってる奴は単位取り消し」というアカハラにしか見えないが、
だからといって人様の日記に「俺が分かるように情報を出せ」と読者がいうのも傲慢だろう。言うだけなら勝手だが、返事するかどうかも勝手だ。

その上で、前提不明どうしでそれぞれ勝手に前提立てて議論しても、前提が違えば結論が違うのは当然で、すれ違うばかりで議論になってない。
もしかしたら、yasuoka氏に近しく学内事情にも詳しく、勝手な前提じゃなくて正しい前提に立って書いてる人もいるのかもしれないけど、これまたその人がそういう人であるという前提不明だと区別がつかない。

---
ちょいと検索したところ

京都大学全学情報システム利用規則
http://www.iimc.kyoto-u.ac.jp/services/kuins/pdf/zengaku_joho_system_riyoukisoku.pdf
京都大学全学情報システム利用規則(抜粋)
https://ecs.iimc.kyoto-u.ac.jp/KuEcsUms/m?m=320&rv=23392

(全学アカウント利用の遵守すべき事項)
第8条 利用者等は、全学アカウントの利用に際して次の各号を遵守しなければならない。
(1) 自分の全学アカウントを他の者に使用させたり、他の者の全学アカウントを使用したりしてはならない。
(2) 他の者の主体認証情報(パスワード)を聞き出したり使用したりしてはならない。
(3) 主体認証情報(パスワード)は、情報環境機構長が別途定める利用者パスワードガイドラインに従って適切に管理しなければならない。
(4) 利用者等は、主体認証を伴って全学情報システム又は特定部局情報システムへアクセス中の利用者端末において、他の者が無断で画面を閲覧・操作することができないように配慮しなければならない。
(5) 学外の不特定多数の人が操作(利用)可能な端末を用いて全学情報システム並びに特定部局情報システムへの全学アカウントによる主体認証を伴ってのアクセスを行ってはならない。
(6) 全学アカウントを他の者に使用され又はその危険が発生した際には、直ちに情報環境機構長にその旨を報告しなければならない。
(7) 姓名の変更等全学アカウントの変更が必要になった際は、遅滞なく情報環境機構に届け出なければならない。
(8) 全学情報システムの利用資格を喪失した際又は利用する必要がなくなった際は、遅滞なく情報環境機構に届け出なければならない。ただし、個別の届出が必要ないと、あらかじめ情報環境機構が定めている場合は、この限りでない。

これが該当の規約かどうか不明だし、他の規約もあるかもしれないが
8条3か6にかかる気はしなくもない。
「他の者に使用され又はその危険が発生」とあり、開発会社曰く「使用しない」とのことだが、アプリをインストールしてアカウント情報を入力した時点で「危険が発生」することはセキュリティ的には自明だ。

(違反行為への対処)
第17条 情報環境機構長は、第7条及び第11条に掲げる事項に違反すると被疑される行為を認めたとき、又は通報を受けたときは、速やかに調査を行い、事実を確認するものとする。なお、事実の確認にあたっては、可能な限り当該行為を行った者の意見を聴取しなければならない。
2 第1項への関与が認められた場合又は疑われた場合、当該部局(本学情報システムでない利用者端末については当該利用者の所属部局)の部局情報セキュリティ責任者は、情報環境機構長が行う当該行為若しくは特定部局情報システム及び利用者端末についての事実の確認及び調査に協力しなければならない。
4 情報環境機構長は、第1項の措置を講じたときは、遅滞無く最高情報セキュリティ責任者にその旨を報告しなければならない。
5 調査によって違反行為が判明したときは、最高情報セキュリティ責任者は全学情報セキュリティ実施責任者を通じて次の各号に掲げる措置を講ずることができる。
(1) 当該行為者が所属する部局情報セキュリティ責任者に対する当該行為の中止勧告
(2) 部局情報セキュリティ責任者に対する当該行為に係る情報発信の遮断勧告
(3) 部局情報セキュリティ責任者に対する当該行為者の全学アカウントの停止又は削除の通知
(4) 当該行為者の所属部局及び総長への報告
(5) その他法令に基づく措置

当該行為つまりアプリ利用の「中止勧告」、セキュリティ責任者への情報発信の「遮断勧告」つまりサーバ側の通信ブロック、当該行為者つまりアプリ利用者のアカウントBAN、とセキュリティ的には当然の対処であるが、当該行為者への罰則等には言及されていない

どこの大学も同様の規約があるとしたら、(大学側が「抗議」は飛ばしタイトルだとして)「各大学が学生に対し利用自粛などを求め」るのは当然の対応だろう。

10605824 journal
日記

beroの日記: mod_evasiveがいまいち使えない件

日記 by bero

ApacheのDoS対策でググるとmod_evasiveとmod_dosdetectorが出てくる。

が、mod_evasiveをテストしてみると、設定したリミットより数倍のアクセスの後にブロックされる。
よく調べてみると、プロセス毎に制限してるようだ。
したがって最大でリミットxプロセス数(最大でMaxServers)のアクセスを許すことになる。

一方mod_dosdetectorは、共有メモリで全プロセスのアクセスを一括して管理しているので、
正確にリミットで制限される。

最終的に mod_dosdetector改 入れた。

10605818 journal
日記

beroの日記: mod_evasiveがいまいち使えない件

日記 by bero

ApacheのDoS対策でググるとmod_evasiveとmod_dosdetectorが出てくる。

が、mod_evasiveをテストしてみると、設定したリミットより数倍のアクセスの後にブロックされる。
よく調べてみると、プロセス毎に制限してるようだ。
したがって最大でリミットxプロセス数(最大でMaxServers)のアクセスを許すことになる。

一方mod_dosdetectorは、共有メモリで全プロセスのアクセスを一括して管理しているので、
正確にリミットで制限される。

最終的に mod_dosdetector改 入れた。

9646060 journal
日記

beroの日記: kindleで角川系出版社隠しセール中 5

日記 by bero

koboでも8/1朝まで角川全作品セール中(30%引)で、
kindleは紙の本との比較なので見かけ上37%とかになるが、koboと同じ。
アスキー/エンターブレインとか系列出版社も有効な模様。

確かkindleの契約条件としてkindleを最安にすべしというのがあったと思うので、合わせてるのだと思われ。
電子書籍を他社でセール中の時はkindleもチェックしてみるのが吉。
但しポイントバック等のときはこのルールが発動しない時もあるようだ。

というわけで星新一とか名作を積ん読。

9487591 journal
日記

beroの日記: LGPLv3の注意点

日記 by bero

LGPLv2は独立したライセンスだが、LGPLv3は例外付きGPLの一種で、GPLv3本体とLGPLv3例外の両方を合わせて有効なライセンスとなる。
配布時にはGPLv3とLGPLv3の両方のライセンス文書を添付しなければならない。

LGPLv3

0.
  As used herein, “this License” refers to version 3 of the GNU Lesser General Public License, and the “GNU GPL” refers to version 3 of the GNU General Public License.
  本文中で使われている通り、「本許諾書」はGNU 劣等一般公衆利用許諾書バー ジョン3を指す。「GNU GPL」は、GNU 一般公衆利用許諾書バージョン3を指す。

4-b)
  Accompany the Combined Work with a copy of the GNU GPL and this license document.
  『結合された作品』に、GNU GPLと本許諾書のコピーを添付す る。

GPL FAQ

もし、LGPLv3をあなたのプロジェクトに使う場合、GPLv3とLGPLv3の両方のコピーを含めることを確実にしてください。これは、今、LGPLv3はGPLv3の上に一組の追加の許可をする形で書かれているからです。

てなことをCOPYING.LGPLv3しか入ってないffmpeg入り某ゲームを見ながら思った

8347925 journal
日記

beroの日記: GoCon行ってきた

日記 by bero

http://togetter.com/li/487380
http://takuan-osho.hatenablog.com/entry/2013/04/14/the-report-of-the-1st-go-conference-in-japan
http://moonstruckdrops.github.io/blog/2013/04/13/gocon-spring/

map遅いという話があったので、帰ってから少し調べてみた

結論から言えば

        hoge := make(map[string]int);
        hoge["hoge"] = 1;


pkg/runtime/hashmap.c
https://code.google.com/p/go/source/browse/src/pkg/runtime/hashmap.c?name=go1.0.3
内の
runtime·makemap
runtime·mapassign1
等を呼び出す。

コレ差し替えれば速くなるんじゃね?と思ったら絶賛書き換え中だった
https://code.google.com/p/go/source/browse/src/pkg/runtime/hashmap.c

ちなみにstructリテラルや配列リテラルはマジ定数だが、mapリテラルはmap初期化+挿入ループに落ちる。

        fuga := map[string]int{"a":1,"b":2,"c":3}

        kvs := []KeyVal{{"a",1},{"b",2},{"c",3}}
        fuga2 := make(map[string]int);
        for _,kv := range kvs {
                fuga2[kv.k] = kv.v;
        }

と同じ。

最初はA Tour of Goをやってた
あと何問残ってるかわからず心が折れそうだったが、右上の[]が目次だった

Exercise: Images
http://go-tour-jp.appspot.com/#59
で詰まった

http://go-tour-jp.appspot.com/#51
では、

func (v *Vertex) Scale(f float64) {
..
func main() {
        v := &Vertex{3, 4}

でも

        v := Vertex{3, 4}

でも、

        v.Scale(5)

が呼べるんだが、

http://go-tour-jp.appspot.com/#59
だと、

...
func (img *Image) At(x, y int) color.Color { v:=uint8(x^y); return color.RGBA{v,v,255,255} }

func main() {
        m := Image{256,256}
        pic.ShowImage(m)
}

prog.go:18: cannot use m (type Image) as type image.Image in function argument:
        Image does not implement image.Image (At method requires pointer receiver)

というエラーが出て動かない。

        m := &Image{256,256}
        pic.ShowImage(&m)

または

        m := Image{256,256}
        pic.ShowImage(&m)

だと動く。または

func (img Image) At(x, y int) color.Color { v:=uint8(x^y); return color.RGBA{v,v,255,255} }
..
        m := Image{256,256}
        pic.ShowImage(m)

のようにレシーバがポインタ版でなく値版にしても動く。

元は

type Image struct{}

func main() {
        m := Image{}
        pic.ShowImage(m)
}

を書き換えて実装しましょう、という問題なのでコレはハマった。
なんでエラーになるかわからん

8142897 journal
日記

beroの日記: Chromium プロジェクトの新しいレンダリングエンジン Blink 1

日記 by bero

Chromium プロジェクトの新しいレンダリングエンジン Blink のご紹介

しかしながら、Chromium は 他の WebKit ベースブラウザーと違い、マルチプロセス アーキテクチャを採用しているため、WebKit プロジェクトと Chromium プロジェクトはここ数年複雑化の一途を辿ってきました。

原文

However, Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects.

しかしながら、Chromium は 他の WebKit ベースブラウザーと違い、マルチプロセス アーキテクチャを採用しているため、

という訳は

しかしながら、Chromium は 他の WebKit ベースブラウザーと異なるマルチプロセス アーキテクチャを採用しているため、

つまり
Chromiumも他の WebKit ベースブラウザーもマルチプロセスだがアーキテクチャが異なる
という意味じゃなかろうか

ChromiumとWebkitのアーキテクチャの概要は、(今やGoogleの中の人である)以下のblogに詳しい

WebKit2 と愉快な仲間たち

この中で「Chromium WebKit」と呼ばれているものがBlinkの正体だと思う。

Chromium が自分用に定義した WebKit の API … Chromium WebKit と呼ぼう … は、 プラットホームにくっつける WebKit1 の流儀をすっかり無視している。 Chromium はライブラリとしての Chromium WebKit を広く人々に使って欲しいとは思っていない。特定ブラウザのためだけに WebKit を使っている。 だから安定した API はなく、 クラスやメソッドが必要に応じて足し引きされていく。 一週間バージョンがずれた WebKit と Chromium はたぶん一緒にビルドできない。
(略)
Chromium はもともと Chromium WebKit のような API レイヤを持たず、 WebCore のクラスを直接使っていた。 WebKit (Project) のリビジョンを固定して開発する分にはそれでもよかったけれど、 最新版の WebKit に追従しつづけようとした途端に WebCore 直接方式は成り立たなくなる。 Chromium チームではない誰かの変更で簡単にビルドが壊れてしまうから。

つまり、「新しいレンダリングエンジン」というより、
すでに事実上forkしてたのを、これまではChromium以外のWebkit側の変更も考慮しつつ上流のWebkitに投げてマージしてたのだが、めんどくさくなったので上流に投げるのやめました、他のアーキテクチャ(WebKit1 APIやWebkit2 マルチプロセス)用のコードはごっそり消して、マージ時の互換性は考えないことにします

ってことじゃないかと思う(コード見てないけど)。

追記:
GoogleがWebKitをフォークして新レンダリングエンジンBlinkをローンチ, 速さと単純性を追求

Chrome Blink よくある質問の翻訳まとめ

7948310 journal
日記

beroの日記: 仮想マシンで摘発逃れ? 4

日記 by bero

児童ポルノ保存、「仮想マシン」使い偽装…逮捕
via: 壇弁護士の事務室

小沢容疑者は、画像を流出させるソフトが存在しないように見せかけられる「仮想マシン」と呼ばれる機能を使っており、府警は摘発逃れを図ったとみている。
発表では、小沢容疑者は2月26日、ファイル共有ソフト「Share(シェア)」を使い、ネット上に流す目的で自宅パソコンに女児の裸の写真が入ったファイル3個を所持した疑い。黙秘しているという。

「摘発逃れを図った」というより、
普通に出所不明ファイルのチェック目的等で仮想マシン内で動かしてたんじゃねーの
(ファイル名を偽装した実行ファイルや、画像や動画を開くだけで発動するウィルスもある)

7771063 journal
日記

beroの日記: GoogleがWebMのためMPEGライセンス取得 33

日記 by bero

GoogleとMPEG LAがVP8規格について合意。Googleがライセンス取得

H.264など動画フォーマットの特許プールを管理する団体 MPEG LA が、Google と VP8コーデックについて合意に達しました。今回の合意では、VP8 や旧 VPx の動画圧縮に必須である「可能性のある」(may be) 技術について、Google はMEPG LAの特許プールを構成する11社からライセンスを取得します。
VP8は Google が2010年に On2 から買った動画フォーマットで、Googleが主導する「ロイヤリティーフリーな」ウェブ向け動画フォーマット WebM の動画部分を構成します。(音声は Vorbis)。

かつてMicrosoftがWindowsMedia(VC-1)をロイヤリティフリー(もしくはMPEGより安価)と発表したものの、結局MPEG特許をベースとしてることが明らかになったが、同様のオチになった模様。

ffmpegのソースを見ると、どこが特許に当たるかわからないが
基本アルゴリズムはどう見てもMPEGと同じだろと思えたので、想定通りのオチ。

ただし

さらに Google はほかの WebM 利用者に対してもサブライセンスする権利を持ち、これは Google 自身による VP8実装に限らず、ほかの企業や個人、団体が実装した場合にも有効とされています。

ということは GoogleがWebMをロイヤリティフリーでサブライセンスできる、
つまりユーザからは現状と同じ?

追記: GoogleとMPEG LAがVP8ビデオコーデックのライセンス問題で合意, より安心して使える規格に

typodupeerror

UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア

読み込み中...