1Password と遺言保管制度を用いたデジタル終活 | blog.jxck.io
Intro 筆者のように、インターネット上での生活が長く、かつエンジニアとして生きてきた人間には、一般の人には伝わりにくいデジタルの遺品が多く存在する。 仮に自分が死んだ場合に、これらをどのように遺族に処分してもらうかは、なかなか難しい問題だ。筆者はこの「デジタル終活」をどうするかを、長いこと模索してきた。 今回は、「1Password」と法務局が行う「自筆証書遺言保管制度」を用いた方法を思いついたため、検証を試みる。 注意 筆者はエンジニアであり、法律の専門家ではない。 本方式は、法的に有効な遺言の作成については範囲外である。 本方式の目的は、「遺族の負担を減らす」ことである。 ここで「デジタル 遺品」とは以下のようなものを指す。 自分が使ってきたメールアドレスや SNS のアカウント 取得しているドメイン 登録しているサブスク 管理しているコミュニティや OSS etc. 以下のような
大フィッシング攻撃時代における攻撃手法と自衛手段の考察 | blog.jxck.io
1 月分の被害が追加されているが、これは全体としては誤差程度だ。後から 4 月の被害が多数発覚したことが大きく影響している。 テスタ氏が被害を公表し話題になったことで、被害に気づいた人もいたかもしれない。非常に有益な公表だったと感じている。 テスタ氏の場合 テスタ氏の過去の発言を振り返っても、非セキュリティエンジニアという意味での一般人としては、非常にセキュリティ意識が高く、なんなら同業者に対する啓蒙も行っていたようだ。 フィッシング対策について意識しており、偽サイトへの対策をしていた。 2 段階認証をきちんと設定し、周囲にも推奨していた。 ウイルス対策ソフトを二重に入れて、毎日スキャンを実施していた。 そんな中、どのように攻撃を受けたか。氏の動画などを元にまとめると以下のような流れのようだ。 株式市場が開く前、朝 8:30 ごろから、楽天マーケットスピード(投資ツール)にログインしていた
悪いのは全部 Eve だと思ってた | blog.jxck.io
Intro いつも本ブログを読んで頂いている皆様、そしてセキュリティ関係者の皆様へ。 この度は、筆者による "Eve" に対する不適切な引用、および、原稿内における不名誉な扱いについて、この場を借りて謝罪させていただきます。 Alice と Bob ネットワークやセキュリティ系の解説の中で、プロトコルの送受信を二人の対話構成になぞらえる場合、一方を Alice、もう一方を Bob とする通例があります。 その構成は、業界では長くこの通例が使われており、私的な文書から現場実務まで、あらゆる文書で Alice と Bob は対話を重ねて参りました。 この二人の会話の間で、ひっそりと盗み聞きしている存在が「Eve」です。 C (Charlie), D (Dave) を飛ばしていきなり Eve が登場するのは、盗聴を意味する Eavesdropper に由来していることと、Charlie と Da
"Less Password" 時代のアカウント防災訓練 | blog.jxck.io
Intro 震災の直後、復興のさなかに水害が起こり、再び全てが流される。能登の人々にとっては大変な 2024 年だったと思う。首都直下型や南海トラフはいつ起こってもおかしくないと言われ、戦火すら他人事ではなくなっている。 家に災害用の備蓄を用意するのと同様、定期的に「アカウント防災訓練」を個人的に実施するようになって数年経つ。 観点は「今、持っているものを全て失っても、リカバリできるだろうか?」だ。 現代のアカウントの管理は、"Password Less" を目指す過渡期で、中途半端に複雑だ。Password は無くなっているというより、集約された "Less Password" 状態であり、残る「最後の Password」を起点にどう全体を復元するかが、災害時リカバリの課題となる。これに失敗して全てが詰むと、仮に無事避難できたとしても、相当な喪失を味わうだろう。 現状の選択肢と設計方針を
Web Developer Conference 2024 開催告知 #wdc2024 | blog.jxck.io
CFP CFP の募集には fortee を使ってみようと思います。まだ慣れてないので色々と失敗すると思いますが、多めにみてください。(参加募集は fortee ではなく、慣れてる connpass を使う予定です) また、採択は fortee のプロポーサルのスターを第一基準にするので、聞きたいのはスターしてください。(なので、多分応募は早い方が有利です) プロポーザル | Web Developer Conference 2024 - fortee.jp https://fortee.jp/web-dev-conf-2024/proposal/all 募集は Session と LT の 2 枠です。 Session 40 分枠 x 12 Web 開発に関わることならなんでも可 終わったら感想戦会場に移動、そこで QA CFP を Fortee で募集 基本は Fortee のスター数
Apple によるブラウザエンジン規制の緩和 | blog.jxck.io
Intro 以前から騒がれていた Apple によるサイドローディング周りの緩和について、正式な情報公開があった。 Apple announces changes to iOS, Safari, and the App Store in the European Union - Apple https://www.apple.com/newsroom/2024/01/apple-announces-changes-to-ios-safari-and-the-app-store-in-the-european-union/ ストアやペイメントの緩和もあるが、ここでは WebKit に関する部分だけを抜粋し、どのような条件があるのかをまとめておく。 筆者が公開情報を読んで解釈したものなので、内容は保証しない。 前提 iOS/iPadOS に入れられるブラウザには、WebKit を用いる必要があ
ブラウザでリロードしながらキャッシュの挙動を確認してる全ての開発者へ | blog.jxck.io
Intro こういうタイトルを付けるのはあまり好きではないが、あえてこのようにした。 「ブラウザでキャッシュがヒットしない」 以下は、Web における Caching の FAQ だ。 サーバで Cache-Control を付与したのにキャッシュがヒットしない サーバで ETag を付与したのに If-None-Match が送られない サーバで Last-Modified を付与したのに If-Modified-Since が送られない 先日も、筆者が書いた MDN の Cache セクションで「記述が間違っているのでは?」と同様の質問を受けた。 Issue about the Age response header and the term "Reload" · Issue #29294 · mdn/content https://github.com/mdn/content/iss
ローカル開発環境の https 化 | blog.jxck.io
Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う場
画像最適化戦略 Lazy Loading 編 | blog.jxck.io
Intro 長らく議論されてきた <img> や <iframe> における Lazyload について、仕様と実装が動きを見せている。 ここでは、特に画像 <img> に注目し、 Lazyloading の議論の変遷を踏まえた上で現状を解説する。 画像最適化シリーズ第 5 回目のエントリである。 画像最適化戦略 PNG/JPEG 編 画像最適化戦略 Picture 編 画像最適化戦略 WebP 編 画像最適化戦略 SVG/Font 編 > 画像最適化戦略 Lazy Loading 編 Lazyloading 画像や iframe の埋め込みは、読み込むサイズも大きく、処理が同期であるため、レンダリングのボトルネックになりやすく、それらが多いページでは初期表示の遅延の原因となることが多くあった。 特に縦に長いページでは、最初にユーザが見えている領域 (Above the Fold) では表
Cache Digest と HTTP2 Server Push の現状 | blog.jxck.io
Intro httpbis のチェアである mnot から、 Cache Digest についての現状確認が ML に投稿された。 もしこのまま反応がなければ、 Cache Digest は終わり、対ブラウザキャッシュの Server Push は現実的ではなくなる。 Update mozilla standard position に RFP を上げたところ「実装はしないが仕様については non-harmful」となりそうだ。 PFP: Cache Digest Issue #131 mozilla/standards-positions HTTP2 Push HTTP2 の仕様策定時に盛り込まれた新機能として、 Server Push があった。 これは、例えば RPC 的な用途で双方向性のある通信を可能にした。 Web においては、リクエストが来る前にレスポンスを返しキャッシュに入れ
.mjs とは何か、またはモジュールベース JS とエコシステムの今後 | blog.jxck.io
Intro 長いこと議論になっていた ES Modules の Node における扱いに一応の決着が付き、 .mjs という拡張子が採択された。 この拡張子の意味と、今後ブラウザと合わせて Universal JS を実装していく上での作法が見えてきたことになる。 合わせてエコシステムが対応していくことで、長年の夢だった JS のモジュール化を進めていくことができるだろう。 ES Modules 徐々に揃いつつある ES Modules(ESM) の仕様は TC39 で行われており、その仕様については主に以下のような部分になる。 import や export と行った構文 module 内はデフォルト strict mode module でスコープを閉じる module 内の this は undefined etc 逆に以下は TC39 での策定範囲外となる どう Module を読
JavaScript における文字コードと「文字数」の数え方 | blog.jxck.io
Intro textarea などに入力された文字数を、JS で数えたい場合がある。 ここで .length を数えるだけではダメな理由は、文字コードや JS の内部表現の話を理解する必要がある。 多言語や絵文字対応なども踏まえた上で、どう処理するべきなのか。 それ自体は枯れた話題ではあるが、近年 ECMAScript に追加された機能などを交えて解説する。 なお、文字コードの仕組みを詳解すること自体が目的では無いため、BOM, UCS-2, Endian, 歴史的経緯など、この手の話題につき物な話の一部は省くこととする。 1 文字とは何か Unicode は全ての文字に ID を振ることを目的としている。 例えば 😭 (loudly crying face) なら 0x1F62D だ。 1 つの文字に 1 つの ID が割り当てられているのだから、文字の数を数える場合は、この ID の
Polyfill のあり方と Web の進化と協調するためのガイドライン | blog.jxck.io
Intro W3C の TAG から、主にブラウザ API の Polyfill に関するドキュメントが公開された。 Polyfills and the evolution of the Web Polyfill は便利な一方で、時として標準化の妨げになってしまう場合があるため、それを避けるために、Polyfill 実装者、利用者、仕様策定者などが、どう振る舞うべきかという趣旨である。 今回はこの内容を元に、Web の進化と協調する Polyfill のあり方について、主に「実装者」がどうすべきかに着目し記す。 Web における Breaking Change Breaking Change は、簡単に言えば 後方互換を失うことで既存のものが壊れる可能性がある変更 のことを表す。 そして、Web における Breaking Change (Break the Web)、具体的には Web
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
