[titus]

Ihr hattet doch beim alten JD ein Webinterface? Könnte man das nicht recyclen und an den neuen Code anpassen? Das muss ja gar nicht mal so graphisch sein, wie die GUI. Prozentzahlen für die Downloads würden ja auch reichen.

"Premium" ist auch inzwischen abgedroschen als Begriff. Meistens hat der Hersteller überzogene Preisvorstellungen hat, weil er sein Produkt für toller hält, als es eigentlich ist, was den Nutzen für den Kunden angeht...

[coalado]

"Premium" ist auch inzwischen abgedroschen als Begriff. Meistens hat der Hersteller überzogene Preisvorstellungen hat, weil er sein Produkt für toller hält, als es eigentlich ist, was den Nutzen für den Kunden angeht...

Ok.. willst du uns damit sagen unser Produkt sei schei%/&? ;-P

Ihr hattet doch beim alten JD ein Webinterface? Könnte man das nicht recyclen und an den neuen Code anpassen? Das muss ja gar nicht mal so graphisch sein, wie die GUI. Prozentzahlen für die Downloads würden ja auch reichen.

Das wäre sicherlich einige Wochen Arbeit. Allerdings habe ich auch nichts dagegen wenn jemand das alte Webinterface wieder ausgraben will. AUch ein neues mit vergleichbarem Funktionsumfang wie das alte wäre ok.

Aber da muss sich halt wer finden, der soviel AUfwand betreiben will, nur um einen kostenlosen MyJDownloader Account rum zu kommen.

[titus]

Jetzt reite nicht die ganze Zeit auf dem kostenlos rum, wo wir doch schon mehrmals hier klar gemacht haben, dass das nicht der Knackpunkt ist. Und nein, ich hab auch nicht gesagt, dass euer "Produkt" scheiße ist. Ich finde halt nur, dass Premium oft mehr suggeriert als es halten kann bzw. der Hersteller die Zahlungsbereitschaft (für gewisse Features) überschätzt.

Außerdem habe ich nie behauptet, dass ein funktionierendes Business Model leicht zu finden ist. Allerdings nutz ich den JD seit Jahren für lau und irgendwie scheint ihr euch mit eurer GmbH über Wasser halten zu können. Nun hab ich als User mehrere kostenlose Alternativen wie Cryptload und vor allem Pyload (das auf meinem NAS läuft), da muss also schon echt was kommen, free user zum Zahlen zu bewegen. Ein in meinem Augen unnötiger Service wird da eher nicht der Auslöser sein.

[pspzockerscene]

Es hat doch niemand behauptet, dass bestehende Features auf einmal kostenpflichtig werden.
Ich meine mich zu erinnern, dass Coalado gepostet hat, bestehende Features würden auf jeden Fall kostenpflichtig bleiben, da man die Werbung im Installer sonst nicht rechtfertigen könnte.

Wie auch immer, ich bin selbst noch nicht in die Pläne eingeweiht und bin gespannt was die Jungs vor haben

GreeZ pspzockerscene

[spellmaster]

Hallo eine Verständnisfrage:
wenn JD eine API hat, dann kann er also auf http-Anfragen als Server reagieren. Was spricht also dagegen, diese API mit ein paar lokalen Seiten aka "file.html" abzufragen. Ist nicht die meiste Arbeit die API??
Und zur Premium-Planung: Bitte keine Geheimplanungen!! Ein offene Diskusion ist langfristig zielführender.

[coalado]

Wie stellst du dir eine offene Diskussion denn vor?

[pspzockerscene]

Ich vermute mal du sollst die Planung der Premiumfunktionen zumindest teilweise offenlegen und dann soll darüber diskutiert werden, was wie umgesetzt wird und sicherlich auch über die Preise.

GreeZ pspzockerscene

[titus]

Originally Posted by pspzockerscene

Es hat doch niemand behauptet, dass bestehende Features auf einmal kostenpflichtig werden.

Nein, coalado hat aber so getan, dass man gegen myjdownloader nichts einwenden könne, weil er kostenlos ist. Das geht aber nun mal an den Kritikpunkten vorbei, hilft also bei ner zielführenden Diskussion nicht sonderlich.

[pspzockerscene]

Das kann ich verstehen, aber ich werde mich da raushalten, da ich mydownloader bisher nicht getestet habe und allgemein wohl keine Remotesteuerung dafür brauche...nen NAS besitze ich auch nicht, somit geht das alles erstmal an mir vorbei.

GreeZ pspzockerscene

[coalado]

Nein, coalado hat aber so getan, dass man gegen myjdownloader nichts einwenden könne, weil er kostenlos ist. Das geht aber nun mal an den Kritikpunkten vorbei, hilft also bei ner zielführenden Diskussion nicht sonderlich.

Ich wollte da nicht drauf rumreiten - sorry wenn das so rüber gekommen ist.
Zu den Kritikpunkten - ich hoffe ich habe keinen vergessen.


1. My JDownloader ist zu langsam
Ich habe weiter oben ja schon erklärt, dass wir über einen Directmode nachdenken. Damit wäre das Thema vom Tisch. Abgesehen davon schrauben wir auch immernoch an der Geschwindigkeit der API, und vor allem daran JDownloader etwas im Download zu limitieren während die API stark genutzt wird.

2. Ich will keinen Account erstellen
Ein Account ist nötig. Für uns wegen Premiumfunktionen, für Nutzer um an komplizierten Router Einstellungen vorbei zu kommen, oder um den Traffic zu verschlüsseln. Abgesehen kann ich unter so einem Account mehrere JD Installationen vereinen, und ziemlich einfach wählen mit wem ich "sprechen" will.

3. Ich will nicht dass jemand "mitlesen" kann
Das kann niemand - zumindest nicht so lange du dein Passwort geheim hältst. Selbst wir können nicht mitlesen. Beispiel: Wenn über MyJdownloader die Downloadliste geladen wird, sehen wir, dass ein Request wie /getdownloadlist gemacht wird. Alles andere wird über die Account Zugangsdaten verschlüsselt. Spätestens wenn der DirectMode kommt, laufen die verschlüsselten Daten direkt, und wir sehen nichtmal mehr die.
Jeder ist herzlich eingeladen diese Verschlüsselung nach Schwachstellen abzuklopfen.


4. Ich finds trotzdem doof, und kann auf den "Komfort" von MyJDownloader gerne verzichten

Tjo.. dagegen fällt mir jetzt nicht viel ein. Wenn sich jemand findet, der für diese Nutzergruppe ein Webinterface im "Alten Stil" bauen will - schön. Aber ich finde den MyJDownloader Ansatz klasse, und werde meine Zeit lieber da rein stecken. Da haben am Ende mehr Leute was davon.

[hightower5]

Hat die Geschwindigkeit der API auch Einfluss auf die Ladezeiten der App file.recon von Christof (pixelvalley.de)? Die sind bei mir wirklich sehr groß, etwa 40-60 Sekunden.

[coalado]

Da die App aiuch über myjdownloader läuft: ja


Wobei es natürlich 1000 Gründe haben kann. Das kann genauso gut an der App liegen. Am besten fragst du da bei Christof nach.


Sind die Ladezeiten nur so groß wenn JDownloader gleichzeitig lädt, oder allgemein?

also ich muss sagen das ich myjdownload von unterwegs nutze mit meinen glaub 10 jd installationen und muss sagen bisher läuft es ganz gut.

sicher fehlen noch gewisse features die es sinnvoller machen wie gesammelte captchas aus allen clients aber an sich läst sich damit auch im aktuellen betazustand sinnvoll arbeiten.

