• Bitte schaltet eure Ad Blocker aus. SLinfo kann nur betrieben werden, wenn es durch Werbung Einnahmen erzielt. Vielen Dank!!
  • Wir freuen uns, wenn du dich in unserem Forum anmeldest. Bitte beachte, dass die Freigabe per Hand durchgeführt wird (Schutz vor Spammer). Damit kann die Freigabe bis zu 24 Stunden dauern.
  • Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Website zu analysieren. Sie geben Einwilligung zu unseren Cookies, wenn Sie unsere Webseite weiterhin nutzen.

Lordgreggreg verlässt Emerald Team

Status
Für weitere Antworten geschlossen.
@ MystyMiracle,
ich hatte einen Open Sim auf meinem Rechner, aber wenn ich in SL teste und baue bin ich für Freunde und Kunden besser erreichbar. Vielleicht gibt es ja doch noch einen alternativen Viewer der temporär hochladen kann.
Gruß
Sand

Dann schaue Dir bitte den Rainbow Viewer an, der kann Bilder auch temporär hochladen, hat auch einige Features von Emerald dabei, etwa Doppelklick-TP oder Radar. Und ist auf 1.22 aufgebaut, dh. weniger prozessorhunrig als Emerald oder Cool, die auf 1.23 aufbauen.

Boy Lane - The final Final Rainbow Viewers

Der wird zwar nicht mehr weiterentwickelt, und er steht auch nicht im Verzeichnis der TPV, aber ich halte ihn dennoch für Vertrauenswürdig. Er wurde von derselben Entwicklerin compilliert, die für H.Baukamp den Coolviewer für Windows compilliert hat.

Und was Emerald angeht. Klar man kann sagen, die Möglichkeit den Schadscode einzubringen animiert zum Misbrauch. Mit gleichen Argumenten begegnet man die Internetsperren: Ist die Technik mal da, kann man sie schnell misbrauchen und nicht nur die Kinderpornographie im Internet sperren, sondern auch mit die politische Gegner.

Ännlich denkt die GEZ, es reicht dass man ein empfangsfähigen Gerät im Hause hat, dass man es tatsächlich benutzt wird einem pauschal unterstellt. Und diese Argumentation trifft wiederum nicht immer auf Begeisterung.

Ich glaube es gibt einen Grundsatz, der ganz einfach lautet "Im Zweifel für den Angeklagten". Es ist nicht bewiesen worden dass Emerald sich böswillig verhält, außer dass da an wenig aussagekräftigen Information in die versendeten Bildern was eingepackt wird. Unehrenhaft hat sich das MS Team schon verhalten, mehrfach, aber bis jetzt ist das auch alles. Dem MS vorzeitig Böswilligkeit untestellen, halte ich an der Stelle aber für übertrieben.

Noch ein Gedanke. Die DLL ist eigentlich eine Bibliothek von Funktionen. Also eine Menge von Funktionen, die vom Viewer aufgerufen werden um irgendeine Aufgabe zu erledigen. Man kann im Primzip schon in eine Funktion Schadscode hinzufügen, der zusätzlich ausgeführt wird, wenn die Funktion aufgerufen wird.

Aber dieser Code muss mit Informationen auskommen die der Viewer an die Funktion liefert, entweder direkt im Funktionsaufruf oder von einer anderen DLL. Und ich stelle mir vor, dass dann auch der Quellcode des Viewers selbst geändert werden müsste, der offen liegt, oder die gelieferten DLLs. Sprich, die Entwickler müssten eine unklare Quellcode-Anderung dann als Indiz erkennen können, wenn ein Schadscode installiert werden soll. Ich kann mich da aber irren.

LG
 
Aber dieser Code muss mit Informationen auskommen die der Viewer an die Funktion liefert, entweder direkt im Funktionsaufruf oder von einer anderen DLL. Und ich stelle mir vor, dass dann auch der Quellcode des Viewers selbst geändert werden müsste, der offen liegt, oder die gelieferten DLLs. Sprich, die Entwickler müssten eine unklare Quellcode-Anderung dann als Indiz erkennen können, wenn ein Schadscode installiert werden soll. Ich kann mich da aber irren.

