moezilla-memorial-photobook/article.md at main · piroor/moezilla-memorial-photobookYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
Web Application開発に10080番ポートは使ってはいけない
要約 現在最新のGoogle Chormeで10080番ポートが使用できなくなった Firefoxではすでにブロック済み NAT Slipstreaming v2攻撃への対応のため ブラウザからアクセスするサーバを建てる場合は10080以外のポートにするべき 回避方法は一応ある Chrome 91以降は10080番ポートがブロックされる Google Chormeの91 (2021/05/25 リリース)から10080番ポートへのサーバに接続できなくなります。 例えば Google Chrome 90だと以下のように10080番のポートを受け付けるサーバにアクセスできますが、91以降だとアクセスできなくなります % python -m http.server 10080 Serving HTTP on 0.0.0.0 port 10080 (http://0.0.0.0:10080/) .
2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか
サマリ2020年2月にGoogle ChromeはCookieのデフォルトの挙動をsamesite=laxに変更しましたが、2022年1月11日にFirefoxも同様の仕様が導入されました。この変更はブラウザ側でCSRF脆弱性を緩和するためのもので、特定の条件下では、ウェブサイト側でCSRF対策をしていなくてもCSRF攻撃を受けなくなります。この記事では、デフォルトsamesite=laxについての基礎的な説明に加え、最近のブラウザの挙動の違いについて説明します。 （2022年1月29日追記） 本日確認したところ、Firefoxにおけるデフォルトsamesite=laxはキャンセルされ、従来の挙動に戻ったようです（Firefox 96.0.3にて確認）。デフォルトsamesite=lax自体は先行してGoogle Chromeにて実装されていましたが、細かい挙動の差異で既存サイトに不具合が
Firefox and Chromium | Madaidan's Insecurities
Last edited: March 19th, 2022 Firefox is sometimes recommended as a supposedly more secure browser because of its parent company's privacy practices. This article explains why this notion is not true and enumerates a number of security weaknesses in Firefox's security model when compared to Chromium. In particular, it covers the less granular process model, weaker sandboxing and lack of modern exp
Latest topics > なぜMozillaはXULアドオンを廃止したのか？（翻訳） - outsider reflex
Latest topics > なぜMozillaはXULアドオンを廃止したのか？（翻訳） 宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！ « 「同調圧力は忌むべきものだ」と思考停止していたことに気付いた話 Main 「なぜMozillaはXULアドオンを廃止したのか？」に寄せられていた反応を見て、「甘い……甘すぎる……」と思って、W3C信者時代からの価値観に行き着いた話 » なぜMozillaはXULアドオンを廃止したのか？（翻訳） - Aug 22, 2020 （原著：David Teller, 2020年8月20日、CC BY-NC 4.0で公開されている内容の全訳。Qiitaにもクロスポストしています。） 要約：Firefoxはかつて、XUL
fetch() upload streaming は WebSocket の代替になるのか。Fetch を使ってカメラから取得した映像をストリーミングで送信する - 別にしんどくないブログ
Fetch Upload Streaming が Chrome 85 から Origin Trial で使えるようになりました。 何ができるかというと ReadableStream を fetch() の body に渡すことができるようになります。 getUserMedia でカメラから取得した映像をブラウザからストリーミング送信したいときに使えそうと考えたので、今回試してみました。 blog.chromium.org TL;DR fetch() で Stream のデータを送れるようになった WebSocket を使わずに映像などのデータをストリーミング送信できる 以下のコードがこの記事の内容 https://github.com/shisama/sample-streaming-video-with-fetch/blob/master/public/script.js Readabl
Webブラウザ上で純粋なHTTPだけで単方向リアルタイム通信を可能にするHTTPのストリーミングアップロードが遂にやってくる - nwtgck / Ryo Ota
Web標準のHTTPクライアントfetch()でストリーミングしながらアップロードできるようになる。
何故お役所ってオワコンIEが大好きなの？｜楠 正憲（デジタル庁統括官）
普通は役所のシステムって構築してから5年とか7年は塩漬けにして使うもので、一度やらかしてしまうと名誉挽回の機会なんて向こう数年は与えられないんだけど、こと本件に関しては高市総務大臣から「今すぐ私がマニュアルなしでも使えるように直しなさい」と叱責いただいて、しっかりと予算的なサポートも得られたことで、たったの数ヶ月で立て直すことができた。 この数ヶ月は外部のセキュリティやPKIの専門家の方から様々なサポートをいただいて何とか実現したんだけれども、役所のシステム開発としては非常識というか、極めて難易度が高い案件だった。「え？単にChromeやSafariをサポートするだけでしょ、難しい訳ないじゃん」と思う諸兄は、もうしばらくこの話に付き合って欲しい。 もともとマイナポータルは日本を代表するITベンダーと通信キャリアの3社が開発したんだけど、大臣からの叱責を受け「ちゃんとお金を払うから直してよ」
WebAssemblyがW3Cの勧告に到達。「WebAssembly Core Specification 」「WebAssembly Web API」「WebAssembly JavaScript Interface 」の3つ
W3Cの WebAssembly Working Groupは、Webブラウザ上でネイティブコードに近い実行速度で高速に実行できるバイナリフォーマット「WebAssembly」の仕様が勧告に到達したことを発表しました。 今回勧告になったのは、WebAssemblyに関連する3つの仕様です。 1つ目はWebAssemblyのバイナリファイルを実行する仮想マシンの仕様を定義した「WebAssembly Core Specification」。これは一般的なマイクロプロセッサの動作を模倣するような作りにすることで、WebAssemblyのバイナリファイルでプロセッサのネイティブコードに近い実行速度を実現するようになっています。 2つ目の「WebAssembly Web API」は、さまざまなプラットフォームでWebAssemblyを利用可能にするため、WebAssemblyバイナリファイルのシリ
WebExtensionsとテスト
Tokyo WebExtensions Meetup #3の発表資料です https://mozilla.doorkeeper.jp/events/81371
W3C、パスワードを不要にする「Web Authentication」（WebAuthn）を勧告として発表。Chrome、Firefox、Androidなど主要ブラウザですでに実装済み
W3C、パスワードを不要にする「Web Authentication」（WebAuthn）を勧告として発表。Chrome、Firefox、Androidなど主要ブラウザですでに実装済み W3Cは3月4日、FIDOアライアンスのFIDO2仕様の中心的な構成要素であるWeb認証技術の「Web Authentication」（WebAuthn）が勧告になったことを発表しました。 W3Cが策定する仕様はおもに、草稿（Working Draft）、勧告候補（Candidate Recommendation）、勧告案（Proposed Recommendation）を経て正式仕様となる「勧告」（Recommendation）に到達します。今回、WebAuthnが勧告となったのに合わせて、W3CとFIDOアライアンスはWebAuthnの仕様が正式版になったことも発表しました。 WebAuthnは2018
Chrome 70から、WebAuthnでMacのTouchIDとAndroidの指紋認証がデフォルトで利用可能に。Webサイトへのログインもタッチで
Chrome 70から、WebAuthnでMacのTouchIDとAndroidの指紋認証がデフォルトで利用可能に。Webサイトへのログインもタッチで パスワードを使わずデバイス側での指紋認証やPINコードなどによる認証によりWebサイトへログインできるWebAuthnは、2018年4月にW3Cの勧告候補になり、Chrome、Firefox、Microsoft Edgeへの実装が進められています。 参考：パスワードに依存しない認証「WebAuthn」をChrome/Firefox/Edgeが実装開始、W3Cが標準化。Webはパスワードに依存しないより安全で便利なものへ Googleは5月にリリースしたChrome 67でWebAuthnへの対応を行いましたが、10月にリリースされるChrome 70では実装を進化させ、デフォルトでMacのTouchIDとAndroidの指紋認証に対応するこ
パスワードに依存しない認証「WebAuthn」をChrome/Firefox/Edgeが実装開始、W3Cが標準化。Webはパスワードに依存しないより安全で便利なものへ
Google、Mozilla、マイクロソフトが「WebAuthn」の実装を開始。これによって「FIDO2」の普及が期待され、Webブラウザから指紋認証や顔認証などで簡単にWebサイトへのログインや支払いの承認といった操作が実現されそうだ。 多くのWebアプリケーションは、ユーザーの認証にユーザー名とパスワードの組み合わせを用いています。 しかしユーザー名とパスワードの組合わせを用いる方法にはさまざまな問題が指摘されています。身近なところでは、安全なパスワードを生成することの手間や、安全性を高めるためにパスワードの使い回しを避けようとした結果発生する多数のパスワードを管理することの手間などがあげられます。 そしてこうしたパスワードの不便さが結果としてパスワードの使い回しを引き起こし、いずれかのサイトで万が一パスワードが流出した場合にはそれを基にしたリスト型攻撃が有効になってしまう、などの状況
Password Stealing from Password Manager of Modern Browsers
Stealing passwords from McDonald's users became a topic of conversation. This article was translated and be mentioned in the Japanese web media. Of course, XSS is a typical security flaw and should be addressed, but it looks that McDonald's password manager issue is a just general issue of password manager. Let's see password managers on modern browsers. Table. An attacker can steal stored user pa
V8、Firefox、Microsoft Edgeが「WebAssembly」の実装を発表。将来のWebの共通バイナリフォーマットへ期待 － Publickey
V8、Firefox、Microsoft Edgeが「WebAssembly」の実装を発表。将来のWebの共通バイナリフォーマットへ期待 WebAssemblyは、JavaScriptのようにどのWebブラウザでも実行可能なポータブル、かつコンパイル済みでロード時間が小さくて済み、汎用的なハードウェアの能力を活用したネイティブスピードで高速に実行できるという特性を備えた共通のバイナリフォーマットを目指してオープンソースで開発が進んでいます。 2015年6月には、Chrome、Firefox、WebKit、マイクロソフトなど主要なWebブラウザやW3Cが相次いでWebAssemblyのサポートを表明しました。 そして、ChromeのJavaScript実行エンジンであるV8、MozillaのFirefox、そしてMicrosoft Edgeで、このWebAssemblyのテスト実装が相次いで
Web制作における対応ブラウザの選定方法
Web制作における対応ブラウザの選定方法 「フロントエンドのテクニカルディレクションに求められるスキル」で出てきた話題として対応ブラウザの選定方法について掘り下げて解説を行います。 サイトのターゲット・予算・リソース・開発期間などビジネスにより選定方法は異なりますので、あくまで参考程度にしてください。 対応ブラウザを絞る意味 まず最初は「なぜ、対応ブラウザを絞るのか」という視点から。 理想論で言ってしまえばWebサイトを訪れるユーザー全てに最適なコンテンツを提供できれば申し分がありません。 しかし、現実的には各ブラウザ/OSによって実装が異なる機能があったり、実装されていない機能があったり、特有のバグを含んでいる物があったりすることもあり、そういった場合は個別のブラウザ/OSに対してデバッグやチューニングを行わなくてはいけません。 そのため対応ブラウザの数が多ければ多いほど、Webサイトの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Katalon AI-augmented Software Quality Management Platform
Katalon Recorder | Web, Mobile & Browser Test Recorder
GitHub - microsoft/playwright: Playwright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit with a single API.
ブラウザ/セキュリティ/プライバシー周りの一次情報に近い二次情報の情報源をまとめたもの
