Chrome-browser voor Android verwijdert stukken van lange url's bij delen

Versie 64 van de mobiele Chrome-browser voor Android introduceert een nieuwe deelfunctie waarbij lange url's met veel aanvullende informatie, bijvoorbeeld in de vorm van referrers en trackers, ingekort worden.

Volgens Android Police was deze functie nog niet aanwezig in versie 63 van de browser. Het inkorten van url's werkt alleen als gebruikers een link delen met behulp van de interne deelfunctie van Chrome, die via het menu te benaderen is. Het is nog steeds mogelijk om niet van de functionaliteit gebruik te maken door de url direct in de adresbalk te selecteren en te kopiëren.

Er zijn echter ook nadelen aan het inkorten van de url, meldt de site. Zo gaan bijvoorbeeld tekstankers verloren. Google introduceerde ook andere wijzigingen in versie 64 van zijn Chrome-browser. Zo blokkeert deze sinds vorige week bepaalde advertenties die niet aan de zogenaamde Better Ads-regels voldoen.

Afbeelding via Android Police

Reacties (67)

Als ik het goed begrijp, wordt de zgn. canonical link gebruikt, als die gedefinieerd is in de HTML van de pagina. Prima idee.

Helemaal geen prima idee.

Stel ik zit op de Pricewatch want mijn moeder wilt een nieuwe tv kopen, dus ik stel allerlei filters in zodat deze enkel tv's toont die voldoen aan de wensen van mijn moeder. Deel ik dan op deze manier de link naar mijn moeder dan komt ze uit op:

"https://tweakers.net/categorie/621/televisies/producten/"

in plaats van:

"https://tweakers.net/categorie/621/televisies/producten/#filter:q1ZKKkrMS_FMKVayijY0NjeP1VEqSExPDc6sSlWyMjQwAHKLMpNTfTPzlKwsjEx1lIoLUpPdMnNKUouAWqqVTCwNLEB0WWKOkpVSaE5JUaKCh4tSbW0tAA"

Ze komt dus uit op de hoofdpagina voor televisies, en ziet dus niet het lijstje tv's dat ik met haar wilde delen. Leuk dat je tracking zaken er uit wilt halen, maar de canonical url gebruiken is er geen oplossing voor.

Er is ook geen oplossing voor webbouwers zoals MaffeMaarten aangaf, want je canonical url is nu eenmaal heel wat anders dan je daadwerkelijke url en dus ook niet bedoeld als "schone" versie van de url. Je kunt niet met bijv. JavaScript de queries gaan toevoegen aan je canonical url want die moet nu juist altijd hetzelfde zijn, daarom is die "canonical".

[Reactie gewijzigd door lepel op 20 februari 2018 15:52]

