h1. Protokoll der Sitzung der PG Basisentscheid "Thema BEO CH" * Ort: Mumble PPS * Datum: 02.04.2017 * Zeit: 20:00 CET * Ende: hh:mm CET * Leitung: Moira Brülisauer * Protokoll: Gemeinsam, Verantwortlich MBR h3. Anwesende * Moira Brülisauer (PPV PPS) * Tobias Stenzel (Entwickler Portal, Anpassung Discourse) * Entropy (Entwickler ID Server) h3. Abwesende * Stefan Thöni (Technik PPS, Juristisches PPS) (entschuldigt) * Robert Arnold (Entwickler VVVote) (entschuldigt) * Foo (Entwickler pseudonymes Voting) (unentschuldigt) * (entschuldigt/unentschuldigt) h1. Informationen und Übersicht des Stands der Teilsysteme h2. Stand der einzelnen Systeme? h3. Discourse (CH) * läuft h3. Portal (CH) * nichts neues h3. ID Server (CH) * nichts neues h3. VVVote (CH) * nichts neues h3. BEO-Pseudonymes-Voting (DE) h1. Traktanden h2. Nächste Schritte h3. Discourse (CH) * Dinge die weiter unten stehen. * Gastzugang h3. Portal (CH) * votezilla anschauen, evtl. Lösungen von dort übernehmen h3. ID Server (CH) * Tasks vom letzten mal. h3. VVVote (CH) * - h3. BEO-Pseudonymes-Voting (DE) * - h2. BPT Nachlese eingereicht von _Escap_ * Gespräch mit Pakki und Friedrich, (Mit-)entwickler von votezilla ** votezilla basiert auf dem Portal von Magnus, wurde von Friedrich und einem Externen angepasst (u.a bootstrap-Design) ** evtl. läuft votezilla mit dieser technischen Basis als BEO für NRW an ** wir streben aber eine gemeinsame Lösung auf Python-Basis an (mit ID-Server) h2. (Ungelöste) Supportfälle eingereicht von: _MBR_ *STH:* * 2x Mitglied aus Backend (member und invitations) und ID Server (account und invitations) gelöscht und dann neue Mails gesendet. _solange wir kein gegenteiliges Feedback bekommen, nehmen wir hier vorerst mal an dass diese beiden Fälle behoben werden konnten_ h2. ID Server verlangt nach Referrer eingereicht von: _JoWi_ "Discourse Diskussion":https://discourse.piratenpartei.ch/t/id-server-verlangt-nach-referrer/152 Der ID Server wirft bei einem fehlenden HTTP Referer Header einen Fehler. Die Verwendung dieses Headers als Massnahme gegen CSRF ist aber unsicher, da der Header beliebig gesetzt werden kann. Stattdessen sollte ein CSRF Token generiert werden. Das würde dann auch die Anmeldung ohne Referrer ermöglichen. Fehlermeldung Forbidden (403) CSRF verification failed. Request aborted. You are seeing this message because this HTTPS site requires a 'Referer header' to be sent by your Web browser, but none was sent. This header is required for security reasons, to ensure that your browser is not being hijacked by third parties. If you have configured your browser to disable 'Referer' headers, please re-enable them, at least for this site, or for HTTPS connections, or for 'same-origin' requests. More information is available with DEBUG=True. *Diskussion* * *Entropy* Wir verwenden ein CSRF Token. https://code.djangoproject.com/ticket/16870 Was da von dem User gemacht wird (Referer von gleichem Origin entfernen) ist sehr unüblich und bringt dem User keine grossen Privacy Vorteile und ich sehe keine Vorteile darin in unserer Standardkonfiguration von dem ist Stand abzuweichen. * *jowi:* Jedenfalls: Ticket Referer: Da ein CSRF Token verwendet wird der Referer ja gar nicht gebrauch, also kann man ihn doch ganz weglassen? Was ich mache finde ich selber nicht unüblich und würde ich mit dem näcten Ticket (CSP) sogar gerne erzwingen (https://www.w3.org/TR/referrer-policy/). * *Entropy* Ich gehe ganz stark davon aus die bei Django sich da sehr gut Gedanken darüber gemacht haben warum sie das so machen. siehe https://groups.google.com/forum/#!msg/django-developers/4ZDBMulE-W0/_iKRIGctxccJ es wir über diese Frage sehr heftig diskutiert. * *jowi* Referer kann beliebig gesetzt werden. Es ist *kein* Schutz. es gibt eine Referer policy für CSP *entropy: hier ist eine Attacke beschreiben, die es verhindern soll https://groups.google.com/d/msg/django-developers/4ZDBMulE-W0/VpKVBom7aAgJ h2. Content Security Policy implementieren eingereicht von: _JoWi_ "Discourse Diskussion":https://discourse.piratenpartei.ch/t/content-security-policy-implementieren/151/1 Das Einbinden externer Inhalte in Discourse führt, wie bereits beim alten Forum, zu Mixed Content Fehlern. Darum schlage ich vor, eine restriktive CSP auszuarbeiten und zu implementieren. Dies dürfte hier wesentlich einfacher umzusetzen sein, als die Seiten, die noch von unseren alten Proxy abhängig sind. *Diskussion* * *Escap* Das Problem ist vor allem die Einbindung von Bildern von externen Quellen über HTTP, versuche, mich zu informieren. * ** h2. Featurewunsch Discourse: Keine Einbindung fremder Inhalte eingereicht von: _STH_ "onebox" bindet die Bilder von Fremdservern ein. Ich möchte aus Datenschutzgründen möglichst keine Fremdinhalte einbinden. Kann eingestellt werden, dass die Bilder kopiert werden? Oder eventuell "onebox" deaktivieren? *Diskussion* * *STH* Ich möchte nicht dass externe Server mitbekommen welche User sich was auf unserem Server anschauen. * *jowi* Auch mit CSP möglich (sowohl externe Inhalte verbieten, als auch Referer unterbinden) * *Escap* ich werde mir das anschauen und es wahrscheinlich ganz deaktivieren. Gibt in diesem Bereich nur wenige Einstellmöglichkeiten. Evtl. gibt es dazu schon passende Feature-Requests an Discourse. Wenn nicht, könnte man einen stellen. h2. Featurewunsch ID-Server: Suchen nach uuid eingereicht von: _STH_ Wäre nützlich für Supportfälle. *Diskussion* * *Entropy:* sollte eigentlich schon funktionieren. Habt ihrs schon mal probiert. * *STH:* ja habe es getestet und ging nicht, versuche nochmals. Jetzt geht es, mindestens bei den Benutzern. h2. Featurewunsch Discourse: Längere Login-Zeit eingereicht von: _STH_ Es nervt sich jeden Tag neu anmelden zu müssen und ist nicht notwendig. *Diskussion* * *MBR* ICh möchte das auch gerne haben * *Escap* ist bereits passiert, habe ich auf das Maximum gesetzt, was in etwa zwei Monate sind. h2. Unicode Emojis eingereicht von: _JoWi_ "Discourse Diskussion": https://discourse.piratenpartei.ch/t/unicode-emojis/174 Discourse verwendet anstelle von Unicode Bilder für Emojis. Das ist für Maschinen (Screenreader, Suchfunktion etc.) nicht wirklich lesbar. Da jedes Bild einzeln vom Server geholt werden muss, ist dieser Weg auch nicht sonderlich effizient. Können wir stattdessen richtige Emojis nutzen? Das Aussehen ist über Schriftarten beliebig anpassbar. Mozilla nutzt im Firefox bspw. "EmojiOne": https://github.com/mozilla/emojione-colr/releases. Vgl. Bilder vs. Schrift: * https://twitter.github.io/twemoji/2/test/preview.html * https://mozilla.github.io/fxemoji/dist/FirefoxEmoji/index.html *Diskussion* * *Escap* ich weiss nicht warum das Discourse das so gemacht haben. Ich wüsste nicht wie man das ändern könnte. * *Entropy* https://blog.discourse.org/2015/12/emoji-and-discourse/ * *Escap* Das ist von Ende 2015, ich weiss nicht was sie seither diesbezüglich gemacht haben. * *Jowi* Als Alternative kann man das Emoji als Alt Text im Bild verwenden. Das macht bspw. Twitter so. Das behebt aber das Performance Problem nicht. h1. Fragen der Mitglieder h2. Frage des Mitglied Fragender ist: _jowi_ Lässt sich der Counter hinter Links in Discourse Beiträgen deaktivieren? *Diskussion* * *MBR* Finde ich eine gute Frage. * *Escap*: Ich habe auf die Schnelle nichts gefunden. Schaue nach, was da genau passiert h1. Schluss und nächste Sitzung Sitzung wird durch den Sitzungsleiter geschlossen um 20:42. Die nächste Sitzung wird im Slack festgelegt. h1. Footer h2. Was soll das ganze? Bitte im Redmine der PPS nachlesen, was die "PPS hier umsetzt":https://projects.piratenpartei.ch/projects/beo?jump=welcome Und wer macht das? "Projektgruppe":http://wiki.piratenpartei.de/Basisentscheid/Projektgruppe h3. Vorherige Protokolle Die Protokolle der Entwicklungsarbeit am Urabstimmungssystem für die Piratenpartei Schweiz finden "sich im Wiki":https://projects.piratenpartei.ch/projects/beo/wiki/Protokolle_PGBasisentscheid h3. Vorherige Protokolle Die Protokolle der Entwicklungsarbeit am Urabstimmungssystem für die Piratenpartei Schweiz finden "sich im Wiki":https://projects.piratenpartei.ch/projects/beo/wiki/Protokolle_PGBasisentscheid