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

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
 
Zuletzt bearbeitet:
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. :)
 
...
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
 
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.

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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
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.

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.

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:

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.
 
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...
 
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.

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.
 
.... 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.
 
Heut gönn ich mir mal nen Doppelten :p (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.
 
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?
 
Hier lesen ja einige Seitenbetreiber mit.

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