Mich kotzt das Web 2.0 einfach nur noch an ...

abeginner schrieb:
Nicht sehr viel.

Unter Windows hatte ich mal eine Zeit lang "NoScript". Mit WhiteList und so. In letzter Zeit habe ich auf Windows & einer PinguinDistri "Ghostery" installiert, gleich mal alles blockiert. Ist aber natürlich wie immer Vertrauenssache und diese PlugIns usw blähen einen Browser halt auch stark auf.
Zum Vergrößern anklicken....

Wobei ich ja interessant finde, dass Ghostery die Privatsphäre erhöhen will und ihr Geld mit dem Verkauf von Analysen verdient. Wenngleich die Daten angeblich nur gesammelt werden wenn ich dem zustimme ist das doch dennoch ein seltsames Konzept...? Wer installiert sich denn ein Privacy-Tool und sagt dann "Jap alles rausschicken"?
 
das.chaos schrieb:
Definitiv... der Webbrowser ist an sich (meines erachtens) ein gescheitertes Konzept... gar ein unnoetiger Flaschenhals (der zum Moloch verkommen ist).
Zum Vergrößern anklicken....
Das sehe ich überhaupt nicht so: Der Browser ist ein Integrations-Tool, vergleichbar der archaischen ComdLine, nur mit weit höherer Komplexität und sich immer noch laufend verändernden Protokollen wodurch ein Teil der Probleme entstehen die die Browser haben. Ob der als monolitische Programm oder per Plug-Ins entsprechend der Unix-Philosophie designed ist, ist eine wichtige, aber zweitrangige Frage.
Die Zukunft des sogenannten Web 2.0 sollte sich, wie im ersten Zitat grob umrissen, als eine transitive Abbildung (bei oberflaechlicher Betrachtung) von einem OS bereitgestellten Funktionen und dessen kapselnden Bibliotheken (man verzeihe die von mir hier eingebrachte Oberflaechlichkeit) ueber eine Hochsprache (bspw. Limbo) in eine aus dieser implementierten Abstraktionsschicht entwickeln. Wobei dann diese, die durch html5 definierte Schnittstelle (top-half) implementiert.
Zum Vergrößern anklicken....
Das verschiebt die Komplexität nur in das OS. Das OS sollte aber m.E. klein, schnell, sicher und zuverlässig sein und nicht eine eierlegende Wollmilchsau. Die zeitkritischen Teile (rendering, script interpretation) sind im Client weit besser aufgehoben als im externen OS. GIT ist ein gutes Beispiel für die Verschiebung der Komplexität vom Server auf den Client.

Und dann geht es auch um Macht, also die Frage wer kontrolliert und trifft die Entscheidungen wie und welche Inhalte dargestellt werden. Im Browser liegt die Kontrolle über die gelieferten Inhalte beim Autor und Webdesigner, und der Benutzer kann entscheiden was er annimmt und was nicht. Das ist ein dezentralisiertes Modell das Abhängigkeiten vom Server reduziert was allemal jeder Zentralisierung vorzuziehen ist. Das damit andere Probleme verbunden sind die einer Lösung bedürfen, und die gelöst werden können, steht außer Frage.

BTW: Ich bedaure zutiefst dass das Konzept der alten (!) Opera aufgegeben worden ist. Hier hatte ich - bis auf Putty und Co - alles in einem Programm was ich für das Inet brauchte und mußte mich nicht mit unterschiedlichen Programmen mit unterschiedlichen Konventionen herumärgern. Warum der Austausch der Display-Engine eine totale Reorganisation notwendig machte ist mir immer noch ein Rätsel, - bye bye Opera. :mad:
 
Azazyel schrieb:
Auch JavaScript-Entwickler sind auf die sinnvolle Idee gekommen, das Rad nicht jedesmal neu zu erfinden, sondern auf existierenden Bibliotheken aufzusetzen.

