Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.sci.electronics > #258218 > unrolled thread
| Started by | Olaf Schultz <o.schultz@enhydralutris.de> |
|---|---|
| First post | 2019-06-08 23:43 +0200 |
| Last post | 2019-06-11 19:46 +0200 |
| Articles | 20 on this page of 284 — 35 participants |
Back to article view | Back to de.sci.electronics
Hamburg, Co.. Olaf Schultz <o.schultz@enhydralutris.de> - 2019-06-08 23:43 +0200
Re: Hamburg, Co.. Heinz Schmitz <kma@kma.org> - 2019-06-09 08:56 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-10 17:36 +0200
Re: Hamburg, Co.. Heinz Schmitz <kma@kma.org> - 2019-06-11 12:44 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-11 15:06 +0200
Re: Hamburg, Co.. Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-06-18 21:46 +0200
Re: Hamburg, Co.. R.Kiefer.SPAEM@gmx.de (Ralf Kiefer) - 2019-06-11 14:50 +0200
Re: Hamburg, Co.. Andreas Neumann <an5275@sedo.com> - 2019-06-11 18:22 +0300
Re: Hamburg, Co.. Martin Klaiber <usenet.martinkl@gmx.de> - 2019-06-09 13:54 +0200
Re: Hamburg, Co.. "Horst-D. Winzler" <horst.d.winzler@web.de> - 2019-06-09 15:44 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-13 13:54 -0700
Re: Hamburg, Co.. Gerhard Hoffmann <dk4xp@arcor.de> - 2019-06-14 00:59 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-14 02:22 +0200
Re: Hamburg, Co.. Gerhard Hoffmann <dk4xp@arcor.de> - 2019-06-14 04:18 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-14 07:55 -0700
Re: Hamburg, Co.. Klaus Butzmann <kb.usenet@butzomail.de> - 2019-06-14 21:19 +0200
Re: Hamburg, Co.. Holger <me@privacy.org> - 2019-06-14 23:45 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-14 14:53 -0700
Re: Hamburg, Co.. Holger <me@privacy.org> - 2019-06-14 23:58 +0200
Re: Hamburg, Co.. "Horst-D. Winzler" <horst.d.winzler@web.de> - 2019-06-15 05:29 +0200
Re: Hamburg, Co.. Holger <me@privacy.org> - 2019-06-15 10:27 +0200
Re: Hamburg, Co.. "horst-d.winzler" <horst.d.winzler@web.de> - 2019-06-15 11:31 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-15 16:03 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-15 07:45 -0700
Re: Hamburg, Co.. "Horst-D. Winzler" <horst.d.winzler@web.de> - 2019-06-15 17:07 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-15 08:27 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-15 19:02 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-15 11:11 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-16 12:00 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-16 07:44 -0700
Re: Hamburg, Co.. Gerhard Hoffmann <dk4xp@arcor.de> - 2019-06-16 17:42 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-16 09:58 -0700
Re: Hamburg, Co.. Peter Thoms <dl6lat@darc.de> - 2019-06-16 19:10 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-16 23:48 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-17 14:04 -0700
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-17 23:40 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-17 14:59 -0700
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-18 08:41 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-18 07:27 -0700
Re: Hamburg, Co.. Holger <me@privacy.org> - 2019-06-18 16:48 +0200
Re: Hamburg, Co.. Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-18 20:08 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-18 20:34 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-18 11:34 -0700
Re: Hamburg, Co.. Hartmut Kraus <hartmut.melina@web.de> - 2019-06-19 22:54 +0200
Re: Hamburg, Co.. Hartmut Kraus <hartmut.melina@web.de> - 2019-06-19 22:57 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-18 17:57 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-18 11:30 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-18 23:48 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-19 10:35 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-19 07:13 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-19 17:19 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-19 18:04 +0200
Re: Hamburg, Co.. Hartmut Kraus <hartmut.melina@web.de> - 2019-06-19 23:40 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-18 20:44 +0200
Re: Hamburg, Co.. Holger <me@privacy.org> - 2019-06-16 19:12 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-17 14:09 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-18 18:05 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-18 11:42 -0700
Re: Hamburg, Co.. Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-06-18 22:18 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-19 00:13 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-18 16:49 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-19 13:51 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-19 07:27 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-19 18:30 +0200
Re: Hamburg, Co.. Holger <me@privacy.org> - 2019-06-21 03:18 +0200
Re: Hamburg, Co.. Uhu <Euleuhu@nest.de> - 2019-06-15 19:51 +0200
Re: Hamburg, Co.. Reinhardt Behm <rbehm@hushmail.com> - 2019-06-16 11:20 +0800
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-16 07:47 -0700
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-16 23:03 +0200
Re: Hamburg, Co.. Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-06-18 22:21 +0200
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-16 12:30 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-16 13:55 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-16 14:04 +0200
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-16 23:12 +0200
Re: Hamburg, Co.. Gerhard Hoffmann <dk4xp@arcor.de> - 2019-06-16 23:22 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-17 14:27 -0700
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-16 07:58 -0700
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-16 19:51 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-17 14:12 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-18 18:13 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-18 11:52 -0700
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-18 21:05 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-18 13:29 -0700
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-19 09:22 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 12:34 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-19 07:30 -0700
Re: Hamburg, Co.. Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-19 16:34 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-19 09:16 -0700
Re: Hamburg, Co.. Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-19 22:02 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-19 13:13 -0700
Re: Hamburg, Co.. Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-19 22:51 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-19 15:08 -0700
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 07:21 +0200
Re: Hamburg, Co.. Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-20 08:50 +0200
Re: Hamburg, Co.. Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-06-20 19:55 +0200
Re: Hamburg, Co.. Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-20 21:39 +0200
Re: Hamburg, Co.. Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2019-06-21 23:36 +0200
Re: Hamburg, Co.. Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2019-06-19 20:59 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 16:05 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-19 07:49 -0700
Re: Hamburg, Co.. [OT] Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 16:57 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-19 09:29 -0700
Re: Hamburg, Co.. Martin Gerdes <martin.gerdes@gmx.de> - 2019-06-19 23:39 +0200
Re: Hamburg, Co.. Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-06-18 22:26 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-19 00:51 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-18 16:36 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-19 14:24 +0200
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-19 09:19 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-19 07:53 -0700
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-19 09:39 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-19 08:08 -0700
Re: Hamburg, Co.. [OT] Falk Dµebbert <falk@duebbert.com> - 2019-06-19 20:02 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-19 11:31 -0700
Re: Hamburg, Co.. [OT] Falk Dµebbert <falk@duebbert.com> - 2019-06-20 00:22 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-19 15:49 -0700
Re: Hamburg, Co.. [OT] Falk Dµebbert <falk@duebbert.com> - 2019-06-20 01:15 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-19 16:22 -0700
Re: Hamburg, Co.. [OT] Falk Dµebbert <falk@duebbert.com> - 2019-06-20 10:15 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 07:00 -0700
Re: Hamburg, Co.. [OT] Hanno Foest <hurga-news2@tigress.com> - 2019-06-20 16:19 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 07:35 -0700
Re: Hamburg, Co.. [OT] Hanno Foest <hurga-news2@tigress.com> - 2019-06-20 16:45 +0200
Re: Hamburg, Co.. [OT] Hanno Foest <hurga-news2@tigress.com> - 2019-06-20 16:46 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 08:04 -0700
Re: Hamburg, Co.. [OT] Hanno Foest <hurga-news2@tigress.com> - 2019-06-20 18:19 +0200
Re: Hamburg, Co.. [OT] Falk Dµebbert <falk@duebbert.com> - 2019-06-20 23:32 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 15:14 -0700
Re: Hamburg, Co.. [OT] Helmut Schellong <rip@schellong.biz> - 2019-06-20 19:04 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 10:13 -0700
Re: Hamburg, Co.. [OT] Helmut Schellong <rip@schellong.biz> - 2019-06-20 14:10 +0200
Re: Hamburg, Co.. [OT] Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-20 08:57 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 07:19 -0700
Re: Hamburg, Co.. [OT] Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 16:29 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 08:02 -0700
Re: Hamburg, Co.. [OT] Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 17:16 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 08:57 -0700
Re: Hamburg, Co.. [OT] Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-20 18:17 +0200
Re: Hamburg, Co.. [OT] Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-20 18:13 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 09:47 -0700
Re: Hamburg, Co.. [OT] Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-20 18:52 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 10:08 -0700
Re: Hamburg, Co.. [OT] Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-20 18:57 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 10:05 -0700
Re: Hamburg, Co.. [OT] Klaus Butzmann <kb.usenet@butzomail.de> - 2019-06-20 23:33 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-20 15:32 -0700
Re: Hamburg, Co.. [OT] Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-21 08:36 +0200
Re: Hamburg, Co.. [OT] Roland Franzius <roland.franzius@uos.de> - 2019-06-21 08:57 +0200
Re: Hamburg, Co.. [OT] Klaus Butzmann <kb.usenet@butzomail.de> - 2019-06-21 13:07 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-21 07:28 -0700
Re: Hamburg, Co.. [OT] Klaus Butzmann <kb.usenet@butzomail.de> - 2019-06-21 16:53 +0200
Re: Hamburg, Co.. [OT] Joerg <news@analogconsultants.com> - 2019-06-21 08:03 -0700
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-18 23:48 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-19 10:40 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 12:44 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-19 13:51 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 16:11 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 18:09 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 18:37 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 19:40 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 20:19 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 21:17 +0200
Re: Hamburg, Co.. Olaf Schultz <o.schultz@enhydralutris.de> - 2019-06-19 22:02 +0200
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-20 00:27 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-20 01:10 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-20 07:15 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 07:29 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-20 14:34 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 14:45 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-20 14:56 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 15:42 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-20 17:15 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 17:18 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-20 15:43 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-20 17:18 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-20 09:01 -0700
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-20 18:13 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-20 19:30 +0200
Re: Hamburg, Co.. Klaus Butzmann <kb.usenet@butzomail.de> - 2019-06-20 23:42 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-20 15:50 -0700
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-22 16:34 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-22 07:54 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-21 12:41 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-21 01:03 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-20 07:28 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-20 18:40 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-20 18:59 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-20 10:01 -0700
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-20 20:37 +0200
Re: Hamburg, Co.. Rupert Haselbeck <mein-rest-muell@gmx.de> - 2019-06-22 16:38 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-22 21:18 +0200
Re: Hamburg, Co.. Stefan Engler <stefan@epiket.de> - 2019-06-23 11:44 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-23 12:03 +0200
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-23 12:48 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-23 12:55 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-23 16:11 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-23 16:17 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-23 19:12 +0200
Re: Hamburg, Co.. Guido Grohmann <guido.grohmann@gmx.de> - 2019-06-23 19:35 +0200
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-24 01:11 +0200
Re: Hamburg, Co.. "Horst-D. Winzler" <horst.d.winzler@web.de> - 2019-06-24 10:09 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-24 07:22 -0700
Re: Hamburg, Co.. Volker Bartheld <news2018@bartheld.net> - 2019-06-24 16:42 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-25 07:13 -0700
Re: Hamburg, Co.. Marte Schwarz <marte.schwarz@gmx.de> - 2019-06-25 11:03 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-25 13:44 +0200
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-25 23:07 +0200
Re: Hamburg, Co.. Heinz Schmitz <kma@kma.org> - 2019-06-26 08:40 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-23 23:01 +0200
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-22 19:08 +0200
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-20 23:37 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 07:31 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-20 09:51 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-20 15:59 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-20 20:08 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-21 00:01 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-21 09:19 +0200
Re: Hamburg, Co.. Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-21 09:35 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-21 14:14 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-21 01:04 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 07:22 +0200
Re: Hamburg, Co.. Ewald Pfau <anderswo@gmx.net> - 2019-06-19 19:35 +0000
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 21:59 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-19 19:09 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 19:14 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 19:56 +0200
Re: Hamburg, Co.. Ewald Pfau <anderswo@gmx.net> - 2019-06-19 20:34 +0000
Re: Hamburg, Co.. Hartmut Kraus <hartmut.melina@web.de> - 2019-06-20 00:15 +0200
Re: Hamburg, Co.. Ewald Pfau <anderswo@gmx.net> - 2019-06-20 12:11 +0000
Re: Hamburg, Co.. Hartmut Kraus <hartmut.melina@web.de> - 2019-06-20 15:03 +0200
Re: Hamburg, Co.. Thomas Prufer <prufer.public@mnet-online.de.invalid> - 2019-06-24 08:21 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-24 11:29 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-24 17:39 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-24 17:55 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-25 02:16 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-25 13:37 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-25 14:22 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-25 14:47 +0200
Re: Hamburg, Co.. Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2019-06-25 21:02 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 16:06 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 18:16 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 18:40 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 20:02 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 20:32 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 21:43 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 22:13 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-20 00:34 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-20 01:21 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-20 14:29 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 07:27 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-20 10:01 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 10:28 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-20 10:49 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 11:48 +0200
Re: Hamburg, Co.. Ewald Pfau <anderswo@gmx.net> - 2019-06-20 12:11 +0000
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-20 14:48 +0200
Re: Hamburg, Co.. Ewald Pfau <anderswo@gmx.net> - 2019-06-20 16:41 +0000
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-19 21:11 +0200
Re: Hamburg, Co.. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2019-06-19 21:54 +0200
Re: Hamburg, Co.. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2019-06-19 22:16 +0200
Re: Hamburg, Co.. Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-06-18 23:01 +0200
Re: Hamburg, Co.. Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-15 16:50 +0200
Re: Hamburg, Co.. Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-06-18 22:55 +0200
Re: Hamburg, Co.. Axel Berger <Spam@Berger-Odenthal.De> - 2019-06-15 10:35 +0200
Re: Hamburg, Co.. "horst-d.winzler" <horst.d.winzler@web.de> - 2019-06-15 11:33 +0200
Re: Hamburg, Co.. Ole Jansen <remove.this.kaspernasebaer@gmx.de> - 2019-06-17 10:11 +0200
Re: Hamburg, Co.. "Horst-D. Winzler" <horst.d.winzler@web.de> - 2019-06-17 11:01 +0200
Re: Hamburg, Co.. Hartmut Kraus <hartmut.melina@web.de> - 2019-06-17 18:30 +0200
Re: Hamburg, Co.. "Horst-D. Winzler" <horst.d.winzler@web.de> - 2019-06-17 19:11 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-17 14:20 -0700
Re: Hamburg, Co.. Klaus Butzmann <kb.usenet@butzomail.de> - 2019-06-17 23:02 +0200
Re: Hamburg, Co.. "Horst-D. Winzler" <horst.d.winzler@web.de> - 2019-06-18 05:31 +0200
Re: Hamburg, Co.. Rolf Bombach <rolfnospambombach@invalid.invalid> - 2019-06-18 22:50 +0200
Re: Hamburg, Co.. "Horst-D. Winzler" <horst.d.winzler@web.de> - 2019-06-19 10:06 +0200
Re: Hamburg, Co.. Hanno Foest <hurga-news2@tigress.com> - 2019-06-19 10:28 +0200
Re: Hamburg, Co.. Klaus Butzmann <kb.usenet@butzomail.de> - 2019-06-14 20:54 +0200
Re: Hamburg, Co.. "Horst-D. Winzler" <horst.d.winzler@web.de> - 2019-06-14 09:28 +0200
Re: Hamburg, Co.. Joerg <news@analogconsultants.com> - 2019-06-14 08:00 -0700
Re: Hamburg, Co.. Holger <me@privacy.org> - 2019-06-14 23:57 +0200
Hamburg-Altona -- Conrad schließt (was: Hamburg, Co..) Martin Gerdes <martin.gerdes@gmx.de> - 2019-06-09 20:57 +0200
Re: Hamburg, Co.. Klaus Dahlwitz <kdahlwitz@gmx.net> - 2019-06-09 21:43 +0200
Re: Hamburg, Co.. Peter Thoms <dl6lat@darc.de> - 2019-06-10 17:48 +0200
Re: Hamburg, Co.. Falk Dµebbert <falk@duebbert.com> - 2019-06-10 22:54 +0200
Re: Hamburg, Co.. Eric Bruecklmeier <usenet@nerdcraft.de> - 2019-06-11 15:44 +0200
Re: Hamburg, Co.. Helmut Schellong <rip@schellong.biz> - 2019-06-11 19:46 +0200
Page 13 of 15 — ← Prev page 1 … 11 12 [13] 14 15 Next page →
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2019-06-19 18:40 +0200 |
| Message-ID | <qedoh3$lbh$2@news.bawue.net> |
| In reply to | #258681 |
On 6/19/19 6:16 PM, Hans-Peter Diettrich wrote: > Am 19.06.2019 um 16:06 schrieb Gerrit Heitsch: >> On 6/18/19 11:48 PM, Hans-Peter Diettrich wrote: > >>> Es wäre deutlich einfacher, erst einmal die Autobahnen nur noch für >>> selbstfahrende (vernetzte!) Kfz offenzulassen. >> >> Aha... Motorradfahrer also nicht mehr? > > Nur noch auf Zweirad-Wegen :-] > >> Und vernetzte Autos? Hacker's Dream! > > Man sollte Vernetzung nicht gleich mit Cloud und Web und offenem Zugang > assoziieren. Das wäre zwar einfacher, aber dann vor allem für Hacker :-( Es reicht wenn ein Auto dem anderen was mitteilen kann. Damit muss das Auto von aussen erreichbar sein. Wie ist egal, ob nun WLAN, was eigenes oder Bluetooth. Sobald das geht reicht 1 Bug an der falschen Stelle und das Auto gehorcht dem Angreifer. Schlecht für den der drin sitzt. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-06-19 20:02 +0200 |
| Message-ID | <gmvbnpF4rglU3@mid.individual.net> |
| In reply to | #258688 |
Am 19.06.2019 um 18:40 schrieb Gerrit Heitsch: > On 6/19/19 6:16 PM, Hans-Peter Diettrich wrote: > Es reicht wenn ein Auto dem anderen was mitteilen kann. Damit muss das > Auto von aussen erreichbar sein. Wie ist egal, ob nun WLAN, was eigenes > oder Bluetooth. Sobald das geht reicht 1 Bug an der falschen Stelle und > das Auto gehorcht dem Angreifer. Bei ordentlichem Design gibt es nicht viele solche Stellen. Zeige mir einen Hacker, der durch die reine Übertragung von Daten (nicht Updates oder Skripte) irgendwo die Kontrolle übernehmen kann. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2019-06-19 20:32 +0200 |
| Message-ID | <qedv4h$o85$1@news.bawue.net> |
| In reply to | #258695 |
On 6/19/19 8:02 PM, Hans-Peter Diettrich wrote: > Am 19.06.2019 um 18:40 schrieb Gerrit Heitsch: >> On 6/19/19 6:16 PM, Hans-Peter Diettrich wrote: > >> Es reicht wenn ein Auto dem anderen was mitteilen kann. Damit muss das >> Auto von aussen erreichbar sein. Wie ist egal, ob nun WLAN, was eigenes >> oder Bluetooth. Sobald das geht reicht 1 Bug an der falschen Stelle und >> das Auto gehorcht dem Angreifer. > > Bei ordentlichem Design gibt es nicht viele solche Stellen. Zeige mir > einen Hacker, der durch die reine Übertragung von Daten (nicht Updates > oder Skripte) irgendwo die Kontrolle übernehmen kann. Buffer Overflow als Beispiel sagt dir was? Da kommen eigentlich unschuldige Datenpakete an und einen Moment später hat der Angreifer eine root-Shell. 'sendmail' war früher berüchtigt dafür, auch 'ssh' hatte solche Probleme. Eigentlich sollte sowas nicht vorkommen, deshalb nennt sich sowas auch 'Bug'. Es reicht wenn ein Programmierer nicht daran denkt. Kurz, wenn ich Daten reinschicken kann, dann müssen die bearbeitet werden und wenn der Code der das erledigt Fehler hat ist der Hacker drin. Wie sowas aussehen kann wird hier beschrieben: http://illmatics.com/Remote%20Car%20Hacking.pdf Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-06-19 21:43 +0200 |
| Message-ID | <gmvhk1F64c2U2@mid.individual.net> |
| In reply to | #258699 |
Am 19.06.2019 um 20:32 schrieb Gerrit Heitsch: > On 6/19/19 8:02 PM, Hans-Peter Diettrich wrote: >> Bei ordentlichem Design gibt es nicht viele solche Stellen. Zeige mir >> einen Hacker, der durch die reine Übertragung von Daten (nicht Updates >> oder Skripte) irgendwo die Kontrolle übernehmen kann. > > Buffer Overflow als Beispiel sagt dir was? Da kommen eigentlich > unschuldige Datenpakete an und einen Moment später hat der Angreifer > eine root-Shell. 'sendmail' war früher berüchtigt dafür, auch 'ssh' > hatte solche Probleme. Das kann nur vorkommen, wenn Messages mangels Redundanz nicht verloren gehen dürfen. Wenn Abstandswerte zu oft hereinkommen, darf gerne jeder zweite weggeworfen werden. Das geht z.B. automatisch wenn den externen Meßwerten feste Speicherplätze zugewiesen werden, die dann stets den neuesten Wert enthalten. Zudem kann im Straßenverkehr das meiste Datenaufkommen lokal gehalten werden, womit ein einzelner Angreifer viele Ziele gleichzeitig bombardieren müßte. Übergeordnete Steuerung betrifft allenfalls die optimale Geschwindigkeit vor Kreuzungen oder Unfallstellen. Und daß beim Buffer Overflow auch noch Daten und Code vermischt werden können, ist ein schwerer Designfehler. Ich schätze mal, daß sich die Militärs dieses Problems spätestens dann annehmen werden, wenn der erste größere Angriff stattgefunden hat. Möglicherweise auch schon früher... Im Verkehrsnetz wäre es durchaus eine sichere Lösung, beim Auftreten von Überlastungen die Fahrzeuge anzuhalten. Das geht auch mit abgeschaltetem Netzwerk, nur mit den Sensoren am Fahrzeug. Oder etwas weicher mit dem Rückfall auf konservative Abstände, wenn die zuvor wegen der vorauseilenden Mitteilungen von Geschwindigkeitsänderungen (Bremsen!) verringert werden konnten. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2019-06-19 22:13 +0200 |
| Message-ID | <qee519$qod$1@news.bawue.net> |
| In reply to | #258702 |
On 6/19/19 9:43 PM, Hans-Peter Diettrich wrote: > Am 19.06.2019 um 20:32 schrieb Gerrit Heitsch: >> On 6/19/19 8:02 PM, Hans-Peter Diettrich wrote: > >>> Bei ordentlichem Design gibt es nicht viele solche Stellen. Zeige mir >>> einen Hacker, der durch die reine Übertragung von Daten (nicht Updates >>> oder Skripte) irgendwo die Kontrolle übernehmen kann. >> >> Buffer Overflow als Beispiel sagt dir was? Da kommen eigentlich >> unschuldige Datenpakete an und einen Moment später hat der Angreifer >> eine root-Shell. 'sendmail' war früher berüchtigt dafür, auch 'ssh' >> hatte solche Probleme. > > Das kann nur vorkommen, wenn Messages mangels Redundanz nicht verloren > gehen dürfen. Nein, das kann jederzeit passieren. Bevor dein Code entscheidet, ob er die Daten behält oder wegwirft hat er (bzw. das OS) sie schon im Netzwerkstack bearbeitet. Dieser könnte fehlerhaft sein. Siehe auch der aktuelle Bug im Linuxkernel im Bezug auf SACK. Passend gebaute Pakete an einen Linux-Rechner geschickt ergeben eine Kernel-Panic. Ein Absturz des Steuerrechners eines autonomen Autos ist ein GAU. Es gilt bei Kommunikation mit der Aussenwelt: Alle eingehenden Daten sind bis zum Beweis (!) des Gegenteils als böse zu betrachten und das bei jedem eingehenden Datenpaket. Alternativ kann man die Logik so bauen, daß nichts passieren kann. Ist aber bemerkenswert schwer wie sich immer wieder zeigt. Wenn Abstandswerte zu oft hereinkommen, darf gerne jeder > zweite weggeworfen werden. Das geht z.B. automatisch wenn den externen > Meßwerten feste Speicherplätze zugewiesen werden, die dann stets den > neuesten Wert enthalten. Vorsicht... Buffer Overflows passieren wenn man meint, daß eingehende Daten nur Länge <X> Bytes haben können und der Angreifer ein spezielles Paket bastelt bei dem das Datenfeld <X+Y> Bytes groß ist. Ist dein Eingangspuffer genau <X> Bytes groß wird er beim Kopieren der Daten des bösen Paketes überlaufen. Zudem kann im Straßenverkehr das meiste > Datenaufkommen lokal gehalten werden, womit ein einzelner Angreifer > viele Ziele gleichzeitig bombardieren müßte. Macht nichts, dafür hat man heutzutage Computer, die können sowas gut. Sobald der proof-of-concept-Exploit da ist finden sich Leute die das optimieren und danach reicht womöglich ein Laptop mit WLAN- oder Bluetooth-Stick um Spass zu haben. > Und daß beim Buffer Overflow auch noch Daten und Code vermischt werden > können, ist ein schwerer Designfehler. Ja, kommt aber immer wieder vor und ist bei der üblichen von-Neumann-Architektur gar nicht so einfach zu vermeiden. Alternative Architekturen die Code und Daten trennen gibt es, aber so richtig durchsetzen wollen die sich nicht. Noch schöner ist der off-by-one-Exploit: https://csl.com.co/en/off-by-one-explained/ Es gibt Sprachen die das Problem nicht haben. Dafür haben sie andere, in einem Auto muss der Kram echtzeitfähig sein. Da kann nicht der Garbage-Collector kommen und das ganze für 100ms einfrieren während er Speichermüll einsammelt. > Im Verkehrsnetz wäre es durchaus eine sichere Lösung, beim Auftreten von > Überlastungen die Fahrzeuge anzuhalten. Autos die das häufiger tun kauft keiner. Schönes Ziel für einen Denial-of-Service-Angriff. Das Auto wird dabei nicht übernommen, aber fahren tut es auch nicht mehr. Das geht auch mit abgeschaltetem > Netzwerk, nur mit den Sensoren am Fahrzeug. Ist nur zu spät wenn der Angreifer das System bereits übernommen hat. Denn dann kannst du das Netzwerk nicht mehr abschalten wenn er das erwartet hat, du (bzw. dein Programm) ist dann nicht mehr Herr im Haus (Auto). Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-06-20 00:34 +0200 |
| Message-ID | <gmvrmjF88a1U1@mid.individual.net> |
| In reply to | #258711 |
Am 19.06.2019 um 22:13 schrieb Gerrit Heitsch: > On 6/19/19 9:43 PM, Hans-Peter Diettrich wrote: > Vorsicht... Buffer Overflows passieren wenn man meint, daß eingehende > Daten nur Länge <X> Bytes haben können und der Angreifer ein spezielles > Paket bastelt bei dem das Datenfeld <X+Y> Bytes groß ist. Ist dein > Eingangspuffer genau <X> Bytes groß wird er beim Kopieren der Daten des > bösen Paketes überlaufen. Das halte ich für ein spezielles Problem unsicherer Programmiersprachen, wie C. Speicher dürfte heutzutage keine Mangelware mehr sein. Kein System kann gezwungen werden, übergroße Datenpakete anzunehmen. > Zudem kann im Straßenverkehr das meiste >> Datenaufkommen lokal gehalten werden, womit ein einzelner Angreifer >> viele Ziele gleichzeitig bombardieren müßte. > > Macht nichts, dafür hat man heutzutage Computer, die können sowas gut. Ähm, wieviele Sender auf unterschiedlichen Kanälen soll so ein Computer haben? > Es gibt Sprachen die das Problem nicht haben. Dafür haben sie andere, in > einem Auto muss der Kram echtzeitfähig sein. Da kann nicht der > Garbage-Collector kommen und das ganze für 100ms einfrieren während er > Speichermüll einsammelt. Sag ich doch: ein Problem der Programmiersprache :-( >> Im Verkehrsnetz wäre es durchaus eine sichere Lösung, beim Auftreten >> von Überlastungen die Fahrzeuge anzuhalten. > > Autos die das häufiger tun kauft keiner. Schönes Ziel für einen > Denial-of-Service-Angriff. Das Auto wird dabei nicht übernommen, aber > fahren tut es auch nicht mehr. Es geht dabei doch nicht um einzelne Autos, und selbst die wären kaum auf einen bestimmten Typ beschränkt. > Das geht auch mit abgeschaltetem >> Netzwerk, nur mit den Sensoren am Fahrzeug. > > Ist nur zu spät wenn der Angreifer das System bereits übernommen hat. Woher kommt nur immer wieder die Annahme, daß ein Kfz bei geeigneter Programmierung gekapert werden könnte? Von den großen Autobauern, nehme ich mal an, die damit schlampige Programmierung entschuldigen wollen. Für mehr als Mogelsoftware scheint es dort nicht zu reichen, zumindest nicht ohne nachhaltigen äußeren Druck :-] DoDi
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2019-06-20 01:21 +0200 |
| Message-ID | <gmvuboF8pg3U1@mid.individual.net> |
| In reply to | #258732 |
Am 20.06.19 um 00:34 schrieb Hans-Peter Diettrich: > Woher kommt nur immer wieder die Annahme, daß ein Kfz bei geeigneter > Programmierung gekapert werden könnte? Aus der Realität? https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/ https://www.theguardian.com/technology/2016/sep/20/tesla-model-s-chinese-hack-remote-control-brakes Die Frage ist eher, woher die Annahme stammt, daß ein vernetzter Computer auf Rädern wundersamerweise besser gegen informationstechnische Angriffe geschützt sein sollte als irgendwelche vernetzte Computer anderswo. Hanno -- The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. - John Kenneth Galbraith
[toc] | [prev] | [next] | [standalone]
| From | Helmut Schellong <rip@schellong.biz> |
|---|---|
| Date | 2019-06-20 14:29 +0200 |
| Message-ID | <qefu78$qvc$1@solani.org> |
| In reply to | #258743 |
On 06/20/2019 01:21, Hanno Foest wrote: > Am 20.06.19 um 00:34 schrieb Hans-Peter Diettrich: > >> Woher kommt nur immer wieder die Annahme, daß ein Kfz bei geeigneter >> Programmierung gekapert werden könnte? > > Aus der Realität? > > https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/ > > https://www.theguardian.com/technology/2016/sep/20/tesla-model-s-chinese-hack-remote-control-brakes > > > Die Frage ist eher, woher die Annahme stammt, daß ein vernetzter Computer auf > Rädern wundersamerweise besser gegen informationstechnische Angriffe > geschützt sein sollte als irgendwelche vernetzte Computer anderswo. Ich verstehe solches seit langem nicht, auch nicht in Filmen. Meine Autos sind nicht vernetzt, und werden es nie sein. Falls doch, würde ich die Antenne unwirksam machen. Es gibt keinerlei Aktoren in meinen Autos, die eine Manipulation erlauben würden. Einen Zugang per Funk sowieso nicht. Meine Autos sind folglich absolut nicht remote zu hacken. Es gibt nur einen Weg: Falls jemand an mein Auto herankäme, es öffnen und ungestört daran arbeiten könnte, nur dann wäre eine Manipulation möglich. -- Mit freundlichen Grüßen Helmut Schellong var@schellong.biz www.schellong.de www.schellong.com www.schellong.biz http://www.schellong.de/c.htm
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2019-06-20 07:27 +0200 |
| Message-ID | <qef5fe$98t$1@news.bawue.net> |
| In reply to | #258732 |
On 6/20/19 12:34 AM, Hans-Peter Diettrich wrote: > Am 19.06.2019 um 22:13 schrieb Gerrit Heitsch: >> On 6/19/19 9:43 PM, Hans-Peter Diettrich wrote: > >> Vorsicht... Buffer Overflows passieren wenn man meint, daß eingehende >> Daten nur Länge <X> Bytes haben können und der Angreifer ein spezielles >> Paket bastelt bei dem das Datenfeld <X+Y> Bytes groß ist. Ist dein >> Eingangspuffer genau <X> Bytes groß wird er beim Kopieren der Daten des >> bösen Paketes überlaufen. > > Das halte ich für ein spezielles Problem unsicherer Programmiersprachen, > wie C. Speicher dürfte heutzutage keine Mangelware mehr sein. Kein > System kann gezwungen werden, übergroße Datenpakete anzunehmen. Doch, eben, aufgrund von Programmierfehlern. Wir reden hier von Fehlern im Code. >> Zudem kann im Straßenverkehr das meiste >>> Datenaufkommen lokal gehalten werden, womit ein einzelner Angreifer >>> viele Ziele gleichzeitig bombardieren müßte. >> >> Macht nichts, dafür hat man heutzutage Computer, die können sowas gut. > > Ähm, wieviele Sender auf unterschiedlichen Kanälen soll so ein Computer > haben? Weieviele USB-Ports hast du und wie schnell kann der Sender in so einem Stick den Kanal wechseln? Dazu noch USB-Hubs. >>> Im Verkehrsnetz wäre es durchaus eine sichere Lösung, beim Auftreten >>> von Überlastungen die Fahrzeuge anzuhalten. >> >> Autos die das häufiger tun kauft keiner. Schönes Ziel für einen >> Denial-of-Service-Angriff. Das Auto wird dabei nicht übernommen, aber >> fahren tut es auch nicht mehr. > > Es geht dabei doch nicht um einzelne Autos, und selbst die wären kaum > auf einen bestimmten Typ beschränkt. Doch, am Ende geht es um einzelne Autos. >> Das geht auch mit abgeschaltetem >>> Netzwerk, nur mit den Sensoren am Fahrzeug. >> >> Ist nur zu spät wenn der Angreifer das System bereits übernommen hat. > > Woher kommt nur immer wieder die Annahme, daß ein Kfz bei geeigneter > Programmierung gekapert werden könnte? Bei geeigneter Programmierung nicht. Aber woher kommt die Annahme, daß die Programmierer solchen Code programmieren? Wer schon länger mit IT zu tun hat, hat eher den Eindruck als wenn solche Bugs der Normalzustand sind. Ich bekomme hier mehrfach die Woche Sicherheitsupdates für alle möglicht Software. Von den großen Autobauern, nehme > ich mal an, die damit schlampige Programmierung entschuldigen wollen. > Für mehr als Mogelsoftware scheint es dort nicht zu reichen, zumindest > nicht ohne nachhaltigen äußeren Druck :-] Nach allem was ich gelesen habe war zumindest die Codequalität der Mogelsoftware sehr gut. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-06-20 10:01 +0200 |
| Message-ID | <gn0sv3Ff3jaU2@mid.individual.net> |
| In reply to | #258752 |
Am 20.06.2019 um 07:27 schrieb Gerrit Heitsch: > Ich bekomme hier mehrfach die Woche Sicherheitsupdates für alle > möglicht Software. Eben, alle mögliche Bananasoft, nicht Kfz :-] > Von den großen Autobauern, nehme >> ich mal an, die damit schlampige Programmierung entschuldigen wollen. >> Für mehr als Mogelsoftware scheint es dort nicht zu reichen, zumindest >> nicht ohne nachhaltigen äußeren Druck :-] > > Nach allem was ich gelesen habe war zumindest die Codequalität der > Mogelsoftware sehr gut. Na also, geht doch :-) Ähm, war die Mogelsoftware auch sicher gegen Hackerangriffe? DoDi
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2019-06-20 10:28 +0200 |
| Message-ID | <qefg35$dge$1@news.bawue.net> |
| In reply to | #258762 |
On 6/20/19 10:01 AM, Hans-Peter Diettrich wrote: > Am 20.06.2019 um 07:27 schrieb Gerrit Heitsch: > >> Ich bekomme hier mehrfach die Woche Sicherheitsupdates für alle >> möglicht Software. > > Eben, alle mögliche Bananasoft, nicht Kfz :-] Frag mal Tesla-Besitzer wie oft die Updates bekommen. Es kam da auch schon vor, daß ein Update Pflicht war und das Auto erst nach Installation fahren wollte. Kommt gut wenn man es eilig hat und auf dem Bildschirm was von '30 min to go' steht. >> Von den großen Autobauern, nehme >>> ich mal an, die damit schlampige Programmierung entschuldigen wollen. >>> Für mehr als Mogelsoftware scheint es dort nicht zu reichen, zumindest >>> nicht ohne nachhaltigen äußeren Druck :-] >> >> Nach allem was ich gelesen habe war zumindest die Codequalität der >> Mogelsoftware sehr gut. > > Na also, geht doch :-) > > Ähm, war die Mogelsoftware auch sicher gegen Hackerangriffe? Die fraglichen Autos sind nicht vernetzt, solange du also keinen BT-Dongle im ODB-Port hast kann da nichts passieren. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-06-20 10:49 +0200 |
| Message-ID | <gn0vp9Ffn3hU1@mid.individual.net> |
| In reply to | #258765 |
Am 20.06.2019 um 10:28 schrieb Gerrit Heitsch: > On 6/20/19 10:01 AM, Hans-Peter Diettrich wrote: >> Am 20.06.2019 um 07:27 schrieb Gerrit Heitsch: >> >>> Ich bekomme hier mehrfach die Woche Sicherheitsupdates für alle >>> möglicht Software. >> >> Eben, alle mögliche Bananasoft, nicht Kfz :-] > > Frag mal Tesla-Besitzer wie oft die Updates bekommen. Es kam da auch > schon vor, daß ein Update Pflicht war und das Auto erst nach > Installation fahren wollte. Kommt gut wenn man es eilig hat und auf dem > Bildschirm was von '30 min to go' steht. Okay, ich war da gedanklich bei den unintelligenten Autos. Bei KI gibt es aber keine Programmierfehler mehr, nur noch falsche Erziehung, und Updates sind dann Gehirnwäsche ;-) DoDi
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2019-06-20 11:48 +0200 |
| Message-ID | <qefkps$fc1$1@news.bawue.net> |
| In reply to | #258766 |
On 6/20/19 10:49 AM, Hans-Peter Diettrich wrote: > Am 20.06.2019 um 10:28 schrieb Gerrit Heitsch: >> On 6/20/19 10:01 AM, Hans-Peter Diettrich wrote: >>> Am 20.06.2019 um 07:27 schrieb Gerrit Heitsch: >>> >>>> Ich bekomme hier mehrfach die Woche Sicherheitsupdates für alle >>>> möglicht Software. >>> >>> Eben, alle mögliche Bananasoft, nicht Kfz :-] >> >> Frag mal Tesla-Besitzer wie oft die Updates bekommen. Es kam da auch >> schon vor, daß ein Update Pflicht war und das Auto erst nach >> Installation fahren wollte. Kommt gut wenn man es eilig hat und auf dem >> Bildschirm was von '30 min to go' steht. > > Okay, ich war da gedanklich bei den unintelligenten Autos. > > Bei KI gibt es aber keine Programmierfehler mehr, nur noch falsche > Erziehung, und Updates sind dann Gehirnwäsche ;-) Natürlich gibt es da noch Programmierfehler wenn die AI Verbindung nach aussen aufbauen soll. Das ist dann ein ganz normales OS mit allen seinen Problemen welches diesen Job übernimmt. Und eine AI kann man nicht wirklich debuggen, wenn sie falsch gelernt hat ist das sicherste auf einen Stand zurückzugehen der diesen Fehler noch nicht hat und das Lernen zu modifizieren. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Ewald Pfau <anderswo@gmx.net> |
|---|---|
| Date | 2019-06-20 12:11 +0000 |
| Message-ID | <gn1bf1Fi71cU1@mid.individual.net> |
| In reply to | #258768 |
Gerrit Heitsch <gerrit@laosinh.s.bawue.de>: > Und eine AI kann man nicht wirklich debuggen, wenn sie falsch gelernt > hat ist das sicherste auf einen Stand zurückzugehen der diesen Fehler > noch nicht hat und das Lernen zu modifizieren. Und wenn es keine Dokumentation der Schritte gibt, wie sich solche Stände etablieren, dann kann man auch nicht zu einem als solide angenommenen Stand zurückgehen. Mir schwant, da wabert eine euphorische Blase, die krankt vorn und hinten. Wenn jemand etwas substantieller an der Oberfläche kratzen will, so wird er auch wahrscheinlich gleich angebafft, das geht niemanden etwas an, das ist urheberrechtsgeschützt - eine andere Lobby als eine, die solche Reaktion wahrscheinlich sein lässt, ist bei der Erstellung von Gesetzen nicht zu erwarten. Und Normen macht die Industrie für sich selbst, nicht zum Dienst am gesellschaftlichen Bedarf. Da ist keine Kontrillinstanz dazwischen. Da verbleibt als Regulativ nur der Zwang im Management, wirtschaftliche Quartalsergebnisse hübsch aussehen zu lassen.
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2019-06-20 14:48 +0200 |
| Message-ID | <qefvba$jm3$1@news.bawue.net> |
| In reply to | #258777 |
On 6/20/19 2:11 PM, Ewald Pfau wrote: > Gerrit Heitsch <gerrit@laosinh.s.bawue.de>: > >> Und eine AI kann man nicht wirklich debuggen, wenn sie falsch gelernt >> hat ist das sicherste auf einen Stand zurückzugehen der diesen Fehler >> noch nicht hat und das Lernen zu modifizieren. > > Und wenn es keine Dokumentation der Schritte gibt, wie sich solche Stände > etablieren, dann kann man auch nicht zu einem als solide angenommenen Stand > zurückgehen. Mir schwant, da wabert eine euphorische Blase, die krankt vorn > und hinten Ja, schon... Liest du hier: https://www.theverge.com/2017/11/2/16597276/google-ai-image-attacks-adversarial-turtle-rifle-3d-printed Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Ewald Pfau <anderswo@gmx.net> |
|---|---|
| Date | 2019-06-20 16:41 +0000 |
| Message-ID | <gn1r9pFljpvU1@mid.individual.net> |
| In reply to | #258783 |
Gerrit Heitsch <gerrit@laosinh.s.bawue.de>: > On 6/20/19 2:11 PM, Ewald Pfau wrote: >> Gerrit Heitsch <gerrit@laosinh.s.bawue.de>: >> >>> Und eine AI kann man nicht wirklich debuggen, wenn sie falsch gelernt >>> hat ist das sicherste auf einen Stand zurückzugehen der diesen Fehler >>> noch nicht hat und das Lernen zu modifizieren. >> >> Und wenn es keine Dokumentation der Schritte gibt, wie sich solche Stände >> etablieren, dann kann man auch nicht zu einem als solide angenommenen Stand >> zurückgehen. Mir schwant, da wabert eine euphorische Blase, die krankt vorn >> und hinten > > Ja, schon... Liest du hier: > > https://www.theverge.com/2017/11/2/16597276/google-ai-image-attacks-adversarial-turtle-rifle-3d-printed Ja, danke, allerdings addieren sich zu obigen Befürchtungen zu euphorischen Blasen dann noch Befürchtungen von Menschen, die Katastrophen im Sandkasten inszenieren, rein als Ansammlung von Beliebigkeit ohne Sinn und Verstand, um damit ihre eigene Wichtigkeit unterstreichen zu können, weil sie in dem Land, in dem sie den Tag mit solcherlei vertreiben, sonst Gefahr laufen, im Monat darauf kein Gehalt mehr auf dem Konto anzutreffen. In EU-Europa ist diese Errungenschaft des Schürens von Hysterie zur Beliebigkeit auch schon in Richtung der Academia unterwegs, wo kann da jemand noch in Ruhe Gedanken entwickeln, die sich hernach als belastbar erproben lassen? Ich lese das heraus, was Du wahrscheinlich nicht als wesentlich sehen wirst, ich hingegen schon: Vor allem einmal die absolute Betonung des Angreifer-Szenarios. Wozu will das Zeug überhaupt permanent nach Waffen suchen? Wenn im Wald ein Bär auftaucht, nimmt man einen Stock und zeigt damit auf ihn. Das ist hier so in etwa die Tonlage. Ich sehe hier das Trauma des Völkermords, welcher den Bewohnern der U.S.A. fest in die Adern gefroren ist, und nicht mehr weichen wird von dort, und immer weiter geht es bumm, bumm, bumm. Noch ein Eingeborener. Noch eine Rothaut. Und Wildwest ist eine Idylle. Weil die Erinnerung an die begangenen Verbrechen hält real kein Mensch aus. Das hatte ich ein Posting weiter schon: Die primitivsten Hirngespinste von Möchtegernfeudalfürsten geben hier den Ton an, und deren Korrektur oder womöglich auch die bessere Einsortierung in zivilisierte Verhätlnisse ist nicht vorgesehen. Bumm. Bumm. Am Flughafen jeden unsittlich begrapschen, den Leuten voll an die Nieren. Bumm. Bumm. Ein Trauma ist das - verdammt dazu, sich nicht mehr weiter entwickeln zu können als in destruktive Richtungen (und die protestantischen Prediger der hunderterlei Geschmacksrichtungen dort, zum billigen und schnellen Heil, helfen dabei mit, so gut es geht). Wenn es da je Fortschritt geben sollte, sorgte man erstmal dafür, dass die Leute eine Daueranstellung haben, und solide abgesichert sind, auch dann noch, wenn sie tatsächlich einmal Erkenntnis riskieren, die nicht immer gleich im Interesse der Shareholder ist. Das klingt dann gleich anders als nur bumm! bumm! Aber das geht dort dann rein ideologisch nicht. Das wäre ja der blanke Kommunismus! Bewahre! So geht der Klang der Imperatoren um die Welt. Bumm. Bumm. Die NATO war da. Gleiche Strophe. Eh schon wissen. Und das zweite ist die Anmaßung: Wir! sind modern, also müsst Ihr! Euch Uns! anpassen. So ein Satz entsprechend diesem Zusammenhang ist eine Frechheit sondergleichen (und die adversial examples sind genau die Verherrlichung des andauernden Bumm! Bumm!): << “Adversarial examples are a practical concern that people must consider as neural networks become increasingly prevalent (and dangerous).” >> Die Maschinen sind auf bumm! bumm! getrimmt, also pass gefälligst auf, wenn du zufällig einer begegnest! Ich hätte mir doch lieber gewünscht, dass ich in meinem persönlichen experimentellen Deutungskino um einiges mehr daneben liege. Den Ehrgeiz hab ich nicht, mit Schwarzmalerei rechtbehalten zu wollen. Besser ist, ich habe nicht recht, bei so einem Mist. Aber diese Skizze stammt von einem Teil der Welt, wo es nur Feinde! Feinde! gibt, und Kooperation ist entweder ein gutes Geschäft oder man muss sie verbieten, weil ideologisch anrüchig. Und wenn Katastrophen passieren, ist zuerst das Pentagon vor Ort, sichert den Flughafen und verwehrt den Hilfskräften, ins Land zu kommen, weil, genau! - die Katastrophe ist ein strategischer Anlass, seine Besatzungsansprüche zu deponieren. So geht real. Friedensstiftende Opferbereitschaft heißt das dann, und ein paar Nasen im Umfeld des Weißen Hauses verdienen sich dumm und dämlich damit, einen Großteil der Gelder für sich und für windige Finanzkonstruktionen unter Freunden abzuzweigen. So geht real. So wird dort gedacht. EU geht wieder ein gutes Stück anders, ein gutes Stück intrikater, in sich verknotet und verworren, also vor allem mutlos. Nur immer bumm! bumm! ist den Leuten hier zu blöd, dafür ist auch die Breitenerziehung zu gut, aber zugleich alles andere hat zuerst mal ein Verbotsschild umgehängt, weil, wir sind ja nicht die hegemonialen Weltmeister, also darf man erstmal nicht dürfen nicht. Das ist dann auch nicht so einladend, dafür, wo denn nun die Analyse herkommen soll, zu so einer neuen Technik, im Sinn von dringend gegebenen gesellschaftlichen Belangen herauszufinden, wie hierzu Dokumentationen auszusehen hätte. Von Zeit zu Zeit werden die eigentlich wichtigen Fragen dann unter dem Titel Ethik ausgesondert. Etwa so, wie unbezahlbare Schulden in eine Bad Bank ausgesondert werden. Das Schema scheint dasselbe - wer wagt es, der Gier, auf zu neuen Ufern, je einen Klotz ans Bein zu binden? Wie groß war doch gleich die Durchsetzung von deutschen Betrieben mit U-S- oder sonstwie strikt Wallstreet-hörigem Kapital? Und wie groß ist die reale Chance, dass sich mit so einem Selbstverständnis der permanenten Katastrophen eine fundamental ins gesellschaftliche Leben einbrechende Technik je Fuß fassen kann? Vielleicht spricht dann die EU ein Machtwort und holt die Brechstange? Oder wie? Ja, sie wollen nur unser Bestes. Und alle geben es her. Zum Billigtarif.
[toc] | [prev] | [next] | [standalone]
| From | Hanno Foest <hurga-news2@tigress.com> |
|---|---|
| Date | 2019-06-19 21:11 +0200 |
| Message-ID | <gmvfn2F5mtoU1@mid.individual.net> |
| In reply to | #258695 |
Am 19.06.19 um 20:02 schrieb Hans-Peter Diettrich: >> Es reicht wenn ein Auto dem anderen was mitteilen kann. Damit muss das >> Auto von aussen erreichbar sein. Wie ist egal, ob nun WLAN, was eigenes >> oder Bluetooth. Sobald das geht reicht 1 Bug an der falschen Stelle und >> das Auto gehorcht dem Angreifer. > > Bei ordentlichem Design gibt es nicht viele solche Stellen. Es gibt allerdings auch nicht viele Beispiele für ordentliches Design :) Bei einem Vortrag zum Thema vor einigen Jahren gehört: "Die IT-Sicherheit im Automobilbereich ist auf dem Niveau der Computersicherheit der 80er Jahre." OK, ist ein paar Jahre her. Vielleicht sind wir jetzt in den 90ern angekommen. Macht es aber nicht so richtig viel besser. > Zeige mir > einen Hacker, der durch die reine Übertragung von Daten (nicht Updates > oder Skripte) irgendwo die Kontrolle übernehmen kann. Dazu schrieb Gerrit schon was. - Einer meiner Favoriten in dem Bereich ist ein buffer overflow in der libjpg (ist ne Weile her, aber dennoch). Irgendne Website mit einem präparierten Bild im Browser anzeigen lassen und zack, hast du ein Problem. . Ich weiß schon ein klein wenig über IT-Sicherheit, und diverse meiner Freunde halten meine Art der Computernutzung für tendenziell paranoid, aber sowas würde auch mich erwischen. Hanno -- The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. - John Kenneth Galbraith
[toc] | [prev] | [next] | [standalone]
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Date | 2019-06-19 21:54 +0200 |
| Message-ID | <gmvigaF6adlU1@mid.individual.net> |
| In reply to | #258700 |
Am 19.06.2019 um 21:11 schrieb Hanno Foest: > Am 19.06.19 um 20:02 schrieb Hans-Peter Diettrich: >> Bei ordentlichem Design gibt es nicht viele solche Stellen. > > Es gibt allerdings auch nicht viele Beispiele für ordentliches Design :) > > Bei einem Vortrag zum Thema vor einigen Jahren gehört: "Die > IT-Sicherheit im Automobilbereich ist auf dem Niveau der > Computersicherheit der 80er Jahre." OK, ist ein paar Jahre her. > Vielleicht sind wir jetzt in den 90ern angekommen. Macht es aber nicht > so richtig viel besser. Richtig, da liegt eine ziemlich unbeachtete Schwachstelle der IT. Welche Firma wird schon freiwillig Geld und Zeit in Sicherheit investieren, wenn die dann sowieso nur gewährleistet werden kann, wenn sich *alle* dran halten? Wie bereits angedeutet, wenn die Industrie nicht dazu gebracht werden kann, etwas zu verbessern, dann wird das wohl am Militär hängen bleiben. Und Zustände wie im Internet, mit fake news in sozialen Medien, sollte es eigentlich im Verkehrsnetz garnicht geben, weil dort solche Medien nichts zu suchen haben. DoDi
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2019-06-19 22:16 +0200 |
| Message-ID | <qee56v$qre$1@news.bawue.net> |
| In reply to | #258704 |
On 6/19/19 9:54 PM, Hans-Peter Diettrich wrote: > Am 19.06.2019 um 21:11 schrieb Hanno Foest: >> Am 19.06.19 um 20:02 schrieb Hans-Peter Diettrich: > >>> Bei ordentlichem Design gibt es nicht viele solche Stellen. >> >> Es gibt allerdings auch nicht viele Beispiele für ordentliches Design :) >> >> Bei einem Vortrag zum Thema vor einigen Jahren gehört: "Die >> IT-Sicherheit im Automobilbereich ist auf dem Niveau der >> Computersicherheit der 80er Jahre." OK, ist ein paar Jahre her. >> Vielleicht sind wir jetzt in den 90ern angekommen. Macht es aber nicht >> so richtig viel besser. > > Richtig, da liegt eine ziemlich unbeachtete Schwachstelle der IT. Welche > Firma wird schon freiwillig Geld und Zeit in Sicherheit investieren, > wenn die dann sowieso nur gewährleistet werden kann, wenn sich *alle* > dran halten? > > Wie bereits angedeutet, wenn die Industrie nicht dazu gebracht werden > kann, etwas zu verbessern, dann wird das wohl am Militär hängen bleiben. Die sind bei der Software auch nicht besser. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Rolf Bombach <rolfnospambombach@invalid.invalid> |
|---|---|
| Date | 2019-06-18 23:01 +0200 |
| Message-ID | <qebjev$1pg$1@dont-email.me> |
| In reply to | #258477 |
Joerg schrieb: > > Z.B. der BMW M535i E12 in Suedafrika. Die hatten auch eine renommierte Schmiede fuer militaerische Elektronik und Kampfflugzeuge (Armscor). Jetzt ist das natuerlich alles weitgehend vorbei. Zynisch ausgedrückt hat die RSA verschiedene Phasen durchgemacht. Man kann sich immer darauf verlassen, dass die Amerikaner das Richtige tun. Nachdem sie alles andere ausprobiert haben. Churchill Andere landen am andern Ende. IIRC hatten die schon sehr früh mysteriöse FFT-Chips für Radarsignale, die waren sehr gesucht für Signalverarbeitung. Da war wohl so was wie ein Schwarzmarkt in Europa. -- mfg Rolf Bombach
[toc] | [prev] | [next] | [standalone]
Page 13 of 15 — ← Prev page 1 … 11 12 [13] 14 15 Next page →
Back to top | Article view | de.sci.electronics
csiph-web