Google vervangt ingekorte goo.gl-links door Firebase Dynamic Links

Google is gestopt met de ondersteuning van ingekorte goo.gl-links en heeft ze vervangen door Firebase Dynamic Links. Dat zijn url's waarmee een gebruiker naar elke locatie binnen een Android-, iOS- of web-app kan worden gestuurd. Bestaande goo.gl-links blijven wel werken.

Google introduceerde zijn url-inkortdienst in 2009. Sindsdien zijn er volgens de techreus echter een heleboel alternatieven verschenen en is ook de manier waarop gebruikers informatie opzoeken sterk veranderd, onder meer door de opmars van smartphones, apps en slimme assistenten. Google is daarom per 30 maart gestopt met de ondersteuning van goo.gl-links en vervangt ze door Firebase Dynamic Links. Dit zijn links die ook naar locaties binnen iOS- en Android-apps kunnen verwijzen en die gepersonaliseerde mogelijkheden bieden, ook als gebruikers vanaf een mobiele site naar de app komen.

In de praktijk gaan gebruikers wellicht niet veel merken van de transitie. Bestaande goo.gl-links blijven als vanouds doorsluizen naar de volledige url die erachter schuilgaat. Bovendien was het sinds 13 april 2018, voor mensen die de inkortdienst nooit eerder hadden gebruikt of anoniem gebruikten, al onmogelijk om nieuwe verkorte url’s te creëren via de goo.gl console.

Reacties (82)

[willyb]

Het gebruik van dit soort verkorte links is vaak totaal overbodig. Je ziet ze vaak gebruikt worden op twitter, terwijl twitter (al erg lang) helemaal geen verschil in lengte telt voor URLs: ze zijn altijd 23 karakters.

Als bedrijf wil je het al helemaal niet gebruiken: plak ".info" achter de url en statistieken zijn zichtbaar voor iedereen die het wil.

