Chromium-Browser in "user"

Post by Lutz E. Cerning
Hallo allerseits,
vorhin habe ich mir den aktuellwn Comium-Browser von

Warum? Die URL ohne "chromium." wirft Fehlermeldungen; als ob nichts
anderes daneben existierte.

Post by Lutz E. Cerning
Ist es ein Sicherheitsrisiko dass er sich in
...AppData\Local\Chromium\Application und *nicht* in den
Programme-Ordner installieren will?
Oder habe ich da nur etwas übersehen?

Keine Ahnung.

Ich würde Chromium (oder jede andere Software) nur von Originalseiten
herunterladen.

--
Andreas

Martin Gerdes

2022-08-04 16:03:13 UTC

Post by Andreas Kohlbach

vorhin habe ich mir den aktuellen Chromium-Browser von

Warum? Die URL ohne "chromium." wirft Fehlermeldungen; als ob nichts
anderes daneben existierte.

Ist es ein Sicherheitsrisiko, dass er sich in
...AppData\Local\Chromium\Application und *nicht* in den
Programme-Ordner installieren will?

Ja.

Post by Andreas Kohlbach

Oder habe ich da nur etwas übersehen?

Ich würde Chromium (oder jede andere Software) nur von Originalseiten
herunterladen.

Das auch.

Das Sicherheitsrisiko liegt darin, daß ein ausführbares Programm in den
Nutzerdatenbereich installiert und dort ausgeführt wird. Ich würde mal
sagen: typisches Malwareverfahren, das bei der üblichen systematisch
unsicheren Installationsmethode von Windows auch reibungslos
funktioniert.

Es hat etwas für sich, daß in Programmbereiche nur ein Administrator
schreiben kann (dann kann der Normaluser sich seine Programme nicht (so
leicht) zerschießen und auch keine eigenen Programme installieren). Dazu
gehört aber auch, daß in Plattenbereichen, in die der Nutzer schreiben
darf, keine Programme ausgeführt werden dürfen.

Selbst dann, wenn sich der Nutzer eine malware.exe herunterlädt und in
seinem Nutzerbereich speichert, verweigert ein gut konfiguriertes System
die Ausführung dieser Datei an diesem Speicherort.

Ja, ist etwas unbequem, immer erst Admin sein zu müssen, um Programme zu
installieren. Sicherheit ist immer mehr oder weniger unbequem.

Mich hat vor etlicher Zeit mal verwundert, daß das Programm 'Zoom' auf
einem vermeintlich abgesicherten System einfach so lief. Diese
Schweinebacke von Programm hatte sich irgendwo im Nutzer-Datenbereich
versteckt, wo eigentlich keine ausführbaren Programme laufen können
sollten.

Lies mal DAS
https://skanthak.homepage.t-online.de/SAFER.html *
und DAS
https://schneegans.de/windows/safer/
zum Thema.

*Ach ja: Laß Dich von der indiskutablen Benutzerschnittstelle dieses
Netizens nicht abschrecken. Er ist ein Rüpel, aber was er schreibt, hat
fachlich Hand und Fuß.

Peter J. Holzer

2022-08-05 10:38:47 UTC

Post by Andreas Kohlbach
Ich würde Chromium (oder jede andere Software) nur von Originalseiten
herunterladen.

Das auch.

ACK.

Post by Martin Gerdes
Das Sicherheitsrisiko liegt darin, daß ein ausführbares Programm in den
Nutzerdatenbereich installiert und dort ausgeführt wird. Ich würde mal
sagen: typisches Malwareverfahren, das bei der üblichen systematisch
unsicheren Installationsmethode von Windows auch reibungslos
funktioniert.
Es hat etwas für sich, daß in Programmbereiche nur ein Administrator
schreiben kann (dann kann der Normaluser sich seine Programme nicht (so
leicht) zerschießen und auch keine eigenen Programme installieren). Dazu
gehört aber auch, daß in Plattenbereichen, in die der Nutzer schreiben
darf, keine Programme ausgeführt werden dürfen.

Die meisten User wären unglücklich, wenn sie ihre Excel-Files nicht
selbst beschreiben dürften.

Ja, ein Excel-File ist ein Programm. Es gibt keinen prinzipiellen
Unterschied zwischen einem Excel-File und einem Python-Script. Beide
enthalten Programmcode, der von einem Interpreter (excel.exe oder
python.exe) interpretiert wird. Ein Unterschied ist, dass Excel zwischen
"harmlosen" und "potenziell gefährlichen" Instruktionen unterscheidet
und optional die Ausführung von letzteren verweigern kann, während das
bei Python nicht vorgesehen ist. Aber das ist eher eine graduelle
Unterscheidung als eine prinzipielle.

In weiterer Folge ist auch der Unterschied zwischen einem Python-File
und einem EXE-File nur ein gradueller: Ersteres wird von einem anderen
Programm interpretiert, letzteres von der Hardware selbst (mit Hilfe von
Microcode (auch wieder ein Programm) und dem Betriebssystem (definitiv
ein Programm).

Das mit der Trennung von Programmen und Nicht-Programmen ist nicht so
einfach. Mal davon abgesehen, dass User mehr Programme schreiben sollten
und nicht weniger ...

hp

Arno Welzel

2022-08-06 08:58:07 UTC

Peter J. Holzer, 2022-08-05 12:38:

[...]

Post by Peter J. Holzer
Die meisten User wären unglücklich, wenn sie ihre Excel-Files nicht
selbst beschreiben dürften.
Ja, ein Excel-File ist ein Programm. Es gibt keinen prinzipiellen

Aber kein Binary was direkten Zugriff auf beliebige Dateien des
Computers hat und API-Calls ausführen darf. Und die Ausführung von
Makros kann man wirksam unterbinden.

Post by Peter J. Holzer
Unterschied zwischen einem Excel-File und einem Python-Script. Beide
enthalten Programmcode, der von einem Interpreter (excel.exe oder
python.exe) interpretiert wird. Ein Unterschied ist, dass Excel zwischen
"harmlosen" und "potenziell gefährlichen" Instruktionen unterscheidet
und optional die Ausführung von letzteren verweigern kann, während das
bei Python nicht vorgesehen ist. Aber das ist eher eine graduelle
Unterscheidung als eine prinzipielle.

Deswegen würde man auch die Ausführung von Pyhton-Scripten, die der
Benutzer selber beschreiben darf, nicht zulassen, wenn man Sicherheit
ernstnmmt.

Post by Peter J. Holzer
Das mit der Trennung von Programmen und Nicht-Programmen ist nicht so
einfach. Mal davon abgesehen, dass User mehr Programme schreiben sollten
und nicht weniger ...

Doch, das ist sehr einfach.

--
Arno Welzel
https://arnowelzel.de

Peter J. Holzer

2022-08-06 11:26:41 UTC

Post by Peter J. Holzer
Die meisten User wären unglücklich, wenn sie ihre Excel-Files nicht
selbst beschreiben dürften.
Ja, ein Excel-File ist ein Programm. Es gibt keinen prinzipiellen

Aber kein Binary was direkten Zugriff auf beliebige Dateien des
Computers hat und API-Calls ausführen darf.

Ob Binary oder nicht ist völlig irrelevant (wie mein Python-Beispiel
demonstrieren sollte). Wichtig ist, welche Aktionen das Programm
ausführen kann.

Post by Arno Welzel
Und die Ausführung von Makros kann man wirksam unterbinden.

Dass man die Aktionen, die ein Excel-File ausführen kann, einschränken
kann, habe ich bereits geschrieben. Du erzählst da nichts Neues.
Trotzdem bleibt es ein Programm, und ob alles, was es noch tun kann,
harmlos ist, hängt von der Konfiguration, der Implementation (da gab es
immer wieder mal sehr interessante Edge-Cases) und auch vom Kontext ab.

Und das "Unterbinden von potentiell gefährlichen Aktionen" funktioniert
natürlich für Binaries und traditionelle Script-Sprachen genauso:
Praktisch jedes Betriebssystem der letzten 20 Jahre hat ein
Berechtigungssystem zumindest auf User-Basis. Etwas neuer aber IMHO auch
recht verbreitet sind Container-Systeme, die einzelne Applikationen
einschließen (primär zu erwähnen wären da die App-Systeme von iOS und
Android, aber es geht darüber hinaus. In Ubuntu 22.04 z.B. haben die
Browser (angeblich) nur sehr eingeschränkten Zugriff auf das Filesystem).

Also keine prinzipiellen Unterschiede. In allen Fällen hängt es von der
Umgebung (Interpreter, Betriebssystem, Hardware) ab, was ein Programm
tun kann.

Post by Arno Welzel
Deswegen würde man auch die Ausführung von Pyhton-Scripten, die der
Benutzer selber beschreiben darf, nicht zulassen, wenn man Sicherheit
ernstnmmt.

Diese Einstellung finde ich sehr bedauerlich. Der Benutzer wird damit
zum Knöpferldrücker degradiert, der das Potential eines Geräts, dessen
Stärke darin liegt, repetitive Aufgaben zu automatisieren, nicht
ausnützen kann. Das ist der hehren Klasse der Programmierer vorbehalten.

hp

Arno Welzel

2022-08-08 15:48:05 UTC

[...]

Post by Arno Welzel
Deswegen würde man auch die Ausführung von Pyhton-Scripten, die der
Benutzer selber beschreiben darf, nicht zulassen, wenn man Sicherheit
ernstnmmt.

Korrekt! Genau das *SOLL* auch so sein, wenn SICHERHEIT im Vordergrund
steht!

Du willst ganz sicher nicht, dass z.B. Mitarbeiter einer Bank, eines
Arztes oder eines Krankenhauses auf dem Computer, der als Arbeitsmittel
dient, irgendwelche Scripte ausführt, nur weil ihm die Arbeit mit der
von der bereitgestellten Software zu umständlich ist. Genau dabei könnte
selbst ohne Malware auch viel schief laufen, wenn der jeweilige Mensch
nicht genau aufpasst, dass seine "Automatisierung" nicht versehentlich
irgend einen Mist baut.

--
Arno Welzel
https://arnowelzel.de

Peter J. Holzer

2022-08-08 21:53:45 UTC

Post by Arno Welzel
Deswegen würde man auch die Ausführung von Pyhton-Scripten, die der
Benutzer selber beschreiben darf, nicht zulassen, wenn man Sicherheit
ernstnmmt.

Zwei Seelen wohnen ach in meiner Brust. Einerseits ist der Wildwuchs an
von Usern geschriebenen Scripts (sprich: Excel-Files und
Access-Datenbanken) in vielen Betrieben tatsächlich ein Problem.
Andererseits ist der Mangel an Automatisierung auch eines - repetitive
Handlungen sind nicht nur geisttötend sondern auch fehleranfällig. Die
Lösung besteht vermutlich in mehr und nicht weniger.

Post by Arno Welzel
Genau dabei könnte selbst ohne Malware auch viel schief laufen, wenn
der jeweilige Mensch nicht genau aufpasst, dass seine
"Automatisierung" nicht versehentlich irgend einen Mist baut.

Die baut dann wenigstens reproduzierbar Mist. Der Mensch hingegen
zufällig.

hp

Arno Welzel

2022-08-09 13:33:17 UTC

[...]

Post by Arno Welzel
Du willst ganz sicher nicht, dass z.B. Mitarbeiter einer Bank, eines
Arztes oder eines Krankenhauses auf dem Computer, der als Arbeitsmittel
dient, irgendwelche Scripte ausführt, nur weil ihm die Arbeit mit der
von der bereitgestellten Software zu umständlich ist.

Wenn bei täglichen Aufgaben immer wieder Dinge gemacht werden, die man
auch automatisieren könnte, wäre es Aufgabe der Verwantwortlichen, genau
dafür zu sorgen, um dadurch verursachte Fehler zu vermeiden.

Die baut dann wenigstens reproduzierbar Mist. Der Mensch hingegen
zufällig.

Ich arbeite selber seit gut 30 Jahren in der Softwareentwicklung -
"reproduzierbar" gilt nur, wenn auch die Umstände genau bekannt sind. Ob
ein von einem reinen Anwender selbst gebautes Script immer für alle
Fälle hinreichend getestet ist, wage ich zu bezweifeln. Dann ist das
Ergebnis im Fehlerfall mitunter auch "zufällig", weil niemand genau
weiß, unter welchem Umständen ein Script fehlerhaft arbeitet.

--
Arno Welzel
https://arnowelzel.de

Peter J. Holzer

2022-08-09 20:40:39 UTC

Skaliert halt nicht. Und die Leute machen was auch immer notwendig ist,
um den Job zu erledigen. Wenn man ihnen geeignete Werkzeuge verweigert,
verwenden sie halt ungeeignete (oder verabschieden sich in die "innere
Emigration", wie das ein Kollege mal genannt hat).

Die baut dann wenigstens reproduzierbar Mist. Der Mensch hingegen
zufällig.

Ich arbeite selber seit gut 30 Jahren in der Softwareentwicklung -

Ähnlich. Und fast 30 Jahre Systemadministration (gleichzeitig, nicht
hintereinander - der Schwerpunkt hat sich im Lauf der Zeit geändert).

Post by Arno Welzel
"reproduzierbar" gilt nur, wenn auch die Umstände genau bekannt sind. Ob
ein von einem reinen Anwender selbst gebautes Script immer für alle
Fälle hinreichend getestet ist, wage ich zu bezweifeln.

Natürlich nicht.

Post by Arno Welzel
Dann ist das Ergebnis im Fehlerfall mitunter auch "zufällig", weil
niemand genau weiß, unter welchem Umständen ein Script fehlerhaft
arbeitet.

Es lässt sich zumindest nachvollziehen, was passiert ist. Im Gegensatz
zu "ich habe gar nichts gemacht" oder "ich habe sicher X, Y und Z in
dieser Reihenfolge gemacht und es gab keine Fehlermeldung".
Kein Vorwurf. Passiert mir auch gelegentlich, dass sich die
Shell-History nicht mir meiner Erinnerung deckt, oder dass da drei
Kommandos weiter oben eine Fehlermeldung prangt, die ich absolut nicht
wahrgenommen habe. (Und ja, die täglichen Cron-Jobs, bei denen ein
halbes Jahr lang niemandem auffällt, dass sie nicht mehr funktionieren,
gibt es natürlich auch - Automatisierung hilft nicht immer.)

hp

Arno Welzel

2022-08-11 16:16:54 UTC

[...]

Post by Arno Welzel
Dann ist das Ergebnis im Fehlerfall mitunter auch "zufällig", weil
niemand genau weiß, unter welchem Umständen ein Script fehlerhaft
arbeitet.

Nö. Dann wird halt gesagt "ich habe Script X benutzt, hat sonst immer
funktioniert".

Und das selbe Script X nochmal auszuführen, zeigt den Fehler aber eben
nicht erneut, weil die vom Script angefassten Daten bereits verändert
wurden und daher der Fehler nicht mehr reproduzierbar ist. Welche Daten
vorher vorlagen, weiß der Anwender aber nicht mehr, weil er ja ein
Script dafür hat, damit er eben *nicht* die Daten selber anfassen muss.

--
Arno Welzel
https://arnowelzel.de

Martin Gerdes

2022-08-06 13:45:17 UTC

Post by Andreas Kohlbach
Ich würde Chromium (oder jede andere Software) nur von Originalseiten
herunterladen.

ACK.

Die meisten User wären unglücklich, wenn sie ihre Excel-Files nicht
selbst beschreiben dürften.

Die meisten Netizens wären unglücklich, wenn sie keine Haare mehr
spalten dürften.

Post by Peter J. Holzer
Ja, ein Excel-File ist ein Programm.

Nein, natürlich nicht. Es ist denkbar, daß eine Excel-Datei aktive
Inhalte enthält (meine tun das sämtlich nicht), aber zwingend ist das
nicht.

Post by Peter J. Holzer
Es gibt keinen prinzipiellen Unterschied zwischen einem Excel-File
und einem Python-Script.

Rechtevergabe war noch nie trivial.

Post by Peter J. Holzer
Das mit der Trennung von Programmen und Nicht-Programmen ist nicht so
einfach.

Stimmt. Wenn man allerdings vorab die Dateien blockiert, die eindeutig
Programme sind, ist damit schonmal ein Gutteil der Gefährdung abgedeckt.

Peter J. Holzer

2022-08-06 19:37:32 UTC

Post by Peter J. Holzer
Ja, ein Excel-File ist ein Programm.

Nein, natürlich nicht. Es ist denkbar, daß eine Excel-Datei aktive
Inhalte enthält (meine tun das sämtlich nicht), aber zwingend ist das
nicht.

Ein Excel-File ist vom Prinzip her ein Programm. Jede Zelle enthält
ausführbaren Code. Der Code mag nur langweilige Sachen machen wie die
Summe von zwei anderen Zellen berechnen, aber Du kannst auch in Python
ein Programm schreiben, das nur
print(1+2)
enthält, und niemand wird behaupten, dass das kein Programm sei.

Du kannst jetzt einwenden, dass damit ja nur die Inhalte des Excel-Files
selbst geändert werden können, aber auch eine Turing-Maschine kann nur
ihr eigenes Band beschreiben. Das ist also kein Kriterium, um zwischen
Programmen und Nicht-Programmen zu unterscheiden.

(Und wenn wir von Turing-Maschinen sprechen: Excel war lange Zeit nicht
turing-vollständig (ein Merkmal "richtiger" Programmiersprachen, wenn
auch IMHO ein eher theoretisches), diese Lücke wurde aber wenn ich mich
recht erinnere vor etlichen Jahren durch die Einführung rekursiver
Funktionen geschlossen.)

hp

Lars Gebauer

2022-08-06 20:24:00 UTC

Post by Peter J. Holzer
Ja, ein Excel-File ist ein Programm.

Nein, natürlich nicht. Es ist denkbar, daß eine Excel-Datei aktive
Inhalte enthält (meine tun das sämtlich nicht), aber zwingend ist das
nicht.

Ein Excel-File ist vom Prinzip her ein Programm.

Nein. Mit einem Excel-File wird der Excel-Interpreter parametrisiert.
Das macht das File noch langer nicht zum Programm.

Post by Peter J. Holzer
Jede Zelle enthält ausführbaren Code.

Der ohne den Interpreter überhaupt nichts macht.

Post by Peter J. Holzer
Der Code mag nur langweilige Sachen machen wie die
Summe von zwei anderen Zellen berechnen, aber Du kannst auch in Python
ein Programm schreiben, das nur
print(1+2)
enthält, und niemand wird behaupten, dass das kein Programm sei.

Doch, ich.

Auch das Python-Skript ist kein Programm. Es mag umgangssprachlich so
genannt werden - ist aber trotzdem keins.

Das Skript entält lediglich eine Reihe von Anweisungen die den
Python-Interpreter dazu bewegen, irgendwas zu tun. So, wie das
Excel-File. Ohne Interpreter sind beide nutzlos.

Goethes Faust als ASCII-File ist auch kein Programm. Ebenso wenig, wie
Schillers Glocke. Aber mit beiden kann der Text-Betrachter/Editor (=
Interpreter) zu irgendwas bewegt (= parametrisiert) werden. Den Text am
Bildschirm anzuzeigen, bspw. Oder ihn an den Drucker zu schicken.

Mit Goethes Faust als html geht das sogar in hübsch. Aber weder das html
noch das dazugehörige css sind Programme. Der Browser, der den Kram
interpretiert, der ist das Programm. Füge ich zum Faust noch etwas
Javascript hinzu, wirds immer noch kein Programm. Lediglich der Browser
bekommt mehr zum Interpretieren.

Meine Kamera erzeugt keine Programme - sondern .jpgs. Mit diesen
wiederum kann der Bildbetrachter parametrisiert werden, so daß am
Bildschirm ein Bild angezeigt wird.

Umgangssprachlich mag man Python-, Javascript-, Perl- und was weiß ich
-Skripte als Programme bezeichnen. Ist auch kein Problem weil allgemein
klar ist, was gemeint ist. Dennoch dienen die nur dazu, Programme zu
parametrisieren.

--
"Nein, ich habe keine Angst vor der Klimakrise, also vor der Zukunft.
Wir sind ja mittendrin. Es ist doch nicht so, dass die Welt eine ganz
andere sein wird, sobald wir 1,5 Grad Erderhitzung erreichen."
--Friederike Otto

Laurenz Trossel

2022-08-06 21:02:58 UTC

Post by Lars Gebauer
Meine Kamera erzeugt keine Programme - sondern .jpgs. Mit diesen
wiederum kann der Bildbetrachter parametrisiert werden, so daß am
Bildschirm ein Bild angezeigt wird.

.. oder das enthaltene Programm ausgeführt wird.

https://www.securityweek.com/google-says-nso-pegasus-zero-click-most-technically-sophisticated-exploit-ever-seen

Peter J. Holzer

2022-08-07 07:11:29 UTC

Post by Lars Gebauer
Auch das Python-Skript ist kein Programm. Es mag umgangssprachlich so
genannt werden - ist aber trotzdem keins.
Das Skript entält lediglich eine Reihe von Anweisungen die den
Python-Interpreter dazu bewegen, irgendwas zu tun. So, wie das
Excel-File. Ohne Interpreter sind beide nutzlos.

Ohne Interpreter ist jedes Programm nutzlos. Auch ein x86-Binary tut
ohne Interpreter (Prozessor oder Emulator) gar nichts.

Ich empfehle Andrew S. Tanenbaum: "Structured Computer Organization"
(1976) zu diesem Thema.

hp

Lars Gebauer

2022-08-07 08:01:47 UTC

Ohne Interpreter ist jedes Programm nutzlos.

Eben. Aber weder Goethes Faust noch Schillers Handschuh sind Programme.
Obwohl sie sich in ihrer Wirkungsweise auf den Interpreter kaum vom
Python-Skript unterscheiden.

Peter J. Holzer

2022-08-07 11:50:09 UTC

Ohne Interpreter ist jedes Programm nutzlos.

Eben. Aber weder Goethes Faust noch Schillers Handschuh sind Programme.

Richtig.

Post by Lars Gebauer
Obwohl sie sich in ihrer Wirkungsweise auf den Interpreter kaum vom
Python-Skript unterscheiden.

Aber nicht deswegen (auch ein Binary Executable unterscheidet sich in
seiner Wirkungsweise auf den Prozessor nicht wesentlich.)

Ein Programm ist ein in einer Programmiersprache notierter Algorithmus.

Faust und Handschuh spezifizieren aber keinen Algorithmus[1], und sie
sind in keiner Programmiersprache geschrieben. US-ASCII oder HTML sind
keine Programmiersprachen, weil sich in ihnen keine Algorithmen
beschreiben lassen (manche Leute sind noch strikter und verlangen, dass
eine Programmiersprache alle Algorithmen abbilden können muss - mir
reicht es, wenn es ein brauchbares Subset gibt). Maschinencode,
Assembler, C, Python, PostScript und Brainfuck sind zweifellos
Programmiersprachen, sogar turing-vollständige. Excel mag für manche das
Kriterium der Sprache nicht erfüllen, aber für jemanden, der mal ein
paar Theoretische-Informatik-Vorlesungen besucht hat, ist jedes
Fileformat eine formale Sprache, und man kann darin Algorithmen
spezifizieren, also ist es eine Programmiersprache (vielleicht nicht
turing-vollständig).

JavaScript ist ebenfalls eindeutig eine Programmiersprache. CSS ist ein
interessanter Grenzfall: Es wurde gezeigt, dass CSS ausreicht, um einen
Schritt einer Turing-Maschine zu implementieren. In einem Browser
braucht man dann noch einen externen Taktgeber (einen Menschen, der
immer auf den "Weiter"-Button klickt, oder ein JavaScript-Programm, das
das macht), aber eine Implementation, in der das automatisch passiert,
wäre leicht denkbar. Aber auch ohne das erlaubt CSS die Implementation
interessanter Algorithmen zur Transformation von HTML in gerenderten
Output. Im Zweifelsfall würde ich das daher auch als Programmiersprache
ansehen.

hp

[1] Jedenfalls für Informatiker. Ich überlasse es den
Theaterwissenschaftlern, ob sie den geschriebenen Text eines
Theaterstück als Algorithmus für die Schauspieler auffassen wollen.

Lars Gebauer

2022-08-07 14:21:35 UTC

Post by Peter J. Holzer
Ein Programm ist ein in einer Programmiersprache notierter Algorithmus.

Nö. Das mag man ja umgangssprachlich "Programm" nennen - aber streng
genommen ist es nur ein Notat, oft irgendein Skript.

Ich könnte auch jede Interpreter-Anweisung einzeln interaktiv an der
Konsole eingeben.

Aber a) würde ich beizeiten die Übersicht verlieren, b) wäre das ein
sehr fehlerträchtiges Verfahren, c) würde das viel zu lange dauern und
d) würde ich mich der Möglichkeit der Wiederverwendung berauben.

