[ English | German ]

Entwicklungspläne

Im Folgenden handelt es sich um technische Beschreibungen von geplanten Aufgaben im Rahmen von Entwicklungsprojekten für AN.ON.

Verbesserungen am JAP-Client

• Spread Java-version via InfoService (complete)
• Popup when new Java version available (complete)
• remove IE-Autoconf (complete)
• integrate simple installation assistant (complete)
• deactivate Tor/MixMinion in release version and make both (de-)activateable (complete)
• write short changelog compared to current release (complete)
• renew HP completely / make it easy-to-use and clear (complete)
• create more scalable graphics (complete)
• rewrite help files (complete)
• make InfoService more robust (complete)

RELEASE (end of October 2006)

• Cascade-Type-Filter (flexible Trust-Model; filter service locations, certificate authorities, cascade length,...)
• fix InfoService errors
• fix reason for connection errors (maybe complete)
• test skins and show on HP
• integrate simple HTTP-Filter (Headers, Cookies)
• enable proxy-support for forwarding clients (+ suggest port 443 for forwarding servers)
• enable complete (if possible) hotkey-key control functions
• make easy-to-use FAQ-list (user-editable Wiki) for Problems at JAP-start and publish on HP

RELEASE (end of November 2006)

• add new anon test on HP
• enhance HTTP-Filter (e.g. try to filter encrypted https traffic)
• transparently integrate forwarding client functionality
• add context menu for windows system tray
• make Tor/MixMinion useable and maintainable (change to plugin?)

RELEASE (end of December 2006)

Datenschutzfreundliches und mehrseitig sicheres Abrechnungssystem

• Preiszertifikate in BI, AI, und JAP einbauen (noch nicht: MixConfig)
• Unterstützung für Preizertifikate in alle Mixe einbauen (melden diese an AI, diese wiederum an den JAP)
• neue Kostenbestätigung in JAP, BI und AI einbauen
• Fehler bei der Übertragung von Daten zur BI beheben (Freitexteingaben werden auf der Seite von JAP in Base64 übertragen; BI dekodiert diese nicht)
• Basisversion der MixConfig-Betreiberoberfläche
• Basisversion der BI-Betreiberschnittstelle (Registrieren von Betreiberzertifikaten d.h. Anlegenen von Betreieberkonten, import von Mixzertifikaten,erstellen, signieren und export von Preiszertifikaten, Grobübersicht über Umsätze auf den Konten der Mixbetreiber (nur gesamtsumme pro Mixbetreiber), Grobübersicht über umsätze von Nutzern (nur gesamtsumme für alle nutzer))

24.September 2006

• Challenge-Response-Überprüfung im Mix aktivieren
• BI sendet signierte Bestätigungen an die AI, dass CC erfolgreich abgerechnet (SHA1-Hashwert über Kontozertifikat des JAP und bestätigter Betrag und aktueller
  Kontostand); noch nicht in DB speichern!
• Vorauszahlung durch den JAP wie bei den mixen auch; AI meldet ab welchem "Bezahlstand" eine neue CC geschickt werden muss und für wieviel MB; wird nichts geschickt und "Guthaben bei AI" abgelaufen Timeout und Anforderung CC an JAP schicken; JAP muss mitzählen, wie viel schon von CC verbraucht
• bei Verbindung mit Kaskade sendet JAP sofort CC und AI löst diese sofort ein (damit kann übermittung des Kontozertifikats eliminiert werden)
• CCs werden von der AI gesammelt und gemeinsam mit CCs anderer Nutzer abgeschickt wenn mindestens ein Nutzer eine bestimtme Zahl an CCs (z.B. 5, CC-Queue-Länge; momentan queue-länge fest in Mix programmiert) geschickt hat (AI reicht jeweils nur die letzte CC ein, da kumuliert)
• AI speichert noch nicht abgesurftes "Guthaben" für eine bereits eingelöste CC und meldet dieses dem JAP beim nächsten Verbinden
• AI ist also immer über Kontostand informiert; BI bestätigt keine CC wenn Sie der AI vorher einen Kontostand geschickt hast, der geringer ist als die CC
• Goodwill-Guthaben bei der BI (z.B. 50 MB), das dem JAP-Nutzer nicht angezeigt wird, aber von der BI auch dann für die AI übernommen wird, wenn das Konto abgesurft ist (Goodwill-Guthaben sollte der CC-Queue-Länge * CC-Volumen entsprechen; beides wird von der BI festgelegt, "bösartige" Änderungen dieser Werte in der AI werden hierbei toleriert)

6. Oktober

• PaySafeCard-Schnittstelle in JAP/BI
• Fehler im Transaktionsdialog beheben (in BI/in JAP?): oft werden nicht alle Transaktionen angezeigt (vor allem wenn älteres Konto)
• wenn Transaktionsnummer ohne Aufladung vorliegt (offene Transaktion, z.B. Überweisung) im AccountSettingPanel anzeigen; erst neue Transaktion zulassen, wenn Transaktion abgeschlossen oder bewusst ignoriert
• bei Klick auf offene Transaktion Daten zur Transaktion anzeigen (z.B. Überweisungsdaten); ebenso im Transaktionsdialog (button neben jeder offenen transaktion, auch doppelklick)
• xml-config für BI
• Unterstützung verschiedener Flatratepreise (10GB, 20GB, ...) in JAP/BI
• (optionaler) Flatrate-Ablauf in Kontozertifikat; im JAP sicherstellen, dass bei noch gültiger Flatrate keine zweite Flatrate gekauft werden kann (Aufladebutton ausgrauen) (Fehlermeldung durch BI wenn Versuch)
• ausbau BI-Schnittstelle: ansicht einzelner Nutzerkonten, eintragung von überweisungsgeldern/per brief geschicktem geld auf Nutzerkonten
  ermöglichen
• ausbau der MixConfig-Oberfläche: Preiszertifikat in MixConfig darstell- und importierbar, Kontenansicht (nur gesamtumsätze) von der BI mit Betreiberzertifikat abrufbar, anforderung neuer Preiszertifikate, download von Preiszertifikaten

20. Oktober

• CC-queue-Länge und Größe von CCs von BI übermitteln lassen (Überprüfung aber nicht möglich...)
• AI speichert signierte Bestätigungen der BI in datenbank
• Mixe zählen traffic + zugehörigen Vorgängermix und speichern diesen in ihrer datenbank einfaches Skript, um datenbankinhalte in MixConfig-Tool zu exportieren
• MixConfig-Tool liest datenbank-exports ein und stellt inhalte übersichtlich dar abgleichfunktion in Config-Tool mit daten, die config-tool von der BI abrufen kann

5. November

• Begrenzung der maximalen Nutzerzahl ermöglichen (mit Vorrecht bereits angemeldeter Nutzer, auch nach kurzzeitiger Trennung, über Zertifikat)
• Mixe stellen jetzt untereinander CCs aus und speichern diese in ihrer datenbank
• Beseitung von Bugs, Sicherstellung der bisherigen Funktionalität
• eigene Tests, ob Bezahlung über PayPal/PaySafeCard funktioniert

1. Dezember

• Start Produktivphase: Angebot zweier schneller (100MBit/s) Pay-Kaskaden mit mindestens je zwei Betreibern (am Besten jeweils Regensburg-SpeedPartner-ULD)
• Kostenloser start mit zeitbegrenzten Flatrates für einen Monat, begrenzte Anzahl (wenige hundert)
• weitere Bugfixes
• Verbesserung BI- und MixConfig-Schnittstelle

1. Januar 2007

• Start der Produktivphase