• 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.
Man hat nur dann eine Chance auf einen guten und sauberen Viewer, wenn man diejenigen unterstützt, die über Jahre gute Arbeit geleistet haben und eben jenen, die jetzt den Ruf einer ganzen Gruppe von Entwicklern in den Schmutz gezogen haben, seine Unterstützung versagt.
Das haben letztendlich auch die Entwickler so gesehen, die sich aus dem Projekt zurückgezogen haben, weil sie gesehen haben, dass der Emerald von innen heraus nicht mehr zu retten ist. Nur der Druck von aussen könnte die Leute von ModSys langfristig dazu bewegen, die führenden Köpfe auszutauschen und sich wieder auf einen sauberen Kurs zu besinnen.
Solange jedoch die User der Führungsriege innerhalb von ModSys, durch weiteres kritikloses Nutzen des Viewers, klar machen, dass es ihnen egal ist was hier mit diesem Viewer gemacht wurde und künftig wird, solange wird man bei ModSys auch keinen Grund sehen, den Kurs zu ändern.
 
@Yistin Usher: LGG warnte aber auch davor, dass ab sofort die Binaries zentral auf einem Buildserver erstellt werden, zu dem nicht alle zugriff haben. D.h. es gibt die Möglichkeit das Code, der nicht im Sourcecode veröffentlicht wird trotzdem in die Binaries einfliesst. (Das ist zwar gegen die GPL, aber davon lassen sich manche vermutlich relativ wenig abhalten)
Vorsicht also bei "neuen" Binaries - dort könnte viel mehr faul sein als nur die closed source library.

mfg
Alex
 
Na ist doch super Yistin!
Eine Diskussion über Vertrauen kann eh nie objektiv sein.

@Janina
Ich denke eher das "diese Leute" gar nix mehr sagen würden, wenn denn was passiert.

Mal ne technische Frage, wir reden doch von objektorientierter Programmierung oder? Ein Vorteil ist ja die Datenkapselung. Sprich, wenn eine nicht open source DLL accountgebundende Daten an wen auch immer schicken will müssen diese Daten Selbiger DLL erst übergeben werden. Oder sehe ich das Falsch?
Was ich damit sagen will, ist das ein eventueller Misbrauch von SL-Daten im normalen Quelltext des Viewers nachgewiesen werden könnte. So eine DLL Datei muss ja eingebunden werden, die Klassen initialisiert und eventuell mit Daten gefüttert werden. Einfach so kommt die da ja nicht ran oder? Das passt auch dazu das die Übermittelung von Daten erst durch externe im Datenstream ? nachgewiesen wurden und nicht durch eigene Entwickler wie LGG.

Also wenn es um den Misbrauch von SL-Daten geht erschließt sich mir die Panik noch nicht so richtig. Denn ein solcher Missbrauch würde im SL-Viewer-Code anfangen und wäre da ersichtlich. Oder sehe ich da was falsch?
 
Mal ne technische Frage, wir reden doch von objektorientierter Programmierung oder? Ein Vorteil ist ja die Datenkapselung. Sprich, wenn eine nicht open source DLL accountgebundende Daten an wen auch immer schicken will müssen diese Daten Selbiger DLL erst übergeben werden. Oder sehe ich das Falsch?
Was ich damit sagen will, ist das ein eventueller Misbrauch von SL-Daten im normalen Quelltext des Viewers nachgewiesen werden könnte. So eine DLL Datei muss ja eingebunden werden, die Klassen initialisiert und eventuell mit Daten gefüttert werden. Einfach so kommt die da ja nicht ran oder? Das passt auch dazu das die Übermittelung von Daten erst durch externe im Datenstream ? nachgewiesen wurden und nicht durch eigene Entwickler wie LGG.

Also wenn es um den Misbrauch von SL-Daten geht erschließt sich mir die Panik noch nicht so richtig. Denn ein solcher Missbrauch würde im SL-Viewer-Code anfangen und wäre da ersichtlich. Oder sehe ich da was falsch?

