  |
はてなキーワード: tlsとは
裏紅白歌合戦とは、自由情報が個人のホームページで展開している架空のテレビ番組およびその年で不祥事などによって逆に有名となってしまった人物の晒上げである。
1998年から自由情報という個人ホームページで独自に展開しているテレビ音楽番組であり、その年で不祥事や死亡などのネガティブな一面で有名になった人物を中心に選出した晒上げの意味合いが強い不謹慎企画の一種。
その不謹慎度はアンサイクロペディアのエクストリーム・謝罪を超えており、同企画は謝罪会見のみを扱っているのに対して裏紅白歌合戦は受信料にも言及できるよう不謹慎なものであれば何でも扱うという一面がある。
なお全てが全て不謹慎ではなく、Xなどのトレンドに上がったものも含まれている。
裏紅白歌合戦は本家（？）の紅白歌合戦の裏で行われているという設定であり、基本的に回数や放送時期も同じものであるとされている。
非常に強固なセキュリティを設けているのか、現在まで動画サイトでの無断転載などは確認されていない。 また無断転載した場合は、自由情報から5000兆円が要求されるが、一部の国家はそれすら払えないためどうやって要求しているのか、どう支払いをするのかは一切不明である。
この箇所を書きすぎると5000兆円の対象になりかねないため、例示はせず複数が対象になる執筆をしてください。
選出される歌手などは基本的に自由情報の趣味によるものがほとんどだが、おおむね以下のような選出基準があると思われる。
自由情報も負けず劣らずのテレビオタクであるため、おそらくそのあたりも関係していると思われる。
もはやインターネットの伝統芸能に近い部分もあるが、やはり以下のような批判も多い。
増田で扱うことかこれ？
anond:20221228030607 の続き。
Apple製品のようなスマートさは期待してなかったがある意味予想通りで期待通りだった。
たとえば2の登録では「家電登録ボタンを押す」→「機種カテゴリを選択」→「品番を選択または家電本体のQRコードを読ませる」という流れになるが、機種カテゴリを間違えると品番は見当たらないしたとえQRコードを読ませてもエラーとなる。なお本機の機種カテゴリは「自動計量IH炊飯器」であって「炊飯器」ではないので、上から順に見て「炊飯器」だと思って選ぶと登録できない。まあこれは注意すれば回避できるので大した問題でも無いが。
厄介なのは3の無線LAN設定時、ここでは背面のQRコードを読ませるのが必須なので意気揚々と設置した後にもう一回持ち上げて裏を向かせる必要がある。それなりに重量も大きさもあるのでペラ1枚の注意書きぐらいは欲しいところ。
アプリでの操作を大前提としている作りなのでアプリの使い勝手が重要になるが、キッチンポケットというパナの調理家電用アプリの一機能としている時点で不安があったがまあお察しというか、やはりこれは「日本の家電」であって「ガジェット」ではないという感想。
たとえばお櫃（内釜）を入れずに炊飯予約を入れるとどうなるか？
内釜なしで炊飯することは出来ないので、画面上では「お櫃が設置されていない」というエラーが表示される。ここまではいい。
問題はこのエラー解除には本体で「キャンセル」ボタンの押下が必須。アプリを一度落とそうが必ず本体側でのキャンセル操作が必要。
どうせお櫃をセットしないと動作しないガードが掛かっているのに、予約キャンセルボタンをわざわざ押させる理由はなんなんだろうか。
アプリ上で炊飯時間・炊飯量・炊飯の速さの組み合わせを3パターン登録できるが、毎日・毎週といった設定や炊飯2回分の先行設定も不可。つまり毎日毎回必ず手作業で予約しろということ。
毎日自動炊飯されると、手入れを忘れたときに衛生面に問題が出るとか色々考慮したのかもしれないが普通に考えてこれは不便だ。
設定の約1時間15分前に「そろそろ炊飯始めるぞ、予約変更するなら早くしろ」というアプリ通知が飛び、1時間前に炊飯前の計量が開始されて時間通りに炊き上がる。
炊き上がるとアプリ通知が飛んでくる。この辺は予想通り、期待通りなので特に何もなし。
米と水の計量時に多少音がするだけ…と思っていたら、炊飯中はずっとファンの音がする。
後部の底面から吸気して、内釜の方に送風しているようだがいまいち用途がよくわからん。この辺は取説にも余り詳しく書かれていない。
なお蒸気レスで炊飯できるという記載は無いが炊飯中に蒸気が出ている気配は無い。
ちなみに本機のボタンは「静電式ボタン」と呼ばれるもの。物理的に押し込むのでは無く、触れるだけで反応する。
記念すべき初回の炊飯中、ふと水平状態が気になり（キッチンの端っこ、IHコンロの段差部分に設置したため）iPhoneの水準器で水平状態を確認してたらキャンセルボタンに触れてしまったらしく、文字通り炊飯がキャンセルされるというイベントが起きた。普通の炊飯器であれば再度炊飯開始ということが可能だと思うが、本機は計量からの自動炊飯器なので計量からやり直さなければならない。つまり内釜に入った水とコメは捨てるか鍋にでも入れて自分で炊くしかない。泣く泣く捨てた。そして二度と本体には指1本触れないと誓った。
本機の購入キャンペーンで貰った米（確かコシヒカリ）だが特に可もなく不可もなし。特に味に拘りはないがトップバリュのパックご飯よりは美味しい…ような気がしないでもない。
内釜とその蓋については洗い物ついでに洗えるのでさして面倒ではないが、蓋はパッキンが付いている（取り外し不可）ので完全乾燥させるには放置するしかない。小さい水滴を気にしないなら、布巾で拭けるだけ吹いてセットして次の日の炊飯というのも有りだとは思う。
内釜は一応コーティングされてるようだが一回使っただけでうっすら傷というか跡が付いたのでコーティングの寿命は余り長くないかもしれない（使った杓文字は本機の購入キャンペーンで貰った木製のもの）。
地味に本体とお櫃を繋ぐ連結パッキン部分も毎回の手入れ箇所となっている。ここは炊飯直後には水滴が付いているので放置すると禄なコトにはならなさそうだし、外からは目に見えにくいという厄介さがある。カビとか生えたりしたら恐怖なので取り外して洗えるようにして欲しい。
水タンクは毎日入れ替えることになるからか毎回の手入れ指定はされていないが、水を扱っているので経年で水垢とかが付くのだろうなあという予感がある。
この水タンク、内側もかなり複雑な形状で手入れはかなりし難い。水垢が目立ってきたら補修部品と交換した方が絶対早い。
ワイが代わりにchatGPTに聞いてやったやで
中継サーバー上の電子メールは、暗号化されていない場合は、中継サーバーの管理者や攻撃者によって盗み見られる可能性があります。ただし、多くのメールプロバイダーは、暗号化された通信プロトコル（例：TLS）を使用して、中継サーバー上の電子メールを暗号化しているため、中継サーバー上で盗聴される可能性は低いです。
2.電子メールが送信される過程で、怪しい第三者が設置したサーバーを経由して送られることはあり得るのか？
インターネット上のどこかに、怪しい第三者が設置したサーバーが存在する可能性はあります。このようなサーバーを使用して、電子メールを送信すると、そのメールが第三者によって盗聴、改ざん、または中断される可能性があります。
3.電子メールが送信元のクライアントと受信先のクライアント間のP2Pで暗号化される技術は何があるのか？
P2Pで暗号化された電子メールを送信するために使用できる一般的な技術には、Pretty Good Privacy（PGP）、GNU Privacy Guard（GPG）、またはS/MIMEがあります。
4.「3.」の実現は中小企業で導入するのは難しいものなのか？
PGP、GPG、S/MIMEなどの技術を中小企業で実装することは可能ですが、技術的な知識とスキルが必要です。また、P2Pで暗号化された電子メールの受信側も同じ技術を使用する必要があります。中小企業では、公開鍵暗号化を使用したエンドツーエンド暗号化を提供するメールサービスを利用することが簡単で効果的な解決策となる可能性があります。
5.中継サーバーを経由するなら、メールアドレスは容易に漏洩し、迷惑メールが来るのはそれで漏れたのが原因？
中継サーバーを経由することによって、メールアドレスが漏洩する可能性があります。この漏洩によって、スパムメールの送信元として使用される可能性があります。
6.例えば、会社のPCのWiresharkから、ネットワーク上を流れるデータを盗聴し、隣にいる社員のメール内容を盗み見することは容易に可能なのか？
Wiresharkなどのネットワークプロトコルアナライザーを使用して、ネットワーク上を流れるデータを盗聴することは可能です。ただし、一般的には、電子メールの内容は、中継サーバー上で暗号化されているため、中継サーバー上での盗聴による情報漏洩がより問題となります。また、会社のネットワーク内でのデータ盗聴は、セキュリティポリシーや監視機能の設定によって防止される場合があります。
2. 電子メールが送信される過程で、怪しい第三者が設置したサーバーを経由して送られることはあり得るのか？
3. 電子メールが送信元のクライアントと受信先のクライアント間のP2Pで暗号化される技術は何があるのか？
4. 「3.」の実現は中小企業で導入するのは難しいものなのか？
5. 中継サーバーを経由するなら、メールアドレスは容易に漏洩し、迷惑メールが来るのはそれで漏れたのが原因？
6. 例えば、会社のPCのWiresharkから、ネットワーク上を流れるデータを盗聴し、隣にいる社員のメール内容を盗み見することは容易に可能なのか？
会社で日常的に契約書のPDFや重要な文書を送付しあってるけど、あれ、内容が漏洩することはないの？
あと、会社の情シスから、「迷惑メールが突然来るようになるのは、第三者が設置した中継サーバーでメールアドレスが漏れてしますから。インターネットは不特定多数のサーバーを経由するから、ITを囓ったものなら誰でもそれは分かる」と言われた。確かにインターネット（というかTCP/IP通信）では冗長化されたネットワーク上でパケットが送付されるが、第三者の個人が設置した野良サーバーを、会社から送付されたメールのデータが経由するものなのか・・・？
送信プロトコルとしてSMTPがあり、受信はPOP3、IMAPがあるのは知ってる。
1.について： TCP/IP通信では冗長化されたネットワークをパケットが通るのは分かるが、例えばGmailからOCNのメールに送られるとして、都内在住のマンションに住むある悪意を持った人物が設置したグローバルIPを持つ野良のサーバーを経由して送られる、なんてことがあるのか？ あるとは思ってなかったのだが。。。
2.について： 上と同じ。
3.について： S/MIMEかな？ PGPは会社で使用されているのは見たことがない。
4.について： S/MIME、PGPは、例えば社員400名くらいの小規模な弊社でも導入は容易なのだろうか。Microsoft 365のExchange Serverの設定がいるの？
5.について： 情シスがこれ（メールアドレスは中継サーバーで漏洩するもの）を気にしていた。だから、重要な文書はメールで送ったりするな・・・と。そうなのか？ 初めて知ったのだが。。。メールアドレス漏洩は、リスト型攻撃みたいに文字列(@の左側)を試行して特定ドメインに送付され、届かなければ存在しない、届けばその文字列のアドレスは存在する、みたいなやり方とか、あとダークウェブで入手するものとか、そうだと思ってた。
6.について： 弊社の情シスが言うには、メールの盗聴というのは容易に可能だから、メールでPDFの給与明細を送付するなんてことは絶対にできないらしい（でも、普通にしてる気はするけど・・・）。確かに電子メールはネットワーク上を平文で送付されるかもしれないが、パスワード付きPDFにすればいいし、給与明細をWebサイト閲覧の形にしてTLS通信させればいいじゃん。そういうクラウドサービスあるんだし。そもそも、社内のHUBに悪意ある第三者がLANケーブルつないでパケットキャプチャするとか、実現の難易度高すぎるから、それは想定しなくていいんじゃないの？
ていうのか、疑問。誰か教えて。
CoreKeeper側で apt に依存しているっぽいので、Ubuntu でやった方が楽だと思います。
Ubuntu 20 TLS でやる場合、/home/steam/Steam/ が /home/steam/.steam/ になってたと思うので、環境に合わせて読み替えてください。
dpkg --add-architecture i386 add-apt-repository multiverse apt-get update apt-get dist-upgrade reboot
useradd -m steam passwd steam gpasswd -a steam sudo
sudo -u steam -s cd sudo apt install steamcmd ln -s /usr/games/steamcmd steamcmd ./steamcmd +login anonymous +app_update 1007 +app_update 1963720 +quit
cd ~/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/ ./_launch.sh
Press Ctrl + C for Stop Core Keeper Dedicated Server
mkmir -p -m 775 /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds chown steam:steam /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds
Copy old world file (0.world.gzip) to
/home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds
Copy old setting file (*.json) to
/home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/
chmod 664 /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds/0.world.gzip chmod 664 /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/*.json
vi /etc/cron.hourly/corekeeper_backup #!/bin/bash cp -a /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds/0.world.gzip /home/steam/worldbackup/0.world.gzip.`date '+%Y%m%d%H%M%S'` cp -a /home/steam/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/CoreKeeperServerLog.txt /home/steam/worldbackup/CoreKeeperServerLog.txt.`date '+%Y%m%d%H%M%S'` chmod 777 /etc/cron.hourly/corekeeper_backup sudo -u steam -s cd mkdir worldbackup
sudo -u steam -s cd ~/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/ nohup ./_launch.sh tail -f ~/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/CoreKeeperServerLog.txt
利用者の問題か、サーバーの問題かわかりませんが人数が10人超えると CPU4コア/メモリ4G/100Mbps で結構ラグかったです。
今は CPU6コア/メモリ8G/1000Mbps で動かしています。
６-８人以上で２-３時間サーバー動かしてると、Unityのライブラリがsegfault起こして、Core Keeper Dedicated Server が落ちます。
ログ取れたのでバグレポしましたが、改善するまでは不特定多数が好き勝手するサーバーみたいなのを長期運用するのは厳しいかなと思います。タイミングによってはアイテムロストしてしまうので。
転勤・単身赴任を原則廃止すると宣言した某グループだが今のままだと恐らく何にも変わらない
現状の転勤・単身赴任者は例外者としてエクセルに名前が記載され
四半期に一度名簿の確認とPDF出力された管理簿に部長の電子署名が行われるような儀式的業務が増えるだけのことが起きる
他にも紙の廃止とかも発表されていたが、同じように紙の使用時にエクセル管理簿に記載するという手順が増えたり
紙の使用時にはエクセルチェックシートの提出が求められたりして手間暇が増えて紙の使用は減らないということが冗談では無く本当に起きる
テレワークは持株やその他本社系組織では進んでいるが支店や営業なんかは全然進んでいない
このグループがなぜこんなにトップの言うことを聞かないかというと、実は原因は明らかで持株は戦略やビジョンを策定してもその実行を各事業会社に委任するからだ
もちろん迅速な遂行のために権限委譲するのは当然なのだが、委譲された組織もまたバカでかいので更に権限委譲する必要が出てくる
そうなると今度は人材不足に陥る
ぶっちゃけ持株や本社系ですらヤバい人が割といるのにそこから更に下の組織になるとまともな人を探す方が難しい
できることはエクセルとパワポを使ったアーティスティックな業務と聞いているだけのミーティング参加、という人が大半で
とてもじゃないが戦略やビジョンを理解して新しい取り組みを遂行できるわけがない
そんなところに「原則廃止」なんていう指示を出したら「例外の場合はどうするか」しか考えない
権限委譲された人も「そうだよね、無理だよね」ってなって何かを変えようなんていうしんどいことは誰もやらず
エクセル管理簿を更新していくというトータルで見るとしんどいことを皆がやるようになる
こういう現状を知っている上の方の偉い人達は権限委譲したがらないので管理するようになるが、そうすると今度は幹部が忙しいことを逆手に取った打ち合わせ・エスカレ調整による時間切れ作戦とかが出てきてしまい、結局幹部は疲弊してエクセル管理簿を承認することになる
とにかくこの企業の大半の人は今の仕事のやり方を変えたがらないので、ドラスティックな業務改革が必要なんだが、電話が止まると省庁に滅茶苦茶怒られるのでそうそう変えられない
恐らく仕事のやり方を変えてしまうとやっていける自信が無いので変えたがらない
管理簿やチェックシートを一度作ると廃止したことで何かが起きるかも知れないからどんどん増えていく
TLS接続するDaaS環境なのに念のためにVPN上で接続するような仕様にしてしまい、DaaS動作が重いだけじゃなくサーバ負荷も高くなって全社員から文句が出ているのにセキュリティはよく分かっていない人ばかりなので怖くてやめられない
能力が低い、というとそれまでだが、異動が多すぎて専門性を高められていないのも大きな要因だと考えられる
つまり、広くて凄く浅い知識を持った社員ばかりなので今の業務を変えるだとか新しい取り組みなんかの業務を持株から割り当てられてもとてもじゃないけれど実行できないのだ
文句ばかりになってしまったが、本当に改革したいなら持株でちゃんと優秀な人を集めた「特命改革チーム」を作り、社長レベルの権限と予算を持たせて事業会社に送り込めばいい
ぶっちゃけ社内にそんなことができる優秀な人はいないと思うからコンサルに大量発注すればいい
金で解決できるのに自前主義とか育成観点とか言い出すのでいつも失敗している
ただ失敗が分かる頃には今の社長は変わっているので、新しい社長がまた別のことを言い出して同じようなことを繰り返すだろう
どうせ今回も同じように失敗する
悪いけれどみんなそう思ってる
彼らにとっては「仕事っぽいことをしていると思うこと」が重要なんだよ
「結果」じゃなくて「労働した感」のためにそこにいるわけだ
TLSでエンドセキュリティが担保されていればPDFよりセキュア、っていう指摘は「わかっている人」って感じだけど、
PDFとセキュリティにこだわるならAdobeのLiveCycleとか使うはずなのに、そんなのを使ってる官公庁を見たことがないってのがそれを証明している
地方自治体を中心にPowerPlatform採用したり地味なイノベーションは起きてるから、時間の問題だとは思うけどね
海外よりその歩みが遅いというだけｗ
https://www.digital.go.jp/posts/kMccIpBR
論点は
「デジタル庁ともあろうものが役員人事の情報をPDFだけで公開するのはどうしたものか」
これまで紙文書として管理していたものをWordやExcelにPDFにして管理することで
無駄なプリンターでの印刷や紙媒体の保存などから脱却する、というのはデジタル化ではなくて単にペーパーレス化
デジタル化というのはそれらの文書管理されていた情報を構造化されたデータに統一し
検索可能にしたり統計処理可能にしたりすることで業務効率化や解析による知見の発見を目指すもの
単に人事情報をPDF化したり、それをHTML化したりしてもまったくデジタル化ではない
「大手企業とか政府とかならPDFやHTMLになる前にシステムに投入してるんでしょ？」
と思う人が多いかもしれないが、実体としては大手企業や政府ほどそういうシステム導入がされておらず
実質的に共有フォルダに置かれたPDFファイルで管理されていたりする
これには定期的な人事異動が関連していて、システムを導入するとシステム操作の習熟という引き継ぎが発生してしまうために業務効率が悪い
それよりも一般常識化しつつある共有フォルダに設置されたPDFやPPTを閲覧してもらったり編集して貰う方が誰でもできるし効率的、という現実があるためだったりする
こういった状況の大手企業や政府に対してデジタル化を推進してもらうために取るべき方策は下記の通り
この3つを全て進めていかないとデジタル化はただのペーパーレス化になる
よくあるのは2つ目だけが行われ、慣例的に文書管理されているPDFファイルを共有フォルダではなくシステム投入するだけのデジタル化だ
結局データ解析できないからそのPDFをOCRしようとかいう謎のムーブメントを見せたりするが
PDFに書かれている内容が構造化されていないので当然ながらデータ化できず、解析もできない
よくある領収書とか請求書とかは解析ができたりするがそういうのはそもそも電子的にやりとりされていてやる必要が無く
社員による立て替え払いの時だけ発生していたのがデジタル化されてお茶を濁される
「内部でPDF管理しているんだから公開するときはそのファイルをリンクすればいいよね」
という安易な考え方に基づいてるのがPDFファイルのWeb公開
つまり1つ目の業務単位での見直しができていないし、2つ目のデータ構造化も行われていないだろうということが予想できる
また3つ目の利用者メリットのことを考えてみても、この役員人事の情報をPDFで貰わないと困る一般人など存在しない
どうしても印刷したい人とか、どうしても自分で管理している共有フォルダに置きたい人、なんかはいるのかもしれないが
それにしてもHTML表示されているものを保存するなり印刷すればよい
それよりもスマホで見ているのにA4縦の形式で表示される方がよっぽど不利益が大きい
デジタル化することで構造的なデータにさえなれば、表示する媒体に合わせてレイアウトを変えることは難しくない（大変ではあるが）
また、もしかしたら別の省庁や地方自治体とかがPDF保存している、というのは2つ目の統一的なシステム化ができていないことを意味する
などという意見もあったりするが、そもそもPDFであれば改変できないというわけではないし
今時なら画面キャプチャしてOCRをかければほぼ同じものが出来てしまうのでほぼ無意味である
それよりもTLS化されているURLで改変されていないことを保証することの方が何倍も役に立つ
結局のところPDFでこの手の情報を公開することには何のメリットもないが、ペーパーレス化のレベルで止まってしまうとPDFのメリットばかりを主張しがちになってしまう
発足したばかりの組織が上記の3つをいきなり解決できるわけがない
この慣例的に行われているPDFファイル公開をやめる・やめさせるのは大変に骨が折れる
単純に「やめなさい」と下達的に言うだけなら簡単だが
そうなると結局はPDF管理とHTML編集の2倍の工数がかかって実務者の反発しか生まない
更にはPDFとHTMLの二重管理になってしまって不整合が発生する、なんていうのも想像できる
業務を見直し、システムを入れ、利用者・作業者にメリットを与える、という3つを同時に進めないと上手くいかない
大きな組織でこれをやるのは非常に骨が折れるだろうが頑張って欲しい
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
400あとで/2455users ハーバード大のプログラミング講座を日本語化 無料で学べる「CS50.jp」公開 - ITmedia NEWS
340あとで/2437users 米ハーバード大学のプログラミング授業 日本語訳が無償公開 誰でも聴講可 | ツギノジダイ
335あとで/2327users 東大が無料公開している超良質なPython/Data Science/Cloud教材まとめ (*随時更新) - Digital, digital and digital
292あとで/1762users 新人の方によく展開している有益な情報 – Qiita | kazuo_reve
244あとで/1441users 知っておきたかったLinuxサーバ設計、構築、運用知識まとめ - hiroportation
228あとで/1463users Googleが提供する無料のAI講座受けてみた 1時間で機械学習の基礎がわかる | Ledge.ai
227あとで/1355users 無料で読める、東大／京大の「Python教科書」電子書籍：AI・機械学習の無料電子書籍 - ＠IT
220あとで/1750users 研究の話 | 医療法人豊隆会 ちくさ病院
208あとで/1145users ブラウザレンダリングの仕組み | Aki Kahamura | Zenn
191あとで/1151users すべての働く人におくるストレスマネジメントの基本 | knowledge / baigie
188あとで/1023users 【図解】https(SSL/TLS)の仕組みとシーケンス,パケット構造 〜暗号化の範囲, Encrypted Alert, ヘッダやレイヤについて～ | SEの道標
187あとで/989users 認証と認可の超サマリ OAuth とか OpenID Connect とか SAML とかをまとめてざっと把握する本 | ほげさん | Zenn
180あとで/1161users すべての開発者へ。すごいGitHubリポジトリ10選 – Qiita | baby-degu
179あとで/2080users 山本ゆり（syunkon レンジは600W) on Twitter: "今まで紹介したレンジのハンバーグで個人的に優勝。この手間でこの味になるかと驚くほど簡単で、本当に美味しい(包丁不要。ボウルで捏ねないからヌルヌルの洗い物もナシ) 卵の有無、練り具合、つなぎの量など何度も試作しました。柔らかくジュ… https://t.co/BXntIVz5NQ"
169あとで/1342users 『スタンフォード式 最高の睡眠』を読んで、睡眠について知らないことがまだまだあったのかと感動しました - おたまの日記
162あとで/1388users CS50 for Japanese(ハーバード大学 CS50 の日本語版翻訳プロジェクト): コンピュータサイエンスの入門
161あとで/1375users カレースパイス調合の基本から、スパイスカレーや肉のスパイス漬けを極める（小林銅蟲／イナダシュンスケ） - ソレドコ
154あとで/743users 世界一わかりみの深いOAuth入門 | Noriyuki TAKEI | Speaker Deck
153あとで/1529users TOKIO国分太一さん「センスのいい、もらって嬉しい手土産知りませんか？」見ているだけで楽しい「推し手土産」が集まる - Togetter
149あとで/980users 機械学習の研究者を目指す人へ | Hiroshi Takahashi
149あとで/1629users お前らの登録してるyoutubeチャンネル教えろよ | anond.hatelabo.jp
144あとで/1277users 【更新】創作する人は必読！書評家が下読みで感じた「応募小説の問題点」がめちゃくちゃタメになる - Togetter
144あとで/1225users ナビつき！ つくってわかる はじめてゲームプログラミング | Nintendo Switch | 任天堂
144あとで/1668users 政府向けシステムの話をするときの前提知識 | anond.hatelabo.jp
135あとで/656users フロントエンドのパフォーマンスチューニングを俯瞰する - 30歳からのプログラミング
133あとで/998users 社員用に作った文書校正ツールを一般公開した - gecko655のブログ
133あとで/2245users ため池に落ちると、なぜ命を落とすのか(斎藤秀俊) - 個人 - Yahoo!ニュース
131あとで/1170users 真っ先に変えるべきは日本人の「思考」 オードリー・タンが貫く「透明性」と「多様性」：「前例がない」をやらない理由に（1/5 ページ） - ITmedia ビジネスオンライン
126あとで/796users DOM Events | Alex Reardon
124あとで/912users 「結果が出ない焦り」と向き合う方法｜柴田史郎｜note
124あとで/598users MySQLとインデックスと私 - Speaker Deck | yoku0825
Pマーク(or ISMS)が批判されているが、皆どんなチェックがされるのか知ってるの？ 内容を知らないのでイマイチ批判の波に乗れないんだよね。自分の検索能力が低いだけかも知れないけど、公開されていないようで文書が見つからず真偽を確かめられないし。
なので、ここから先は自分の推測。間違っていたら指摘して欲しい。
PマークやISMSの認定では「パスワード付きzipしろ」と明言されているわけではなく、「メールでファイルを送るなら暗号化しなさい」くらいの話だと想像している。
もちろん、「パスワード付きzipで送付します！」に対してダメと言わないPマークが悪いとも言えるが、以下が担保されればセキュリティとしては問題ないように思う。
審査がザルなんだろうとは思うけど、受ける側が嘘ついてたらどうしようもないし、PPAPが手間が掛かる/非効率である点はPマーク側がどうこう言う話ではない（本当はコストを考慮した上でのセキュリティであって欲しいけどね）。
あと、別ソリューションとしてよく挙げられる外部ストレージサービスの活用について、Pマーク側が禁止しているわけじゃないよね？ 禁止していないなら、それを採用しないお宅が悪いのであってPマークを批判するのはお門違いなのでは？と思っている。
とりとめもなく書いたが、思っていたことをぶち撒けられてスッキリした。
じゃあな。
某大企業に勤めてるよ！
みんな絶対に知ってる日本でトップクラスっていうかある意味トップの企業だよ！
もちろんDXをゴリゴリに推進しているし「DX」と名の入った部署まで作って本気だよ！
社内システムはもちろんDaaS（Desktop As A Service）を使ってるよ！
要するにリモートデスクトップだよ！
社内全員がDaaSを利用するんだけど負荷を抑えるためにWindowsのインデックスサーチはOFFにされてるよ！
なのでファイル検索はめちゃくちゃ遅いしOutlookのメール検索も死ぬほど遅いよ！
おまけに一人あたり20GBの容量しか使えないよ！でも基本的にメールのやりとりだからメールだけで使い切るよ！
え？使い切ったらどうするかって？もちろん、古いメールは削除だよ！
なんで20GBしか使えないのか聞いたら、「平均して20GBしか使ってない」んだって！
ってことは平均以上の半分の人は見捨てられたんだね！
スマホに入ってるmicroSDですら128GB使えるけどね！
ちなみに不正防止の観点でメール等の証跡は全部別のサーバに蓄積されているよ！社員からは見えないけどね！
あと、インデックスサーチOFFにされてるけど、結局はセレロン並の遅さだよ！
だからUSBで持ち出しても外では開けないよ！セキュアだね！DaaSだからUSB刺さらないけどね！
ちなみに暗号化の解除は社員なら了承無しで誰でもできるよ！不便だもんね！
本当に危ないファイルはzipでパスワードを独自に付ける人が多いよ！
でもほとんどの人が4桁数字しか使わないしzipにパスワード付けてるだけだから
DaaSにつなぐためにVPNを張るよ！ワンタイムパスワードで保護してるからセキュリティもバッチリ！
ちなみにこのVPNはDaaSのサーバにしか繋げないVPNだよ！
DaaSにはTLSでアクセスするんだけど、念の為VPNで更にセキュアにしてるよ！
そのせいでVPN繋ぐとトラフィックがそっちに吸い取られてインターネット通信できないよ！
キーロガー仕込まれてたとしても安心かもね！後で送信されたら一緒だけどね！
ちなみにコロナのときはVPNへのアクセス集中でみんな仕事できなくなったよ！DaaSは余裕があったけどね！
社内システムのWeb会議システムがあるからリモートでも会議可能だよ！
DaaS上でしか使えないからラグとエコーがひどくて結局現地で開催されている会議を聞くだけのツールになってるけどね！
なぜかZOOMは初期の頃に猛烈な反対にあって使用不可になったけどね！
DaaS上でしか使えないから映像はほとんど無理だし音声もエコーだらけだけどね！
だからみんな自分の携帯でログインして画面共有のために二重ログインしてるよ！
メールに添付ファイル付けるともちろんPPAP（パスワードZIP送付、パスワード送付、暗号化、プロトコル）してるよ！
exe送れないこと多いからex_にしてから送って、受け取り側でexeにして実行してもらうよ！
４，５年前はこの状態だったけど、これは流石に修正されたのかな？実際に送られたファイルを知らないからわかんないね！
定期的に訓練が実施されているよ！
「訓練が実施されるのでうっかり開いた人は報告してね」
っていうメールが事前に来るよ！親切だね！
訓練メールはだいたいWordのdocファイルが付いていて開封したらHTTPリクエストが飛ぶ仕掛けで開封したかどうかが分かるよ！
ちなみに受け取っただけなら報告はいらないらしいよ！
この時期に本当の標的型メールが来てたらどうするんですか？っていう質問の回答は未だに返ってこないね！
社員への周知がある場合は、周知ページへのリンクがメールされてくるよ！
たとえどんなに些細な周知（社長が挨拶に来ます、とか）でもリンクがメールされるよ！
リンクを踏むとIE9が開いて貧相なページが表示されるんだけど、そこにもまだ内容はないよ！
貧相なページの下に更にリンクがあって、Wordファイルがダウンロードされるよ！
Wordファイルをダウンロードして激重のDaaSで開封すると
だけ書いてあるよ！
勤務表に投入するだけじゃなくて、どういう作業をしたかの稼働までちゃんと入れるよ！
毎日１５分単位で始業開始時刻と終業時刻と休憩時間を入れるよ！
ちなみに2つのシステムで業務時間に誤差があると物凄く怒られるよ！
最近知ったけど日々の業務時刻はどうでもよくて合計しか見てないらしいけどね！
信じられないぐらいチェックシートをたくさん用意して不正防止に努めてるよ！
鉛筆一本買うだけでもとんでもないチェックをしないといけないよ！
チェックが多すぎて誰もチェックしないっていうのが常態化してるよ！
あ、ダブルチェックトリプルチェックは当たり前なので、責任希薄になってやっぱり誰もチェックしないよ！
ちなみに事件は頻繁に起きてるよ！だって、肝心のシステム側がザルだからね！
チェックシートは前は紙にサインだったけどペーパーレス化が進んだからPDF保存になったよ！
おまけにファイルは暗号化されちゃうので検索で引っかからないよ！
ファイル名で検索するしかないから、ファイル名を間違えてると内容が合ってても後ですごく困るよ！
あと会計に少しでも関わるものは絶対にペーパーレスにならないよ！
領収書は原本いらなくなったって何回言っても原本保管から変わってくれないよ！
飛行機の領収書とかPDFをダウンロードしてきて印刷して保管してるよ！
肝心の半券は不要だからやろうと思えばPDFダウンロードした後にキャンセルできるけどね！
業務で使うサーバにログインするときは共通アカウント・共通パスワードが常識だよ！
だいたいのパスワードはアカウント名＋1234みたいな感じだよ！
この前、公開鍵設置して秘密鍵でログインしようとしたらなぜか弾かれてて、よく見たらわざわざOFFにしてあったよ！
公開鍵認証の話をしたら「は？なにそれ？」みたいな顔をされたよ！
あ、もちろんパスワードの定期変更は推奨されてるよ！
なんと今流行りのチャットコミュニケーションツールが導入されたよ！
社内のDaaSからはアクセスできるけど、社外からはアクセスできないほどセキュアだよ！
でもでも、スマホアプリなら社外からでもアクセスできるよ！よくバグで落ちてるけどね！
今のようなことを情シスに言っても何も変わらないよ！だって、ほとんど素人だからね！
3年で人事異動でメンバーが入れ替わるから、それまで問題を起こさないために何もしないよ！
こんな感じでDXを進めてるよ！
もちろん客先では「うちは最先端のDXやってます」って言ってるよ！
胸が痛いね！
フェイクをちょっと混ぜといてよかったよ！本当は「社長が挨拶に来る」じゃなくて副社長だよ！
割と酔った勢いで書いたから今読み返したら意味わからんだろう内容があるのはごめんよ！
教えられるわけないよ！
ごめんね！そうだね！ガチDX施策のクソさも書きたいけどさすがに身バレするね！
本当に書きたかったのは社内システムこんなクソなのにもっとDXしよう！って言ってるシュールさと
社外的に「DXしましょう！うちはプロですから！」って言ってるとこだよ！
もはや全部変えると予算がつかないからこんなことになってるよ！
でもたぶん全部MS社にしてOffice 365とOneDriveにしたら問題の8割は解決しそうだよ！
この辺のシステム請けてるのがそもそもグループ会社ってのが日本の一般的な大企業だよ！
そこで働いてる人はおじいちゃんばっかりで若者はみんな派遣だよ！
この辺のシステムが最適化されると派遣が切られちゃうから下請けはたぶん喜んでるよ！
みんなの会社はこんなにひどくないと信じてるけど
プログラミングで食っていくためには、他の職業と同様に様々なスキルが必要になる。単に技術的な面だけに絞っても、以下のようなことが出来なければ話にならない。
プログラミングスクールなどを卒業したゴミには、(1)〜(2)もしくは(1)だけを以て「自分はプログラミングが出来る」と勘違いしている奴が多い印象がある。
[B! セキュリティ] フェイスブックの暗号化、日米英などが見直し要求へ （写真=AP） 日本経済新聞
平文に一定のアルゴリズムに従って暗号鍵から生成したノイズデータを掛け合わせ、意味が読み取れない暗号文を作るのが暗号化である。逆に意味が取れない暗号文から平文を求める操作を復号と呼ぶ。アルゴリズムがよく知られていながら暗号鍵が無ければ復号できないものがよい暗号と言われる。一般には256bitAESでも使っておけばまずパッと見ても聞いても数学的にもほぼ乱数と区別できなくなる。
ノイズデータの生成方法には色々あり、事前に送り付けた乱数表を使い使用後は破棄するもの、事前に送り付けた共通鍵や公開鍵を使うもの、都度生成するものなどがある。掛け合わせる方法も色々あり、乱数表に書いてある数字と暗号文を足し合わせると平文になるもの、共通鍵を暗号文に使うと平文になるもの、公開鍵を使うと平文になるものなどがある。
共通鍵を平文に使うと暗号文になり、共通鍵を暗号文に使うと平文になるものを、対称暗号とか共通鍵暗号と呼ぶ。
公開鍵を平文に使うと暗号文になり、暗号文に秘密鍵を使うと平文になるものを公開鍵暗号と呼ぶ。非対称暗号ともいう。
共通鍵暗号でも公開鍵暗号でも「平文が、暗号文になり、平文に戻る」というところは同じだが、
共通鍵では「平文→ 鍵→暗号文→鍵 →平文」と同じ鍵を使い、
公開鍵では「平文→ 公開鍵→暗号文→秘密鍵 →平文」と二種類の鍵を順に使う。
なお、この二種類の鍵は順に使えば順序はどっちでも良い。先に秘密鍵で処理して公開鍵で処理することも可能だ。とにかく2種類両方を使えば良い。
共通鍵暗号は分かりやすい。zipのパスみたいなもんだ。Wi-Fiのパスワードも同じだ。だが公開鍵暗号については、二種類の鍵を順番に使うと何が良いのかと思う人も多いだろう。どうせ暗号で読めないのだからいいじゃないかと思うだろう。実は名前の通り鍵を公開しても全くノーダメージというところがメリットなのだ。書かなかったが公開鍵から秘密鍵を数学的に求めることは不可能である。逆も不可能である。そして処理する順番もどっちでもいい。つまり適当な暗号文と鍵の片割れを公開しておくことで、もう片割れの所有を証明できるのである。これが公開鍵暗号の醍醐味である。
この技術はHTTPSの証明書に使われている。というかすべての公開鍵基盤で使われている。.pemとか.cerとかid_rsa.pubはこの片割れであり、ウェブブラウザの「証明書の検証」とは、ネットを見てる時にサーバが送ってくる「適当な暗号文」として"*.hatena.ne.jp"のハッシュを知らん鍵で暗号化したもののハッシュを知らん鍵で暗号化したもののハッシュを暗号化したものに対して、事前にWindowsをインストールした時に付いてきたHatena-Masuda Ultra Global Root CAとかいったけったいな鍵の片割れを使ってみてちゃんと復号出来てるかチェックしているのである。
暗号化通信を行うには、暗号鍵でデータを暗号化すればいい。暗号化には共通鍵暗号を使うのが高速で便利だ。公開鍵暗号は原理的に計算量が多く低速である。しかし、どうやって共通鍵を事前に知らせればいい? 公開鍵暗号で共通鍵を暗号化すれば、受け取り手は自分の秘密鍵で復号できるだろう。しかし、秘密鍵は本当に秘密か? 暗号文と秘密鍵が手に入れば、公開鍵暗号でも解読できてしまうのではないか? HTTPS化しているウェブサービスでも、TLSをロードバランサで終端してデータセンタ内は平文だったりするのではないか? そこで鍵交換、セッション鍵生成の議論が登場する。
Diffie-Hellman-Merkle(Diffie-Hellman)鍵交換方式とは、ディッフィー君とヘルマン君が下宿で階段をドタドタやってる時に天啓のように降ってきたと言われる、ネット上に数字そのものを公開することなく、2者間で同じ1つの乱数を得る方法である。
送信者と受信者の間で共通の1つの乱数を得ることができ、その乱数を第三者に知られることがない。
上で何度か「公開鍵暗号の秘密鍵と公開鍵は、平文に対して両方使えば平文に戻り、順序は関係ない」と書いたのを覚えているだろうか。Diffie-Hellmanはこれに似た方式だ。まず、AさんとBさんは送信者がお互い本人であることを証明できるようにする(公開鍵基盤を使う)。そして、それぞれ手元で乱数AとBを生成する。次に、鍵用の乱数Aを適当な乱数で暗号化した鍵Aと、鍵用の乱数Bを適当な乱数で暗号化した鍵Bを計算し、お互いに送り付ける。この暗号Aと暗号Bは盗聴されているものとする。
AさんとBさんはそれぞれ鍵Bと鍵Aに対して暗号化を行う。すると鍵BAと鍵ABが生まれる。このとき数学的な都合により鍵BA == 鍵ABである。
では、暗号A、暗号B、適当A、適当Bのみから鍵ABや乱数Aを求めることはできないのか? 可能だが式変形などで「解く」ことができず、総当たりになるため計算量が膨大になる。従って実質的にはできない。
或は、暗号A、暗号Bを掛け合わせれば、鍵ABになるのではないか? これもできない。暗号AまたはBと掛け合わせるのは生の乱数AまたはBでなければ意味がない。第三者が乱数Cを作って暗号AやBと掛け合わせても、鍵ACや鍵BCになってしまい、鍵ABと一致しない。
これにより、手元で生成した乱数以外のすべての情報が公開で既知で盗聴されているにもかかわらず、2者間で秘密の暗号鍵用乱数を得ることができる。
原始的なDiffie-Hellman鍵交換の実際の計算は非常に簡単であり、この「暗号化」は事前に決めた別の方法で生成する既知の2つの整数X, Yと乱数A, Bに対して、
暗号A = XをA乗してYで割った余り、
暗号B = XをB乗してYで割った余り、
鍵AB = 暗号BをA乗してYで割った余り、
である。
なお、くれぐれも簡単と聞いてPython 2.7とかで実装しようとしないように。算数の上手い人が作ったライブラリを使え。暗号処理の自作は絶対バグらせて割られるのがオチだ。ちなみにDiffie-Hellman-Merkleの三人目のマークル氏というのは両名と何のゆかりもないので普通は名前に入れないのだが、Merkle氏の先行研究が直接の元ネタなので入れるべきだと主張する派閥もある。俺はどっちでもいいと思うが折角なので入れておく。
ここでやっとE2E暗号化が登場する。上のセクションでしれっと書いたが、DH鍵交換が完了した時に送信者と受信者が得る共通の乱数は、各々ローカルで都度生成する乱数を元にしている。身許保証は公開鍵によるが、鍵は公開鍵に縛られないのだ。つまり、SNSやメールサーバその他、身許を保証する機能と文章をやり取りする機能があるツールと、そのツールで間違いなく本人にDH鍵交換の暗号を送れるクライアントアプリがあれば、その経路で本人同士の間だけで共通の乱数を生成し、それを「セッション鍵」として共通鍵暗号方式による通信経路が設定できる。
この「公開鍵認証基盤で本人確認し、DH鍵交換でセッション鍵を設定し、鍵を端末に出し入れすることなく、受信側端末のメモリに入るまで暗号化を解くこともないまま、共通鍵暗号で通信する」のがいわゆる「End-to-End 暗号化」である。
E2E暗号化を行うと、鍵はDH鍵交換で生成され、端末の外に出ないし書き出す必要もなく、通信の中で割り出す事もできず、通信が終われば破棄してもよい。好きなだけ定期再生成してもよい。認証に使う公開鍵と数学的な関係もない。一度設定してしまえば、SNS運営にチャットログを出させても鍵交換した意味不明な履歴と意味不明な暗号文が出てくるのみで、盗聴者をなりすまさせて鍵を再設定させても前の鍵と何も関係のない新しい鍵が出てくるだけで、意味不明な暗号文の解読の助けにはならない。ちょっと量子コンピュータめいているが、端末となりすましの両方で鍵を一致させることもできない。
ざっくり言えば送信側端末と受信側端末に残っている平文か鍵をバレる前にぶっこ抜く以外に解読方法がない。
これは盗聴関係者にとって非常に大きな問題で、米国のFBIなどは盗聴能力を維持するには法規制以外に策がないと考えている。DH鍵交換のアルゴリズムは上に書いた剰余以外にも楕円曲線を用いた数学的に更に複雑なものもあり、ソースはネットにいくらでも転がっているし、電子計算機アルゴリズムの常でやたら強力な癖に計算量的には全然負担にならない。NSAなどは数学者を揃えて最高のアルゴリズムを提供する振りをして、規格書で事前に決めた一定の数学的特徴を備えているべき定数に備えていないものを指定するとか、実装でミスが出やすい関数を選ぶなど小細工を入れているが俺は二次関数も分からんので詳しいことは知らん。しばしば政府の陰謀にキレた若いITキッズが小細工を抜いて差し替えた再実装を公開したりして揉めている。
実際にSNSなどでE2E暗号化を実装する上での問題点は、本人確認、機種変とマルチデバイス、嫌がらせ対応がある。まず本人確認がコケればMITMは可能だ。E2Eでは鍵を外に出さないのがメリットなので複数端末ログインができず(鍵が変わって別端末で書いたメッセージは解読できなくなる)、運営で常時メッセージを監視できない(したら意味がない)ので嫌がらせ対応が多少困難になる。またMITBというか、改造偽アプリで抜かれる可能性は、まあ、ある。