Im Interesse der Besucher sollte man JavaScript-Bibliotheken auch nicht selber hosten, sondern auf das jeweilige CDN verlinken. Der Browser braucht dann nicht bei jeder Seite, die z.B. jQuery verwendet, die Bibliothek neu laden, sondern kann sich einfach aus seinem lokalen Cache bedienen.
Zum Vergrößern anklicken....
Das macht aus Performancegründen Sinn, ist aber ein realität gewordener Security Alptraum.

Denn dadurch ist es so gut wie unmöglich das WWW zu verwenden ohne Fremdinhalte zu blocken. Wenn das CDN gehackt ist, dann werden tausende Webauftritte zu Virenverteilern. Das gleiche gilt für Werbung. Das Viren über Werbenetzwerke verteilt werden ist nicht gerade ungewöhnlich. Dazu kommt, dass einem ein Anbieter jederzeit kritische Infrastruktur unterm Hintern wegziehen kann.

Nicht zu vergessen, dass der Einsatz von CDNs https unterwandert. Wenn man eh nicht verschlüsseln kann, könnten die ISPs genauso gut Caching Proxies einsetzen. Die würden dann für alle funktionieren, statt bloß für große Konzerne, die sich die Dienste eines CDN leisten können. Wenn der Proxy mit Prüfsummen arbeitet würde das auch das redundanten Vorhandensein von .js Bibliotheken abmildern.
 
Kamikaze schrieb:
Denn dadurch ist es so gut wie unmöglich das WWW zu verwenden ohne Fremdinhalte zu blocken. Wenn das CDN gehackt ist, dann werden tausende Webauftritte zu Virenverteilern.
Zum Vergrößern anklicken....

Dafür gibt es Subresource Integrity:
HTML: 
<script src="https://code.jquery.com/jquery-1.10.2.min.js"
        integrity="ni:///sha-256;C6CB9UYIS9UJeqinPHWTHVqh_E1uhG5Twh-Y5qFQmYg?ct=application/javascript">
Entspricht die tatsächliche Prüfsumme nicht der Erwartung, wird die Bibliothek nicht geladen.

Kamikaze schrieb:
Das gleiche gilt für Werbung. Das Viren über Werbenetzwerke verteilt werden ist nicht gerade ungewöhnlich.
Zum Vergrößern anklicken....

Korrekt, Flash und Java-Applets lassen grüßen.
Wobei sich viele Seiten nur über Werbung finanzieren können - das ist aber ein anderes Thema.

Kamikaze schrieb:
Dazu kommt, dass einem ein Anbieter jederzeit kritische Infrastruktur unterm Hintern wegziehen kann.
Zum Vergrößern anklicken....

Das ist ein Tradeoff - Ladezeiten für den Anwender und geringere Kosten vs. Verfügbarkeit des CDNs.

Kamikaze schrieb:
Die würden dann für alle funktionieren, statt bloß für große Konzerne, die sich die Dienste eines CDN leisten können.
Zum Vergrößern anklicken....

Wenn ein JavaScript-Framework populär genug ist, findet sich auch jemand, der die Kosten für das CDN übernimmt.
Wer mehr braucht, kann die entsprechende Bibliothek immer noch selber für seine eigene Anwendung hosten.
 
Azazyel schrieb:
Dafür gibt es Subresource Integrity:
HTML: 
<script src="https://code.jquery.com/jquery-1.10.2.min.js"
        integrity="ni:///sha-256;C6CB9UYIS9UJeqinPHWTHVqh_E1uhG5Twh-Y5qFQmYg?ct=application/javascript">
Entspricht die tatsächliche Prüfsumme nicht der Erwartung, wird die Bibliothek nicht geladen.
Zum Vergrößern anklicken....
Das ist ziemlich cool. Jetzt fehlt mir nur die Option im Browser, die remote Scripte abschaltet, wenn keine (sichere) Prüfsumme verwendet wird.
 
Azazyel

