Re: Hat die Mehrheit JavaScript abgestellt?
Georg Maaß
> Newsgroups: de.comm.infosystems.www.authoring.misc,de.comp.lang.javascript
> Followup-To: de.comm.infosystems.www.authoring.misc
>
> Eine Meldung
>
> http://www.heise.de/newsticker/meldung/print/66952
>
> des Unternehmens "Heise Zeitschriften Verlag GmbH & Co. KG"
> kann man so interpretieren, daß ein größerer Teil der
> Benutzer als bisher vermutet JavaScript deaktiviert hat.
>
> Dort steht nämlich:
>
> "doch trotz zahlreicher Warnungen surfen weiterhin rund
> 40 Prozent mit offenem Visier, sprich mit eingeschaltem
> Active Scripting."
>
> Der Meldung zufolge haben also wohl 60 Prozent dann
> ActiveScripting deaktiviert. Nun ist das zwar begrifflich
> nicht genau das gleiche wie JavaScript, aber wenn man beim
> Microsoft® Internet Explorer "ActiveScripting" aktiviert oder
> deaktiviert wird damit, soweit ich weiß, JavaScript aktiviert
> oder deaktiviert.
>
Aber es surfen doch nur noch 2% mit etwas anderem als Mozilla, Firefox,
Opera, iCab oder Safari. Wer Ie zu etwas wnderem verwendet, als zum die
neues Microsoft Patsche runter zuholen oder um sich einen der genannten
Browser zu organisieren, ist selber schuld.
Die Mehrheit der IE-Surfer unter den c't Lesern mag zwar ActivScripting
abgeschaltet haben, weil sie es vielleicht nach einem Schädlingstest bei
Heise einfach vergessen haben, wieder einzuschalten. Aber repräsentativ
sind sie damit noch lange nicht. Das Media-Center bei GMX geht ohne
JavaScript gar nicht. Wenn man Popups blockt, geht es auch nicht.
Zumglück geht dort vieles über WebDAV, so daß man sich an der
Popup-Penetranz für die meisten Dinge vorbeimogeln kann.
Wenn Du JavaScript irgendwo brauchst, mache eine Beschreibung dazu, was
Du alles brauchst und wozu, damit der User seinen Browser so
konfigurieren kann, daß er die benötigten Features freischaltet.
Gruß, Georg
Thomas 'PointedEars' Lahn
> Newsgroups: de.comm.infosystems.www.authoring.misc,de.comp.lang.javascript
> Followup-To: de.comm.infosystems.www.authoring.misc
Was soll das? Wer Header lesen kann, weiss wo er sie findet.
> Eine Meldung
>
> http://www.heise.de/newsticker/meldung/print/66952
>
> des Unternehmens "Heise Zeitschriften Verlag GmbH & Co. KG"
> kann man so interpretieren, daß ein größerer Teil der
> Benutzer als bisher vermutet JavaScript deaktiviert hat.
Man könnte, aber diese Interpretation wäre föllig vhcals.
> Dort steht nämlich:
>
> "doch trotz zahlreicher Warnungen surfen weiterhin rund
> 40 Prozent mit offenem Visier, sprich mit eingeschaltem
> Active Scripting."
Diese Aussage ist _so_ falsch, darauf basierende
Schlussfolgerungen sind ergo per se falsch.
Da steht nämlich:
| Internet-Explorer-Loch: Rund 40 Prozent surfen ungeschützt
|
| [...] doch trotz zahlreicher Warnungen surfen weiterhin rund 40 Prozent
| mit offenem Visier, sprich mit eingeschaltem Active Scripting. Das lässt
| sich der laufenden Statistik des Internet Storm Center[2] entnehmen, die
| die Zero-Day-Verwundbarkeit der Browser der Besucher im Verlauf der
| letzten Stunde ausgibt. Auf der Seite bekommt man zudem sofort Aufschluss
| über die eigene Verwundbarkeit: " You are considered [not] vulnerable".
Zitat (mit inzwischen latür veränderten Zahlen, z.B. habe ich
gerade mit Firefox vorbeigeschaut):
,-[[2] <URL:http://isc.sans.org/>]
|
| Over the last hour, 33 % of the visitors to this site were
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| vulnerable to the Internet Explorer 0-day exploit."
^^^^^^^^^^^^^^^^^ ^^^^^^^
Zitat Ende.
> Der Meldung zufolge haben also wohl 60 Prozent dann
> ActiveScripting deaktiviert.
Nein. Korrekt interpretiert bedeutet das nichts weiter als:
,-----------------------------------------------------------------------.
| Web-Benutzer weltweit |
| ,--------------------------------------------------------------------.|
| | Benutzer von Windows ab NT 3.x (lt. M$) ||
| | ,-----------------------------------------------------------------.||
| | | IE-Benutzer |||
| | | ,--------------------------------------------------------------.|||
| | | | Besucher dieser Website ||||
| | | | ,-----------------------------------------------------------.||||
| | | | | Besucher, die ActiveScripting aktiviert hatten |||||
| | | | | ,--------------------------------------------------------.|||||
| | | | | | Aussage: ||||||
| | | | | | Besucher, deren Browser anfällig für den Exploit waren ||||||
| | | | | `--------------------------------------------------------'|||||
| | | | `-----------------------------------------------------------'||||
| | | `--------------------------------------------------------------'|||
| | `-----------------------------------------------------------------'||
| `--------------------------------------------------------------------'|
`-----------------------------------------------------------------------'
Da es an einem Patch mangelt:
,-----------------------------------------------------------------------.
| Web-Benutzer weltweit |
| ,--------------------------------------------------------------------.|
| | Benutzer von Windows ab NT 3.x (lt. M$) ||
| | ,-----------------------------------------------------------------.||
| | | IE-Benutzer |||
| | | ,--------------------------------------------------------------.|||
| | | | Besucher dieser Website ||||
| | | | ,-----------------------------------------------------------.||||
| | | | | Aussage: Besucher, die ActiveScripting aktiviert hatten |||||
| | | | `-----------------------------------------------------------'||||
| | | `--------------------------------------------------------------'|||
| | `-----------------------------------------------------------------'||
| `--------------------------------------------------------------------'|
`-----------------------------------------------------------------------'
Wer rechnen kann, ist hier klar im Vorteil. Lies mehr <dciwam/>,
z.B. Steffi Abel würde Dir die Zahlen zu Recht um die Ohren hauen.
> Nun ist das zwar begrifflich nicht genau das gleiche wie JavaScript,
Richtig.
> aber wenn man beim Microsoft® Internet Explorer "ActiveScripting"
> aktiviert oder deaktiviert wird damit, soweit ich weiß, JavaScript
> aktiviert oder deaktiviert.
Clientseitiger Script-Support wird damit aktiviert oder deaktiviert,
d.h. Support für JScript und VBScript.
F'up2 ignoriert und neu gesetzt
PointedEars
Artur Weißgerber
>> Newsgroups: de.comm.infosystems.www.authoring.misc,de.comp.lang.javascript
>> Followup-To: de.comm.infosystems.www.authoring.misc
>
> Was soll das? Wer Header lesen kann, weiss wo er sie findet.
Es gilt aber als unhöflich, unangekündigte X-Posts und F'Ups zu posten...
Gruß,
Artur
Christoph Schneegans
> http://www.heise.de/newsticker/meldung/print/66952 (...) kann man so
> interpretieren, daß ein größerer Teil der Benutzer als bisher vermutet
> JavaScript deaktiviert hat.
Nein, es geht doch nur um die Besucher von <http://isc.sans.org/>,
repräsentativ sind die Zahlen also nicht, und die Meldung von Heise ist
einfach nur irreführend.
--
<http://schneegans.de/> |
Thomas 'PointedEars' Lahn
Deshalb muss man noch lange keine Header duplizieren.
X-Post & F'up2 dsnu
PointedEars
David Dahlberg
>> Dort steht nämlich:
>>
>> "doch trotz zahlreicher Warnungen surfen weiterhin rund
>> 40 Prozent mit offenem Visier, sprich mit eingeschaltem
>> Active Scripting."
>
>Diese Aussage ist _so_ falsch, darauf basierende
>Schlussfolgerungen sind ergo per se falsch.
Also ähm, nein. Richtig!
Ex falso quodlibet.
Aber so falsch ist die Aussage garnicht: Das steht ja genaugenommen
nur was über, dass 40% aller User -- nämlich welchen, die mit
aktiviertem Active Scripting surfen. Tatsächlich steht da jedoch
nichts über die restlichen 60%. Die surfen nämlich auch mit
aktiviertem Active Scripting, oder eben nicht.
>,-[[2] <URL:http://isc.sans.org/>]
>|
>| Over the last hour, 33 % of the visitors to this site were
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>| vulnerable to the Internet Explorer 0-day exploit."
> ^^^^^^^^^^^^^^^^^ ^^^^^^^
>Zitat Ende.
So wird nämlich ein Schuh draus: 33% der Nutzer surfen mit dem IE
UND eingeschaltetem JavaScript UND sind verwundbar bzgl. diesen
Exploits. (Was du im weiteren ja auch genau richtig beschreibst.)
Nur mal klugscheißen wollend:
David
Irmgard Schwenteck
> Aber es surfen doch nur noch 2% mit etwas anderem als Mozilla, Firefox,
> Opera, iCab oder Safari. Wer Ie zu etwas wnderem verwendet, als zum die
> neues Microsoft Patsche runter zuholen oder um sich einen der genannten
> Browser zu organisieren, ist selber schuld.
Und wer in seiner Firma das nehmen muß, was er auf seinem PC vorfindet?
Es ist eher selten, daß sich da ein Nutzer die Software seiner Wahl
installieren darf.
Meine Schwester arbeitet in $Großunternehmen. Standardbrowser ist IE.
Nach Bekanntwerden der letzten Sicherheitslücken ist kurzerhand für alle
(mehrere 100 Leute) JS deaktiviert worden.
Ende und aus.
> Wenn Du JavaScript irgendwo brauchst, mache eine Beschreibung dazu, was
> Du alles brauchst und wozu, damit der User seinen Browser so
> konfigurieren kann, daß er die benötigten Features freischaltet.
Jetzt denkt sie ersthaft über einen Providerwechsel nach, weil das
webmail von 1&1 nur mit JS funktioniert.
Gruß
Irmgard
Jascha Lendeckel
> Jetzt denkt sie ersthaft über einen Providerwechsel nach, weil das
> webmail von 1&1 nur mit JS funktioniert.
Na ja, Gott sei Dank gibt es ja noch alternativen zum webmail. Bei
Leuten die viel unterwegs sind, kann ich es verstehen, das Sie mit
Webmail arbeiten aber privat lese ich alle meine Email mit
Mozilla/Thunderbird. Ein Providerwechsel ist also nicht zwingend
erforderlich.
Eine weiter Möglichkeit währe die Einrichtung eines Kontos bei Web.de
oder GMX und eine E-Mail-Weiterschaltung bei 1und1. Ausgehende Mails
können ja nach wie vor über 1und1 laufen.
Gruß Jascha
Michael Fesser
>Juergen Arnold <news.juer...@gmx.de> schrieb:
>
>>Ich persönlich sehe das ganz locker: wer mich ohne JavaScript *nicht*
>>will, kann auf mich als Kunden verzichten. Die Ausnahmen, bei denen
>>*ich* ein Angebot *unbedingt* wahrnehmen wollte und aus einzig diesem
>>Grund JavaScript aktiviert habe, sind *sehr* überschaubar...
>
>Das finde ich eine assoziale Haltung!
Warum? Als genauso assozial könnte man es dann bezeichnen, wenn Firmen
ihre Werbung auf Kosten der Benutzer verbreiten, anstatt selbst dafür zu
bezahlen. Oder kriegt der Benutzer etwa den Traffic bezahlt, den ihm
Werbebanner und ähnlicher Schmonz verursachen?
>Wenn mir eine redaktionelle
>Webseite gut gefällt, klicke ich dort auch auf einen Werbebanner.
Erwarte nicht, daß sich das jeder freiwillig antut. _Niemand_ hat im WWW
um Werbung und Kommerz gebettelt, es gab auch vorher hochwertige Inhalte
_ohne_ Werbung und die wird es auch weiterhin geben.
>Nur
>so bekommen die Redakteure und Betreiber auch etwas für Ihren Einsatz,
>der sich in der Regel eh nie auszahlt.
Deren Problem, nicht meins. Man kann von einem Besucher nicht verlangen,
auf Werbebanner zu klicken bzw. sich diese überhaupt anzuschauen. Darauf
zu vertrauen oder gar ein Geschäftsmodell darauf zu basieren ist
schlichtweg blauäugig und ignoriert selbst die simpelsten technischen
Grundlagen des WWW.
Wie soll z.B. ein Besucher auf ein Werbebanner klicken, wenn er es in
seinem Textbrowser überhaupt nicht zu sehen bekommt? Müssen wir deswegen
ab sofort sämtliche Textbrowser verbieten, nur damit die Firmen zu ihrem
ach so wichtigen Geld kommen? Und PDAs/Handys gleich mit? Nicht zu
vergessen Screenreader und ähnliches kommerzfeindliches Teufelszeug.
Werbung auf einer Braillezeile - das wärs.
Letztlich ist es _immer_ der Benutzer allein, der entscheidet, was,
wieviel und in welcher Form er den Inhalt einer Website nutzen möchte.
Das ist eine der Grundlagen von HTML. Jeder Benutzer hat das Recht, ihm
ungenehme oder unnütze Dinge auszublenden bzw. einen Browser zu
verwenden, der sich auf das Wesentliche konzentriert, nämlich den
nackten Inhalt. Daran ist nichts assoziales.
Das eigentliche Problem ist, daß viele Firmen das noch nicht kapiert
haben, sich dafür aber lauthals über Verluste ihres WWW-"Geschäfts" und
mangelnde Werbeeinnahmen beklagen.
>Ich denke aber, in ein paar Jahren ist das Vorbild der Stiftung
>Warentest akkzeptiert, dass man für den Content im Internet zahlen
>muss.
Sicher nicht.
>Im Moment findet man kaum noch seriöse Testberichte im Internet,
>da fast alle Tester inzwischen Geld für Ihre Auswertungen haben
>möchten. Spiegel Online will für alles, was ein paar Monate alt ist,
>auch schon Geld sehen, und in dem Moment, wo man für Spiegel Online
>ein Abo abschließen muss, ist das deutsche Internet endlich
>kommerziell geworden.
Es wird auch immer freie Alternativen geben. Eine reine
Kommerzgesellschaft wäre der Untergang des WWW.
>Und ein Großteil der Schuld daran haben Leute, die Adblock&Co.
>einsetzen und auch sonst nie auf Werbung klicken.
Flacsh.
>Wie soll man sonst
>eine echte unabhängige Redaktion bezahlen?
Zumindest nicht mit Werbung im WWW.
Micha
Konni Scheller
> Wenn mir eine redaktionelle
> Webseite gut gefällt, klicke ich dort auch auf einen Werbebanner.
Das ist ja eigentlich nicht der Sinn der Werbebanner. Du sollst drauf
klicken, wenn dich das Beworbene interessiert ;)
(in dem Zusammenhang ist GoogleAdSense unschlagbar.)
> Ich denke aber, in ein paar Jahren ist das Vorbild der Stiftung
> Warentest akkzeptiert, dass man für den Content im Internet zahlen
> muss.
Hm, nein. Das wird alle paar Jahre ausprobiert und geht regelmäßig in
die Hose.
> Spiegel Online will für alles, was ein paar Monate alt ist,
> auch schon Geld sehen,
Klappt auch mehr schlecht als recht.
> Und ein Großteil der Schuld daran haben Leute, die Adblock&Co.
> einsetzen und auch sonst nie auf Werbung klicken. Wie soll man sonst
> eine echte unabhängige Redaktion bezahlen?
Du kannst doch nicht ersthaft jemanden vorschreiben wollen, dass er auf
Werbebanner klicken soll, um die Anzeigenseite zu finanzieren? Das ist
nämlich auch nicht im Sinne der Werbenden.
Servus,
Konni
--
http://www.scharfe-wochen.de/ - Meerrettichspezialitäten und Rezepte
Im Oktober wird verschärft gekocht
Rudolf Polzer
> Juergen Arnold <news.juer...@gmx.de> schrieb:
> >Ich persönlich sehe das ganz locker: wer mich ohne JavaScript *nicht*
> >will, kann auf mich als Kunden verzichten. Die Ausnahmen, bei denen
> >*ich* ein Angebot *unbedingt* wahrnehmen wollte und aus einzig diesem
> >Grund JavaScript aktiviert habe, sind *sehr* überschaubar...
>
> Das finde ich eine assoziale Haltung!
Was ist daran asozial, sich nicht immer den unsichersten Browser mit der
unsichersten Konfiguration zu holen, damit die Werbung gut funktioniert?
Mir persönlich ist meine Privatsphäre wichtiger als irgendwelche Werbung
für irgendwelche Produkte (Pornos, Microsft, eBay), die ich sowieso
nicht konsumiere, ob ich das Banner jetzt sehe oder nicht. Und die Rede
ist nicht von Cookies, die stören mich absolut nicht - sondern
irgendwelche Sicherheitslückenausnutzung von Werbefuzzis. Gab es bei
Falk AG schon.
> Wenn mir eine redaktionelle Webseite gut gefällt, klicke ich dort auch
> auf einen Werbebanner. Nur so bekommen die Redakteure und Betreiber
> auch etwas für Ihren Einsatz, der sich in der Regel eh nie auszahlt.
Auf das Banner "pro forma" zu klicken, ist strenggenommen auch asozial,
weil es den Wert eines Klicks senkt, wenn du als Nicht Interessierter
die Werbeseite herunterlädst.
> Ich denke aber, in ein paar Jahren ist das Vorbild der Stiftung
> Warentest akkzeptiert, dass man für den Content im Internet zahlen
> muss.
Wieso auch nicht?
Wird halt wieder mehr freier Content genutzt, und der kommerzielle
gelangt mit wenigen Ausnahmen ins Abseits.
> Im Moment findet man kaum noch seriöse Testberichte im Internet,
> da fast alle Tester inzwischen Geld für Ihre Auswertungen haben
> möchten. Spiegel Online will für alles, was ein paar Monate alt ist,
> auch schon Geld sehen, und in dem Moment, wo man für Spiegel Online
> ein Abo abschließen muss, ist das deutsche Internet endlich
> kommerziell geworden.
Nein, denn dann nutzt diese Angebote kaum einer mehr.
> Und ein Großteil der Schuld daran haben Leute, die Adblock&Co.
> einsetzen und auch sonst nie auf Werbung klicken.
Wenn ihr Werbefuzzis nicht ständig Werbepopups, Werbelayers und sonstige
Störungen machen würdet, sondern stinknormale Werbebanner (meinetwegen
auch animiert, stört mich nicht), müsste ich kein Adblock installieren.
Dementsprechend ist meine Blockliste sehr klein - und keinesfalls nutze
ich eine "fertige" Adblock-Liste. Ich will die Kontrolle darüber haben,
was ich blockiere. Und ich hätte gerne die Adblock-Option "Bilder nicht
blockieren", denn was per <img> eingebunden wird, ist harmlos.
Zum Beispiel die Google-Werbeplattform würde ich in der aktuellen Form
nie ausblenden - sie ist harmlos, sie ist sogar manchmal relevant und es
öfters auch wert, dass man auf der Zielseite nachschaut.
--
Elfen Lied ist gewaltverherrlichend. Vor allem, was da so alles brutalst
niedergemetzelt, grausamst in Stücke gerissen und bei lebendigem Leibe
zerschnitten, zersägt, zerhackt wird... es wäre nicht übertrieben, zu
sagen: "Boldly splitting German composites that no man had split before"
Gregor Kofler
> Das finde ich eine assoziale Haltung! Wenn mir eine redaktionelle
> Webseite gut gefällt, klicke ich dort auch auf einen Werbebanner. Nur
> so bekommen die Redakteure und Betreiber auch etwas für Ihren Einsatz,
> der sich in der Regel eh nie auszahlt.
Was ist das für eine Seite? Ich schaue gerne vorbei und klicke 20, 30,
50 mal auf die (gleichen) Adsense-Banner. Gerne.
Im richtigen Leben klicke ich übrigens allenfalls auf Werbung, die mich
interessiert - also fast nie. Wie und ob der Betreiber zu seinem Geld
kommt, ist wirklich seine Sache. Explizite Klickaufforderungen habe ich
bislang auch nur auf ...ähm... weniger seriösen Seiten gelesen.
Gregor
(dem sein Google-Adsense Account abgedreht wurde, ohne dass es jemals
irgendwo eingesetzt wurde)
--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum
Heiko Kuerschner
> Verdient habe ich dabei 20,07 USD. Eigentlich sollte man die User ohne
> Javascript gleich rausschmeißen: ich habe viele einmalige
> redaktionelle Inhalte und "finanziere" (600 EUR im Monat ist nicht
> wirklich eine angemessene Bezahlung für die viele Zeit +
> Hostingkosten) die Seite nur über Adsense.
</ironie> ?
--
Kürsche
Wenns 'ner net gwittern tun tut ;)
Linux/*BSD-Anleitungen, Forum und Chat: www.newbie-net.de
Irmgard Schwenteck
>
>> ... Providerwechsel nach, weil das
>
> Na ja, Gott sei Dank gibt es ja noch alternativen zum webmail. Bei
> Leuten die viel unterwegs sind, kann ich es verstehen, das Sie mit
> Webmail arbeiten aber privat lese ich alle meine Email mit
> Mozilla/Thunderbird. Ein Providerwechsel ist also nicht zwingend
> erforderlich.
In $Großunternehmen ist webmail die einzige Möglichkeit, Mittags mal an
seine mails zu kommen. Da kann man nicht schnell mal TB installieren
oder im Outlook ein neues Konto einrichten.
Gruß
Irmgard
Heiko Kuerschner
> Und ein Großteil der Schuld daran haben Leute, die Adblock&Co.
> einsetzen und auch sonst nie auf Werbung klicken. Wie soll man sonst
> eine echte unabhängige Redaktion bezahlen?
Kann mans den Leuten verdenken?
Wo man hinschaut, Werbung, Werbung, Werbung. Selbst am Telefon hat man
keine Ruhe. Und dann soll man noch freiwillig auf Werbung klicken?
Außerdem finde ich es 'asozial' auf Banner zu klicken, die einem eh
nicht interessieren. Das klaut anderen evtl. Bandbreite.
Gregor Kofler
> Günther Bach schrieb:
>
>
>>Verdient habe ich dabei 20,07 USD. Eigentlich sollte man die User ohne
>>Javascript gleich rausschmeißen: ich habe viele einmalige
>>redaktionelle Inhalte und "finanziere" (600 EUR im Monat ist nicht
>>wirklich eine angemessene Bezahlung für die viele Zeit +
>>Hostingkosten) die Seite nur über Adsense.
>
>
> </ironie> ?
Nach dem *ersten* Posting hab ich das auch gedacht...
Gregor
Goetz Hoffart
> In $Großunternehmen ist webmail die einzige Möglichkeit, Mittags mal an
> seine mails zu kommen.
Nö, SSH ist erfunden.
BTW: Dein "reply-to" ist in Newsgroups etwas arg ungewöhnlich.
Grüße
Götz
--
http://www.knubbelmac.de/
Joachim Wiesemann
> Irmgard Schwenteck <nix...@4haus.de> wrote:
>
>> In $Großunternehmen ist webmail die einzige Möglichkeit, Mittags mal an
>> seine mails zu kommen.
>
> Nö, SSH ist erfunden.
Nur wenn der Admin der Firewall eine Pappnase ist.
Viele Grüße
Joachim
--
Dr. Joachim Wiesemann
http://www.bestviewed.de/ Seiten über Webdesign und Usability
http://jwiesemann.com/ Ingenieurdienstleistungen, Usabilityberatung
"Die schärfsten Kritiker der Elche waren früher selber welche!"
Robert Wetzlmayr
> Irmgard Schwenteck <nix...@4haus.de> wrote:
>
>
>>In $Großunternehmen ist webmail die einzige Möglichkeit, Mittags mal an
>>seine mails zu kommen.
>
>
> Nö, SSH ist erfunden.
In $grossunternehmen geht ssh kaum nach aussen durch. Zumindest hier ist
das so (ca. 1.300 Clients, relativ "$gross" für die Region).
Unternehmen, die das anders handhaben, erlauben wohl auch smtp und pop
nach aussen.
> BTW: Dein "reply-to" ist in Newsgroups etwas arg ungewöhnlich.
Nicht wirklich. Soll angeblich spam vermeiden
(http://www.mailmsg.com/SPAM_munging.htm).
Robert
--
robert wetzlmayr, http://awasteofwords.com/
Irmgard Schwenteck
Nein, sorry.
Da steht ausnahmsweise fup to poster.
War zuerst auch Absicht, weil es mir etwas sehr neben dem Gruppenthema
erschien.
Hab es nach diversen Unterbrechungen vergessen, wieder rauszunehmen.
Gruß
Irmgard, nun föllig OT schreibselnd und jetzt wirklich mit Absicht fup
to me setzend
Goetz Hoffart
> > Nö, SSH ist erfunden.
>
> In $grossunternehmen geht ssh kaum nach aussen durch. Zumindest hier ist
> das so (ca. 1.300 Clients, relativ "$gross" für die Region).
SSH muß am Zielrechner nicht auf Port 22 laufen. Stateful inspection ist
doch eher selten, meistens werden Ports geprüft.
> Unternehmen, die das anders handhaben, erlauben wohl auch smtp und pop
> nach aussen.
SMTP würde ich nie, nie nach draußen erlauben, das kann wirklich böse
werden.
> > BTW: Dein "reply-to" ist in Newsgroups etwas arg ungewöhnlich.
>
> Nicht wirklich. Soll angeblich spam vermeiden
> (http://www.mailmsg.com/SPAM_munging.htm).
Super. Bei Antworten auf solche Postings muß ich das erstmal händisch
zurück in die Newsgroup verbiegen.
Konni Scheller
> SMTP würde ich nie, nie nach draußen erlauben, das kann wirklich böse
> werden.
Wieso jetzt genau? Weil es unverschlüsselt ist? Oder denkst Du an was
anderes?
> > > BTW: Dein "reply-to" ist in Newsgroups etwas arg ungewöhnlich.
> Super. Bei Antworten auf solche Postings muß ich das erstmal händisch
> zurück in die Newsgroup verbiegen.
Hm, Nur wenn gleichzeitig F'up2 Poster gesetzt wurde.
Dominik Schlütter
Konni Scheller <ksch...@ochs.franken.de> schrieb:
> Wieso jetzt genau? Weil es unverschlüsselt ist? Oder denkst Du an was
> anderes?
Vielleicht weil man Spam-Aktionen (sei es durch irgendwelche Viren,
Würmer oder mitgebrachte Notebooks) verhindern will - an der RWTH-Aachen
ist SMTP aus dem internen Netz auch geblockt, das geht nur über den
zentralen Mailserver. Insbesondere Wohnheimsbewohner ärgern sich
darüber, weil so eMails mit "nicht zum SMTP-Server passenden"
Mail-Adressen gerne mal als Spam klassifiziert werden. Einige Anbieter
wie GMX bieten aber einen alternativen SMPT-Port an (IIRC 587).
> Hm, Nur wenn gleichzeitig F'up2 Poster gesetzt wurde.
War ja auch, Götz hat es ignoriert ... .
Gruß,
Dominik.
Robert Wetzlmayr
> SSH muß am Zielrechner nicht auf Port 22 laufen. Stateful inspection ist
> doch eher selten, meistens werden Ports geprüft.
SI ist mE üblich (Checkpoint hat laut eigenen Angaben über 50%
Marktanteil, macht SI). Dein Workaround geht trotz allem an meiner
Realität vorbei: Ich stell mir gerade einen unserer Einkäufer,
Personaler oder Instandhalter vor, wie er zu mir sagt: "Ich fahre SSH
über Port 80 nach Hause". Wer das kann, soll auch Webmail haben...
> SMTP würde ich nie, nie nach draußen erlauben, das kann wirklich böse
> werden.
Ein vernünftiger Firewall-Admin wird nur die Ports öffnen, die explizit
nötig sind. Alles andere ist Pseudosicherheit. Siehe auch
http://www.ranum.com/security/computer_security/editorials/dumb/, #1.
>>>BTW: Dein "reply-to" ist in Newsgroups etwas arg ungewöhnlich.
> Super. Bei Antworten auf solche Postings muß ich das erstmal händisch
> zurück in die Newsgroup verbiegen.
"Follow-Up-To: poster" ist ungewöhnlich, ja. "Reply-To:" nicht. Ich
dachte, du meintest das.
Joachim Wiesemann
> Robert Wetzlmayr <thund...@nurfuerspam.de> wrote:
>
>>> Nö, SSH ist erfunden.
>>
>> In $grossunternehmen geht ssh kaum nach aussen durch. Zumindest hier ist
>> das so (ca. 1.300 Clients, relativ "$gross" für die Region).
>
> SSH muß am Zielrechner nicht auf Port 22 laufen. Stateful inspection ist
> doch eher selten, meistens werden Ports geprüft.
Ein Proxy reicht völlig und ist auch üblich um einzelne Domains blocken
zu können. Da müsste SSH schon über http getunnelt werden.
>> Unternehmen, die das anders handhaben, erlauben wohl auch smtp und pop
>> nach aussen.
>
> SMTP würde ich nie, nie nach draußen erlauben, das kann wirklich böse
> werden.
Stimmt, die meisten Würmen versenden sich über smtp selbst.
Goetz Hoffart
> > SMTP würde ich nie, nie nach draußen erlauben, das kann wirklich böse
> > werden.
>
> Wieso jetzt genau? Weil es unverschlüsselt ist? Oder denkst Du an was
> anderes?
Eine infizierte Maschine kann dann wunderbar mit der dicken
Firmenleitung nach draußen spammen. Das muß nicht sein.
Rainer Kersten
> Eigentlich sollte man die User ohne
> Javascript gleich rausschmeißen:
Darauf können wir uns gerne einigen. Wo keine Kommunikation stattfindet,
kann sie auch keine Probleme verursachen.
*PLONK*
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn schrieb:
>>> Dort steht nämlich:
>>>
>>> "doch trotz zahlreicher Warnungen surfen weiterhin rund
>>> 40 Prozent mit offenem Visier, sprich mit eingeschaltem
>>> Active Scripting."
>>
>> Diese Aussage ist _so_ falsch, darauf basierende
>> Schlussfolgerungen sind ergo per se falsch.
>
> Also ähm, nein. Richtig!
> Ex falso quodlibet.
Ich habe geahnt, dass mir jemand damit kommen würde :)
Gegenargument: Die Aussage oben ist bereits eine falsche Schlussfolgerung.
Eine falsche Schlussfolgerung kann AIUI nicht zu richtigen
Schlussfolgerungen führen, die auf ihr basieren; aber ich lass mich da
gern belehren, meine letzte KI-Vorlesung ist schon eine Weile her.
> Aber so falsch ist die Aussage garnicht: Das steht ja genaugenommen
> nur was über, dass 40% aller User -- nämlich welchen, die mit aktiviertem
> Active Scripting surfen. Tatsächlich steht da jedoch nichts über die
> restlichen 60%. Die surfen nämlich auch mit aktiviertem Active Scripting,
> oder eben nicht.
Ja.
"aller User" stimmt aber schon nicht, da sich die Statistik der Website
und folglich auch "alle User" nur auf diese spezielle Website bezieht.
"Man sollte" den zuständigen Redakteur für diese schlampige Recherche
kräftig LARTen.
PointedEars
Thomas 'PointedEars' Lahn
> Dementsprechend ist meine Blockliste sehr klein - und keinesfalls nutze
> ich eine "fertige" Adblock-Liste. Ich will die Kontrolle darüber haben,
> was ich blockiere. Und ich hätte gerne die Adblock-Option "Bilder nicht
> blockieren", denn was per <img> eingebunden wird, ist harmlos.
Das ist so auch nicht richtig, denn eine Bild-Ressource ist auch nur ein
HTTP-Request, der z.B. im Senden des `Set-Cookie'-Headers resultieren kann.
Ausserdem kann man "Dich" so prima "verfolgen". Auch ohne Cookies.
Zudem wird von Browsern das onload-Attribut des img-Elements, obwohl
nicht spezifiziert, unterstützt. Darin kann man beliebig Unfug machen.
Und dann gibt es noch das "javascript:"-Pseudo-Protokoll oder
"data:"-URIs in src-Attributwerten von img-Elementen.
Dabei gebe ich zu bedenken, dass ich dies auch als J(ava)Script-Entwickler
schreibe. Daher trotz allem meine Bitte an die Benutzer: Mit
J(ava)Script/ECMAScript kann man, sinnvoll angewendet, viele Dinge
machen, die für den Benutzer zum Vorteil sind (z.B. Formularüberprüfung
schon _vor_ dem Absenden). Schränkt meinetwegen den clientseitigen
Script-Support ein, wenn ihr das müsst, um Scriptkiddies kaltzustellen;
aber bitte schaltet ihn nicht kategorisch ab. Danke im Voraus.
PointedEars
Rudolf Polzer
> Rudolf Polzer wrote:
> > Dementsprechend ist meine Blockliste sehr klein - und keinesfalls nutze
> > ich eine "fertige" Adblock-Liste. Ich will die Kontrolle darüber haben,
> > was ich blockiere. Und ich hätte gerne die Adblock-Option "Bilder nicht
> > blockieren", denn was per <img> eingebunden wird, ist harmlos.
>
> Das ist so auch nicht richtig, denn eine Bild-Ressource ist auch nur ein
> HTTP-Request, der z.B. im Senden des `Set-Cookie'-Headers resultieren kann.
Und? Die halten nicht lange.
> Ausserdem kann man "Dich" so prima "verfolgen". Auch ohne Cookies.
Wenn man so paranoid ist, sollte man das WWW ganz meiden.
Moment, das wäre aber asozial, wenn man dann nicht die Werbung
anklickt... ;)
> Zudem wird von Browsern das onload-Attribut des img-Elements, obwohl
> nicht spezifiziert, unterstützt. Darin kann man beliebig Unfug machen.
Weniger.
> Und dann gibt es noch das "javascript:"-Pseudo-Protokoll oder
> "data:"-URIs in src-Attributwerten von img-Elementen.
Ersteres ist ein typischer XSS-Fall, und letzteres versucht Adblock
gar nicht erst abzufangen.
Aber mehr als ein Bild an Adblock vorbei eingebetttet habe ich damit
nicht hinbekommen - man müsste aber mal testen, ob man auch Java-Applets
oder Flash als data: laden kann.
> Dabei gebe ich zu bedenken, dass ich dies auch als J(ava)Script-Entwickler
> schreibe. Daher trotz allem meine Bitte an die Benutzer: Mit
> J(ava)Script/ECMAScript kann man, sinnvoll angewendet, viele Dinge
> machen, die für den Benutzer zum Vorteil sind (z.B. Formularüberprüfung
> schon _vor_ dem Absenden). Schränkt meinetwegen den clientseitigen
> Script-Support ein, wenn ihr das müsst, um Scriptkiddies kaltzustellen;
> aber bitte schaltet ihn nicht kategorisch ab. Danke im Voraus.
Es existiert noch kein Webbrowser, mit dem das gut einschränken kann.
Dumm nur, dass gerade Onlinebanking-Seiten gerne JavaScript brauchen,
während es eigentlich anzuraten wäre, die Domains dieser Seiten mit
einem JavaScript-Verbot zu belegen, um XSS zu erschweren bzw. unmöglich
zu machen.
Thomas 'PointedEars' Lahn
> »Thomas 'PointedEars' Lahn« <Point...@web.de> wrote:
>> Rudolf Polzer wrote:
>> > Dementsprechend ist meine Blockliste sehr klein - und keinesfalls nutze
>> > ich eine "fertige" Adblock-Liste. Ich will die Kontrolle darüber haben,
>> > was ich blockiere. Und ich hätte gerne die Adblock-Option "Bilder nicht
>> > blockieren", denn was per <img> eingebunden wird, ist harmlos.
>>
>> Das ist so auch nicht richtig, denn eine Bild-Ressource ist auch nur ein
>> HTTP-Request, der z.B. im Senden des `Set-Cookie'-Headers resultieren
>> kann.
>
> Und? Die halten nicht lange.
img-Elemente sind also nicht so harmlos, wie Du sie hinstellst, und
es gibt Gründe, sie unter gewissen Umständen trotzdem zu blockieren.
(Ich blockiere übrigens per /etc/hosts, das geht in jedem Browser ohne
zusätzliche Konfiguration und macht das Web von hier aus sehr viel
schneller :))
>> Ausserdem kann man "Dich" so prima "verfolgen". Auch ohne Cookies.
>
> Wenn man so paranoid ist, sollte man das WWW ganz meiden.
Daher die Anführungszeichen. Wobei die Paranoia nicht unbegründet ist,
immerhin gibt es Firmen, die damit ihr Geld verdienen (z.B. das unsägliche
doubleclick.net).
> Moment, das wäre aber asozial, wenn man dann nicht die Werbung
> anklickt... ;)
:)
>> Zudem wird von Browsern das onload-Attribut des img-Elements, obwohl
>> nicht spezifiziert, unterstützt. Darin kann man beliebig Unfug machen.
>
> Weniger.
Hinreichend viel.
>> Und dann gibt es noch das "javascript:"-Pseudo-Protokoll oder
>> "data:"-URIs in src-Attributwerten von img-Elementen.
>
> Ersteres ist ein typischer XSS-Fall,
Nein.
> und letzteres versucht Adblock gar nicht erst abzufangen.
>
> Aber mehr als ein Bild an Adblock vorbei eingebetttet habe ich damit
> nicht hinbekommen -
Seit wann geht es hier um Adblock?
> man müsste aber mal testen, ob man auch Java-Applets oder Flash als data:
> laden kann.
Ja.
>> Dabei gebe ich zu bedenken, dass ich dies auch als
>> J(ava)Script-Entwickler schreibe. Daher trotz allem meine Bitte an die
>> Benutzer: Mit J(ava)Script/ECMAScript kann man, sinnvoll angewendet,
>> viele Dinge machen, die für den Benutzer zum Vorteil sind (z.B.
>> Formularüberprüfung schon _vor_ dem Absenden). Schränkt meinetwegen
>> den clientseitigen Script-Support ein, wenn ihr das müsst, um
>> Scriptkiddies kaltzustellen; aber bitte schaltet ihn nicht kategorisch
>> ab. Danke im Voraus.
>
> Es existiert noch kein Webbrowser, mit dem das gut einschränken kann.
In Firefox und neueren Mozillas kann man immerhin die typischsten
Scriptkiddie-Auswüchse blockieren:
| Allow scripts to:
| [_] Move or resize existing windows
| [x] Raise or lower windows
| [_] Disable or replace context menus
| [_] Hide the status bar
| [x] Change status bar text
| [x] Change images
Ich muss mal schauen, ob es eine Extension gibt, um das noch zu verfeinern;
diese könnte nämlich die entsprechenden Methoden unwirksam machen.
> Dumm nur, dass gerade Onlinebanking-Seiten gerne JavaScript brauchen,
> während es eigentlich anzuraten wäre, die Domains dieser Seiten mit
> einem JavaScript-Verbot zu belegen, um XSS zu erschweren bzw. unmöglich
> zu machen.
Ja. (Das Online-Banking der Deutschen Bank z.B. braucht keinen
clientseitigen Script-Support.)
PointedEars
Rudolf Polzer
> Rudolf Polzer wrote:
> > »Thomas 'PointedEars' Lahn« <Point...@web.de> wrote:
> >> Rudolf Polzer wrote:
> >> > Dementsprechend ist meine Blockliste sehr klein - und keinesfalls nutze
> >> > ich eine "fertige" Adblock-Liste. Ich will die Kontrolle darüber haben,
> >> > was ich blockiere. Und ich hätte gerne die Adblock-Option "Bilder nicht
> >> > blockieren", denn was per <img> eingebunden wird, ist harmlos.
> >>
> >> Das ist so auch nicht richtig, denn eine Bild-Ressource ist auch nur ein
> >> HTTP-Request, der z.B. im Senden des `Set-Cookie'-Headers resultieren
> >> kann.
> >
> > Und? Die halten nicht lange.
>
> img-Elemente sind also nicht so harmlos, wie Du sie hinstellst, und
> es gibt Gründe, sie unter gewissen Umständen trotzdem zu blockieren.
> (Ich blockiere übrigens per /etc/hosts, das geht in jedem Browser ohne
> zusätzliche Konfiguration und macht das Web von hier aus sehr viel
> schneller :))
ACK. Gewisse Hosts gehören da wirklich rein.
> >> Ausserdem kann man "Dich" so prima "verfolgen". Auch ohne Cookies.
> >
> > Wenn man so paranoid ist, sollte man das WWW ganz meiden.
>
> Daher die Anführungszeichen. Wobei die Paranoia nicht unbegründet ist,
> immerhin gibt es Firmen, die damit ihr Geld verdienen (z.B. das unsägliche
> doubleclick.net).
Beschränkt man Cookies auf "session only", sind sie schon relativ
harmlos. Vor allem, wenn man, wie ich, Browserfenster, die man nicht
braucht, schließt (und dann auch die meiste Zeit gar keinen Browser
offen hat).
> > man müsste aber mal testen, ob man auch Java-Applets oder Flash als data:
> > laden kann.
>
> Ja.
Das ist ein Stück schlimmer... eben Konqueror von KDE 3.5 ausprobiert.
Der lädt standardmäßig kein Flash mehr sofort, da kommt erst nur ein
Button "Start plugin". Ist zwar wohl eher wegen eines gewissen
Softwarepatents, aber erlaubt mir endlich, ohne größere Nerverei Flash
wieder zu aktivieren, um es bei wirklichem Bedarf auch zu starten.
IMHO haben wir dann das erste Softwarepatent gefunden, das dem gemeinen
Nutzer HILFT. War eine ganz schön lange Sucherei.
> >> Dabei gebe ich zu bedenken, dass ich dies auch als
> >> J(ava)Script-Entwickler schreibe. Daher trotz allem meine Bitte an die
> >> Benutzer: Mit J(ava)Script/ECMAScript kann man, sinnvoll angewendet,
> >> viele Dinge machen, die für den Benutzer zum Vorteil sind (z.B.
> >> Formularüberprüfung schon _vor_ dem Absenden). Schränkt meinetwegen
> >> den clientseitigen Script-Support ein, wenn ihr das müsst, um
> >> Scriptkiddies kaltzustellen; aber bitte schaltet ihn nicht kategorisch
> >> ab. Danke im Voraus.
> >
> > Es existiert noch kein Webbrowser, mit dem das gut einschränken kann.
>
> In Firefox und neueren Mozillas kann man immerhin die typischsten
> Scriptkiddie-Auswüchse blockieren:
Dito in Konqueror.
> | Allow scripts to:
> | [_] Move or resize existing windows
> | [x] Raise or lower windows
Das gehört auf jeden Fall aus, das wird nur zum Nerven benutzt...
> | [_] Disable or replace context menus
> | [_] Hide the status bar
> | [x] Change status bar text
Und das ist Geschmackssache, habe ich bei mir auch aus.
> | [x] Change images
>
> Ich muss mal schauen, ob es eine Extension gibt, um das noch zu verfeinern;
> diese könnte nämlich die entsprechenden Methoden unwirksam machen.
Stimmt, ich würde auf manchen Seiten gerne auch Alertboxen verbieten.
Alternativ ein "Kill scripts"-Button in jeder JS-Alertbox (wie es der
Textmodusbrowser Links macht).
> > Dumm nur, dass gerade Onlinebanking-Seiten gerne JavaScript brauchen,
> > während es eigentlich anzuraten wäre, die Domains dieser Seiten mit
> > einem JavaScript-Verbot zu belegen, um XSS zu erschweren bzw. unmöglich
> > zu machen.
>
> Ja. (Das Online-Banking der Deutschen Bank z.B. braucht keinen
> clientseitigen Script-Support.)
Gut zu wissen, das könnte mich zum Wechsel bewegen. Danke!
Thomas 'PointedEars' Lahn
> »Thomas 'PointedEars' Lahn« <Point...@web.de> wrote:
>> Rudolf Polzer wrote:
>> > »Thomas 'PointedEars' Lahn« <Point...@web.de> wrote:
>> >> Rudolf Polzer wrote:
>> >> > Dementsprechend ist meine Blockliste sehr klein - und keinesfalls
>> >> > nutze ich eine "fertige" Adblock-Liste. Ich will die Kontrolle
>> >> > darüber haben, was ich blockiere. Und ich hätte gerne die
>> >> > Adblock-Option "Bilder nicht blockieren", denn was per <img>
>> >> > eingebunden wird, ist harmlos.
>> >>
>> >> Das ist so auch nicht richtig, denn eine Bild-Ressource ist auch nur
>> >> ein HTTP-Request, der z.B. im Senden des `Set-Cookie'-Headers
>> >> resultieren kann.
>> > [...]
>> >> Ausserdem kann man "Dich" so prima "verfolgen". Auch ohne Cookies.
>> > Wenn man so paranoid ist, sollte man das WWW ganz meiden.
>> Daher die Anführungszeichen. Wobei die Paranoia nicht unbegründet
>> ist, immerhin gibt es Firmen, die damit ihr Geld verdienen (z.B. das
>> unsägliche doubleclick.net).
>
> Beschränkt man Cookies auf "session only", sind sie schon relativ
> harmlos. Vor allem, wenn man, wie ich, Browserfenster, die man nicht
> braucht, schließt (und dann auch die meiste Zeit gar keinen Browser
> offen hat).
Wie gesagt, Cookies sind dabei nicht entscheidend, solange sich die
IP-Adresse des Clients über einen hinreichend langen Zeitraum nicht
ändert.
>> >> Dabei gebe ich zu bedenken, dass ich dies auch als
>> >> J(ava)Script-Entwickler schreibe. Daher trotz allem meine Bitte an
>> >> die Benutzer: Mit J(ava)Script/ECMAScript kann man, sinnvoll
>> >> angewendet, viele Dinge machen, die für den Benutzer zum Vorteil sind
>> >> (z.B. Formularüberprüfung schon _vor_ dem Absenden). Schränkt
>> >> meinetwegen den clientseitigen Script-Support ein, wenn ihr das müsst,
>> >> um Scriptkiddies kaltzustellen; aber bitte schaltet ihn nicht
>> >> kategorisch ab. Danke im Voraus.
>> > Es existiert noch kein Webbrowser, mit dem das gut einschränken kann.
>> In Firefox und neueren Mozillas kann man immerhin die typischsten
>> Scriptkiddie-Auswüchse blockieren:
>
> Dito in Konqueror.
>
>> | Allow scripts to:
>> | [_] Move or resize existing windows
>> | [x] Raise or lower windows
>
> Das gehört auf jeden Fall aus, das wird nur zum Nerven benutzt...
Das stimmt so nicht. Wenn man Script-Support aktiviert hat (und das
setzen diese Einstellungen voraus), dann besteht mit clientseitigem
Scripting die Möglichkeit, vorhandene Fenster bei Wiederverwendung in
den Vordergrund zu holen ("raise"). Ich wünsche mir allerdings eine
separate Einstellung für "lower windows", wofür mir keine sinnvolle
Anwendungsmöglichkeit einfällt.
>> | [_] Disable or replace context menus
>> | [_] Hide the status bar
>> | [x] Change status bar text
>
> Und das ist Geschmackssache, habe ich bei mir auch aus.
ACK
>> | [x] Change images
>>
>> Ich muss mal schauen, ob es eine Extension gibt, um das noch zu
>> verfeinern; diese könnte nämlich die entsprechenden Methoden unwirksam
>> machen.
>
> Stimmt, ich würde auf manchen Seiten gerne auch Alertboxen verbieten.
> Alternativ ein "Kill scripts"-Button in jeder JS-Alertbox (wie es der
> Textmodusbrowser Links macht).
Habe gerade zufällig etwas ähnliches gefunden, aber noch nicht ausprobiert:
<URL:https://addons.mozilla.org/extensions/moreinfo.php?id=722&application=firefox>
HTH
PointedEars
B.Tove
> Juergen Arnold <news.juer...@gmx.de> schrieb:
>
>
>>Günther Bach <gb0...@hotmail.com> wrote:
>>
>>
>>>Eigentlich sollte man die User ohne
>>>Javascript gleich rausschmeißen
>>
>
>
> Weil es mir zu dumm ist, meinen Content nur noch mit JavaScript
> auszuliefern, das widerspricht meine Ideen vom Internet.
Aber bei der Werbung setzt du diese dann ein?
Da widerspricht dir das nicht?
> Und weil mich ein "Nicht-Zahlender-Besucher" trozdem dafacto nichts
> kostet.
Wenn deine kosten nutzen Analyse nicht passt, sperre die aus.
Wundere dich aber dann nicht das diese nichtseher keine Links setzt und
Werbung für deine Seiten mehr macht.
Also meckere nicht.
>>Wenn Du Besucher ohne JavaScript nicht
>>aus geschäftlichen sondern aus "altruistischen" Erwägungen heraus
>>*nicht* aussperrst, darfst Du Dich auch nicht darüber beklagen, daß es
>>eben einen nicht zu vernachlässigenden Anteil an (potentiellen)
>>Besuchern gibt, die aus guten Gründen JavaScript deaktiviert haben und
>>trotzdem Deine Seite besuchen.
>>
>>Ich persönlich sehe das ganz locker: wer mich ohne JavaScript *nicht*
>>will, kann auf mich als Kunden verzichten. Die Ausnahmen, bei denen
>>*ich* ein Angebot *unbedingt* wahrnehmen wollte und aus einzig diesem
>>Grund JavaScript aktiviert habe, sind *sehr* überschaubar...
>
>
> Das finde ich eine assoziale Haltung! Wenn mir eine redaktionelle
> Webseite gut gefällt, klicke ich dort auch auf einen Werbebanner. Nur
> so bekommen die Redakteure und Betreiber auch etwas für Ihren Einsatz,
> der sich in der Regel eh nie auszahlt.
Ja, mach das ruhig, am besten noch Millionen andere.
Vieleicht haben die Bezahler für die Werbung endlich erkannt das diese
Art von Werbung nichts bringt.
Wer nur deswegen auf Banner klickt, verursacht nur kosten. Er kauft ja
sehr selten was.
Wer meint Javascript für Werbung nutzen zu wollen, der soll sich halt
damit abfinden das welche Javascript abgeschaltet haben.
Dann soll er aber nicht auf diese abschalter meckern, sondern er sollte
sein Werbemodell überareiten.
Es geht auch ohne Javascript.
>
> Ich denke aber, in ein paar Jahren ist das Vorbild der Stiftung
> Warentest akkzeptiert, dass man für den Content im Internet zahlen
> muss. Im Moment findet man kaum noch seriöse Testberichte im Internet,
> da fast alle Tester inzwischen Geld für Ihre Auswertungen haben
> möchten. Spiegel Online will für alles, was ein paar Monate alt ist,
> auch schon Geld sehen, und in dem Moment, wo man für Spiegel Online
> ein Abo abschließen muss, ist das deutsche Internet endlich
> kommerziell geworden.
> Und ein Großteil der Schuld daran haben Leute, die Adblock&Co.
> einsetzen und auch sonst nie auf Werbung klicken. Wie soll man sonst
> eine echte unabhängige Redaktion bezahlen?
Wieso sind die Leute schuld?
Haben die diese Werbeform geschaltet?
Es gibt noch andere Werbeformen als die die geblockt werden.
Die Werbung die dann übrigbleibt, die finde ich dann angenehm, und diese
kann bleiben.
Wenn Firmen für die Art von Werbung noch Geld ausgeben, obwohl bekannt
ist das diese geblockt werden kann, dann sind die selber schuld.
Was ich auf meinem Bildschirm sehen will, bestimme ich noch immer selber.
Hoch lebe die http://prefbar.mozdev.org/
Da kann ich selbst Color, Referrer und Bilder abstellen wenn ich das will.
Bei Ebay geht dann vieles sehr viel schneller.
Tove
Rudolf Polzer
> Wie gesagt, Cookies sind dabei nicht entscheidend, solange sich die
> IP-Adresse des Clients über einen hinreichend langen Zeitraum nicht
> ändert.
Dann soll man Tor o.ä. nutzen. Eine Website könnte ja auch ein
PHP-Skript haben, das doubleclick.net die Werte von REMOTE_ADDR schickt.
> >> | Allow scripts to:
> >> | [_] Move or resize existing windows
> >> | [x] Raise or lower windows
> >
> > Das gehört auf jeden Fall aus, das wird nur zum Nerven benutzt...
>
> Das stimmt so nicht. Wenn man Script-Support aktiviert hat (und das
> setzen diese Einstellungen voraus), dann besteht mit clientseitigem
> Scripting die Möglichkeit, vorhandene Fenster bei Wiederverwendung in
> den Vordergrund zu holen ("raise"). Ich wünsche mir allerdings eine
> separate Einstellung für "lower windows", wofür mir keine sinnvolle
> Anwendungsmöglichkeit einfällt.
Ich tue mich schon sehr schwer damit, einen sinnvollen Einsatz für
window.open zu finden. Außer Spamfenstern und Erzwingen einer bestimmten
Fenstergröße bzw. Abstellen von Adressleiste etc. habe ich noch nie eine
Anwendung dafür gesehen. Und Erzwingen einer bestimmten Fenstergröße
bringt absolut nix, wenn ich andere Fonts oder eine andere dpi-Zahl habe
als der Autor der Seite.
> >> | [x] Change images
> >>
> >> Ich muss mal schauen, ob es eine Extension gibt, um das noch zu
> >> verfeinern; diese könnte nämlich die entsprechenden Methoden unwirksam
> >> machen.
> >
> > Stimmt, ich würde auf manchen Seiten gerne auch Alertboxen verbieten.
> > Alternativ ein "Kill scripts"-Button in jeder JS-Alertbox (wie es der
> > Textmodusbrowser Links macht).
>
> Habe gerade zufällig etwas ähnliches gefunden, aber noch nicht ausprobiert:
>
> <URL:https://addons.mozilla.org/extensions/moreinfo.php?id=722&application=firefox>
Ja, nutze ich bereits. Absolut notwendig, weil es jetzt schon genug
Websites schaffen, am Popupblocker von Firefox vorbei zu kommen.
Besonders nervig dabei: die Option "JS-Popups als Tabs öffnen" gibt es
nicht mehr, genausowenig wie die sie freischaltende Option
browser.tabs.showSingleWindowModePrefs. Hiermit scheint es halbwegs zu
gehen, aber sicher bin ich mir da nicht (nur auf einer Seite getestet,
und dank der scheinbar absolut nicht vorhandenen Dokumentation der
Preferences kann ich nicht verifizieren, ob die das tun, was ich denke):
user_pref("browser.link.open_newwindow", 3);
user_pref("browser.link.open_newwindow.restriction", 0);
user_pref("browser.tabs.loadDivertedInBackground", true);
Thomas 'PointedEars' Lahn
> »Thomas 'PointedEars' Lahn« <Point...@web.de> wrote:
>> Wie gesagt, Cookies sind dabei nicht entscheidend, solange sich die
>> IP-Adresse des Clients über einen hinreichend langen Zeitraum nicht
>> ändert.
>
> Dann soll man Tor o.ä. nutzen. Eine Website könnte ja auch ein
> PHP-Skript haben, das doubleclick.net die Werte von REMOTE_ADDR schickt.
Was ist "Tor"?
>> >> | Allow scripts to:
>> >> | [_] Move or resize existing windows
>> >> | [x] Raise or lower windows
>> >
>> > Das gehört auf jeden Fall aus, das wird nur zum Nerven benutzt...
>>
>> Das stimmt so nicht. Wenn man Script-Support aktiviert hat (und das
>> setzen diese Einstellungen voraus), dann besteht mit clientseitigem
>> Scripting die Möglichkeit, vorhandene Fenster bei Wiederverwendung in
>> den Vordergrund zu holen ("raise"). Ich wünsche mir allerdings eine
>> separate Einstellung für "lower windows", wofür mir keine sinnvolle
>> Anwendungsmöglichkeit einfällt.
>
> Ich tue mich schon sehr schwer damit, einen sinnvollen Einsatz für
> window.open zu finden. Außer Spamfenstern und Erzwingen einer bestimmten
> Fenstergröße bzw. Abstellen von Adressleiste etc. habe ich noch nie eine
> Anwendung dafür gesehen.
Eine häufige und IMHO sinnvolle Anwendung dafür ist ein Tool-Fenster für
detaillierte Dateneingaben, beispielsweise ein Kalender-Steuerelement.
> Und Erzwingen einer bestimmten Fenstergröße bringt absolut nix, wenn ich
> andere Fonts oder eine andere dpi-Zahl habe als der Autor der Seite.
Bei der Anzeige von Bildern kann das mitunter sinnvoll sein, zudem kann
man theoretisch berechnen, wie gross das Fenster sein muss, um Deine
Bedürfnisse mindestens zu erfüllen.
>> >> | [x] Change images
>> >>
>> >> Ich muss mal schauen, ob es eine Extension gibt, um das noch zu
>> >> verfeinern; diese könnte nämlich die entsprechenden Methoden unwirksam
>> >> machen.
>> >
>> > Stimmt, ich würde auf manchen Seiten gerne auch Alertboxen verbieten.
>> > Alternativ ein "Kill scripts"-Button in jeder JS-Alertbox (wie es der
>> > Textmodusbrowser Links macht).
>>
>> Habe gerade zufällig etwas ähnliches gefunden, aber noch nicht
>> ausprobiert:
>>
>>
<URL:https://addons.mozilla.org/extensions/moreinfo.php?id=722&application=firefox>
>
> Ja, nutze ich bereits. Absolut notwendig, weil es jetzt schon genug
> Websites schaffen, am Popupblocker von Firefox vorbei zu kommen.
>
> Besonders nervig dabei: die Option "JS-Popups als Tabs öffnen" gibt es
> nicht mehr, genausowenig wie die sie freischaltende Option
> browser.tabs.showSingleWindowModePrefs. Hiermit scheint es halbwegs zu
> gehen, aber sicher bin ich mir da nicht (nur auf einer Seite getestet,
> und dank der scheinbar absolut nicht vorhandenen Dokumentation der
> Preferences kann ich nicht verifizieren, ob die das tun, was ich denke):
>
> user_pref("browser.link.open_newwindow", 3);
> user_pref("browser.link.open_newwindow.restriction", 0);
> user_pref("browser.tabs.loadDivertedInBackground", true);
Das driftet doch jetzt sehr ab, ich leite mal um.
X-Post & F'up2 de.comm.software.mozilla.browser
PointedEars
Rudolf Polzer
> Rudolf Polzer wrote:
> > »Thomas 'PointedEars' Lahn« <Point...@web.de> wrote:
> >> Wie gesagt, Cookies sind dabei nicht entscheidend, solange sich die
> >> IP-Adresse des Clients über einen hinreichend langen Zeitraum nicht
> >> ändert.
> >
> > Dann soll man Tor o.ä. nutzen. Eine Website könnte ja auch ein
> > PHP-Skript haben, das doubleclick.net die Werte von REMOTE_ADDR schickt.
>
> Was ist "Tor"?
> >> >> | Allow scripts to:
> >> >> | [_] Move or resize existing windows
> >> >> | [x] Raise or lower windows
> >> >
> >> > Das gehört auf jeden Fall aus, das wird nur zum Nerven benutzt...
> >>
> >> Das stimmt so nicht. Wenn man Script-Support aktiviert hat (und das
> >> setzen diese Einstellungen voraus), dann besteht mit clientseitigem
> >> Scripting die Möglichkeit, vorhandene Fenster bei Wiederverwendung in
> >> den Vordergrund zu holen ("raise"). Ich wünsche mir allerdings eine
> >> separate Einstellung für "lower windows", wofür mir keine sinnvolle
> >> Anwendungsmöglichkeit einfällt.
> >
> > Ich tue mich schon sehr schwer damit, einen sinnvollen Einsatz für
> > window.open zu finden. Außer Spamfenstern und Erzwingen einer bestimmten
> > Fenstergröße bzw. Abstellen von Adressleiste etc. habe ich noch nie eine
> > Anwendung dafür gesehen.
>
> Eine häufige und IMHO sinnvolle Anwendung dafür ist ein Tool-Fenster für
> detaillierte Dateneingaben, beispielsweise ein Kalender-Steuerelement.
Wenn man sowas nutzt, sollte man das klar auf der Website dokumentieren
- denn dass window.open ein Fenster öffnet, ist mittlerweile eher die
Ausnahme. Zuviele Werbefirmen haben diese Funktion mit ihrer
Popup-Spammerei so sehr missbraucht, dass alle aktuellen Browser
standardmäßig keine Popups mehr zulassen.
Und um von einem User eine Änderung seiner Browsereinstellungen zu
verlangen, musst du schon verdammt viel bieten.
> > Und Erzwingen einer bestimmten Fenstergröße bringt absolut nix, wenn ich
> > andere Fonts oder eine andere dpi-Zahl habe als der Autor der Seite.
>
> Bei der Anzeige von Bildern kann das mitunter sinnvoll sein, zudem kann
> man theoretisch berechnen, wie gross das Fenster sein muss, um Deine
> Bedürfnisse mindestens zu erfüllen.
Du kennst nicht einmal die Größe der Titelleiste, also wie willst du das
also machen? Die Attribute "innerWidth" o.ä. werden längst nicht überall
unterstützt.
> X-Post & F'up2 de.comm.software.mozilla.browser
Hier missachtet, die Gruppe abonniert, mal sehen, was aus der anderen
Hälfte wird.
Thomas 'PointedEars' Lahn
> »Thomas 'PointedEars' Lahn« <Point...@web.de> wrote:
>> Rudolf Polzer wrote:
>> > »Thomas 'PointedEars' Lahn« <Point...@web.de> wrote:
>> >> Wie gesagt, Cookies sind dabei nicht entscheidend, solange sich die
>> >> IP-Adresse des Clients über einen hinreichend langen Zeitraum nicht
>> >> ändert.
>> > Dann soll man Tor o.ä. nutzen. Eine Website könnte ja auch ein
>> > PHP-Skript haben, das doubleclick.net die Werte von REMOTE_ADDR
>> > schickt.
>> Was ist "Tor"?
>
> http://tor.eff.org/
ACK, danke.
>> > Ich tue mich schon sehr schwer damit, einen sinnvollen Einsatz für
>> > window.open zu finden. Außer Spamfenstern und Erzwingen einer
>> > bestimmten Fenstergröße bzw. Abstellen von Adressleiste etc. habe ich
>> > noch nie eine Anwendung dafür gesehen.
>> Eine häufige und IMHO sinnvolle Anwendung dafür ist ein Tool-Fenster für
>> detaillierte Dateneingaben, beispielsweise ein Kalender-Steuerelement.
>
> Wenn man sowas nutzt, sollte man das klar auf der Website dokumentieren
> - denn dass window.open ein Fenster öffnet, ist mittlerweile eher die
> Ausnahme. Zuviele Werbefirmen haben diese Funktion mit ihrer
> Popup-Spammerei so sehr missbraucht, dass alle aktuellen Browser
> standardmäßig keine Popups mehr zulassen.
Dies gilt AFAIK nicht für Popups, die der Benutzer selbst ausgelöst hat.
Und nur um die geht es hier.
> Und um von einem User eine Änderung seiner Browsereinstellungen zu
> verlangen, musst du schon verdammt viel bieten.
Wer z.B. auf <URL:http://reiseauskunft.bahn.de/bin/query.exe/dn?> das
Kalender-Steuerelement benutzen möchte, hat Script-Support aktiviert
und Popups nicht blockiert. Wer nicht, der nicht, kann dann aber
dieses Feature auch nicht nutzen. (Wobei da allerdings kein
javascript:-Link hingehört, vielmehr sollte das dynamisch generiert
werden.)
>> > Und Erzwingen einer bestimmten Fenstergröße bringt absolut nix, wenn
>> > ich andere Fonts oder eine andere dpi-Zahl habe als der Autor der
>> > Seite.
>> Bei der Anzeige von Bildern kann das mitunter sinnvoll sein, zudem kann
>> man theoretisch berechnen, wie gross das Fenster sein muss, um Deine
>> Bedürfnisse mindestens zu erfüllen.
>
> Du kennst nicht einmal die Größe der Titelleiste, also wie willst du das
> also machen? Die Attribute "innerWidth" o.ä. werden längst nicht überall
> unterstützt.
Ich weiss nicht, was Du mit `innerWidth' willst. Das "Attribut" `width'
bzw. `height' im dritten Argument von window.open() gibt die Breite bzw.
Höhe des Viewports des Fensters, nicht die des Fensters, an. Dies gilt
nur dann nicht, wenn das Fenster schmaler bzw. niedriger als die
Mindestabmessungen (100x100px) oder breiter bzw. höher als der Desktop
würde (und das UniversalBrowserWrite-Privileg nicht garantiert wäre).
var w = window.open("http://pointedears.de/", "foo", "width=512");
alert([w.width, w.clientWidth, w.innerWidth]);
Die Größe der Titelleiste, wenn es denn eine solche überhaupt gibt, ist
hierbei irrelevant. Solltest Du auf die clientWidth (IE)/innerWidth
(Mozilla)-Eigenschaft des Window-Objekts anspielen, so ist eine
nachträgliche Veränderung der Fenstergrösse bereits durch
| Allow scripts to:
| [_] Move or resize existing windows
unmöglich.
PointedEars
Rudolf Polzer
> Rudolf Polzer wrote:
>
> >> > Ich tue mich schon sehr schwer damit, einen sinnvollen Einsatz für
> >> > window.open zu finden. Außer Spamfenstern und Erzwingen einer
> >> > bestimmten Fenstergröße bzw. Abstellen von Adressleiste etc. habe ich
> >> > noch nie eine Anwendung dafür gesehen.
> >> Eine häufige und IMHO sinnvolle Anwendung dafür ist ein Tool-Fenster für
> >> detaillierte Dateneingaben, beispielsweise ein Kalender-Steuerelement.
> >
> > Wenn man sowas nutzt, sollte man das klar auf der Website dokumentieren
> > - denn dass window.open ein Fenster öffnet, ist mittlerweile eher die
> > Ausnahme. Zuviele Werbefirmen haben diese Funktion mit ihrer
> > Popup-Spammerei so sehr missbraucht, dass alle aktuellen Browser
> > standardmäßig keine Popups mehr zulassen.
>
> Dies gilt AFAIK nicht für Popups, die der Benutzer selbst ausgelöst hat.
> Und nur um die geht es hier.
Woher soll der Browser das wissen?
Ich kenne Websites, die ihre Popups in document.onclick und ähnlichen
Handlern registrieren - ebenso im onClick vieler Links. Das machen die,
weil viele Popupblocker meinen, "vom Benutzer initiierte Popups"
erkennen zu können.
Und genau die Seiten sind es, die bei mir in der "deny scripting"-Liste
stehen. Oder manchmal schalte ich Popups komplett ab. Noch taugt diese
Liste recht gut als Adblock-Ersatz (bis Debian endlich KDE 3.5 bzw.
dessen Konqueror - sonst nutze ich keine KDE-Komponente - bringt... aber
da werden die wohl wieder ein halbes Jahr für brauchen, irgendwie macht
unstable zur Zeit den Eindruck, hoffnungslos zu veralten - gibt ja auch
z.B. keinen Firefox 1.5 in unstable und wegen eines gcc4-Bugs kompiliert
er auch nicht - außer, man spielt manuell in der autoconf.mk rum - und
laut Debian-Bugtracker ist der Bug "fixed in experimental" seit Monaten.
Einen Scheißdreck ist er, die Version, in der er behoben sei, liegt gar
nicht in experimental, sondern eine viel ältere der Deerpark-Alpha.
Genug über Debian gemeckert, ich steige wohl bald auf was anderes um -
egal was).
> > Und um von einem User eine Änderung seiner Browsereinstellungen zu
> > verlangen, musst du schon verdammt viel bieten.
>
> Wer z.B. auf <URL:http://reiseauskunft.bahn.de/bin/query.exe/dn?> das
> Kalender-Steuerelement benutzen möchte, hat Script-Support aktiviert
> und Popups nicht blockiert. Wer nicht, der nicht, kann dann aber
> dieses Feature auch nicht nutzen.
Doch schon... er kann den Fahrplan abfragen.
Er muss das Datum dann halt tippen. Und wenn das Fensteröffnen nicht
klappt, dann tut der Button nix - kein Beinbruch, links davon ist ein
Eingabefeld.
Das ist aber ein typischer _sinnvoller_ Einsatz von JavaScript - und wie
immer ist dieser optional, aber nett. Mich persönlich würde dieses
Fenster z.B. stören - es dauert erst zu lange, bis das Java-Applet
dadrin geladen ist (warum das noch als Apple?t Ein Kalender-Steuerelement
geht recht bequem als reines JavaScript), und Popups haben die nervige
Eigenschaft, nie dort zu erscheinen, wo man sie gerne hätte.
IMHO wäre ein einblendbares <div> an der Stelle besser gewesen.
> Ich weiss nicht, was Du mit `innerWidth' willst. Das "Attribut" `width'
> bzw. `height' im dritten Argument von window.open() gibt die Breite bzw.
> Höhe des Viewports des Fensters, nicht die des Fensters, an.
[...]
> var w = window.open("http://pointedears.de/", "foo", "width=512");
> alert([w.width, w.clientWidth, w.innerWidth]);
Stimmt, mittlerweile wird width als die innere Größe betrachtet. Das war
mal anders...
Thomas 'PointedEars' Lahn
> »Thomas 'PointedEars' Lahn« <Point...@web.de> wrote:
>> Rudolf Polzer wrote:
>> >> > Ich tue mich schon sehr schwer damit, einen sinnvollen Einsatz für
>> >> > window.open zu finden. Außer Spamfenstern und Erzwingen einer
>> >> > bestimmten Fenstergröße bzw. Abstellen von Adressleiste etc. habe
>> >> > ich noch nie eine Anwendung dafür gesehen.
>> >> Eine häufige und IMHO sinnvolle Anwendung dafür ist ein Tool-Fenster
>> >> für detaillierte Dateneingaben, beispielsweise ein
>> >> Kalender-Steuerelement.
>> > Wenn man sowas nutzt, sollte man das klar auf der Website dokumentieren
>> > - denn dass window.open ein Fenster öffnet, ist mittlerweile eher die
>> > Ausnahme. Zuviele Werbefirmen haben diese Funktion mit ihrer
>> > Popup-Spammerei so sehr missbraucht, dass alle aktuellen Browser
>> > standardmäßig keine Popups mehr zulassen.
>> Dies gilt AFAIK nicht für Popups, die der Benutzer selbst ausgelöst hat.
>> Und nur um die geht es hier.
>
> Woher soll der Browser das wissen?
Ganz einfach: es wurde kein Script-Code benutzt, um zum window.open()
zu gelangen. Und diese Unterscheidung funktioniert nachweislich.
> Ich kenne Websites, die ihre Popups in document.onclick und ähnlichen
> Handlern registrieren -
Und? Das Popup hat der Benutzer dann trotzdem selbst ausgelöst.
> ebenso im onClick vieler Links.
Welcher Teil von "Benutzer selbst ausgelöst" ist unklar?
> Das machen die, weil viele Popupblocker meinen, "vom Benutzer initiierte
> Popups" erkennen zu können.
Man könnte ja einen Popup-Blocker installieren, der window.open()
innerhalb document.onclick(), in manuell aufgerufenen Event-Listenern
oder gebubbleten Events blockiert.
> Und genau die Seiten sind es, die bei mir in der "deny scripting"-Liste
> stehen.
Solche Sites stünden bei mir auf der "never ever visit again"-Liste.
>> > Und um von einem User eine Änderung seiner Browsereinstellungen zu
>> > verlangen, musst du schon verdammt viel bieten.
>> Wer z.B. auf <URL:http://reiseauskunft.bahn.de/bin/query.exe/dn?> das
>> Kalender-Steuerelement benutzen möchte, hat Script-Support aktiviert
>> und Popups nicht blockiert. Wer nicht, der nicht, kann dann aber
>> dieses Feature auch nicht nutzen.
>
> Doch schon... er kann den Fahrplan abfragen. [...]
Mit "dieses Feature" war latür das Kalender-Steuerelement im Popup gemeint,
nicht die Reiseauskunft selbst.
> Das ist aber ein typischer _sinnvoller_ Einsatz von JavaScript - und wie
> immer ist dieser optional, aber nett. Mich persönlich würde dieses
> Fenster z.B. stören - es dauert erst zu lange, bis das Java-Applet
> dadrin geladen ist (warum das noch als Apple?t Ein Kalender-Steuerelement
> geht recht bequem als reines JavaScript),
Ohne CSS- und DOM-Support geht das nicht so bequem. Ich stimme Dir aber
zu, dass das Java-Applet nicht sein _muss_.
> und Popups haben die nervige Eigenschaft, nie dort zu erscheinen,
> wo man sie gerne hätte.
Wie gesagt, es gibt bei der Einschränkung von Script-Support noch viele
Feinheiten, die da möglich sind. In diesem Fall ignorieren von left/top-
Angaben im dritten Argument von window.open(). Für alles andere ist
allerdings Dein Window-Manager verantwortlich.
> IMHO wäre ein einblendbares <div> an der Stelle besser gewesen.
Das erfordert aber zusätzlich noch Style-Scripting-Support, der dürfte rein
historisch gesehen noch weniger verbreitet sein. Spannend fände ich z.B.,
wie Du ein div-Element in einem Textbrowser einblenden willst. (Und ja, es
gibt anscheinend aktuelle Textbrowser mit Script-Support.)
>> Ich weiss nicht, was Du mit `innerWidth' willst. Das "Attribut" `width'
>> bzw. `height' im dritten Argument von window.open() gibt die Breite bzw.
>> Höhe des Viewports des Fensters, nicht die des Fensters, an.
> [...]
>> var w = window.open("http://pointedears.de/", "foo", "width=512");
>> alert([w.width, w.clientWidth, w.innerWidth]);
>
> Stimmt, mittlerweile wird width als die innere Größe betrachtet. Das war
> mal anders...
Das wäre mir neu. AFAIK hat sich an der Semantik von window.open() seit
mindestens NN4/IE4 diesbezüglich nichts geändert.
<URL:http://wp.netscape.com/eng/mozilla/3.0/handbook/javascript/ref_m-q.htm#177627>
<URL:http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/open_0.asp>
PointedEars
Michael Fesser
>[...] Hiermit scheint es halbwegs zu
>gehen, aber sicher bin ich mir da nicht (nur auf einer Seite getestet,
>und dank der scheinbar absolut nicht vorhandenen Dokumentation der
>Preferences kann ich nicht verifizieren, ob die das tun, was ich denke):
http://www.firefox-browser.de/wiki/About:config_(Einstellungen)
Micha
Rudolf Polzer
> Rudolf Polzer wrote:
> > »Thomas 'PointedEars' Lahn« <Point...@web.de> wrote:
> >> Rudolf Polzer wrote:
> >> >> > Ich tue mich schon sehr schwer damit, einen sinnvollen Einsatz für
> >> >> > window.open zu finden. Außer Spamfenstern und Erzwingen einer
> >> >> > bestimmten Fenstergröße bzw. Abstellen von Adressleiste etc. habe
> >> >> > ich noch nie eine Anwendung dafür gesehen.
> >> >> Eine häufige und IMHO sinnvolle Anwendung dafür ist ein Tool-Fenster
> >> >> für detaillierte Dateneingaben, beispielsweise ein
> >> >> Kalender-Steuerelement.
> >> > Wenn man sowas nutzt, sollte man das klar auf der Website dokumentieren
> >> > - denn dass window.open ein Fenster öffnet, ist mittlerweile eher die
> >> > Ausnahme. Zuviele Werbefirmen haben diese Funktion mit ihrer
> >> > Popup-Spammerei so sehr missbraucht, dass alle aktuellen Browser
> >> > standardmäßig keine Popups mehr zulassen.
> >> Dies gilt AFAIK nicht für Popups, die der Benutzer selbst ausgelöst hat.
> >> Und nur um die geht es hier.
> >
> > Woher soll der Browser das wissen?
>
> Ganz einfach: es wurde kein Script-Code benutzt, um zum window.open()
> zu gelangen. Und diese Unterscheidung funktioniert nachweislich.
Aber selbstverständlich wird immer Script-Code dafür benutzt, wenn es
nicht gerade direkt in einem onClick o.ä. steht.
> > Ich kenne Websites, die ihre Popups in document.onclick und ähnlichen
> > Handlern registrieren -
>
> Und? Das Popup hat der Benutzer dann trotzdem selbst ausgelöst.
Aber sicher nicht gewollt. Das meine ich damit ja.
> > ebenso im onClick vieler Links.
>
> Welcher Teil von "Benutzer selbst ausgelöst" ist unklar?
Ich würde es gerne praktikabler machen, indem ich es durch "vom Benutzer
selbst bewusst ausgelöst" ersetze.
Vom Benutzer selbst ausgelöst sind ja sonst auch onLoad-Popups, denn
diese werden ja vom Benutzer durch das Laden der Seite ausgelöst.
> > Das machen die, weil viele Popupblocker meinen, "vom Benutzer initiierte
> > Popups" erkennen zu können.
>
> Man könnte ja einen Popup-Blocker installieren, der window.open()
> innerhalb document.onclick(), in manuell aufgerufenen Event-Listenern
> oder gebubbleten Events blockiert.
Viel einfacher: window.open() ausschließlich in onClick und JS-URLs von
einer Whitelist von HTML-Tags.
> > Und genau die Seiten sind es, die bei mir in der "deny scripting"-Liste
> > stehen.
>
> Solche Sites stünden bei mir auf der "never ever visit again"-Liste.
Was leider nicht immer so einfach möglich ist. Die Werbefirmen, die
sowas machen, sind einfach schon zu viele.
> >> > Und um von einem User eine Änderung seiner Browsereinstellungen zu
> >> > verlangen, musst du schon verdammt viel bieten.
> >> Wer z.B. auf <URL:http://reiseauskunft.bahn.de/bin/query.exe/dn?> das
> >> Kalender-Steuerelement benutzen möchte, hat Script-Support aktiviert
> >> und Popups nicht blockiert. Wer nicht, der nicht, kann dann aber
> >> dieses Feature auch nicht nutzen.
> >
> > Doch schon... er kann den Fahrplan abfragen. [...]
>
> Mit "dieses Feature" war latür das Kalender-Steuerelement im Popup gemeint,
> nicht die Reiseauskunft selbst.
Und den Rest würde ich nicht als Feature bezeichnen, da es nicht
nennenswert zur Funktion der Reiseauskunft beiträgt. Ich besuche ja
nicht die Reiseauskunft, um mir das schöne Kalender-Popup anzusehen.
> > IMHO wäre ein einblendbares <div> an der Stelle besser gewesen.
>
> Das erfordert aber zusätzlich noch Style-Scripting-Support, der dürfte rein
> historisch gesehen noch weniger verbreitet sein.
Kein auch nur irgendwie klar denkender Mensch surft heute noch mit
Netscape 4 im öffentlichen Internet herum.
> Spannend fände ich z.B., wie Du ein div-Element in einem Textbrowser
> einblenden willst. (Und ja, es gibt anscheinend aktuelle Textbrowser
> mit Script-Support.)
Diese können weder CSS noch Java. Und frei positionierbare Fenster erst
recht nicht.
Und ich bezweifle, dass das jemals einer so implementieren wird - das
Interesse unter Entwicklern, sowas zu implementieren, ist dank der
Werbepopupflut im Netz einfach nur extrem gering.
> >> Ich weiss nicht, was Du mit `innerWidth' willst. Das "Attribut" `width'
> >> bzw. `height' im dritten Argument von window.open() gibt die Breite bzw.
> >> Höhe des Viewports des Fensters, nicht die des Fensters, an.
> > [...]
> >> var w = window.open("http://pointedears.de/", "foo", "width=512");
> >> alert([w.width, w.clientWidth, w.innerWidth]);
> >
> > Stimmt, mittlerweile wird width als die innere Größe betrachtet. Das war
> > mal anders...
>
> Das wäre mir neu. AFAIK hat sich an der Semantik von window.open() seit
> mindestens NN4/IE4 diesbezüglich nichts geändert.
>
> <URL:http://wp.netscape.com/eng/mozilla/3.0/handbook/javascript/ref_m-q.htm#177627>
> <URL:http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/open_0.asp>
Dann war das mal ein Bug in einer Version... ich meine mich aber zu
erinnern, dass NN4 das war, und bei dem überrascht mich nichts mehr.
Goetz Hoffart
> Kein auch nur irgendwie klar denkender Mensch surft heute noch mit
> Netscape 4 im öffentlichen Internet herum.
Das ist ein wenig hart ausgedrückt.
Ich nutze NN4 ab und an auf etwas exotischen Unix-Plattformen - da hat
man oft nichts anderes zur Hand - höchstens noch Dillo oder links.
Und nein, Firefox läßt sich da in den seltensten Fällen "mal eben
schnell" compilieren.
Thomas 'PointedEars' Lahn
> »Thomas 'PointedEars' Lahn« <Point...@web.de> wrote:
>> Rudolf Polzer wrote:
>> > »Thomas 'PointedEars' Lahn« <Point...@web.de> wrote:
>> >> Rudolf Polzer wrote:
>> >> >> Eine häufige und IMHO sinnvolle Anwendung [für window.open()] ist
>> >> >> ein Tool-Fenster für detaillierte Dateneingaben, beispielsweise ein
>> >> >> Kalender-Steuerelement.
>> >> > Wenn man sowas nutzt, sollte man das klar auf der Website
>> >> > dokumentieren - denn dass window.open ein Fenster öffnet, ist
>> >> > mittlerweile eher die Ausnahme. Zuviele Werbefirmen haben diese
>> >> > Funktion mit ihrer Popup-Spammerei so sehr missbraucht, dass alle
>> >> > aktuellen Browser standardmäßig keine Popups mehr zulassen.
>> >> Dies gilt AFAIK nicht für Popups, die der Benutzer selbst ausgelöst
>> >> hat. Und nur um die geht es hier.
>> > Woher soll der Browser das wissen?
>> Ganz einfach: es wurde kein Script-Code benutzt, um zum window.open()
^^^^^^^^^^^^^^^^^^^^
>> zu gelangen. Und diese Unterscheidung funktioniert nachweislich.
^^^^^^^^^^^^
> Aber selbstverständlich wird immer Script-Code dafür benutzt, wenn es
> nicht gerade direkt in einem onClick o.ä. steht.
Lies bitte genauer hin. Allerdings ist mir aufgefallen, dass diese
Definition trotzdem nicht hinreichend ist.[1]
>> > ebenso im onClick vieler Links.
>> Welcher Teil von "Benutzer selbst ausgelöst" ist unklar?
>
> Ich würde es gerne praktikabler machen, indem ich es durch "vom
> Benutzer selbst bewusst ausgelöst" ersetze.
ACK
> Vom Benutzer selbst ausgelöst sind ja sonst auch onLoad-Popups, denn
> diese werden ja vom Benutzer durch das Laden der Seite ausgelöst.
*mit den Augen roll*
*Augen wieder einsammel*
>> > Das machen die, weil viele Popupblocker meinen, "vom Benutzer
>> > initiierte Popups" erkennen zu können.
>> Man könnte ja einen Popup-Blocker installieren, der window.open()
>> innerhalb document.onclick(), in manuell aufgerufenen Event-Listenern
>> oder gebubbleten Events blockiert.
>
> Viel einfacher: window.open() ausschließlich in onClick und JS-URLs von
> einer Whitelist von HTML-Tags.
[1] Damit werden schonmal benutzerdefinierte Funktionen zum
browserkompatiblen und scriptcodewurmvermeidenden Einsatz von
window.open() ausgehebelt. Nicht gut.
>> > Und genau die Seiten sind es, die bei mir in der "deny scripting"-Liste
>> > stehen.
>> Solche Sites stünden bei mir auf der "never ever visit again"-Liste.
>
> Was leider nicht immer so einfach möglich ist. Die Werbefirmen, die
> sowas machen, sind einfach schon zu viele.
man 5 hosts
>> >> > Und um von einem User eine Änderung seiner Browsereinstellungen zu
>> >> > verlangen, musst du schon verdammt viel bieten.
>> >> Wer z.B. auf <URL:http://reiseauskunft.bahn.de/bin/query.exe/dn?> das
>> >> Kalender-Steuerelement benutzen möchte, hat Script-Support aktiviert
>> >> und Popups nicht blockiert. Wer nicht, der nicht, kann dann aber
>> >> dieses Feature auch nicht nutzen.
>> > Doch schon... er kann den Fahrplan abfragen. [...]
>> Mit "dieses Feature" war latür das Kalender-Steuerelement im Popup
>> gemeint, nicht die Reiseauskunft selbst.
>
> Und den Rest würde ich nicht als Feature bezeichnen, da es nicht
> nennenswert zur Funktion der Reiseauskunft beiträgt. Ich besuche ja
> nicht die Reiseauskunft, um mir das schöne Kalender-Popup anzusehen.
<URL:http://foldoc.org/?query=feature&action=Search>
>> > IMHO wäre ein einblendbares <div> an der Stelle besser gewesen.
>> Das erfordert aber zusätzlich noch Style-Scripting-Support, der dürfte
>> rein historisch gesehen noch weniger verbreitet sein.
>
> Kein auch nur irgendwie klar denkender Mensch surft heute noch mit
> Netscape 4 im öffentlichen Internet herum.
Demnach hältst Du z.B. IRIX-Benutzer (z.B. in RZs von Universitäten) oder
Benutzer leistungsschwächerer Computer nicht für "irgendwie klar denkende
Menschen". Und Du willst Deinen Besuchern den UA vorschreiben. Toll.
>> Spannend fände ich z.B., wie Du ein div-Element in einem Textbrowser
>> einblenden willst. (Und ja, es gibt anscheinend aktuelle Textbrowser
>> mit Script-Support.)
>
> Diese können weder CSS noch Java.
Richtig. _Du_ hattest vorgeschlagen, ein div-Element einzublenden ...
> Und frei positionierbare Fenster erst recht nicht.
Da bin ich mir nicht so sicher.
> [...]
>> >> Ich weiss nicht, was Du mit `innerWidth' willst. Das "Attribut"
>> >> `width' bzw. `height' im dritten Argument von window.open() gibt die
>> >> Breite bzw. Höhe des Viewports des Fensters, nicht die des Fensters,
>> >> an.
>> > [...]
>> >> var w = window.open("http://pointedears.de/", "foo", "width=512");
>> >> alert([w.width, w.clientWidth, w.innerWidth]);
>> > Stimmt, mittlerweile wird width als die innere Größe betrachtet. Das
>> > war mal anders...
>> Das wäre mir neu. AFAIK hat sich an der Semantik von window.open() seit
>> mindestens NN4/IE4 diesbezüglich nichts geändert. [URLs zu Dokus]
>
> Dann war das mal ein Bug in einer Version... ich meine mich aber zu
> erinnern, dass NN4 das war, und bei dem überrascht mich nichts mehr.
Bei meinem Mozilla/4.8 [en] (X11; U; Linux 2.6.14-20051103.160641+0100 i686)
jedenfalls ist so, wie ich es beschrieben habe.
PointedEars
Rudolf Polzer
> Rudolf Polzer wrote:
> > »Thomas 'PointedEars' Lahn« <Point...@web.de> wrote:
> >> > Das machen die, weil viele Popupblocker meinen, "vom Benutzer
> >> > initiierte Popups" erkennen zu können.
> >> Man könnte ja einen Popup-Blocker installieren, der window.open()
> >> innerhalb document.onclick(), in manuell aufgerufenen Event-Listenern
> >> oder gebubbleten Events blockiert.
> >
> > Viel einfacher: window.open() ausschließlich in onClick und JS-URLs von
> > einer Whitelist von HTML-Tags.
>
> [1] Damit werden schonmal benutzerdefinierte Funktionen zum
> browserkompatiblen und scriptcodewurmvermeidenden Einsatz von
> window.open() ausgehebelt. Nicht gut.
Nein.
Bei window.open sollte einfach geprüft werden, ob das aktuell
bearbeitete Event ein eben solches onClick oder eine JS-URL ist. Die
Information liegt auf dem Aufrufstack.
Durch wieviele Funktionen das jetzt geht, sei dabei unerheblich.
> >> > Und genau die Seiten sind es, die bei mir in der "deny scripting"-Liste
> >> > stehen.
> >> Solche Sites stünden bei mir auf der "never ever visit again"-Liste.
> >
> > Was leider nicht immer so einfach möglich ist. Die Werbefirmen, die
> > sowas machen, sind einfach schon zu viele.
>
> man 5 hosts
Solcher Code wird mittlerweile schon gerne server-side auf die Seite
geklatscht. Für irgendwas hat man ja PHP. Müssen die Werbefirmen ja auch
machen, um Adblock auszuhebeln - war die logische Konsequenz.
> >> > IMHO wäre ein einblendbares <div> an der Stelle besser gewesen.
> >> Das erfordert aber zusätzlich noch Style-Scripting-Support, der dürfte
> >> rein historisch gesehen noch weniger verbreitet sein.
> >
> > Kein auch nur irgendwie klar denkender Mensch surft heute noch mit
> > Netscape 4 im öffentlichen Internet herum.
>
> Demnach hältst Du z.B. IRIX-Benutzer (z.B. in RZs von Universitäten) oder
> Benutzer leistungsschwächerer Computer nicht für "irgendwie klar denkende
> Menschen". Und Du willst Deinen Besuchern den UA vorschreiben. Toll.
Nein.
Aber mit NN4 ins öffentliche Internet zu gehen, würde ich mich nicht
trauen. Lieber lasse ich es mit dem WWW sein - einfach aus
Sicherheitsgründen. NN4 ist mindestens so löchrig wie IE5, alleine die
ganzen SEGVs sprechen für sich.
Das öffentliche Internet ist nicht mehr so freundlich, wie es mal war -
heute lauern an jeder Ecke irgendwelche Werbe/Adware/Spyware/Dialer-Fuzzis
und an allen anderen Stellen irgendwelche Kiddies. Da kann man keine
bekannt unsichere Software einsetzen. Da muss man aktuelle Software
einsetzen und diese auch aktuell halten.
> >> Spannend fände ich z.B., wie Du ein div-Element in einem Textbrowser
> >> einblenden willst. (Und ja, es gibt anscheinend aktuelle Textbrowser
> >> mit Script-Support.)
> >
> > Diese können weder CSS noch Java.
>
> Richtig. _Du_ hattest vorgeschlagen, ein div-Element einzublenden ...
Na und? Wenn's nicht geht, geht's halt nicht. Dem Kalender-Steuerelement
wäre so oder so nicht geholfen.
> > Und frei positionierbare Fenster erst recht nicht.
>
> Da bin ich mir nicht so sicher.
Es kann bisher nur links, und der kann per JS im Textmodus keine Fenster
öffnen. Außer, er läuft innerhalb von GNU screen, dann macht er einen
weiteren auf.
Im Grafikmodus dagegen kann Links das "halbwegs komplett".
Goetz Hoffart
> Aber mit NN4 ins öffentliche Internet zu gehen, würde ich mich nicht
> trauen. Lieber lasse ich es mit dem WWW sein - einfach aus
> Sicherheitsgründen. NN4 ist mindestens so löchrig wie IE5, alleine die
> ganzen SEGVs sprechen für sich.
Das stimmt für Windows - aber ich glaube doch nicht, dass es relevante,
heute im WWW verbreitete Schadsoftware für IRIX oder AIX 3.2.5 gibt, die
auch dann läuft, wenn man (wie unter Unix eben üblich) keine erweiterten
Rechte hat.
Rudolf Polzer
"Nur" die Rechte des ausführenden Users. Der hat oft auch "interessante"
Daten.
Thomas 'PointedEars' Lahn
> »Thomas 'PointedEars' Lahn« <Point...@web.de> wrote:
>> Rudolf Polzer wrote:
>> > »Thomas 'PointedEars' Lahn« <Point...@web.de> wrote:
> [...]
>> > > [Popups sinnvoll blockieren]
>> > Viel einfacher: window.open() ausschließlich in onClick und
>> > JS-URLs von einer Whitelist von HTML-Tags.
>>
>> [1] Damit werden schonmal benutzerdefinierte Funktionen zum
>> browserkompatiblen und scriptcodewurmvermeidenden Einsatz von
>> window.open() ausgehebelt. Nicht gut.
>
> Nein.
>
> Bei window.open sollte einfach geprüft werden, ob das aktuell
> bearbeitete Event ein eben solches onClick oder eine JS-URL ist.
Es gibt keine JS-URLs; ich weiss aber, was Du meinst.
> Die Information liegt auf dem Aufrufstack.
>
> Durch wieviele Funktionen das jetzt geht, sei dabei unerheblich.
Einverstanden. (Jetzt musst Du nur noch das Problem lösen, dass jeder
Popup-Blocker sich in die Script-Engine einklinken muss und man in
JScript jedenfalls nativ nicht an den Stack kommt.)
>> >> > Und genau die [Websites, bei denen ein unerwünschtes Popup als
>> >> > vom Benutzer ausgelöstes Popup erkannt wird,] sind es, die bei
>> >> > mir in der "deny scripting"-Liste stehen.
>> >> Solche Sites stünden bei mir auf der "never ever visit again"-Liste.
>> > Was leider nicht immer so einfach möglich ist. Die Werbefirmen, die
>> > sowas machen, sind einfach schon zu viele.
>> man 5 hosts
>
> Solcher Code wird mittlerweile schon gerne server-side auf die Seite
> geklatscht. Für irgendwas hat man ja PHP. Müssen die Werbefirmen ja auch
> machen, um Adblock auszuhebeln - war die logische Konsequenz.
Du hast da offensichtlich irgendwas bei serverseitiger Verarbeitung nicht
verstanden. Guckst Du hier:
<URL:http://groups.google.de/group/de.comp.lang.javascript/msg/82952a8db74a0346?hl=de&lr=&ie=UTF-8>
>> >> > IMHO wäre ein einblendbares <div> an der Stelle besser gewesen.
>> >> Das erfordert aber zusätzlich noch Style-Scripting-Support, der dürfte
>> >> rein historisch gesehen noch weniger verbreitet sein.
>> > Kein auch nur irgendwie klar denkender Mensch surft heute noch mit
>> > Netscape 4 im öffentlichen Internet herum.
>> Demnach hältst Du z.B. IRIX-Benutzer (z.B. in RZs von Universitäten) oder
>> Benutzer leistungsschwächerer Computer nicht für "irgendwie klar denkende
>> Menschen". Und Du willst Deinen Besuchern den UA vorschreiben. Toll.
> Nein.
>
> Aber mit NN4 ins öffentliche Internet zu gehen, würde ich mich nicht
> trauen. Lieber lasse ich es mit dem WWW sein - einfach aus
> Sicherheitsgründen. NN4 ist mindestens so löchrig wie IE5, alleine die
> ganzen SEGVs sprechen für sich.
Der Vergleich hinkt nicht, er humpelt auch nicht mehr, er fällt gleich um.
NN4 auf Unices unterstützt noch nicht einmal ActiveX. Udiags.
> Das öffentliche Internet ist nicht mehr so freundlich, wie es mal war -
> heute lauern an jeder Ecke irgendwelche Werbe/Adware/Spyware/Dialer-Fuzzis
> und an allen anderen Stellen irgendwelche Kiddies. Da kann man keine
> bekannt unsichere Software einsetzen. Da muss man aktuelle Software
> einsetzen und diese auch aktuell halten.
Wer von uns ist jetzt paranoid? :)
>> >> Spannend fände ich z.B., wie Du ein div-Element in einem Textbrowser
>> >> einblenden willst. (Und ja, es gibt anscheinend aktuelle Textbrowser
>> >> mit Script-Support.)
>> > Diese können weder CSS noch Java.
>> Richtig. _Du_ hattest vorgeschlagen, ein div-Element einzublenden ...
>
> Na und? Wenn's nicht geht, geht's halt nicht. Dem Kalender-Steuerelement
> wäre so oder so nicht geholfen.
Richtig. Deine Idee ist also bestenfalls als zusätzliche Alternative
brauchbar.
PointedEars
Thomas 'PointedEars' Lahn
> »Goetz Hoffart« <use...@hoffart.de> wrote:
>> Rudolf Polzer <use...@durchnull.ath.cx> wrote:
>> > Aber mit NN4 ins öffentliche Internet zu gehen, würde ich mich nicht
>> > trauen. Lieber lasse ich es mit dem WWW sein - einfach aus
>> > Sicherheitsgründen. NN4 ist mindestens so löchrig wie IE5, alleine die
>> > ganzen SEGVs sprechen für sich.
>> Das stimmt für Windows - aber ich glaube doch nicht, dass es relevante,
>> heute im WWW verbreitete Schadsoftware für IRIX oder AIX 3.2.5 gibt, die
>> auch dann läuft, wenn man (wie unter Unix eben üblich) keine erweiterten
>> Rechte hat.
>
> "Nur" die Rechte des ausführenden Users. Der hat oft auch "interessante"
> Daten.
Du möchtest ein ausführbares/hinreichend belegtes Beispiel bringen, wie man
den ausführenden User per NN4/$UNIX ausspionieren kann. Ich bin gespannt.
PointedEars
Rudolf Polzer
> Rudolf Polzer wrote:
>
> > »Thomas 'PointedEars' Lahn« <Point...@web.de> wrote:
> >> Rudolf Polzer wrote:
> >> > »Thomas 'PointedEars' Lahn« <Point...@web.de> wrote:
> > [...]
> >> > > [Popups sinnvoll blockieren]
> >> > Viel einfacher: window.open() ausschließlich in onClick und
> >> > JS-URLs von einer Whitelist von HTML-Tags.
> >>
> >> [1] Damit werden schonmal benutzerdefinierte Funktionen zum
> >> browserkompatiblen und scriptcodewurmvermeidenden Einsatz von
> >> window.open() ausgehebelt. Nicht gut.
> >
> > Nein.
> >
> > Bei window.open sollte einfach geprüft werden, ob das aktuell
> > bearbeitete Event ein eben solches onClick oder eine JS-URL ist.
>
> Es gibt keine JS-URLs; ich weiss aber, was Du meinst.
Wie heißen die Dinger eigentlich wirklich?
> > Die Information liegt auf dem Aufrufstack.
> >
> > Durch wieviele Funktionen das jetzt geht, sei dabei unerheblich.
>
> Einverstanden. (Jetzt musst Du nur noch das Problem lösen, dass jeder
> Popup-Blocker sich in die Script-Engine einklinken muss und man in
> JScript jedenfalls nativ nicht an den Stack kommt.)
Die Popup-Blocker sind heutzutage in den Browsern eingebaut und mein
Vorschlag wäre daher recht einfach über ein Flag "mayIssuePopups" zu
realisieren, das vom nativen Eventhandler vor Ausführung des Scriptcodes
gesetzt und danach zurückgesetzt wird.
> >> >> > Und genau die [Websites, bei denen ein unerwünschtes Popup als
> >> >> > vom Benutzer ausgelöstes Popup erkannt wird,] sind es, die bei
> >> >> > mir in der "deny scripting"-Liste stehen.
> >> >> Solche Sites stünden bei mir auf der "never ever visit again"-Liste.
> >> > Was leider nicht immer so einfach möglich ist. Die Werbefirmen, die
> >> > sowas machen, sind einfach schon zu viele.
> >> man 5 hosts
> >
> > Solcher Code wird mittlerweile schon gerne server-side auf die Seite
> > geklatscht. Für irgendwas hat man ja PHP. Müssen die Werbefirmen ja auch
> > machen, um Adblock auszuhebeln - war die logische Konsequenz.
>
> Du hast da offensichtlich irgendwas bei serverseitiger Verarbeitung nicht
> verstanden. Guckst Du hier:
> <URL:http://groups.google.de/group/de.comp.lang.javascript/msg/82952a8db74a0346?hl=de&lr=&ie=UTF-8>
Und zwar was habe ich nicht verstanden?
Ich meinte, dass schon einige dazu übergehen, per PHP oder SSI dynamisch
erzeugten HTML- und JavaScript-Code von irgendwelchen Werbefirmen zu
übernehmen, damit das Skript nicht auf dem Host der Werbefirma liegen
muss und Filter es damit erheblich schwerer haben, das Skript zu
beurteilen. Dagegen hilft dann auch der Trick mit der /etc/hosts nicht -
in dem Falle ginge dann ein Popup auf, das seine Bilder nicht laden
kann, weil der Server, von dem sie kommen, blockiert ist. Aber das
Fenster ist dann trotzdem da.
Dass der beschriebene Weg auch der einzig mögliche Weg für Text-Ads ist,
ist klar - aber bei diesen Text-Ads ist es auch kein Problem, wenn diese
nicht blockiert werden können, da sie ohnehin nicht nennenswert stören.
> >> >> > IMHO wäre ein einblendbares <div> an der Stelle besser gewesen.
> >> >> Das erfordert aber zusätzlich noch Style-Scripting-Support, der dürfte
> >> >> rein historisch gesehen noch weniger verbreitet sein.
> >> > Kein auch nur irgendwie klar denkender Mensch surft heute noch mit
> >> > Netscape 4 im öffentlichen Internet herum.
> >> Demnach hältst Du z.B. IRIX-Benutzer (z.B. in RZs von Universitäten) oder
> >> Benutzer leistungsschwächerer Computer nicht für "irgendwie klar denkende
> >> Menschen". Und Du willst Deinen Besuchern den UA vorschreiben. Toll.
> > Nein.
> >
> > Aber mit NN4 ins öffentliche Internet zu gehen, würde ich mich nicht
> > trauen. Lieber lasse ich es mit dem WWW sein - einfach aus
> > Sicherheitsgründen. NN4 ist mindestens so löchrig wie IE5, alleine die
> > ganzen SEGVs sprechen für sich.
>
> Der Vergleich hinkt nicht, er humpelt auch nicht mehr, er fällt gleich um.
> NN4 auf Unices unterstützt noch nicht einmal ActiveX. Udiags.
NN4 ist mir so oft gecrasht gerade bei langen Zeilen im HTML-Code, dass
es einfach ein Overrun sein muss. secunia.com kennt aber keine Lücken
für Netscape 4.78, eventuell war es doch nur ein harmloser DoS.
> >> >> Spannend fände ich z.B., wie Du ein div-Element in einem Textbrowser
> >> >> einblenden willst. (Und ja, es gibt anscheinend aktuelle Textbrowser
> >> >> mit Script-Support.)
> >> > Diese können weder CSS noch Java.
> >> Richtig. _Du_ hattest vorgeschlagen, ein div-Element einzublenden ...
> >
> > Na und? Wenn's nicht geht, geht's halt nicht. Dem Kalender-Steuerelement
> > wäre so oder so nicht geholfen.
>
> Richtig. Deine Idee ist also bestenfalls als zusätzliche Alternative
> brauchbar.
Sie wäre aber geeignet, das Steuerelement ohne störende Fensterrahmen in
der Nähe vom gesteuerten Element zu platzieren.
Thomas 'PointedEars' Lahn
> »Thomas 'PointedEars' Lahn« <Point...@web.de> wrote:
>> Rudolf Polzer wrote:
>> > »Thomas 'PointedEars' Lahn« <Point...@web.de> wrote:
>> >> Rudolf Polzer wrote:
>> >> > »Thomas 'PointedEars' Lahn« <Point...@web.de> wrote:
>> > [...]
>> >> > > [Popups sinnvoll blockieren]
>> >> > Viel einfacher: window.open() ausschließlich in onClick und
>> >> > JS-URLs von einer Whitelist von HTML-Tags.
>> >>
>> >> [1] Damit werden schonmal benutzerdefinierte Funktionen zum
>> >> browserkompatiblen und scriptcodewurmvermeidenden Einsatz von
>> >> window.open() ausgehebelt. Nicht gut.
>> >
>> > Nein.
>> >
>> > Bei window.open sollte einfach geprüft werden, ob das aktuell
>> > bearbeitete Event ein eben solches onClick oder eine JS-URL ist.
>> Es gibt keine JS-URLs; ich weiss aber, was Du meinst.
>
> Wie heißen die Dinger eigentlich wirklich?
Nachdem ich eine Zeitlang "`javascript:'-URIs" schrieb, wurde ich in
comp.infosystems.www.authoring.* freundlich darauf aufmerksam gemacht,
dass das keine URIs (nach RFC3986) sein können, weil z.B. URIs keine
Leerzeichen enthalten dürfen. Da mir bisher nichts besseres eingefallen
ist, bin ich zur Bezeichnung "`javascript:' Pseudo-Protokoll"
zurückgekehrt.
Verbesserungsvorschläge sind willkommen.
>> > Die Information liegt auf dem Aufrufstack.
>> >
>> > Durch wieviele Funktionen das jetzt geht, sei dabei unerheblich.
>> Einverstanden. (Jetzt musst Du nur noch das Problem lösen, dass jeder
>> Popup-Blocker sich in die Script-Engine einklinken muss und man in
>> JScript jedenfalls nativ nicht an den Stack kommt.)
>
> Die Popup-Blocker sind heutzutage in den Browsern eingebaut
Das stimmt so auch nicht. Richtig ist bestenfalls: bei einigen
neueren Browserversionen ist ein Popup-Blocker eingebaut.
> und mein Vorschlag wäre daher recht einfach über ein Flag "mayIssuePopups"
> zu realisieren, das vom nativen Eventhandler vor Ausführung des
> Scriptcodes gesetzt und danach zurückgesetzt wird.
Sorry, da kann ich Dir nicht folgen. (Vielleicht ist es nur schon zu spät^W
früh.)
>> >> >> > Und genau die [Websites, bei denen ein unerwünschtes Popup als
>> >> >> > vom Benutzer ausgelöstes Popup erkannt wird,] sind es, die bei
>> >> >> > mir in der "deny scripting"-Liste stehen.
>> >> >> Solche Sites stünden bei mir auf der "never ever visit
>> >> >> again"-Liste.
>> >> > Was leider nicht immer so einfach möglich ist. Die Werbefirmen, die
>> >> > sowas machen, sind einfach schon zu viele.
>> >> man 5 hosts
>> > Solcher Code wird mittlerweile schon gerne server-side auf die Seite
>> > geklatscht. Für irgendwas hat man ja PHP. Müssen die Werbefirmen ja
>> > auch machen, um Adblock auszuhebeln - war die logische Konsequenz.
>> Du hast da offensichtlich irgendwas bei serverseitiger Verarbeitung nicht
>> verstanden. Guckst Du hier: [URL]
>
> Und zwar was habe ich nicht verstanden?
Ich habe Dich wohl fhcsal verstanden, wobei Du Dich auch missverständlich
ausgedrückt hast.
> Ich meinte, dass schon einige dazu übergehen, per PHP oder SSI dynamisch
> erzeugten HTML- und JavaScript-Code von irgendwelchen Werbefirmen zu
> übernehmen, damit das Skript nicht auf dem Host der Werbefirma liegen
> muss und Filter es damit erheblich schwerer haben, das Skript zu
> beurteilen.
> Dagegen hilft dann auch der Trick mit der /etc/hosts nicht -
> in dem Falle ginge dann ein Popup auf, das seine Bilder nicht laden
> kann, weil der Server, von dem sie kommen, blockiert ist. Aber das
> Fenster ist dann trotzdem da.
Ja und ja.
>> >> >> Spannend fände ich z.B., wie Du ein div-Element in einem
>> >> >> Textbrowser
>> >> >> einblenden willst. (Und ja, es gibt anscheinend aktuelle
>> >> >> Textbrowser mit Script-Support.)
>> >> > Diese können weder CSS noch Java.
>> >> Richtig. _Du_ hattest vorgeschlagen, ein div-Element einzublenden ...
>> > Na und? Wenn's nicht geht, geht's halt nicht. Dem
>> > Kalender-Steuerelement wäre so oder so nicht geholfen.
>> Richtig. Deine Idee ist also bestenfalls als zusätzliche Alternative
>> brauchbar.
>
> Sie wäre aber geeignet, das Steuerelement ohne störende Fensterrahmen in
> der Nähe vom gesteuerten Element zu platzieren.
Ja, unter bestimmten Voraussetzungen, die ich aber nicht für
wahrscheinlicher halte als die Voraussetzungen für ein Popup
per clientseitigem Scripting.
PointedEars
Rudolf Polzer
> Rudolf Polzer wrote:
> > »Thomas 'PointedEars' Lahn« <Point...@web.de> wrote:
> >> Rudolf Polzer wrote:
> >> > Die Information liegt auf dem Aufrufstack.
> >> >
> >> > Durch wieviele Funktionen das jetzt geht, sei dabei unerheblich.
> >> Einverstanden. (Jetzt musst Du nur noch das Problem lösen, dass jeder
> >> Popup-Blocker sich in die Script-Engine einklinken muss und man in
> >> JScript jedenfalls nativ nicht an den Stack kommt.)
> >
> > Die Popup-Blocker sind heutzutage in den Browsern eingebaut
>
> Das stimmt so auch nicht. Richtig ist bestenfalls: bei einigen
> neueren Browserversionen ist ein Popup-Blocker eingebaut.
Genau genommen in Firefox, IE, Opera, Konqueror, Safari, iCab. Bei
Mozilla weiß ich es nicht, und sonst fallen mir keine "voll
JavaScript-fähigen" aktuellen Browser ein.
> > und mein Vorschlag wäre daher recht einfach über ein Flag "mayIssuePopups"
> > zu realisieren, das vom nativen Eventhandler vor Ausführung des
> > Scriptcodes gesetzt und danach zurückgesetzt wird.
>
> Sorry, da kann ich Dir nicht folgen. (Vielleicht ist es nur schon zu spät^W
> früh.)
Naja, im Prinzip macht Konqueror das ja auch schon, wenn ich "open new
windows" auf "smart" stelle - nur, dass er dann Popups von sämtlichen
Eventhandlern aus erlaubt, und das ist zuviel.
Vielleicht mal ein Bugreport von mir... aber erstmal in den Source
schauen, so Sachen werden meist schneller angenommen, wenn sie schon in
Form eines Patchs kommen.
> > Sie wäre aber geeignet, das Steuerelement ohne störende Fensterrahmen in
> > der Nähe vom gesteuerten Element zu platzieren.
>
> Ja, unter bestimmten Voraussetzungen, die ich aber nicht für
> wahrscheinlicher halte als die Voraussetzungen für ein Popup
> per clientseitigem Scripting.
Links2 ist soweit ich weiß der _einzige_ aktuelle JS-fähige Browser, der
kein CSS kann. Und es dürfte um Größenordnungen mehr JS-Absteller als
Links2-User geben - und noch viel mehr Leute, die Popups abgeschaltet
haben.
Wenn man natürlich Rücksicht auf Nutzer antiker Browser (NN4, IE5,
Uralt-Opera, Uralt-Mozilla aus Debian Woody) nimmt, hast du recht - dann
dürfte es wahrscheinlicher sein, dass der JS-Ansatz tut, was er soll.
Johannes Koch
> Nachdem ich eine Zeitlang "`javascript:'-URIs" schrieb, wurde ich in
> comp.infosystems.www.authoring.* freundlich darauf aufmerksam gemacht,
> dass das keine URIs (nach RFC3986) sein können, weil z.B. URIs keine
> Leerzeichen enthalten dürfen.
Wenn man aber alle Nicht-URI-Zeichen escapet, ist es ein URI und
funktioniert trotzdem noch, oder?
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Nachdem ich eine Zeitlang "`javascript:'-URIs" schrieb, wurde ich in
>> comp.infosystems.www.authoring.* freundlich darauf aufmerksam gemacht,
>> dass das keine URIs (nach RFC3986) sein können, weil z.B. URIs keine
>> Leerzeichen enthalten dürfen.
>
> Wenn man aber alle Nicht-URI-Zeichen escapet,
Was verstehst Du unter "Nicht-URI-Zeichen"?
> ist es ein URI
Ich bin nicht sicher. Rein formal ja, denn die relevanten Produktionen
sind folgende:
| URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
| scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
| hier-part = "//" authority path-abempty
| / path-absolute
| / path-rootless
| / path-empty
| path-rootless = segment-nz *( "/" segment )
| segment-nz = 1*pchar
| pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
| unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
| pct-encoded = "%" HEXDIG HEXDIG
| sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
| / "*" / "+" / "," / ";" / "="
| segment = *pchar
| path-empty = 0<pchar>
Allerdings ist `javascript' anscheinend nicht als URI-Schema bei der
IETF registriert[1] oder Teil eines von der IESG erzeugten zusätzlichen
Registrierungsbaums; vor allem findet sich dafür kein Verantwortlicher
(Brendan Eich vielleicht?), wie es BCP35 beschreibt, auf welches RFC3986,
Abschnitt 3.1, verweist.
[1] <URL:http://www.iana.org/assignments/uri-schemes>
> und funktioniert trotzdem noch, oder?
(Gute Frage!) Ja, jedenfalls in Mozilla/4+ ist das sehr wahrscheinlich.
(Für ausführlichere Tests fe lt mir im Moment die Zeit.)
Aber finde mal jemanden, dem Du von der Verwendung in href- und
ähnlichen Attributwerten abraten willst, der das wirklich so macht ;-)
PointedEars
Johannes Koch
> Was verstehst Du unter "Nicht-URI-Zeichen"?
Solche, die nichtin einem URI vorkommen dürfen, wie zum Beispiel das
Leerzeichen.
> Allerdings ist `javascript' anscheinend nicht als URI-Schema bei der
> IETF registriert[1] oder Teil eines von der IESG erzeugten zusätzlichen
> Registrierungsbaums; vor allem findet sich dafür kein Verantwortlicher
> (Brendan Eich vielleicht?), wie es BCP35 beschreibt, auf welches RFC3986,
> Abschnitt 3.1, verweist.
>
> [1] <URL:http://www.iana.org/assignments/uri-schemes>
Vielleicht will Björn ja auch das Schema registrieren, nachdem er schon
die Medientypen registriert hat, weil's sonst niemand gemacht hat.
--
Johannes Koch
Spem in alium nunquam habui praeter in te, Deus Israel.
(Thomas Tallis, 40-part motet)
Bjoern Hoehrmann
>Vielleicht will Björn ja auch das Schema registrieren, nachdem er schon
>die Medientypen registriert hat, weil's sonst niemand gemacht hat.
Nun, daran gedacht habe ich...
--
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/