WebKit sandboxing conflict causes Safari block-A font problem

Recently we discussed a problem that has cropped up in Safari 5.1 running under Lion, in which the browser will display Web pages with block-A characters instead of the desired text. We initially suggested that people check their fonts and rebuild their font caches. However, this issue shows up only in Safari and Chrome, which both use the WebKit engine, and specifically for those users who have font manager tools installed. It turns out this issue is likely a compatibility problem between how third-party font managers store fonts and a limitation in the WebKit framework that deals with the new sandboxing features in Safari and Lion.

That may seem like a mouthful, but it overall is a fairly simple idea.

What is sandboxing?
In order to enhance the security of Web processes, Apple has implemented new sandboxing techniques in the WebKit framework. Sandboxing is a method of isolating a process and the resources it has access to, in order to prevent any malicious or faulty code in it from interfering with other running processes and system resources.

Sandbox configuration in OS X is done through SB configuration files that are set up for individual process types. These include applications, push services, the system clipboard, the system preferences, VPN services, and other system features including core technologies. In addition to centralized configuration files, some special processes defined in system frameworks (with WebKit being one of them) may have their own unique sandboxing configurations to either include or exclude specific system resources required for these processes to run in an isolated and secure mode.

When it comes to the block-A issue, the problem is that the special locations that third-party font managers use to store their font collections may differ from the locations specified in the sandbox configuration for WebKit.

OS X Font setup
OS X's font setup has some core fonts that are always active, which are located in the /System/Library/Fonts/ directory. These include Times, Helvetica, Geneva, Symbol, and other system fonts that need to be active at all times to display basic text for the system. In addition to the basic system fonts there is a font called LastResort that consists of nothing but the block-A characters seen by people experiencing this problem. This LastResort font is, as its name suggests, the font that the system will use if no substitute font can be located with which to display the text being presented. In essence, the use of this font is the system telling you that text is present and being rendered, but it has no way of showing it to you.

Besides these core fonts, OS X has two other default locations in the global library and user library folders, so there are three locations total for storing fonts in the system:

/System/Library/Fonts
/Library/Fonts
/username/Library/Fonts

What all these locations have in common is the subdirectory path /Library/Fonts, which is the path expected by the system for locating font collections. While these are the default paths, you do not necessarily need to use them for storing fonts, and can set up font collections in pretty much any folder you would like. The problem with doing this is that in order for custom paths to be used, applications will need to be aware of them. Third-party font manager tools set up these paths properly, but in Apple's new sandboxing technique, third-party font path locations may be excluded from the resources available to the sandbox.

This exclusion happens in the WebKit sandbox configuration file. As a result, if your fonts are managed by a third-party font manager tool, then the system may resort to using the LastResort font instead of properly substituting fonts or showing the intended one.

How to fix it
This issue may be a bug, or it may be an intentional restriction by Apple that the developers of third-party font managers will have to contend with. For now, at any rate, if you are seeing this problem then the following options are available to try:

1. Stop using font managers
   The easiest option is to stop using your font manager. If you do not extensively work with fonts and have a font manager utility installed either as a demo or just to try out, then you might consider uninstalling the manager and disabling it. This should reset the system's font configuration to use the default font subdirectories noted above, and allow the WebKit framework sandbox configuration to properly access the fonts.

2. Consolidate fonts into the standard font locations
   If your font manager supports it, consolidate your font collections in the aforementioned default font directories, instead of having the fonts managed in separate folders. This should allow the font manager to continue functioning while still allowing the fonts to be accessed by the system and sandboxed processes.

3. Edit the WebKit sandbox configuration file
   The last option is to edit the sandbox configuration file that is not allowing access to the third-party font collection locations. Ultimately this is a fairly simple idea, but may be moderately complex to do as it requires editing a system file, and also depends on the specific directories your font manager uses.

   The WebKit sandbox configuration file is located in the WebProcess application in the WebKit framework, so to get to it you will need to follow this procedure:

   1. Go to the /System/Library/PrivateFrameworks/WebKit2.framework/ folder.

   2. Right-click (Option-click) the WebProcess application and choose "Show Package Contents."

   3. Navigate to the /Contents/Resources/ folder, and you should see a file called "com.apple.WebProcess.sb".

   The com.apple.WebProcess.sb process is the sandbox configuration file, and while you can edit it directly in the current folder with some editor applications, it is best to back up the file and edit a duplicate of it. Doing this is not only safer, but allows you to edit the file with Apple's TextEdit program:

   1. Drag the file to your desktop (it should copy there).

   2. Rename the original file "com.apple.WebProcess.sb.bak" or something similar to indicate it is a backup.

   3. Right-click the file on your desktop, choose "Open With," and then open it with TextEdit.

   4. Locate the section called "Read-only preferences and data" (this should be commented with two semicolons before it), under which you should see an "(allow file-read*" line followed by a listing of paths and file pointers in parentheses that are lumped into groups like "Basic system paths," "Plugins," and "System and user preferences." You will be adding file paths to this list.

   5. Add the following entries to this list, making sure they are properly indented and look exactly as they are listed here. It does not matter where you add them in the list, but you can add them immediately after the "(allow file-read*" line to make things easier:

      (home-subpath "/FontExplorer X")
      (home-subpath "/FontExplorer X/Font Library")
      (home-subpath "/FontAgent Pro Fonts")
      (home-subpath "/Library/FontAgent Pro")
      (subpath "/Library/FontAgent Pro")

      Note that these paths are for FontExplorer X and FontAgent Pro, so if you have another font manager you should check with the developer to find out the specific paths to use, or you can attempt to guess the paths by browsing your system and checking your program's settings.

   6. Save and close the file.

   7. Copy the edited file from your Desktop to the framework folder, and authenticate when prompted.

   8. Change ownership and permissions of the file by opening the Terminal utility (in the /Applications/Utilities/ folder) and typing "sudo chown root:wheel" followed by a single space. Then drag the file you just copied to the Terminal window and press Enter, and then supply your password.

   When this is done, your fonts should now be included in the WebKit framework's sandboxed processes, and Safari and Chrome should now display Web pages correctly. Do keep in mind that this fix is a bit of a crude approach, and since the WebKit sandboxing is relatively new there is a possibility it could lead to odd behavior. If you notice problems after performing these edits, you can always delete the edited file and change the backup to its original name, and that should restore all prior functionality.

For those who are more visual, here is an excellent video tutorial on how to apply similar edits to the sandbox configuration file:

Note that in the sandbox configuration file you will see a number of commented lines stating "FIXME: This should be removed when URL is fixed," followed by one or more paths to various system resources. These paths are likely included as specific workarounds for bugs and known issues referenced by the URL (an Apple internal bug tracking URL only), and since one of these paths is a home subpath for the "/Library/Fonts" directory, it indicates that there maybe be a few known issues involving WebKit sandboxing and the handling of fonts that will likely be fixed in the future.

Questions? Comments? Have a fix? Post them below or e-mail us!
Be sure to check us out on Twitter and the CNET Mac forums.