... "semantic body browser" ... sehr schöne und nützliche Applikation, keine Frage, aber eben eine Applikation. Und eben da fängt die Sünde an, beim Applikation sein, beim "das Ding läuft zu einem wesentlichen Teil in meinem Browser".
Sowas nenne ich dann "surf-by application". Der "Browser" kann das heutzutage halt. Mal eben ne app runterladen und auf meiner Kiste ausführen. Na ja, eigentlich nicht; eigentlich kann er's nur, weil er völlig pervertiert wurde und weite Teile der Funktionalität eines OS zur Verfügung stellt.

Aber das wollte und will ich nicht. Ein Browser hat eigentlich eine recht klar umrissene Aufgabe. Mit dem kann ich - erfreulich reichhaltig gestaltbare - Seiten ansehen. Reichhaltig wie in "Passable Anzahl von Textdarstellungs/Formatierungs Möglichkeiten plus Bilder und - wichtig - mit Verweisen (links)".

Wenn ich eine tolle Applikation will, dann lade ich sie runter. Und dann kann ich selbst über so einiges verfügen.

Vermutlich gibt es inzwischen tatsächlich einen Bedarf an "Web Applkationen". Und zwar weil der von einer gigantesken Marketing Machinerie geschaffen wurde. Aber, O.K., wenn Leute das wollen, dann sollen sie's auch gerne kriegen. Nur nicht in meinem Browser - denn den hab ich zum Browsen. Die sollen von mir aus "web 3.0" basteln, mit java, javascript, dart, vb, net .net engine, und sonst noch allerlei, mir egal. Das können die dann auf ihre apple pad und android devices runterladen oder von mir aus auch auf "dynamisches Klopapier 2.0".

Das Problem ist nämlich, dass dieser ganze Mist nicht umsonst ist. Wir bezahlen z.B. mit ganz erheblichen Sicherheitsverlusten dafür. Aber auch mit irrwitzigen Systemanforderungen. Da ist für mich der Maßstab nämlich nicht, ob Frl. Müller semantic body web oder google earth auf ihrem Handy haben kann, sondern ob das junge Fräulein Shrivasvarta in Indien aufm Land an Informationen kommen kann. Und das kann sie nicht; weil sie nicht die Mittel hat, um Ubuntu auf ner 4 GB Kiste mit 2,8 GHz dual core und mit dem ganze web 2.0 Mist zu haben. Da hat dann die ganze Schulklasse 1 Rechner, wenn sie Glück haben.
Und auch mine Mutter kapiert nicht im mindesten, was da vor sich geht und hat regelmäßig eine völlig versaute, verdreckte Büchse mit haufenweise Spam und sonst noch was.

Und bitte erzählt mir nix über Sicherheit, O.K. - nicht mal so sehr, weil das mein Fachgebiet ist und ich *weiss*, dass 90% der "Sicherheit" nichts als halbgarer Mist ist. Sondern weil es halbgarer Mist ist. Das ist zum großen Teil Zeug aus sehr zweifelhaften Quellen, vielleicht noch eben abgesegnet von nem "web 2.0" Konzern. Die Märchenstunde sollte doch spätestens seit heartbleed vorbei sein. Nehmt's doch endlich zur Kenntnis, dass das "viele Augen" Prinzip nur ein feuchter Traum war, der schlimm in die Hose ging. Noch nicht mal *zuständige* (und durchaus kompetente) Augen haben's verhindert. Die Gründe sind vielfältig - und denen sehr ähnlich, warum der ganze web 2.0 Mist von vorne bis hinten unsicherer Crap mit security Blabla Garnierung ist.

Also, Kurzversion: Ich will Web 1.0. Von mir aus auch Web 1.2, im Sinne eine gesunden, gut überlegten und gut umgesetzten Weiterentwicklung. Als Grundausstattung. Für Mutti, Fr. Köttenbrink und 2 Mrd. Menschen in ärmeren Ländern.
Und ich will, dass wir web 1.0 reparieren und sicher machen, bevor wir's erweitern und anbauen.