Ik vat de tips maar even samen waarom je niet altijd een url verkorter van een derde partij wilt gebruiken (en vooral niet in e-mail en op twitter):
1️⃣ Lengte van de URL telt niet mee op twitter: https://help.twitter.com/...itter/how-to-tweet-a-link
2️⃣ Je kunt als ontvanger van de link niet zien wat het uiteindelijke adres is wat je gaat bezoeken. Of je moet je hier al in verdiepen met bv. https://laatjeniethackmaken.nl/#check-kortje-linkjes
3️⃣ Sommige wifi netwerken blokkeren toegang: https://twitter.com/Scott_Helme/status/950472872304226304
4️⃣ Verkorters zijn niet altijd beschikbaar: https://blog.sucuri.net/2...google-safe-browsing.html
5️⃣ Je statistieken gaan publiek: zet een plus (+) [bv. http://goo.gl/l6MS+ ] of '.info' achter de link en iedereen kan het inzien.
6️⃣ Kijk eens in je mailbox naar mails: phishing mails gebruiken vaak een url-shortner, legitieme mail niet ( https://www.ncsc.nl/actue...niet-op-phishingmail.html )

Wil je toch een url verkorten? Gebruik dan gewoon je eigen domein: https://tweakers.net/nieuws/150948/ gaat naar bv. dit artikel is toch lekker kort en leesbaar, maar toont wel waar je naar toegaat.

[Reactie gewijzigd door willyb op 23 juli 2024 01:03]

[Xirt]

Volgens mij gaat het niet alleen om characters: zo heeft de URL protocol://tweakers.net/categorie/49/videokaarten/producten/#filter:TYxBCsIwEEXv8tdFkjSTkh5AcKEbl9JFbQcJ1FpScWHJ3Z1YUTfz5z1m_oJzbMd-18-oT9QUmNoLH8OTUZMSiqHjfRhROyU4d7e4ohWYuNuG4c5RfhcYk-ejHaQI2lpvUECXRNUn_ZpOo0my-Xx-zV2wyjuIM7ayP6vJqY3KvlRG_5WbdwFp8l-JAzNSSi8 een stuk meer impact op de leesbaarheid van een korte tekst dan de verkorte variant https://bit.ly/2I6PnJD .

Edit: deze reactie is geschreven op de korte reactie hiervoor. Ik zie net dat deze flink aangepast is met meer informatie en een betere insteek ;-).

[Reactie gewijzigd door Xirt op 23 juli 2024 01:03]

[OddesE]

De vraag is waarom het veld 'filter' zo'n gigantisch lange waarde nodig heeft?
Ik ken de filter opties van Tweakers en ik stel dat die parameter waarde VEEL korter kan. Ik vermoed dat men alle filter opties als name-value pairs achter elkaar plakt en het resultaat met base 64 encode. Snel gebouwd maar de URL wordt er niet mooier van.

Ik stel dat de URL er ook ongeveer zo had kunnen uitzien:

protocol://tweakers.net/categorie/49/videokaarten/producten/#filter:TYxBCsIwEEXv

Met één Base64 karakter kun je 64 mogelijkheden encoden dus een URL met dezelfde lengte als bovenstaande kan al 64^12 oftewel 4.722.366.482.869.645.213.696 oftewel 4,7 TRILJARD mogelijkheden encoden.

[ACM]

Natuurlijk kan die parameters-encoding korter. Maar er is vziw niet echt een goede reden voor; wat het kosten-baten plaatje dan wel erg moeilijk maakt.

Het is inderdaad effectief een key-value array zoals die binnen php werkt, ontdaan van de "defaults", json-geserialized, gzip-gecomprimeerd (deflate) en dat uiteindelijk base64-encoded (nouja een variant die geen %-encoded entities nodig heeft).

De reden voor die key-value array is dat dat filter onderhuids simpelweg een html-form is, wat dus daardoor eenvoudig te verwerken is in php omdat we effectief in die hash-waarde dezelfde datastructuur kunnen hanteren als we gebruiken bij de (ajaxified) "form submit".

Aangezien de techniek grotendeels stamt uit de tijd dat GET-urls niet al te lang mochten zijn (met dank aan IE <= 9 oid), is er overigens wel wat moeite gedaan om e.e.a. zo kort te houden. Zo is de genoemde compressie toegepast en worden - aanvullend op wat @.oisyn zegt - de id's van keuze-opties gebruikt waar mogelijk.

Verder is het vrij normaal dat er filter-opties bijkomen of wegvallen en zou het wat stom zijn om de filter-encoding korter te maken op zo'n manier dat de urls korter worden, maar de houdbaarheid reduceert van enkele weken tot maanden naar tot hooguit een paar dagen

We zouden natuurlijk ook de gekozen filters aan onze kant kunnen opslaan en ze met een heel kort id kunnen herleiden... Maar dan moeten we weer langdurig nogal wat data opslaan en krijgen we extra druk op de database.

Ik neem voor het gemak aan dat er voor het delen van de specifieke urls relatief weinig (ivt het aantal keren dat ze gegenereerd worden) behoefte is om ze te delen.
En mede daardoor en door het wegvallen van die oude browsers (die maximaal 1 kB - 4 kB als url aankonden) en vele andere veranderingen in de internetwereld, is er ondertussen weinig reden om significante moeite te steken in een kortere encoding.

[Reactie gewijzigd door ACM op 23 juli 2024 01:03]

[.oisyn]

Het is inderdaad effectief een key-value array zoals die binnen php werkt, ontdaan van de "defaults", json-geserialized, gzip-gecomprimeerd (deflate) en dat uiteindelijk base64-encoded (nouja een variant die geen %-encoded entities nodig heeft).

Hier het voorbeeld van @Xirt in CyberChef :P:

{"brandIds":[5],"pageSize":50,"priceMin":600,"scoreMin":4,"specFilters":{"22":{"val":["14492","13557","13559","13561"]},"19":{"min":"4096"},"2474":{"min":"1560.0"},"3021":{"val":["2"]},"5159":{"val":"Nee"}}}

[Reactie gewijzigd door .oisyn op 23 juli 2024 01:03]

[ACM]

Yep. Er wordt zo te zien nog wat ruimte verspild met de aanhalingstekens voor dingen die gewoon integer mogen zijn... Helaas zijn dat soort dingen in php zelf niet altijd even makkelijk om te herkennen (vooral omdat op die posities ook strings voor kunnen komen).

En verder zouden we dezelfde korte labels kunnen gebruiken die we al hanteren voor de form-opbouw zelf...

Ik heb gelijk even gekeken hoeveel het zou schelen met messagepack, als enige aanpassing; maar behalve dat het wat sneller wordt als we deflate eruit halen, scheelt het erg weinig in de grootte. In dat geval zouden we naar 196 bytes zonder of 188 bytes met 'raw deflate' gaan. Terwijl het nu met json+deflate op 192 bytes uitkomt.

Op zich zou een compression met een vooraf te definiëren dictionary wel interessant zijn hiervoor. Maar daar bestaan er vrij weinig van. Zeker als het niet significant trager mag zijn en goed in php beschikbaar moet zijn... en degenen die ik voor Java wel eens geprobeerd heb waren bovendien erg slecht gedocumenteerd (geen informatie hoe je dan een dictionary moet maken bijvoorbeeld)

[.oisyn]

Ik ben het eens met de kern van je post, maar de laatste alinea is een beetje nietszeggend. Zoveel mogelijkheden lijkt veel, maar je zit er al snel aan - je voorbeeld bevat 72 bits, een beetje categorie heeft meer dan 72 vinkjes. En dan kun je ook nog eens gewoon zoektermen opgeven.

Bovendien wil je dat de URL ook blijft werken als er een merk oid verdwijnt of bijkomt, dus je ontkomt er niet aan om ook de namen zelf te encoderen ipv alleen het bitpattern van de keuzes.

[Reactie gewijzigd door .oisyn op 23 juli 2024 01:03]

[Barryke]

Snel gebouwd maar de URL wordt er niet mooier van.

Ik stel dat de URL er ook ongeveer zo had kunnen uitzien:

protocol://tweakers.net/categorie/49/videokaarten/producten/#filter:TYxBCsIwEEXv

Url wordt naar mijn mening er niet mooier van want nog steeds onleesbaar. Het enige voordeel is dat een mens eenvoudig kan zien of iets 2x dezelfde url/filter is. Soms is een simpele oplossing prima.

[Kevinp]

Alleen kan je wel zien dat je naar tweakers gaat. De korte variant kan naar elke malafide site wijzen.

[Viraldope]

Ohja? https://tweakers.net/nieuws/150948/google-vervangt-ingekorte-goo-punt-gl-links-door-firebase-dynamic-links.html

[Reactie gewijzigd door Viraldope op 23 juli 2024 01:03]

[Barryke]

Tuurlijk tekst link gebruiken kan, maar als je wil kan je de URL gewoon zien.

Ook zonder te openen op android: als je lang indrukt om die link in een nieuw tabje te openen, dan staat de url erboven en kan je zien dat deze naar https://www.youtube.com/watch?v=dQw4w9WgXcQ gaat.

Update:
Eigenlijk zou een goede browser moeten waarschuwen voor dergelijk misleidende linkteksten bedenk ik me net.. maar dat zal Google niet willen want dat trucje gebruikt hun search results pagina ook..

[Reactie gewijzigd door Barryke op 23 juli 2024 01:03]

[mjz2cool]

Maar die kun je nog steeds herleiden zonder aan te klikken. In chrome zie je het onderin als je erop wijst, of op android ingedrukt houden, dan komt het bovenaan het menuutje te staan. Die verkortte urls kun je niet herleiden, behalve door ze te openen, of de link te plakken bij een website die het voor je kan uitzoeken.

[The Zep Man]

Dit betreft een legitieme URL die zo lang is met een reden. Echter zie je vaak genoeg URL's die voor copy/paste onnodig inefficiënt zijn. Neem bijvoorbeeld:
http[s]://www.darkreading.com/threat-intelligence/safeguard-cyber-launches-new-tool-to-detect-defend-against-cross-channel-cyber-threats/d/d-id/1334058

Dit kan ingekort worden tot:
http[s]://www.darkreading.com/d/d-id/1334058

En de URL werkt nog steeds. De lange URL is voor 'search optimization', maar sommige sites maken het echt belachelijk lang. Hetzelfde met onnodige GET parameters in de link.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 01:03]