zu alternativen downloadprogrammen kann ich nur sagen das ich schon einige ausprobiert habe und kaum eines wird so gut aktualisiert und um features erweitert wie jd, weswegen ich am ende auch immerwieder zum jd gekommen bin.

wer alternativen nutzt weil man dabei direkten zugriff hat, da vermute ich mal das diese verbindung meist nicht verschlüsselt sein dürfte und daher erst recht mitgelesen werden kann.

ich persönlich habe keine angst das jemand was mitlesen kann was ich mache denn spätestends die downloads sind dann ja wohl seltenst verschlüsselt.

my 10 cents

DuneMan

[hightower5]

@coalado, die Downloads scheinen keinen Einfluss auf die langen Ladezeiten zu haben. Die sind selbst wenn JD2 oder auch sonst kein anderes Programm etwas läd, unverändert hoch.

Die Reaktionszeit und die Steuerung über den Browser ist deutlich schneller.

Originally Posted by coalado

[...]

[...] aber zumindest für die Authentifizierung wird ein MyJDownloader Account nötig sein.

[...]
Und ja.... wir werden Erweiterungen und ko, die das umgehen wollen sicherlich nicht freudig empfangen.

Originally Posted by coalado

[...]
Ein Grund für die Kontobindung ist, dass es im JDownloader demnächst auch bezahlte Premiumfunktionen geben wird.
Solche Premiumfunktionen wird es auch im Webinterface oder anderen Remote Apps geben. Dazu werden zum Beispiel die Art oder die Häufigkeit bestimmter API Funktionen limitiert sein. Das geht ohne Kontrolle nicht.
[...]

Hallo coalado,

vielen Dank zuerst einmal für deine klare und offene Antwort. Ich kann bis zu einem gewissen Grad auch verstehen, dass ihr mit JD jetzt diesen Kurs einschlagen wollt, schließlich hat jeder das Recht, für seine harte Arbeit (und die steckt im JD mit Sicherheit drin) auch angemessen entlohnt zu werden. Ich hätte es allerdings wesentlich schöner gefunden, wenn ihr den Usern die freie Wahl gelassen hättet, ob sie my.jdownloader.org verwenden wollen, oder doch lieber ein "direktes" Webinterface (ohne Beteiligung von my.jdownloader.org).
Wäre es nicht möglich gewesen, die Anwender einfach durch die schieren Vorteile und gute Argumente von my.jdownloader.org zu überzeugen, anstatt den Weg einzuschlagen, den Anwendern keine Wahl zu lassen?
Nun ja, ihr werdet das wohl im Hintergrund bereits ausführlich diskutiert haben und ihr habt euch nun für diesen Weg entschieden, aber für mich hinterlässt so ein "Zwang" halt immer einen ziemlich negativen Beigeschmack. Und wie hat Jack Nasher kürzlich bei "SWR Leute" sinngemäß erklärt: "Friss-oder-Stirb-Situationen führen bei Menschen häufig zu irrationalem Verhalten". Ich muss sagen, dass ich das bei mir im Moment auch ein wenig feststellen muss. Hätte ich die freie Wahl, würde ich my.jdownloader mit Sicherheit mal antesten und vielleicht ja sogar langfristig verwenden, aber da ich mich jetzt dazu gezwungen fühle, werde ich stattdessen alles dran setzen, eine Ausweichmöglichkeit zu finden.
Wie man sieht ist das ja eigentlich ein irrationales Verhalten, denn ich muss zugeben, dass ich oberflächlich betrachtet durchaus die großen Vorteile von my.jdownloader sehe. Es ist auf jeden Fall eine extrem einfach zu benutzendes Remote-Interface und vor allem ist der Einrichtungs-Aufwand selbst für technisch unerfahrene Benutzer praktisch null. Im Grunde eine tolle Sache. Mein Glückwunsch dazu.

Leider gibt es (wie fast immer im Leben) auch Nachteile. Für mich persönlich liegen die Nachteile vor allem in dem von dir angesprochenen Bereich:

Originally Posted by coalado

[...]
3. Ich will nicht dass jemand "mitlesen" kann
[...]

Wobei ich das jetzt nochmal in 2 Aspekte unterteilen würde. 3.1 Privacy und 3.2 Security. Das ist ja nicht unbedingt identisch, auch wenn es eine Schnittmenge gibt.

Wie dem auch sei, ich will dir jetzt nicht auf die Nerven geben, aber gerade in diesem Breich habe ich sogar an mehreren Stellen ziemliche Zweifel, ob das wirklich alles so einfach ist, wie du es darstellst. Ich muss aber zugeben, dass ich mich mit meinen technischen Kenntnissen nicht annähernd in euren Sphären bewege, bin aber gerne bereit, dazu zu lernen. Gibt es denn mittlerweile eine einfach öffentlich zugängliche Doku beispielsweise zur API? Vor ein paar Wochen hatte ich mal angefragt, da wurde ich noch auf den Sourcecode verwiesen, auf den ich damals aber aus irgend einem Grund keinen anonymous Zugriff kriegen konnte. Gibt's eine Doku zu den vielen Kommunikations-Wegen, die hier auftreten. Die ganze Konstruktion ist ja doch nicht gleich auf den ersten Blick glasklar. Ich bezweifle ehrlich gesagt, dass es viele User geben wird, die wirklich präzise verstehen werden, welche Wege welche (privaten) Daten laufen werden, mit welcher Verschlüsselung das passieren wird, und wo welche Daten mit welcher/-m Verschlüsselung/Hash dann am Ende auch bei euch (my.jdownloader.org) gespeichert werden.

Und wenn ich mir's genau überlege, ist das eigentlich für mich persönlich auch schon Grund genug, doch lieber ein direktes Web-Interface zu benutzen. Denn für mein LAN habe ich bereits einen Zugang, der im Rahmen der Möglichkeiten einigermaßen gut abgesichert ist. Da gibt es ja genügend Standard-Möglichkeiten (SSH-Tunnel, VPN, Port-Knocking, etc...). Da so etwas bei mir bereits existiert, wäre der Zusatz-Aufwand für ein direktes Webinterface bei mir praktisch Null und es würde vor allen Dingen die Gefährdung meiner/-s Daten/LAN nur geringfügig erhöhen. Wenn ich jetzt my.jdownloader.org verwenden würde, dann würde ich ein System benutzen, das ich (momentan) noch nicht wirklich durchblicke und wo ich potenziell/wahrscheinlich die möglichen Fehlerquellen/Lücken deutlich erhöhen werde. Wir werden uns ja einig sein, dass wir alle nur Menschen sind, und dass da einfach auch Fehler passieren. Warum sollte ich jetzt also mein LAN - wo durchaus auch Fehler vorhanden sein können - noch mit weiteren zusätzlichen potentiellen und unübersehbaren Fehlerquellen "belasten". Da würde ich mir einfach wünschen, dass ich da bei dem guten alten direkten Webinterface bleiben könnte. Dann hätte ich wenigstens nur meine eigenen Fehler zu verantworten. ;-)

Naja, ich sehe schon, man kann da noch sehr viel diskutieren. Am Ende werden wohl die meisten User nach ihrem Bauchgefühl entscheiden. Ich könnte mir vorstellen, dass ihr jetzt in Zeiten, in denen viele Anwender ihre Bedenken bezüglich Privacy und Security einfach beiseite schieben, wenn es im Gegenzug um Bequemlichkeit geht, mit my.jdownloader.org durchaus erfolgreich sein werdet.

Ich werd's aber vermutlich nicht benutzen.