Deswegen macht man das nur bei sehr kleinen, sehr wenig komplexen und
vergleichsweise sehr selten vorkommenden Aufgaben.

Deswegen ist es allermeist viel sinnvoller, sämtliche Anweisungen zu
notieren[sic!] und dieses Notat dem Interpreter zu Abarbeitung en bloc
zu übergeben.

Post by Peter J. Holzer
Faust und Handschuh spezifizieren aber keinen Algorithmus[1], und sie
sind in keiner Programmiersprache geschrieben. US-ASCII oder HTML sind
keine Programmiersprachen, weil sich in ihnen keine Algorithmen
beschreiben lassen (manche Leute sind noch strikter und verlangen, dass
eine Programmiersprache alle Algorithmen abbilden können muss - mir
reicht es, wenn es ein brauchbares Subset gibt).

Ich habe auch nie behauptet, daß es Programme wären. Obwohl ich es
könnte, würde ich Deine Definition akzeptieren. Aber nach Deiner
Definition gäbe es ja nur und ausschließlich Programme - weswegen ich
die für wenig sinnvoll halte.

Der Interpreter, der ist das Programm. Alles andere - Notat, Skript,
Quellcode, Excel-File etc.pp. - parametrisiert lediglich dieses Programm
und ist ohne dieses Programm wertlos.

Peter J. Holzer

2022-08-07 16:19:21 UTC

Post by Peter J. Holzer
Ein Programm ist ein in einer Programmiersprache notierter Algorithmus.

Nö. Das mag man ja umgangssprachlich "Programm" nennen - aber streng
genommen ist es nur ein Notat, oft irgendein Skript.

Nach deiner Privat-Definition. Mag sein. Du kennst die Geschichte "Ein
Tisch ist ein Tisch" von Peter Bichsel?

hp

Lars Gebauer

2022-08-07 16:51:31 UTC

Post by Peter J. Holzer
Ein Programm ist ein in einer Programmiersprache notierter Algorithmus.

Nö. Das mag man ja umgangssprachlich "Programm" nennen - aber streng
genommen ist es nur ein Notat, oft irgendein Skript.

Nach deiner Privat-Definition. Mag sein. Du kennst die Geschichte "Ein
Tisch ist ein Tisch" von Peter Bichsel?

Nein.

Arno Welzel

2022-08-11 16:22:24 UTC

[...]

Doch, ich.
Auch das Python-Skript ist kein Programm. Es mag umgangssprachlich so
genannt werden - ist aber trotzdem keins.

Es ist.

Post by Lars Gebauer
Das Skript entält lediglich eine Reihe von Anweisungen die den
Python-Interpreter dazu bewegen, irgendwas zu tun. So, wie das
Excel-File. Ohne Interpreter sind beide nutzlos.

In bei Binaries ist eben die CPU der Interpreter. Oftmals nicht mal das,
weil die vermeintlichen "Binaries" tatsächlich Bytecode einer Runtime
wie C# oder Java sind, die aber vollen Zugriff auf das System-API hat
und damit genauso viel Schaden anrichten kann, wie ein "echtes" Binary.

Umgekehrt kann man auch "echte" Binaries in eine Sandbox stecken und den
Zugriff auf Daten außerhalb der Sandbox einschränken.

Der entscheidende Punkt ist, ob man es *vorgesehen* ist, mit den
Anweisungen Daten außerhalb der ausführenden Anwendung zu beeinflussen.
Ob das dann mit einem "echten" Binary passiert oder "nur" mit einem
Script, macht im Ergebnis keinen Unterschied.

--
Arno Welzel
https://arnowelzel.de

Lars Gebauer

2022-08-11 18:27:59 UTC

Doch, ich.
Auch das Python-Skript ist kein Programm. Es mag umgangssprachlich so
genannt werden - ist aber trotzdem keins.

Es ist.

Wie schon geschrieben: Dann ist jede Trennung Daten vs. Programme
aufgehoben. Meine Kamera erzeugt dann keine Bilder mehr sondern kleine
Programme. Jeder Knipser wird so zum Programmierer.

Arno Welzel

2022-08-12 15:29:21 UTC

Doch, ich.
Auch das Python-Skript ist kein Programm. Es mag umgangssprachlich so
genannt werden - ist aber trotzdem keins.

Es ist.

Wie schon geschrieben: Dann ist jede Trennung Daten vs. Programme
aufgehoben. Meine Kamera erzeugt dann keine Bilder mehr sondern kleine
Programme. Jeder Knipser wird so zum Programmierer.

Du scheinst eine sehr eigenwillige Auffassung zu haben, was
"Programmiersprache" bedeutet.

Die Bilder denier Kamera enthalten ja keine Befehle sondern nur die
Information zur Repräsentation von Bildern. Damit kannst Du weder
Dateien erzeugen lassen noch Programme starten.

Python dagegen besteht aus konkreten Befehlen, was der Computer tun
soll, was auch das Lesen und Schreiben von Dateien oder den Start
anderer Programme beinhaltet. Dass ein Interpreter nötig ist, damit der
Computer dieser Befehle ausführen kann, ändert nichts daran, dass es
dennoch ein Programm ist.

Andernfalls müsstest Du auch sagen, dass Programme mit Binärcode für
eine bestimmte CPU-Architektur keine Programme sind, weil sie auf einer
anderen CPU-Architektur nicht ausführbar sind ohne Emulation.

Alles, was mit einer Programmiersprache erstellt wird, ist ein Programm.
Und auch Python ist eine Progammiersprache. Ob zur Ausführung des
Programms der Quelltext compiliert oder interpretiert wird, ist dafür
völlig unterheblich. Das legt nur die Form fest, in der das Programm
vorliegt - eben als Quelltext, Bytecode oder Binary.

Auf mobilen Plattformen wie Android sind echte Binaries eher die
Ausnahme. Java und Kotlin erzeugen Bytecode - und das will man da auch
so, damit man nicht für jede CPU-Architektur ein angepasstes Binary
bereitstellen muss.

--
Arno Welzel
https://arnowelzel.de

Lars Gebauer

2022-08-12 16:23:15 UTC

Doch, ich.
Auch das Python-Skript ist kein Programm. Es mag umgangssprachlich so
genannt werden - ist aber trotzdem keins.

Es ist.

Wie schon geschrieben: Dann ist jede Trennung Daten vs. Programme
aufgehoben. Meine Kamera erzeugt dann keine Bilder mehr sondern kleine
Programme. Jeder Knipser wird so zum Programmierer.

Du scheinst eine sehr eigenwillige Auffassung zu haben, was
"Programmiersprache" bedeutet.

Äh, nein. :)

Es ging um Programme vs. Daten. Und meine Auffassung läuft darauf
hinaus, daß Daten Programme parametrisieren, selbst aber keine Programme
sind.

Die jpgs aus meiner Kamera parametrisieren den Bildbetrachter, der dann
ein Bild am Monitor anzeigt. Hierzu interpretiert der Bildbetrachter die
von der Kamera gelieferten Daten.

Mit Programmier*sprachen* hat das soviel erst mal nichts zu tun. (Bitte
keine (dümmliche) Ablenkerei probieren.)

Arno Welzel

2022-08-16 11:40:42 UTC

Doch, ich.
Auch das Python-Skript ist kein Programm. Es mag umgangssprachlich so
genannt werden - ist aber trotzdem keins.

Es ist.

Wie schon geschrieben: Dann ist jede Trennung Daten vs. Programme
aufgehoben. Meine Kamera erzeugt dann keine Bilder mehr sondern kleine
Programme. Jeder Knipser wird so zum Programmierer.

Du scheinst eine sehr eigenwillige Auffassung zu haben, was
"Programmiersprache" bedeutet.

Äh, nein. :)
Es ging um Programme vs. Daten. Und meine Auffassung läuft darauf
hinaus, daß Daten Programme parametrisieren, selbst aber keine Programme
sind.

Ein Python-Script ist aber ein Programm und keine "Daten". Und nein,
auch wenn ein Programm in Form eines Textes mit geschrieben Befehlen
vorliegt, ist es immer noch ein Programm.

Abgesehen davon ist die strikte Trennung des Arbeitsspeichers einers
Computers in Programm- und Datenspeicher schon seit mehreren Jahrzehnten
nicht mehr üblich. Statt dessen kennzeichnet man nur Teile des
Speicherhinhalt als "nicht ausführbar" für die CPU. Weiterhin ist auch
die Ausführung von einem Binärcode durch eine hartverdrahtete CPU auch
schon seit Jahrzehnten nicht mehr üblich. Verwendet wird Microcode, der
x86-Befehle interpretiert. Deiner Lesart nach, wären dann auch
x86-Binaries keine Programme, sondern nur Daten, die erst durch die CPU
interpretiert und durch Microcode ausgeführt wird.

