Conversation

twitter.com/EtTuCarl/statu It's 3 vulnerabilities in Skia, which is a 2D rendering library used by Android, Firefox and Chromium. It's widely used and the context where an attacker could gain code exec varies. For Chromium on Android it's in the Chrome or WebView renderer sandbox.

Quote Tweet

Carl (fan parody)

@EtTuCarl

Feb 14, 2019

@DanielMicay Do you know exactly what part of Android does this (specific to built-in photo app, webview, or something else)? twitter.com/cybersecboardr…

Daniel Micay

@DanielMicay

Feb 14, 2019

There are other Android apps using it along applications on other platforms. There's a detailed post about the issues on the Project Zero blog: googleprojectzero.blogspot.com/2019/02/the-cu Can tell it has diverse apps using it from StackOverflow questions like stackoverflow.com/questions/4229 (C# on iOS).

stackoverflow.com

How to add rect using Skia Sharp and apply both fill color and stroke color to that object?

How to add rect or any shape using Skia Sharp and apply both fill color and stroke color to that object in iOS

Replying to

Skia sounds as awful as something I'd expect out of Google...

Replying to

They made it because Cairo has terrible performance and varying output across platforms. I'd expect that Cairo has bigger security problems too, but doesn't get nearly as much attention because it's not exposed in two of the major browsers as the 2D canvas implementation.

Replying to

and

Cairo was used exclusively by Firefox until 52. Performance is acceptable even on very old and embedded hardware. Dunno what you are talking about.

Replying to

and

Cairo performance for canvas and elsewhere was atrocious. It was a massive bottleneck and made rendering very CPU bound. Going from 5-10 fps to 60-120 fps for 2D games, etc. is a big deal. A large part of the issue is Cairo's API. Read Mozilla's posts. robert.ocallahan.org/2011/09/graphi

Replying to

and

Most users aren't running games in the browser but viewing websites. Switch away from Cairo was about competing with (and deprecating) Flash and about letting sites get orders of magnitude more resource-hungry (GPU-dependent), not about making performance acceptable.

Replying to

and

Performance was unacceptable simply for rendering and scrolling web pages consisting entirely of CSS, text and images without any JavaScript. There are also many applications based on Canvas including obvious cases like Google Maps but also lots of examples that are less obvious.

Replying to

and

That's also after Mozilla put in lots of work to develop improvements and accelerated backends for Cairo. Firefox performance can still be sluggish on demanding web pages with complex HTML/CSS. Still often has lots of dropped frames / jank with popular sites on weaker hardware.

Replying to

and

And sure, most sites consume orders of magnitude more resources than they should need to deliver the same experience (with exceptions for web applications with real use cases for complex rendering). That's just the reality of the web, and people won't use Firefox if it's slow.

2:40 AM · Feb 16, 2019Twitter Web Client

Replying to

and

HTML, CSS and the DOM is incredibly complex and inefficient. Rendering it efficiently is extremely difficult. Sites also keep piling on more and more bloat / complexity. If Firefox can't keep up with that, it's just going to drop in usage share even more than it already does.

Replying to

and

Making IonMonkey (or whatever they call it now) more performant, and making Stylo more concurrent, would pay far more dividends than keeping up with Skia CVEs and having to deal with the fallout of merging major Skia versions in every few cycles. But I'm going to bed now. 💤🐱🦊

Show replies