LINEグループのトークなんてものは、雑談したい人以外は通知をOffにして、Twitterのタイムラインのように暇なときに眺めるかもしれないぐらいのもの（読まなくて良い）に考えておけば良いでしょう。

その上で、下記の様に、「メンション」「アナウンス機能」「投票」「ノート」を活用すれば良いと思います。

• 相手に通知を送る必要がある場合（連絡を必要とする場合）のみ、「メンション」を付けてメッセージを送る（名前欄タップで自動入力できます）。全員に読んでもらう必要があるなら全員にメンションする。
• メンションを送るほどではないが意見を募集したいようなケースなどは、特定のメッセージをトーク上部にピン留めできる「アナウンス機能」を使う。
• 意見調整などは「投票」機能を使う（作成者が匿名投票にするかを選べるし、投票する側が選択肢を追加することもできる）。
• 決定事項は「ノート」にまとめておく。

雑談用のグループを分けるというのは、ナンセンスな解決策です。

仮に全員が雑談と連絡用のグループを正しく使い分けたとしても、「グループをわざわざ分けたのだから連絡用グループでは全員が通知をONにすべきだ」といった意見が出かねないし、全トークの通知ONにしていたら、「了解です」「分かりました」「私もその日程で大丈夫です」みたいなトークで大量の通知に悩まされるだけです。

PDF なら 墨消しツール という機密情報削除用の機能を使えば良いのでは。

メタデータ・添付ファイル・しおり・注釈・フォームフィールド・非表示テキスト・非表示のレイヤー・埋め込まれた検索用インデックス・リンク、アクションおよびJavaScriptなどの非表示情報も一括で削除できるので、便利だと思います。

画像データとして黒塗りするのは、良く分かっていない人がやると、複数のレイヤーに対応した画像フォーマット (スキャンデータならTIFFとか) で別のレイヤーで黒塗りしてしまって機密情報が消えない恐れや、画像のメタデータに含まれているサムネイルが更新または削除されない画像編集ソフトを使ってしまう恐れがあります。

最新モデルのF-01K は、両方搭載されてますよ。

手袋していると使えないけど電源ボタンに指を乗せるだけで認証できる指紋認証と、手袋をしていても大丈夫な虹彩認証の良いとこ取りができます。

ルーターを貸与するプロバイダによっては、そこはロックされてるな。フレッツ網以外は基本そうだと思う。

ソフトバンクの光BBユニットのようにDHCPサーバ機能で割り当てるDNSサーバアドレスを変更できない（その上DHCPサーバを停止できない）ルータもありますが、変更可能なルータの方が一般的では？

iOSでは基本DNSレコードを弄れない。
カジュアルには出来んさ。

そんなことはなくて iPhone でもたった18秒間で変更できます (動画有り)。DNSブロッキングは回避しやすいので（もとからパブリックDNSを使っている人は回避する必要すら無い）、そもそも海賊版対策としての効果は低いと思われます。

# DNSブロッキングがパブリックDNSで回避されてしまう → OP53B の適用も併せてやる、VPN や Tor で回避されてしまう → VPN や Tor もブロック …… と検閲を強化していったら、中国のような不自由なイントラネットが出来上がります。

1.1.1.1 はプライバシーを重視するため、EDNS Client Subnet には非対応 なようです。

1.1.1.1 is a privacy centric resolver so it does not send any client IP information and does not send the EDNS Client Subnet Header to authoritative servers

CloudFlare, Amazon CloudFront, Akamai などの CDN は、DNS 問い合わせに対して地域によって異なるIPアドレスを返すことで地理的に近いサーバに接続させる仕組みになっているわけですが、EDNS Client Subnet 非対応だとエンドユーザの地域 (IPアドレスの一部) が判別できないため、CDN を使っているサイトに接続する際には遠いサーバに繋がって「遅く」なることがあります。

速さが目的なら、EDNS Client Subnet に対応している Google Public DNS (8.8.8.8) を使うか、素直に ISP の DNSサーバを使い続けるのが良いでしょう。

Let's Encryptの証明書の有効期間は90日間固定 で、ACME v2やワイルドカード証明書導入でも変更されていません。

