[.NET] Nosomco Games - Kindersicherung

henni · Verfasst: Do 11.03.10 14:57

Nosomco Games - Kindersicherung

Hallo Community!

Titel
"NoSoMCo Games" soll das Projekt heißen, was so viel heißt wie "Not so much Computer Games" - kurzum, es wird sich um eine Kindersicherung handeln.
Über den Titel lässt sich noch viel diskutieren, er ist mir nur spontan in den Sinn gekommen; ich bin offen für weitere Vorschläge.

Beschreibung und Ziel
Kindersicherungen gibt es viele im Internet, einige kostenlos, andere extrem teuer. Für die meisten gibt es Anleitungen, wie sie deaktiviert werden können, viele haben an sich einfach extreme Sicherheitslücken.
Nosomoco Games soll ein oder mehrere eingeschränkte Benutzerkonten mit einem Kinderschutz versehen können - die Eltern müssen immer die volle Kontrolle, möglichst von Überall her, haben.
Der Schutz soll auf das lokale Netzwerk erweitert werden können, sodass ein Kind auf zwei Rechnern spielen darf, die aber ein gemeinsames Zeit-Konto benutzen.
Trotzdem soll das System weitestgehenst dezentral laufen, d.h. ohne permanenten Server.
Das Projekt soll höchst erweiterbar sein, sodass jeder seinen eigenen Schutz hinzuprogrammieren kann (zu den bereits vorhandenen Schützen (Pl. von Schutz??) komm ich später).

Ziel ist es also, eine effektive, zu 100% sichere, flexible, erweiterbare und trotzdem einfache Kindersicherung zu erstellen.

Sofern es möglich ist, sollte die Windows 7 Parental API genutzt werden.