Datenkapselung in der OOP ist ein Konzept, daß helfen soll komplexe Strukturen zu organisieren, es hat aber keine Sicherheitsfunktion und läßt sich, insbesondere in C/C++, leicht umgehen. Um von der DLL aus auf Daten im Viewer zugreifen zu können, brauchst du prinzipiell (und vereinfacht gesagt) nur die Information darüber wo sie im Viewer abgelegt sind. Am Viewer selber sind keine Modifikationen erforderlich.

Natuerlich ist das ein Hack und keine saubere Programmierung wie sie im Lehrbuch steht, aber auch nicht wirklich kompliziert und er hinterläßt keine Spuren.

Allerdings würde ich mir weniger Sorgen darum machen solange es nur um SL und Session bezogene Daten geht. Viel bedenklicher finde ich die Möglichkeit der DLL auf das gesamte Betriebssystem zuzugreifen, inklusive aller Festplatteninhalte und Screenshots (alles das was der jeweilige Benutzer auch kann). Über den Weg käme man dann nebenbei auch einfacher an SL relevante Informationen heran.

Das sind technische Aspekte und Möglichkeiten die fast jedes Programm hat. Ich würde niemandem unterstellen wollen das auch auszunutzen, aber ich gebe auch nicht jedem meine Wohnungsschlüssel...
 
@Yistin Usher: LGG warnte aber auch davor, dass ab sofort die Binaries zentral auf einem Buildserver erstellt werden, zu dem nicht alle zugriff haben. D.h. es gibt die Möglichkeit das Code, der nicht im Sourcecode veröffentlicht wird trotzdem in die Binaries einfliesst. (Das ist zwar gegen die GPL, aber davon lassen sich manche vermutlich relativ wenig abhalten)
Vorsicht also bei "neuen" Binaries - dort könnte viel mehr faul sein als nur die closed source library.

mfg
Alex

Was das Problem nur mehr verschlimmert.

Yis
 
Das hieße doch aber in letzter Konsequenz, dass ich mir mit diesem Viewer dann nur noch einigermaßen sicher sein könnte, wenn ich
1. den Source Code penibel prüfe,
2. die emkdu.dll durch die llkdu.dll ersetze
3. das Ganze dann selbst kompiliere.

Ein wenig viel Aufwand, finde ich.
 
Das hieße doch aber in letzter Konsequenz, dass ich mir mit diesem Viewer dann nur noch einigermaßen sicher sein könnte, wenn ich
1. den Source Code penibel prüfe,
2. die emkdu.dll durch die llkdu.dll ersetze
3. das Ganze dann selbst kompiliere.

Ein wenig viel Aufwand, finde ich.


... Und das reicht nicht mal.
Wenn du "eingermaßen sicher" sein willst musst du auf jede Art von Code verzichten, den du nicht selbst kompiliert hast. Einfach weil überall Schadcode drin sein kann. Selbst offizielle Treiber von AMD und Asus hatten schon Viren.

D.h. du darfst auch keine llkdu.dll einsetzen, du darfst keine vivox Libraries, keine fmod.dll usw. einsetzen und musst alles selbst erstellen.

Ach ja: Auf Quicktime musst du auch verzichten. Und du musst die mozilla libs auch selbst kompilieren.

In jedem Schnipsel Code könnte schließlich was vesteckt sein.

In der Praxis kann man eine *.exe oder eine *.dll durchaus unter die Lupe nehmen und z.B. nachsehen, welche Threads bei der Ausführung gestartet werden, welche Daten wo hin versendet werden, was sich auf dem System alles tut usw. Auch wenn man keinen Sourcecode hat.

--> Wireshark Go deep.

--> GnuWin32 (vor allem grep, diff-utils, usw. sind da interessant)

--> Sysinternals Suite (hier sind z.B. Filemon, TCPView, Process explorer, Process Monitor u.ä. interessant)

--> Wer sich mit Assembler auskennt kann auch noch Decompiler einsetzen.
IDA Pro 5.7 kostet zwar über 450€ oder so, aber Version 4.7 gibts gratis für nichtkommerzielle Nutzung: Hex-Rays IDA Page : IDA Pro Freeware Download Page

In Win7 gibts auch noch den Ressourcenmonitor, mit dem man einen überblick bekommen kann.

