Autor: mbs
November 20, 2010, 10:43:34
Um Flos Erklärung vielleicht noch mit ein paar drastischen Worten 
zu ergänzen:
"Add-Ons" wie Glims verwenden eine ähnliche Angriffstechnik wie Computerviren, um sich in fremdem Code einzunisten. Der Entwickler eines solchen Programms versucht, zu erraten, wie ein bestimmter technischer Aspekt von Safari funktioniert und injiziert dann von außen seinen eigenen Code, der Teile von Apples Originalcode "zerstört" und diese durch sein eigenes Programm ersetzt.
Zum einen ist das Problem, dass solche Entwickler niemals wissen können, in welchen Fällen und zu welchen Zwecken die angegriffenen Teile des Originalcodes überhaupt in Safari gebraucht werden. Möglicherweise gibt es Fälle, in denen der Code nur funktioniert, wenn er genauso bleibt, wie er von Apple gemacht wurde. D.h. die manipulierte Variante "vergisst", einige Spezialfälle zu berücksichtigen, die in der Praxis aber gebraucht werden. Zusätzlich können Sicherheitsmaßnahmen außer Kraft gesetzt werden und durch den fremden Code wird auch die digitale Versiegelung von Safari gebrochen.
Zum anderen kann es sein, dass beim nächsten Update von Safari Apples Originalcode ganz andere Dinge tut oder sich an einer ganz anderen Stelle befindet. Da das Add-On ja von außen quasi blind am Code der bisher bekannten Varianten von Safari herumpfuscht, kann es sein, dass Safari nach dem Update durch die Codemanipulation wirklich zerstört wird und überhaupt nicht mehr funktioniert, was man dann ja auch im Forum immer wieder lesen kann.
Extensions dagegen verwenden eine von Apple offiziell dazu konzipierte Schnittstelle, um Safari zu ergänzen. Jede Extension wird dabei zusätzlich durch die Sandbox-Technik von Mac OS X geschützt, d.h. eine unabhängige Prüfinstanz im System schaut der Extension bei jedem Kommunikationsvorgang mit Safari und mit der Außenwelt auf die Finger und würde die Extension sofort abbrechen, wenn sie etwas erkennbar Unzulässiges macht.
zu ergänzen:"Add-Ons" wie Glims verwenden eine ähnliche Angriffstechnik wie Computerviren, um sich in fremdem Code einzunisten. Der Entwickler eines solchen Programms versucht, zu erraten, wie ein bestimmter technischer Aspekt von Safari funktioniert und injiziert dann von außen seinen eigenen Code, der Teile von Apples Originalcode "zerstört" und diese durch sein eigenes Programm ersetzt.
Zum einen ist das Problem, dass solche Entwickler niemals wissen können, in welchen Fällen und zu welchen Zwecken die angegriffenen Teile des Originalcodes überhaupt in Safari gebraucht werden. Möglicherweise gibt es Fälle, in denen der Code nur funktioniert, wenn er genauso bleibt, wie er von Apple gemacht wurde. D.h. die manipulierte Variante "vergisst", einige Spezialfälle zu berücksichtigen, die in der Praxis aber gebraucht werden. Zusätzlich können Sicherheitsmaßnahmen außer Kraft gesetzt werden und durch den fremden Code wird auch die digitale Versiegelung von Safari gebrochen.
Zum anderen kann es sein, dass beim nächsten Update von Safari Apples Originalcode ganz andere Dinge tut oder sich an einer ganz anderen Stelle befindet. Da das Add-On ja von außen quasi blind am Code der bisher bekannten Varianten von Safari herumpfuscht, kann es sein, dass Safari nach dem Update durch die Codemanipulation wirklich zerstört wird und überhaupt nicht mehr funktioniert, was man dann ja auch im Forum immer wieder lesen kann.
Extensions dagegen verwenden eine von Apple offiziell dazu konzipierte Schnittstelle, um Safari zu ergänzen. Jede Extension wird dabei zusätzlich durch die Sandbox-Technik von Mac OS X geschützt, d.h. eine unabhängige Prüfinstanz im System schaut der Extension bei jedem Kommunikationsvorgang mit Safari und mit der Außenwelt auf die Finger und würde die Extension sofort abbrechen, wenn sie etwas erkennbar Unzulässiges macht.
