Google zet controversiële Web Accelerator terug online

Nadat Google zijn Web Accelerator offline haalde wegens de vele heisa die eromheen ontstond, is de plugin nu terug online geplaatst. Met deze software zou het mogelijk worden sneller te surfen, doordat de internetverbinding omgeleid wordt via de servers van Google. Doordat de zoekmachine een supersnelle verbinding heeft met de rest van de wereld en enkel de laatste wijzigingen van een website hoeft te downloaden, kan een gebruiker volgens Google heel wat tijd winnen met het gebruik van de Accelerator-plugin.

Bovendien houdt de plugin de muiscursor in de gaten zodat het programma een pagina al kan beginnen te downloaden zodra de cursor in de buurt van een link komt. Wanneer de gebruiker vervolgens effectief op de link klikt, is een deel van de pagina al ingeladen zodat hij niet zo lang hoeft te wachten. Naast de boze reacties die dit opriep met betrekking tot de privacy van internetgebruikers, ontstond er ook een probleem met beveiligde sites. Door het gebruik van gecachete pagina's werden gebruikersnamen voor verschillende websites verspreid via de Web Accelerator-plugin. Ook bij sites waar links gebruikt kunnen worden om bijvoorbeeld records te verwijderen ontstonden er problemen, doordat de plugin de link onbedoeld al ophaalde omdat de muiscursor in de buurt van de link kwam.

Om deze problemen in de toekomst te vermijden, heeft Google een pagina online gezet met uitleg voor webmasters. Daarin wordt de verantwoordelijkheid voor het onbedoeld uitvoeren van acties bij de webmasters gelegd. Zo wordt bijvoorbeeld uitgelegd dat de HTTP 1.1-specificaties duidelijk stellen dat een link met de GET-method niet gebruikt hoort te worden voor het uitvoeren van acties, maar enkel voor het ophalen van gegevens. Toch stelt Google dat links met query-parameters - onder andere herkenbaar aan een vraagteken in de url - en versleutelde pagina's niet opgehaald zullen worden door de prefetch-technologie. Om prefetch-requests uit de statistieken te kunnen filteren, werd aan de HTTP header de tekst 'x-moz: prefetch' toegevoegd.

Reacties (118)

[Rekcor]

Zo wordt bijvoorbeeld uitgelegd dat de HTTP 1.1-specificaties duidelijk stellen dat een link met de GET-method niet gebruikt hoort te worden voor het uitvoeren van acties, maar enkel voor het ophalen van gegevens.

Eerlijk gezegd vind ik dit een beetje flauw: het staat weliswaar in de regels, maar als het merendeel van de sitebouwers het nou niet doet...moet je volgens mij ook pragmatisch zijn.

@Omega Supreme:

Ik vind dat je beide dingen moet doen: en pragmatisch zijn (omdat er anders privacy- en beveiligingsproblemen kunnen ontstaan) en idd aandringen bij websitebouwers/browserproducenten om zich aan de standaarden te houden.

[Verwijderd]

Inderdaad, en helemaal fijn zou het zijn moesten ze zelf ook consequent zijn in dit gebruik.
http://mail.google.com/mail/?logout&hl=en is volgens mij nog steeds een GET methode die je netjes uitlogt op gMail. Als ik het goed begrijp kan ik met het gebruik van deze accelerator maar best mijn muiscursor uit de buurt van het logout linkje houden?

[sopsop]

Toch stelt Google dat links met query-paramters - onder andere herkenbaar aan een vraagteken in de url - en versleutelde pagina's niet opgehaald zullen worden door de prefetch-technologie

Deze wordt dus niet opgehaald.

Ben wel benieuwd hoe ze dat dan doen met de url-rewrite functionaliteit. Zoals ook bij tweakers i.p.v. _tweakers.net?nieuws=39152
Het volgende wordt gebruikt:
_tweakers.net/nieuws/39152

[Verwijderd]

Als ik het goed lees hoef je je geen zorgen te maken. Er staat zo'n mooi vraagtekentje in de URL wat betekent dat hij nu niet geaccelereerd zal worden.

@ Rekcor: Ik ben er geen voorstander van om pragmatisch om te gaan met bouwers die zich niet aanstandaarden houden.

Wat je wilt is dat men zich richting de standaard beweegt. Als men rekening hiermee houdt is er geen reden voor om bij een volgende aanpassing de standaard toe te passen het werkt toch wel.

Hetzelfde voor websites die browser specifieke pagina's gebruiken. Houdt je aan de standaard en gebruik geen vendor specific extensions. Als je een workaround moet gebruiken voor een browserfout, dan moet dat, maar mail de maker met een dringend verzoek het probleem te corrigeren.