und unter Unix/Linux/Mac gibts noch mehr Software die ebenfalls nichts kostet und mit der man sein System etwas im Auge behalten kann.
 
Shirley,

du hast nach wie vor nur die rein technische Seite im Blick, alles andere prallt an dir offensichtlich einfach ab.

Technisch ist das richtig - dann dürftest du nicht mal das BIOS des Rechners nutzen, eng betrachtet. Jegliche Software kann missbraucht werden.

In diesem Fall kommt aber noch die Komponente Mensch dazu.

- Bei ModSys ist entsetzlich viel schiefgelaufen.
- Eigenen Progger misstrauen der Software so sehr, dass sie flüchten.
- Es ist ein ehrenamtliches Team, bei dem Einzelne plötzlich mit finanziellen Interessen "behaftet" sind.
- Es wurde regelrecht getestet, wieviel Verschlüsselung notwendig ist, bis keiner mehr "drauf kommen kann". Das dabei erstmal harmlose Daten übertragen wurden, sagt nur sehr wenig über Zukünftiges aus.

Keine Software isst risikofrei. Wie ich oben schon mal schreib, kann man deshalb nur eine Risikoabwägung machen: Wie groß ist die Wahrscheinlichkeit, dass ich mit der Software X bzw der Software Y auf die Schnauze falle?

Bei einer Risikoabschätzung schneidet der Emerald nach all den Vorfällen und den Aussagen eigener Ex-Progger mehr als nur schlecht ab.

Das hat rein gar nichts mit irgendwelchen Kompilaten, DLL's oder anderem Technikkram zu tun, sondern einfach mit der Anhäufung sehr negativer Vorfälle. Derer gab es bei ModSys ja nun mittlerweile überreichlich. Die Reaktionen von ModSys waren jedesmal so, man nur den Kopf schütteln konnte.

Auf der Basis diverser Vorfälle und Aussagen fällt eine Risikobeurteilung sachlich betrachtet für den Emerald erheblich schlechter aus als für die wohl meisten anderen Viewer.
 
Shirley hat Recht: jedes Stück Software, das ich auf meinen Rechner bringe, und das ich nicht selbst programmiert (oder den Code inspiziert) und kompiliert habe, kann Dinge tun, die ich nicht mag.

Also MUSS ein sehr bedeutendes Kriterium für die Auswahl von Software, die ich nicht selbst kompiliere das Vertrauen sein, dass ich in den Hersteller oder Vertreiber setze.

Solches Vertrauen basiert auf guter, ehrlicher, transparenter PR des Unternehmens, basiert auf Referenzen, auf guter Qualitätskontrolle und dem Nichtvorhandensein auch kleiner unerwünschter Nebeneffekte (wie Programmpfadnamen in Grafikdateien).

Solches Vertrauen ist in der Regel sogar wichtiger als Bugfreiheit.

Wenn solches Vertrauen nicht aufgebaut werden kann, dann bekomme ich als Programmierer nicht den Auftrag des Kunden, und wenn ich Unternehmer bin, der Kunden schon mal mit dubiosen Äußerungen und gebrochenen Versprechungen gekommen ist, dann darf ich nicht erwarten, dass mein Produkt weiterhin der Verkaufsschlager bleibt, egal, wie gut das Produkt ist.
 
Ja, alles was ich nicht selbst erstellt habe ist erstmal "potentiell gefährlich".
Es gibt aber gewisse Kriterien, die das "Gefahren level" heruntersetzen:
OpenSource - wenn denn der Peer Review funktioniert (d.h. wenn die Community gross genug ist, um "Ungereimtheiten" aufzudecken)
Überlege dir einfach mal, wie viele Developer die Mozilla Commits und Changes im Auge behalten.

Closed Source - hier ist es reine Vertrauenssache und ein Abwägen.
Ich traue Microsoft nicht für fünf Pfennig. Allerdings gibt es auch hier sehr viele "Watchdogs" - trotzdem akzeptiere ich einfach das Risiko, da ich für mich Windows brauche.
Andererseits gibt es Firmen, denen ich persönlich Vertraue - so z.B. Avira.