Post by Lars Gebauer
Die jpgs aus meiner Kamera parametrisieren den Bildbetrachter, der dann
ein Bild am Monitor anzeigt. Hierzu interpretiert der Bildbetrachter die
von der Kamera gelieferten Daten.

Nein, Bilddaten sind auch keine "Parameter", sondern einfach nur Daten.

Post by Lars Gebauer
Mit Programmier*sprachen* hat das soviel erst mal nichts zu tun. (Bitte
keine (dümmliche) Ablenkerei probieren.)

Mit der dümmlichen Ablenkerei hast *Du* angefangen.

--
Arno Welzel
https://arnowelzel.de

Lars Gebauer

2022-08-16 13:21:57 UTC

Post by Lars Gebauer
Es ging um Programme vs. Daten. Und meine Auffassung läuft darauf
hinaus, daß Daten Programme parametrisieren, selbst aber keine Programme
sind.

Ein Python-Script ist aber ein Programm und keine "Daten". Und nein,
auch wenn ein Programm in Form eines Textes mit geschrieben Befehlen
vorliegt, ist es immer noch ein Programm.

Jetzt hast Du aber tüchtig mit dem Fuß aufgestampft. Ich bin beeindruckt!

Aber gut: Dann produziert meine Kamera eben lauter Programme. Kann ich
mit leben, ist mir nicht so wichtig.

Nein, Bilddaten sind auch keine "Parameter", sondern einfach nur Daten.

Ja, Daten die ein Programm parametrisieren. So, wie ein Python-Skript.

--
"Das Problem ist nicht, dass eine relativ kleine Gruppe von Verrückten
behauptet, dass zwei plus zwei fünf ergibt, dass es zwölf verschiedene
Geschlechter gibt oder dass man bei der Energieversorgung die Gesetze
der Thermodynamik ignorieren kann. Das Problem ist, daß sich die große
Gruppe der Normalos künstlich dumm stellt und den selben Quatsch
behauptet, weil sie von den Verrückten nicht als verrückt bezeichnet
werden wollen."
--Vince Ebert

Arno Welzel

2022-08-17 12:56:22 UTC

Post by Lars Gebauer
Es ging um Programme vs. Daten. Und meine Auffassung läuft darauf
hinaus, daß Daten Programme parametrisieren, selbst aber keine Programme
sind.

Ein Python-Script ist aber ein Programm und keine "Daten". Und nein,
auch wenn ein Programm in Form eines Textes mit geschrieben Befehlen
vorliegt, ist es immer noch ein Programm.

Jetzt hast Du aber tüchtig mit dem Fuß aufgestampft. Ich bin beeindruckt!
Aber gut: Dann produziert meine Kamera eben lauter Programme. Kann ich
mit leben, ist mir nicht so wichtig.

Jetzt hast Du deine Ignoranz endgültig demonstriert. Dann eben nicht.

Nein, Bilddaten sind auch keine "Parameter", sondern einfach nur Daten.

Ja, Daten die ein Programm parametrisieren. So, wie ein Python-Skript.

Nein, ein Python-Skript "parametrisiert" exakt gar nichts. Das *ist* ein
Programm.

Wenn Du etablierte Begrifflichkeiten der Informatik nicht magst, auch
gut. Aber bitte höre auf, so einen hochgradigen Unsinn zu verbreiten.

--
Arno Welzel
https://arnowelzel.de

Lars Gebauer

2022-08-17 14:55:01 UTC

Post by Lars Gebauer
Es ging um Programme vs. Daten. Und meine Auffassung läuft darauf
hinaus, daß Daten Programme parametrisieren, selbst aber keine Programme
sind.

Ein Python-Script ist aber ein Programm und keine "Daten". Und nein,
auch wenn ein Programm in Form eines Textes mit geschrieben Befehlen
vorliegt, ist es immer noch ein Programm.

Jetzt hast Du aber tüchtig mit dem Fuß aufgestampft. Ich bin beeindruckt!
Aber gut: Dann produziert meine Kamera eben lauter Programme. Kann ich
mit leben, ist mir nicht so wichtig.

Jetzt hast Du deine Ignoranz endgültig demonstriert. Dann eben nicht.

Wenn ich Dir Recht gebe, nölst Du. Hast Du Probleme mit Dir selbst?

Nein, Bilddaten sind auch keine "Parameter", sondern einfach nur Daten.

Ja, Daten die ein Programm parametrisieren. So, wie ein Python-Skript.

Nein, ein Python-Skript "parametrisiert" exakt gar nichts.

Schon gar nicht den Python-Interpreter. Ist ja schon gut.

Arno Welzel

2022-08-20 00:58:47 UTC

Post by Lars Gebauer
Es ging um Programme vs. Daten. Und meine Auffassung läuft darauf
hinaus, daß Daten Programme parametrisieren, selbst aber keine Programme
sind.

Ein Python-Script ist aber ein Programm und keine "Daten". Und nein,
auch wenn ein Programm in Form eines Textes mit geschrieben Befehlen
vorliegt, ist es immer noch ein Programm.

Jetzt hast Du aber tüchtig mit dem Fuß aufgestampft. Ich bin beeindruckt!
Aber gut: Dann produziert meine Kamera eben lauter Programme. Kann ich
mit leben, ist mir nicht so wichtig.

Jetzt hast Du deine Ignoranz endgültig demonstriert. Dann eben nicht.

Wenn ich Dir Recht gebe, nölst Du. Hast Du Probleme mit Dir selbst?

Nein, Du hast mir nicht Recht gegeben. Ich habe nicht behauptet, dass
Bilddaten Programme wären.

Post by Arno Welzel
Nein, ein Python-Skript "parametrisiert" exakt gar nichts.

Schon gar nicht den Python-Interpreter. Ist ja schon gut.

Korrekt. Ein Interpreter wird durch Programmcode nicht parametrisiert,
sondern interpretritiert den Code. Deswegen nennt man das Ding auch
"Interpreter" und nicht "parametrisierbare Anwendung".

--
Arno Welzel
https://arnowelzel.de

Lars Gebauer

2022-08-20 06:23:20 UTC

Post by Lars Gebauer
Aber gut: Dann produziert meine Kamera eben lauter Programme. Kann ich
mit leben, ist mir nicht so wichtig.

Jetzt hast Du deine Ignoranz endgültig demonstriert. Dann eben nicht.

Wenn ich Dir Recht gebe, nölst Du. Hast Du Probleme mit Dir selbst?

Nein, Du hast mir nicht Recht gegeben. Ich habe nicht behauptet, dass
Bilddaten Programme wären.

Das ist aber die Konsequenz, wenn man Deiner Argumentation folgt.

Produziert Deine Argumentation Ergebnisse, die Dir nicht gefallen? Dann
solltest Du sie vielleicht überdenken.

Post by Arno Welzel
Nein, ein Python-Skript "parametrisiert" exakt gar nichts.

Schon gar nicht den Python-Interpreter. Ist ja schon gut.

Korrekt. Ein Interpreter wird durch Programmcode nicht parametrisiert,

Richtig. Da werden keinerlei Parameter wie Konstanten oder Variablen
übergeben.

Post by Arno Welzel
sondern interpretritiert den Code.

So, wie ein Bildinterpreter.

Peter J. Holzer

2022-08-20 07:25:46 UTC

Post by Lars Gebauer
Aber gut: Dann produziert meine Kamera eben lauter Programme. Kann ich
mit leben, ist mir nicht so wichtig.

Jetzt hast Du deine Ignoranz endgültig demonstriert. Dann eben nicht.

Wenn ich Dir Recht gebe, nölst Du. Hast Du Probleme mit Dir selbst?

Nein, Du hast mir nicht Recht gegeben. Ich habe nicht behauptet, dass
Bilddaten Programme wären.

Das ist aber die Konsequenz, wenn man Deiner Argumentation folgt.

Nein. Nur wenn man deiner Dichotomie folgt:

Entweder:
1) Programme und Daten sind fundamental unterschiedlich. Etwas ist
entweder Daten oder Programm
oder:
2) Daten und Programme sind das gleiche. Alle Daten sind Programme und
umgekehrt,

Aber warum sollte man das tun? Das wäre, wie wenn man argumentieren
würde, dass Forellen keine Fische sein können, weil sonst alle Fische
Forellen wären.

Programme sind Daten[1], aber nicht die einzigen Daten.

Post by Arno Welzel
sondern interpretritiert den Code.

So, wie ein Bildinterpreter.

Es gibt Programme, die verarbeiten Bilder und es gibt welche, die
verarbeiten Töne. Heißt das, dass Bilder Töne sind? Nein. Bilder sind
eine andere Art von Daten als Töne. Programme sind wieder eine andere
und es gibt noch hunderte weitere.

(Es gibt natürlich auch Überschneidungen: PostScript z.B. ist eine
Programmiersprache. Aber sehr wenige Leute verwenden sie, um beliebige
Anwendungen zu schreiben, die allermeisten PostScript-Programme
produzieren fixen, graphischen Output)

hp

[1] Ich verwende "Daten" hier sehr weit. Ein Programm ist auch ein
Programm, wenn es auf Papier gedruckt oder mit Kreide auf eine Tafel
geschrieben ist.

Lars Gebauer

2022-08-20 09:06:03 UTC

Post by Arno Welzel
Nein, Du hast mir nicht Recht gegeben. Ich habe nicht behauptet, dass
Bilddaten Programme wären.

Das ist aber die Konsequenz, wenn man Deiner Argumentation folgt.

1) Programme und Daten sind fundamental unterschiedlich. Etwas ist
entweder Daten oder Programm
2) Daten und Programme sind das gleiche. Alle Daten sind Programme und
umgekehrt,
Aber warum sollte man das tun?

Genau das. Ich frage mich schon die ganze Zeit, warum Ihr das tut.

Ausgangspunkt war Deine Behauptung, daß ein Excel-File ein Programm sei,
genauso wie ein Python-Skript. Und daß das wohl "niemand bezweifeln" würde.

Mal ganz davon abgesehen, daß derartige Aussagen ("wird niemand
bezweifeln") häufig nur den Auftakt zu gröberem Unfug darstellen, kann
es ja durchaus sein, daß Du Recht hast.

Dann aber drängt sich (mir zumindest) die Frage auf, worin sich
eigentlich das Excel-File oder das Python-Skipt von einer Text-, Bild-
oder sonstigen Datei unterscheiden. Schließlich enthalten alle diese
Files lediglich Daten, die durch einen Interpreter weiter verarbeitet
werden, mithin also den Interpreter parametrisieren. Da ist dann einfach
kein erkennbarer Unterschied.

Diese Frage konnten bisher weder Du noch Arno schlüssig beantworten.
Außer "isso, fußaufstampf" kam da bisher nichts. Mag ja sein, daß diese
Erklärung für Dich und Arno völlig ausreichend ist - bei mir ezeugt sie
eher Belustigung.

Post by Peter J. Holzer
Das wäre, wie wenn man argumentieren
würde, dass Forellen keine Fische sein können, weil sonst alle Fische
Forellen wären.

Zwischen einer Forelle und einem Karpfen gibt es erkenn- und benennbare
Unterschiede.

Bei Programmen und Daten gibt es (für mich) diese Unterschiede
ebenfalls: Programme interpretieren und verarbeiten Daten. Aber nicht
umgekehrt.

Folglich interpretieren und verarbeiten Bildinterpreter Bild-Files.
Folglich interpretieren und verarbeiten Textinterpreter Text-Files.
Folglich interpretieren und verarbeiten Excelinterpreter Excel-Files.

...

Folglich interpretieren und verarbeiten Pythoninterpreter Python-Files.

Folglich bestehen zwischen Python-, Excel-, Text- und Bild-Files
insofern keine Unterschiede. Daß manche dieser Daten-Files komplexer
aufgebaut sind als andere, kann ja sein. Aber das ist nur ein
quantitativer und kein qualitativer Unterschied.

Post by Peter J. Holzer
Es gibt Programme, die verarbeiten Bilder und es gibt welche, die
verarbeiten Töne.

Und es gibt Programme, die verarbeiten Python-Skripte.

Post by Peter J. Holzer
Heißt das, dass Bilder Töne sind?

Macht das daß Skript zu einem Programm?

Peter J. Holzer

2022-08-20 10:36:00 UTC

Post by Arno Welzel
Nein, Du hast mir nicht Recht gegeben. Ich habe nicht behauptet, dass
Bilddaten Programme wären.

Das ist aber die Konsequenz, wenn man Deiner Argumentation folgt.

Genau das. Ich frage mich schon die ganze Zeit, warum Ihr das tut.

Wir tun es eh nicht. Du erwartest offenbar von uns, dass wir es tun
sollen und bist irritiert, dass wir nicht zum dem Schluss gelangen, zu
dem das führen würde.

Post by Lars Gebauer
Ausgangspunkt war Deine Behauptung, daß ein Excel-File ein Programm sei,
genauso wie ein Python-Skript. Und daß das wohl "niemand bezweifeln" würde.
Mal ganz davon abgesehen, daß derartige Aussagen ("wird niemand
bezweifeln") häufig nur den Auftakt zu gröberem Unfug darstellen, kann
es ja durchaus sein, daß Du Recht hast.
Dann aber drängt sich (mir zumindest) die Frage auf, worin sich
eigentlich das Excel-File oder das Python-Skipt von einer Text-, Bild-
oder sonstigen Datei unterscheiden.

Im Zweck. Eine Bild-Datei repräsentiert ein Bild. Eine Sound-Datei eine
Folge von Geräuschen. Eine Programm-Datei ein Programm.

Auf der untersten Ebene sind alle nur Folgen von Bytes und haben absolut
keine intrinsische Bedeutung. Die bekommen sie erst dadurch, dass sie
verarbeitet werden.

Post by Lars Gebauer
Schließlich enthalten alle diese Files lediglich Daten, die durch
einen Interpreter weiter verarbeitet werden, mithin also den
Interpreter parametrisieren. Da ist dann einfach kein erkennbarer
Unterschied.

Selbes gilt für Exe-Files. Die "parametrisieren" (ich glaube, Du
verwendest das Wort auch etwas anders als üblich) nur den in der CPU
eingebauten Interpreter (typischerweise als Mischung von Microcode (ein
Programm!) und festverdrahteter Hardware implementiert).

Post by Lars Gebauer
Diese Frage konnten bisher weder Du noch Arno schlüssig beantworten.
Außer "isso, fußaufstampf" kam da bisher nichts. Mag ja sein, daß diese
Erklärung für Dich und Arno völlig ausreichend ist - bei mir ezeugt sie
eher Belustigung.

Immerhin habe ich eine Definiton gepostet, was ein Programm ist. Von Dir
habe ich sowas bisher noch nicht gelesen (vielleicht habe ich es
übersehen), nur die wiederholte Behauptungen, was alles kein Programm
sei, und die Abqualifizierung der üblichen Bedeutung von "Programm" als
"umgangssprachlich".

Post by Peter J. Holzer
Das wäre, wie wenn man argumentieren würde, dass Forellen keine
Fische sein können, weil sonst alle Fische Forellen wären.

Zwischen einer Forelle und einem Karpfen gibt es erkenn- und benennbare
Unterschiede.

Ja, aber beides sind Fische. Du kannst nicht behaupten, wenn eine
Forelle ein Fisch ist, dann ist ein Karpfen auch eine Forelle. Das ist
einfach ein fundamentaler Logik-Fehler. Bei Deiner
Programm/Daten-Argumentation machst Du aber genau diesen Fehler (ein
bisschen versteckt dadurch, dass Du weder "Programm" noch "Daten" jemals
definiert hast und man somit (anders als bei "Forelle" und "Karpfen")
nicht sicher sein kann, wovon Du eigentlich redest (eigentlich kann ich
das bei Forelle und Karpfen auch nicht wissen - ich traue Dir durchaus
zu, dass Du da auch Privatdefinitionen hast)).

hp

Lars Gebauer

2022-08-20 11:34:08 UTC

Post by Peter J. Holzer
1) Programme und Daten sind fundamental unterschiedlich. Etwas ist
entweder Daten oder Programm
2) Daten und Programme sind das gleiche. Alle Daten sind Programme und
umgekehrt,
Aber warum sollte man das tun?

Genau das. Ich frage mich schon die ganze Zeit, warum Ihr das tut.

Wir tun es eh nicht.

Ich allerdings auch nicht. Deswegen gibt es ja "meine Dichotomie" gar nicht.

Post by Peter J. Holzer
Du erwartest offenbar von uns, dass wir es tun
sollen und bist irritiert, dass wir nicht zum dem Schluss gelangen, zu
dem das führen würde.

Nönö. Ich erwarte gar nichts.

Im Zweck.

Ach geh', das wird jetzt aber völlig humorisch. Dinge (auch
immaterielle) /haben/ keinen Zweck. Ein Zweck wird ihnen immer nur von
An-/Verwender gegeben.

Post by Peter J. Holzer
Eine Bild-Datei repräsentiert ein Bild. Eine Sound-Datei eine
Folge von Geräuschen. Eine Programm-Datei ein Programm.