LG
Eine DLL hat über die normalen Betriebssystem APIs vollen Zugriff auf den Rechner, mit den gleichen Rechten die auch der ausführende Benutzer hat.

Der einzige Unterschied zu dem Programm und dessen statisch gelinkten Routinen besteht darin, daß die DLL erst spät, beim Starten des Programms eingebunden wird. Danach macht es keinen Unterschied mehr wo der Code steht, ob im Programm oder in der DLL.

Den Rainbow Viewer werde ich mir auch mal anschauen. Danke für den Tipp :)
 
Und was Emerald angeht. Klar man kann sagen, die Möglichkeit den Schadscode einzubringen animiert zum Misbrauch. Mit gleichen Argumenten begegnet man die Internetsperren: Ist die Technik mal da, kann man sie schnell misbrauchen und nicht nur die Kinderpornographie im Internet sperren, sondern auch mit die politische Gegner.

Der kleine, aber feine Unterschied: Hier wurde bereits mehrmals nachweislich Schadcode eingebaut! Zwei mal wurde zugesagt, den Code zu entfernen, beim ersten mal war er weiter drin, nur die Lib wurde verschlüsselt. Das flog auf, weil jemand den Schlüssel geknackt hat und siehe da: das Zeug war immer noch drin. Beim zweiten mal wurde wiederum der Codeschlüssel erheblich verschärft, ob der Code weiterhin drin ist, ist für niemanden nachvollziehbar.

Notabene, wir reden ja nicht von Programmierfehlern und Sicherheitslücken, sondern von bewusst implementiertem Schadcode.

Das macht einen ganz erheblichen Unterschied. Sicher, auch in Windows kann theoretisch jemand Code einschleusen - allerdings dürfte der Codeaudit bei Microsoft etwas anders aussehen als bei ModSys. Dort wird der Code an einem Punkt geprüft, an dem die ursprünglichen Programmierer keinen Zugriff mehr haben.
Das ist bei ModSys nach Lage der Dinge und der Struktur nicht machbar. Die Leute, die den Code sehen, werden nicht in die Prüfung der Libs eingebunden, die sie als reine Binary bekommen. Dort spielen dann, so man LGG glauben schenkt, auch finanzielle Interessen einzelner eine Rolle - und da werde ich misstrauisch.

Ännlich denkt die GEZ, es reicht dass man ein empfangsfähigen Gerät im Hause hat, dass man es tatsächlich benutzt wird einem pauschal unterstellt. Und diese Argumentation trifft wiederum nicht immer auf Begeisterung.

Ein Vergleich von Äpfeln mit Autos stößt auch nicht überall auf Begeisterung.
Ich glaube es gibt einen Grundsatz, der ganz einfach lautet "Im Zweifel für den Angeklagten". Es ist nicht bewiesen worden dass Emerald sich böswillig verhält, außer dass da an wenig aussagekräftigen Information in die versendeten Bildern was eingepackt wird. Unehrenhaft hat sich das MS Team schon verhalten, mehrfach, aber bis jetzt ist das auch alles. Dem MS vorzeitig Böswilligkeit untestellen, halte ich an der Stelle aber für übertrieben.
Es war zweimal Code drin, der da nicht hingehört. Punkt. Beim erstenmal wurde gesagt: Ist entfernt, die Bibliothek wurde verschlüsselt. Der Schlüssel wurde geknackt. der Code war immer noch drin. Wiederum wurde zugesagt, das zu entfernen, diesmal wurde die Verschlüsselung sehr hoch gesetzt - ob der Code immer noch da ist, weis zur Zeit niemand außer dem Programmierer selbst.

Hier von "nicht nachgewiesen" zu reden, ist schon gewagt. Es hat drin gestanden und es hat deswegen Beschwerden gegeben. Es ist versucht worden, es trotzdem wieder einzubauen und durch Verschlüsselung unkenntlich zu machen. Es wurde wieder beanstandet, und es wurde hochverschlüsselt - ob Code noch enthalten ist, weis keiner.

