【selflockin】特権使わずにblockできそうだ
TL;DR
cold turky blockerは、ブラウザ拡張と連携することで。
Focus appは、apple scriptを使うことで。
ここから察するに特権なしでも上手くやれるということ。
特権なしで実現できる x Apple特有機能とか必要ないならば、ネイティブ言語使わずともTauriで実現できそう ならば、より融通聴きそうなTauri使おう。
Rustを一緒に学ぶことで、システム周りの知識・スキルも向上させようか。 hr.icon
cold turkey blockerの内容が気になるな。どうやってユーザー権限だけであれだけのことをしてるのか。
探ってみるか。imhexとかで見えるのかな？
ghidraてので、逆アセンブリもできるっぽい。
これツールから覚えるの面倒くさすぎるな..w
とりあえず存在だけ知っておこう...
特権を使わないと決めたら、Tauriでもシンプルに開発できるはずだ。 リスクが大きい箇所を徹底的に動作確認していこう。
1. tauriから常駐プロセスを登録し、プロセス間の通信できるか否か
2. macの非特権プロセスから他アプリの起動を監視し、killするという制御ができるか
tauriから常駐プロセスを登録してみよう
チェック項目
アプリを起動したらすぐに、別の常駐プロセスが登録&実行されている。
アプリを終了しても、登録された常駐プロセスは実行されている。
PCを再起動しても、登録された常駐プロセスは起動して実行されている。
やってみよう
agentを簡単に登録できる。
macの場合、applescriptか、plistを使ったlaunchdの利用のどちらか選べるっぽい。
どちらにせよバックグラウンドのプロセスを登録できる。
難点としては、keepaliveがないってことかな。keepaliveはしておきたいね。少しでも生きながらえさせる..。
チェック項目の達成は可能
ユーザーが「バックエンド実行」をOFFにしない限り、「チェック項目」3つを達成できる。
しかし、この「バックエンド実行のOFF」が難点ではある。簡単にブロックを無効にできてしまうから。
少しパソコンが触れて、誘惑に弱いユーザーの場合、気づいたらすぐoffにしてしまうだろう。
macの挙動で気になるのが「バックグラウンド実行のon/off」
offにしたら今起動してるプロセスもすぐに止まってしまう。
まぁセキュリティ上正しい挙動なんだけど、回避したいなぁという気持ち。
backgroundをoffにしても、簡単にはprocessを消させてはくれない。
多分、PCを再起動してやっと回避できるくらい。回避策に時間がかかって面倒なので、強制力が強い。これは素晴らしい。
結論.icon おそらく、プロセスの相互監視を使ってる
そして、agentの方の名前を変えて見つかりにくくしてる。隠してる。
background実行のon/offで確かにagentプロセスは一度消えてるのだが、メインアプリが監視してて復活させてる。
逆に、メインアプリが終了されたら、次はagentが復活させてる。相互監視の形。
ユーザーは、background実行をoffにすればいいと思って試しても、そう簡単にはoffにできない。
プロセスの相互監視ってありなのかな？やるとしてどうやるんだろうか。
Agentとlaunchdが繋がってるとしよう。
その上で、launchdではないbackendプロセスを動かす。
そいつにagentを監視させて、再起動させるとか？
相互監視してバックエンド実行が無効化されても動くっていうのは、なんだろう...挙動が少しウイルスっぽい...
相互監視とかしなくていいや。
watchdogていうのかな、そういう考え方で監視プロセスを動作させよう。
監視対象のagentがkillされたら再度起動させるようにする。
監視プロセスがlacunctlコマンドを実行することで復活させる。
監視プロセス自身はどうやって止まるのか。こいつもメインアプリとagentプロセスからは切り離しておきたい。
通信ファイルとか使うか。Unixソケット通信的なのでも良いな。
Appleのセキュリティ志向から少し外れ気味で野蛮なやり方だけど、まあいいだろう。
今後のOSアップデートでそれが禁止されたとしもて、コア機能にはそこまで影響はない。
ユーザーが誘惑に少し負けやすくなる程度だから。
構成は以下
1. tauriのメインプロセス：非常駐、UIとかそういうの担当
2. watchdog：agentプロセスの監視、agentかメインがpawnする、準常駐プロセス（OSのサービスを使わない）
3. agent：本アプリのバックエンドと言っても過言ではない、常駐プロセス（OSのサービスを使う）
watchdogの制御をうまく考える必要がある。
pawnしたらpidを保存しておいて、みたいなことするか。
もしくはユニークな名前にしておいて、それでprocessを探すようにするか。
psを探せるかやな。側をつくろうか。リスクヘッジ。
agentをserverに見立て、mainの方をclientのようにする。
agentがブロックの本体なので、こいつからデータをもらう。それにプロセス間通信を使うってわけ。
agentとメインアプリの通信方法を色々試す。request/response方式で繋がれるものが良いね
tauri sidecar
tauriのsidecarとは別にsidecarパターンってのはあるが概念としては近いのかな？
sidecarの理解
ビジネスロジックとは外れる処理（ロギングやメトリクス取得など）の管理を離して、コア側をスッキリさせる設計
このsidecarパターンってのは今回のtauri sidecarとは違うかもしれない。
アプリケーションと一緒にバンドルされる外部バイナリ（実行可能ファイル）
見る感じ、どの言語で書かれたバイナリでも良さげ。
すでにある既存のCLIツールやバイナリをTauriアプリに統合するために使う。
q.icon sidecarのユースケースがいまいち不明
Common use cases are Python CLI applications or API servers bundled using pyinstaller.
どういうユースケースなんそれ。
まだユースケースは見えない。
SideCarプロセスをmainから起動して、そのプロセスと通信できる。
こっちからデータを送れるし、向こうからのデータ受信も可能。
stdout/stdinの方式を取ってるらしい。これIPCの手段の一つなのかな。Pipe方式か？ おそらくそうだな。だとしたらなぜPipe方式なんだろう。
言語別でも簡単に対応可能だからかな？
フロント側のjsからもsidecarプロセスを呼び出せるっぽい。
なんとなく理解した。
別プロセスをメインから呼び出して、それと通信できるって話やな。
おそらくsidecarに使うのはすでにある既存のbinaryとか。別言語で書かれたbinaryとかなんだろう。
ユースケースを見るに...
メインから子プロセスとして呼び出して、それと通信する動きしてるから。
多分、メインプロセスのライフサイクルを超えることは出来ないと見える。