Originally Posted by DuneMan

[...]
zu alternativen downloadprogrammen kann ich nur sagen das ich schon einige ausprobiert habe und kaum eines wird so gut aktualisiert und um features erweitert wie jd, weswegen ich am ende auch immerwieder zum jd gekommen bin.
[...]

Ging mir bisher genauso. JD ist momentan einfach das beste. Leider ist die GUI auf meinem Raspberry Pi ärgerlich langsam, während der Kern ziemlich flott läuft. Auch das ist übrigens ein Grund, weshalb ich eine direkte einfache Web-GUI begrüßen würde. Selbst wenn die nur im lokalen LAN laufen würde, wär' das für mich schon erfreulich. Muss aber zugeben, dass das bei mir natürlich ein Sonderfall ist. :-)

Originally Posted by DuneMan

[...]
wer alternativen nutzt weil man dabei direkten zugriff hat, da vermute ich mal das diese verbindung meist nicht verschlüsselt sein dürfte und daher erst recht mitgelesen werden kann.
[...]

Naja, zumindest bei p_l__d ist es soweit ich gesehen habe prinzipiell möglich, auf das Webinterface per HTTPS zuzugreifen. Soweit ich das verstanden habe, muss man da aber ziemlich basteln. Insofern hast du im Endergebnis dann wohl doch recht, dass die Verbindungen zum Webinterface aus diesem Grund zur Zeit meistens unverschlüsselt sein dürften.

Aber warum sollte das JD2 nicht besser machen? Prinzipiell möglich ist es doch. Wäre doch toll, wenn es da ein HTTPS-Webinterface gäbe.

Originally Posted by DuneMan

[...]
ich persönlich habe keine angst das jemand was mitlesen kann was ich mache denn spätestends die downloads sind dann ja wohl seltenst verschlüsselt.
[...]

Naja, die Sache ist halt nicht einfach nur schwarz und weiß. Es gibt da halt auch Grautöne. Sicherlich ist die Verbindung zum (bspw.) OneClickHoster häufig unverschlüsselt. Aber ich denke durch my.jdownloader.org wird das ganze jetzt doch nochmal eine Stufe "grauer". Klar kann man da sagen "ach egal, ein oder zwei Stufen heller oder dunkler, wo ist da der Unterschied?". Aber wenn man das alle paar Monate macht, dann hat man am Ende schwarz. Ich finde schon, dass man jede Verschlechterung, die sich vermeiden lässt, auch vermeiden sollte!

Ich zähle jetzt mal ein paar Punkte auf

• Es gibt _eine_ Stelle (my.jdownloader.org), wo vielleicht(!) / eventuell(!) / man_überblickt_es_nicht_genau(!!) / vielleicht_auch_nicht(!) die Liste aller meiner Downloads gesammelt verschlüsselt(?) / oder_nicht(?) / wie_gut_verschlüsselt(?) durchläuft
• Dieser Punkt (my.jdownloader.org) ist außerhalb meiner Kontrolle
• Was wäre, falls(!) an diesem Punkt (my.jdownloader.org) die Daten alle gespeichert und gesammelt würden? Ich denke nicht, dass das so ist, aber ich kann das schlecht kontrollieren. Eine Frage des Vertrauens?
• Man kennt dort zwar nicht meinen Namen, aber es handelt sich um eine Firma in Deutschland und "gewisse Leute" haben recht einfachen Zugriff und Einflussmöglichkeiten.
• Erst vor kurzer Zeit ist der Betreiber von my.jdownloader.org relativ schnell vor "gewissen Leuten" eingeknickt "Stichwort R_M_E". Was wäre, wenn auf my.jdownloader.org plötzlich geloggt wird?

Klar kann man da immer sagen "das ist ja so äääähnlich, wie bei den OneClickHostern". Aber es ist halt doch nicht exakt gleich. Es wird dadurch alles ein Stück einfacher für "gewisse Leute" und es ist auch ein Stück "näher an mir dran". Es ist "ein paar Grautöne dunkler". Und wie gesagt, es ließe sich halt wirklich sooo einfach vermeiden, wenn es ein "direktes" Webinterface gäbe. Warum sollte ich es nicht vermeiden wollen, wenn es doch theoretisch so einfach möglich wäre.

Ich will ja niemanden my.jdownloader.org "wegnehmen"! :-) Kann ich ja auch gar nicht. :-) Und das hat durchaus seine Existenz-Berechtigung. Aber ich fände es halt auch schön, wenn potentielle Entwickler eines "direkten Webinterface" mit offenen Armen empfangen würden. Wie coalado aber sagte werden die "sicherlich nicht freudig empfangen". Ich kann das zwar verstehen, würde mir aber wünschen, es wäre anders. Ich hoffe man kann nachvollziehen, warum ich das so sehe.

[coalado]

Uff. das war lange.

Also eine vorläufige API Docu gibt es hier: http://goo.gl/CaoaIY

Die ist halt bisher nur für internen Gebraucht gedacht, und ist deswegen jetzt nicht perfekt aufbereitet. Ob das jetzt soviel weiterhilft... ich weiß nicht.


Die Daten werden mit AES im CBC Mode über einen 128Bit Schlüssel verschlüsselt. Der Schlüssel dazu wird aus email und deinem Passwort errechnet.
[CODE]

deviceSecret (Das kennt nur dein JD, und die andere Seite. z.B. Das webinterface. Der Server kennt das nicht, und kann es nicht errechnen)

deviceSecret = sha256( email.lowercase + pass + “device” );

Beim Login erhält man ein sessionToken. Das ist ein zufallsschlüssel, der aber an die momentane IP gebunden ist. Dieser sessionToken wird zusammen mit dem deviceSecret zum errechnen der Schlüssel für die Datenverschlüsselung genutzt.

encryptionKeys= sha256(deviceSecret +sessionToken)

Die encryptionKeys ändern sich damit mit jedem IP wechsel.

Wenn es dazu Fragen gibt, sollen wir vermutlich ein eigens Thema dazu aufmachen.




Wenn wir den DirectMode wie oben beschrieben umsetzen, dann laufen aber in so einem DirectMode ohnehin keine Daten über my.jdownloader.org - sondern eben nur der Login. Das ist doch dann eh fast wie ein direktes Webinterface.

Was wäre, falls(!) an diesem Punkt (my.jdownloader.org) die Daten alle gespeichert und gesammelt würden? Ich denke nicht, dass das so ist, aber ich kann das schlecht kontrollieren. Eine Frage des Vertrauens?

Also einerseits können wir das nicht. Stichwort Verschlüsselung.
Abgesehen davon: Vertrauen JA! Denk mal drüber nach, dass du eigentlich jedem Software Entwickler, dessen Software du nutzt und installierst auch vertrauen musst. Das hat absolut nichts mit My.JDownloader zu tun. Während der Installation lässt du das Tool schonmal mit Adminrechten arbeiten. Und anschließend bei jedem Start "völlig unkontrolliert" laufen. Dabei hat das Tool Zugriff auf ziemlich alles auf deinem PC.
Nochmal: das alles trifft auf jedes Stück Software auf deinem PC zu. Installiere nie Software wenn du den Herstellern nicht vertraust.

Klar.. Open Source Software kann man kontrollieren. Aber wer macht das, außer den Entwicklern selbst?

Man kennt dort zwar nicht meinen Namen, aber es handelt sich um eine Firma in Deutschland und "gewisse Leute" haben recht einfachen Zugriff und Einflussmöglichkeiten.

Wie überall anders auch. Wir leben diesbezüglich hier eher noch in Luxus würde ich sagen.

