デライトは、あらゆる情報を「輪郭」という形で描き出し、“つなげながらまとめる”ことによって、脳を拡張したように自由自在な記憶の保存・検索・伝達を可能にする“なんでもメモ”サービスです。
デライトは、あらゆる情報を「輪郭」という形で描き出し、“つなげながらまとめる”ことによって、脳を拡張したように自由自在な記憶の保存・検索・伝達を可能にする“なんでもメモ”サービスです。
Let's Encryptが6日間のShort-Lived証明書のサポートを発表しました。それに合わせて、IPアドレス証明書の発行もサポートされました。 「6-day and IP Address Certificates are Generally Available」 http://1.1.1.1 が実際にIPアドレス証明書を使ってたり、一部の用途でIPアドレス証明書のユースケースもあるので試してみる。 cerbotで発行 certbotも --ip-adress オプションをサポートした (コミットはあるが未リリース) ので実際に発行してみた。 ▶ https://160.16.124.39/ (* 現在はIPアドレス証明書なしに変更してしまいました) 良さそう。 方法 まだ未リリースなので、開発者ガイドラインの通り githubリポジトリから最新コードを実行する。 下記のコマンドで
はじめに 突然ですがこのページを開いてCtrl+Fのページ内検索を開き、 x y z のいずれかの文字を検索してみてください。 https://codepen.io/babatakao/full/bNeBOwr このように、検索した結果がalertで表示されます。 言いたかったこと このように、ページ内検索したテキストはコンテンツJavaScriptから検知できます。 選択したテキストや、フォームに入力したテキストが検知できるのは当然なのですが、ページ内検索テキストは今まで知りませんでした。例えば得体のしれない怪しいウェブサイトで「自分のメールアドレスが漏洩していないかな」とページ内検索、などはやっては駄目なことになりますね。気をつけましょう。 仕組み こんなHTMLとJavaScriptを仕込んでいました。 <p hidden="until-found" id="x">x</p> <p
好きなことに熱中して オンラインでつながりはじめた時代から 約30年 インターネットが育んできたカルチャーを見つめなおし、 人と人、過去と未来をつなげていきます Project to connect with people online 30年前、90年代のインターネットはネットニュースやwww、電子掲示板やチャット、個人ホームページといったコミュニティサービスが始まったばかりでした。携帯やスマートフォンの普及に続き、SNSの登場によって情報は瞬時に多くの人々に届くようになり、その利用は爆発的に拡大しました。 しかしその一方でどうでしょう。個人の発信手段が広がったことは、同時に多くの課題も生み出しました。私たちは毎日、大量の情報に追われ、その中にはフェイクニュースや詐欺が紛れていることも少なくありません。さらに、自己表現の自由という名の下に、誰かを傷つける言葉が飛び交う場になってしまうこと
Loading... Please wait a moment while we ensure the security of your connection. Protected by Anubis From Techaro. Made with ❤️ in 🇨🇦. Mascot design by CELPHASE. This website is hosted by Techaro. If you have any complaints or notes about the service, please contact support@techaro.lol and we will assist you as soon as possible. -- Imprint This website is running Anubis version v1.25.1-0.2026060
2025年のモーダルの実装方法のメモ書き。 <dialog> 要素の利用を前提とします。 Web アプリケーションで UI ライブラリを利用する場合は話が変わってきます。 1年前にdialog要素を使用したモーダルウィンドウの実装例を投稿しましたが、大幅にアップデートされているため、忘れても構いません。 結論<dialog>要素の開閉は command 属性を使用する<dialog>要素の外側をクリックした際に閉じる Light dismiss 機能は closedby 属性を使用するcommand 属性と closedby 属性は Polyfill を使用する開閉時のアニメーション、背面のスクロール抑制、スクロールバーの有無によるガタツキの防止は CSS で行う方針としては極力JavaScriptを書かないことを目指します。 次のようにHTMLを書くことで<dialog>要素の開閉および
scroll-state() はコンテナ要素のスクロール状態に応じてスタイルを変更することができるコンテナクエリです。例えば、スクロール中にヘッダーを sticky な場合の境界線を表示することが挙げられます。 scroll-state() はコンテナクエリの一種であり、コンテナ要素のスクロール状態に応じてスタイルを変更できます。 よくある使い方としては、スクロール中にヘッダーを sticky な場合の境界線を表示することが挙げられます。従来は要素が sticky によりスナップされているかどうかを JavaScript を使って判定する必要がありましたが、scroll-state() を使うことで CSS だけで実現できます。 スクロールがスタックされている状態 はじめに container-type プロパティを使ってコンテナを定義します。container-type の値には scr
インターネットの世界は進歩しているように見えて、ここ20年くらい大きな進歩はない。 数多くのインターネットサービスが生まれ、育ってきたが、どれも「すごい掲示板」にすぎない。 例えばメルカリ。 売りたいものをメルカリという「掲示板」に書く。 買いたい人は「掲示板」を見る。そして買いたいと「掲示板」に書く。 すると、買った人と売った人だけが見れる掲示板が新たに作られ、取引が終わる。 例えばクックパッド。 レシピを載せたい人が、レシピをクックパッドという「掲示板」に書く。 料理を作りたい人はクックパッドという「掲示板」を見る。 これだけ。 例えばYouTube。 動画を載せたい人が、動画をYouTubeという「掲示板」にアップする。 動画を見たい人は、すごい掲示板であるYouTubeで動画を再生する。 例えばInstagram。 自分の撮った写真を、Instagramという「掲示板」にアップする
徳丸さん、こんにちは。 読売のような大手メディアのサイトでもサポート詐欺の偽警告が表示されるようになってしまいましたし、今の時代は広告ブロッカーが必須と考えたほうが安全なのでしょうか？
はじめに はじめまして、セキュリティエンジニアのSatoki (@satoki00) です。今回はブラウザの開発者ツールのネットワークタブから隠れて、Webサイト内の情報を送信する手法をまとめます。所謂Exfiltrationというやつです。中にはCSPの制限をBypassするために用いられるテクニックもあります。CTFなどで安全に使ってください。 前提 発端はWeb上でテキストの文字数をカウントできるサイトが閉鎖する際の話です。カウント対象のテキストデータがサイト運営 (やサイトを改竄した攻撃者) に盗み取られていないかという議論が巻き起こっていました。「盗み取られていない」側の主張は、ブラウザの開発者ツールのネットワークタブにリクエストを送信した形跡がないというものでした。ここで ブラウザの開発者ツールのネットワークタブに表示がなければ外部へデータを送信していないのか？ といった疑問が
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
これまでいろんな現場でWebフロントエンド開発をしてきて、メンテナンスしやすく効率の高いWebフロントエンド開発をする上で重要になる考えが自分なりにまとまってきたので記事にしてみます。 Worse is Betterという考え方 自分が見てきた中でWebフロントエンドの開発効率が落ちてしまう一番の要因は、きれいで理論的には優れているアーキテクチャを構築しようとしてそれ自体がもたらす複雑性を支えきれないというパターンです。 少し前にフロントエンドにClean Architecture（以下CA、あの同心円の図を指すのは誤用に近いですがここではそれに乗ります）を導入する記事が流行ったと思いますがあんな感じです。ああいったクラスベースでDIが重要となる設計手法はサーバーサイドのJavaでSpringを使うのとは違ってReactがサポートしているものではないため、CAの実現自体に高い設計スキルが必
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