[MrWouterNL]

Onnodig lang ook weer niet, het kan korter maar dan kan je niet meer aan de link zien waar het artikel over gaat. Er is voor beide wat te zeggen

[keranoz]

Die query strings in de URL hebben meestal als doel om jou te tracken, er zit bijvoorbeeld een ID of referer in.

[OddesE]

StackOverflow lost dat slim op. Die zetten de lange parameter die op de titel gebaseerd is achteraan en maken hem optioneel. Dus je kunt dan gewoon het laatste stuk van de URL helemaal weglaten. Maar goed dat moet je ook maar net weten dan.

[mjz2cool]

Dit kan ingekort worden tot:
http[s]://www.darkreading.com/d/d-id/1334058

Dat is natuurlijk wel afhankelijk van de site.

[The Zep Man]

Echter zie je vaak genoeg URL's die voor copy/paste onnodig inefficiënt zijn. Neem bijvoorbeeld:

[TeraMod]

Net zoals

https://tweakers.net/nieuws/150948/google-vervangt-ingekorte-goo-punt-gl-links-door-firebase-dynamic-links.html
en https://tweakers.net/nieuws/150948/

[thanx]

Voor html mail en andere html-bronnen, naast twitter vermoedelijk meestal het geval, is een verkorting van de url al niet nodig. Html heeft van zichzelf al een scheiding tussen url en weergave van de url. Meestal is het gebruik van externe diensten daarom sowieso onnodig. En vrijwel iedere browser laat ook zien waar de url echt naar verwijst, bijvoorbeeld als je er met de muis overheen beweegt.

[burne]

Je gebruikt hier hele specifieke functionaliteit van het Tweakers CMS, dat is natuurlijk geen eerlijke vergelijking. Als jij http://categorie:Videokaarten/ aan je browser voert gebeurt er niets en jouw shortcut resolved naar een URL from hell:

tweakers.net/categorie/49/videokaarten/producten/#filter:TYxBCsIwEEXv8tdFkjSTkh5AcKEbl9JFbQcJ1FpScWHJ3Z1YUTfz5z1m_oJzbMd-18-oT9QUmNoLH8OTUZMSiqHjfRhROyU4d7e4ohWYuNuG4c5RfhcYk-ejHaQI2lpvUECXRNUn_ZpOo0my-Xx-zV2wyjuIM7ayP6vJqY3KvlRG_5WbdwFp8l-JAzNSSi8

[Reactie gewijzigd door burne op 23 juli 2024 01:03]

[Xirt]

Ik heb 'm aangepast (http aangepast naar protocol), omdat T.net 'm automatisch aanpaste naar een korte versie. Slim, maar in dit geval even niet wenselijk ;-).

[burne]

En het zette mij op het verkeerde been over het punt wat je probeerde te maken.. Excuses daarvoor.

[mjz2cool]

Dan vind ik de leesbaarheid van de volledige url beter, net als punt 2 van @willyb: Je weet bij de verkortte url niet waar die naar leid.

[Kiswum]

Het is juist vaak wel noodzakelijk voor marketeers, bloggers, vloggers, reviewers, influencers en andere mensen die zich met refferal links bezighouden. Met zo'n link kan een leek niet direct zien dat er geld verdiend kan worden met aankopen of een klik als iemand de link bezoekt en eventueel iets aanschaft.
dat
Men is er vaak geheimzinnig over en dat is vaak een reden om de link niet transparant te houden. De link verkorten is de perfecte oplossing om iemand naar je gesponsorde link te lokken.

Edit: voor de consument/lezer, heeft zo'n verkorte link geen meerwaarde.

[Reactie gewijzigd door Kiswum op 23 juli 2024 01:03]

[OddesE]

Men is er vaak geheimzinnig over

Altijd een teken dat iets dubieus gedrag is eigenlijk toch?

[gjmi]

Noodzakelijk voor marketeers omdat je anders misschien weet dat er mee verdient word?

Noodzakelijk om iemand om de tuin te leiden dus, om je anders voor te doen dan je bent. Oplichting?

Als marketeer wil je juist transparant zijn als je geloofwaardig over wilt komen, lijkt me.

[DonLexos]

Niet mee eens, ik gebruik ze wel degelijk om in een bericht een korte link naar een deeplink in een website te plaatsen waarbij het bericht leesbaar blijft. Bijkomend voordeel is (omdat je via goo.gl landde) dat er een klikteller opzit. Het is niet alleen affiliate programma's waar dit voor wordt gebruikt.

[torp]

Op fora etc. worden links vaak niet geaccepteerd vanwege de lengte of bijzondere karakters. Dan kan een verkorte link een handig alternatief zijn.

Zo werd de link naar een Wikipedia-artikel niet geaccepteerd omdat er twee letters met een trema in zaten. Gelukkig verwijst Wikipedia de link zonder trema's ook door naar het juiste artikel:
UEFA-coëfficiënten
UEFA-coefficienten

[OddesE]

Ja er is helaas nogal wat validatie code in gebruik die VEEL te streng is.
Trema's in de URL is één ding, maar wat dacht je van emojis? Dat kan tegenwoordig gewoon!

📙.ws

EDIT: Grrr Tweakers accepteert hem ook niet... Maar copy paste dit maar eens naar je adresbalk

[Reactie gewijzigd door OddesE op 23 juli 2024 01:03]

[ACM]

Nee, dat mag niet (van de uri RFC). Het is simpelweg een ongeldige url. UTF-8 karakters en een groot deel van de niet-alfanumerieke asciikarakters moet met 'procent encoding' worden gestuurd (een hexadecimale representatie).

Browsers laten die in de regel echter als het gerepresenteerde karakter zien, in plaats van de procent-encoding.

En daarnaast zijn browsers 't gaan accepteren als je die utf-8 versie zelf invoert, ipv de procent-encoded versie. Op zich is dat natuurlijk wel handig, dat scheelt wat gedoe, maar uiteindelijk vertaalt een browser het onderhuids alsnog naar procent-encoding.
Waar het helaas wel mis gaat, is dat sommige browsers bij het copy&pasten het niet ook naar procent-encoding vertalen, waardoor je effectief een ongeldige url copy&paste.

[Reactie gewijzigd door ACM op 23 juli 2024 01:03]

[OddesE]

Q: What is an Internationalized Domain Name (IDN)?

A: Domain names, such as "macchiati.blogspot.com", were originally designed only to support ASCII characters. In 2003, a specification was released that allows most Unicode characters to be used in domain names. IDNs are supported by all modern browsers and email programs, so people can use links in their native languages, such as http://Bücher.de.

http://unicode.org/faq/idn.html

[ACM]