Erst vor kurzer Zeit ist der Betreiber von my.jdownloader.org relativ schnell vor "gewissen Leuten" eingeknickt "Stichwort R_M_E". Was wäre, wenn auf my.jdownloader.org plötzlich geloggt wird?

Eingeknickt würde ich das jetzt nicht nennen. Und mit Security oder Privacy hatte das jetzt auch herzlich wenig zu tun.

Falls uns jemand dazu zwingen könnte (ich bezweifle das, aber ich bin kein Anwalt!) mehr Daten zu loggen als wir in unseren Datenschutzerklärungen(Ja! die gibt es) angeben, dann brauchen wir da kein MyJDownloader. Ich habe den Punkt mit Vertrauen weiter oben ausgeführt.





Ich verstehe deine Bedenken durchaus, Aber man muss die Kirche auch im Dorf lassen. Wir tun unser Bestes um ein sauberes, sicheres, schnelles und faires System zu bauen - Wie schon immer.

[thecoder2012]

Eingeknickt würde ich das jetzt nicht nennen.

Also wenn man die Funktion deaktiviert/löscht würde ich das schon als einen Eingriff bezeichnen. Ich hoffe sicherlich das beste aber ob die Funktion je wieder kommt ist fraglich.

Falls uns jemand dazu zwingen könnte (ich bezweifle das, aber ich bin kein Anwalt!) mehr Daten zu loggen als wir in unseren Datenschutzerklärungen(Ja! die gibt es) angeben, dann brauchen wir da kein MyJDownloader. Ich habe den Punkt mit Vertrauen weiter oben ausgeführt.

Wäre eher dafür sha512 oder stärker (SHA-3 => Keccak) zu nutzen und das noch ein stärkerer Schlüssel genutzt wird. Damits auch für dutzende Jahre definitiv unmöglich bleibt bzgl. Rechenleistung. Noch gilt SHA-2 Familie als sicher aber SHA-3 wurde entwickelt um deutlich sicherer zu sein. Vielleicht Paranoid aber man kann nie genug Sicherheit haben.

Ansonsten warte ich mal mit viel Spannung auf den DirectMode.

Originally Posted by coalado

Uff. das war lange.

Tut mir wirklich leid, aber ich wollte meine Bedenken halt halbwegs differenziert darstellen und ich krieg das leider nicht im Twitter-Stil hin. Und ich hab' ja auch versucht deutlich zu machen, dass ich durchaus auch die großen Vorteile von my.jdownloader.org sehe.
Danke jedenfalls, dass du dir die Mühe gemacht hast, den "Roman" zu lesen. Ich fürchte, hier kommt nochmal einer.

Originally Posted by coalado

[...]
Die Daten werden mit AES im CBC Mode über einen 128Bit Schlüssel verschlüsselt.
[...]
Wenn es dazu Fragen gibt, sollen wir vermutlich ein eigens Thema dazu aufmachen.
[...]

Das ist in der Theorie wirklich alles toll ausgedacht, das will ich euch absolut zugestehen. Meinen Respekt, wie ihr das konstruiert habt. Darin habe ich auch nie das Problem gesehen. Aber die Praxis hat mich halt gelehrt, dass es da noch andere Faktoren gibt. Um nicht wieder ewige Romane zu schreiben nur kurz eines von mehreren Stichworten und zwar der Faktor "Mensch". Menschen machen Fehler. Und hier gibt es wirklich massig Raum, wo Menschen Fehler machen könnten. Wenn ich zuhause mein VPN einrichte (das ich sowieso schon anderweitig brauche) und ein "direktes Webinterface" benutzen könnte, dann bräuchte ich wenigstens nur meine eigenen Fehler auszubaden, aber so bin ich auch noch darauf angewiesen, dass bei euch keine Fehler passieren.

Originally Posted by coalado

[...]
Wenn wir den DirectMode wie oben beschrieben umsetzen, dann laufen aber in so einem DirectMode ohnehin keine Daten über my.jdownloader.org - sondern eben nur der Login. Das ist doch dann eh fast wie ein direktes Webinterface.
[...]

Ok, da muss ich dir Recht geben. Wenn der Direct-Mode kommt, dann werden zwar nicht alle, aber zumindest schon mal ein großer Teil meiner Bedenken ausgeräumt. Das wäre dann im Prinzip so eine Art Browser-App (oder wie nennt man so was neu-deutsch?). Und wäre quasi fast vergleichbar mit einer lokalen App, die dann lediglich noch die Authentifizierung (und ich vermute mal die Berechtigungen für die Premium-Features) bei my.jdownloader.org abruft.
Wenn das so kommt, dann wäre ich eventuell bereit, meine restlichen verbleibenden Bedenken über Bord zu werfen. Ohne den Direct-Mode - no way.

Was ich auch noch eingestehen muss, dass ich Depp erst kürzlich überhaupt kapiert habe, wie das mit dem Passwort-Hashen bei euch abläuft. Bei vielen Websites, die man so kennt (Google, Facebook, etc.), wird das Passwort ja zwar über eine gesicherte Leitung (HTTPS) übertragen aber am anderen Ende der Leitung (also auf deren Server) "purzeln" die Passwörter ja erst mal wieder im Klartext aus der Leitung. Theoretisch können die dort in diesem Moment also problemlos mein Passwort mitlesen, auch wenn es dann in der Folge (hoffentlich ) gehasht gespeichert/geprüft wird. Ich ging irgendwie automatisch davon aus, dass das bei euch genauso läuft. Aber ihr hingegen macht euch tatsächlich die Mühe, das Passwort schon vor der Übermittlung client-seitig im Browser zu hashen! Also das ist wirklich mal eine tolle Idee! So aus dem Stand heraus fällt mir da jetzt gerade nicht mal eine andere Website ein, die das auch macht. Also ich finde, damit dürftet ihr ruhig mehr Hausieren gehen.
Ich glaube ihr habt euch wirklich ganz schön viele Gedanken und Mühe gemacht.

Originally Posted by coalado

[...]
Abgesehen davon: Vertrauen JA! Denk mal drüber nach, dass du eigentlich jedem Software Entwickler, dessen Software du nutzt und installierst auch vertrauen musst.
[...]
Klar.. Open Source Software kann man kontrollieren. Aber wer macht das, außer den Entwicklern selbst?
[...]

Ich hatte schon befürchtet, dass dieses Fass auch noch aufgemacht wird.
Dabei habe ich's in meinem letzten Posting extra nicht mehr angesprochen, weil ich die Diskussion nicht ausufern lassen wollte. Naja, egal.
Also ich finde schon, dass es da noch einen Unterschied gibt, zwischen einer (fast?) OpenSource-Software, die ich lokal installiere und wo ich theoretisch neben dem Sourcecode auch noch den ganzen Netzwerktraffic im eigenen Netz analysieren kann und einer Client-Server-Web-Applikation bei der (wenn ich dich richtig verstanden habe) der Server-Teil nicht mal OpenSource werden soll (oder liege ich da falsch). Klar muss ich persönlich (weil ich einfach zu dumm bin, um mir den ganzen Quelltext durchzuschauen) auch beim lokalen JD ein gewisses Maß an Vertrauen entgegen bringen, aber bei my.jdownloader.org muss das Vertrauen eben ein Stück größer sein! Ganz klar, ich rede hier nicht von schwarz und weiß, sondern von Graustufen! Aber wie ich schon sagte, ich und einige andere, die hier in diesem Thread mitgeschrieben haben, besitzen bereits ein VPN (oder ähnliches) und bräuchten nur noch ein direktes Webinterface für ihr Glück. Dass wir nicht unbedingt scharf auf eine Lösung sind, wo wir unseren Vertrauens-Vorschuss halt doch ein Stück erhöhen müssten, ist doch nachvollziehbar?

