Spacegate.mw

   1 {{Projekt
   2 |verantwortlich={{Benutzer|DooMMasteR}}
   3 |status=aktiv
   4 |interessenten=[[Benutzer:Daniel Bohrer|Daniel Bohrer]], [[Benutzer:Hellfyre|Hellfyre]]
   5 }}
   6 == Idee ==
   7
   8 Das Spacegate sollte nach Möglichkeit von jedem Mitglied und ggf. auch kurzfristig autorisierten Gast geöffnet werden.
   9 Das äußere Spacegate lässt sich bisher einfach per Handy öffnen, ist zwar nicht toll, abe rklappt.
  10
  11 Für das Innere Gate wäre eine raffinierter Lösung erstrebenswert.
  12
  13 Zur Verwirklichung sind 2 Hürden zu überwinden.
  14 #Authetifizierung der Person die Zugang verlangt
  15 #ermöglichen des Zuganges
  16
  17 === Authorisierung ===
  18 Wir sollten zum Autorisieren des Zuganges ein System haben, welches folgende Bedingungen erfüllt:
  19 *Günstig
  20 *Sicher
  21 *Flexibel
  22 *PrivacyProtecting
  23 *Available
  24
  25 Das Problem ist dabei größer als es Zunächst erscheint.
  26
  27 Mechanische Schlüssel scheiden aus, da sie 1. recht teuer sind und 2. bei Verlust zu Problemen in der Autorisierungskette anderer Schlüssel führen.
  28
  29 IP-Basierende Systeme scheiden aus, da sie den Betrieb eines IP-Fähigen Endgerätes voraussetzen und auch recht hohen Implementierungsaufwand auf verschiedenen Plattformen mit sich brächte.
  30
  31 RFID ist im Grunde sehr viel versprechend aber birgt eine gewisse Privacyproblematik in sich, die ID des Tags und damit die Traceability des Users.
  32
  33 Dennoch erscheint RFID als der Beste Ansatz, denn:
  34 *recht günstig
  35 *lässt sich vielfältig einsetzen (man könnte ungenutzte Bereiche von Karten offen für andere Nutzungen lassen)
  36 *flexibel ggf. kann ein Nutzer seine eigene Karte mitbringen und Beschreiben lassen
  37 *weit verbreitet, gerade 13,xxMHz Tags
  38 *ließe sich auch in Smartphones implementieren
  39 *einzelne Karten können bei Verlust de-autorisiert werden
  40
  41 bleibt die privacy Problematik durch die ID, dazu: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1508247 (z.B. aus dem Uninetz lesbar)
  42
  43 Falls der Link oben nicht funktioniert (IEEE Seite hat merkwürdige Cookie-Magie), hier der DOI [http://dx.doi.org/10.1109/DEXA.2005.28 10.1109/DEXA.2005.28]
  44
  45 Lösung bisher: KEINE -.-
  46 Das Problem wäre beim Einsatz eines aktiven Tags nicht vorhanden
  47
  48 === Oeffnung ===
  49
  50 Ich habe einen Tueroeffner, den man vermutlich oben in den Tuerrahmen einbauen kann. Bei Anlegen von 12V gibt das frei. habs allerdings nie ausprobiert. Ich brings mal mit demnaechst --[[Benutzer:Valodim|Valodim]] 20:04, 30. Mär. 2012 (CEST)
  51
  52 == Alte Diskussion ==
  53 ''…wurde vorher auf [[Open/Close-Monitor]] geführt, hier der Vollständigkeit halber hinverschoben --[[Benutzer:Daniel Bohrer|Daniel Bohrer]] 12:17, 31. Mär. 2012 (CEST)''
  54
  55 Falls der Space sich hinreichend entwickelt hat, kann über weitergehende Maßnahmen nachgedacht werden. Im µCCC z.B. wird die Türschließung durch ein [https://wiki.muc.ccc.de/luftschleuse Zugangssystem per SSH] gesteuert.
  56
  57 === Verbesserung der Klingel ===
  58 …wenn wir grad schonmal am Klingelhacken sind. Im Chat kam der Vorschlag nach einer optischen Klingel (Blinken o.ä.). Alternativ, falls alle Spaceinsassen gerade schlafen:
  59
  60  [11:59:51] <rohieb> dann die sofas mit drahtgeflecht versehen und die klingel stromschläge draufgeben lassen?
  61  [12:00:04] <tommie-lie> schon besser
  62  [12:00:04] <neobechstein> :D
  63  [12:00:06] <neobechstein> rohieb: +1
  64
  65 Alternativ wäre zu überlegen, ob man [[ZombiePoet]] beibringt, Klingelevents im IRC zu verkünden. Bzw, wenn an der Tür später eh ein µC/ARM oder ähnliches mit Netzwerk hängt, könnte man dort direkt einen IRC-Bot implementieren ;-) (ZombiePoet läuft ja auf einem externen Server, das würde dann nur noch eine Schicht mehr hinzufügen)
  66
  67 [[Kategorie:Infrastruktur]]