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 のメール表示画面からワンタップで確認できるので、正当なドメイン名と比較することでフィッシング詐欺対策に活用できます。

RFC2616だろうが、7230だろうが、HTTPヘッダに許可されているのはISO-8859-1のみです。

確かにそのままでは UTF-8 などの文字は使用できませんが、RFC 7231 - 8.3.1. Considerations for New Header Fields には、

Header fields needing a greater range of characters can use an encoding such as the one defined in [RFC5987].

とあるので、US-ASCII 以外のキャラクターを使用する必要がある場合には、RFC 5987 で定められた符号化方式が使えるはずです。

また、RFC 6266 において、「filename」と「filename*」は別のパラメータで、「filename*」のみエンコードした UTF-8 が使用できます。

RFC 2616には、filenameに非ASCII文字が含まれている場合の規定は見つけられなかったのですが。（略）いくら誰もリンク先見ないからって参照が適当すぎやしませんか。

#3360309 のコメント内容を再確認したところ、タイトルの「RFC 6266 を無視するサイトが悪い」とアンカーのリンク先は「RFC 6266」で意図した通りでしたが、アンカーテキストのみ「RFC 2616」と誤表記してしまったようでした。正しくはアンカーテキストも「RFC 6266」とすべきでした。お詫び申し上げます。

ていうかすでにRFC 7230～7235でobsoleteされてるし。

RFC 6266 - 6.Internationalization Considerations では、下記の通り、"filename*" パラメータには RFC5987 で定められたエンコーディングを使用することができ ISO-8859-1 以外のキャラクターセットが使用可能とされています。

6.  Internationalization Considerations

   The "filename*" parameter (Section 4.3), using the encoding defined
   in [RFC5987], allows the server to transmit characters outside the
   ISO-8859-1 character set, and also to optionally specify the language
   in use.

   Future parameters might also require internationalization, in which
   case the same encoding can be used.

RFC 6266 (June 2011) の目的は、RFC 2616 (June 1999) の Content-Disposition を国際化するためのものであり、仰る通りもととなる RFC 2616 は既に obsolete されています。

しかし、改訂版 HTTP/1.1 の RFC の一部である RFC 7231 (June 2014) - Appendix B. Changes from RFC 2616 において、Content-Disposition ヘッダーについての定義は RFC 2616 → RFC 7231 の過程で RFC 7231 からは除去され、今は RFC 6266 で定義されているとあるので、今も RFC 6266 は有効だと思われます。

下記は、RFC 7231 からの引用です（太字強調は引用者）。

The Content-Disposition header field has been removed since it is now defined by [RFC6266].

Edge以外使ってくださいという対応しましたわ

Microsoft Edge 41.16299.15.0 で確認しましたが、RFC 2616 に準拠した方法で filename* を指定（URLエンコード）すれば、日本語ファイル名の文字化けは発生しませんでした。

誤った指定方法:

Content-Disposition: attachment; filename="テスト画像.jpg"

正しい指定方法:

Content-Disposition: attachment; filename*=UTF-8''%E3%83%86%E3%82%B9%E3%83%88%E7%94%BB%E5%83%8F.jpg

悪いのは、Edge ではなく Webアプリケーションの製作者です。

docomo の Android 端末は スグ電 という機能で切り忘れ対策が可能なようですが、デフォルトでは無効のようです。

2017年夏モデルより新しく通話中の言葉を認識し、終話の合図（「じゃあね」「失礼します」「バイバイ」など）の後、耳から端末を離すと自動で通話を切断できる。「音声終話機能」を世界で初めて搭載しました。

2017年5月26日（金曜）より、スグ電アプリをアップデートしていただく事で「バイビー」「おやすみなさい」「おやすみ」「またね」および21個の方言でも自動で切断できるようになります。

（DSはバッテリ交換が容易なのに3DSはそうでない）

3DS はバッテリーパックだけを公式に販売している し、ネジ2本緩めてカバーを外して交換するだけで、数分間もかかりません。緩められるだけで外れない特殊なネジなので初めてだと違和感があるかもしれませんが……。

Nintendo ハードだと、バッテリーの取り外しができなくなったのは Switch からです。