Was muss eigentlich passieren, damit das als "nachgewiesen" gilt und man misstrauisch wird?

Noch ein Gedanke. Die DLL ist eigentlich eine Bibliothek von Funktionen. Also eine Menge von Funktionen, die vom Viewer aufgerufen werden um irgendeine Aufgabe zu erledigen. Man kann im Primzip schon in eine Funktion Schadscode hinzufügen, der zusätzlich ausgeführt wird, wenn die Funktion aufgerufen wird.

Aber dieser Code muss mit Informationen auskommen die der Viewer an die Funktion liefert, entweder direkt im Funktionsaufruf oder von einer anderen DLL. Und ich stelle mir vor, dass dann auch der Quellcode des Viewers selbst geändert werden müsste, der offen liegt, oder die gelieferten DLLs. Sprich, die Entwickler müssten eine unklare Quellcode-Anderung dann als Indiz erkennen können, wenn ein Schadscode installiert werden soll. Ich kann mich da aber irren.

Bibliotheksfunktionen sind im Grunde nichts anderes als Unterprogramme, die in eine externe Datei ausgelagert wurden. Da können - notabene: Können! - ausschließlich solche Subroutines drin sein, die nur auf externen Aufruf, ggf. mit Parametern, reagieren. Von "Das muss so sein" kann jedoch keine Rede sein.

Nur ein ausgesprochen primitives Beispiel:

In der Bibliothek ist irgendeine Subroutine, die regelmäßig vom Programm aufgerufen wird, z.B. der Aufbau des Fensters. Der Aufruf kommt vom Programm mit irgendwelchen Daten. Die Subroutine/Funktion ist jedoch einkompiliert und daher nicht mehr ohne weiteres nachvollziehbar. Sie kann ohne Probleme Code enthalten, der z.B. Daten des Fensters zusätzlichirgendwohin übermittelt. Pech, wenn es das Login-Fenster ist. Es könnten auch Funktionen der Bibliothek ggf. weitere Funktionen innerhalb der Bibliothek aufrufen, die ihrereseits unerwünschten Code enthalten.

Schon etwas weniger primitiv:
Beim ersten Aufruf irgend einer beliebigen Funktion wird der Aufruf einer anderen Funktion z.B in den PC-Timer eingeklinkt. Die Funktion wird dann - ohne jede Aufforderung durch das Hauptprogramm - immer wieder automatisch ausgeführt. Daten kann so eine Funktion auch selbstständig sammeln, sie ist dazu nicht an das Hauptprogramm geknebelt.

Das wäre, da sich alles innerhalb der verschlüsselten Bibliothek abspielt, nicht nachvollziehbar. Nach außen hin führt die Lib dann ganz brav aus, was sie soll, ohne jede Änderung im Hauptprogramm. Das sie intern so ganz zufällig noch etwas mehr macht, sieht man nicht.

Das ist die böse Kombination, die hier gespielt wird: Wenige oder nur einer baut eine verschlüsselte Lib, die niemand kontrollieren kann - der Rest muss sie nutzen, ohne genau zu wissen, was neben den "Für SL optimierten" Funktionen noch verändert oder eingebaut wurde.

Dafür haben große Softwarefirmen einen Codeaudit - eben damit nicht einzelne etwas "drehen" können. das hat Emerald nicht. Da gibts nur einen, der den Code baut - und der hat bereits zweimal nachweislich etwas eingebaut, was da nichts verloren hat.

Wer in der Situation da weiter vertraut, möge das tun. Ich nicht.
 
Er hat eingie Daten übermittelt. Siehe z.B. den Blogeintrag von LGG oder einfach mal nach emkdu googeln, da findet sich das eine oder andere...

Was er damals gemacht hat, ist daneben eine Sache. Was er heute macht bzw. ob es ihn zur Zeit noch gibt eine ganz andere. Ob es ggf.wieder einen geben wird, wenn die Wogen sich geglättet haben, steht noch auf einem anderen Blatt.