Naja und apropos Vertrauen. Wie ich ja schon erwähnt habe, ist die Tatsache, dass ich jetzt im Grunde kein andere Wahl mehr haben werde, als auf die ein oder andere Art my.jdownloader.org zu benutzen, nicht gerade dazu angetan, mein Vertrauen zu erhöhen.
Überlegt euch doch wirklich nochmal, ob ihr nicht wenigstens einem externen Projekt die Chance geben wollt, ein direktes kleines Webinterface zu entwickeln. Ich glaube wirklich nicht, dass euch das weh tun würde. Das spricht doch ganz unterschiedliche Benutzergruppen an. Wenn ihr das mit my.jdownloader.org jetzt ordentlich zu Ende entwickelt, werdet ihr bestimmt eine Menge Benutzer dafür begeistern können.

Originally Posted by coalado

[...]
Eingeknickt würde ich das jetzt nicht nennen. Und mit Security oder Privacy hatte das jetzt auch herzlich wenig zu tun.
[...]

Du hast recht, "eingeknickt" war nicht fair, tut mir leid. Aber der Fall zeigt halt nochmal deutlich - was im Grunde auch vorher schon klar war - dass ihr einfach der deutschen Rechtsprechung unterworfen seid. Und da kommt jetzt auch der Zusammenhang zu meiner (zumindest) Privacy. Wenn nämlich bei euch irgendwann "gewisse Leute" mit einem Zettel in der Hand zur Tür reinkommen, wo draufsteht "Loggen!", dann werdet ihr loggen müssen. Und ich kann ganz ehrlich von mir behaupten, ich an eurer Stelle hätte in dem Moment die Hosen gestrichen voll und auch ich würde loggen und zwar was das Zeug hält. Ich will euch das nicht zum Vorwurf machen, so ist die Lage nun einfach mal.

Originally Posted by coalado

[...]
Falls uns jemand dazu zwingen könnte (ich bezweifle das, aber ich bin kein Anwalt!) mehr Daten zu loggen als wir in unseren Datenschutzerklärungen(Ja! die gibt es) angeben, [...]

Ach, ich habe schon lange aufgegeben, die Gerichtsentscheidungen der letzten Jahre (Jahrzente) verstehen zu wollen. Die sind teilweise so absurd... Ich würde da nicht meine rechte Hand drauf verwetten - nicht mal meine linke.

Originally Posted by coalado

[...]
dann brauchen wir da kein MyJDownloader. Ich habe den Punkt mit Vertrauen weiter oben ausgeführt.
[...]

Naja, MyJDownloader würde die "Sache" halt noch erleichtern. Beim lokalen JD würde es mir vielleicht doch irgendwann auffallen. Und ich habe ja weiter oben auch versucht, meine Sicht zum Punkt Vertrauen einigermaßen differenziert zu erklären.

Aber weißt du was? Ich glaube ich werde das ganze Thema und insbesondere die Sache mit dem Direct-Mode für mich jetzt erst mal ein bissel sacken lassen. Immerhin bin ich auf my.jdownloader.org überhaupt erst vor kurzem aufmerksam geworden. Hab' das lange Zeit immer überlesen, weil der Bedarf vorher nicht so akut war.
Und euch lasse ich jetzt auch erst mal wieder in Ruhe weiterarbeiten. Bin auf jeden Fall schon auf das Endergebnis gespannt.

Originally Posted by coalado

[...]
Ich verstehe deine Bedenken durchaus, Aber man muss die Kirche auch im Dorf lassen. Wir tun unser Bestes um ein sauberes, sicheres, schnelles und faires System zu bauen - Wie schon immer.

Amen - so sei es!

Originally Posted by thecoder2012

[...] ob die Funktion je wieder kommt ist fraglich.
[...]

Mein Bauch sagt mir, wohl eher nicht mehr.
Hab' auch nicht ganz verstanden, worüber da im September jetzt nochmal verhandelt wird. Geht's da überhaupt noch um den ursprünglichen Auslöser oder werden da nur noch andere Fragen geklärt? Aber egal, ich fürchte wir schweifen ab. Das gehört wo anders hin.

Originally Posted by thecoder2012

[...]
Ansonsten warte ich mal mit viel Spannung auf den DirectMode.

Ohne DirectMode geht gar nicht!

[coalado]

Solange RTMPE als Kopierschutz angesehen wird, ist daran wohl nichts zu machen. Aber darum soll es ja hier jetzt gar nicht gehen.


Passwort hashen:
Das machen viele Webseiten und Dienste so. Ich hoffe es zumindest.
Bei uns hat das aber auch einen anderen Grund: Wir leiden aus dem Passwort des Nutzers über das hinzufügen von Salts und Co , und das anschließende Hashen quasi verschiedene passwörter ab.

Das eine wird zum Server geschickt, und für die Authentifzierung sowie die Verschlüsselung der Daten zwischen Server und Webinterface genutzt. z.B. Wenn sich das Webinterface Kontoinformationen holt. Also für Daten WI->MYJD oder MYJD->WI

Das andere wird gar nicht verschickt, sondern für die Kommunikation JD <--> WI genutzt.

Wüsste der MYJD Server nun dein Passwort, könnte er damit die Schlüssel für JD <--> WI errechnen nund theoretisch mithören. Das betrifft auch alle anderen "Men in the Middle" (Grüße an Prism und co ;-P)

Das vom Benutzer gewählte Passwort und die daraus abgeleiteten Schlüssel für die JD<->WI Kommunikation gehen NIEMALS über die Leitung. Selbst beim registrieren nicht. Nur das WI und der JD zu Hause kennen die.


Die größte Schwachstelle sind vermutlich die statischen Webinterface Inhalte von my.jdownloader.org. Weil die NOCH nicht über eine https Verbindung laufen.

[titus]

Originally Posted by coalado

Also eine vorläufige API Docu gibt es hier: http://goo.gl/CaoaIY

Der Link funktioniert nicht.

Originally Posted by coalado

Jeder ist herzlich eingeladen diese Verschlüsselung nach Schwachstellen abzuklopfen.

Als Anbieter des Service seid ihr man-in-the-middle und habt daher immer - ohne dass man es von außen wirklich nachvollziehen könnte - die Möglichkeit, Klartext zu lesen.

Mein Hauptkritikpunkt bleibt jedoch weiterhin, dass der sogenannte Komfort eines (evtl. auch mal nicht erreichbaren) Service einfach unnötig ist. Ich will ein remote paar Links zum Download eintragen können, dazu hab ich in Pyload ein Webinterface.

Originally Posted by coalado

Wenn wir den DirectMode wie oben beschrieben umsetzen, dann laufen aber in so einem DirectMode ohnehin keine Daten über my.jdownloader.org - sondern eben nur der Login. Das ist doch dann eh fast wie ein direktes Webinterface.

Könnte man den Zugriff dann nicht auch über ein Webinterface realisieren? Ich hab vom Programmieren null Ahnung, aber ich wunder mich, dass der Zugriff auf diese API durch ein Webinterface (das es für den alten JD ja schon mal gab) so ein Mehraufwand sein soll. Wenn vom offiziellen Team keiner Lust hat, könnte man ja vielleicht an nen Coder spenden, der so ein Webinterface zusammenbaut. Denn selbst mit Interface hätte der myjdownloader doch noch genug Zusatzfeatures, die zur Differenzierung als Premim-Service ausreichen.