Programmiersprache
.Net soll die Kernsprache sein - welche konkrete Sprache ist letztendlich dann ja egal (C#, Prism, Visual Basic etc.).
Jeglicher unmanaged Code (durch z.B. C++) sollte in einer .Net-Sprache gekapselt werden.

Lizenz
Freeware, wenn nicht sogar Open Source.
Mir ist es egal.

Dauer
Bis es fertig ist!
Ein System ist nie fertig, man hört nur irgendwann auf zu programmieren.
Da Nosomco Games aber eine offene und dokumentierte Schnittstelle haben soll, kann zum Schluss jeder selbst noch weiter daran arbeiten.

Features, die unterstützt werden sollen
Die Kindersicherung soll
* im Netzwerk eingesetzt werden
* zwischen Spielen und Hausaufgaben (also Office-Programmen) differenzieren
* brutale Spiele blocken
* flexibles Zeit-System anbieten
* theoretisch unknackbar sein (außer die Netzwerkkommunikation [1])
* komplett erweiterbar sein

Wobei das Zeit-System folgendes können soll:
* Es gibt Zeitfenster, indenen ein Zeit-Maximum festgelegt werden kann
Beispiel: Innerhalb von 24 Stunden darf nur 4 Stunde gespielt werden und innerhalb 1 Stunde darf nur 55 Minuten gespielt werden und innerhalb 1 Woche darf nur 12 Stunden gespielt werden.
Das heißt, das Kind darf am Montag, Dienstag und Mittwoch 4 Stunden spielen, wobei in jeder Stunde 5 Minuten Pause gemacht werden muss, dann aber nicht mehr, da das Wochen-Limit von 12 Stunden bereits erreicht wurde.
Nicht ausgenutzte Limits verfallen natürlich.

* Es gibt ein Zeit-Konto
Von diesem Konto wird die Zeit abgebucht, die gespielt wird.
Ist keine Zeit mehr vorhanden, kann nicht gespielt werden.
Es kann aber auch Zeit hinzugefügt werden (durch Eltern).

* Es gibt ein Ticket-System
Eltern können so mit einem privaten Schlüssel Tickets (= Gutscheine) von Überall generieren, mit denen eine Zeit verknüpft ist.
Wird dieses Ticket eingelöst, wird der Betrag auf das Zeit-Konto gebucht.

[1] Mir ist klar, dass die Netzwerkübertragung theoretisch nicht sicher ist.
Selbst wenn eine asymmetrische Verschlüsselung gebraucht wird, lässt sich der Schlüssel durch Disassemblierung immer noch feststellen.
Darum sollte dieser Teil des Systems auch obfuskiert werden.

Zeitlicher Ablauf
Kann ich jetzt noch nicht sagen.

Benötigte Fähigkeiten
* Kenntnisse in irgendeiner .Net-Sprache
* Kenntnisse in objektorientierter Programmierung

Wobei folgendes gewünscht ist:
* Kenntnisse in Windows 7 Parental API

Umso mehr Kenntnisse, desto besser natürlich!
Teamfähigkeit und alle anderen selbstverständliche Fähigkeiten (Umgang mit PC

) sind Vorraussetzung.

Ein gewisses Niveau, Engagement und Erfahrung wird aber erwartet - die Grundlagen müssen vollständig beherrscht werden!

Teamgröße
Die wesentliche Planung soll in einem Kernteam von maximal 4 Personen (inklusiv mir) stattfinden.
Das Entwicklerteam sollte eine Größe von 10 Mitgliedern keinesfalls überschreiten.

Nachdem das Kernteam die Planung und das Konzept fertiggestellt hat, können dann alle ihren zugeordneten Teil entwickeln - jeder, so gut wie er kann.
Hauptsache ist, dass die vom Kernteam getroffenen Kontrakte der jeweiligen Module eingehalten werden.

Bei kritischen Problemen werde ich als Monarch eine Entscheidung treffen oder die Entscheidung demokratisch durchführen

Ich hoffe, dass dieses Projekt Anklang findet und erfolgreich verlaufen wird!

traceurmicha · Verfasst: Sa 13.03.10 15:05

Jo Wie gesagt bin Dabei, hoffe das noch weitere Leute sich uns anschließen!

Ehemaliges Mitglied Erhaltene Danke: 1

Ich will euch nicht entmutigen, aber das Projekt ist bei weiten zu umfangreich und komplex, als dass man so was über ein Forum managen könnte. Hinzukommt, dass es zu ihr euch da wohl zu viel auf einmal vorgenommen habt. Es wird wahrscheinlich wie folgt laufen: Es werden sich noch ein paar melden, dann wird es Koordinationsprobleme geben, es stellt sich kein Sichtbarer Erfolg ein, mit der Folge, dass es sang und klanglos im Sande verlaufen wird.

Reduziert den Funktionsumfang und die Komplexibilität auf ein Mindests. Haltet das Team klein. Höchstens zwei bis drei Leute. Wenn ihr dann eure minimale Minimalanforderung innerhalb einer überschaubaren Zeit hinbekommt und ihr ein Erfolgserlebnis habt, könnte ihr den Funktionsumfang nach und nach Stück für Stück erweitern.

Als erstes würde ich beispielsweise das mit dem Zeitmanagement machen. Aber da auch erst mal nur mit einer Minimalanforderung: Stundenkonto für einen Monat mit festgelegten Loginzeiten für ein lokales System. Wobei das natürlich ein Feature ist, was Windows schon mitbringt.

Aber man kann es ja zum Üben und zum Einstieg versuchen nachzuprogrammieren. Wenn ihr das habt, könnt ihr versuchen das Zeitkonto eines Benutzers im Netzwerk zu verwalten.

Also:
1. Meilenstein: Zeitkonto mit festgelegten Loginzeiten
2. Meilenstein: Verwalten des Stundenkontos im Netzwerk

Und dann könnt ihr nach und nach weiter Features in kleinen überschaubaren Schritten dazu nehmen. Und ich würde euch empfehlen es gleich von Anfang an richtig zu machen und streng objektorientiert zu arbeiten und tzumindest grobe Klassen Diagramme zu entwerfen bevor ihr auch nur eine Zeile Projektcode schreibt. Nebenbei kann man ja mal in Quick and Dirty Testprogrammen versuchen ein Stundenkonto zu führen oder zu gucken, wie man das mit den Loginzeiten machen könnte.

Ach ja, die Schritte sollten so klein sein, dass sie sich an einem, höchstens zwei Tagen umsetzen lassen. Zumindest geht es mir so, dass ich recht schnell das Interesse verliere, wenn ich rausbekommen habe, wie es geht und die Umsetzung in ein Projekt dann nicht am gleichen Tag fertig wird und ich mehrere Tage brauche/bräuchte. Meist endet so was dann in einem "proof of concept" und das Projekt bleibt auf der Strecke, weil ich zu faul für den Rest bin. Mein ADSReader www.michael-puff.de/Artikel/ADS.shtml ist zum Beispiel so ein Fall oder die SFXTools www.michael-puff.de/...r/Delphi/Programme/.

henni · Verfasst: Mo 15.03.10 22:22

Hi!

Zitat:

das Projekt ist bei weiten zu umfangreich und komplex, als dass man so was über ein Forum managen könnte

Würde ich nicht unbedingt sagen...

Zitat:

Haltet das Team klein. Höchstens zwei bis drei Leute.

Darum ist ein Kern-Team vorgesehen, das ein Konzept plant und die "Arbeit" einteilt.

Zitat:

könnte ihr den Funktionsumfang nach und nach Stück für Stück erweitern.

Bedingt: Das zugrunde liegende Konzept muss Erweiterungen erlauben.
Fängt man da schon falsch an, funktioniert gar nichts mehr und das "Stück für Stück" ist nicht mehr möglich.
Der Funktionsumfang kann außerdem parallel erweitert werden.

Zitat:

Als erstes würde ich beispielsweise das mit dem Zeitmanagement machen.

Das sollte IMHO als eigenständiges, externes Modul arbeiten, am Anfang also halb unberücksichtigt bleiben.

Zitat:

Stundenkonto für einen Monat mit festgelegten Loginzeiten für ein lokales System.

Das sind dann nachher konkrete Features, die dann in Massenware produziert werden können.

Zitat:

Und ich würde euch empfehlen es gleich von Anfang an richtig zu machen und streng objektorientiert zu arbeiten und tzumindest grobe Klassen Diagramme zu entwerfen bevor ihr auch nur eine Zeile Projektcode schreibt.

Das hab ich mir auch so gedacht.
Darum soll das Kern-Team auch nur Konzepte designen etc.

Zitat:

Ach ja, die Schritte sollten so klein sein, dass sie sich an einem, höchstens zwei Tagen umsetzen lassen.

Wenn ein gutes Konzept steht, lassen sich die Schritte meistens extrem schnell erledigen.

Zitat:

Zumindest geht es mir so, dass ich recht schnell das Interesse verliere, wenn ich rausbekommen habe, wie es geht und die Umsetzung in ein Projekt dann nicht am gleichen Tag fertig wird und ich mehrere Tage brauche/bräuchte.

Die programmiertechnische Schwierigkeit ist untergeordnet. Das Konzept muss stimmen und ist extrem wichtig - das Programmieren ist dann (fast) ein Kinderspiel; dieser Aha-Effekt, der die Programmierung dann total langweilig macht, tritt in diesem Projekt also nicht in dem Maße auf.
Mir geht es in diesem Punkt übrigens oft genauso wie dir

So könnte das Konzept der Kindersicherung in etwa aussehen:
Moderiert von Narses: Bild als Anhang hochgeladen.

Noch etwas zu einem Netzwerkproblem, das zwangsläufig entsteht:
Wenn eine Einschränkung z.B. ist, dass das Kind nicht mehr als 5 Stunden pro Tag spielen darf, könnte das Kind auf jedem Computer 5 Stunden spielen, also insgesamt 10 Stunden.
Um dieses Problem zu lösen, muss der Benutzer-Account mit jedem Computer synchronisiert werden - da das bei dezentralen System etwas schwierig ist, hab ich mir überlegt, dass das Kind prinzipiell nur auf einem Computer spielen darf.
Will es auf einem anderen PC im Netz spielen, muss es seinen gesamten Account auf diesen PC transferieren (allerdings kann dann nicht mehr auf dem ursprünglichen Computer gespielt werden).
Das Synchronisierungs-Problem wird also durch Verhinderung von asynchronen Benutzerkonten gelöst.

Einloggen, um Attachments anzusehen!

ps2freak · Hält's aus hier Beiträge: 1

Hey, Hallo!
Da der letzte Beitrag schon über 1 Jahr her ist, würde ich gerne mal wissen, ob aus dem Projekt was geworden ist!?
Habt ihr es geschafft die Teams zu bilden?
Habt ihr angefangen zu entwickeln?

Weil mich interessiert die Idee, kann aber nicht selber programmieren, sondern würde nur gerne das Programm haben, wenn´s dann fertig ist. Die Idee jedenfalls ist wunderbar!!

henni · Verfasst: Mi 03.08.11 11:00

Hallo ps2freak,

leider habe ich das Projekt - wie in dieser Sparte bereits viele vor mir schon von sich gegeben haben - (vorerst) aufgeben müssen.
Einerseits, da mein Bruder mittlerweile alt genug ist und nicht nicht weiß, ob sich das Projekt unter Berücksichtigung der Interessenten überhaupt lohnt, anderseits, weil mein Mitstreiter ganz schnell an den UML-Diagrammen das Interesse verloren hat. Es fehlt mir jetzt auch einfach die Zeit für dieses Projekt.

Ein erster (Pre-)Prototyp existiert aber schon: Eine (statisch einprogrammierte) Regel im Server hat dafür gesorgt, dass unter einem (statisch eingegeben) Benutzer Notepad nach einer voreingestellten Zeit sanft geschlossen und 30 Sekunden später, wenn das Programm immer noch läuft, brutal beendet wird.

Wen es interessiert, so einfach sieht diese "Regel" auf dem Server aus:

markieren

C#-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:

[Plugin(PluginType.Factory)]
public class NotepadApplicationLimitsControl : IApplicationLimitsControl
{
  public ApplicationLimitCheck CheckApplicationLimits(IApplicationTypePropertys applicationTypePropertys, IUserAccount currentUserAccount)
  {
    if ((applicationTypePropertys.Propertys["Filename"] as string).ToLower().EndsWith("\\notepad.exe"))
    {
      TimeSpan allowedTimeSpan = currentUserAccount.Propertys.GetPropertyOrDefault<TimeSpan>("AllowedNotepadTime", TimeSpan.FromMinutes(5));
      TimeSpan runningTimeSpan = DateTime.Now - ((DateTime)applicationTypePropertys.Propertys["StartTime"]);
      if (runningTimeSpan.CompareTo(allowedTimeSpan) > 0)
        return ApplicationLimitCheck.ApplicationForbidden(applicationTypePropertys, new TimeLimitationBreak());
      else
        return ApplicationLimitCheck.ApplicationAllowed(applicationTypePropertys, new TimeLimitation(allowedTimeSpan - runningTimeSpan));
    }

    return ApplicationLimitCheck.ApplicationAllowed(applicationTypePropertys, null);
  }
}

applicationTypePropertys ist ein gemarshaltes Objekt vom Client.

Große Teile des UML-Diagramms habe ich auch schon implementiert, für fehlende Module existieren Mock-Implementierungen, damit der Prototyp läuft.

Als Netzwerk-Kommunikation habe ich mich der Einfachheit halber für .Net Remoting entschieden, was ein großer Fehler war. WCF-Services sind wesentlich einfacher und besser (regelmäßig pollen muss der Client sowieso, um abgebrochenen Verbindungen zu erkennen).
Ansonsten habe ich beim Implementieren festgestellt, dass die UML-Diagramme, so wie sie sind, an sich geeignet sind.
Auch für diejenigen, die es interessiert, im Anhang befinden sich die zwei wichtigsten UML-Diagramme.
Das eine beschreibt das grundlegende System, das andere mögliche Plugins, die das grundlegende System (dessen Komponenten blass eingezeichnet sind) erweitern.

Insgesamt habe ich aber das Gefühl, dass die Kategorie "Gemeinschaftsprojekte" leider zum Friedhof für teilweise doch sehr interessante Projekte geworden ist.
Aber vielleicht hat Luckie Recht, über ein Forum kann ein solches Projekt nicht so einfach gemanagt werden.

Viele Grüße,
Henning

Einloggen, um Attachments anzusehen!

Zuck · Verfasst: Fr 05.08.11 00:33

Für alle die sich für das Thema interessieren hat sich Microsoft auch schon Gedanken gemacht.

Die Meinung von Henning bezüglich des Projekte-Friedhofs teile ich leider. Von den hier geplanten Projekten ist AFAIK noch keines bis zur Release gekommen. dcCalc hatte eine gute Idee, ebenso dieses Projekt hier. Allerdings verlaufen alle Projekte nach einigen Wochen / Monaten im Sande und werden nicht weitergeführt. Eigentlich schade, wenn man bedenkt, was andere Gemeinschaftsprojekte hervorgebracht haben. Ein gutes Projekt aus diesem Forum würde den Programmierern, dem Forum und auch Delphi helfen.

Zuck

Ehemaliges Mitglied Erhaltene Danke: 1

henni hat folgendes geschrieben :

leider habe ich das Projekt - wie in dieser Sparte bereits viele vor mir schon von sich gegeben haben - (vorerst) aufgeben müssen. [..] weil mein Mitstreiter ganz schnell an den UML-Diagrammen das Interesse verloren hat. Es fehlt mir jetzt auch einfach die Zeit für dieses Projekt.

Wie Prophezeit.

Martok · Verfasst: So 07.08.11 02:30

Moderativer Hinweis: Diskussion über die Schwächen und Fehlschlagsursachen von Gemeinschaftsprojekten abgetrennt in einen separaten Thread.

_________________
"The phoenix's price isn't inevitable. It's not part of some deep balance built into the universe. It's just the parts of the game where you haven't figured out yet how to cheat."

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme