Archive for November 8, 2015

Sunday, November 8, 2015 [Tweets] [Favorites]

The New Favicon

Craig Hockenberry:

The href points to an SVG file and the color is used to draw the vector shape contained in the file (the background color for the tab changes depending on whether the browser window is active and if it’s selected.)

The documentation states that the graphic should be a vector shape filled with black. In our first test, we used a fill color that wasn’t black: the image is used as a mask, so the opacity of a filled shape is the only thing that matters. Any opacity in the shape’s fill color will be used, but we don’t recommend using it (and you’ll see why in just a second.)

[…]

Of course, at such a small size, a hand-tuned bitmap graphic would be a better choice.

[…]

It’s our guess that the company has other plans for these files. They currently only appear in pinned tabs, but as more sites support this new style of “favicon”, it’s likely that they’ll make their way into lists for browser history or frequently visited sites.

[…]

Of course you’ll want to preview your work as you tune your vectors. Safari caches the SVG files, so it takes a bit of effort to clear the old data and see your changes.

The Java Deserialization Bug and NSSecureCoding

Charles Miller:

The problem, described in the talk the exploit was first raised in — Marshalling Pickles — is that arbitrary object deserialization (or marshalling, or un-pickling, whatever your language calls it) is inherently unsafe, and should never be performed on untrusted data.

[…]

This means that if there is any object reachable from your runtime that declares itself serializable and could be fooled into doing something bad by malicious data, then it can be exploited through deserialization. This is a mind-bogglingly enormous amount of potentially vulnerable and mostly un-audited code.

In Cocoa land, this is why we have NSSecureCoding. Some things to be aware of:

Update (2015-11-10): Paul Kim:

Even if you don’t call -decodeObject:… in your -initWithCoder: you still have to implement +supportsSecureCoding and return YES in your class, even if a superclass already did it.

[…]

Objects like NSPredicate and NSSortDescriptor can take in key paths or selectors making them potentially unsafe. As a result, they are disabled after being securely decoded. To re-enable them, you have to call -allowEvaluation (presumably after doing some sort of check).