Googleが抜けた後のWebKit
Life with Web Browser Engine (Gecko, WebKit and etc), Mobile and etc. 久々にwebkit-dev見てたら、こんなメールがあったりしてウケた。差出人はAppleの中の人ね。 Hi WebKittens, I’d like to propose removing the Pointer Lock API code from WebKit. The code hasn’t been touched for 12 months, and AFAICT no ports are building with ENABLE(POINTER_LOCK). Is anyone currently building (and shipping / planning to ship) this API? Other thoughts? -Kl
Androidアプリセキュリティ 〜Webサイト閲覧でroot権限を取得されてしまう脆弱性(1)〜 | Remote TestKit
Androidのブラウザ(図中ではWebkitと記載)の脆弱性を利用して相手の端末の管理者権限を取得されてしまうのはどういった仕組みで起きるのかについて解説します。 「○○○の脆弱性により任意のコードが実行される可能性があります」といった文章を一度は見たことがあると思います。 しかし、実際にどのような流れで任意のコードが実行されるのか？読者の皆さんはイメージできるでしょうか？ 今回説明するのは、Androidのブラウザ(図中ではWebkitと記載)の脆弱性を利用して相手の端末の管理者権限を取得する、という少し過激な内容です。 読者の皆様、特にAndroidアプリケーション開発技術者の方々に、今回の記事を通して少しでもセキュリティに興味を持っていただき、セキュアなアプリケーション開発のヒントになればと思います。 1．全体の流れ 遠回りになっていまいますが、まずは、「Android端末からWe
webkit-devで見るBlinkのフォーク | Scene Research Station
ついにWebKitからGoogle勢が分裂してBlinkという新しいフォークが出来てしまった。 折りしもmozillaがレンダリングエンジンをRustで作り直すという挑戦的なニュースも重なり、 新年度早々Web業界ウォッチャーには衝撃が走った。 さて、このBlinkのフォーク騒動だけど、理由は大きく２つあると思う。 一つは、性能や安全性向上のためのリアーキが現状のWebKitのtrunkでは難しいから。 二つは、WebKitのコミュニティ上でのApple勢とGoogle勢の信頼関係が崩れたため。 一つ目の性能に関する理由は明白。Blinkの公式サイトにもあるような、iframeのsandbox化、ネットワークコードの簡潔化、DOMをJSヒープに移動させることによるDOM操作の高速化などを、様々な移植層に適合した形で実現するのは技術的にも政治的にも非常に難しいためだ。 そういったドラスティッ
Opera's Developer Relations Team - Opera 10.60 moves to the beta zone
8 March 2022 by Danny Yao in Blog By supporting the Opera Crypto Wallet, Dapp developers can gain access to millions of crypto users on Opera platform. To do so, Dapp developers need simply add a few lines of code to set up integration with the Opera Crypto Wallet. 23 January 2019 by Daniel Bratell in Blog Opera 58 (based on Chromium 71) for Mac, Windows, Linux is out! To find out what’s new for u
炭坑の庭師 - steps to phantasien
Chromium と WebKit は二つの独立したプロジェクトだ。 ソースツリーはそれぞれ別で、そこにはインテグレーションの苦労がある。 WebKit 以外にも V8 や Skia など Chromium が依存している外部のプロジェクトは山ほどあるけれど, WebKit とは特にぴったりくっついている。 そのぶん二つの足並みをあわせる手間も際立つ。 以前、書籍 ”アジャイル開発の本質とスケールアップ” で リリーストレイン という大規模プロジェクトのインテグレーション手法を読んだ。 プロジェクトの内部で一段細かい時限リリースを設け、そのタイミングでインテグレーションする方法。 内部リリースにあわせてプロジェクト同士が依存している相手のバージョンを上げ、 壊れたところをなおすわけ。 Chromium と WebKit もこまめに相手のバージョンを新しくする。 主たる依存の向きは Chro
-webkit-border-radius なんて書いているWeb開発者は腹を切って死ぬべきである - hogehoge @teramako
地獄の火の中に投げ込むものである。 いや、まあそんなネタはどうでも良くて... そのベンダー接頭辞はいつまで書くの？ | Unformed Building 書いてあることは至極真っ当なこと。もろ手をあげて賛成である。 また、 ベンダー拡張プリフィックスはそれそのものがWebを破壊することはないし、ベンダー独自のプロパティーや関数が数万追加されて使われまくったとしても本当はWebは壊れない。またその文法が変更されても修正または追加すれば対応できるし、その余裕は十分にある。つまり壊れるのはほとんど全てのケースで開発者の怠慢に過ぎないので、ちゃんと仕様と実装を理解して必要ならば寝る間を惜しんで修正作業に血眼になるべき。みたいな実践を伴わない意識を僕は持っている。 なので憂うべきこの現状は、IE6が拡散して残り続けたことと同じようにベンダー側ではなくWeb開発者側に非があると思っている。 ベンダ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
