サーバサイドを含むWordPressのフルスタックをWebAssembly化した「In-Browser WordPress」、WordPressのコア開発チームとGoogle Chromeの開発チームが紹介
PHPやSQLiteなどのサーバサイドを含むWordPressのバックエンドをWebAssembly化し、WordPressのフルスタックをWebブラウザ上で実行する「In-Browser WordPress」が、「WordPress Playground」で公開されています。 これは昨年（2022年）9月にWordPressのコア開発チームが開発中であることを明らかにし、今年1月頃にWordPress Playgroundで公開が始まった、サーバサイドを含むWordPressの試験的なフルスタック実装です。 参考：WordPressのコア開発チーム、WordPressをWebブラウザで実行する「Client-side WebAssembly WordPress」を開発中 「WordPress Playground」でアクセスすると、Webブラウザ上で「In-Browser WordPre
パスキーとは何か、そしてその課題
パスキーはフィッシングに強く、テクノロジーに詳しくないユーザーでも使いやすい新しい認証方式で、いずれパスワードを置き換えると言われています。この記事では、パスキーの基本と、これからのウェブにとってパスキーがどういう意味を持つのかについてまとめてみます。 パスキーとは何か # 2022 年 12 月 9 日に Google が Android 版 Chrome でパスキーがサポートされたとのアナウンスが出ました。Apple もすでに最新版の macOS Ventura、iOS / iPadOS 16 で Safari がパスキーに対応しています。 パスキーは Apple、Google、Microsoft が協調して使う FIDO クレデンシャルの名前です。エンドユーザーのみなさんがパスワードの代わりとして認識し、直感的にログインできるよう「パスキー」というブランドとアイコンが決まりました。ウ
ブラウザでTCPを直接送受信できるDirect Sockets APIについて - ASnoKaze blog
ブラウザから直接TCP・UDPで送受信する「Direct Sockets API」という仕組みが議論されています。 実験段階ですが、Chromeでは起動時にオプションを付けることでこの機能を有効にできます。今回はTCPの方で簡単に動作を見てみます。 Direct Sockets API Direct Sockets APIは、TCP・UDPで直接送受信可能にするAPIです。既存のアプリケーションプロトコル(SSHやIRC)、P2Pのような機能を実現可能になります。 もちろんセキュリティ上の問題もあるので、Chromeでは現状デフォルトでは有効になっていない機能です。 セキュリティ面についてはだいぶGithubリポジトリで議論されておりますので目を通すと良いでしょう。ローカルネットワークへの通信やSame-Origin-Policy(CORS)回避の話が上がっていますが、今回は細かくは紹介し
WebSocketの次の技術！？WebTransportについての解説とチュートリアル - Qiita
概要 こんにちは。NTTコミュニケーションズのyuki uchidaです。普段はSkyWayというWebRTCプラットフォームの開発やWebRTCリサーチャー(見習い)をしています。 この記事は NTTコミュニケーションズ Advent Calendar 2020 の3日目の記事です。 昨日はMasaki Shimuraさんの記事、 「Threat Intelligenceの活用を促進するMISPの紹介」でした。 この記事は、WebSocketの次の技術ではないかと噂される、WebTransportの概要や双方向通信の歴史をまとめつつ、WebTransportのdatagram形式でデータを送信してみるチュートリアル記事です。 対象読者 WebTransportっていう技術を初めて聞いた人 WebSocketを使ったことがあり、不満がある人 双方向通信・リアルタイム通信について興味がある人
ChromeとFastlyのEarly Hintsの効果計測に貢献する — HACK The Nikkei
この記事は Nikkei Advent Calendar 2020 20 日目の記事です。 日経電子版 Web チームの阿部です。今回は HTTP/2 の目玉機能の 1 つであった Server Push の事実上の終焉と、現在 Chrome チームや Fastly 社が実験中の 103 Early Hints について、日経電子版 Web での取り組みを紹介させていただきます。 HTTP/2 Server Push HTTP/2 Server Pushは HTTP/2 で策定された、一言で言ってしまうと「必要なリソースがリクエストされる前にサーバーからクライアントに送ってしまおう」という技術です。 これによりクライアントがリクエストするリソースを先回りしてサーバーが送ることで、必要なリソースが揃うまでにかかる時間を短縮できるため、パフォーマンスの向上が期待されていました。 Server
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/) .
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（後編）
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（後編） Webの世界では新しいHTTPの標準として「HTTP/3」の策定が進み、現在最終段階にあります。このHTTP/3はこれまでのHTTPをどのように改善し、高速化を実現していくのでしょうか。 2020年11月25日と26日にオンラインで開催されたFastly Japan主催のイベント「Yamagoya Traverse 2020」のセッション「Webを加速するHTTP/3」で、同社の奥一穂氏がHTTP/3の解説を行っています。 本記事では奥氏のセッションをダイジェストで紹介します。（本記事は「HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（前編）」の続きです） サーバプッシュの
ChromeのHTTP/2サーバプッシュサポート廃止検討と、103 Early Hintsについて - ASnoKaze blog
ChromeがHTTP/2サーバプッシュの廃止を検討し始めている。またPreload + 103 Early Hintsの有効性について実験していく模様 背景 HTTP/2(RFC 7540) にはサーバプッシュという機能があります。これは、クライアントからのHTTPリクエストをまたずにサーバがHTTPレスポンスを先行して送ることが出来る機能です。 たとえば、index.htmlに画像1,2,3が含まれているようなページがあるとします。このindex.htmlへのリクエストを受け付けたサーバは、クライアントが画像1,2,3がを要求してくることを予測しサーバプッシュでこれらのリソースを送りつけることが来でます。（クライアント側から、そのリソースが不要であればサーバプッシュをキャンセルすることもできます） そうすることで、ページの表示を効率化出来ると考えられていました。 しかし、様々な議論の中
Google Chromeは「DNSルートサーバー」に大きな負荷をかけている、その理由とは？
Google ChromeやMicrosoft Edgeのベースであるオープンソースのウェブブラウザ「Chromium」には、アドレスバーと検索バーを一体化させた「Omnibox」という機能が搭載されていますが、そのOmniboxによってDNSのルートサーバーに大きな負荷がかかっていると、ベリサインのCSOであるMatthew Thomas氏が報告しています。 Chromium’s impact on root DNS traffic | APNIC Blog https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-dns-traffic/ A Chrome feature is creating enormous load on global root DNS servers | Ars Technica https://ar
QuicTransport によるアプリケーションレイヤでの QUIC 活用 | blog.jxck.io
Intro WebTransport の Quic 実装である QuicTransport の開発が Chrome で行われている。 Chrome で Origin Trials が開始されたので仕様と実装を解説する。 QuicTransport WebTransport については 以前解説した が、位置づけとしてはこうだ。 WebTransport QuicTransport Http3Transport 今回入ったのは、 WebTransport の通信レイヤとして QUIC を用いた QuicTransport という位置づけになる。 IETF で WebTransport over QUIC としてバインディングの仕様が策定され、 WICG でブラウザ API が策定されている。 draft-vvv-webtransport-quic-00 - WebTransport over
簡単にSSL証明書を取得可能＆シンプルな設定ファイルでHTTP/3も利用できるGo製ウェブサーバー「Caddy」
ウェブサーバーとして有名なソフトウェアはApacheやnginxですが、設定が難しいと感じる人も少なくないはず。Google発のプログラミング言語「Go」で開発された「Caddy」は、最低限の設定でSSLによる暗号化やHTTP/3での通信も可能なウェブサーバーです。 Caddy 2 https://caddyserver.com/v2 CaddyはUbuntuやCentOSなどのLinuxで利用可能。今回はUbuntu 18.04にCaddyをインストールしてみます。 下記コマンドを実行すれば、Caddyをインストールすることができます。 echo "deb [trusted=yes] https://apt.fury.io/caddy/ /" \ | sudo tee -a /etc/apt/sources.list.d/caddy-fury.list sudo apt update s
ヘッドレスブラウザとSSRF | 技術者ブログ | 三井物産セキュアディレクション株式会社
ヘッドレスブラウザは、サーバ環境などでHTMLをレンダリングするためにバックグラウンドで動作させるブラウザです。 筆者も昨年診断ツールに組み込んだのを契機に使用し始めました。使ってみるとなかなか面白いので、今年は社内での学習用の「やられサイト」にも組み込んでみました。今回はこのやられサイトを題材にして、ヘッドレスブラウザとSSRF（Server-side request forgery）について書きます。 やられサイトの概要 開発したやられサイトは簡単なブックマークサイトです。ユーザがURLを入力すると、そのスクリーンショット画像をヘッドレスブラウザで取得して、ユーザが付けたコメントなどの付加情報とともに保存します。 下図はヘッドレスブラウザに関連する部分の構成です。 図のとおりNode.jsのPuppeteerを使用しており、バックエンドのブラウザエンジンはChromiumです。性能向上
サーバーサイドレンダリングの代替としてPrerenderを試してみた - Qiita
9月から入社したフューチャーアーキテクトのアドベントカレンダーのエントリーです。技術的にはウェブフロントエンドとGolangあたりです。 シングルページアプリケーションを数年前に試してみて、やりたい表現はこれで十分できるし、過去大変だったことも大分解消されましたのを感じました。一方でSEOとかOGPとかいくつかそのまま実現できないものがあります。とはいえ、それの解消のためにサーバーサイドレンダリングをするのは実装の手間が大変です。そこで、設計時に考えなきゃいけないことが増えます。ウェブアプリケーション側でその手の考慮＆実装をいっさいせずに、今時のウェブアプリケーションでやった方がいいことを実現できる方法について考えました ・・・と思って準備しておいたのですが、@R548さんがDMM.comさんのアドベントカレンダーに書かれてしまった内容と一部かぶります。合わせてお読みいただくと、理解が深ま
Chrome DevToolsを用いたメルカリWebのパフォーマンス計測 - Mercari Engineering Blog
フロントエンドチームの @urahiroshi です。Mercari Advent Calendar 2018 12日目を担当します。 今年の8月から12月にかけて，メルカリ・メルペイのフロントエンドチーム有志で「超速！Webページ速度改善ガイド」の社内輪読会を行いました。 この本の中で，「推測するな，計測せよ」という言葉が紹介されていますが，今回の記事は，輪読会で学んだことのまとめとして，Chrome DevToolsを用いてメルカリWebのパフォーマンス計測と簡単な分析を行ったものです。 なお，現在メルカリWebのアーキテクチャを刷新するための開発が進んでいるため，ここで計測したパフォーマンスの値は大幅に変化していく可能性が高いです。アーキテクチャの刷新後に振り返って見られる楽しみが増えることも、この記事を書いた目的の一つです。 計測方法，環境 計測はGoogle Chrome 71.
SEO対策をサーバーサイドレンダリングせずにやっていく - Qiita
2019/05/08 追記 【大ニュース】 なんとGoogleBotのJSレンダリングエンジンがChrome74相当になって、ES6に対応するようです...！ ここで書かれた内容の多くはすでに古くなっているかもしれません...！ https://webmasters.googleblog.com/2019/05/the-new-evergreen-googlebot.html もう時は2018年の後半となり、React・Vue・AngularといったモダンJavaScriptフレームワークは開発現場でよく見かける存在となりました。 一方で、依然としてこれらを利用して開発をする場合には「Googlebotがそれらをレンダリングできない可能性がある」という問題がついてまわります。 そのため、サーバーサイド側で前もってJavaScriptをレンダリングしておく、サーバーサイドレンダリングという技
Let’s EncryptとACME | IIJ Engineers Blog
社会人生活の半分をフリーランス、半分をIIJで過ごすエンジニア。元々はアプリケーション屋だったはずが、クラウドと出会ったばかりに半身をインフラ屋に売り渡す羽目に。現在はコンテナ技術に傾倒中だが語りだすと長いので割愛。タグをつけるならコンテナ、クラウド、ロードバイク、うどん。 2018年7月はWeb業界にとって記憶に残る日になるでしょう。httpsが標準となった日として。 これまでWebサイトへのアクセスにはhttpを利用するのが通常で、安全性が求められる場合にはhttpsを利用すると考えられてきましたが、これからはhttpsを使うのが当たり前になっていくでしょう。この流れを強力にけん引しているのは、保守的な我が国においてもトップシェアブラウザとなったChromeを擁するGoogleであることはご存知の通りです。これまではhttpでのアクセスには特に表記はなく、httpsでアクセスすると「保
錆びついたTLSを滑らかに、GoogleによるGREASE試験 - ぼちぼち日記
0. 短いまとめ 長い間、TLSのクライアント・サーバ間で使用するTLSバージョンを合意する際に、 不完全なサーバ実装によって version intolerance が発生することが問題になっていました。 TLS1.3ではこの version intolerance の影響を最小化するため、新しい version negotiation の仕組みを取り入れました。 Googleは、GREASE(Generate Random Extensions And Sustain Extensibility)という仕様をChromeに実装し、TLSサーバのバグで通らない拡張やフィールド値で問題が発生しないか試験を始めました。 パケットキャプチャが好きな人は、Chromeが 0x[0-f]a0x[0-f]a の見慣れない値をCipherSuiteやTLS拡張に使っているのを見つけても驚かないよう気を
パスワードに依存しない認証「WebAuthn」をChrome/Firefox/Edgeが実装開始、W3Cが標準化。Webはパスワードに依存しないより安全で便利なものへ
Google、Mozilla、マイクロソフトが「WebAuthn」の実装を開始。これによって「FIDO2」の普及が期待され、Webブラウザから指紋認証や顔認証などで簡単にWebサイトへのログインや支払いの承認といった操作が実現されそうだ。 多くのWebアプリケーションは、ユーザーの認証にユーザー名とパスワードの組み合わせを用いています。 しかしユーザー名とパスワードの組合わせを用いる方法にはさまざまな問題が指摘されています。身近なところでは、安全なパスワードを生成することの手間や、安全性を高めるためにパスワードの使い回しを避けようとした結果発生する多数のパスワードを管理することの手間などがあげられます。 そしてこうしたパスワードの不便さが結果としてパスワードの使い回しを引き起こし、いずれかのサイトで万が一パスワードが流出した場合にはそれを基にしたリスト型攻撃が有効になってしまう、などの状況
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Node.js x Headless Chrome for WeRTC MCU / Node.js x Chrome headless で、お手軽WebRTC MCU
仕事で WebRTC