Du siehst also, dass ein Vergleich zwischen Molliza Foundation's compiled Binaries (eine Respektable, anerkannte RL Organisation die sich bei Malware im Code vor rechtlichen (zivil und strafrechtlich) Konsequenzen fürchten muss) und den Binaries einer Gruppe von mehr-oder-weniger Unbekannten die keinerlei Absicht haben, ihr Fehlverhalten zu ändern ziemlich stark hinkt.

mfg
Alex
 
und was will modsys nun erreichen? Was senden? Sind das Cyberkriminelle? Ihr müsst ja eine ungefähre Vorstellung davon haben. Das Senden von Daten in einer closed Binary kann es doch alleine nicht sein. Es müssen doch konkrete Befürchtungen darüber da sein was aus welchem Grund gesendet werden könnte.
Jaaaaaa ich will Spekulationen. Ich glaube allerdings persönlich nicht, dass sie kritische systeminfos haben wollen, sondern account infos. Allerdings glaube ich da wiederum nicht das es um Passwörter oder payment infos geht.
Ich meine es muss doch ein Motiv geben, oder?


@Christoph
Stimmt ich ging davon aus das der Viewer strikt objektorientiert programmiert wurde, das mag zwar sein aber mit C++ kan man diese Objektorientierung leicht aushebeln.

@Mysty
Das technische soll ja keine Handlungsanweisung sein... wäre auch echt ein wenig viel für SL ;).
Aber hier handelt es sich um einen technischen Vorgang und den muss man hinterfragen, denn nur so schafft man es auch die Sensibilität der Leute für sowas zu schärfen.

Vertrauen kann man eben nicht diskutieren, man kann nur versuchen durch Fakten oder konkrete Befürchtungen das Vertrauen anderer zu erschüttern.

Nun Fakt ist doch bei diesem Skandal: Code ist in einer closed Binary eingeschläust worden der das Installationsverzeichnis des Emerald Viewers in jpg Dateien verschlüsselt an die Emerald Server sendet oder?

Warum das gemacht wurde erschließt sich mir nicht. Ich halte so eine Information für irrelevant. Aber es könnte ja auch nur ein Test sein für andere Daten, welche gesendet werden könnten. Das Verschärfen der Verschlüsselung zeugt ja auch davon.

Meine persönliche Vermutung:
Modsys versucht mit verschiedenen Systemen Geld zu verdienen. Davon zeugt das AntiGriefer-Beta-Dingens dessen dem zugrunde liegende Datensammlung ja in die Öffentlichkeit gezerrt wurden. Davon zeugt auch das der Typ vom CDS mittlerweile Entwickler bei Modsys ist. Meine Vermutung sind eben Tests für einen Service für Simowner, wie auch immer der geartet sein soll...
Wenn man dafür den Emerald als Datenerfassungsdingens misbrauchen könnte, wäre das für Modsys natürlich (erstmal) ideal.

Das ist natürlich reine Spekulation meinerseits. Nun müsste man, wenn das denn so wäre nicht die Vertrauensfrage stellen, sondern eher die Frage ob man sowas unterstützen möchte... ich sehe schon Stari in den Thread rennen mit nem großen NEIN Schild, kann ich auch verstehen.

Was habt ihr denn nun für Befürchtungen?
 
Es gilt für mich der alte Grundsatz: wer einmal lügt, dem glaubt man nicht, auch wenn er mal die Wahrheit spricht.

Für mich sind neben den Äußerungen LGGs in Bezug auf den Buildserver, auf dem nicht alle Entwickler Zugriff haben sollen - warum eigentlich? - der Hinweise interessant, dass in Emerald auch Funktionalität(en) eingebaut werden soll(te?), die dann Teile der Emeraldentwickler in anderen Projekten zu Geld machen können. Dies war nach LGG nur scherzhaft gesprochen, aber wenn es doch kommen sollte, wird das dann mit CDS und/oder der Lösung in der Mache verzahnt? Logisch erschiene es.
 
Ich denke auch wenn überhaupt das da was mit CDS oder Ähnlichem verzahnt werden soll.
 
Status
Für weitere Antworten geschlossen.

Users who are viewing this thread

Zurück
Oben Unten