Posted by Scott Laird
Wed, 19 Mar 2008 01:19:00 GMT
So, one of the features that’s been in the WebKit tree for a while but finally showed up in Safari today is downloadable font support. You can use CSS to apply a specific font to an element and Safari will download the font from a URL provided.
That’s really cool, but the odds of an exploitable buffer overflow somewhere in the font rendering pipeline has to be almost 100%. I mean, almost every graphics format has had multiple exploitable bugs on every platform, and I can’t see how a complete OpenType renderer can be any less complex than JPEG. Even worse, this is a new attack vector, against a part of the system that wasn’t part of the security perimeter before. Is there a way to turn this off?
Tags fonts, safari, security | 1 comment
Posted by Scott Laird
Sat, 07 May 2005 03:12:22 GMT
According to a post on 0xDECAFBAD, Safari records a bit of extra metadata onto every file that you download:
$ mdls QS.2AD4.dmg
QS.2AD4.dmg -------------
kMDItemAttributeChangeDate = 2005-05-06 12:40:37 -0700
...
kMDItemWhereFroms = (
"http://imajes.info/quicksilver/application/QS.2AD4.dmg",
"http://quicksilver.blacktree.com/"
)
Notice the kMDItemWhereFroms entry–that’s Safari tagging the file to remind you where it came from. I didn’t think that was possible in Tiger–Safari just downloaded the file, it doesn’t own it, and it doesn’t provide a Spotlight indexing driver for the file. Somehow, it still managed to add extra metadata of its own onto the file; I though we were going to have to wait for 10.5 before we could do this.
Unfortunately, the extra tags are fragile. I made two copies (one using the Finder, one using cp), and neither copy has a kMDItemWhereFroms field. That’s what you’d expect if Safari cheated and stuck an extra field into Spotlight’s DB, but it’s not how a “real” metadata system would behave. Hopefully 10.5 will allow metadata to belong to the file itself, not just the Spotlight index, so that copying it will preserve the extra metadata.
Posted in Mac stuff | Tags macosx, metadata, safari, spotlight | 1 comment
Posted by Scott Laird
Tue, 03 May 2005 02:11:04 GMT
This is certainly a skewed sample, but I just ran a quick test, and it looks like over half of the Safari users that have visited this site today are using Safari 2.0. Most the the rest are using Safari 1.3. Considering that Safari 2.0 is only available on Tiger, and Safari 1.3 arrived about two weeks ago as part of the 10.3.9 upgrade, it looks like most of my readers are quick upgraders.
If time permits, I’ll build a little graph later showing the version percentage by day; that should be entertaining.
Posted in Mac stuff | Tags macosx, safari, tiger | no comments
Posted by Scott Laird
Fri, 08 Apr 2005 00:58:31 GMT
It seems like every month, Safari runs just a little bit slower on my PowerBook. Some sites are worse then others–I can’t visit cnn.com or newegg.com without staring at the spinning beachball of death for 5 or 10 seconds. Even worse, whenever this happens, Mail or NetNewsWire tend to go away as well, rendering my system effectively useless. Clearly something was eating a bunch of CPU time, but there was no obvious way to tell what it was.
So, this afternoon I decided that I’d bite the bullet and find the problem. I downloaded Apple’s CHUD toolset, installed it, and fired up Shark, Apple’s system-wide profiling tool. I left it running in the background, collecting performance data, while I loaded up a bunch of slow websites, and then took a look at the profile that it generated. The single biggest block of time was spent running CFStringFindWithOptions (9.1%). Drilling down a bit, it looks like most of those calls came from NSHTTPCookieDiskStorage (8.8% of the total). So I fired up Safari’s cookie editor and realized that I hadn’t cleared out my cookie cache since I first installed Safari–there were several thousand cookies sitting there. From looking at the profile, I’d guess that OS X’s cookie system does a linear search through the whole cookie jar every time it hits a page. Since the same basic code is used by every native OS X application, that’d explain why both Safari and NetNewsWire were slow.
I spent a few minutes cleaning out the cookie jar, and–amazingly enough–Safari’s a lot faster. I haven’t seen the beachball of death since I cleaned up the cookies; before I was seeing it every minute or so. I don’t have any hard benchmark numbers, but subjectively it feels a lot better.
So, if Safari’s running slow, try cleaning out your cookies.
Update: Thinking about it a bit more, it seems obvious what’s happening–every single HTTP request does a linear read of the cookie database. With some sites, a decent percentage of the HTTP requests also result in a write to the cookie database. Most likely, this triggers a reader-writer lock of the cookie DB, so the write stalls waiting for a bunch of slow reads, and then a handful of writes back up one after the other, so even if the cookie handling is only eating 9% of the CPU, the total wall-clock time lost due to locking could easily be really substantial. Even worse, this effectively serializes HTTP requests, limiting the system to one cookie-invoking request at a time. That’d explain a lot of the weird behavior that I’ve seen in Safari, where one slow website will block a dozen tabs from loading. Does anyone know if Tiger has a new cookie implementation? Any decent database system will solve all of these problems.
Tiger Update: It still uses ~/Library/Cookies/Cookies.plist–no SQLite. So it’s this is probably still a problem with Tiger.
Posted in Mac stuff | Tags cache, macosx, safari, speedup | 12 comments