Goed voorbeeld van wanneer dit niet goed werkt. Ik heb te weinig verstand van zaken om te weten of tweakers dit zou kunnen fixen. Mijn gevoel zegt van wel, er is vast iets mogelijk om die canonical url ook dynamisch aan te passen. (Anders zouden de REST-style url's van sommige sites ook niet werken, er zou ook een site gebouwd kunnen worden die eruit ziet als t.net/pricewatch/TV/500-1600euro/42-52inch/ zover ik weet)

De vraag is dan wel weer meteen: hoe lang gaat het duren voordat websites ook gewoon weer de tracking-info in de "canonical"-url van de site gaan zetten?

Lijkt een paradox, meestal betekend dat dat ik het niet goed begrijp.

Iemand?

--edit:
Na wat leeswerk snap ik het beter, canonical-url gaat vooral om ranking in google.

Voorbeeltje: Tweakers wil graag dat links op het internet naar pricewatch/TV/filter=125642hk23jh4 meetellen voor de ranking naar pricewatch/TV. Dus zorgen ze ervoor dat de canonical url daarheen wijst. Als ze dat niet doen zijn het gewoon heel veel verschillende pagina's voor google, die allemaal een hele lage ranking hebben. (En ook nog eens duplicate content zijn waarschijnlijk, waardoor hij maar meetelt als 1 pagina met een hele lage ranking).

Dat is waar de canonical-url vooral voor bedoelt is. En daarom is het voor specifieke pagina's vaak niet de handige url om te delen. (Weer wel om te "liken" of facebook bijvoorbeeld, en daarvoor wordt dan ook de cononical url al gebruikt.)

Om bijvoorbeeld de m. uit m.wikipedia.com wel te halen werkt het dan weer wel heel goed, of in dit specifieke amazon voorbeeld. Wachten tot iemand een extra tag voorstelt voor in html? Dat weerhoudt sites er niet van om (zelfs extra) tracking info toe te voegen als ze dat graag willen, maar maakt het wel mogelijk voor goedwillende sites om de url op te schonen als je 'm wil delen.

[Reactie gewijzigd door MaffeMaarten op 20 februari 2018 16:18]

De vraag is dan wel weer meteen: hoe lang gaat het duren voordat websites ook gewoon weer de tracking-info in de "canonical"-url van de site gaan zetten?

Dat kan meestal juist niet, want de referrer tag wordt meegegeven vanuit een verwijzende site. Je canonical url is altijd hetzelfde, de "basis" van je pagina zeg maar. Verschillende verwijzers hebben verschillende referrer tags.

Je kunt dan wel programmatisch de referrer queries gaan toevoegen aan je canonical url maar ik gok dat Google (de zoekmachine) dit niet erg leuk vind en je daarom een lagere ranking geeft.

[Reactie gewijzigd door lepel op 20 februari 2018 15:49]

je kan haar natuurlijk ook gelijk de link geven naar Plattetv, want die zijn de enige die de UltraHD Salora op voorraad hebben

Maar serieus, ik lever ook altijd de tweakers link inclusief de filters.

Die link was puur even als voorbeeld Ik heb wat random filters aangeklikt waardoor er toevallig alleen die ene tv naar voren kwam.

Dat zou heel prima zijn. Maar jammer dat ik dit niet teruglees in het artikel.

Zeker. Hier vond ik nog iets meer informatie daarover: https://news.ycombinator.com/item?id=16415935

Dit zou ook betekenen dat bij pagina's waarop het niet goed werkt dat eigenlijk hun eigen schuld is. En belangrijker, dat ze het zelf kunnen fixen.

Dat hoeft helemaal niet waar te zijn. Een canonical URL is doorgaans statisch, logisch ook, want dit wordt gecrawled. Echter, de daadwerkelijke pagina kan interactief zien en state bewaren via de URL. Die state wil je niet in je canonical, want dan wordt je pagina dubbel geindexeerd.

Dan moet je ervoor zorgen dat je website niet zo afhankelijk is van states dat een canonical url de site kan breken. Dit kan misschien moeilijk zijn in sommige gevallen, maar dan ligt het gewoon aan de manier waarop jij je website op hebt gebouwd en heb je er zelf mee te dealen.

Nee daar klopt niks van. Queries zijn gewoon normale onderdelen van een url, de meeste sites breken als je die er af haalt. En dat is wat Google nu doet.

De canonical link is nooit bedoeld geweest als "schone" versie van je huidige link. Dat is hetzelfde als alle cookies weren en dan zeggen dat ze de website verkeerd gebouwd hebben want je kunt niet meer inloggen. Je hebt het gewoon nodig.

De canonical link is een soort basislink, de meest basis versie van een pagina. Echter met de huidige staat van webtechnologie zijn pagina's vaak al bijna applicaties op zich, en heb je die queries gewoon nodig wanneer je een sortering wilt veranderen, je een filter wilt toepassen, etc. Haal je deze er af door de canonical link te gebruiken dan ben je weer terug bij af, om het zo te zeggen.

Ga je naar de Pricewatch om voor je moeder een tv uit te zoeken, want ze wilt een 50" tv, met LED paneel en met WebOS. Voer je netjes al je filters in, heb je een mooi lijstje van mogelijke tv's. Deel je het dan via deze functie dan wordt je moeder gewoon naar de homepage van tv's op de pricewatch gestuurd. Dit is niet omdat Tweakers de website verkeerd in elkaar heeft zitten, dit is omdat Android belangrijke informatie verwijderd uit de url.

[Reactie gewijzigd door lepel op 20 februari 2018 15:58]

Queries zijn gewoon normale onderdelen van een url, de meeste sites breken als je die er af haalt.

Dan hebben die sites dus geen goede canonical url. Alle query parameters die de inhoud van de pagina wijzigen moeten opgenomen worden in de canonical, want effectief is het dan een hele nieuwe pagina. Alleen representatieve parameters zoals utm_source en sortering horen niet in de canonical thuis want de inhoud van de pagina blijft gelijk.

Dat is wat kort door de bocht. Inderdaad in sommige gevallen is dat zo. Maar bv. een sortering of filter opnemen in de canonical link zou - ironisch genoeg - voor duplicate content penalties bij Google zorgen.

Bovendien krijg je dan alsnog een lange (canonical) url, wat dus bewijst dat de parameters niet zomaar weg konden...

Let wel: tracking rotzooi en referral parameters mogen wat mij betreft meteen weg, maar daar zijn veel marketeers weer niet blij mee. Vraag me af hoe Google hier omgaat met haar eigen belangen (in dit soort meuk t.b.v. analytics en adwords).

Wat een onzin. Vrijwel iedere moderne web applicatie gebruikt client-side state welke afwijkt van de canonical url. Daar is niets mis mee, en vaak de enige manier om dingen client side goed uit te voeren.

Huh, nog nooit van gehoord. Goed om te weten.

Dit zou bijvoorbeeld ook met SEO gerelateerde URLs kunnen zoals de link van dit artikel:
https://tweakers.net/nieuws/135439/chrome-browser-voor-android-verwijdert-stukken-van-lange-urls-bij-delen.html

Kan dan gewoon als:
https://tweakers.net/nieuws/135439/

Een slechte dag voor url filtering, en een kans voor deep packet inspection

Die ga je toch echt moeten uitleggen. Wat heeft dit in hemelsnaam met DPI te maken? Het inkorten van de URL vereist helemaal geen DPI maar is gewoon een analyse doen van die URL, bepalen welke tags gebruikt kunnen worden voor tracking en die eruit halen. De relevantie met DPI is 0,0. Een browser en DPI gaan trouwens ook niet echt samen aangezien een browser toch echt alle data die over het netwerk binnenkomt en bedoeld is voor de browser moet bekijken, hoe kan een browser anders de pagina weergeven?

Deze volg ik niet. Jij gebruikt web filtering op basis van tracking get-parameters? En deze staan je opeens ook nog toe om DPI uit te voeren?

Dit raakt echt kant noch wal.

Ik denk dat hij doelt op een #SmartBlockChain

Hij heeft wel en punt. Ze slaan namelijk de DNS vermeldingen op in een blockchain en distribueren deze (tevens wel transparant). De IP eigenaren hebben zo wel controle.
Wel een must dat Chrome dan governance bereikt via slimme contracten in een andere blockchain. Dat de softwareleveringsketen als het ware beveiligd is en hiervoor slimme contracten implementeerd.

Ik vind het wel goed om te gebruiken op het forum, Amazon plakt er vaak refferals achter, maar die zijn niet toegestaan op het (algemene) forum, dus als Chrome ze nu vanzelf verwijderd hebben we daar geen mods meer voor nodig

Moet je de link eerst met jezelf delen want copy/paste werkt nog niet

En ik hoop dat ze het met copy/paste nooit per default zullen aanzetten. Een copy hoort dat te zijn: een identieke kopie van wat je geselecteerd hebt.

Mee eens, maar ik vrees er wel voor.
Ze hadden er ook weinig moeite mee om het onmogelijk te maken de domeinnaam te kopieeren op websites met een HTTP verbinding.

Mee eens, maar ik vrees er wel voor.
Ze hadden er ook weinig moeite mee om het onmogelijk te maken de domeinnaam te kopieeren op websites met een HTTP verbinding.

Exactly this is what grinds my gears the wrong way

En ik hoop dat ze het met copy/paste nooit per default zullen aanzetten. Een copy hoort dat te zijn: een identieke kopie van wat je geselecteerd hebt.

Als ik in mijn desktop browser rechtsklik kan ik (onder andere) kiezen voor "paste", maar ook voor "paste & go". Dat laatste is vaak handig, maar het zou ontzettend irritant zijn als het de default was. Gelukkig is het dat niet en daarmee wordt het juist een fijne toevoeging.

Zo ook in dit geval; de default kan intact blijven, maar via de popup (op dit moment geeft Chrome me al "cut", "copy", "paste" en "share") kan "copy filtered" ook aangeboden worden.

[Reactie gewijzigd door robvanwijk op 20 februari 2018 19:23]

Je kan toch zodra je op delen hebt gedrukt in dat menu waar je kiest met welke app je het wilt delen kiezen voor kopiëren naar klembord

Je kunt delen naar het klembord, zoveel extra werk is dat niet.

Een "mooi" stukje automatisering?
Zelfs Chrome neemt al dingen over van mods

Ach ja, dan kunnen de mods ook lekker achteruit hangen in hun stoel.

Dit zou opt in moeten zijn.
Dit breekt het link-delen principe, als je juist een filter hebt gezet op een productlijst, een vergelijkingstabel enzovoort.
Ofwel moeten alle webdevelopers nu gaan hun site zo gaan aanpassen, dat je steeds een zoekopdracht of vergelijktabel kan opslaan, dat je een permalink krijgt, die je probleemloos kan delen.
Of chrome moet heel precies bepaalde tags strippen, maar daar kan je dan weer makkelijk* omheen werken. *Niet moeilijk, maar met veel bugfixes waarschijnlijk

Het is nog steeds mogelijk niet van de functionaliteit gebruik te maken door de url direct in de adresbalk te selecteren en te kopiëren.

Lijkt mij een mooie compromis. Handmatig kopiëren plakken als je echt de exacte link wil delen.
De "link delen" functionaliteit kiezen als je gewoon een pagina wil linken zonder een link die 3 pagina's in beslag neemt

Ze zouden 'de gewone gebruiker' hier ook over moeten informeren. Zie de volgende situatie al gebeuren: 'Pietje kan jij even kijken of dit de goede ticket is?' 'De link werkt niet, rot website!'.

Verder vind ik dit trouwens een prima functie, zie er voor weinig partijen grote nadelen aan behalve bovengenoemd voorbeeld.

Daar hoef je niet zo’n debiele link voor te hebben. ticketsite.tld/concerts/artist/01-01-1990 zou bvb genoeg moeten zijn.

De deelfunctie zou een checkboz moeten hebben of je wel of niet de verkorte link wilt gebruiken. Dan zou het perfect zijn.

gewoon een extra menu optie - deel verkorte link, deel lange link..

Nee, zoals @ralphm hierboven aangeeft: indien de website goed is opgezet, staat de link inclusief filters, maar zonder trackers opgegeven in de HTML.

Ik vraag me af hoe ze dit willen uitvoeren zonder alle campagnes van Analytics gebruikers om zeep te helpen.

Die tracken toch veelal met script, cookie en/of op basis van IP ipv URL?

Voor sommige doeleinden wordt dat nog wel gedaan. Linken vanuit reviews bijvoorbeeld

Ik ben vooral benieuwd of die URL ook nog op andere browsers dan Chrome werkt.
Het lijkt me vooral een afkort dienst van Google Chrome. Ziets als tinyurl ook doet.

Nee, bekijk de screenshot onder het artikel. De url verwijst nog rechtstreeks naar amazon.com maar een hoop url parameters zijn verwijderd. Ik denk wel dat veel links op die manier gaan breken. En voor affiliate marketing is het helemaal een ramp als je affiliate id wordt verwijderd. Maar ik denk niet dat veel mensen die functie gebruiken.

Maar dan zou het een functie zijn die Amazon zou moeten ondersteunen.
In de originele URL zie ik namelijk niet dezelfde parameters als in de nieuwe URL.

Sterker nog, het path zelf is ook anders: /b ipv /s/browse/ref=br_msw_pdt-1. Ik vraag me af hoe Chrome dit weet.

In de HTML source van een Amazon pagina:

<link rel="canonical" href="https://www.amazon.com/ZOTAC-ZBOX-CI327NANO-U-Celeron-1-1GHz-Barebone/dp/B0728F8JS5" />

Ja, klopt. Het lijkt me in het geval van Amazon.com maatwerk. Dat Chrome van een "s" een "b" kan maken, zal afgesproken moeten zijn. Maar als de url op Chrome werkt, zal deze op alle browsers werken. Amazon vangt dit op.

Het strippen van de URL zorgt er op sommige websites voor dat je op een andere pagina terecht komt dan waar de originele URL naar verwijst. Op sommige websites werkt het wel goed met query parameters.

Dan moet zo'n website de jusite canonical maar toepassen

Er zijn genoeg redenen om naar een andere pagina te verwijzen in de canonical, de query parameters worden juist vaak gebruikt voor het linken naar pagination ed en die worden er zo afgestript want die wil je niet meenemen in je canonical.

Die tekstankers zijn jammer, maar voor de rest is dat wel erg relaxt als het optioneel is. Best vaak dat ik er stukken af wil halen en dan een beetje zit te priegelen.

Dat is wel jammer ja. Het zou mooi zijn geweest als dat intact werd gehouden.

Dit gaat naar verwachting problemen geven.

Canonical is een belangrijke link en in veel gevallen gericht op het voorkomen van duplicated content.

Maar als je gaat sorteren, bijvoorbeeld een webshop, met goedkoopste product bovenaan zal in veel gevallen de canonical url niet veranderen. Je wilt immers voorkomen dat er duplicated content ontstaat.

In de praktijk wil dat zeggen dat als jij gaat sorteren en je stuurt die link naar een vriend met 'check het 3e product eens' dat je vriend dus een andere volgorde ziet en het verkeerde product koopt.
Sta je ineens daar met je Audi A7 terwijl je eigenlijk een Seat Ibiza wilde hebben...

Klopt maar dit probleem bestond al doordat steeds meer sites personalisatie toepassen. Dan zie je sowieso een ander resultaat dan degene waarmee je de url deelt. Verder zullen de meeste mensen niet een zoekresultaat delen maar een product pagina en dan gaat dit prima.

Ja, en Google heeft geen idee wat ze doen natuurlijk.....

Je argument is me niet helemaal duidelijk?

Blijkbaar is Google zelfdestructief, of zullen ze UTM tags 'toevallig' wél laten staan?

Dat vraag ik me dus inderdaad ook af.
Echter maakt het niet persee veel uit, de utm tag klopt eigenlijk niet meer op het moment dat je het doorstuurt.

De UTM tag verdwijnt niet voor de huidige bezoeker verwacht ik, enkel de volgende.