Naar verloop van tijd dit laatste ook niet meer doen en de browser fabrikant hiervan op de hoogte stellen.

[Soultaker]

Eerlijk gezegd vind ik dit een beetje flauw: het staat weliswaar in de regels, maar als het merendeel van de sitebouwers het nou niet doet...moet je volgens mij ook pragmatisch zijn.

Tja, wat is flauw. Ze hebben een methode bedacht om de performance van webbrowsing (tenminste naar de gebruiker toe) te verbeteren en die methode werkt goed volgens alle geldende afspraken. Het is niet alsof ze vage eigenschappen van webservers exploiteren.

De keuze die je dan hebt, is:
a) de kwaliteit van goed geprogrammeerde sites verbeteren ten koste van de werking van een paar slecht geprogrammeerde sites; of:
b) alles laten zoals het is.

Als je altijd met iedereen rekening wilt houden dan kun je dus nooit voortuigang boeken; die paar slecht geprogrammeerde sites gijzelen zo de ontwikkeling van het internet ten koste van de goed geprogrammeerde sites (die van de ontwikkeling hadden kunnen profiteren). Het gezegde dat je geen omelet kunt bakken zonder eieren te breken gaat ook hier op.

Het is dus niet een kwestie van 'flauw' zijn of niet-pragmatisch, maar de vooruitgang van webtechnologie niet laten belemmeren door diegenen die geen zin hebben zich aan standaarden te houden.

[levi_h]

Ik denk dat je met "een paar slecht geprogrammeerde sites" de zaak onderschat.

[Verwijderd]

GET is in feite handig om URLs van search queries te e-mailen, in feite gebruiken de meeste forms GET, alleen als er login.php?u=pietje&p=puk dan moet er wel een belletje gaan rinkelen, volgens mij bedoelen ze zoiets.

[NoControl]

Niet alleen is 't een beetje gek van Google om zo maar eventjes te zeggen dat de webmasters maar beter hadden moeten opletten, een van hun argumenten is ook niet helemaal juist.

HTTP 1.1 (RFC 2616):

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

Er staat dat GET enkel voor opvragen gebruikt ZOU moeten worden.

ZOU is echter geen verplichting, maar een sterke suggestie. Moest er MUST NOT gestaan hebben, DAN had Google gelijk. (Maar dat zou het nog niet veel begrijpelijker maken.)

[Olaf van der Spek]

ZOU is echter geen verplichting, maar een sterke suggestie.

En als je ervoor kiest er vanaf te wijken, dan zijn de consequenties voor jou.

[Fuzzillogic]

Zeer onwelkome actie van Google! Afgezien van security-dingen en de welbekende "logout"-linkjes is dit ook funest voor het tracken van bezoekers! Bedrijven zijn zeer geinteresseert in hoe bezoekers de site 'doorklikken', om te zien of men de gewenste informatie snel kan vinden en aan de hand van die gegevens de site verbeteren.

De statistieken en gegevens worden met deze tool dus enorm vervuild!

Daarnaast natuurlijk nog de extra traffic die dit gaat opleveren. Ik hosts mijn prive-website op mijn eigen ADSL-lijntje en ik heb geen behoefte aan page requests die toch niet bekeken gaan worden. Indien mogelijk zal ik gebruikers van deze Web Accelerator zelfs blokkeren!

[Jermaine]

Enjoy

[Verwijderd]

Geweldig! Ik heb ze nu geblockt met de firewall met een tcp-reset. Maar als google dit doorzet, gaat er op het hele server park een redirector op naar een virtual host.

Dus iptables laten DNAT'en naar 192.168.x.x:80, en apache reageert op een GWA request met een error.

Waarom zo moeilijk?
1) niet per-virtual, maar server-wide
2) geen ongewenste entries in je access_log
3) je hoeft je klanten/gebruikers er niet mee lastig te vallen

Hoop dat jullie er ook wat aan hebben.

[Roland684]

Doe je dit ook voor iedereen die via de proxie van zijn/haar provider surft?

[Verwijderd]

Zullen eigenaren van online shops leuk vinden, alle logs van meest populaire producten, etc kunnen ze wegmikken.

Dus sites moeten maar een ?{var} in de url gaan mikken omdat de Web accelerator het dan niet cached.

Ik vind het een beetje een krom programma, je moet aangeven welke pagina NIET gecached moet worden i.p.v. wel. Google maakt dus voor jou keuzes... beetje jammer.

Webmasters zullen he tnog druk gaan krijgen met robot.txt-tjes, ip ban's, HTTP headers filteren, etc