:)

Dabei sollte man immer bedenken, daß die Zweckvergabe meist nur wenigen
Einschränkungen unterliegt und allgemein arg willkürlich ist.

Mithin ist dann ein Programm ein Programm wenn Du sagst, daß es ein
Programm sei. Soweit waren wir aber schon.

Selbes gilt für Exe-Files.

Natürlich: Programme können auch Programme verarbeiten. Aber Daten
können keine Programme verarbeiten.

Immerhin habe ich eine Definiton gepostet, was ein Programm ist.

Naja. :)

Post by Peter J. Holzer
Von Dir
habe ich sowas bisher noch nicht gelesen (vielleicht habe ich es
übersehen), nur die wiederholte Behauptungen, was alles kein Programm
sei,

Dann hast Du die Herleitung meiner Behauptung übersehen.

Auch in dem Posting, auf das Du hier gerade beantwortet hast, habe ich
versucht, das darzustellen.

Aber Du wolltest Dich damit nicht weiter auseinander setzen.

Post by Peter J. Holzer
und die Abqualifizierung der üblichen Bedeutung von "Programm" als
"umgangssprachlich".

Das hat überhaupt nichts mit Abqualifizierung zu tun sondern ist eine
einfache Erfahrungssache. Häufig werden Dinge als etwas bezeichnet, was
sie eigentlich gar nicht sind. Das ist gar nicht weiter schlimm sondern
dient der Vereinfachung.

Post by Peter J. Holzer
Das wäre, wie wenn man argumentieren würde, dass Forellen keine
Fische sein können, weil sonst alle Fische Forellen wären.

Zwischen einer Forelle und einem Karpfen gibt es erkenn- und benennbare
Unterschiede.

Ja, aber beides sind Fische. Du kannst nicht behaupten, wenn eine
Forelle ein Fisch ist, dann ist ein Karpfen auch eine Forelle.

Tue ich ja auch gar nicht.

Post by Peter J. Holzer
Das ist
einfach ein fundamentaler Logik-Fehler. Bei Deiner
Programm/Daten-Argumentation machst Du aber genau diesen Fehler (ein
bisschen versteckt dadurch, dass Du weder "Programm" noch "Daten" jemals
definiert hast

Doch, tat ich. In dem Teil des Postings, auf den Du nicht näher eingehen
wolltest.

Post by Peter J. Holzer
und man somit (anders als bei "Forelle" und "Karpfen")
nicht sicher sein kann, wovon Du eigentlich redest

Du wüßtest es, wenn Du den gelöschten Teil auch gelesen hättest.
Abgesehen davon, daß ich das auch hier nicht zum ersten Mal tat.

Takvorian

2022-08-21 13:12:13 UTC

Post by Peter J. Holzer
Immerhin habe ich eine Definiton gepostet, was ein Programm ist.

Die hier genügt nicht?
https://en.wikipedia.org/wiki/Computer_program

Peter J. Holzer

2022-08-22 13:25:44 UTC

Post by Peter J. Holzer
Immerhin habe ich eine Definiton gepostet, was ein Programm ist.

Die hier genügt nicht?
https://en.wikipedia.org/wiki/Computer_program

Das ist die, die ich in diesem Thread angeführt habe. Mir reicht sie
also offensichtlich. Lars nicht, aber seine Definiton wollte er uns
bisher nicht mitteilen. Wir wissen nur, dass Python-Programme nicht
darunterfallen.

hp

Arno Welzel

2022-08-21 15:00:01 UTC

Post by Arno Welzel
Nein, Du hast mir nicht Recht gegeben. Ich habe nicht behauptet, dass
Bilddaten Programme wären.

Das ist aber die Konsequenz, wenn man Deiner Argumentation folgt.

Genau das. Ich frage mich schon die ganze Zeit, warum Ihr das tut.

Das tue ich nicht!

Programme und Daten *SIND* fundamental unterschiedlich.

Deswegen ist ein Python-Script ein *Programm* und nicht nur "Daten".

Post by Lars Gebauer
Ausgangspunkt war Deine Behauptung, daß ein Excel-File ein Programm sei,
genauso wie ein Python-Skript. Und daß das wohl "niemand bezweifeln" würde.

Es kann sein, dass in einem Excel-File Makros enthalten sind, die in VBA
o.Ä. geschrieben sind - *das* sind dann zweifellos Programme.

Aber ein Excel-File ohne Makros ist zweifellos *kein* Programm!

Post by Lars Gebauer
Dann aber drängt sich (mir zumindest) die Frage auf, worin sich
eigentlich das Excel-File oder das Python-Skipt von einer Text-, Bild-
oder sonstigen Datei unterscheiden. Schließlich enthalten alle diese

Sie unterscheiden sich dadurch, wofür sie *vorgesehen* sind.

Ein Python-Skipt enthält Anweisungen in einer Programmiersprache.

Ein Excel-File - wenn man Makros mal außen vorlässt - dagegen nur Zahlen
und Formeln.

Post by Lars Gebauer
Files lediglich Daten, die durch einen Interpreter weiter verarbeitet
werden, mithin also den Interpreter parametrisieren. Da ist dann einfach
kein erkennbarer Unterschied.

Auf einem Computer wird *jedes* Programm interpretiert. Es ist völlig
egal, in welcher Form es vorliegt - es ist *immer* ein Interpreter
vorhanden, ggf. eben der Interpreter für x86-Befehle in der CPU, den der
Hersteller in Microcode geschrieben hat.

Dann definiere bitte, was FÜR DICH ein "Programm" ist und was "Daten".

--
Arno Welzel
https://arnowelzel.de

Lars Gebauer

2022-08-21 17:27:55 UTC

Post by Arno Welzel
Programme und Daten *SIND* fundamental unterschiedlich.

Schreibe ich doch schon die ganze Zeit.

Post by Arno Welzel
Deswegen ist ein Python-Script ein *Programm* und nicht nur "Daten".

Nein. /Deswegen/ nun ganz bestimmt nicht.

Post by Lars Gebauer
Ausgangspunkt war Deine Behauptung, daß ein Excel-File ein Programm sei,
genauso wie ein Python-Skript. Und daß das wohl "niemand bezweifeln" würde.

Es kann sein, dass in einem Excel-File Makros enthalten sind, die in VBA
o.Ä. geschrieben sind - *das* sind dann zweifellos Programme.

Genau das bezweifele ich schon die ganze Zeit. Ganz besonders bezweifele
ich das "zweifellos". Und bisher ist es weder Dir noch Peter gelungen,
mich davon zu überzeugen.

Post by Arno Welzel
Aber ein Excel-File ohne Makros ist zweifellos *kein* Programm!

Na, ob der Peter Dir das glaubt?

Sie unterscheiden sich dadurch, wofür sie *vorgesehen* sind.

Gewiß nicht. Eine Zweckbestimmung wird immer erst durch den
An-/Verwender gegeben und kann sehr willkürlich sein.

Post by Arno Welzel
Ein Python-Skipt enthält Anweisungen in einer Programmiersprache.

Richtig. Was es allerdings nicht zu einem Programm macht sondern nur den
Interpreter (= das Programm) parametrisiert.

Dann definiere bitte, was FÜR DICH ein "Programm" ist und was "Daten".

Bitte lies meine Postings. Insbesondere die, auf die Du antwortest.

Arno Welzel

2022-08-21 18:24:36 UTC

Post by Arno Welzel
Programme und Daten *SIND* fundamental unterschiedlich.

Schreibe ich doch schon die ganze Zeit.

Post by Arno Welzel
Deswegen ist ein Python-Script ein *Programm* und nicht nur "Daten".

Nein. /Deswegen/ nun ganz bestimmt nicht.

Post by Lars Gebauer
Ausgangspunkt war Deine Behauptung, daß ein Excel-File ein Programm sei,
genauso wie ein Python-Skript. Und daß das wohl "niemand bezweifeln" würde.

Es kann sein, dass in einem Excel-File Makros enthalten sind, die in VBA
o.Ä. geschrieben sind - *das* sind dann zweifellos Programme.

Genau das bezweifele ich schon die ganze Zeit. Ganz besonders bezweifele
ich das "zweifellos". Und bisher ist es weder Dir noch Peter gelungen,
mich davon zu überzeugen.

Na dann schau hier:

<https://docs.microsoft.com/de-de/office/vba/library-reference/concepts/getting-started-with-vba-in-office>

Ja, ich ahne schon - für Dich sind das sicher nur wieder Daten, die halt
speziell interpretiert werden.

Post by Arno Welzel
Aber ein Excel-File ohne Makros ist zweifellos *kein* Programm!

Na, ob der Peter Dir das glaubt?

Das ist mir egal.

Sie unterscheiden sich dadurch, wofür sie *vorgesehen* sind.

Gewiß nicht. Eine Zweckbestimmung wird immer erst durch den
An-/Verwender gegeben und kann sehr willkürlich sein.

Falsch. Die Zweckbestimmung legt sehr genau fest, wofür die Daten
vorgesehen ist. Ein Programm ist immer ein Programm, egal ob Du als
Anwender den Quelltext dazu ausdruckst oder es durch einen Interpreter
oder Compiler zur Ausführung bringst.

Genau deshalb gibt es für Shells die shebang-Zeilen, damit klar ist, wie
etwas in der Konsole ausgeführt werden soll. Für Dich als Nutzer ist es
daher völlig wurscht, ob die Eingabe eines Kommandos direkt ein Binary
startet.

Post by Arno Welzel
Ein Python-Skipt enthält Anweisungen in einer Programmiersprache.

Richtig. Was es allerdings nicht zu einem Programm macht sondern nur den
Interpreter (= das Programm) parametrisiert.

Wieder falsch. Das Python-Skipt *ist* das Programm.

Aber wenn für Dich "muss ein Interpreter ausführen" automatisch
bedeutet, dass etwas kein Programm mehr ist, dann gibt es keine
Programme! Denn *alles* was ein Computer ausführt muss *ausnahmslos*
*immer* interpretiert werden. Auch x86-Befehle müssen von der CPU
interpretiert werden.

[...]

Post by Arno Welzel
Dann definiere bitte, was FÜR DICH ein "Programm" ist und was "Daten".

Bitte lies meine Postings. Insbesondere die, auf die Du antwortest.

Habe ich. Ich habe keine Definition von Dir dafür gefunden. Kannst Du
mir die Message-ID nennen, wo Du das getan hast?

--
Arno Welzel
https://arnowelzel.de

Lars Gebauer

2022-08-21 19:27:45 UTC

Post by Arno Welzel
Es kann sein, dass in einem Excel-File Makros enthalten sind, die in VBA
o.Ä. geschrieben sind - *das* sind dann zweifellos Programme.

Genau das bezweifele ich schon die ganze Zeit. Ganz besonders bezweifele
ich das "zweifellos". Und bisher ist es weder Dir noch Peter gelungen,
mich davon zu überzeugen.

<https://docs.microsoft.com/de-de/office/vba/library-reference/concepts/getting-started-with-vba-in-office>
Ja, ich ahne schon - für Dich sind das sicher nur wieder Daten, die halt
speziell interpretiert werden.

Womit Du vollkommen Recht hast. Ich sehe, wir nähern uns der Sache an.

Sie unterscheiden sich dadurch, wofür sie *vorgesehen* sind.

Gewiß nicht. Eine Zweckbestimmung wird immer erst durch den
An-/Verwender gegeben und kann sehr willkürlich sein.

Falsch.

Nein.

Post by Arno Welzel
Die Zweckbestimmung legt sehr genau fest, wofür die Daten
vorgesehen ist.

Überhaupt nicht. Der Zweck, den Du festlegst, muß mich überhaupt nicht
jucken. Und umgekehrt.

Der Zweck ergibt sich *immer* aus der Intention des An-/Verwenders.

Post by Arno Welzel
Ein Python-Skipt enthält Anweisungen in einer Programmiersprache.

Richtig. Was es allerdings nicht zu einem Programm macht sondern nur den
Interpreter (= das Programm) parametrisiert.

Wieder falsch. Das Python-Skipt *ist* das Programm.

Nein, der Interpreter ist das Programm.

Post by Arno Welzel
Aber wenn für Dich "muss ein Interpreter ausführen" automatisch
bedeutet, dass etwas kein Programm mehr ist, dann gibt es keine
Programme!

Aber immer gibt es die. Interpreter sind Programme. Das schreibe ich
doch schon die ganze Zeit.

Post by Arno Welzel
Dann definiere bitte, was FÜR DICH ein "Programm" ist und was "Daten".

Bitte lies meine Postings. Insbesondere die, auf die Du antwortest.

Habe ich. Ich habe keine Definition von Dir dafür gefunden. Kannst Du
mir die Message-ID nennen, wo Du das getan hast?

<tdq844$1rihv$***@dont-email.me> Das ist das, auf das Du geantwortet hast.

Arno Welzel

2022-08-22 15:39:58 UTC

Post by Arno Welzel
Es kann sein, dass in einem Excel-File Makros enthalten sind, die in VBA
o.Ä. geschrieben sind - *das* sind dann zweifellos Programme.

Genau das bezweifele ich schon die ganze Zeit. Ganz besonders bezweifele
ich das "zweifellos". Und bisher ist es weder Dir noch Peter gelungen,
mich davon zu überzeugen.

Womit Du vollkommen Recht hast. Ich sehe, wir nähern uns der Sache an.

Nö. Denn ich teile deine Ansicht nicht.

[...]>> Habe ich. Ich habe keine Definition von Dir dafür gefunden.
Kannst Du

Post by Arno Welzel
mir die Message-ID nennen, wo Du das getan hast?

Nein.

<http://al.howardknight.net/?STYPE=msgid&MSGI=%3Ctdq844%241rihv%241%40dont-email.me%3E>

Da steht exakt NICHTS dazu, wie DU "Programm" konkret definierst.

Da steht nur:

"Programme interpretieren und verarbeiten Daten. Aber nicht umgekehrt."

Ein Python-Script interpretiert und verarbeitet Daten - also ist es ein
Programm. Die Tatsache, dass Python-Script eine Laufzeitumgebung dafür
benötigt, ist irrelevant, weil auch ein Binary mit x86-Code ebenfalls
eine Laufzeitumgebung braucht.

Du aber behauptest, dass ein Python-Script kein Programm sei, weil es
von einem Python-Interpreter ausgeführt wird.

Ob nun bei Dir aber "Interpreter nötig = kein Programm" gilt, ist mir
noch nicht klar. Wenn Du so argumentierst, gibt es eigentlich keine
Programme, da auch ein x86-Binary durch den x86-Interpreter der CPU
interpretiert werden muss, der seinerseits in Microcode geschrieben
wurde. Damit würde dann deiner Lesart folgendend gelten, dass nur der
Microcode von CPUs Programme sind, weil nur dieser Code direkt vom
CPU-Kern ausgeführt wird und nicht interpretiert werden muss.

--
Arno Welzel
https://arnowelzel.de

Lars Gebauer

2022-08-22 17:27:45 UTC

Post by Arno Welzel
Da steht exakt NICHTS dazu, wie DU "Programm" konkret definierst.

Falsch.

Post by Arno Welzel
"Programme interpretieren und verarbeiten Daten. Aber nicht umgekehrt."

Richtig.

Post by Arno Welzel
Ein Python-Script interpretiert und verarbeitet Daten

Tut es selbstverst#ndlich nicht. Versuche mal, das Python-Skript ohne
Python-Interpreter aufzurufen. Du wirst feststellen, daß genau gar
nichts passiert. Bestenfalls kommt eine Fehlermeldung.

Das Python-Skript interpretiert und verarbeitet also *nichts*.

Post by Arno Welzel
Du aber behauptest, dass ein Python-Script kein Programm sei, weil es
von einem Python-Interpreter ausgeführt wird.

Richtig. Der Python-Interpreter verarbeitet die Daten.

Das Skript bestimmt dabei nur, was konkret der Interpreter mit den Daten
machen soll. Iow: Es parametrisiert den Interpreter.

Post by Arno Welzel
Ob nun bei Dir aber "Interpreter nötig = kein Programm" gilt, ist mir
noch nicht klar. Wenn Du so argumentierst, gibt es eigentlich keine
Programme, da auch ein x86-Binary durch den x86-Interpreter der CPU
interpretiert werden muss, der seinerseits in Microcode geschrieben
wurde.

Ich habe nie bestritten, daß Programme auch Programme interpretieren und
verarbeiten können.

Arno Welzel

2022-08-23 14:06:11 UTC

Post by Arno Welzel
Da steht exakt NICHTS dazu, wie DU "Programm" konkret definierst.

Falsch.

Post by Arno Welzel
"Programme interpretieren und verarbeiten Daten. Aber nicht umgekehrt."

Richtig.

Post by Arno Welzel
Ein Python-Script interpretiert und verarbeitet Daten

Tut es selbstverst#ndlich nicht. Versuche mal, das Python-Skript ohne
Python-Interpreter aufzurufen. Du wirst feststellen, daß genau gar
nichts passiert. Bestenfalls kommt eine Fehlermeldung.
Das Python-Skript interpretiert und verarbeitet also *nichts*.

Versuche mal ein x86-Binary auf einer ARM-CPU auszuführen. Ein
x86-Binary interpretiert und verarbeitet also *nichts* ohne die richtige
Laufzeitumgebung.

Post by Arno Welzel
Du aber behauptest, dass ein Python-Script kein Programm sei, weil es
von einem Python-Interpreter ausgeführt wird.

Richtig. Der Python-Interpreter verarbeitet die Daten.
Das Skript bestimmt dabei nur, was konkret der Interpreter mit den Daten
machen soll. Iow: Es parametrisiert den Interpreter.

Diesere Argumentation folgende gibt gar keine Programme. Denn *alles*
muss interpretiert werden.

Ich habe nie bestritten, daß Programme auch Programme interpretieren und
verarbeiten können.

Deiner Logik nach gibt es aber keine Programme. Es sei denn, Du
definierst GANZ EXAKT wann etwas als "Programm" anzusehen ist.

Nein, auch ein Python-Interpreter ist deiner bisherigen Argumentation
nach KEIN PROGRAMM! Denn auch der Python-Interpreter läuft nicht ohne
Laufzeitumgebung, die den Interpreter selbst wieder interpretiert.

--
Arno Welzel
https://arnowelzel.de

Lars Gebauer

2022-08-23 14:43:29 UTC

Post by Arno Welzel
Ein Python-Script interpretiert und verarbeitet Daten

Tut es selbstverst#ndlich nicht. Versuche mal, das Python-Skript ohne
Python-Interpreter aufzurufen. Du wirst feststellen, daß genau gar
nichts passiert. Bestenfalls kommt eine Fehlermeldung.
Das Python-Skript interpretiert und verarbeitet also *nichts*.

Versuche mal ein x86-Binary auf einer ARM-CPU auszuführen.

Wozu? Bleib' doch einfach mal bei der Sache und versuche nicht laufend
abzulenken.

Post by Arno Welzel
Ein
x86-Binary interpretiert und verarbeitet also *nichts* ohne die richtige
Laufzeitumgebung.

Und wennschon: Programme können natürlich auch andere Programme
verarbeiten. Wie oft muß ich das noch schreiben?

Post by Arno Welzel
Du aber behauptest, dass ein Python-Script kein Programm sei, weil es
von einem Python-Interpreter ausgeführt wird.

Richtig. Der Python-Interpreter verarbeitet die Daten.
Das Skript bestimmt dabei nur, was konkret der Interpreter mit den Daten
machen soll. Iow: Es parametrisiert den Interpreter.

Diesere Argumentation folgende gibt gar keine Programme.

Doch: Interpreter sind Programme.

Post by Arno Welzel
Denn *alles* muss interpretiert werden.

Ja - aber nicht "Alles" kann alles interpretieren. Python-Skripte bspw.
können das nicht. Die brauchen dafür einen Interpreter. Was sie mit txt-
oder jpg-Files gemeinsam haben.

Ich habe nie bestritten, daß Programme auch Programme interpretieren und
verarbeiten können.

Deiner Logik nach gibt es aber keine Programme.

Aber natürlich gibt es die. Interpreter sind bspw. welche.

Post by Arno Welzel
Nein, auch ein Python-Interpreter ist deiner bisherigen Argumentation
nach KEIN PROGRAMM! Denn auch der Python-Interpreter läuft nicht ohne
Laufzeitumgebung, die den Interpreter selbst wieder interpretiert.

Ja. Weil Programme auch Programme interpretieren können. Was Daten nicht
können.

Arno Welzel

2022-08-23 20:23:40 UTC

Post by Arno Welzel
Ein Python-Script interpretiert und verarbeitet Daten

Tut es selbstverst#ndlich nicht. Versuche mal, das Python-Skript ohne
Python-Interpreter aufzurufen. Du wirst feststellen, daß genau gar
nichts passiert. Bestenfalls kommt eine Fehlermeldung.
Das Python-Skript interpretiert und verarbeitet also *nichts*.

Versuche mal ein x86-Binary auf einer ARM-CPU auszuführen.

Wozu? Bleib' doch einfach mal bei der Sache und versuche nicht laufend
abzulenken.

Das *IST* die Sachen! Genau das! DU(!) faselst die ganze Zeit davon,
dass irgendtwas kein Programm mehr ist, wenn es nicht direkt auf einem
Computer "aufgerufen" werden kann.

Genau das gilt exakt GANZ GENAU SO(!), wenn das Binary nicht passend zur
CPU ist! Und ja - mit einem Emulator ist das ebenso lösbar - ist das
dann kein Programm mehr, wenn der x86-Code auf eier ARM-CPU durch einen
Emulator interpretiert werden muss?

[...]

Post by Arno Welzel
Diesere Argumentation folgende gibt gar keine Programme.

Doch: Interpreter sind Programme.

Falsch! DEINE(!) Argumentation sagt, wenn etwas interpretiert werden
muss, ist es kein Programm mehr!

Es muss aber ALLES interpretiert werden, ausnahmslos!

Post by Arno Welzel
Denn *alles* muss interpretiert werden.

Ja - aber nicht "Alles" kann alles interpretieren. Python-Skripte bspw.
können das nicht. Die brauchen dafür einen Interpreter. Was sie mit txt-
oder jpg-Files gemeinsam haben.

ALLES(!) braucht einen Interpreter!

[...]

Post by Arno Welzel
Deiner Logik nach gibt es aber keine Programme.

Aber natürlich gibt es die. Interpreter sind bspw. welche.

Nein, da sie deiner Logik folgend ebenfalls interpretiert werden müssen.

--
Arno Welzel
https://arnowelzel.de

Lars Gebauer

2022-08-24 13:05:54 UTC

Post by Arno Welzel
Versuche mal ein x86-Binary auf einer ARM-CPU auszuführen.

Wozu? Bleib' doch einfach mal bei der Sache und versuche nicht laufend
abzulenken.

Dann ist es eben für für diesen Computer kein Programm. Wo soll das
jetzt das Problem sein?

Post by Arno Welzel
Diesere Argumentation folgende gibt gar keine Programme.

Doch: Interpreter sind Programme.

Falsch! DEINE(!) Argumentation sagt, wenn etwas interpretiert werden
muss, ist es kein Programm mehr!

Nein. Das war und ist nicht meine Aussage. Eher im Gegenteil habe ich
schon mehrfach geschrieben, daß Programme selbstverständlich auch
Programme ausführen können.

Post by Arno Welzel
Denn *alles* muss interpretiert werden.

Ja - aber nicht "Alles" kann alles interpretieren. Python-Skripte bspw.
können das nicht. Die brauchen dafür einen Interpreter. Was sie mit txt-
oder jpg-Files gemeinsam haben.

ALLES(!) braucht einen Interpreter!

Aber nicht alle *ist* ein Interpreter.

Arno Welzel

2022-08-24 19:39:54 UTC

Post by Arno Welzel
Versuche mal ein x86-Binary auf einer ARM-CPU auszuführen.

Wozu? Bleib' doch einfach mal bei der Sache und versuche nicht laufend
abzulenken.

Dann ist es eben für für diesen Computer kein Programm. Wo soll das
jetzt das Problem sein?

Das Problem ist deine Aussage, dass irgendetwas für Dich kein Programm
ist, nur weil irgendwelche Rahmenbedingungen gerade nicht passen.

Wenn Dir jemand einen Text vorlegt, der ein Kochrezept enthält, Du die
Sprache des Textes aber nicht verstehst, sagst Du dann acuh "Das ist
kein Kochrezept, weil ich den Text nicht verstehe."?

[...]

Post by Arno Welzel
Falsch! DEINE(!) Argumentation sagt, wenn etwas interpretiert werden
muss, ist es kein Programm mehr!

Nein. Das war und ist nicht meine Aussage. Eher im Gegenteil habe ich
schon mehrfach geschrieben, daß Programme selbstverständlich auch
Programme ausführen können.

Nein, deine Aussage war, dass ein Python-Script kein Programm ist, weil
es ohne Interpreter nicht ausführbar ist.

Daher gilt logischerweise, das *alles* was ohne Interpreter nicht
ausführbar ist, kein Programm ist. Wieso sollte das denn nur für Python
gelten?

[...]

Post by Arno Welzel
ALLES(!) braucht einen Interpreter!

Aber nicht alle *ist* ein Interpreter.

Das war auch gar nicht das Thema! Lenke nicht wieder ab!

Es geht darum, dass es deiner Logik nach keine Programme geben kann,
weil nichts ohne Interpreter ausführbar ist.

--
Arno Welzel
https://arnowelzel.de

Peter J. Holzer

2022-08-22 19:27:02 UTC

Post by Arno Welzel
Nein, Du hast mir nicht Recht gegeben. Ich habe nicht behauptet, dass
Bilddaten Programme wären.

Das ist aber die Konsequenz, wenn man Deiner Argumentation folgt.

1) Programme und Daten sind fundamental unterschiedlich. Etwas ist
entweder Daten oder Programm
2) Daten und Programme sind das gleiche. Alle Daten sind
Programme und umgekehrt,
Aber warum sollte man das tun?

Genau das. Ich frage mich schon die ganze Zeit, warum Ihr das tut.

Das tue ich nicht!
Programme und Daten *SIND* fundamental unterschiedlich.

Da widerspreche ich.

| Gebilde aus Zeichen oder kontinuierliche Funktionen, die aufgrund
| bekannter oder unterstellter Abmachungen Informationen darstellen,
| vorrangig zum Zweck der Verarbeitung und als deren Ergebnis.
-- DIN 44300 Nr. 19

| a reinterpretable representation of information in a formalized
| manner, suitable for communication, interpretation, or processing
-- ISO/IEC 2382-1

(beide zitiert in https://de.wikipedia.org/wiki/Daten#Informatik)

Diese Definitionen treffen auf Programme zu. Folglich sind Programme
Daten (aber nicht notwendigerweise umgekehrt).

Der Wikipedia-Artikel erwähnt dann weiter unten auch "Programmcode,
Ausführbare Dateien usw." als Beispiele von "technischen Daten".

Post by Arno Welzel
Deswegen ist ein Python-Script ein *Programm* und nicht nur "Daten".

Das scheint mir ein Non-Sequitur zu sein.

Ein Python-Script ist ein Programm, weil es eben der Definition eines
Programms genügt.

Sie unterscheiden sich dadurch, wofür sie *vorgesehen* sind.

ACK.

Post by Arno Welzel
Ein Python-Skipt enthält Anweisungen in einer Programmiersprache.
Ein Excel-File - wenn man Makros mal außen vorlässt - dagegen nur Zahlen
und Formeln.

^^^^^^^
Formeln sind eine Programmiersprache. Mit Rekursion wäre es sogar eine
turing-vollständige. (Ich wollte schon Fibonacci oder sowas implemen-
tieren, kann aber leider nicht, weil unsere Excel-Version zu alt ist.
Offenbar sind rekursive Funktionen erst in den letzten 1-2 Jahren für
die breite Masse freigeschaltet worden (Build
vierzehntausendundirgendwas). Gelesen habe ich davon das erste Mal vor
etlichen Jahren, daher meine optimistische Annahme, dass das
mittlerweile ein Standardfeature ist (aber naja, der Begriff Vapourware
wurde ja von Microsoft erfunden ...).)

hp

Lars Gebauer

2022-08-23 12:42:30 UTC

Post by Peter J. Holzer
(beide zitiert in https://de.wikipedia.org/wiki/Daten#Informatik)
Diese Definitionen treffen auf Programme zu. Folglich sind Programme
Daten (aber nicht notwendigerweise umgekehrt).

Sag' ich doch die ganze Zeit.

Post by Peter J. Holzer
Ein Python-Script ist ein Programm, weil es eben der Definition eines
Programms genügt.

Ein Programm ist etwas "Ausführbares". Ich rufe ein Programm auf - und
$irgendetwas passiert: Am Bildschirm wird irgendwas aufgelistet, es
zeigt sich ein prompt und es wird auf eine weitere Eingabe gewartet,
eine grafische Anwendung wird gestartet, $irgendwas. Vielleicht läuft
auch nur eine Hintergrund-Anwendung ab. Aber es passiert was.

Rufe ich ein Python-Skript auf, passiert nichts. Überhaupt nichts.
Maximal erscheint eine vom Betriebsystem generierte Fehlermeldung.

Es sei denn, ein Python-Interpreter ist installiert. Dann übergibt das
Betriebssystem das Skript an jenen Interpreter und *dann* passiert
etwas. Der Interpreter ist das Programm, das Skript enthält nur Daten
(die an den Interpreter übergeben werden und ihn parametrisieren).

Nicht anders bei einer Bild-Datei:

Rufe ich ein .jpg auf, passiert nichts. Überhaupt nichts. Maximal
erscheint eine vom Betriebsystem generierte Fehlermeldung.

Es sei denn, ein .jpg-Interpreter ist installiert. Dann übergibt das
Betriebssystem das .jpg an jenen Interpreter und *dann* passiert etwas.
Der Interpreter ist das Programm, das .jpg enthält nur Daten (die an den
Interpreter übergeben werden und ihn parametrisieren).

Ebenso bei einem Excel-File:

Rufe ich ein Excel-File auf, passiert nichts. Überhaupt nichts. Maximal
erscheint eine vom Betriebsystem generierte Fehlermeldung.

Es sei denn, ein Excel-Interpreter ist installiert. Dann übergibt das
Betriebssystem das Excel-File an jenen Interpreter und *dann* passiert
etwas. Der Interpreter ist das Programm, das Excel-File enthält nur
Daten (die an den Interpreter übergeben werden und ihn parametrisieren).

Daß die an den Interpreter übergebenen Daten verschieden komplex sein
können, ist vollkommen richtig. Tut aber überhaupt nichts zur Sache, da
das kein qualitativer Unterschied ist.

Arno Welzel

2022-08-23 14:09:23 UTC

Sag' ich doch die ganze Zeit.

Post by Peter J. Holzer
Ein Python-Script ist ein Programm, weil es eben der Definition eines
Programms genügt.

Ein Programm ist etwas "Ausführbares". Ich rufe ein Programm auf - und

Das trifft auf ein Python-Script zu.

Post by Lars Gebauer
$irgendetwas passiert: Am Bildschirm wird irgendwas aufgelistet, es
zeigt sich ein prompt und es wird auf eine weitere Eingabe gewartet,
eine grafische Anwendung wird gestartet, $irgendwas. Vielleicht läuft
auch nur eine Hintergrund-Anwendung ab. Aber es passiert was.
Rufe ich ein Python-Skript auf, passiert nichts. Überhaupt nichts.
Maximal erscheint eine vom Betriebsystem generierte Fehlermeldung.

Genaus wie wenn ich auf einem x86-PC ein ARM-Binary aufrufen würde oder
unter Windows ein Linux-Programm starten wollte

Post by Lars Gebauer
Es sei denn, ein Python-Interpreter ist installiert. Dann übergibt das
Betriebssystem das Skript an jenen Interpreter und *dann* passiert
etwas. Der Interpreter ist das Programm, das Skript enthält nur Daten
(die an den Interpreter übergeben werden und ihn parametrisieren).

Ja und? Das passiert mit JEDEM(!) Programm so! Du merkst das nur nicht.

--
Arno Welzel
https://arnowelzel.de

Lars Gebauer

2022-08-23 14:34:00 UTC

Post by Peter J. Holzer
Ein Python-Script ist ein Programm, weil es eben der Definition eines
Programms genügt.

Ein Programm ist etwas "Ausführbares". Ich rufe ein Programm auf - und

Das trifft auf ein Python-Script zu.

Was? Daß ich es aufrufe? In der Tat.

Ja und? Das passiert mit JEDEM(!) Programm so! Du merkst das nur nicht.

Richtig! Mit jedem *Programm*!

Nicht aber mit einem Daten-File. Da passiert ohne Programm
(=Interpreter) gar nichts.

Arno Welzel

2022-08-23 20:25:13 UTC

[...]

Post by Arno Welzel
Ja und? Das passiert mit JEDEM(!) Programm so! Du merkst das nur nicht.

Richtig! Mit jedem *Programm*!
Nicht aber mit einem Daten-File. Da passiert ohne Programm
(=Interpreter) gar nichts.

Das gilt aber IMMER. Daher gibt es in deiner Welt keine Programme,
sondern nur nur "Daten-Files", von denen für manche auch Interpreter
existieren. Diese Interpreter sind aber selbst ebenfalls nur
"Daten-Files", die zufälligerweise von einem anderen Interpreter
ausgeführt werden können, der beim Betriebssystem schon dabei war.

--
Arno Welzel
https://arnowelzel.de

Lars Gebauer

2022-08-24 13:14:42 UTC

Post by Arno Welzel
[...]

Post by Arno Welzel
Ja und? Das passiert mit JEDEM(!) Programm so! Du merkst das nur nicht.

Richtig! Mit jedem *Programm*!
Nicht aber mit einem Daten-File. Da passiert ohne Programm
(=Interpreter) gar nichts.

Das gilt aber IMMER.

Dennoch sind nicht alle Daten auch Interpreter. Manche sind einfach nur
Daten(-Files).

Stefan Reuther

2022-08-24 16:24:02 UTC

Post by Arno Welzel
[...]

Post by Arno Welzel
Ja und? Das passiert mit JEDEM(!) Programm so! Du merkst das nur nicht.

Richtig! Mit jedem *Programm*!
Nicht aber mit einem Daten-File. Da passiert ohne Programm
(=Interpreter) gar nichts.

Das gilt aber IMMER.

Dennoch sind nicht alle Daten auch Interpreter. Manche sind einfach nur
Daten(-Files).

Irgendwann wird jemand die Datendatei in einer grafischen Oberfläche
anzeigen wollen. Und dann dient sie als Eingabe für den Hint-Interpreter
im Fontrenderer.

(siehe z.B. <https://litherum.blogspot.com/2019/03/addition-font.html>)

Stefan

Arno Welzel

2022-08-21 14:54:16 UTC

Post by Lars Gebauer
Aber gut: Dann produziert meine Kamera eben lauter Programme. Kann ich
mit leben, ist mir nicht so wichtig.

Jetzt hast Du deine Ignoranz endgültig demonstriert. Dann eben nicht.

Wenn ich Dir Recht gebe, nölst Du. Hast Du Probleme mit Dir selbst?

Nein, Du hast mir nicht Recht gegeben. Ich habe nicht behauptet, dass
Bilddaten Programme wären.

Das ist aber die Konsequenz, wenn man Deiner Argumentation folgt.

Nein, ist es nicht.

Meine Argumentation war, dass Programme nicht ausschliesslich in binärer
Form vorliegen müssen, sondern auch aus Befehlen in Textform bestehen
können, und zur Ausführung noch einenn Interpreter oder Compiler
benötigen. Das ändert aber nichts daran, dass es Programme sind und
keine Kochrezepte oder Bilder, wie z.B. SVG, was auch in Textform vorliegt.

Post by Lars Gebauer
Produziert Deine Argumentation Ergebnisse, die Dir nicht gefallen? Dann
solltest Du sie vielleicht überdenken.

Produziert deine Ignoranz Ergebnisse, die Dir nicht gefallen? Dann
solltest Du sie vielleicht überdenken.

Post by Arno Welzel
Nein, ein Python-Skript "parametrisiert" exakt gar nichts.

Schon gar nicht den Python-Interpreter. Ist ja schon gut.

Korrekt. Ein Interpreter wird durch Programmcode nicht parametrisiert,

Richtig. Da werden keinerlei Parameter wie Konstanten oder Variablen
übergeben.

Auch Konstanten oder Variablen sind keine "Parametrisierung".

Post by Arno Welzel
sondern interpretritiert den Code.

So, wie ein Bildinterpreter.

Das Programm, was eine JPEG-Datei liest und diese dann auf dem
Bildschirm angezeigt oder ausdruckt, ist aber kein "Interpreter".

Bevor hier noch weiteren Unsinn verbreitest, soltest Du wenigstens
Begrifflichkeiten korrekt verwenden.

--
Arno Welzel
https://arnowelzel.de

Lars Gebauer

2022-08-21 17:46:50 UTC

Post by Arno Welzel
Meine Argumentation war, dass Programme nicht ausschliesslich in binärer
Form vorliegen müssen, sondern auch aus Befehlen in Textform bestehen
können, und zur Ausführung noch einenn Interpreter oder Compiler
benötigen. Das ändert aber nichts daran, dass es Programme sind und
keine Kochrezepte oder Bilder, wie z.B. SVG, was auch in Textform vorliegt.

Dann erkläre mal den Unterschied zwischen bspw. einem Python-Script und
einer Bilddatei. Die Bilddatei taugt nämlich ohne Interpreter auch nichts.

Post by Lars Gebauer
Produziert Deine Argumentation Ergebnisse, die Dir nicht gefallen? Dann
solltest Du sie vielleicht überdenken.

Produziert deine Ignoranz Ergebnisse, die Dir nicht gefallen?

Überhaupt nicht. Ganz im Gegenteil bin ich mit den Ergebnissen
hochgradig zufrieden.

Post by Arno Welzel
Dann solltest Du sie vielleicht überdenken.

Dazu besteht überhaupt kein Anlaß.

Post by Arno Welzel
Nein, ein Python-Skript "parametrisiert" exakt gar nichts.

Schon gar nicht den Python-Interpreter. Ist ja schon gut.

Korrekt. Ein Interpreter wird durch Programmcode nicht parametrisiert,

Richtig. Da werden keinerlei Parameter wie Konstanten oder Variablen
übergeben.

Auch Konstanten oder Variablen sind keine "Parametrisierung".

Nun ist aber langsam gut. Was sollen Konstanten und Variablen denn sonst
sein, wenn keine Parameter, die an den Interpreter übergeben werden?

Post by Arno Welzel
sondern interpretritiert den Code.

So, wie ein Bildinterpreter.

Das Programm, was eine JPEG-Datei liest und diese dann auf dem
Bildschirm angezeigt oder ausdruckt, ist aber kein "Interpreter".

Aber natürlich ist es einer! Was soll es denn sonst sein, wenn kein
Interpreter?

Post by Arno Welzel
Bevor hier noch weiteren Unsinn verbreitest, soltest Du wenigstens
Begrifflichkeiten korrekt verwenden.

Das tue ich die ganze Zeit. Genau damit begann die Diskussion.

Allerdings beschleicht mich bei Dir zunehmend das Gefühl, daß es Dir am
strukturierten und konsequenten Denken mangelt. Da hat sich wohl über
die Zeit eine gewisse Schlampigkeit etabliert. Das ist gar nicht weiter
schlimm; nur solltest Du Dir dessen bewußt sein.

Arno Welzel

2022-08-21 18:26:34 UTC

Dann erkläre mal den Unterschied zwischen bspw. einem Python-Script und
einer Bilddatei. Die Bilddatei taugt nämlich ohne Interpreter auch nichts.

Die Bilddatei kann den Computer nicht zu beliebigen Aktionen
veranlassen, sondern kann nur benutzt werden, um Bilder zu speichern

Post by Lars Gebauer
Produziert Deine Argumentation Ergebnisse, die Dir nicht gefallen? Dann
solltest Du sie vielleicht überdenken.

Produziert deine Ignoranz Ergebnisse, die Dir nicht gefallen?

Überhaupt nicht. Ganz im Gegenteil bin ich mit den Ergebnissen
hochgradig zufrieden.

Troll....

--
Arno Welzel
https://arnowelzel.de

Lars Gebauer

2022-08-21 19:34:16 UTC

Dann erkläre mal den Unterschied zwischen bspw. einem Python-Script und
einer Bilddatei. Die Bilddatei taugt nämlich ohne Interpreter auch nichts.

Die Bilddatei kann den Computer nicht zu beliebigen Aktionen
veranlassen, sondern kann nur benutzt werden, um Bilder zu speichern

Na das ist ja nun völliger Blödsinn. Was da passiert, hängt einzig vom
Interpreter der Bilddatei ab.

Arno Welzel

2022-08-22 15:42:59 UTC

Dann erkläre mal den Unterschied zwischen bspw. einem Python-Script und
einer Bilddatei. Die Bilddatei taugt nämlich ohne Interpreter auch nichts.

Die Bilddatei kann den Computer nicht zu beliebigen Aktionen
veranlassen, sondern kann nur benutzt werden, um Bilder zu speichern

Na das ist ja nun völliger Blödsinn. Was da passiert, hängt einzig vom
Interpreter der Bilddatei ab.

Welche Programme interpretieren Bilddateien so, dass sie sich dann
genaus verhalten wie Scripte in einer Programmiersprache inkl.
Variablen, Sprüngen, Bedingungen, Schleifen etc.? Wo ist der Standard
dafür beschrieben? Die Erweiterung dafür in Formaten wie JPEG oder PNG
muss ich wohl übersehen haben.

Und nein, ich meine bewusst nicht SVG oder PostScript, sondern
Bitmap-Formate.

--
Arno Welzel
https://arnowelzel.de

Lars Gebauer

2022-08-22 17:15:23 UTC

Post by Lars Gebauer
Dann erkläre mal den Unterschied zwischen bspw. einem Python-Script und
einer Bilddatei. Die Bilddatei taugt nämlich ohne Interpreter auch nichts.

Die Bilddatei kann den Computer nicht zu beliebigen Aktionen
veranlassen, sondern kann nur benutzt werden, um Bilder zu speichern

Na das ist ja nun völliger Blödsinn. Was da passiert, hängt einzig vom
Interpreter der Bilddatei ab.

Welche Programme interpretieren Bilddateien so, dass sie sich dann
genaus verhalten wie Scripte in einer Programmiersprache inkl.
Variablen, Sprüngen, Bedingungen, Schleifen etc.?

Im Zweifel immer die, die $morgen geschrieben werden.

Daß es solche Programme momentan nicht gibt (afaik) heißt doch nicht,
daß es sie nicht geben könnte.

Arno Welzel

2022-08-23 14:10:15 UTC

Post by Lars Gebauer
Dann erkläre mal den Unterschied zwischen bspw. einem Python-Script und
einer Bilddatei. Die Bilddatei taugt nämlich ohne Interpreter auch nichts.

Die Bilddatei kann den Computer nicht zu beliebigen Aktionen
veranlassen, sondern kann nur benutzt werden, um Bilder zu speichern

Na das ist ja nun völliger Blödsinn. Was da passiert, hängt einzig vom
Interpreter der Bilddatei ab.

Welche Programme interpretieren Bilddateien so, dass sie sich dann
genaus verhalten wie Scripte in einer Programmiersprache inkl.
Variablen, Sprüngen, Bedingungen, Schleifen etc.?

Im Zweifel immer die, die $morgen geschrieben werden.

Lenke nicht ab. Beweise deine Behauptung. Nein, dass es irgendwann
irgendwas geben könnte, ist kein Beweis.

--
Arno Welzel
https://arnowelzel.de

Lars Gebauer

2022-08-23 14:30:28 UTC

Post by Lars Gebauer
Na das ist ja nun völliger Blödsinn. Was da passiert, hängt einzig vom
Interpreter der Bilddatei ab.

Welche Programme interpretieren Bilddateien so, dass sie sich dann
genaus verhalten wie Scripte in einer Programmiersprache inkl.
Variablen, Sprüngen, Bedingungen, Schleifen etc.?

Im Zweifel immer die, die $morgen geschrieben werden.

Lenke nicht ab. Beweise deine Behauptung.

Was gibt es da zu beweisen? Willst Du ernsthaft behaupten, daß es
unmöglich ist, daß es ein solches Programm gibt? Oder doch wenigstens
geben könnte?

Arno Welzel

2022-08-23 20:19:17 UTC

Post by Lars Gebauer
Na das ist ja nun völliger Blödsinn. Was da passiert, hängt einzig vom
Interpreter der Bilddatei ab.

Welche Programme interpretieren Bilddateien so, dass sie sich dann
genaus verhalten wie Scripte in einer Programmiersprache inkl.
Variablen, Sprüngen, Bedingungen, Schleifen etc.?

Im Zweifel immer die, die $morgen geschrieben werden.

Lenke nicht ab. Beweise deine Behauptung.

Was gibt es da zu beweisen? Willst Du ernsthaft behaupten, daß es
unmöglich ist, daß es ein solches Programm gibt? Oder doch wenigstens
geben könnte?

Deine Aussage war, dass Bilder auch als Programme interpretiert werden
können. Dann zeige ein Beispiel dafür.

Und selbst wenn jemand ein Programm schreibt, dass Inhalte aus Bildern
als Programme interpretiert und ausführt, dann sind diese Bilder eben
auch Programme, weil sie explizit dafür *vorgesehen* sind! Denn auch die
Bilder müssen logischerweise passende Inhalte dafür haben, so wie nicht
jeder Text automatisch auch ein Programm ist, nur weil man Texte als
Programme interpretieren kann.

--
Arno Welzel
https://arnowelzel.de

Laurenz Trossel

2022-08-24 08:45:50 UTC

Post by Arno Welzel
Deine Aussage war, dass Bilder auch als Programme interpretiert werden
können. Dann zeige ein Beispiel dafür.

Das Beispiel war:
https://www.securityweek.com/google-says-nso-pegasus-zero-click-most-technically-sophisticated-exploit-ever-seen

Eine virtuelle CPU und Programme in Bilddaten, die vom
Bilddaten-Interpreter ausgeführt werden.

Laurenz Trossel

2022-08-24 11:02:20 UTC

Post by Arno Welzel
Deine Aussage war, dass Bilder auch als Programme interpretiert werden
können. Dann zeige ein Beispiel dafür.

Eine Frage habe ich noch: Ist Postscript eine Programmiersprache oder ein
Datenformat?

Lars Gebauer

2022-08-24 12:58:10 UTC

Post by Arno Welzel
Welche Programme interpretieren Bilddateien so, dass sie sich dann
genaus verhalten wie Scripte in einer Programmiersprache inkl.
Variablen, Sprüngen, Bedingungen, Schleifen etc.?

Im Zweifel immer die, die $morgen geschrieben werden.

Lenke nicht ab. Beweise deine Behauptung.

Was gibt es da zu beweisen? Willst Du ernsthaft behaupten, daß es
unmöglich ist, daß es ein solches Programm gibt? Oder doch wenigstens
geben könnte?

Deine Aussage war, dass Bilder auch als Programme interpretiert werden
können.

Nein, das war und ist *nicht* meine Aussage. Noch nie.

Post by Arno Welzel
Dann zeige ein Beispiel dafür.

Du denkst Dir Blödsinn aus und ich soll ein Beispiel dafür zeigen?

Peter J. Holzer

2022-08-23 21:17:24 UTC

Post by Lars Gebauer
Na das ist ja nun völliger Blödsinn. Was da passiert, hängt einzig vom
Interpreter der Bilddatei ab.

Welche Programme interpretieren Bilddateien so, dass sie sich dann
genaus verhalten wie Scripte in einer Programmiersprache inkl.
Variablen, Sprüngen, Bedingungen, Schleifen etc.?

Im Zweifel immer die, die $morgen geschrieben werden.

Lenke nicht ab. Beweise deine Behauptung.

Was gibt es da zu beweisen? Willst Du ernsthaft behaupten, daß es
unmöglich ist, daß es ein solches Programm gibt? Oder doch wenigstens
geben könnte?

Du kannst natürlich jedes File in .com umbenennen und unter MS-DOS
ausführen[1]. Irgendwas wird das schon tun. Macht das jedes File in
Deinen Augen zum Programm? Es sollte jedenfalls Deinen Kriterien
entsprechen, soweit ich sie erkennen kann: Es ist ausführbar und es
braucht keinen Interpreter außer der CPU.

hp

[1] Zumindest, wenn es kürzer als 65280 Bytes ist. Bin mir nicht sicher,
was MS-DOS mit COM-Files gemacht hat, die nicht in ein Segment passen.

Martin Gerdes

2022-08-08 10:29:20 UTC

Post by Peter J. Holzer
Ja, ein Excel-File ist ein Programm.

Nein, natürlich nicht. Es ist denkbar, daß eine Excel-Datei aktive
Inhalte enthält (meine tun das sämtlich nicht), aber zwingend ist das
nicht.

[Zitat ergänzt]

|> Die meisten User wären unglücklich, wenn sie ihre Excel-Files nicht
|> selbst beschreiben dürften.

|Die meisten Netizens wären unglücklich, wenn sie keine Haare mehr
|spalten dürften.

Das gilt offensichtlich speziell für Dich.

Meinen Einwand mit der Verringerung der Exposition durch Ausschluß
eindeutig ausführbarer Programme hast Du nonchalant gesnippt.
Offensichtlich hast Du kein gutes Argument dagegen.

Peter J. Holzer

2022-08-08 21:42:31 UTC

Post by Martin Gerdes
|Die meisten Netizens wären unglücklich, wenn sie keine Haare mehr
|spalten dürften.
Das gilt offensichtlich speziell für Dich.

Ich habe schon beim ersten Mal verstanden, dass Du mich meinst.

Aber tatsächlich mache ich genau das Gegenteil. Ich spalte nicht ein
Haar, ich betrachte den ganzen Pelz.

Post by Martin Gerdes
Meinen Einwand mit der Verringerung der Exposition durch Ausschluß
eindeutig ausführbarer Programme hast Du nonchalant gesnippt.
Offensichtlich hast Du kein gutes Argument dagegen.

Ich habe keine belastbaren Statistiken bzw. bin zu faul, welche zu
suchen. Es würde also meine unbelegte Meinung gegen deine unbelegte
Meinung stehen. Dafür ist mir meine Zeit zu schade.

hp

Martin Gerdes

2022-08-09 11:07:32 UTC

Ich habe keine belastbaren Statistiken bzw. bin zu faul, welche zu
suchen. Es würde also meine unbelegte Meinung gegen deine unbelegte
Meinung stehen. Dafür ist mir meine Zeit zu schade.

"Die Trauben sind sauer", sagte der Fuchs (bei de la Fontaine, so Du das
Zitat nicht erkannt haben solltest).

Arno Welzel

2022-08-11 16:18:28 UTC

Peter J. Holzer, 2022-08-06 21:37:

[...]

Post by Peter J. Holzer
(Und wenn wir von Turing-Maschinen sprechen: Excel war lange Zeit nicht
turing-vollständig (ein Merkmal "richtiger" Programmiersprachen, wenn
auch IMHO ein eher theoretisches), diese Lücke wurde aber wenn ich mich
recht erinnere vor etlichen Jahren durch die Einführung rekursiver
Funktionen geschlossen.)

Wenn man keine Makros zulässt, gibt es in Excel keine rekursiven Funktionen.

Excel ohne Makros ist genauso wenig eine "Programmiersprache" wie HTML
ohne JavaScript.

--
Arno Welzel
https://arnowelzel.de

Marco Moock

2022-08-03 19:44:34 UTC

Sicherheitsrisiko nicht - aber je nach Installer ist das normal. Viele
bieten das an, sodass man auch ohne Adminrechte Software installieren
und nutzen kann.

Ob die von dir genannte Seite offiziell von Google ist weiß ich nicht.
Da würde ich mir mehr sorgen machen.

Stefan Kanthak

2022-08-03 20:43:51 UTC

Post by Lutz E. Cerning
Ist es ein Sicherheitsrisiko dass er sich in
...AppData\Local\Chromium\Application und *nicht* in den
Programme-Ordner installieren will?

Ja. Und obendrein STRUNZEND DUMM:
1) seit 50+ Jahren wird von allen ernst zu nehmenden Betruebssystem
ausfuehrbarer Code im Hauptspeicher nur NICHT-(ueber)schreibbar
geladen (<https://en.wikipedia.org/wiki/Code_segment> vs.
<https://en.wikipedia.org/wiki/Data_segment>);
2) seit 20 Jahren werden (ueber)schreibbare Daten NICHT-ausfuehrbar
geladen ("Write XOR Execute" <https://en.wikipedia.org/wiki/W%5EX>
alias "data execution prevention"
<https://msdn.microsoft.com/en-us/library/aa366553.aspx>)

Post by Lutz E. Cerning
Oder habe ich da nur etwas übersehen?

Ja. Dass diese Trennung selbstverstaendlich auch im Dateisystem
vorgenommen (siehe
<https://msdn.microsoft.com/en-us/library/bb776776.aspx#installing-your-application-properly>)
und dann (beispielsweise) mittels SAFER effektiv durchgesetzt wird
(siehe <https://skanthak.homepage.t-online.de/SAFER.html>)

Stefan

--
<https://www.duden.de/rechtschreibung/Kanthaken>

Arno Welzel

2022-08-04 08:29:41 UTC

Post by Lutz E. Cerning
Hallo allerseits,
vorhin habe ich mir den aktuellwn Comium-Browser von
Ist es ein Sicherheitsrisiko dass er sich in
...AppData\Local\Chromium\Application und *nicht* in den
Programme-Ordner installieren will?

Ja.

Post by Lutz E. Cerning
Oder habe ich da nur etwas übersehen?

Nein.

Das ist leider bei etlichen Anwendungen mittlerweile üblich, weil man so
keine administrativen Rechte braucht - aber es ist eben auch unsicher,
weil so Malware natürlich die Daten ebenfalls leicht manipulieren kann.

--
Arno Welzel
https://arnowelzel.de

Marco Moock

2022-08-04 09:48:25 UTC

Post by Arno Welzel
Das ist leider bei etlichen Anwendungen mittlerweile üblich, weil man
so keine administrativen Rechte braucht - aber es ist eben auch
unsicher, weil so Malware natürlich die Daten ebenfalls leicht
manipulieren kann.

Das kann Malware aber auch ganze ohne die Installation in AppData.
Wer der Software nicht traut, sollte sie nicht auf dem Produktivsystem
ausführen.
Und mit Adminrechten kann man de facto auf alles im System zugreifen.

Arno Welzel

2022-08-04 16:47:15 UTC

Das kann Malware aber auch ganze ohne die Installation in AppData.

Wie genau soll Malware die Binaries installierter Anwendungen
modifizieren, wenn sie darauf keine Schreibrechte hat?

Post by Marco Moock
Wer der Software nicht traut, sollte sie nicht auf dem Produktivsystem
ausführen.

Und wer Software traut, sollte sie nicht so installieren, dass sie von
Malware jederzeit leicht verändert werden kann.

Post by Marco Moock
Und mit Adminrechten kann man de facto auf alles im System zugreifen.

Malware hat aber üblicherweise keine Adminrechte.

--
Arno Welzel
https://arnowelzel.de

Marco Moock

2022-08-04 16:55:30 UTC

Post by Arno Welzel
Wie genau soll Malware die Binaries installierter Anwendungen
modifizieren, wenn sie darauf keine Schreibrechte hat?

Die kann die Daten des ausführenden Users missbrauchen wie sie will -
ganz ohne Adminrechte.

Post by Marco Moock
Wer der Software nicht traut, sollte sie nicht auf dem
Produktivsystem ausführen.

Und wer Software traut, sollte sie nicht so installieren, dass sie von
Malware jederzeit leicht verändert werden kann.

ok, das macht Sinn, ändert aber nichts daran, dass Malware direkt auf
die Daten des Users zugreifen kann.

Post by Marco Moock
Und mit Adminrechten kann man de facto auf alles im System
zugreifen.

Malware hat aber üblicherweise keine Adminrechte.

Und auch ohne die kann sie die Dateien des Users lesen und ändern.
Zudem führen viele Leute praktisch jede Software aus dem Internet
ungeprüft aus, auch wenn die UAC-Abfrage kommt.
Bei DAUs klappt das meist immer.

Arno Welzel

2022-08-05 08:07:34 UTC

Post by Arno Welzel
Wie genau soll Malware die Binaries installierter Anwendungen
modifizieren, wenn sie darauf keine Schreibrechte hat?

Die kann die Daten des ausführenden Users missbrauchen wie sie will -
ganz ohne Adminrechte.

Darum ging es aber nicht.

[...]

Post by Arno Welzel
Und wer Software traut, sollte sie nicht so installieren, dass sie von
Malware jederzeit leicht verändert werden kann.

ok, das macht Sinn, ändert aber nichts daran, dass Malware direkt auf
die Daten des Users zugreifen kann.

Richtig. Ich sprach aber nicht von den Daten des Users sondern den
Dateien der Anwendung, die ja auch "Daten" sind.

Post by Marco Moock
Und mit Adminrechten kann man de facto auf alles im System
zugreifen.

Malware hat aber üblicherweise keine Adminrechte.

Und auch ohne die kann sie die Dateien des Users lesen und ändern.

Richtig. Aber um die Dateien ds Users ging es aber nicht.

Post by Marco Moock
Zudem führen viele Leute praktisch jede Software aus dem Internet
ungeprüft aus, auch wenn die UAC-Abfrage kommt.
Bei DAUs klappt das meist immer.

Bei DAUs ist jede Diskuskussion über Sicherheitsmaßnahmen vollkommen
überflüssig. Und alle Anderen wissen ja, was sie tun und müssen nicht
mehr darüber reden. Also können wir uns die komplette Diskussion
eigentlich sparen.

--
Arno Welzel
https://arnowelzel.de

Peter J. Holzer

2022-08-05 11:12:00 UTC

Post by Arno Welzel
Wie genau soll Malware die Binaries installierter Anwendungen
modifizieren, wenn sie darauf keine Schreibrechte hat?

Die kann die Daten des ausführenden Users missbrauchen wie sie will -
ganz ohne Adminrechte.

Darum ging es aber nicht.

Doch, im Endeffekt geht es genau darum. Die Programme auf einem PC sind
für sich nicht schützenswert - sie sind weder geheim noch schwer zu
ersetzen. Die Daten des Users hingegen sind es. Die Programme zu
schützen ist nur deshalb sinnvoll, weil sie für einen Angreifer einen
Weg zu den Userdaten bahnen können, und weil man annimmt, dass man durch
das Blockieren dieses Wegs die Userdaten schützt. Wenn es einen
direkteren Weg gibt, ist diese Annahme zumindest zweifelhaft.

hp

Arno Welzel

2022-08-06 09:05:13 UTC

Post by Arno Welzel
Wie genau soll Malware die Binaries installierter Anwendungen
modifizieren, wenn sie darauf keine Schreibrechte hat?

Die kann die Daten des ausführenden Users missbrauchen wie sie will -
ganz ohne Adminrechte.

Darum ging es aber nicht.

Falsch. *Alles* auf dem Computer ist schützenswert, nicht nur die Daten
des Users.

Beispiel:

Ein Browser, der z.B. für den Zugang auf Websites mit privaten Daten
genutzt wird, soll keine Hintertüren für Angreifer haben, die ihnen die
Daten, die er anzeigt, im Klartext zusenden oder die die Anzeige verfälscht.

Malware kann aber den Browser beliebig verändern oder gleich komplett
austausdchen, wenn die Installation keine administrativen Rechte
erfordert hat.

Ja, man kann auch so argumentieren, dass man ohnehin verloren hat,
sobald Malware zur Ausführung kommt und es dann auch egal ist, was die
Malware dann konkret macht. Dann kann man sich aber die Trennung
zwischen Administratorrechten und Benutzerrechten auf privat genutzten
Computern auch ganz sparen und das lediglich im Firmenumfeld so
handhaben, weil man da u.U. nicht möchte, dass Mitarbeiter an den
installierten Anwendungen etwas ändern.

--
Arno Welzel
https://arnowelzel.de

Peter J. Holzer

2022-08-06 11:31:56 UTC

Post by Peter J. Holzer
Doch, im Endeffekt geht es genau darum. Die Programme auf einem PC sind
für sich nicht schützenswert - sie sind weder geheim noch schwer zu
ersetzen. Die Daten des Users hingegen sind es. Die Programme zu

Falsch. *Alles* auf dem Computer ist schützenswert, nicht nur die Daten
des Users.

Warum schneidest Du den Teil des Absatzes weg, in dem ich genau auf
dieses Argument eingegangen bin?

hp

Arno Welzel

2022-08-11 16:31:36 UTC

Falsch. *Alles* auf dem Computer ist schützenswert, nicht nur die Daten
des Users.

Warum schneidest Du den Teil des Absatzes weg, in dem ich genau auf
dieses Argument eingegangen bin?

Weil ich die Aussage dieses Arguments nicht teile:

"Die Programme zu schützen ist nur deshalb sinnvoll, weil sie für einen
Angreifer einen Weg zu den Userdaten bahnen können, und weil man
annimmt, dass man durch das Blockieren dieses Wegs die Userdaten
schützt. Wenn es einen direkteren Weg gibt, ist diese Annahme zumindest
zweifelhaft."

Einen direkteren Weg als über die Programme gibt es halt nicht. Und ja,
auch "Malware als Datei abspeichern und dann ausführen", muss ein
*Programm* ermöglichen. Nur weil bei Windows jeder Müll, den man per
Browser herunterlädt, ausführbar sein darf, ändert nichts am Grundprinzip.

--
Arno Welzel
https://arnowelzel.de

Peter J. Holzer

2022-08-12 18:48:05 UTC

Falsch. *Alles* auf dem Computer ist schützenswert, nicht nur die Daten
des Users.

Warum schneidest Du den Teil des Absatzes weg, in dem ich genau auf
dieses Argument eingegangen bin?

Das ist halt schwer zu erkennen, wenn Du so tust, als ob es gar nicht
geschrieben worden wäre. So hat es nur nach dem Wiederholen eines
bereits widerlegten (oder zumindest bestrittenen) Arguments ausgesehen.

Post by Arno Welzel
"Die Programme zu schützen ist nur deshalb sinnvoll, weil sie für einen
Angreifer einen Weg zu den Userdaten bahnen können, und weil man
annimmt, dass man durch das Blockieren dieses Wegs die Userdaten
schützt. Wenn es einen direkteren Weg gibt, ist diese Annahme zumindest
zweifelhaft."
Einen direkteren Weg als über die Programme gibt es halt nicht.

Doch. Der Weg über vorhandene Programme ist nämlich immer ein
indirekter. Um die zu überschreiben, muss bereits Schadcode auf dem
angegriffenen Rechner laufen.[1] Der kann aber auch direkt seine
Tätigkeit durchführen, und muss nicht seine Payload irgendwo ablegen und
darauf warten/hoffen, dass sie der Benutzer irgendwann später ausführt.

Es kann durchaus Gründe geben, warum der indirekte Ansatz über
Executables sinnvoll oder sogar notwendig ist, aber es bleibt ein
indirekter Ansatz. Und wenn der direkte Weg (oder ein anderer indirekter
Weg, das ist ja nicht der einzige) möglich ist, dann bringt es halt
nicht viel, den indirekten zu blockieren.

hp

[1] Den Fall, dass man den Benutzer dazu bringt, das Executable selbst
zu überschreiben, ignoriere ich hier. Im Fall des Privat-PCs hat der
Benutzer ja Admin-Rechte und darf das (wenn auch mit einem weiteren
Schritt). Ebenso ignoriere ich mit dem Internet gesharte C-Laufwerke
und ähnliche Konfigurationsfehler.

Arno Welzel

2022-08-17 12:58:46 UTC

[..]

Post by Arno Welzel
Einen direkteren Weg als über die Programme gibt es halt nicht.

Doch. Der Weg über vorhandene Programme ist nämlich immer ein
indirekter. Um die zu überschreiben, muss bereits Schadcode auf dem
angegriffenen Rechner laufen.[1] Der kann aber auch direkt seine

[...]

Wofür wiederum ein Programm nötig ist, was es erlaubt, den Schadcode auf
den Rechner zu bekommen.

--
Arno Welzel
https://arnowelzel.de

Peter J. Holzer

2022-08-18 15:38:01 UTC

Post by Arno Welzel
Einen direkteren Weg als über die Programme gibt es halt nicht.

Doch. Der Weg über vorhandene Programme ist nämlich immer ein
indirekter. Um die zu überschreiben, muss bereits Schadcode auf dem
angegriffenen Rechner laufen.[1] Der kann aber auch direkt seine

[...]
Wofür wiederum ein Programm nötig ist, was es erlaubt, den Schadcode auf
den Rechner zu bekommen.

Aber dieses Programm muss schon da sein, es kann nicht durch den
Schadcode erst angelegt/überschrieben werden.

hp

Arno Welzel

2022-08-20 01:01:24 UTC

Post by Arno Welzel
Einen direkteren Weg als über die Programme gibt es halt nicht.

Doch. Der Weg über vorhandene Programme ist nämlich immer ein
indirekter. Um die zu überschreiben, muss bereits Schadcode auf dem
angegriffenen Rechner laufen.[1] Der kann aber auch direkt seine

[...]
Wofür wiederum ein Programm nötig ist, was es erlaubt, den Schadcode auf
den Rechner zu bekommen.

Aber dieses Programm muss schon da sein, es kann nicht durch den
Schadcode erst angelegt/überschrieben werden.

Was am Ergebnis nichts ändert - an dem, was in einem Computer vorgeht,
sind *immer* Programme beteiligt.

--
Arno Welzel
https://arnowelzel.de

Peter J. Holzer

2022-08-20 06:24:21 UTC

Post by Arno Welzel
Einen direkteren Weg als über die Programme gibt es halt nicht.

Doch. Der Weg über vorhandene Programme ist nämlich immer ein
indirekter. Um die zu überschreiben, muss bereits Schadcode auf dem
angegriffenen Rechner laufen.[1] Der kann aber auch direkt seine

[...]
Wofür wiederum ein Programm nötig ist, was es erlaubt, den Schadcode auf
den Rechner zu bekommen.

Aber dieses Programm muss schon da sein, es kann nicht durch den
Schadcode erst angelegt/überschrieben werden.

Was am Ergebnis nichts ändert - an dem, was in einem Computer vorgeht,
sind *immer* Programme beteiligt.

Das hat auch niemand bestritten. Die Frage war, ob die Installation
eines Programms unter einer anderen User-Id als der, mit der der User
normalerweise arbeitet, die Sicherheit des Gesamtsystems wesentlich
erhöht.

hp

Takvorian

2022-08-20 07:06:15 UTC

Post by Peter J. Holzer
Die Frage war, ob die Installation
eines Programms unter einer anderen User-Id als der, mit der der User
normalerweise arbeitet, die Sicherheit des Gesamtsystems wesentlich
erhöht.

Alberne Frage, denn selbstverständlich erhöht Rechtetrennung die Sicherheit
des Systems und auch der Anwenderdaten erheblich.

Peter J. Holzer

2022-08-20 07:53:05 UTC

Die Frage war, ob die Installation eines Programms unter einer
anderen User-Id als der, mit der der User normalerweise arbeitet, die
Sicherheit des Gesamtsystems wesentlich erhöht.

Alberne Frage, denn selbstverständlich erhöht Rechtetrennung die
Sicherheit des Systems und auch der Anwenderdaten erheblich.

Als selbstverständlich sollte man in IT-Security gar nichts ansehen. Man
muss sich immer überlegen, wie die Angriffsszenarien aussehen und welche
Maßnahmen für diese Szenarien effektiv sind. (Wird leider in der Praxis
oft nicht gemacht - Cargo-Culting ist weit verbreitet und oft werden
noch Maßnahmen neu eingeführt, die in der Literatur schon seit 10-15
Jahren als kontraproduktiv gelten.)

Auf einem Multiuser-System ist ein Angriffsszenario, dass ein User Daten
eines anderen unberechtigt lesen oder ändern möchte. Das lässt sich mit
einem Berechtigungssystem auf (User, File)-Basis effektiv verhindern.

Auf einem Single-User-System aber existiert dieses Szenario nicht.
Dafür gibt es ein paar andere:
* Eine Applikation gibt unberechtigt Daten nach außen
* Daten aus externer Quelle führen dazu, dass Programme unerwünschtes
Verhalten zeigen
* Beobachtung des Systems offenbart kritische Informationen

Etc.

Es ist jedenfalls nicht offensichtlich, dass die Trennung in
"System+Programme" und "Daten" und die Vergabe von Rechten für zwei
User-Ids ("Admin" und "User") in diesen Szenarien effektiv schützt.

Das müsstest Du also belegen. Idealerweise an Hand realer Beispiele.

hp

Takvorian

2022-08-20 09:02:28 UTC

Die Frage war, ob die Installation eines Programms unter einer
anderen User-Id als der, mit der der User normalerweise arbeitet, die
Sicherheit des Gesamtsystems wesentlich erhöht.

Alberne Frage, denn selbstverständlich erhöht Rechtetrennung die
Sicherheit des Systems und auch der Anwenderdaten erheblich.

Als selbstverständlich sollte man in IT-Security gar nichts ansehen. Man
muss sich immer überlegen, wie die Angriffsszenarien aussehen und welche
Maßnahmen für diese Szenarien effektiv sind.

Hat man ja getan, das Ergebnis ist in modernen OSen deutlich sichtbar.

Post by Peter J. Holzer
(Wird leider in der Praxis
oft nicht gemacht - Cargo-Culting ist weit verbreitet und oft werden
noch Maßnahmen neu eingeführt, die in der Literatur schon seit 10-15
Jahren als kontraproduktiv gelten.)

Rechtetrennung gehört nicht dazu.

Post by Peter J. Holzer
Auf einem Multiuser-System ist ein Angriffsszenario, dass ein User Daten
eines anderen unberechtigt lesen oder ändern möchte. Das lässt sich mit
einem Berechtigungssystem auf (User, File)-Basis effektiv verhindern.
Auf einem Single-User-System aber existiert dieses Szenario nicht.
* Eine Applikation gibt unberechtigt Daten nach außen
* Daten aus externer Quelle führen dazu, dass Programme unerwünschtes
Verhalten zeigen
* Beobachtung des Systems offenbart kritische Informationen
Etc.

Insbesondere die Daten aus externer Quelle, die man als Malware bezeichnet,
können durch Rechtetrennung recht effektiv abgewehrt werden.

Post by Peter J. Holzer
Es ist jedenfalls nicht offensichtlich, dass die Trennung in
"System+Programme" und "Daten" und die Vergabe von Rechten für zwei
User-Ids ("Admin" und "User") in diesen Szenarien effektiv schützt.
Das müsstest Du also belegen. Idealerweise an Hand realer Beispiele.

Nun, das beweist sich doch täglich im praktischen Einsatz. Ein System, so
konfiguriert wie hier z.B. vorgeschlagen
https://skanthak.homepage.t-online.de/SAFER.html
ist erheblich sicherer als ohne diese Konfiguration.
Und via Whitelisting kann man zusätzlich noch sämtlichen Programmen den
Zugriff auf wichtige Daten verweigern, außer den erlaubten. Dazu muss ich
doch nichts belegen.

Peter J. Holzer

2022-08-20 10:12:21 UTC

Die Frage war, ob die Installation eines Programms unter einer
anderen User-Id als der, mit der der User normalerweise arbeitet, die
Sicherheit des Gesamtsystems wesentlich erhöht.

Alberne Frage, denn selbstverständlich erhöht Rechtetrennung die
Sicherheit des Systems und auch der Anwenderdaten erheblich.

Als selbstverständlich sollte man in IT-Security gar nichts ansehen. Man
muss sich immer überlegen, wie die Angriffsszenarien aussehen und welche
Maßnahmen für diese Szenarien effektiv sind.

Hat man ja getan, das Ergebnis ist in modernen OSen deutlich sichtbar.

Rechtetrennung gehört nicht dazu.

Richtig, weil Multi-User-Systeme verbreitet sind, und die Rechtetrennung
dort (für einige, aber nicht alle Szenarien) effektiv ist.

Aber es gibt halt auch Single-User-Systeme. Vom durchschnittlichen
privaten Laptop bis zu Smartphones.

Und da ist die Trennung in zwei Bereiche IMHO zumindest zweifelhaft.

Und bei Smartphones z.B. sieht die Berechtigungsstruktur daher auch
deutlich anders aus: Da wird nicht zwischen "Admin" und "User"
unterschieden, sondern jede App bekommt ihre eigenen Berechtigungen.

Insbesondere die Daten aus externer Quelle, die man als Malware bezeichnet,
können durch Rechtetrennung recht effektiv abgewehrt werden.

[citation needed]

Eben das bezweifle ich. Ich bin in der Windows-Welt nicht so zuhause,
aber was ich über diverse im Umlauf befindliche Malware lese, scheint
mir das eben nicht sonderlich effektiv zu sein (d.h. die Malware
verbreitet sich trotzdem).

Aber Du kannst gerne der Behauptung Daten folgen lassen: Such Dir eine
Handvoll aktueller Malware heraus, erkläre den Einfallsvektor und wie
die Zweiteilung der Berechtigungen diesen effektiv unterbindet (und ja,
mir ist klar, dass ich Dir mit "such dir ..." einen riesigen
Heimvorteil verschafft habe).

Auch das ist erstmal nur eine Behauptung, die zu belegen wäre. Abgesehen
davon geht das aber deutlich über den Ausgangspunkt der Diskussion
hinaus.

Post by Takvorian
Und via Whitelisting kann man zusätzlich noch sämtlichen Programmen den
Zugriff auf wichtige Daten verweigern, außer den erlaubten. Dazu muss ich
doch nichts belegen.

Wenn ich mich recht erinnere, hatte ich das schon in die Diskussion
eingebracht, ja.

hp

Takvorian

2022-08-21 13:40:48 UTC

Die Frage war, ob die Installation eines Programms unter einer
anderen User-Id als der, mit der der User normalerweise arbeitet, die
Sicherheit des Gesamtsystems wesentlich erhöht.

Alberne Frage, denn selbstverständlich erhöht Rechtetrennung die
Sicherheit des Systems und auch der Anwenderdaten erheblich.

Als selbstverständlich sollte man in IT-Security gar nichts ansehen. Man
muss sich immer überlegen, wie die Angriffsszenarien aussehen und welche
Maßnahmen für diese Szenarien effektiv sind.

Hat man ja getan, das Ergebnis ist in modernen OSen deutlich sichtbar.

Rechtetrennung gehört nicht dazu.

Gerade auch für diese ist
https://skanthak.homepage.t-online.de/SAFER.html
extrem wichtig, da hier meist DAUs und ONUs am Werke sind. Man kann Systeme
auf die Weise recht effektiv versiegeln.

Post by Peter J. Holzer
Und bei Smartphones z.B. sieht die Berechtigungsstruktur daher auch
deutlich anders aus: Da wird nicht zwischen "Admin" und "User"
unterschieden, sondern jede App bekommt ihre eigenen Berechtigungen.

Der Smartphone-Bereich ist eh ein Grauen für sich.

Insbesondere die Daten aus externer Quelle, die man als Malware bezeichnet,
können durch Rechtetrennung recht effektiv abgewehrt werden.

Wenn alle Systeme von Microsoft OOBE so eingestellt wären wie im obigen Link
beschrieben, würde sich das sehr deutlich ändern. Leider macht Microsoft das
Gegenteil: es unterstützt sogar noch lausigen Schrott, der sich nicht an die
Windows-Regeln hält, durch Wirrtualisierung. Und Schlangenöl ist kein
Schutz, sondern macht Systeme eher unsicherer als sie vorher waren.

Post by Peter J. Holzer
Aber Du kannst gerne der Behauptung Daten folgen lassen: Such Dir eine
Handvoll aktueller Malware heraus, erkläre den Einfallsvektor und wie
die Zweiteilung der Berechtigungen diesen effektiv unterbindet (und ja,
mir ist klar, dass ich Dir mit "such dir ..." einen riesigen
Heimvorteil verschafft habe).

Das ergibt sich ja schon aus dem Lesen der Seite und der INFs, deren Inhalt
genau beschreibt, was Malware dann nicht mehr kann. Und auch gegen
E-Mail-Malware:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc740025(v=ws.10)?redirectedfrom=MSDN

Auch das ist erstmal nur eine Behauptung, die zu belegen wäre. Abgesehen
davon geht das aber deutlich über den Ausgangspunkt der Diskussion
hinaus.

Effektive Rechtetrennung ist halt wesentlich mehr als nur die Existenz eines
Admin- und eines User-Kontos, die nur die Grundvoraussetzung, das Fundament
darstellen. Sieht man recht schön, wenn man sich den Inhalt der INFs
anschaut.

Arno Welzel

2022-08-21 15:12:52 UTC

Alberne Frage, denn selbstverständlich erhöht Rechtetrennung die Sicherheit
des Systems und auch der Anwenderdaten erheblich.

Nicht zwangsläufig.

Wenn man unter Windows ein Programm startet, hat es erstmal Zugriff auf
*alle* Daten des User, der es gestartet hat. Das ändert sich auch nicht,
wenn zur Installation Administrationsrecht nötig sind. Es hängt
wesentlich vom Programm ab, ob es keine bösen Dinge tut.

Allerdings: wenn man weiß, dass ein Programm vertrauenswürdig ist und
keine ausnutzbaren Sicherslücken hat, sollte man dafür sorgen, dass auch
Malware daran nichts ändern kann. Und das wiederum ist einfacher, wenn
die Programmdateien nicht ohne administrative Rechte verändert werden
dürfen. Ebenfalls hilfreich für die Sicherheit ist es dann auch, wenn
man überhaupt gar keine Programme starten kann, die nicht explizit
vorher mit administrativen Rechten an den dafür vorgesehenen Stellen
eingerichtet wurden. Windows bietet dafür mit SAFER Möglichkeiten an,
Linux mit SELinux. Und bei Systemen wie Android geht man noch einen
Schritt weiter und erlaubt Programmen gar keinen Zugriff mehr außer auf
ihre eigenen Daten und APIs, die der Benutzer aber explizit freigeben muss.

--
Arno Welzel
https://arnowelzel.de

Arno Welzel

2022-08-21 15:01:48 UTC

[...]

Post by Arno Welzel
Was am Ergebnis nichts ändert - an dem, was in einem Computer vorgeht,
sind *immer* Programme beteiligt.

Das kommt auf das System an und wie es Rechtetrennung durchsetzt.

--
Arno Welzel
https://arnowelzel.de

Martin Gerdes

2022-08-06 13:45:20 UTC

[Die Installation ausführbarer Programme im User-Datenbereich] ist
leider bei etlichen Anwendungen mittlerweile üblich, weil man
so [zur Installation dieser Software] keine administrativen Rechte
braucht - aber es ist eben auch unsicher, weil so Malware natürlich
die Daten ebenfalls leicht manipulieren kann.

Das kann Malware aber auch ganze ohne die Installation in AppData.

Das stimmt natürlich.

Damit Malware wirken kann, muß sie cum grano salis im System erstmal
installiert sein. Dabei ist es egal, ob sie im Programmbereich
installiert ist, der deswegen offen ist (weil der betreffende Anwender
immer als Admin unterwegs ist) oder im Datenbereich des Anwenders (weil
dessen System wie die allermeisten Windowssysteme die Ausführung von
Programme im Anwender-Datenbereich erlaubt).

Post by Arno Welzel
Wie genau soll Malware die Binaries installierter Anwendungen
modifizieren, wenn sie darauf keine Schreibrechte hat?

Es ging oben um die Manipulation von Daten, nicht um die Binaries
installierter Anwendungen.

Post by Marco Moock
Wer der Software nicht traut, sollte sie nicht auf dem Produktivsystem
ausführen.

Und wer Software traut, sollte sie nicht so installieren, dass sie von
Malware jederzeit leicht verändert werden kann.

Anderes Thema.

Post by Marco Moock
Und mit Adminrechten kann man de facto auf alles im System zugreifen.

Malware hat aber üblicherweise keine Adminrechte.

Oft hat sie sie, weil der betreffende Anwender eben Adminrechte hat. Das
liegt bei Windows auch nahe, weil die Anwender eines Windowssystems aus
der Schachtel alle Admin-Rechte haben. Will man diese Sicherheitslücke
schließen, muß man sich aktiv ein Nutzerkonto anlegen, das keine
Admin-Rechte hat. Das machen viele Leute aber nicht. Die Mehrzahl der
Privatanwender dürfte daher ständig als Admin unterwegs sein.

Lutz E. Cerning

2022-08-04 17:37:21 UTC

Post by Lutz E. Cerning
vorhin habe ich mir den aktuellwn Comium-Browser von

Ihr habt ja recht - habs wieder deinstalliert.
Warum machen die so was? Die sind doch nicht blöde, diese ganze Masse
von Leuten die an so einem (freien) Browser arbeiten, na ja...

--
Grüße von LutzeC*54 aus
(ca.) 52.64736,13.550518

Stefan Kanthak

2022-08-04 18:55:00 UTC

Post by Lutz E. Cerning

Post by Lutz E. Cerning
vorhin habe ich mir den aktuellwn Comium-Browser von

Ihr habt ja recht - habs wieder deinstalliert.
Warum machen die so was? Die sind doch nicht blöde,

Aber UNFAEHIG und SCHLAMPIG!
Das erkennst Du beispielsweise am XML-Tag
<maxversiontested Id="10.0.18362.0"/>
des in den ausfuehrbaren (IGITT!) Installationsprogrammen eingebetteten
Manifests: 10.0.18362.0 ist Windows 10 1903, das von Microsoft seit
ueber zwei Jahren NICHT mehr gepflegt wird.
Ausserdem am Missbrauch einer VERALTETEN Entwicklungsumgebung und
deren UNSICHEREN statischen libcmt.lib: die Programme wurden mit
LINK.exe 14.0 fuer Windows XP bzw. Windows 2003 als Zielsystem gebunden.

Alternativ daran, dass ADVAPI32.dll als "delay load" gebunden wurde:
das ist VOELLIGER SCHWACHSINN, denn ADVAPI32.dll ist seit Anbeginn der
eNTe eine "known DLL" (im Gegensatz zu dbghelp.dll, winmm.dll und
EINIGEN anderen DLLs, die diese AHNUNGSLOSEN Frickler aus dem
"application directory" laden lassen).
Und zu schlechterletzt noch daran, dass dieses DREXZEUX anfaellig fuer
DLL-Hijacking ist.

Post by Lutz E. Cerning
diese ganze Masse von Leuten die an so einem (freien) Browser arbeiten,
na ja...

"Viele Koeche verderben den Brei!"

EINMAL mit Profis arbeiten...
Stefan

--
<https://www.duden.de/rechtschreibung/Kanthaken>

Arno Welzel

2022-08-05 08:08:37 UTC

Post by Lutz E. Cerning

Post by Lutz E. Cerning
vorhin habe ich mir den aktuellwn Comium-Browser von

Ihr habt ja recht - habs wieder deinstalliert.
Warum machen die so was? Die sind doch nicht blöde, diese ganze Masse
von Leuten die an so einem (freien) Browser arbeiten, na ja...

Die Leute, die den Kern von Chromium entwickeln sind *nicht* die Leute,
die die Windows-Version daraus erstellen!

--
Arno Welzel
https://arnowelzel.de

Martin Gerdes

2022-08-06 13:45:16 UTC