Interesting, my webkit.framework, and all files in it, don't seem to
have been touched. They have a creation and modification date of
September 2, 2008 which I presume is the day this Macbook had its
system installed. Odd, I would've expected at least one file to have a
different modification date if Webkit has been updated.
On Nov 15, 2008, at 15:38, Esther wrote:
Hi,
Jacob wrote:
As far as I can tell, the update to Safari was just that. It didn't
touch the Webkit framework that OS X, and consequently all
applications, use by default.
Apparently a few (3) of the security fixes made to Safari 3.2 were
made by fixes to WebKit:
"WebKit, the core rendering engine used in Safari, also received
some attention in the update. In one vulnerability it fixed, an
attacker could have gained unauthorized access to a Safari user's
local files. The flaw is due to the fact that Safari's WebKit plug-
in structure does not block it from launching local addresses."
According to Apple's advisory, "This update addresses the issue by
restricting the types of URLs that may be launched via the plug-in
interface."
A word of caution: when updating webkit, keep your previous build--
i.e. the build you were running before you updated--in case the new
build doesn't work properly. These are SVN builds, after all, they
are the bleeding edge.
Yes, although most of the current builds have worked pretty well,
there can still be problems. On of the reasons for mentioning the
freeware program NightShift, is that not only will this program
check whether you have the latest nightly build of WebKit and
install it (automatically, if you choose, and even through a cron
job if you want to have this run at a time you're not actively using
your computer), it also gives options for reverting to an earlier
build if you found the current one too buggy.
On Nov 15, 2008, at 00:30, Mike Arrigo wrote:
So far, web kit is working great for me. It looks like safari 3.2
is still using an older version of the engine, the bug of having
to refresh the page to get it to work is still there. Haven't seen
this at all with web kit.
This is the bug where sometimes when a web page finishes loading,
VoiceOver can't interact and you have to use Command-R to reload it
and expose it to VoiceOver before you can interact? Yes, that's one
of the fixes in WebKit. So is correct handling of some tags that
would otherwise appear unlabeled, making multi-select list boxes
visible, and making contextual menus available for links for the
first time (no more having to control-click in order to download and
save PDF and mp3 files). Any other new fixes?
Cheers,
Esther