[coalado]

OVH scheint gerade Probleme zu haben. Deswegen geht der Link nicht.

ls Anbieter des Service seid ihr man-in-the-middle und habt daher immer - ohne dass man es von außen wirklich nachvollziehen könnte - die Möglichkeit, Klartext zu lesen.

Ich denke ich habe genug zum Thema Verschlüsselung gesagt. Trotz meiner Erklärungen zum Thema Verschlüsselung hier von Plaintext zu reden ist Quatsch. Entweder hast du nicht gelesen was geschrieben wurde, oder du willst einfach nur trollen - Beides nicht sonderlich fein.


Deinen Kritikpunkt "Der Komfort sei unnötig" kann ich so auch nicht stehen lassen. Für dich ist er unnötig. Für tausende andere ist er nötig, weil sie ohne diesen "Komfort" gar kein Webinterface nutzen könnten. Denk mal drüber nach, das die meisten Menschen da draussen, keine Ahnung von VPNs, Routern, Dyndns Diensten und Co haben. Die wissen in der Regel mit sehr viel Glück gerade mal was eine IP ist! Und all diese Leute, sind sehr dankbar für diesen "unnötigen" Komfort. Du bist mit deinem Know How Teil einer Minderheit die sich mit all dem Zeug auskennt. Die meisten Nutzer tun das leider nicht. Und trotzdem erwartest du von uns, dass wir alles nach deinen Wünschen umstellen, oder gar extra ein zweites Webinterface bauen?



@karlheinz2013

Naja und apropos Vertrauen. Wie ich ja schon erwähnt habe, ist die Tatsache, dass ich jetzt im Grunde kein andere Wahl mehr haben werde, als auf die ein oder andere Art my.jdownloader.org zu benutzen, nicht gerade dazu angetan, mein Vertrauen zu erhöhen.
Überlegt euch doch wirklich nochmal, ob ihr nicht wenigstens einem externen Projekt die Chance geben wollt, ein direktes kleines Webinterface zu entwickeln. Ich glaube wirklich nicht, dass euch das weh tun würde. Das spricht doch ganz unterschiedliche Benutzergruppen an. Wenn ihr das mit my.jdownloader.org jetzt ordentlich zu Ende entwickelt, werdet ihr bestimmt eine Menge Benutzer dafür begeistern können.

Wie gesagt. Uns fehlt da echt die Zeit. Wenn das Thema jemand eigenverantwortlich angehen will. gerne.

Etwas Java schadet nicht, die gängisten Webdeveloper Skills sollten aber natürlich da sein. Codeserver, Bugtracker usw stellen wir natürlich, und stehen auch mir Rat (und wenig Tat) gerne zur Seite.

[thecoder2012]

Originally Posted by coalado

Die größte Schwachstelle sind vermutlich die statischen Webinterface Inhalte von my.jdownloader.org. Weil die NOCH nicht über eine https Verbindung laufen.

Die Frage wäre ob der eingesetzte Webserver dann TLS 1.2 unterstützt? (wenn alles https ist)

Und ob z.B. auf my.jdownloader.org bereits im Browser (z.B. per JavaScript) bei der Anmeldung vorgehasht wird, so das auch dieses Passwort niemals bekannt wäre.

Daher auch in meinem vorherigen Posting die Frage nach einer stärkeren Verschlüsselung und nicht erst wenn es absolut nötig wird. Unabhängig davon ob einige User nun die Implentierung verstehen oder nicht.

Sicherheit ist ein schwieriges Thema und fortlaufende Arbeit.

Siehe **External links are only visible to Support Staff**
**External links are only visible to Support Staff**
und leider auch **External links are only visible to Support Staff**
**External links are only visible to Support Staff**

Grundsätzlich bin ich dafür auch die Anmeldung mit OpenID zu ergänzen um möglichst Anonym zu sein. Gibt ja auch recht sichere anonyme Zahlungsarten für spätere Premiumdienste für beide Seiten.

Originally Posted by coalado

[...]
[Bezüglich "direktem Webinterface"]
Wie gesagt. Uns fehlt da echt die Zeit.
[...]

Habe ich volles Verständnis für. Da müsste sich natürlich jemand finden, der sich der Aufgabe annimmt. Aber zuallererst müsste halt auch erkennbar sein, dass so ein (externes) Projekt auch langfristig wohlwollend geduldet wird.

Originally Posted by coalado

[...]
Wenn das Thema jemand eigenverantwortlich angehen will. gerne.
[...]
Codeserver, Bugtracker usw stellen wir natürlich, und stehen auch mir Rat (und wenig Tat) gerne zur Seite.

Freut mich zu lesen, dass wir vielleicht doch noch Hoffnung auf ein direktes Webinterface haben dürfen. Deine Aussage von letzter Woche klang da ehrlich gesagt noch ganz anders.

Originally Posted by coalado

[...]
Ich bin für ziemlich alles zu haben - auch direkte Kommunikation - aber zumindest für die Authentifizierung wird ein MyJDownloader Account nötig sein.
[...]
Und ja.... wir werden Erweiterungen und ko, die das umgehen wollen sicherlich nicht freudig empfangen.

Wie dem auch sei, ich hoffe, dass ihr da jetzt doch noch eine langfristig offen Einstellung zu dem Thema finden werdet. Ich bin mir wie gesagt sicher, dass das letztlich zu "Ruhm und Ehre" des ganzen JD-Projekts beitragen wird und das wiederum wird sich auch positiv auf den Erfolg von my.jdownloader.org auswirken. Und ich glaube auch nicht, dass sich die beiden Projekte in großem Umfang gegenseitig Benutzer abgraben werden. Das werden doch ziemlich unterschiedliche Benutzergruppen sein.

Originally Posted by thecoder2012

Die Frage wäre ob der eingesetzte Webserver dann TLS 1.2 unterstützt? (wenn alles https ist)
[...]

Ich habe selber zwar auch noch gewisse Bedenken bezüglich my.jdownloader.org, aber ich habe schon das Gefühl, dass die Entwickler dort zumindest ehrlich versuchen, im Rahmen der Umstände alles nach bestem Wissen und Gewissen umzusetzen. Und ich denke schon, dass dann (bei Aktivierung von https) auch alle Sicherheits-Features, die sich aus den Browsern und dem Server standardmäßig "rausquetschen" lassen, auch wirklich aktiviert werden...... hoffe ich mal.

Originally Posted by thecoder2012

[...]
Und ob z.B. auf my.jdownloader.org bereits im Browser (z.B. per JavaScript) bei der Anmeldung vorgehasht wird, so dass auch dieses Passwort niemals bekannt wäre.
[...]

:biggrin:
Das ist schon jetzt der Fall! Ich hatte das zuerst auch nicht kapiert, aber das ist bereits implementiert - siehe eines meiner obigen Postings (keine Sorge, ich hätte meine eigenen Postings auch nicht gelesen, die sind mir einfach zu lang geraten ).
Hab' das inzwischen auch mal mit Firebug überprüft. Was da an Daten übertragen wird, sieht zumindest sehr nach "gehasht" aus.
Ich muss wirklich zugeben, dass mir dieses Feature imponiert hat. Ich habe das bisher noch nirgends anderswo gesehen. Nicht bei Google, nicht bei Facebook. Keine Ahnung, ob sowas überhaupt irgendwo anders bereits angewandt wird.

Originally Posted by thecoder2012

[...]
Sicherheit ist ein schwieriges Thema und fortlaufende Arbeit.
[Thema TLS 1.2]
[...]