Als je goed kijkt naar hoe die url's zijn ge-encodeerd, dan is het uiteindelijk alsnog met ascii

quote: https://en.wikipedia.org/wiki/Internationalized_domain_name

Internationalized domain names are stored in the Domain Name System as ASCII strings using Punycode transcription.

Het is dus eigenlijk meer een extentie op clientniveau dan op (low-level) protocolniveau.

Als je die link van jouw voorbeeld copy&paste krijg je met firefox ook dit:
://xn--bcher-kva.de/

En utf-8 karakters in de rest van de url worden alsnog met "urlencoding" gedaan.

Anders gezegd, de "utf-8-ondersteuning" in zowel de domeinnamen als in de rest van de url is op zo'n manier ingebouwd dat de door mij aangehaalde RFC niet hoefde te worden vervangen. Dat heeft vast allerlei voordelen gehad met forward en backward compatibility, maar is daardoor natuurlijk wel wat hacky op het moment dat de getoonde url niet meer overeenkomt met de werkelijke url.

[Reactie gewijzigd door ACM op 23 juli 2024 01:03]

[TrekVogel]

Wat grappig, ik wist helemaal niet dat dat kon. Of het een goed idee is, is dan weer een andere discussie.

[kristofv]

Je kan ook emoticons in je wifi ssid's stoppen bijvoorbeeld, of in je windows active directory domeinnaam enzovoort.

Zo is mijn gsm hotspot gewoon " ", best handig eigenlijk om rogue connecties te voorkomen, veel mensen hebben niet eens door dat dit een echt werkend wifi netwerk is.

[kozue]

Wat beter werkt tegen ongewenste bezoekers op je wifi netwerk is om de security in orde te hebben. Degenen die niet doorhebben dat het ssid is zijn ook niet degenen die je wachtwoord gaan kraken als je bv nog steeds WEP gebruikt

[kristofv]

Mijn beroep is IT architect dus je bent wel ietwat tegen de verkeerde aan het praten wat dat betreft ;-)

Maar op zich heb je natuurlijk gelijk, het voorbeeld was een hyperbool.

[Yzord]

Is het niet zo dat Twitter ze zelf kleiner maakt? Die gebruikt de t.co variant.

[jemson]

Ja dat schoot mij net te binnen, kan mij idd voorstellen dat dit gebeurd.

[dreambofh]

De URL verkorters gebruiken veel tokos voor de statistieken. Tegenwoordig is het verkorten misschien wel een bijzaak.

[DeCo]

QR code ziet er een stuk mooier en eenvoudiger uit bij een korte link, en minder foutgevoelig

[McJeroen]

Inderdaad... niets zo belachelijk als een mega-QR code met duizenden mini-vierkantjes op een camionette of auto...

Met een korte url is het allemaal net wat netter.

[kozue]

Maar wie scant er dan ooit QR codes vanaf een voertuig? Als je er een langs ziet rijden is die al weg voor je je telefoon gepakt hebt en als je er achter rijdt hoor je niet met je telefoon te spelen. QR codes hebben niets op een voertuig te zoeken, dus die zien er altijd belachelijk uit.

[mjz2cool]

Dan verlies je waarschijnlijk ook gelijk een groot deel van de potentiële bezoekers, omdat een qr code gewoon niet te onthouden is. En hoe gebruik je zo'n code als je die op je telefoon ziet?

[DeCo]

QR codes staan doorgaans afgebeeld, ergens op gedrukt, geprint, etc. Die hoef en kun je niet onthouden, tenzij je een fotografisch geheugen hebt 😉
Je hebt er op een device inderdaad niets aan,, maar daar zijn ze dan ook niet voor bedoeld.

[DonLexos]

Ja maar daar kan je dan weer niets mee op een desktop. .. Handig mogelijk als je ervanuitgaat dat mensen iets lezen en dan mobiel scannen en gaan browsen, maar als je een notificatie/bericht wil sturen met een link naar info is een QR code in zn geheel niet handig (om je moet het handig vinden dat je 2 devices nodig hebt om de link te kunnen openen, 1 om te lezen en 1 om te scannen)...

[aldieaccounts]

Linkverkorters zijn erg praktisch op folders enzo. Op alle plaatsen waar mensen een url handmatig over moeten tikken. QR codes zijn nog handiger natuurlijk, maar lang niet iedereen snapt die.

[willyb]

De kans dat je gebruiker een typo maakt is zeer groot.

Probeer maar eens: bit.ly/IllustratieO1 over te typen. 3x I (i) of 3x l (L), een O (nul) of een O (o)?
En als die url shortner dan niet op je eigen domein is, dan is de kans groot dat varianten daarop dus te claimen zijn voor je concurrenten.

[aldieaccounts]

Natuurlijk. Maar de kans op een typo bij

