Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

--- arbeitskreise:technikfolgenabschaetzung:protokoll_muenchen2017 [01.11.2017 17:04] – angelegt fmahdi
+++ arbeitskreise:technikfolgenabschaetzung:protokoll_muenchen2017 [22.02.2018 20:17] (aktuell) – [Zusammenfassung] Robert Niebsch
@@ Zeile 1: / Zeile 1: @@
 ====== Protokoll Technik Folgenabschätzung ======
-Anwesend:
+Anwesend: Robert Helling (Gast, µc³), Christina Gürster (Alumnus, TH Regensburg), Robert Niebsch (Alumnus, TU Dresden), Nils (RWTH Aachen), Paul Geisler (HS Ostfalia), Alexander Greinert (HS Ostfalia), Pascal Lange (HS Ostfalia), Matthias Gleiminger (HTW Berlin), Tobias (Uni Paderborn), Isabel (Uni Paderborn), Henrik (Uni Paderborn), Christian(Uni Paderborn), Moses (TU Wien), Peter Hartebrodt (HTW Dresden), Alexander Deublein (FAU Erlangen-Nürnberg), Julian Neureuther (FAU Erlangen-Nürnberg), Valentin Olpp (FAU Erlangen-Nürnberg), Richard (Universität Freiburg), Marc Kreft (FH-OWL), Josef Gartner (TU Dresden), Franz Schmidt (TU Dresden), Robert Lehmann (TU Dresden), Ludwig Tesar (TU Dresden), Arne Dubenhorst (TU Braunschweig)
-BuFaTa SoSe17 \\
+Es soll um IoT Aspekte gehen. Spezielle technische Fragen, sollen nicht im Vordergrund stehen.
-Anwesend: Name (Uni/FH) \\
+Robert (µc³) gibt einen kurzen Impulsvortrag:
-Leitung des AK: Name des Leiters(Uni/FH) \\
-Protokoll: Name\\
-\\
-===== Einführung =====
+  * IoT wird kommen
-Zu Beginn Diskussion über Vorgehensweise. Was will der AK eigentlich machen? Austausch über Sponsorennutzung. Entwicklung für das anwerben von Sponsoren soll durchgeführt werden.
+  * jeder will alles Steuern und Überwachen können, dahingestellt ob sinnvoll
+  * Hardware extrem günstig, aber auch langlebig?
+  * "alle Geräte mit Elektroanschluss werden eine IP Adresse haben"
+  * IBM Studie: minimale Software Fehler Quote = 1 Fehler pro 10000 Zeilen Code
+  * Einfallstor für Hacker über diese Fehler z.B. Telekom Router, DNS-Server
+  * Update Politik für viel IoT Hardware sehr mangelhaft
+    * was kann man da machen?
+    * Kunde fühlt sich nicht verantwortlich für mangelhafte Produkte und ist in der Regel nicht betroffen von den Angriffen seiner Geräte
+  * Für die Kunden der möglicherweise magelhaften Produkte sind die Fehler in der Software der Produkte nicht entscheident. Die Leittrageden würden eher große Unternehmen sein, oder Organisationen, bei den es sich lohnt Internetangriffe durchzuführen.
+  * Bei der nächsten Lücke werden wohl Politiker aktiv werden und in Aktionismus verfallen
+    * was könnte dort kommen?
+      * Registrierungspflicht, Regulierung, Zertifizierungspflicht
+      * Produkthaftung für Software
+         * Zur Zeit können die Softwarelieferanten / weisen Softwarelieferanten jegliche Schuld in den AGBs  von sich  zurück
+      * Jetzt ist die Zeit noch auf die "Politik" Einfluss zu nehmen.
+      * Eine Möglichkeit wäre die verpflichtende Angabe eines "Verfallsdatum" für elektronische Geräte, z.B. Garantierte Updates bis in 2/5/10/20 Jahren
-==== Uni 1 ====
+Beginn der Diskussion dazu:
+  * Ablaufdatum für viele Käufer vielleicht ignorierbar
+    * Vorschlag: Zwangsabschaltung
+    * Ablaufdatumsverlängerung durch Erkaufen von Support vom Händler oder Hersteller
+  * Garantieverlängerung meist über Versicherung, Regelung über den Markt
+    * Vorschlag: Hersteller gesetzlich zu Updates verpflichten
+  * Regulierung wohl nur über den Verkauf realistisch. Ein Bestehen auf Fehlerfreiheit ist jedoch weltfremd. Updates sollten aber definitv erwartbar und in sinnvoller Weise vorgeschrieben werden, falls Fehler bekannt werden
+  * Vorschlag: Möglicherweise sollten Geräte erst anfangen zu Arbeiten, wenn der Benutzer eine "Grundeinrichtung" (Systempasswort) vorgenommen hat.
+  * Denkbares Problem: "Updates" ohne Fehlerbehebung/Sicherheitspatches -- nur Versionsnummer erhöhen
+  * Was ist bei "Open Source" Projekten?
+    * polemisch: was ist überhaupt "Open Source"? -> Nichts ist nicht-kommerziell
+  * offenes Hardwaredesign als Chance und Gefahr
+    * beliebige Software drauf spielbar
+    * Ausrede für Hersteller, Support einzustellen
+  * Normierung und Zertifizierung von Software:
+    * z.B. um wirklich grobe Fehler zu vermeiden
+    * Wie soll die Zertifizierung aussehen?
+    * Was soll diese Zertifizierung finden?
+    * Aufwand problematisch/unrealistisch, da jedes Update zertifiziert werden müsste
+    * Zertifizierung von Prozessen, nicht Patches
+      * Welche Kriterien?
+      * z.B. ISO 9001
+  * Hürden für User bei Erstinbetriebnahme, z.B. Zwangs-Passwortänderung
+     * oder auch: Koppelung mit Home-Devices
+  * Anleitungen sind zu umfangreich
+    * Problembehebungstechnisch sind teils nicht ausgerichtet genug, zu viele "Standart Sicherheitshinweise
+     --> Kunden haben keine Lust / Zeit diese komplett zu lesen
+    * Anleitung wird erst interessant, wenn es wirklich Probleme gibt
+    * Anleitungen sollten gesammelt im Internet zu finden sein
+      * Es gibt z.T. kommerzielle Firmen, die dies anbieten (Alte Anleitunge einscannen und zur Verfügung stellen gegen Bezahlung)
+  * Allerdings: Von geschätzten 60Mio. Konsumenten in Deutschland kontaktiert in akuten Phasen nur ein sehr kleiner Teil den Support --> Man kann davon ausgehen, dass der Großteil der Geräte läuft und ein Großteil der Kunden Anleitungen liest.
+  * Internationales Problem - Problemlösungen mindestens auf EU-Ebene
+      Fachpolitiker haben bereits das Gespräch aufgenommen.
+  * Standartisierung von Protokollen, an Stelle von Zertifikaten oder Prozessen
+    * ISO für Home Automation
+  * Hardware Security
+    * z.B. elektronische Schlüssel
+    * Hardware irgendwann nicht mehr in der Lage, die Sicherheit gewährleisten zu können
+    -> z.T. kein Problem, da Hardware so billig und somit einfach austauschbar
+  * Über die KFZ Elektronik wurde sich nicht wirklich unterhalten, dabei handelt es sich noch wieder um ein ganz anderes Thema.
+    * Softwareentwicklung ist bei Sicherheitsrelevanten Softwarekomponenten stärker getestet, dokumentiert.
+       * Zertifizierungsprozesse sind möglicherweise zu lang?
+    * Bei immer mehr Unterhaltungselektronik im KFZ wird die Sicherheit immer schwieriger zu kontrolieren sein.
+  * Trade-Off auch hier natürlich zwischen Sicherheit, Schnelligkeit, Featuremenge
-  * Bericht zum Thema, oder eine kleine Tabelle \\
-^ Thema                           ^ Lösung 1                          ^ Lösung 2              ^
+    * Wie kann ich diese Anforderungen von 08/15-Geräten erwarten, wenn nichtmal High-End Geräte das schaffen? -- Schlichtweg notwendig!
-| Warum schreiben wir Protokolle? | Um unsere Arbeit zu Dokumentieren | Um den Protokollanten zu ärgern |
+    * Bsp. Krankenhaus oder auch Mestechnik-Geräte, für 50 000 € und mehr, deren Software irgendwann verfällt [da Basis z. B. ein veraltetes Windows-System])
-| Wieso Tabellen                  | Weil cool und übersichtlich       | Weil in jeder Wikisprache irgendwie komisch |
+    * Was bedeutet das für den Massenmarkt? Sind die Endkunden bereit, plötzlich die damit verbundenen Kosten auch zu tragen?
-| Eine ganze Zeile für einen Satz, mit wenig Nährwert |  |  |
+    * Ansätze:
+       * Firmen in Zukunft verpflichten, dort besser zu werden
+       * alte Geräte in z.B. "isolierte" Netze verpacken
-==== Uni 2 ====
-Hat einen [[http://www.google.de|Link]] mit der Empfehlung mal dort zu schauen, oder doch im [[arbeitskreise:start| BuFaTa Wiki]] und macht noch eine Aufzählung
-  - Zwei Leerzeichen zu beginn der Zeile
-  - Bindestriche geben eine Aufzählung
-  * Sternchen einen tollen Kasten
-  - Aufzählung mit einrücken,
-    - nochmal zwei Leerzeichen
-  * Beim Sternchen,
-    * passiert nicht so viel :-(
-===== Problemlösungen =====
+===== Besuch der CCC-Räumlichkeiten in München =====
-Alkohol ist keine Lösung sondern ein Destillat, Fließtexte sind auch immer gut ...
-==== Vorschlag 1 ====
-Vorschläge nicht aufzählen sonder mit Einzelüberschriften versehen damit Sie im Inhaltsverzeichnis auftauchen, wir arbeiten konstruktiv an unserer Gesellschaft mit LOL
-==== Vorschlag 2 ====
+===== Zusammenfassung =====
+  * Es gab sehr viel Brainstorming. Eine gezieltere Befassung mit einzelnen Themen könnte noch sinnvoll sein.
+    * Mehr strukturiert,
+    * Zielsetzung?:
+    * Strategien ausarbeiten?
+  * Letztendlich ist unser Spielraum technische Belange betreffend allerdings begrenzt. (Werden keine Normen schaffen können etc.)
+  * Wir könnten uns allerdings politisch äußern, um die Diskussion in eine für uns interessante und relevante Richtung zu lenken.
+    *(Stellungnahme?)
+  * Nicht behandelt: Besprechen, wie Hochschulen damit umgehen, solche Problematiken auch zu Lehren oder forschend zu behandeln.
+    * ->Welche Fächer oder Vorlesungen bieten die unterschiedlichen Hochschulen oder Universitäten für diese Themen an?
-=== Noch besser eingegrenzter Vorschlag ===
-== Der perfekte Vorschlag  ==
-Die Lösung in der Box oder Erde ...
-  Fest gemauert in der Erden
-  Steht die Form aus Lehm gebrannt.
-  Heute muß die Glocke werden!
-  Frisch, Gesellen, seyd zur Hand!
-  Von der Stirne heiß
-  Rinnen muß der Schweiß,
-  Soll das Werk den Meister loben;
-  Doch der Segen kommt von oben.
 ===== Ende =====
-Beginn: 14:30 Uhr\\
+Beginn: 09:15 Uhr\\
-Ende: 17:30 Uhr \\
+Ende: 12:00 Uhr \\
-Der AK ist fertig / nicht fertig / sollte auf weiteren Tagungen besprochen werden
+Der AK ist nicht fertig und sollte auf weiteren Tagungen besprochen werden.
+Zwischenplenum: Können sich Hochschulen oder Universitäten dazu äußern, ob sie sich an ihren Standorten zu diesen Themen in Vorlesungen oder Praktika mit diesem Thema beschäftigt wird?

Die hier im BuFaTa ET Wiki dargestellten Arbeitsdokumente sind Einzelbeiträge der jeweiligen Autoren und i.d.R. nicht repräsentativ für die BuFaTa ET als Organisation. Veröffentlichte Beschlüsse und Stellungnahmen der BuFaTa ET befinden sich ausschließlich auf der offiziellen Homepage.