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

こちらは、ko-zuさんのユーザページですよ。 Idle.srad.jpは、あなたの人生において完全な時間の浪費です。見るなよ、見るなよ。

13414175 journal
日記

ko-zuの日記: DevFoxからアドオンが消えた

日記 by ko-zu

ついにWebExtension強制となった。
自分にとってのFireFoxを使う理由の9割が拡張機能なのでchromeか。
WebExtension拡張より類似のChrome拡張のほうが見つかる可能性が高いと思うのは自分だけかな?

12968336 comment

ko-zuのコメント: Re:Firefox 49.0.2で4GB超えられました (スコア 1) 2

by ko-zu (#3106655) ネタ元: Firefoxのメモリ消費量を増やす方法を求む

51.0a2 (2016-10-30) (64-bit)
タブを開きつづけると2GBまでは順調に増加。そこで増加ストップしてCPUを食いつづける。

マルチプロセスの合計は3GB超えているのと、瞬間的に2.3GBとか表示されるので32bitアドレスしてて確保不可というよりGC閾値かなにかの設定がよくないっぽいのだけど、mem関係のabout:configを見回しても初期値ばかり。なにが悪いのか……

ありがとうです。49に戻してみようかな

12967201 journal
日記

ko-zuの日記: Firefoxのメモリ消費量を増やす方法を求む 2

日記 by ko-zu

Firefox(少なくともwindows版 dev build)はx86_64でもメモリ消費を2GB以下に制限しようとしているらしい。この上限はいくら空きメモリがあっても変わらず、設定ファイル周りにそれらしい項目がない。

実装の中身を知っているわけではないけれど、挙動からすると32bit時代に書かれたメモリ管理実装に確保上限がハードコードされてしまっているのだろう。2GB以上のメモリ確保を必要とする処理、例えば複数ウィンドウを表示しようとすると、過剰にオブジェクト削除・再描写処理やGCなどのメモリ再配置が走っているようだ。
2GB弱消費している状態でCPUを1コア常時食いつぶすという現象がしばしば発生する。

表トピックのコメントが指摘してるのはこれじゃなかろうか?

12908769 comment

ko-zuのコメント: Re:パスワードの定期的変更 (スコア 1) 38

X秒毎定期変更論者『利用者がX+1秒後(!)に変更するまでの期間、利用者はずっとリスクにさらされていたわけだが、X+1秒毎定期変更論者にとって、このリスクは許容可能なのかね。』
帰納により0秒毎定期変更以外は4年毎定期変更も1000年毎定期変更も危険である。

というのは冗談として、これはリスクだけを見た相対的比較ではなくコスト対リスクの問題。ゼロか否かというだけなら定期的変更も漏洩発覚時の変更もどちらも効果はゼロではない。コストを含めた定量的比較が難しいから議論している。
また確率的な事象に対して事例が一つある、なんて主張するのは、当り番号がわかってからあの時くじに投票しておけば、と同じで意味が無い。

ところで定期変更の強制はパスワードの使い回しや脆弱化を助長しかねない。そのコストを必要論者はどのように許容しているのかな?

12906729 journal
日記

ko-zuの日記: DNS Amp

日記 by ko-zu

リゾルバのログにはそれっぽいのが見つからなかった。
クエリ自体あまり見えてないのでフィルタが効いてたのか単にオープンリゾルバスキャンしてるのが別組織なのか

12597276 submission
セキュリティ

同一の秘密鍵が異なる製品間で使われている問題

タレコミ by Anonymous Coward
あるAnonymous Coward 曰く、
多数のネットワーク機器などで、同一のHTTPS証明書や秘密鍵が使われているという(ITmedia)。オーストラリアのSEC Consultによる調査で明らかになったもの。

同じメーカー、製品ライン内だけでなく、複数のベンダー間で同じ証明書や鍵が使われているケースもあったそうだ。証明書や秘密鍵がユニークなものでない場合、中間者攻撃などに悪用される可能性がある。
12550098 comment

ko-zuのコメント: Re:LINEの中の人は 「なりすまし」 が可能 (スコア 1) 46

問題なのは"簡単で効果的な"公開鍵の交換手段が無いことです。
まともな実装と信頼できる鍵交換手段さえあればリバースエンジニアリングで現代暗号の通信は盗聴できません。

12549885 comment

ko-zuのコメント: Re:LINEの中の人は 「なりすまし」 が可能 (スコア 2) 46

信頼されている認証局が公的に発行するのとLINEがLINEのために発行するのでは大違いです。

公的なCAも不正な証明書を発行すればなりすましできますが、それは現実的ではありません。CAがまがりなりにも信頼されているのは不正が技術的に可能・不可能ではなく、不正を第三者が検証できると考えられていることと、不正によって信頼を失ってブラウザベンダやユーザに失効させられるリスクを背負っているからです。

LINEがLINEの発行したIDに対してLINEのクライアントアプリでのみ検証可能な公的でない証明を与えるのでは意味がありません。またLINE以外による盗聴を防ぐだけであればエンドツーエンド暗号化は不要です。

12549796 comment

ko-zuのコメント: その鍵はどうやって検証したの? (スコア 1) 46

クライアント間で公開鍵をセキュアに受け渡しする必要があるわけですが、どうやって実装してるんですかね?
公開鍵の所有者確認をLINE側しかできないのであればメッセージだけ暗号化してもLINEが中間者になれるのは変わらないのですが。

typodupeerror

ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家

読み込み中...