[code]http://www.langedomeinnaam.com/eenofanderelangeurl/query.html?bla&bloe&iks=3&kkkk&nogzowatparams&base64EncodedOnzinVanJeCMS[/code]

is *nog* groter. :-)

[Reactie gewijzigd door aldieaccounts op 23 juli 2024 01:03]

[willyb]

De typo achter je domein heeft alleen wel veel minder impact.

En vrijwel elk bedrijf heeft gewoon een korte domeinnaam natuurlijk.

Voorbeeldje: ikea had recent een bit.ly in een enquete. Ikea.nl/enquete was letterlijk minder tekens en minder kans op typefouten.

[aldieaccounts]

Sure, soms heeft het zin, en soms niet. Maar ik heb toch echt genoeg gevallen meegemaakt waar een bit.ly link beduidend minder typewerk (en dus kans op fouten) opleverde dan de volledige url.

Niet alle bedrijven zijn ikea.nl, er zijn ook genoeg bedrijfjes als uwlokaleslager.nl of hoteldegroenelinde.nl en dergelijke. Een typefout in een bit.ly url geeft meestal een vrij random resultaat, dus dat risico is in de meeste gevallen prima te nemen. Dat betekent slechts dat een enkeling niet bij je enquete/promo terecht komt.

Ik vindt http://tinyurl.com/y25yz986 nog steeds een stuk minder werk om in te tikken dan de oorpsronkelijke link.

[TheVivaldi]

"Je ziet ze vaak gebruikt worden op twitter, terwijl twitter helemaal geen verschil in lengte telt voor URLs: ze zijn altijd 23 karakters."

Nu niet meer nee, maar voorheen wel.

[jemson]

Behalve dan de overhead aan karakters die je bericht dan krijgt (sommige URL'S zijn gigantisch lang). Zo hou je je Twitter bericht wel een beetje netter.

[OddesE]

sommige URL'S zijn gigantisch lang

En dat is eigenlijk het probleem.

Veel developers zien de URL als puur een transport mechanisme. Je kunt ze lekker vol laden met parameters en state info etc. Dat de URL hiermee voor de gebruiker totaal onhandelbaar wordt ziet men dan als iets dat niet belangrijk is.

Persoonlijk zie ik de URL als zijnde onderdeel van de user interface. Wat daar staat maakt uit. En in de regel geldt: korter is beter. Vrijwel altijd is het mogelijk, of zelfs eenvoudig, om parameters en state velden uit de URL weg te halen. Dan ook nog het pad kort en eenvoudig houden en je krijgt een handelbare URL.

Tweakers is een goed voorbeeld van hoe het wél moet.

[psychodude]

Een url als website.com/forum/topic/1 is, ondanks langer, voor mij toch echt te verkiezen boven een nietszeggende url als website.com/a/b/1. Zowel uit developer als user perspectief. Korter heeft dan ook de grenzen. En daar zijn url verkorters dan wel weer handig in.

Niet voor digitale links, maar wel bijv. als korte link tijdens een presentatie. Om op die manier bijvoorbeeld het publiek bij een interactief deel te betrekken of een url mee te geven naar verdere informatie.

Een QR code kan ook, maar de ervaring leert dat binnen een niet IT publiek nauwelijks 1 op de 10 een QR code scanner geïnstalleerd heeft en/of weet te gebruiken. Een verkorte link overtypen, dat kan vrijwel iedereen.

Daar komt nog eens bij dat de domeinnaam markt verder en verder verzadigd raakt, waardoor de primaire domeinnaam voor veel startups vaak al langer is dan een verkorte url.

[robvanwijk]

Een url als website.com/forum/topic/1 is, ondanks langer, voor mij toch echt te verkiezen boven een nietszeggende url als website.com/a/b/1. Zowel uit developer als user perspectief. Korter heeft dan ook de grenzen. En daar zijn url verkorters dan wel weer handig in.

Spreek je jezelf hier niet tegen? Als "website.com/forum/topic/1" beter is dan "website.com/a/b/1", hoe kun je dan tegelijkertijd zeggen dat "link.com/abc123" beter is dan "website.com/a/b/1"; daar zit nog veel minder informatie in, je weet zelfs niet eens op welk domein je uit gaat komen.

[psychodude]

Zoals aangegeven, niet voor de digitale links. Op het web, in email, etc. gaat de voorkeur sterk uit naar een volledige links. Je kunt hieruit goet aflezen waar de pagina je zal brengen, en op basis van de link kun je ook relatief goed aflezen wat voor een content hiermee gepaard zal gaan.

Daarentegen om op een congres bijv. te verwijzen naar de huidige pagina:
nieuws: Google vervangt ingekorte goo.gl-links door Firebase Dynamic Links

Dan is het niet heel erg praktisch om van het publiek te verlangen om even vlug deze URL over te typen. Een verkorte variant:
https://bit.ly/2JQvCIA

Is dan praktischer. Nee, je weet hiermee niet met zekerheid waar je beland. Maar gezien het kader waarin het gebruikt wordt is de kans dat het voor malafide praktijken ingezet wordt aanzienlijk kleiner dan via een gemiddelde verkorte link op 4chan.

Het zou vanuit het oogpunt weten op welk domein je uit gaat komen ergens wenselijk zijn indien websites laagdrempeliger een eigen url shortener zouden introduceren. En technisch uiteraard helemaal niet zo ingewikkeld. Maar in de praktijk maar weinig die hier voor opteren.

[Steyn_E]

Behalve dat het interessant kan zijn om bij interactieve sites door te kunnen linken naar een specifiek deel. Zo wil ik een Google Streetview link kunnen delen met daarin de informatie:
-coördinaten van de camerapositie
-welk beeld er getoond moet worden (meest recente of juist die ene uit 2009)
-welke richting je op kijkt
-zoomniveau
Dat wordt nou eenmaal een lange URL lijkt me.

[OddesE]

Ja ok, zo kort mogelijk is soms nog steeds langer dan prettig is.
Overigens zouden de Google Maps URLs wel wat korter kunnen volgens mij hoor.

[space_octopus]

links in tweets worden ook visueel ingekort. Bijvoorbeeld https://www.euroncap.com/en/results/fiat/panda/34191 word iets als https://euroncap.com...panda/34191
dan doet twitter de hele link in een t.co variant, zodat ze statistieken kunnen bijhouden.

[MrMonkE]

Daarom moet je gewoon als bedrijf je eigen verkorter maken en gebruiken.

[JorzoR]

Het gebruik van dit soort verkorte links is vaak totaal overbodig. Je ziet ze vaak gebruikt worden op twitter, terwijl twitter (al erg lang) helemaal geen verschil in lengte telt voor URLs: ze zijn altijd 23 karakters.

Klopt. Maar korte URL's maken je text ook leesbaarder én vaak (zeker in het geval van goo.gl) worden ook de hoeveelheid kliks op die link bijgehouden, dus je kan gemakkelijk zien hoe vaak iemand op die link heeft geklikt. Dat kan voor sommigen waardevol zijn om te weten.

[Reactie gewijzigd door JorzoR op 23 juli 2024 01:03]

[Anoniem: 1128097]

Ik snap je .info deel niet helemaal. Wie of waar zie je dan die info?

[willyb]

Stel dat de link is: http://goo.gl/l6MS
Dan gooi je, in het geval van goo.gl de + erachter: [ http://goo.gl/l6MS+ ] en je krijgt de statistieken. Kan dus van elke link, niet alleen die van jezelf.

[Blue Knight]

Ik vind die ingekorte url's irritant en gevaarlijk. Je kan namelijk niet zien naar welke website ze gaan, tenzij je ze weer via een website controleerd wat er achter zit.
Tegenwoordig is het klikken op onbekende url's soms niet het meest veilige wat je kan doen.....

[TheVivaldi]

Daar heb je gelijk in. Aan de andere kant: als ik niet wist wat Tweakers was, dan zou ik bij de url 'tweakers.net' ook aan andere dingen kunnen denken en niet zeker weten of ik het wel zou vertrouwen...

[Soldaatje]

Voordat het werd overgenomen door Tweakers was tweakers.nl een pornosite inderdaad.

Als laatste is vermeldenswaardig dat we, zij het met nogal wat moeite, de beschikking hebben gekregen over het lang gewenste Tweakers.nl-domein. Tweakers.nl leidt de bezoeker nu direct naar Tweakers.net. Hoewel er geen plannen zijn om de site om te dopen tot kortweg 'Tweakers' en het .net-achtervoegsel te laten vallen scheelt het verkrijgen van het nl-domein heel wat verwarring. Met name beginnende bezoekers die via mond-tot-mond reclame op het bestaan van 'Tweakers' gewezen werden keken vreemd op als het invoeren van het .nl-achtervoegsel een site met schaarsgeklede dames opleverde.

reviews: Tweakers.net NG: what's new?

[Reactie gewijzigd door Soldaatje op 23 juli 2024 01:03]

[Olympus user]

Inderdaad, ik klik eigenlijk nooit op verkorte links.

[OddesE]

Een link klikken zou nooit gevaarlijk mogen zijn. Als dat toch het geval is is er gewoon een lek dat gedicht moet worden.

Vraag: Wat is de overeenkomst tussen het Financieel Dagblad, de Leeuwarder Courant, nu.nl, de Telegraaf en de website van MySQL?

Antwoord: ze serveerden op een bepaald moment allemaal malware.

Het is niet zo dat je veilig bent voor malware door fanatiek al je links te controleren op 'shady' websites. Zi werkt het helaas gewoon niet.

[Douweegbertje]

"zou nooit". We zouden nooit beroofd mogen worden, toch doe we onze deur op slot.

Je hebt een liefdevolle logica alleen werkt dat niet altijd. Puur omdat je technisch gezien nergens veilig bent betekend niet dat je dan maar alle vormen van preventie moet laten vallen.

@Blue Knight geeft niet aan dat je dan veilig bent, maar wel veiliger. Dat is ook gewoon waar.

[mjz2cool]

Een link klikken zou nooit gevaarlijk mogen zijn. Als dat toch het geval is is er gewoon een lek dat gedicht moet worden.

Het is geen lek, het is een handige functie die uiteraard ook misbruikt kan worden, zoals dat met vrijwel alles kan. De enige manier om dit te fixen is de "shady" websites te verbieden, zodat er ook geen verkortte links naar gemaakt kunnen worden. Maarja, dat zou een ideale online wereld zijn, want dan heb je ook geen virusscanners meer nodig voor het browsen.

Vraag: Wat is de overeenkomst tussen het Financieel Dagblad, de Leeuwarder Courant, nu.nl, de Telegraaf en de website van MySQL?

Antwoord: ze serveerden op een bepaald moment allemaal malware.

Dit is dan ook iets wat wel gefixed kan worden door die kwaadaardige code gewoon niet toe te staan in je advertentieplatform.

[easyriider]

Op Google maps worden nog steeds een goo.gl link aangemaakt bij het delen van een kaart zodat je de link kan versturen.

[unglaublich]

De typische situatie dat wanneer je op een link klinkt je door 4 redirects wordt geloosd met bijbehorende verzameling van statistieken omtrent je gedrag bij allerlei providers en cookies voor referrals worden gezet.
Eigenlijk weet je na die 1 seconde vertraging al dat het een slechte keuze was om te klikken.

[kozue]

Precies. Meestal worden url verkorters gebruikt door marketingmensen, en niet om een makkelijk te onthouden url te hebben (niemand onthoudt zo'n cryptische hash), maar om te verbergen dat je eigenlijk naar een of meerdere marketingtrackers gaat voordat je op de site zelf belandt...

Aangezien ik toch geen behoefte heb aan marketinguitingen staan die goo.gl links al jaren gewoon geblokkeerd in de lokale dns op mijn eigen netwerk. En eigenlijk kom ik ze ook nooit tegen. Misschien zie je die alleen op social media, waar ik al helemaal niet aan doe?

[DonLexos]

Je bedoelt dat als je Ghostery aan (desnoods niet actief) hebt je kan zien (los van advertentie netwerken) dat iedere willekeurige .nl website 10+ aan analytics/meldingen/etc inlaadt?

[ajakkes]

Ben ik de enige die nog nooit van Google Firebase Dynamic Links had gehoord?

Het ziet er op het eerste gezicht uit als iets met de prioriteit op User-tracking en Ad-serving. Maar dat is natuurlijk ook de core-business van Google. En dat was natuurlijk ook het doel van goog.le linkjes.

Kan iemand toelichten wat Firebase precies inhoud?

[JorzoR]

Kan iemand toelichten wat Firebase precies inhoud?

https://firebase.google.com/

[mutley69]

Een bedenking: In de strijd tegen malware zijn verkorte links zelfs een pest.

[Anoniem: 420148]

Slordig artikel. Er wordt niet echt beschreven wat Firebase Dynamic Links precies zijn, geen direct linkje naar de docs en dat het op je eigen domein werkt.

In de praktijk gaan gebruikers wellicht niet veel merken van de transitie.

Wat? FDL is geen drop-in replacement voor een URL-verkorter. Een willekeurige consument kan niet even elk willekeurig linkje laten verkorten, zoals voorheen. Je moet dus je eigen domein bezitten. Lijkt met wel degelijk een merkbaar verschil. Ik gebruikte zelfs wel eens goo.gl voor linkjes met veel args, die vervolgens niet geparsed werden door bepaalde messengers, evenals links met karakters die werden vervormd. (naar bvb emoji) Dat kan nu allemaal dus niet meer.

https://firebase.google.com/docs/dynamic-links/

[DonLexos]

Nee exact, en al helemala niet omdat firebase vooral voor apps is bedacht, en goo.gl ook prima richting webSITES kon en vanaf iedere browser/device te gebruiken was... jammer dat ze ermee ophouden, was nl een redelijk clean doet-1-ding-en-dat-is-prima-dienst zonder veel poespas.

[Mushroomician]

Ben benieuwd wat zij gaan doen na de invoer van art 11 & 13.

[SeatRider]

Eerst dacht ik aan een flauwe 1 april-grap, en toen zag ik dat de data genoemd in dit bericht uit 2018 zijn