Plus, zusätzlich und als eigenes Ding, web 2.0 oder 7.0 mit share-your-fart (in Stereo. Mindestens.) semantic body browser, web office (haha) etc. usw.
 
Für den OP:

Ja ich kann dein Eingangs-Thread vollstens verstehen. So ist die Welt nunmal.

Ich nutze eine 6-12KB!!!-Leitung und es geht damit vieles, weil...
a) Textbrowser
b) alles an Skripten, Graphiken in Gui-Browser abgeschaltet ist

Bei Bedarf kann es angeschaltet werden. Nur bei Bedarf.

Fast alles ist damit benutzbar.

Warum krähen?

Gruß
Chu
 
rubricanis schrieb:
Das sehe ich überhaupt nicht so: Der Browser ist ein Integrations-Tool, vergleichbar der archaischen ComdLine, nur mit weit höherer Komplexität und sich immer noch laufend verändernden Protokollen wodurch ein Teil der Probleme entstehen die die Browser haben.
Zum Vergrößern anklicken....

Integrations-tool? Warum so Konservativ? :-) Warum nicht einen
Browser durch bspw. eine VM ersetzen? Das versuchte ich zu
artikulieren. :-).

rubricanis schrieb:
Ob der als monolitische Programm oder per Plug-Ins entsprechend der
Unix-Philosophie designed ist, ist eine wichtige, aber zweitrangige Frage.
Zum Vergrößern anklicken....

bzw.

rubricanis schrieb:
Das verschiebt die Komplexität nur in das OS. Das OS sollte aber m.E. klein, schnell, sicher und zuverlässig sein und nicht eine eierlegende Wollmilchsau. Die zeitkritischen Teile (rendering, script interpretation) sind im Client weit besser aufgehoben als im externen OS. GIT ist ein gutes Beispiel für die Verschiebung der Komplexität vom Server auf den Client.
Zum Vergrößern anklicken....

Ein monolitisches Programm (hier der Browser) kastriert IMHO
die Moeglichkeiten (sowohl derjenigen die sogennante "Web-applikationen"
entwickeln als auch denjenigen die diese nutzen), die tatsaechlich sich bieten
wuerden, wenn ein tatsaechliches "Web 2.0" (oder auch 3.0) als verteiltes
System (Phrase of the day: "The network is the Computer", Sun Microsystems)
implementiert werden wuerde.

Der Browser bzw. seine Komplexizitaet bzw. der allseits
beliebte Firefox (als abschreckendes Beispiel), der tatsaechlich
als OS weiterentwickelt wird (was nur Konsequent ist *lol*) fuehrt
IMHO das Konzept verteilter Systeme (und dessen Anwendungen)
ad absurdum, da man quasi nur durch ein kleines "Fenster" in eine
"Welt" blickt.

Nun denn, bspw. dieses JavaScript Kasperltheater erscheint mir
wie eine Art Workaround (man verzeihe mir diese Ignoranz,
bitte mich jetzt nicht steinigen), um diese Defizit zu ueberwinden
bzw. verteilte Systeme darzustellen.

rubricanis schrieb:
Und dann geht es auch um Macht, also die Frage wer kontrolliert und trifft die Entscheidungen wie und welche Inhalte dargestellt werden. Im Browser liegt die Kontrolle über die gelieferten Inhalte beim Autor und Webdesigner, und der Benutzer kann entscheiden was er annimmt und was nicht.
Zum Vergrößern anklicken....

Letzendlich wuerde IMHO bspw. durch das Firefox OS geschaffenen
kuenstlichen Machtposition (seitens der Entwickler und Integratoren)
dem Machtmissbrauch Tuer und Tor oeffnen.