ワイルドカード証明書の更新時も初回と同様に DNS-01 Challenge が必要でTXTレコードに新しいワンタイムトークンを登録する必要があるので、DNSレコードを簡単に書き換えられるAPIが利用可能なDNSサーバ（や自前のDNSサーバ）を使っていないと自動更新は難しいです。そのため、自動更新のハードルは非ワイルドカード証明書（http-01 / tls-sni-01 Challenge が可能）より高いといえます。

# CA/Browser Forum でも有効期間を短縮する流れ があり、今月から有償の証明書も有効期間が39か月から825日間に短縮されました。

メガバンクの個人向けネットバンキングサービスの中では 物理トークンを使ったトランザクション署名 に対応している、みずほ銀行が圧倒的に安全です。

三菱東京UFJ銀行のパスワードカード や 三井住友銀行のパスワードカード や ゆうちょ銀行のワンタイムパスワード生成機は、トークン（たぶん Digipass）自体は、トランザクション署名対応なのにも関わらず、銀行側が対応していないため、単なるワンタイムパスワード発行機としてしか使用できません。

みずほ銀行のトランザクション署名は、中継型フィッシング・パソコンやスマホが遠隔操作やマルウェアによるMITBの影響下にあっても、トークンに振込先口座番号を入力しない限り（振込先の口座番号固有のワンタイムメッセージ認証コードを発行しない限り）は、不正振込を防げるという優れものです。せっかく大規模なシステム変更をするならば、他行はみずほ銀行を見習って安全な方式を導入すべきだったと思います。

スマホを利用した認証方法については、PCで振込してスマホで認証するならともかく、スマホのみで完結しようとしたらスマホ1要素の認証にしかなっておらず、スマホがマルウェアに感染した場合に安全性が保てないので危険です。OSの月例パッチすらあたっていないまま放置された Android スマホは root 権限が悪意のある第三者に奪われる恐れがあり、認証アプリ自体の安全性が保てません。

利便性のためにスマホでの認証の選択をユーザーに与えるだけならともかく、せっかくの トランザクション署名対応のテンキー付きトークン を導入しているのに、それを単なるワンタイムパスワード生成器としてしか使えない三菱東京UFJ銀行のシステムは糞としか言いようがありません。

Subject の情報（例えば組織名や住所など）を見たかったら「証明書をダウンロード」から pem をダウンロードして、「openssl x509 -text -noout -in certificates.pem」などのコマンドを実行する必要があります。

誤解を招くので補足します。この方法は、証明書の中身を表示するための方法なので、署名の正当性の検証は別途行う必要があります。

長い間 Gmail は S/MIME 署名に非対応で、添付ファイルとして「smime.p7s」が表示されるという酷い状況でしたが、最近になって対応したようです。
今確認してみたところ (スクリーンショット)、Android 版 Gmail (8.2.11.186835846) でも、PCブラウザ版でも署名の検証ができました。

スマホなら件名や差出人等の情報が表示されている部分の「詳細を表示」をタップ、PCブラウザ版なら To の文字のすぐ右の □ で囲まれた ▼ ボタンをクリックで確認できます。
例えば、三菱東京UFJ銀行からのメールであれば、「確認済みメールアドレス」として「email_info02@mufg.jp」が表示されるので、From が偽装されていないことは確認できます。

しかし、住信SBIネット銀行からのメールなど「サポートされていないアルゴリズムが署名で使われています。 デジタル署名が無効です。」というエラーが表示されるメールも多いようです。自分のメールボックスに来ているメールをいくつか確認してみたところ、このエラーが表示されるメールは共通して micalg が sha1 なので、おそらくそれが原因だと思われます。

三菱東京UFJ銀行（エラー無し）
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha-256"; boundary="（略）"

住信SBIネット銀行（エラー表示）
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="（略）"

sha-256 だと古いメーラーでエラーになるし、sha1 だと Gmail でエラーになるというジレンマになってそうです。

残念なことに、Gmail では S/MIME 証明書の Subject 全体を確認することはできないようで、Subject の情報（例えば組織名や住所など）を見たかったら「証明書をダウンロード」から pem をダウンロードして、「openssl x509 -text -noout -in certificates.pem」などのコマンドを実行する必要があります。
しかし、現状でも差出人のメールアドレスが偽装されていないことだけは、S/MIME 署名があれば Gmail のメール表示画面からワンタップで確認できるので、正当なドメイン名と比較することでフィッシング詐欺対策に活用できます。