[Adion]

In totaal zal het je denk ik niet meer, maar net minder traffic opleveren.
Google haalt inderdaad een paar links op waar enkele mensen misschien niet op klikken, maar de sites die wel bekeken worden kunnen 1000x bekeken worden, terwijl google het bij jou slechts 1x ophaalt.

Zoals al gezegd worden enkel vrij statische pagina's gecached, dus zo'n probleem lijkt het mij niet.

[exyll]

Dat is nou juist de gein.. ze cachen je read pagina's voor je dus je krijgt juist MINDER traffic... Tenzij je site dus slecht is ontworpen en tegen de standaarden in gaat.

[BramT]

FYI:

Thank you for your interest in Google Web Accelerator. We have currently reached our maximum capacity of users and are actively working to increase the number of users we can support.

Maar het lijkt me anders toch niet erg nuttig... Pagina's laden doorgaans al in 0,1sec. Sneller hoeft eigenlijk niet
/edit:
Ze zouden bij tweakers 's een mooit testje moeten doen wat het gevolg is voor websites. Mbv de prefetch-header / geregistreerde gebruikers kan t.net mooi een 'gemiddelde extra/minder load' per gebruiker berekenen.

[Rac-On]

heeft iemand de ip's via welk deze plugin werkt?? Dan gaan die gelijk op de zwarte lijst hier, omdat ik:
a) niet wil dat gebruikers de weg kwijtraken doordat ze opeens uigelogd zijn oid
b) m'n statistieken niet verkloot wil zien
c) ik ivm privacy en machtsmisbruik dit zowiezo een slecht initiatief vind

[Verwijderd]

ik vind dit eigenlijk heel sterk op een proxy server lijken...
Google heeft ivm het doorzoeken van het net heel veel caches en snelle servers. Nu mis/gebruiken (het is maar hoe je het ziet) dit om daarmee een webaccelerator te maken.
Dus kort samengevat
1. je statistieken niet meer correct
2. je krijgt niet meer maar juist minder data verkeer naar je site (dat wordt allemaal door google uit de cache gehaald ook als mensen met hun muis over een link hangen)
3. je krijgt dat er mogelijk data in de cache beland die er niet in hoort (ingelogd)
4. sites die juist de google spiders toelieten voor het indexen zullen niet zo blij zijn gezien mensen met een webaccelerator er ook bij kunnen komen..
5. je kan de google spider wel blokeren maar dan kom je ook niet meer in de zoek resulten van google terug....

[liberque]

1. je statistieken niet meer correct

Net zoals met als proxy thingies zal hij toch bij iedere request gaan kijken of er niets aangepast lijkt me. Anders is het direct onbruikbaar. Je statistieken moet je dan anders leren intrepeteren maar het valt nog te doen.

2. je krijgt niet meer maar juist minder data verkeer naar je site (dat wordt allemaal door google uit de cache gehaald ook als mensen met hun muis over een link hangen)

Ik kan me niet voorstellen dat dit onder slechte kritiek valt. Minder traffic is minder kosten, is een happy beheerder. Als Google mijn traffic wilt betalen dan hou ik ze echt niet tegen.

3. je krijgt dat er mogelijk data in de cache beland die er niet in hoort (ingelogd)

Als Google er op die manier al bij kan, dan moet je bij jezelf een hoop vraagtekens gaan zetten of je site niet aan een update toe is. Immers als Google het kan dan kan malware / spyware het ook.

4. sites die juist de google spiders toelieten voor het indexen zullen niet zo blij zijn gezien mensen met een webaccelerator er ook bij kunnen komen..

Je kan specifieke spiders/crawlers toelaten. Zo kan je webaccelerator naar hartelust blocken terwijl Google gewoon zijn werk kan blijven doen.

5. je kan de google spider wel blokeren maar dan kom je ook niet meer in de zoek resulten van google terug....

Je kan stoppen met werken maar dan krijg je ook geen loon meer. Daarnaast kan je Google ook gewoon gerust je webpage laten indexen maar hem verbieden om je linkjes te volgen. Dit doe je met de NOFOLLOW meta tag.

[exyll]

In de http standaard is opgenomen dat een webserver voor opgehaalde content kan aangeven of het gecached mag worden en voor hoelang. Deze gegevens zullen hoogstwaarschijnlijk zo door de google webaccellerator worden overgenomen.

Dus als je dit niet wilt (dus uberhaupt niet wilt dat proxy servers informatie cachen.. want dat is google webaccellerator..) dan aangeven dat ALLE content direct expired. Probleem opgelost.