Oh ja, wahre Worte. Leider übersteigt das mein Begriffs-Vermögen nur allzu oft.
In dem Zusammenhang übrigens auch sehr interessant "Perfect Forward Secrecy". Das könnte man dann ja bei der Gelegenheit (https) auch gleich noch aktivieren, wenn man sowieso schon dabei ist.

heise.de/security/artikel/Zukunftssicher-Verschluesseln-mit-Perfect-Forward-Secrecy-1923800.html
http://de.wikipedia.org/wiki/Diffie-...Csselaustausch

Sehr faszinierend, dass es tatsächlich möglich ist, über einen öffentlichen Kanal, wo jeder mitlesen kann, einen Schlüssel auszutauschen, und trotzdem kann keiner der Mitlesenden den Schlüssel herausfinden. Für mich wirkt das immer noch wie Zauberei.

Naja, aber ich schweife schon wieder vom eigentlichen Thema ab...

[titus]

Originally Posted by coalado

Trotz meiner Erklärungen zum Thema Verschlüsselung hier von Plaintext zu reden ist Quatsch. Entweder hast du nicht gelesen was geschrieben wurde, oder du willst einfach nur trollen

Oder ich glaube einfach, dass ein Coder, der weiter oben noch schrieb, man müsse Programmierern eh trauen, weil man ja nie wisse, was genau die Software so anstelle, immer irgendeine Möglichkeit hat, an die Daten zu kommen, wenn er denn will.

Originally Posted by coalado

Für dich ist er unnötig. Für tausende andere ist er nötig, weil sie ohne diesen "Komfort" gar kein Webinterface nutzen könnten.

Das sie bisher anscheinend auch gar nicht brauchten.

Originally Posted by coalado

Und trotzdem erwartest du von uns, dass wir alles nach deinen Wünschen umstellen, oder gar extra ein zweites Webinterface bauen?

Von dir erwarte ich gar nichts, nicht einmal vernünftigen Umgang mit konstruktiver Kritik oder die Einsicht, dass man sich durchaus über aus Vorversionen verschwundene Features ärgern kann.

[coalado]

Originally Posted by hightower5

Die Frage wäre ob der eingesetzte Webserver dann TLS 1.2 unterstützt? (wenn alles https ist)

Wir haben gerade erst begonnen my.jdownloader.org auf https umzustellen.

Originally Posted by hightower5

Und ob z.B. auf my.jdownloader.org bereits im Browser (z.B. per JavaScript) bei der Anmeldung vorgehasht wird, so das auch dieses Passwort niemals bekannt wäre.

Was meinst du mit vorgehasht? Das Passwort wird nach der Eingabe gehasht, und als Plaintext nie wieder verwendet.


Unser Server kann laut Doku TLS 1.2 (Nginx in aktueller Version). Deine Links lesen sich allerdings so als ob die meisten Browser damit noch Probleme hätten. Du scheinst dich da ja auszukennen. Wie machst du das bei 9kw?

OpenID hat für mich jetzt echt nichts mit Sicherheit zu tun. Da kann ich den MyJD Account doch gleich mit Facebook koppeln ;-P


So nebenbei: Der NUtzer ist nicht an my.jdownloader.org gebunden. Das zeug kann auch Lokal gestartet werden, oder vom JD verteilt werden, oder es findet sich ein Drittanbieter, der ein super Webinterface hinstellt, und das dann per Werbung oder so finanziert. (Vertrauen?)

Theoretisch könntest du das webinterface auch auf **External links are only visible to Support Staff****External links are only visible to Support Staff** stellen.

Originally Posted by karlheinz

Habe ich volles Verständnis für. Da müsste sich natürlich jemand finden, der sich der Aufgabe annimmt. Aber zuallererst müsste halt auch erkennbar sein, dass so ein (externes) Projekt auch langfristig wohlwollend geduldet wird.

WIe gesagt. Es sollte halt nicht im KOnflikt mit den Premiumfunktionen von MyJDownloader stehen - oder es fällt uns was ein wie wir entsprechende Funktionen trotz direktem WI an ein Premiumkonto binden können. MUs man drüber reden. Aber solange der Funktionsumfang das alte WI nicht weit übersteigt, sehe ich da keine Probleme.

Originally Posted by karlheinz

Das werden doch ziemlich unterschiedliche Benutzergruppen sein.

Vermute ich auch. Und solange das so ist, wären alle glücklich.

Originally Posted by karlheinz

Ich habe selber zwar auch noch gewisse Bedenken bezüglich my.jdownloader.org, aber ich habe schon das Gefühl, dass die Entwickler dort zumindest ehrlich versuchen, im Rahmen der Umstände alles nach bestem Wissen und Gewissen umzusetzen. Und ich denke schon, dass dann (bei Aktivierung von https) auch alle Sicherheits-Features, die sich aus den Browsern und dem Server standardmäßig "rausquetschen" lassen, auch wirklich aktiviert werden...... hoffe ich mal.

Natürlich tun wir das. Trotzdem sind wir für Tipps jederzeit dankbar.



@Titus: Dir zu antworten ist mir langsam zu doof. Man kann mir denke ich nicht vorwerfen dass ich mich hier nicht der Kritik stellen würde. Jeder hier schafft es den richtigen Ton zu treffen - trotz Kritik. Nur von deinen Beiträgen fühle ich mich doch arg "angefeindet". Liegt das an mir? In meinen Augen ist auch kein Feature "weg". Das neue WI kann deutlich mehr als das alte. Es ist auch num ein vielfaches sicherer als das alte. Du willst es wieder so wie früher. Da wirst du drauf hoffen müssen, dass sich jemand findet der coden kann, und das auch will.

[thecoder2012]

Was meinst du mit vorgehasht? Das Passwort wird nach der Eingabe gehasht, und als Plaintext nie wieder verwendet.

Laut karlheinz2013 wird es ja bereits so gemacht, dann hab ich zu dem Thema nichts gesagt.

Unser Server kann laut Doku TLS 1.2 (Nginx in aktueller Version). Deine Links lesen sich allerdings so als ob die meisten Browser damit noch Probleme hätten. Du scheinst dich da ja auszukennen. Wie machst du das bei 9kw?

Also zu dem Thema lässt sich leider wenig sagen. Grundsätzlich im Webserver einfach aktivieren und ansonsten bleibt das Problem mit den Browsern. Firefox und Chrome können es in stabilen Version noch nicht (wenn nur nighty/alpha/beta) aber soll noch in diesem Jahr folgen. Bei IE muss es explizit aktiviert werden.

Prüfen des Servers kann man es mit einem einzigen Befehl: openssl s_client -connect my.jdownloader.org:443
Laut dem Check wird TLS v1.2 vom Webserver auch tatsächlich unterstützt.

Grundsätzlich geht es mit der letzten nightly von Firefox und dürfte innerhalb von so 12-18 Wochen in der Stable landen (Version 25?) und auch Erweiterungen/Einstellungen um TLS 1.2 zu erzwingen, wenn der Webserver es mitmacht. Einzige was man machen könnte wäre ein Hinweis welche Methode der Webserver/Browser gerade nutzt, falls es technisch möglich ist. Meines Wissens ist nur TLS 1.2 als sicher genug anzusehen aber lieber eine niedrige Version/Methode von SSL/TLS als gar nichts.

Man müsste auch mal schauen welche Lib/Methode JD2 da intern unterstützt. Hinzu kommt dann noch oft das Thema Zertifikate und viele kümmern sich um die Sicherheit beim Download eher wenig.