Diese Entwicklung sehe ich deutlich Kritischer, als wenn eine
existierende VM (Dis, JRE, ...) verwendet werden wuerde (oder
eine neu entwickelt wuerde), um eine Basis fur (tasaechliche)
"Web-entwicklung" darzustellen.
 
Ich will an dieser Stelle nochmal alle, die Unbehagen am Nutzen des http-webs haben, ermutigen gopher zu nutzen. Gopher ist mitnichten tot. Es gibt da einen schoenen Artikel[1], der jenen, die es nicht eh schon wissen, erklaert, warum gopher auch heute noch Sinn macht. Es gibt auch einige interessante Projekte im "gopher space", z.B. wikipedia[2]. Je mehr Leute sich im gopher space tummeln, desto weniger haeufig muss man ins http web ausweichen ;)
Als gopher client kann man ein gopher2http Gateway nutzen (s.u.), Addons fuer die gaengigsten Desktop-Browser (z.B. Overbite) oder man nutzt lynx, gopher, ...
Auch das Aufsetzen eines eigenen gopher servers (z.B. bucktooth, motsognir, ...) ist nicht sonderlich schwer.
Dann gibt es eine Mailingliste[3] auf der aktuelle Themen rund um gopher verhandelt werden.

[1] http://gopher.floodgap.com/gopher/gw?gopher://gopher.floodgap.com:70/0/gopher/relevance.txt
[2] gopher://gopherpedia.com
[3] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project
 
Azazyel schrieb:
Im Interesse der Besucher sollte man JavaScript-Bibliotheken auch nicht selber hosten, sondern auf das jeweilige CDN verlinken.
Zum Vergrößern anklicken....
Vorsicht: Sowas klingt immer so einleuchtend und daher "muss es ja richtig sein". Aber in Sachen Webperformance - und ganz besonders wenn es um Javascript geht - muss man doch immer wieder reale Daten analysieren, bevor man zu einer Antwort kommt. Für das Verlinken von jQuery hat Steve Souders letztes Jahr eine interessante Analyse veröffentlicht. Er vergleicht drei Optionen: Google-gehosteten Code einbinden über ajax.googleapis.com, die einzelne Library selbst hosten oder die Library mit anderen Javascripts bundeln und selbst hosten.

Das ganz kurze Fazit:
If you’re loading core jQuery as a standalone request from your own server (which 38% of sites are doing), you’ll probably get an easy performance boost by switching to Google Hosted Libraries. If you’re considering creating a combined script that includes jQuery, the issues raised here may mean that’s not the optimal solution. [...]
To make the best decision, website owners need to test the alternatives. Using a RUM solution [...] will tell you the impact on your real users.
Zum Vergrößern anklicken....

Hier die Conclusion in voller Länge:
This blog post contains many statistics that are useful in deciding whether to load jQuery from Google Hosted Libraries. The pros of requesting jQuery core from Google Hosted Libraries are:

  • potential benefit of cross-site caching
  • ease of switching if you’re already loading jQuery core as a standalone request
  • no hosting, storage, bandwidth, nor maintenance costs
  • benefit of Google’s CDN performance
  • 1-year cache time
The cons to loading jQuery from Google Hosted Libraries include:

  • an extra DNS lookup
  • you might use a different CDN that’s faster
  • can’t combine jQuery with your other scripts
There are two other more complex but potentially significant issues to think about if you’re considering bundling jQuery with your other scripts. (Thanks to Ilya Grigorik for mentioning these.)

First, combining multiple scripts together increases the likelihood of the resource needing to be updated. This is especially true with regard to bundling with jQuery since jQuery is likely to change less than your site-specific JavaScript.

Second, unlike an HTML document, a script is not parsed incrementally. That’s why some folks, like Gmail, load their JavaScript in an iframe segmented into multiple inline script blocks thus allowing the JavaScript engine to parse and execute the initial blocks while the file is still being downloaded. Combining scripts into a single, large script might reach the point where delayed parsing would be offset by downloading two or more scripts. As far as I know this has not been investigated enough to determine how “large” the script must be to reach the point of negative returns.

