Losemenge.de - Mindestlosemenge, Loseumlauf, Losevernichtung, Kontostände von mehr als 40 Projekten!

chrissel · 21 Juni 2011

Was mir gerade noch eingefallen ist: Hier sind ja sicherlich mehrere klamm-Premiumaccount Benutzer unterwegs.
Es gibt ja einige gratis Textlinks im Monat [sup][1][/sup], vielleicht kann ja der ein oder anderen zwischendurch mal ein paar Textlinks buchen wenn er diese eh nicht braucht

Meine sind für diesen Monat auf jeden Fall schon weg.

EDIT:

Also die Werbemittel habe ich nun auch auf meinen Webspace hochgeladen.
Warum auch immer diese nicht immer über myImg erreichbar waren..

- - - - - - - - - - - - -

[1]

klamm.de schrieb:
monatlich tausende GRATIS Textlinks (variabel, aktuell 30.000)

- klamm PREMIUM

kommissar · 22 Juni 2011

So sieht der Balken gut aus meines Erachtens.
Die Punkte sind klar ersichtlich und auch sonst ist alles gut zu erkennen.

P.S. Die Idee gefällt mir jeden Tag mehr und mehr.

jpwfour · 22 Juni 2011

chrissel schrieb:
...
Aber ich möchte das Projekt vollständig alleine durchführen, unabhängig von anderen klamm-Usern. Denn dann müssen die teilnehmenden User schon 2 anderen Usern vertrauen und nicht nur mich.
Das einzige was ich mir vorstellen könnte wäre eventuell mal eingeschränkten Lesezugriff, falls doch irgendwo Skepsis aufkommt, ob alles stimmt was ich da so auslese und anzeige.
....

Umso mehr daran mitarbeiten würden, umso unwahrscheinlicher werden doch manipulierte Werte? Einer alleine hat schnell mal 'ne Bio. aufaddiert, aber wenn nun 5 vollkommen unabhängige Leute daran arbeiten, müsste man ja erstmal Alle davon überzeugen

Transparenz geht auf jeden Fall anders, an sich könntest du problemlos den kompletten Source Code des Projektes offenlegen (bis auf die Passwörter, Schlüssel).
Inkl. Verschlüsselung, siehe: Kerckhoffs’ Prinzip vs. Security through obscurity

chrissel · 22 Juni 2011

jpwfour schrieb:
Umso mehr daran mitarbeiten würden, umso unwahrscheinlicher werden doch manipulierte Werte? Einer alleine hat schnell mal 'ne Bio. aufaddiert, aber wenn nun 5 vollkommen unabhängige Leute daran arbeiten, müsste man ja erstmal Alle davon überzeugen

Ja, das meine ich ja.

jpwfour schrieb:
Transparenz geht auf jeden Fall anders, an sich könntest du problemlos den kompletten Source Code des Projektes offenlegen (bis auf die Passwörter, Schlüssel).

Ich müsste aber Zugriff auf die live-Daten geben direkt über FTP z.B. und nicht einfach als Archiv oder so den Quellcode anbieten. Selbst wenn ich bei direkten Aufrufen der PHP-Dateien (läuft ja derzeit alles über mod_rewrite) den Sourcecode anzeige, könnte dieses eine manipulierte Darstellung sein.

Bububoomt · 22 Juni 2011

jpwfour schrieb:
Transparenz geht auf jeden Fall anders, an sich könntest du problemlos den kompletten Source Code des Projektes offenlegen (bis auf die Passwörter, Schlüssel).https://de.wikipedia.org/wiki/Security_by_Obscurity

Was bringt der Sourcecode? Aufm Server könnte wieder was ganz anderes laufen. Zudem, stell dir vor da ist ne Sicherheitslücke drin und die kann man mit dem Sourcecode leichter finden als ohne...

Je mehr darauf zugriff drauf hätten, desto weniger würden dann da mitmachen.

ice-breaker · 22 Juni 2011

Bububoomt schrieb:
Was bringt der Sourcecode? Aufm Server könnte wieder was ganz anderes laufen. Zudem, stell dir vor da ist ne Sicherheitslücke drin und die kann man mit dem Sourcecode leichter finden als ohne...

wenn bei dem wenig Code, der dafür notwendig ist, ne Sicherheitslücke drinne ist, dann ist schon ein Epic-Fail.

Generell lässt sich eben keine Transparenz herstellen, ohne Offenzulegen wieviele Lose auf jedem Account gezählt wurden....
Aber auch da könnte chrissel natürlich einbauen, dass einige Accounts falsch gezählt werden.

Die einzige Möglichkeit Transparenz zu schaffen, wäre alle Statistik-PWs + den Schlüssel zum Ermitteln des EF-Guthabens offen zu legen, aber das ist eben undenkbar.

hankfromhelvete · 22 Juni 2011

ice-breaker schrieb:
Generell lässt sich eben keine Transparenz herstellen, ohne Offenzulegen wieviele Lose auf jedem Account gezählt wurden....
Aber auch da könnte chrissel natürlich einbauen, dass einige Accounts falsch gezählt werden.

Warum sollte er das tun? Ich sehe da keinen Grund/Vorteil für den Betreiber, falsche Daten auszugeben. Es sei denn, er will klamm schaden :ugly:

Aber das denke ich mal eher nicht.

Bububoomt · 22 Juni 2011

ice-breaker schrieb:
wenn bei dem wenig Code, der dafür notwendig ist, ne Sicherheitslücke drinne ist, dann ist schon ein Epic-Fail.

Generell lässt sich eben keine Transparenz herstellen, ohne Offenzulegen wieviele Lose auf jedem Account gezählt wurden....

Naja passieren kann es. muß ja nicht am Code selber liegen, aber anderes Thema...

Naja man kann abwarten und wenn irgendwann ein Wert erreicht wird, dann könnte man ja mal schauen bzgl. Offenlegung oder sonst was.

hankfromhelvete · 22 Juni 2011

Wozu ist eigentlich der Button "Ansicht zurücksetzen"? Man kann ja nichts auswählen. Oder kommt das noch?

Lokutos · 22 Juni 2011

hankfromhelvete schrieb:
Wozu ist eigentlich der Button "Ansicht zurücksetzen"? Man kann ja nichts auswählen. Oder kommt das noch?

du kannst einen bereich markieren der dann vergrössert wird.
Aktuell noch nutzlos aber wenn das Projekt dann mal n Jahr läuft kann man sich dann da n Monat raus markieren etc.

HighClixx · 23 Juni 2011

ice-breaker schrieb:
wenn bei dem wenig Code, der dafür notwendig ist, ne Sicherheitslücke drinne ist, dann ist schon ein Epic-Fail

Natürlich. Und du codest alles perfekt.

Bububoomt · 23 Juni 2011

Muß ja ncihtmal im Code ein Fehler sein, sondern einfach eine Funktion die man benutzt, die eine Sicherheitslücke hat.
Banales Beispiel.
man benutzt int.parse um eine übergeben ID zu prüfen. Wenn nun aber int.parse einen Fehler hat....

Es kommt immer wieder vor (auch wenn Selten), das die einfachsten Funktionen einen Bug haben.

jpwfour · 23 Juni 2011

Bububoomt schrieb:
Muß ja ncihtmal im Code ein Fehler sein, sondern einfach eine Funktion die man benutzt, die eine Sicherheitslücke hat.
Banales Beispiel.
man benutzt int.parse um eine übergeben ID zu prüfen. Wenn nun aber int.parse einen Fehler hat....

Es kommt immer wieder vor (auch wenn Selten), das die einfachsten Funktionen einen Bug haben.

Und deswegen stellt man den Code nicht zur Verfügung? Hm, schon komisch, ich hätte wetten können,d ass es mittlerweile mehr SourceCode "Open" gibt als Closed, aber egal

Mir ist klar, dass man theoretisch jedem Vollzugriff geben müsste etc.
Es geht aber auch nicht um 100% Transparenz, dann würde das Projekt, wie schon richtig gesagt, nicht mehr laufen.

Aber um "mehr" Transparenz. Dazu könnte gehören, dass man sich in etwa anschauen kann, was der Webbi das macht, und vorallem, dass das Projekt von jemand anderem weitergeführt werden könnte, sollte der einzige Betreiber mal keine Lust mehr haben/verschollen sein usw. (Aussage ist ja: "Für die Community).

In dem Skript für EF-Betreiber finden sich kodierte Daten, zwar ist es kaum ein Problem, die in "menschenlesbaren Code" zu übersetzen, aber als Webbi würde ich mir so ein Skript, wo ich nicht ganz genau sehen kann, was es macht, niemals hochladen.

ice-breaker · 23 Juni 2011

HighClixx schrieb:
Natürlich. Und du codest alles perfekt.

ich glaube du verstehst meine Aussage nicht

Es gibt in dem Losemenge-Script maximal 5 Punkte an denen das Script mit Daten von außerhalb arbeitet, wenn in den 5 Mini-Teilen schon Fehler stecken würden, dann wäre das auf eine große Anwendung betrachtet der löcherichste Schweizer Käse den du je gesehen hast.

Bububoomt schrieb:
Muß ja ncihtmal im Code ein Fehler sein, sondern einfach eine Funktion die man benutzt, die eine Sicherheitslücke hat.
Banales Beispiel.

glücklicherweise kommt das nur sehr selten vor, und Sicherheitslücken die dazu da sind "malicious input" zu bearbeiten noch viel viel viel seltener.

jpwfour schrieb:
Und deswegen stellt man den Code nicht zur Verfügung? Hm, schon komisch, ich hätte wetten können,d ass es mittlerweile mehr SourceCode "Open" gibt als Closed, aber egal

Security through obscurity in seiner reinsten Form.
Manche halten dies eben für Sicherheit :roll:

jpwfour schrieb:
In dem Skript für EF-Betreiber finden sich kodierte Daten, zwar ist es kaum ein Problem, die in "menschenlesbaren Code" zu übersetzen, aber als Webbi würde ich mir so ein Skript, wo ich nicht ganz genau sehen kann, was es macht, niemals hochladen.

Man kann in dem Script doch ablesen was es tut, denn das kann man nicht verstecken.

Bububoomt · 23 Juni 2011

Da brauchst nicht wetten, das wissen wir alle und wir wissen alle wie oft auch diese Ziel von Bösewichten sind. Ich muß da auch ncihts aufzähln, überall wo es etwas Interessantes gibt oder was "zu holen", das ist nun mal ein Ziel...

Was er macht, und wer etwas Ahnung vom Proggen kann es nach machen.

Wenn er es veröffenlticht haben wir nachher 20 solcher Projekte, was scheiße wäre, weil sich nachher dann alle irgendwo anders anmelden oder gar nicht.

Da sollte man halt über nen ganz anderen Weg nachdenken, wie man vielleicht die Daten verifizieren könnte....

Das codierte ist sind die Dateien, die angelegt werden. Könnte man sicherlich noch anders machen...

chrissel · 23 Juni 2011

jpwfour schrieb:
In dem Skript für EF-Betreiber finden sich kodierte Daten, zwar ist es kaum ein Problem, die in "menschenlesbaren Code" zu übersetzen, aber als Webbi würde ich mir so ein Skript, wo ich nicht ganz genau sehen kann, was es macht, niemals hochladen.

ice-breaker schrieb:
Man kann in dem Script doch ablesen was es tut, denn das kann man nicht verstecken.

Bububoomt schrieb:
Das codierte ist sind die Dateien, die angelegt werden. Könnte man sicherlich noch anders machen...

Ja, da es nun wirklich ein kleines Installationsscript ist (bei dem ich mir ehrlich gesagt auch nicht die meiste Mühe gegeben habe: Alleine ein Design fehlt da ja z.B.), sind in der install.php die Daten für alle Dateien die benötigt werden drin. Base64 kodiert, damit ich die vernünftig in der Datei abspeichern kann.
Wenn das Script installiert wird liegen die kodierten Daten als nicht kodierte Dateien vor und jeder kann sich anschauen, was dort gemacht wird

Jeder der meint den Code überprüfen zu können sollte merken, dass die kodierten Daten nach der Installation unkodiert vorliegen.. von daher habe ich mir nicht große Gedanken dabei gemacht, dass es stören könnte, dass dort etwas kodiert vorliegt.

jpwfour · 24 Juni 2011

chrissel schrieb:
.... sind in der install.php die Daten für alle Dateien die benötigt werden drin. Base64 kodiert, damit ich die vernünftig in der Datei abspeichern kann.
Wenn das Script installiert wird liegen die kodierten Daten als nicht kodierte Dateien vor und jeder kann sich anschauen, was dort gemacht wird

Jeder der meint den Code überprüfen zu können sollte merken, dass die kodierten Daten nach der Installation unkodiert vorliegen.. von daher habe ich mir nicht große Gedanken dabei gemacht, dass es stören könnte, dass dort etwas kodiert vorliegt.

Ich weis das und würde sowas eh erst mal in ner sicheren Umgebung ausprobieren.

Und wenn die Dateien entpackt sind (und einmal includ'ed wurden) könnte es schon zu spät sein

Mir geht es um den Otto-Normal-Webbi, der meist eh kaum Ahnung von X oder Y hat. Der vetraut meiner Meinung nach jedem Scriptshop und installiert sich übelstes Zeug, aber er hat ja für gezahlt, ausserdem "will er Addon Z jetzt sofort haben!".

Aber irgensoein Skript, von irgendwem, was irgendwas macht, und zwar mit "seinem EF und seinen Losen?"

Dazu wird man diese Webbis nicht bekommen.

Vermutlich auch nicht, indem man die Dateien unkodiert ablegt.

Evtl. müsste man auf die Seitenbetreiber "offensiv" zugehen, sie auf losemenge.de ansprechen etc., würde ja schon reichen, wenn 2-3 "große" Seiten "offiziell" mitmachen. Dann ziehen einige der Seiten(betreiber), die diesen Seiten sonst auch alles nachzumachen versuchen, evtl. nach.

jpwfour · 24 Juni 2011

Heut gönn ich mir mal nen Doppelten

(weil dieser Post vollkommen unabhängig vom vorgehenden ist!)

In der losemenge.php wärs denke ich praktisch im check (Zeile 3) noch auf die Beschreibbarkeit der temp zu prüfen: is_writable().

Wenn der "Installateur" die Anleitung zu genau nimmt:

setze die Rechte von PHP für dieses Verzeichnis ... zurück

kann das Skript u.U. nachher die Datei temp nicht beschreiben.

Das wär dann ziemlich unschön, weil die Lose von EF -> Klamm-Account, aber nicht mehr zurück gehen, da die Menge nicht abgespeichert würde.

chrissel · 24 Juni 2011

Vielen Dank jpwfour.

Habe ich nun sofort geändert und hochgeladen

Zum Thema Seitenbetreiber direkt ansprechen:
Ich habe hier ja schon einmal geschrieben, dass ich das eventuell mache. Allerdings habe ich nun wirklich überlegt, ob dass nicht aufdringlicher Spam ist und somit das Projekt eventuell unbeliebt macht?
Was meint ihr denn so?
Oder gibt es hier eventuell schon ein paar Seitenbetreiber die den richtigen Startschuss für die EF's machen wollen?

Die-Fackel · 24 Juni 2011

Hier lesen ja einige Seitenbetreiber mit.

Wäre schön wenn die mal Ihre Bedenken äußern würden.

Losemenge.de - Mindestlosemenge, Loseumlauf, Losevernichtung, Kontostände von mehr als 40 Projekten!

chrissel

Woohooo!

kommissar

Well-known member

jpwfour

NoOb

chrissel

Woohooo!

Bububoomt

ohne Vertrauen

ice-breaker

return void

hankfromhelvete

RaR 2012

Bububoomt

ohne Vertrauen

hankfromhelvete

RaR 2012

Lokutos

$_POST => dev/null

HighClixx

Bububoomt

ohne Vertrauen

jpwfour

NoOb

ice-breaker

return void

Bububoomt

ohne Vertrauen

chrissel

Woohooo!

jpwfour

NoOb

jpwfour

NoOb

chrissel

Woohooo!

Die-Fackel

Well-known member