Bisher leider eine unschöne Lösung bei den Browsern für mehr Sicherheit. Auch einige Libs können es bisher nicht oder nur eingeschränkt. Obwohl TLS 1.2 schon fast 5 Jahre alt ist. Denke das viele andere Clients wie Android es auch noch nicht können. Finde es tragisch das die bekannten Browser mit Thema Sicherheit oft werben und selbst nicht alles unterstützen bisher.

OpenID hat für mich jetzt echt nichts mit Sicherheit zu tun. Da kann ich den MyJD Account doch gleich mit Facebook koppeln ;-P

Es ging mir weniger um die Sicherheit selbst sondern mehr darum das man bei kostenloser Nutzung keine Daten wie E-Mailadresse angeben müsste. Und OpenID ist nicht nur Facebook sondern ein ziemlich grosses Netzwerk von Seiten. Dazu hab ich keine Lust mich überall zusätzlich anzumelden. Wegen Premium müsste man dann eventuell mal schauen bzgl. verschiedener Zahlungsarten.

Hallo hightower 5,

ich wollte die nächsten Tage eine neue Version veröffentlichen.
Kannst du mich mal wegen den Ladezeiten kontaktieren?
40 - 60 Sekunden bei Dir ist wirklich viel.

PM oder Mail an info@pixelvalley.de

[titus]

Originally Posted by coalado

Jeder hier schafft es den richtigen Ton zu treffen - trotz Kritik. Nur von deinen Beiträgen fühle ich mich doch arg "angefeindet". Liegt das an mir?

You tell me. Jedenfalls würde ich

Originally Posted by coalado

Und trotzdem erwartest du von uns, dass wir alles nach deinen Wünschen umstellen, oder gar extra ein zweites Webinterface bauen?

nicht als den richtigen Ton bezeichnen. Weder hatte ich das gefordert noch hätte das was geändert. War also reine Provokation deinerseits, ebenso wie dein Trollvorwurf weiter oben.

Originally Posted by coalado

@Titus: Dir zu antworten ist mir langsam zu doof.

Dann lass es, die Standpunkte sind ja geklärt.

Wir werden sehen, wie gut ihr bei einer Klientel, die OCHs ausgiebig nutzt, mit Premium-Funktionen punkten könnt. Die headless-Funktion ohne myjdownloader ist mir Geld wert, entweder geht das dann an euch oder denjenigen, den ihr es implementieren lasst (sollte sie wegen des Abstands zur Premium nicht allzusehr eingeschränkt sein).

[thecoder2012]

Originally Posted by coalado

Unser Server kann laut Doku TLS 1.2 (Nginx in aktueller Version). Deine Links lesen sich allerdings so als ob die meisten Browser damit noch Probleme hätten. Du scheinst dich da ja auszukennen. Wie machst du das bei 9kw?

Wollte nun nochmals etwas konkreter auf Sicherheit, SSL und TLS eingehen. Auch wegen my.jdownloader.org und den aktuellen Browsern. Erfahrung in Bezug auf Java habe ich damit bisher leider noch nicht.

1. Theorie TLS und SSL
SSL ist der Vorgänger bis Version 3 immer noch ein üblicher alter Standard.
TLS gibt sich teilweise als SSL 3.1, 3.2 bzw. 3.3 aus und ist der Nachfolger von SSL als Standard so gesehen.
Inzwischen in der verbesserten Version 1.2 wie in der RFC5246 (=> tools.ietf.org/html/rfc5246) aus dem Jahr 2008 zu finden. Version 1.0 ist bereits aus dem Jahre 1999 und unter RFC2246 zu finden.

2. Prüfen ob der Server TLS v1.2 unterstützt.
Befehl: openssl s_client -connect my.jdownloader.org:443

Ausgabe enthält min. 2 Zeilen:
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384

Wir sehen das der Webserver es schonmal beherrscht und können damit die Dokumentation von Nginx bestätigen. Genutzt wird dabei AES mit 256-Bit und dem Hashalsgo SHA384. Anmerkung auch Lighttpd (z.B. 1.4.x oder höher mit ssl) als Beispiel beherrscht es. Der Cipher kann abweichend sein und wird in der Regel zwischen Client und Server ausgehandelt.

2. Browser und TLS v1.2
Die meisten Browser können inzwischen TLS v1.0 und v1.1
Bei v1.2 trifft dies bisher nur eingeschränkt zu. Bei 1.2 ist der Algo/Hash für den Geheimschlüssel flexibler bzw. stärker und kann nicht wie bisher mit MD5/SHA1 eine einfache Schwachstelle darstellen.

2a. Firefox / SeaMonkey
Bis Version 24 muss es explizit aktiviert werden. (SeaMonkey 2.21)
Über about:config unter dem Wert security.tls.version.max auf 3 setzen.

Um TLS v1.2 zu erzwingen den Wert security.tls.version.min auf 3 setzen.
Ab Version 25/26 sollte es per Default aktiv sein und auch _**External links are only visible to Support Staff**

Wert 1 -> TLS 1.0 is the minimum required / maximum supported encryption protocol.
Wert 2 -> TLS 1.1 is the minimum required / maximum supported encryption protocol.
Wert 3 -> TLS 1.2 is the minimum required / maximum supported encryption protocol.

Version 23 und älter können nur TLS v1.1 / v1.0 (SeaMonkey 2.20)

2b. Chrome
In aktueller Version 29/30 sollte TLS v1.2 vollständig aktiviert und unterstützt sein. Ältere Versionen sollten aus Gründen der Sicherheit sowieso nicht mehr eingesetzt werden.

2c. Internet Explorer
In Version 11 sollte TLS v1.2 funktionieren und aktiviert sein. Ggf. muss es in 10 noch aktiviert werden.
Empfehlenswert ist Internet Explorer 11 wegen enorm erhöhter Geschwindigkeit bei der Verarbeitung.

TLS v1.0/1.1 deaktivieren im Internet Explorer => Internetoptionen => Erweitert => Nur das Kontrollkästchen TLS 1.2 aktivieren und 1.0/1.1 deaktivieren.

2d. Opera
In Version 10-12 muss es in jedenfall explizit aktiviert werden.
Bei der aktuellsten Version 17 ist es aktiviert und kann explizit auf TLS v1.2 eingestellt werden.
Extras => Einstellungen => Erweitert => Sicherheit => Sicherheitsprotokolle

2e. Safari
In der aktuellsten Version sollte es aktiviert und unterstützt sein. Allgemein sollte der Support seit Version 6 oder höher bestehen.

Siehe auch: kuketz-blog.de/nsa-abhoersichere-ssl-verschluesselung-fuer-apache-und-nginx/

Anmerkung: Es ist möglich das sowohl Browser als auch Server in Einzelfälle noch Probleme mit TLS v1.2 haben und daher man v1.2 nicht unbedingt erzwingen sollte. Bei Problemen würde sonst die Verbindung abgebrochen und damit die Funktion "gestört". Immerhin hat man dann die größte Sicherheit bei dem Thema. Tja meine Bank hat schonmal kein TLS v1.2 im Webserver, nichtmal v1.1 sondern nur v1.0. :(

Hey Ho!

myjdownloader is nicht schlecht für die meisten recht gut aber was ist wenn ich eine userverwaltung benötige?

mit dem alten webinterface konnte ich mir da etwas zusammenbasteln aber jetzt geht das nicht mehr.

habt ihr da ne lösung für mich parat?

[coalado]

phispo:

Also grundsätzlich ist die my.jdownloader API ja auch offen, und kann erweitert werden.

Was für eine Userverwaltung stellst du dir denn da vor?