If you’re loading core jQuery as a standalone request from your own server (which 38% of sites are doing), you’ll probably get an easy performance boost by switching to Google Hosted Libraries. If you’re considering creating a combined script that includes jQuery, the issues raised here may mean that’s not the optimal solution.

SteveW and I both agree: To make the best decision, website owners need to test the alternatives. Using a RUM solution like Google Analytics Site Speed, Soasta mPulse, Torbit Insight, or New Relic RUM will tell you the impact on your real users.
Zum Vergrößern anklicken....
 
Short time no forum, und jede Menge Posts...

Yamagi schrieb:
Wem der javascript-lastige Editor zur Fett ist, kann in den Optionen noch immer den simplen Editor auswählen...
Zum Vergrößern anklicken....

Danke für den Hinweis, diese Option war mir direkt nach der Umstellung entgangen. Bisher bin ich damit tatsächlich glücklicher ;)

Azazyel schrieb:
Das kriegst du in allen Browsern nach dem ersten Heartbleed/ShellShock-Event im JavaScript-Umfeld schneller als du "trusted third parties" tippen kannst. ;)
Zum Vergrößern anklicken....

Aber dann ist es doch schon zu spät, oder habe ich deinen Satz einfach nur falsch verstanden?
 
Rakor schrieb:
Wobei ich ja interessant finde, dass Ghostery die Privatsphäre erhöhen will und ihr Geld mit dem Verkauf von Analysen verdient. Wenngleich die Daten angeblich nur gesammelt werden wenn ich dem zustimme ist das doch dennoch ein seltsames Konzept...? Wer installiert sich denn ein Privacy-Tool und sagt dann "Jap alles rausschicken"?
Zum Vergrößern anklicken....
Danke für diese Information, wusste ich nicht. Erstaunt mich aber nach den Berichten über so manche skandalöse PlugIn's nicht.

Chu schrieb:
a) Textbrowser
b) alles an Skripten, Graphiken in Gui-Browser abgeschaltet ist

Bei Bedarf kann es angeschaltet werden. Nur bei Bedarf.

Fast alles ist damit benutzbar.
Zum Vergrößern anklicken....

Ich habe mich da schon gefragt, ob quasi nicht auch der "umgekehrte Weg" sinnvoll ist. Also halt nun mal standardmässig einen üblichen, aber sehr konfigurierbaren Browser verwenden.
Opera (zumindest jene Versionen die ich mal nutzte) und Firefox sind doch eigentlich hervorragend konfigurierbar. Anstatt sich fragwürdigen PlugIn's zu bedienen gleich direkt zB in "about:config" konfigurieren bzw abschalten was unnötig bzw sicherheitsrelevant ist.
So sehr mir Browser wie Lynx oder Links/2 symtpathisch sind, sind sie halt leider für manches wirklich wiederum zu einschränkend.
 
@ Rakor : Diese "Ghostrank" genannte Funktion (in der also Daten tatsächlich aufgezeichnet werden) muss man aber tatsächlich erst mal aktivieren. Aber klar : Vertrauenssache :)
 
CrimsonKing schrieb:
Gegenthese: Ohne diese Mitmachscheiße wäre "DSL Light" für die normale Webnutzung mehr als ausreichend.
Zum Vergrößern anklicken....
Der Artikel ist, mit Verlaub, in weiten Teilen Quatsch. Er schiebt die Schuld allein auf (vermeintlich) diejenigen, die das Internet für geschäftliche Zwecke nutzen. Dass die aber auch einen erheblichen Teil der Infrastruktur finanzieren - oops, vergessen. Und dass softwareseitig merkwürdige Dinge entstehen, ist in erster Linie nicht irgendwelchen BWLern zu verdanken (die können nämlich i. d. R. nicht programmieren), sondern Typen wie Poettering & Co.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben