Doorduino opt-in: Difference between revisions

From RevSpace
Jump to navigation Jump to search
No edit summary
No edit summary
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{Project
{{Project
   |Name=Opt-in voor nickname bij online doorduino-meldingen
   |Name=Opt-in voor nickname bij online doorduino-meldingen
   |Picture=
   |Picture=P1000798.JPG
   |Omschrijving=
   |Omschrijving=
   |Status=Completed
   |Status=Completed
Line 16: Line 16:


Het zou makkelijker zijn geweest om helemaal te stoppen met nicknames bij de online meldingen zetten, maar we zouden dan belangrijke sociale samenhang verliezen. Daarom kun je nu specifieke toestemming geven. De technische implementatie is helaas veel werk geweest, maar stelt deelnemers in staat om zelf hun toestemming te verlenen of in te trekken, zonder dat ze daarvoor bij een bestuurder moeten zijn. De wijzigingen worden meteen gelogd, zodat er ook een zorgvuldige registratie is van de toestemming.
Het zou makkelijker zijn geweest om helemaal te stoppen met nicknames bij de online meldingen zetten, maar we zouden dan belangrijke sociale samenhang verliezen. Daarom kun je nu specifieke toestemming geven. De technische implementatie is helaas veel werk geweest, maar stelt deelnemers in staat om zelf hun toestemming te verlenen of in te trekken, zonder dat ze daarvoor bij een bestuurder moeten zijn. De wijzigingen worden meteen gelogd, zodat er ook een zorgvuldige registratie is van de toestemming.
== Gebruik ==
=== Toestemming geven ===
Scan je iButton bij de krul (zie foto). Je toestemming blijft actief tot je die weer intrekt.
=== Toestemming intrekken ===
Scan je iButton bij het kruis (zie foto). Je eerder gegeven toestemming wordt weer uit de lijst gehaald.


== Implementatie ==
== Implementatie ==
Line 21: Line 31:
Aangezien alles om iButtons draait, kunnen we die gebruiken voor betrouwbare authenticatie. We hebben daarvoor al bestaande systemen, namelijk doorduino's. Door deze te hergebruiken blijft het systeem consistent, en dus hebben we hiervoor twee nepdeuren in het leven geroepen: "opt-in" en "opt-out". Qua hardware zijn deze erg vergelijkbaar met de andere deuren, behalve dat er geen daadwerkelijk deurslot is.
Aangezien alles om iButtons draait, kunnen we die gebruiken voor betrouwbare authenticatie. We hebben daarvoor al bestaande systemen, namelijk doorduino's. Door deze te hergebruiken blijft het systeem consistent, en dus hebben we hiervoor twee nepdeuren in het leven geroepen: "opt-in" en "opt-out". Qua hardware zijn deze erg vergelijkbaar met de andere deuren, behalve dat er geen daadwerkelijk deurslot is.


Je vindt deze scanners bij de eerste deur na binnenkomst.
[[File:P1000797.JPG|300px|thumb|Je vindt deze scanners bij de eerste deur na binnenkomst.]]


=== Hardware ===
=== Hardware ===
Line 33: Line 43:
Het script op de Pi is uitgebreid met een configuratie-optie "skip_access", zodat het commando om de deur te openen niet wordt gegeven aan de doorduino. Dit access-commando zou namelijk de groene LED laten oplichten, wat pas moet gebeuren nadat de toestemming is verwerkt!
Het script op de Pi is uitgebreid met een configuratie-optie "skip_access", zodat het commando om de deur te openen niet wordt gegeven aan de doorduino. Dit access-commando zou namelijk de groene LED laten oplichten, wat pas moet gebeuren nadat de toestemming is verwerkt!


Het script op gateway dat de doorduino-meldingen verzorgt, houdt nu in een lijstje bij wie er toestemming heeft gegeven, en in een logbestand wie er toestemming heeft gegeven of ingetrokken. Na een mutatie geeft het een unlock-commando via MQTT terug voor de Pi.
Het [https://github.com/revspace/houtje-touwtje/blob/master/doorduino-mqtt.pl script op gateway dat de doorduino-meldingen verzorgt], houdt nu in een lijstje bij wie er toestemming heeft gegeven, en in een logbestand wie er toestemming heeft gegeven of ingetrokken. Na een mutatie geeft het een unlock-commando via MQTT terug voor de Pi.


Op de Pi draait een nieuw script, "unlock-via-mqtt", dat luistert op MQTT en op verzoek de doorduino het access-commando geeft zodat de groene LED alsnog gaat branden en de gebruiker weet dat de wijziging is doorgevoerd. Dit script is niet in staat om echte deuren te openen.
Op de Pi draait een nieuw script, "[https://github.com/revspace/houtje-touwtje/blob/master/unlock-via-mqtt.pl unlock-via-mqtt]", dat luistert op MQTT en op verzoek de doorduino het access-commando geeft zodat de groene LED alsnog gaat branden en de gebruiker weet dat de wijziging is doorgevoerd. Dit script is niet in staat om echte deuren te openen.

Latest revision as of 22:55, 25 January 2022

Project Opt-in voor nickname bij online doorduino-meldingen
P1000798.JPG
Status Completed
Contact bestuur
Last Update 2022-01-25

Aanleiding

De space is een sociaal gebeuren waarbij het belangrijk is dat mensen van elkaar weten wie ze zijn en onder welke nickname de ander werkt. Het is belangrijk om te kunnen weten wie elders in de space deuren opent. We laten daarom de meldingen van het deursysteem in de space zien met vermelding van iemands nickname. Het bericht gaat via MQTT en diverse systemen in de space (bijv. ledbanner of geluidssysteem) kunnen hier gebruik van maken. Dit blijft zo.

Omdat veel RevSpace-deelnemers op IRC zitten, laten we daar ook de unlocks zien. Oorspronkelijk stond daar altijd, zonder specifieke toestemming, de nickname van de sleutelhouder bij. We weten inmiddels dat nicknames ook persoonsgegevens zijn. Het is moeilijk om het vermelden van persoonsgegevens buiten de space zelf, waarbij mensen die niet op de space zijn ook kunnen meekijken, te verantwoorden als gerechtvaardigd belang.

We wilden de functionaliteit echter wel houden. Er wordt veel gebruik van gemaakt: veel mensen willen graag naar de space als er bepaalde andere leuke mensen zijn. En aangezien we van onze deelnemers vrijwel nooit iets negatiefs hebben gehoord over deze privacyschending, vermoedden we dat veel deelnemers wel hun specifieke toestemming zullen willen geven.

Het zou makkelijker zijn geweest om helemaal te stoppen met nicknames bij de online meldingen zetten, maar we zouden dan belangrijke sociale samenhang verliezen. Daarom kun je nu specifieke toestemming geven. De technische implementatie is helaas veel werk geweest, maar stelt deelnemers in staat om zelf hun toestemming te verlenen of in te trekken, zonder dat ze daarvoor bij een bestuurder moeten zijn. De wijzigingen worden meteen gelogd, zodat er ook een zorgvuldige registratie is van de toestemming.

Gebruik

Toestemming geven

Scan je iButton bij de krul (zie foto). Je toestemming blijft actief tot je die weer intrekt.

Toestemming intrekken

Scan je iButton bij het kruis (zie foto). Je eerder gegeven toestemming wordt weer uit de lijst gehaald.

Implementatie

Aangezien alles om iButtons draait, kunnen we die gebruiken voor betrouwbare authenticatie. We hebben daarvoor al bestaande systemen, namelijk doorduino's. Door deze te hergebruiken blijft het systeem consistent, en dus hebben we hiervoor twee nepdeuren in het leven geroepen: "opt-in" en "opt-out". Qua hardware zijn deze erg vergelijkbaar met de andere deuren, behalve dat er geen daadwerkelijk deurslot is.

Je vindt deze scanners bij de eerste deur na binnenkomst.

Hardware

Een bestaande doorduinokast is uitgebreid met 2 extra doorduino's (arduino's met wat weerstandjes en een USB-serial met serienummer). De kast was vol, evenals de Raspberry Pi's USB-poorten, dus de nieuwe doorduino'tjes zitten in een klein kastje ernaast, en het aantal USB-poorten is uitgebreid met een USB-hub. Er zijn plannen voor een nieuwe versie van de doorduinokast, dus voor nu leek er geen reden om het al te netjes te maken.

Aan de wand hangt een plaat met de specifieke toestemmingstekst, een reader waarmee je je toestemming kunt geven, en een reader waarmee je die toestemming kunt intrekken. Omdat het te veel werk is om dit allemaal weer- en waterdicht te maken, hangt ie binnen. Wie anoniem op de space wil zijn terwijl die eerder toestemming heeft gegeven, zal dus moeten aanbellen zoals bezoekers zonder iButton.

Software

Het script op de Pi is uitgebreid met een configuratie-optie "skip_access", zodat het commando om de deur te openen niet wordt gegeven aan de doorduino. Dit access-commando zou namelijk de groene LED laten oplichten, wat pas moet gebeuren nadat de toestemming is verwerkt!

Het script op gateway dat de doorduino-meldingen verzorgt, houdt nu in een lijstje bij wie er toestemming heeft gegeven, en in een logbestand wie er toestemming heeft gegeven of ingetrokken. Na een mutatie geeft het een unlock-commando via MQTT terug voor de Pi.

Op de Pi draait een nieuw script, "unlock-via-mqtt", dat luistert op MQTT en op verzoek de doorduino het access-commando geeft zodat de groene LED alsnog gaat branden en de gebruiker weet dat de wijziging is doorgevoerd. Dit script is niet in staat om echte deuren te openen.