+comunity+ AUP - Acceptable/Apropriate Use Policy Vorschlag

[jogi hofmueller]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi!

ein kurzer update/input meinerseits zur laufenden diskussion:

add portscanning/portprobing:

* die diskussion ueber boese absichten oder nicht ist IMHO reine
meinungs/ansichtssache. meine ansicht ist die, das portscanning - mit
wenigen ausnahmen - immer boese absichten impliziert. andere sind anderer
meinung.

* vergleiche mit der realen welt hinken leider sehr. ein port ist z.b.
keine autotuer, ein rechner kein parkplatz ... oder kein auto.

* ob portscanning in oesterreich verbotenist oder nicht, tut in dieser
diskussion nicht wirklich was zur sache. ich bin trotzdem - schon alleine
aus interesse - am recherchieren und halte euch auf dem laufenden.

* die geschichte mit dem knowbotic research project ist auch hier bekannt.
trotz langem studium der website ist mir die intention des projektes nach
wie vor nicht klar. dass eine diskussion ausgeloest wurde ist toll genug,
wobei ich hier auf den 'paranoiden US zustand' verweisen moechte, in
dessen kontext das zu sehen ist. ein zitat aus reinhards mail moecht ich
hier trotzdem kommentieren:

> If we published the precise vulnerabilities of the public domain in the
> networks, the 18 U.S.C. 1030 Fraud and Related Activity in Connection
> with Computers would make us hackers=terrorists.

1. hab ich ein eindeutiges verhaeltnis zum begriff hacker: hacker !=
cracker (hacker ist nicht cracker).

2. waere es mir egal, ob irgendein gesetz die veroeffentlichung von
schwachstellen (vulnerabilities) kriminalisiert oder nicht, weil das per
se schon idiotisch ist bzw. eine einladung, die schwachstellen zu
missbrauchen.

3. daher: wenn mensch glaubt, irgendwo schwachstellen zu bemerken,
empfehle ich persoenlich die verstaendigung der verantwortlichen.

aber vielleicht hat das alles gar nix mit dem projekt zu tun :)

add resourcenverschwendung - 'grosse' emails:

* die 'praxis' grosse dateien via email zu versenden ist mir allzu bekannt
:) leider ist diese praxis dazu angetan, ansonsten recht leistungsfaehgie
systeme ziemlich zu behindern, weil MTAs (die software, die mail hin und
her schickt) mail komplett in den RAM einer maschine kopieren. wer sich
hin und wieder auf fox.mur.at einlogged (ssh) wird bemerken, dass die
maschine von zeit zu zeit 'langsam' wird. der grund dafuer sind meistens
grosse emails ...

gefragt waere hier ein 'limit', dass einen kompromiss zwischen
gewuenschter attachmentgroesse und systemvertraeglichkeit darstellt.
vorschlaege?

dank nochmal allen, die sich bisher in die debatte eingemischt haben.
etwas weniger als zwie wochen bleiben noch, um an dem papier rumzuwerkeln
und verbesserungen anzubringen.

gruss
- -- 
j.h.
jogi hofmueller <jogi at mur.at>
	GPG-public-key: http://mur.at/~jogi/text/public.key.txt
	or
	wwwkeys.at.pgp.net[:11371]
	GPG-key-ID: B972CEC1
	Key fingerprint: 2CD5 4786 AA9E F315 6430  868F 00FA E375 B972 CEC1




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/

iD8DBQE+dd5WAPrjdblyzsERApFZAKDTrv9GkS+ZK1x6Y3vyLng08ryLtgCfT6od
df7NsnXTZ1VPqvCiByPz4+I=
=JEXD
-----END PGP SIGNATURE-----