Het enige nadeel is dat het prefetchen tussen de client pc en google dan ALTIJD ook een load actie op je eigen webserver tot gevolg heeft.

[Immortal_NL]

Meer traffic = meer inkomen (van advertenties op je site)

[liberque]

Meer traffic = meer inkomen (van advertenties op je site)

Hoe werken die advertenties dan? Immers, ik veronderstelde altijd dat deze werkten met referers of unieke tags. In beide gevallen zou dit voor proxy's niet uit mogen maken. De url blijft immers hetzelfde en de unieke tags zullen echt niet door Google gefilterd worden (het is geen Privoxy). Nee, volgens mij hoef je je daar geen zorgen over te maken.

[Roland684]

1) een proxie/browsercache gaat vaak pas kijken of er iets aangepast is nadat de ttl is verstreken.

[mosymuis]

4. How do I differentiate prefetch requests from regular user-initiated requests?

Prefetch requests include an "x-moz: prefetch" HTTP header. Websites can choose to filter out prefetch requests in their server statistics, as well as reject prefetch requests, which would cause the request to be sent only when a user actually clicks on a link.

Uit de FAQ.

[Fuzzillogic]

Als je die eruit gooit, gooi je ook de requests eruit die uiteindelijk wél bekeken werden. Een slechte oplossing dus.

[Verwijderd]

Dus jou gebruikers mogen gewoon zelf software-installeren? Je privacy wordt pas 'geschonden' als jij dat programma installeerd, in de EULA staat omschreven wat het doet, Google bied dit aan, en drukt het niet door jou strot..

Je hebt oko nog een eigen verantwoordelijkheid..

[Rac-On]

gebruikers als in mensen die onze sites bezoeken.

[DarthPlastic]

Ik gebruik al een tijdje de Webaccellerator, en het IP-adres van de proxy (teminste bij mij dan) is 72.14.192.32

edit: Het adres wisselt nogal heb ik gezien dus om alleen dit bovenstaande IP te blocken zal niet veel helpen

[Verwijderd]

Het werkt toch alleen maar bij statische pagina's?
Ik kan me niet voorstellen dat ze bij internetbankieren alle rekeningoverzichten die voorbijkomen gaan cachen.

Of toch wel?

[mosymuis]

Internetbankieren verloopt zoiezo over een beveilige verbinding met de server, Web Accelerator zorgt wel dat hij daar geen byte van cached. De risicogroep zijn de websites over een onbeveiligde verbinding waar bovendien geen duidelijke dynamiek in te herkennen is, bijvoorbeeld met www.site.com/dit/soort/urls in plaats van www.site.com/dit.php?soort=urls (denk hierbij aan T.net en GoT).

Als deze website daarbij dan ook nog eens geen correct gebruik zou maken van de webtechnieken GET en POST bij het uitvoeren van acties loopt de privacy van de bezoeker daarbij gevaar. Ik geeft Google daarin echter wel gelijk, dat de verantwoordelijkheid daarvan bij de ontwikkelaar van de website ligt.

In practice, Google Web Accelerator does not prefetch links which have query parameters (i.e. have a "?" in the URL) and encrypted pages (i.e. URL starting with https://).

[Verwijderd]

Toch vreemd dat als een werkende site niet meer werkt met een google tool de website de schuld krijgt.

[Olaf van der Spek]

Toch vreemd dat als een werkende site niet meer werkt met een google tool de website de schuld krijgt.

Hoezo vreemd? De website voldoet niet aan de standaard.

[Verwijderd]

Gmail voldoet ook niet aan de standaard, maar daar hoor je ze niet over.

[Olaf van der Spek]

Gmail voldoet ook niet aan de standaard, maar daar hoor je ze niet over.

Submit een bug report zou ik zeggen.

[Roland684]

En wat noem jij dan een 'werkende site'? Iets dat in specifieke gevallen doet wat het moet doen, of iets dat in alle gevallen doet wat het moet doen? Google doet gewoon iets wat 100% valide is en al vele keren eerder is gedaan (zoek maar eens naar 'web accelerators', of specifiek naar netsonic). Dat luie scriptkiddies daar niet aan gedacht hebben, is echt hun eigen probleem.

Get-request mogen ge(pre-)cached worden. Dat een webmaster daardoor meent dat dat roet in het eten gooit bij een manier waarmee hij dacht bezoekers te kunnen tellen, is zijn probleem. Er is zowiezo geen betrouwbare manier om bezoekers te tellen, proxyservers en routers gooien al tientallen jaren roet in het eten en elke provider heeft een proxy-server. Maar die webmaster wist gewoon niet beter...

[DJ Henk]

De risicogroep zijn de websites over een onbeveiligde verbinding waar bovendien geen duidelijke dynamiek in te herkennen is, bijvoorbeeld met http://www.site.com/dit/soort/urls]www.site.com/dit/soort/urls in plaats van http://www.site.com/dit.php?soort=urlswww.site.com/dit.php?soort=urls

En de grap is, vaak worden dat soort url's expres gebruikt: om vriendelijker te zijn voor zoekmachines als Google.

[Verwijderd]

Maar: is deze accellerator de enige waarmee dat soort sites misgaan? Er bestaan toch al langer programma's die dit soort dingen doen, links in de pagina al vast ophalen en zo? Alleen heeft deze het extratje om via de servers van Google te cachen en daardoor mogelijk nog wat meer snelheidswinst te halen.
* 786562 fremar

[Helsie]

Klopt het dat je geen risico loopt op verspreide gegevens wanneer je dit gewoon niet gebruikt?

Zo ja, dan houd ik dat nog maar even zo...

[a.prinsen]

yup mensen doen het zichzelf aan.. probleem is jij weet het, ik weet het maar de gemiddelde consument ?

Google is leuk zeg de webdesigners opzadelen van zo moet je maar je werken want WIJ hebben een nieuw tooltje bedacht.
Als je webpagina zo werkt (of het zo 'hoort' of niet) en het goed/veilig doet heb je toch geen zin om alles aan te passen omdat MR. Google met een foute accellerator komt.

De accellerator is eigenlijk niets anders dan een server side "load all available links" achter de schermen.. met alle gevolgen van dien.

Dergelijke client side tools zijn er volgens mij ook al maar zijn niet echt een success vanwegen de extra bandwithgebruik (je download immers veel meer, ook sommige niet geclickte links)

[stunn0r]

de accelerator is hier niet fout het zijn wel degelijk de sites die niet aan de standaard voldoen

[Verwijderd]

@gymno
FF is een heel ander geval. het niet correct weergeven van een pagina is duidelijk van een andere urgentie dan de security risks.

is die x-moz header een die door google naar de server wordt gestuurd, of voegt google die toe aan de headers die naar de gebruiker gaan? Als het om het eerste gaat, wordt het weren van de tool wel makkelijk:
<?
if ($_VAR['x-moz']=='prefetch') {
echo('uninstall moron tool, then come back');
exit
}

[marty]

Tip voor webbouwers:

Voorzie hyperlinks die acties uitvoeren met een random parameter. Op deze manier zal iedere URL uniek overkomen op proxies e.d.

Dat zal geen zin hebben. als ik een linkje maak:
<a href="index.php?id=1&action=delete">delete</a> om iets te verwijderen en ik voeg daar een random paramater aan toe
<a href="index.php?id=1&action=delete&rnd=123456789">delete</a>
Dan wordt dat item nog steeds verwijderd als google met die 'gewelde' precache-functionaliteit dat linkje op gaat halen.

Verder ben ik het met iedereen eens die vindt dat Google arrogant is en te ver gaat.

[Verwijderd]

Standaards zijn er niet voor niets. Google verplicht die mensen niets, maar als ze niet aan de standaard voldoen, is dat hun eigen fout en niet die van Google

Je hebt helemaal gelijk. Ik heb hier zelf ook nu last van, maar het is toch echt mijn eigen schuld. Het is hetzelfde alsdat je de win32 api (om maar wat te noemen) verkeerd gebruikt, en dan gaat lopen zeuren als je programma niet onder de nieuwste versie van Windows draait.

Op het web hebben de prutsers (ik zelf dus ook als het om html gaat!) door hun gepruts al meerdere problemen veroorzaakt. Door maar wat raak te html'en en door de "als het toevallig werkt dan werkt het" houding hebben alternatieve browsers het nu zo moeilijk met sommige bagger sites.

Dit is niks meer dan het zo veelste probleem dat gepruts opleverd.

[xzenor]

Nee, google zegt gewoon dat hun autoradio alleen in rechhoekige sleuven past die in iedere auto zitten..
Dat er nog steeds debielen zijn die ronde autoradio's maken die ze dan maar gewoon in die rechthoekige gleuf rossen is niet de schuld van google..

Ik vind overigens wel dat google dit niet kan maken, maar ik zie opmerkingen voorbij komen die zeggen: 'fuk de standaarden' en dat is gewoon hersenloos geblaat..
Die standaarden zijn er niet voor niets.
Daar moet men zich gewoon aan houden..

Kijk naar DVD+R en DVD-R..
Tot de lezers en schrijvers er waren die beide aankonden was dit echt een gekloot omdat er geen standaard voor was.

[DJ Henk]

Dat kan vanuit puur technisch oogpunt wel het geval zijn, maar dat is in de praktijk een volslagen non-argument.

Vergeleken met het constante gezeur over webstandaarden, wat explorer er van bakt en de, technisch incorrecte bochten waar de webdevelopers zich in wringen is dit echt een heel kleine druppel in de oceaan van fouten die wordt gemaakt.

Van het laten zien van webpagina's wil iedereen dat browsers overal tegen kunnen en dat alles er goed uitziet.

Nu gaat het om iets veel belangrijkers, namelijk het verwijderen van gegevens en het verspreiden van privacy-gevoelige gegevens, en dan zegt google doodleuk: 'We weten wel dat een groot deel van de websites niet goed in elkaar zit, maar dat interesseert ons dus geen reet. Jammer voor je, gebruiker!'

Die gasten worden met de dag arroganter.

[Targeter]

Dat is het punt wél. Standaards zijn er niet voor niets. Google verplicht die mensen niets, maar als ze niet aan de standaard voldoen, is dat hun eigen fout en niet die van Google, zij houden zich netjes aan de standaard. Ze gebruiken de standaard alleen op een wat nieuwere manier.

[aaiding]

Jammer voor je, gebruiker!'

Eerder: "Jammer voor je, webmaster!". Als je niet goed oplet kan in één keer 'n complete database tabel leeggegooid worden door dit tooltje. Heb je maar 1 user voor nodig die dat ding toevallig geïnstalleerd heeft.

[Verwijderd]

En hoe zit dat dan met al FF, zijn die ook arrogant, omdat ze bepaalde pagina's (die niet volgens de standaard hebben geimplementeerd) niet correct weergeven ??

Nee, het is terecht dat ze de verantwoording bij de page designer leggen. Ze zullen nu snel genoeg hun pagina's aanpassen, wanneer dat data ongewenst verwijderd wordt, omdat het design verkeerd is.

[MacWolf]

Er is wel een verschil. Een GET of POST actie wordt gebruikt om gegevens te zenden naar een site. Bij een GET worden de gegevens verzonden via een URL en bij een POST gebeurt dit 'onderhuids'. Een GET actie zou je nooit moeten gebruiken om wijzigingen in een database uit te voeren, dat is gewoon slecht/gevaarlijk site ontwerp. Een GET actie kan wel gebruikt worden om gegevens uit een database op te halen.

[a.prinsen]

eigenlijk is dit niets anders dan een proactieve proxy
(proxy cached links die je nog niet heb geklikt in)

zoals bekend kleven er voor en nadelen aan proxies.. zeker met dynamische pagina's

[Verwijderd]

Mensen, mensen, vervang het woordje "Google" in het bericht eens door "Microsoft" en heroverweeg dan uw antwoord.

Ik wordt het een beetje zat dat alles dat Google doet maar geweldig moet zijn, terwijl als Microsoft datzelfde zou doen de wereld te klein zou zijn.

Dit is gewoonweg idioot. Je kan niet roepen: als je je niet aan de standaard houdt dan heb je pech. Zeker niet als het afwijken van die standaard op zichzelf een standaard is. (de jure vs de facto). Het Web is nog steeds niet bedoeld voor computers, maar voor mensen. En als jij dan toch wilt dat een computer dat Web gebruikt, zul je er rekening mee moeten houden dat er beslissingen genomen kunnen worden die nadelig zijn voor _jou_, maar voor de 99,99999% die het Web als mens gebruiken geen enkel probleem vormen. De realiteit is nu eenmaal dat Web developers vaker gedreven worden door deadlines dan door standaarden en het voldoen daaraan.

[Bosmonster]

Dat is het punt niet. Het feit is dat zij een programma uitbrengen dat vereist dat sites op een bepaalde manier werken. Wat nogal een arrogante houding is natuurlijk en ervoor zorgt dat miljoenen sites/webdevelopers in hun applicaties met dit onzinnige tooltje rekening moeten gaan houden.

[Verwijderd]

Nee, het is juist arrogant om van de standaard af te wijken en dan te zeuren dat het niet goed werkt.

[Maverick]

Wat google nu doet is zeggen onze autoradio werkt alleen op auto's met een accu, als auto's geen accu hebben dan moeten ze er 1 in bouwen.
Dat er mensen zijn die auto's maken zonder accu daar kan google toch niets aan doen.

[Glashelder]

Met deze software zou het mogelijk worden sneller te surfen, doordat de internetverbinding omgeleid wordt via de servers van Google.

Je doet moeilijk

Overigens is er over die standaard niet goed nagedacht. Dan zou je voor elke action een form nodig hebben -> onzinnig.

[Verwijderd]

"Zo wordt bijvoorbeeld uitgelegd dat de HTTP 1.1-specificaties duidelijk stellen dat een link met de GET-method niet gebruikt hoort te worden voor het uitvoeren van acties, maar enkel voor het ophalen van gegevens"

Simpel:

Nogal tegenstrijdig, aangezien het ophalen van gegevens ook per definitie ook een actie is. Verder zou de gestelde definitie betekenen dat webapplicaties per definiete niet voldoen aan de standaard tenzij ze voor ALLES forms voor gebruiken. Dus geen hyperlinks meer die een actie starten, maar code die een form submit. Laat het nu ook standaard zijn dat je maar 1 enkele form per webpagina mag hebben, en een beetje rondneuzen naar toepassingen van beide op het web leert dat ook standaarden behoorlijk achterlijk kunnen zijn!

Tip voor webbouwers:

Voorzie hyperlinks die acties uitvoeren met een random parameter. Op deze manier zal iedere URL uniek overkomen op proxies e.d.

Toch vindt ik het slap verweer van Google op dit punt! Je hebt namelijk standaarden, recomendations, sprookjes en de realiteit.....

@themarty:

Je hebt helemaal gelijk, er is nog ietsje meer nodig aan de server kand. Deze moet namelijk herkennen of een user het request doet, of google. Hoe je het dan ook doet, er is altijd een ongewenst effect....er worden onbedoeld acties uitgevoerd, of er worden helemaal geen acties uitegvoerd.

@MacWolf:

Het verschil is mij wel duidelijk, probleem is alleen dat je dan voor alle acties met een form moet werken, aangezien enkel deze een post kunnen genereren. Als je dan niet gebruik wilt maken van buttons, maar van hyperlinks of andere elementen die klikbaar zijn, dan heb je meteen ook javascript nodig en een form.

Goede kans dat (zoals ik aangaf), je dan al niet meer aan de HTML standaard voeldoet.

Dit is typisch een probleem van te agressief een standaard volgen. Als webbouwer moet je dat niet doen, en als Google zijnde ook niet. Het aantal problemen en/of de complexiteit bij het bouwen van een site wordt groter, dus de kosten hiervoor ook. Iedere partij die hier bewust fors aan bijdraagd is in mijn ogen niet goed bezig.

[exyll]

Onzin... het is volledig valide om meerdere forms op een pagina te hebben. Dat toevallig ASP.NET het niet op die manier doet en volledige scripting workarounds verzint inclusief hidden controls voor hints en viewstate is de (verkeerde...) design keuze toen geweest.

[MrE]

Niet helemaal waar.
Jouw vergelijking is:
Als ik een auto koop zonder accu, kan je geen autoradio van Google kopen, want de standaard is nu eenmaal dat auto's wel een accu hebben.
Het is dus mijn eigen keuze, om af te zien van een Google radio.
Ik heb er, in jouw voorbeeld, dus geen last van, want ik kan kiezen voor een transistorradio, iedereen dus blij.

In het bericht is het echter zo dat Google een radio (accelerator) maakt die, als iemand er mee in de buurt komt van een auto zonder accu (niet standaard website), die auto uit kan schakelen (content kan vernielen).
Ik ben dus de lul als iemand zo'n radio heeft, en hij langs mij rijdt.

Dat Google iets heeft van 'je kan de vooruitgang niet stoppen, dus stap over op de Web standaard', kan ik heel goed begrijpen.
Dat Google lak heeft aan de gevolgen die dat kan hebben voor gebruikers (zoals ik) die af en toe iets in html online zetten, en helemaal niet weten wat die standaard inhoud, vind ik een slechtere zaak.

Mooier zou het geweest zijn als Google iets in deze accelerator had gebouwd in de trant van 'als een pagina zo en zo werkt', dan tonen wij een scherm dat deze pagina niet volgens de webstandaard werkt, en dat die niet wordt geladen (of dat die via de 'oude' manier wordt geladen).
Van mij part hadden ze deze pagina's een negatieve modifier meegegeven, zodat ze lager in een zoekopdracht komen te staan.

Maar het is bot om te zeggen, 'jij bent niet zoals ik wil, jij komt er niet in'.

[Verwijderd]

Dus incompetentie aankaarten staat voor jou gelijk met arrogantie?

[Forage]

Hoewel ik het behoorlijk brutaal en gedurft vind van Google om een dergelijke houding in te nemen, eentje die niet bepaald zonder risico is, hebben ze geen ongelijk. Ik wist niet dat het volgens de specificaties niet toegestaan was de GET methode toe te passen voor het uitvoeren van acties. Deze actie van Google zorgt er dan hopelijk voor dat webbouwers hun boel verbeteren.

Laat het nu ook standaard zijn dat je maar 1 enkele form per webpagina mag hebben

Hoezo maar 1 from per pagina? Je mag er zoveel in propper als je zelf wilt, je mag ze alleen niet nesten.

Nog een tip voor webbouwers:
Voor de mensen die iconen gebruiken voor acties en deze normaal gesproken in een link tag plaatsen, het is een kleine moeite dit even netjes via een form te doen en dezelfde style te behouden:

<input type="submit" value="" id="delete" class="button" />

.button {
background: transparent url("icoontje.gif") no-repeat;
border: none;
cursor: pointer;
}

[MrE]

Incompetentie kaart je aan door een breed vlak te creëren, en dan actie te ondernemen (bijvoorbeeld door met providers af te spreken, alleen pagina's toe te laten die volgens webstandaard zijn gebouwd of iets dergelijks)

Ik ga ook niet jouw auto te lijf met een honkbalknuppel omdat je een rood licht negeerde, en ik jouw incompetentie wil aankaarten.

[Verwijderd]

Inderdaad dan "jammer voor de webmaster!". Als je zo'n zware handeling niet aan een doublecheck onderwerpt. Toch?

[Verwijderd]

Eerder: "Jammer voor je, webmaster!". Als je niet goed oplet kan in...

Inderdaad dan "jammer voor de webmaster!". Als je zo'n zware handeling niet aan een doublecheck onderwerpt. Toch?

[Rekcor]

Bovendien houdt de plugin de muiscursor in de gaten zodat het programma een pagina al kan beginnen downloaden van zodra de cursor in de buurt van een link komt

Toch is dit een handige functie, alleen zou ik hem gewoon als feature van de browser zelf willen zien.

* 786562 Rekcor

[TeRanEX_]

Zoiets als de Fasterfox extensie bedoel je?

https://addons.mozilla.org/extensions/moreinfo.php?id=1269

[Rekcor]

Eeeh... ik weet niet of je de 'User comments' van deze plugin hebt gelezen:

'Kills FireFox', 'Total Crap', 'Wiped out the internet connection'

Dan kies ik nog liever voor minder privacy bij Google

[TeRanEX_]

die heb'k gelezen nadat'k de link hier had gezet

[Mac_Cain13]

Wat een geweldige uitvinding van Google!
Persoonlijk snap ik niet helemaal waar al deze negatieve reacties vandaan komen.

Dat Google je surf-gedrag kan tracen is duidelijk en wordt ook netjes genoemd tijdens de install. Dus dat is iets waar de gebruiker netjes op gewezen wordt en waar je dan dus ook zelf over kunt beslissen.

Het prefetch-en scheelt je webserver uiteindelijk alleen maar dataverkeer, omdat Google die pagina na die ene request weer 100x doorstuurt. Waardoor het voor de gebruiker én voor de webmaster een voordeeltje opleverd.

En ja, natuurlijk gaat dat ten koste van je nauwkeurige stats, maar vergeet niet dat veel bedrijven/scholen ook al cachende proxy servers hebben. Dus stats uit die hoek klopten toch al niet helemaal. Het enige wat Google doet is hun gigantische capaciteit delen met de rest van de wereld. Zodat wij ook van hun caches en netwerk kunnen profiteren.
Overigens laat Google netjes weten hoe je die prefetch requests kunt onderscheiden en dus netjes kunt filteren uit je stats en evt zelf kunt blokkeren. Dus er is totaal geen rede tot paniek.

Tot slot doet Google er zo te lezen alles aan om ongewenst cachen, uitloggen en andere geintjes te voorkomen, maar roept (net als veel Firefox tweakers hier) op tot het netjes schijven van je site. Zodat er een eenduidige standaard gebruikt wordt, waardoor we nog meer uit het web kunnen halen en compatible met elkaar zijn.

Kortom is dit weer een geweldige en shockerende uitvinding uit het Google lab.
Thumbs up Google!

[Verwijderd]

Weet niet waar al die heisa voor nodig is?!! Er staat duidelijk in de voorwaarden wat er allemaal gedaan wordt. En HTTPS verkeer wordt niet gecached. Ik heb het zelf ook geinstalleerd gehad, maar ik merkte niet veel verschil en heb het er weer afgehaald.