Für mich persönlich zählt der Fakt, dass versucht wurde, eine Übermittlungsfunktion zu verbergen - ob diese Funktion Trallalapipa übermittelt oder Logindaten, ist in Anbetracht der Vorgehensweise von ModSys für mich unerheblich. Mittlerweile ist die Verschlüsselung so hoch, dass sie mit heutigen Mitteln nicht ohne weiteres knackbar ist - also kann wieder eine Übertragungsfunktion drin sein oder nicht oder erst beim übernächsten - Vertrauenssache ist was anderes.

Das Argument, das man mit einem Netsniffer nichts sehen kann, ist nur bedingt zutreffend. Die Netsniffer-Logs sind in aller Regel ein "Snapshot" - anderenfalls werden die Datenmengen so riesig, dass ein View kaum noch möglich ist. Jeder nicht völlig tumbe Trojaner ist heute so programmeirt, dass er keinen permanenten und dadurch vglw. leicht auffindbaren Datenstrom produziert. Der verschlüsselt udn komprimiert die Daten und schickt sie dann in einem kurzen Burst weg - man muss schon Glück haben, das mit einem normalen Sniffer zu finden.

Geht das auch noch an einem Empfänger innerhalb von SL, hat man nur noch sehr wenig Chancen das überhaupt zu finden - das von dem "normalen" Datenverkehr von SL zu trennen, bräuchte eine InDeep-Analyse jedes einzelnen Datenpaketes - viel Spaß dabei.
 
Es war doch aber bisher noch überhaupt kein Schadcode in der dll!

Die dll hat lediglich den Dateipfad der dll in die Metadaten der default-Kleidertexturen geschrieben, bei Linux/Mac stand da dann standardmäßig "/home" (der Username wurde abgeschnitten...) und bei Windowsrechnern eben "c:\program files(x86)\Emerald Viewer".

Bei diesen Beispielen, bei denen man einen Windows-Usernamen im Inertia-Copybot sieht, da wurde das Programm gezielt auf eine unter Windows ziemlich unübliche Art und Weise in die "Eigene Dateien" Ordner installiert. Also gezielt nicht in den Ordner, der für die Programmdateien vorgesehen ist.

Es wurden aber bei der ganzen Geschichte keine privaten Daten an Server von modularsystems übermittelt. Es gab keine auffälligen Schreib/Lesezugriffe. Lediglich der Pfadname war in der Textur.

Und somit geht es bei der ganzen Diskussion um die dll eigentlich nur um eine theoretische Möglichkeit Schadcode einzubauen.

Man kann sich auch drüber unterhalten, dass Kochmesser in Privatbesitz für einen brutalen Mord verwendet werden könnten. Diese theorethische Möglichkeit besteht. Und jeder fände es wohl reichlich absurd wenn man wegen der Gefahr, die von so einem Messer ausgeht deswegen alle Messer > 12cm Klinge daheim an die Wand ketten müsste, wie es etwa in manchen Einrichtungen der Fall ist.
 
Ob mir der Code geschadet hat, und ich ihn deshalb Schadcode nenne, oder ob der Code einfach irgendeinen Pfad auf meinem PC übermittelt hat und deshalb Harmloscode genannt werden muss ...

Was wichtig ist, hat Yistin eindeutig und recht klar dargelegt:

- Es war Code in der Lib, der da nicht reingehört
- Es ist versprochen worden, den zu entfernen
- Das Versprechen wurde gebrochen, statt dessen wurde verschlüsselt
- Der Bruch des Versprechens wurde aufgedeckt
- Daraufhin wurde noch besser verschlüsselt.

Ich habe vollstes Verständnis dafür, dass LGG einem Team, das so handelt, nicht mehr vertraut.

Und auch ich kann einem solchen Team nicht vertrauen, egal ob der Code geschadet hat oder Lindendollars an Nutzer verteilt hat.
 
Das Argument, das man mit einem Netsniffer nichts sehen kann, ist nur bedingt zutreffend. Die Netsniffer-Logs sind in aller Regel ein "Snapshot" - anderenfalls werden die Datenmengen so riesig, dass ein View kaum noch möglich ist. Jeder nicht völlig tumbe Trojaner ist heute so programmeirt, dass er keinen permanenten und dadurch vglw. leicht auffindbaren Datenstrom produziert. Der verschlüsselt udn komprimiert die Daten und schickt sie dann in einem kurzen Burst weg - man muss schon Glück haben, das mit einem normalen Sniffer zu finden.

Netsniffer Logs sind kein Snapshot. Und für einen modernen Rechner ist es kein Problem die Ausgabe von tcpdump nicht auf dem Schirm anzuzeigen, sondern in eine Datei zu speichern.

Selbst wenn du dann irgendwann 5 GB an Netzwerkdaten mitgeloggt hast (was zwei Wochen eingeloggt in SL entspricht) - wer mit sed,grep & Co. und Wireshark umgehen kann, für den ist es überhaupt kein Problem da z.B. erst mal alle irrelevanten Daten rauszufiltern und nach verdächtigen Verbindungen zu suchen usw.
 
Netsniffer Logs sind kein Snapshot. Und für einen modernen Rechner ist es kein Problem die Ausgabe von tcpdump nicht auf dem Schirm anzuzeigen, sondern in eine Datei zu speichern.

Selbst wenn du dann irgendwann 5 GB an Netzwerkdaten mitgeloggt hast (was zwei Wochen eingeloggt in SL entspricht) - wer mit sed,grep & Co. und Wireshark umgehen kann, für den ist es überhaupt kein Problem da z.B. erst mal alle irrelevanten Daten rauszufiltern und nach verdächtigen Verbindungen zu suchen usw.

Mal was anderes?

Wieso sollte ich mir ein Programm auf den Rechner laden, zu dem ich so wenig Vertrauen habe, dass ich ständig mit Netsniffern dessen Aktivitäten beobachten muss?
 
Ich hatte mal mit Wireshark gespielt. Der erfasste Datenstrom war Kontinuirlich, dh ich konnte von der Anfrage einer Webseite bis zu ihrem vollständigen Laden die Paketenkette lückenlos einsehen. Zugegeben, das Ergebnis zu analysieren hat dann halbe Stunde gedauert und beim SL Klient wäre das viel länger, aber machbar. Ich bin daher nicht einverstanden dass man per Netsniffler nur Snapshoots betrachtet. Eine derartige Analyse wäre keine Analyse.

Man könnte aber die Erfasste Datenmenge reduzieren, wenn man die vertrauliche Ziele ausschließt, z.b. das Versenden an die LL Server als vertraulich ansieht und die Pakete nicht mehr erfasst. Dann hätte man wirklich nur Snapshoots und es stünden irgendwann nur die Mediaserver und ein Spionageserver auf der Paketliste, auch bei tagelangen Surfen
 
Ich hatte mal mit Wireshark gespielt. Der erfasste Datenstrom war Kontinuirlich, dh ich konnte von der Anfrage einer Webseite bis zu ihrem vollständigen Laden die Paketenkette lückenlos einsehen. Zugegeben, das Ergebnis zu analysieren hat dann halbe Stunde gedauert und beim SL Klient wäre das viel länger, aber machbar. Ich bin daher nicht einverstanden dass man per Netsniffler nur Snapshoots betrachtet. Eine derartige Analyse wäre keine Analyse.

Man könnte aber die Erfasste Datenmenge reduzieren, wenn man die vertrauliche Ziele ausschließt, z.b. das Versenden an die LL Server als vertraulich ansieht und die Pakete nicht mehr erfasst. Dann hätte man wirklich nur Snapshoots und es stünden irgendwann nur die Mediaserver und ein Spionageserver auf der Paketliste, auch bei tagelangen Surfen

Was machst du, wenn der Empfänger z.B. ein Bot innerhalb SL ist?
dann hast du einen Datenstrom, in dem selten mal ein komprimiertes und verschlüsseltes, also vom Inhalt her nicht zu erkennendes Paket an eine deiner vertrauenswürdigen Server geht.

Nebenbei, bezogen auf eine gelegentliche Übersendung ist auch eine mehrtägige Aufzeichnung u.U. ein Snapshot. Es gibt m. W. mindestens zwei Trojaner, die Daten erst nach Wochen der Sammelei übermitteln - viel Spaß beim Auffinden, wenn etwas in einem Viewer ähnlich verfährt. Das wird mit Sniffern a la Wireshark eine ziemliche Geduldsprobe mit fragwürdigem Ausgang.
 
Es war doch aber bisher noch überhaupt kein Schadcode in der dll!

Die dll hat lediglich den Dateipfad der dll in die Metadaten der default-Kleidertexturen geschrieben, bei Linux/Mac stand da dann standardmäßig "/home" (der Username wurde abgeschnitten...) und bei Windowsrechnern eben "c:\program files(x86)\Emerald Viewer".

Bei diesen Beispielen, bei denen man einen Windows-Usernamen im Inertia-Copybot sieht, da wurde das Programm gezielt auf eine unter Windows ziemlich unübliche Art und Weise in die "Eigene Dateien" Ordner installiert. Also gezielt nicht in den Ordner, der für die Programmdateien vorgesehen ist.

Es wurden aber bei der ganzen Geschichte keine privaten Daten an Server von modularsystems übermittelt. Es gab keine auffälligen Schreib/Lesezugriffe. Lediglich der Pfadname war in der Textur.

Text vom LGG-Blog:
I did not realize at the time that emkdu was added, that it could be used to add in code I was not able to see. These things were done behind my back, it was found out by others that code was placed in that braodcasted your viewers title bar and executable path in a obfuscated manner. This was addressed, promised to be fixed, and (luckily) people broke through the now encrypted layer to find out that it was not. Of-course, it has been promised to be fixed a third time, but now with an encryption level too high to be broken.
Ich habe zu der Zeit nicht bemerkt, das emkdu eingeführt wurde, das benutzt werden kann, Code einzufügen, den ich nicht sehen kann. Das wurde hinter meinem Rücken gemacht, es wurde durch andere festgestellt, dass dort Code eingefügt war, der die Titelzeile des Viewers und den Pfad der ausführbaren Dateien verschlüsselt übertragen hat. Das wurde angesprochen, es wurde versprochen, das zu ändern, und glücklicherweise haben Einige das nun verschlüsselte Layer geknackt und festgestellt, dass das nicht der Fall war. Natürlich wurde zum dritten mal versprochen, das zu ändern, aber nun mit einem Verschlüsselungslevel, der zu hoch zum Knacken ist.

Dem hat ModSys nicht wirklich widersprochen.

Fazit:

1. Es war Code drin, der dort selbst nach Meinung eines Entwicklers nicht hin gehört.
2. Bis jetzt hat der bekannt gewordene Code nichts all zu wichtiges übermittelt, obwohl ich auch "Executable PathS" nicht gern in Umlauf sehe.

Wer garantiert eigentlich, das jemand, der mehrmals versucht hat, dort versteckten Code unterzubringen, und bereits zwei mal getestet hat, wie hoch eine Verschlüsselung sein muss. das nicht ein drittes mal versucht?

Wer garantiert, dass ers dann nicht etwas anderes übermittelt als Dateipfade?

Hier hat ein Einzelner die Fäden in der Hand, nach den Aussagen von LGG sind dort bereits Gelder recht undurchsichtig geflossen.

Mir ist das zu wackelig. Ist ja nett, per Im Zweifel für den Angeklagten zu argumentieren. Für mich argumentiere ich da eher mit "Wer einmal lügt....."
 
Und wenn man den Netzwerkverkehr erkennt wäre es ohnehin schon zu spät....

Es geht ja aber auch gar nicht um versteckten Netzwerkverkehr sondern es geht zunächst um verschlüsselte Metadaten angehängt an Texturen. Und was dort hineingeschrieben wird, wird in Zukunft und bei geeigneter Verschlüsselung niemand wissen. Die Möglichkeit zukünftig noch andere Dinge in einer DLL unterzubringen besteht natürlich ebenfalls.

Ob man den Leuten um Phlox soweit vertraut um das zuzulassen muss aber letztlich jeder für sich entscheiden, mit OpenSource und Transparenz hat das nicht mehr viel zu tun.
 
Wieso sollte ich einem Produkt vertrauen, dem maßgebliche Entwickler den Rücken kehren, weil sie ihrem eigenen Produkt nicht mehr vertrauen?

Das muss jeder für sich selber entscheiden; ich tue es jedenfalls nicht, da kann Shirley hier noch so häufig Postings technischer Art nach dem Motto "Es ist doch gar nichts schlimmes passiert" hier schreiben.

Dabei übersieht Shirley nur leider immer und immer wieder, dass es neben der technischen Ebene - auf der vielleicht wirklich nichts schlimmes passiert ist, darüber möchte ich jetzt gar nicht weiter diskutieren - auch eine menschlich-organisatorische Ebene gibt.

Wenn ich mich auf dieser Ebene bewege und sie betrachte, dann ist da in der Tat genügend Mist gelaufen, wie es schon Danziel treffendst beschrieben hat, der einem doch nur noch zweifeln lässt. Da geht es nämlich um Zuverlässigkeit und Vertrauen in ein Produkt.
 
Meine nächste Frage wäre tatsächlich gewesen, was denn übertragen wurde damit der Code den Namen Schadcode verdient.
Wie ich das erkennen kann, nichts Kritisches. Aber es ist möglich Schadcode so an jeglicher Kontrolle vorbei einzuschleusen.

Nun kann man den Entwicklern vertrauen, dass sie das nicht machen oder eben wieder nicht.
Punkt. (für mich)
 
Ich vertraue keinem, der die Nutzer bereits zwei mal mit "Das wird entfernt" belogen und lediglich den Code höher verschlüsselt hat. Mittlerweile ist es so hoch verschlüsselt, dass kein Nachweis mehr möglich ist, Einblick in den Quellcode gibts nicht. Wer mich da bekrückt, der bekrückt mich auch,, wenn es um inhalte und Daten geht.

Emerald und seine Komponenten bleiben bei mir von der Platte - endgültig.

Da ist so viel schief gelaufen, LGG ist m. W. der Dritte, der sich unter Protest aus dem Emerald-Team verabschiedet....

Barth hat da völlig recht. Neben aller Technik, ich habe kein Vertrauen zu einem Progger, dass auf Vorhaltungen mit höherer Verschlüsselung reagiert, damit User das nicht mehr nachweisen können. Das ist nicht vertrauenswürdig.

Mysty trifft den Nagel auf den Kopf:
Warum Emerald vertrauen, wenn selbst die Entwickler dem eigenen Team und dem Produkt nicht mehr vertrauen?
 
Die Leute die jetzt den Emerald verteidigen, werden die sein, die dann am lautesten jammern wenn doch was passiert. Ich sehe es schon kommen. :roll:
 
Die Leute die jetzt den Emerald verteidigen, werden die sein, die dann am lautesten jammern wenn doch was passiert. Ich sehe es schon kommen. :roll:
Für mich ist ein Wechsel von Emerald auf einen anderen Viewer - trotz des Debakels mit dieser DLL - wie ein Wechsel von "Lucid Lynx" auf Suse 9.1 oder gar Windows XP - Linux User werden wissen was ich meine 8). Kommt also nur sehr bedingt, im Notfall quasi, in Frage. Umstieg auf V2 und ähnliche? Im Läwe net. Da warte ich dann eher auf die Browserversion, ehe ich diese Mist-UI auf meinen Bildschirm lasse.:evil:
Egal was vorgefallen ist und egal was das für eine Enttäuschung auch für mich bedeutet, weil auch Vertrauen in gute Freunde verloren gegangen ist: Unter den Viewern ist der Emerald m.E. nachwievor mit der berühmten "eierlegenden Wollmilchsau" vergleichbar - es gibt nichts annähernd Optimales.
Verschlüsselte DLL hin oder her: ich bleibe vorerst beim Emerald.
 
du kannst lt. den Blogs die emkdu.dll löschen und durch die llkdu.dll ersetzen. Das umgeht zumindest diesen Knackpunkt.
 
Status
Für weitere Antworten geschlossen.

Users who are viewing this thread

Zurück
Oben Unten