erkka

Missään ei kai ole hakattu kiveen, että mikroblogipalvelujen 140 merkin rajoitusten pitäisi koskea URL:eja? Palveluhan voisi typistää osoitteen näin http://www.qaiku.com/home/erkka/show/... jolloin se vie vähemmän tilaa, mutta ei hämärrä käsitystä siitä, mihin se viittaa - tuon http-alunkin voisi tiputtaa tarvittaessa esityksestä

Periaatteessa riittää kun siinä olisi domain/... eli http://www.qaiku.com/... tai www.qaiku.com/...

Pointtinani kuitenkin, että URL söisi merkkirajoituksesta vain vähän, ei absoluuttista summaa. Esim. vain 10 merkkiä.

Hyvä pointti, enpä ole tullut ajatelleeksi.

@erkka On käynyt itselläkin mielessä, että kuinka kauan nuo erilaiset lyhytlinkkipalvelut toimivat. Sitten kun joku ei toimi, sillä tehty linkki on hävinnyt. - Viha ehkä on liioiteltu tunne tähän, ehdotan närkästystä tai ihmettelyä.

Edit: kolmannen osapuolen tuominen (se lyhytlinkkipalvelu) on ihan turhaa.

@erkka Olet asian ytimessä. Mikroblogipalvelu voisi laskea linkin vaikka vain yhdeksi merkiksi. Noista lyhyturlipaikoista on tullut mielenkiintoinen kohde hakkereille. Minä vierastan noita sen takia, että en vain yksinkertaisesti tiedä, mikä olisi luotettava seuraavien aspektien suhteen:

• On hengissä seuraavat 50 vuotta
• On toteutettu ja ylläpidetty laadukkaasti niin, että hakkerit eivät pääse vaihtamaan hyppykohdetta

Eikö tuon www-osuudenkin voisi heivata pois? Miten se sitten käytännössä olisi toteutettavissa? Voisiko esim. Qaikuun saada moisen?

Esimerkiksi qaikussa voisi olla oeriaatteessa mahdollista, mutta käsittely vaatii oikeastaan postitusvaiheessa (taas) yhden lisätarkistuksen ja käsittelyn tekemisen; hieman lisäraskautta järjestelmälle. Myös reaaliaikaisen laskurin tekeminen menee ns. aikalailla mielenkiintoiseksi tälläisissa tapauksissa.

Pistetään korvan taakse mietittäväksi miten tuota voisi parantaa qaikun osalta, mutta siis teknisesti tuo ei ole ihan niin suoraviivainen kuin äkkiseltään tuntuu :)

Rikkoutuneet linkit ja tietoturvaongelmat eivät kuulosta hyvältä. Itselleni tuo lyhyt linkki tietoturva pulma oli uusi. Kaikkea sitä oppii kun wwwanhaksi.elää.fi

@eholmila: Eikös ongelma koske enimmäkseen tuota aloitusqaikua, jossa on asiakaspuolella merkkejä rajoittava skripti? Mikäli URLit havaitsevan koodin voisi vääntää myös asiakaspuolelle, poistaisi se kuormituksen palvelimilta niiden osalta joilla javascript on käytössä. Luonnollisesti homma täytyy hoitaa myös backendissa, mutta näin ei koko kuormitus olisi palvelimilla.

@nikc, kyllä joo, koskee vain aloitusqaikuja. Ja tosiaan pelkkiä client-pään rajoitukset pitäisi luonnollisesti aina mapata ja napata myös backendissä. Käytännössä tuo ei pitäisi olla mitenkään täysin mahdotonta, mutta vaatii kuitenkin oman vääntämisensä. Katsotaan :)

Tuli mieleen yksi potentiaalinen privacy-ongelmakin tähän liittyen, voisin katsoa onko epäilykseni jo totta...

Mutta sorsastetaan ensin: Mitä lyhyturlipalveluita on.
http://tinyurl.com

http://bit.ly/

Melko kattava lista löytyy osoitteessa http://www.dmoz.org/Computers/Interne...

http://➡.ws/

Lyhytlinkkipalvelut ovat mulla olleet hyödyllisiä kun meilaa linkkejä: sellaiset pitkät, joissa on monta sataa merkkiä muuttujia, kun ei aina tuu perille oikein.

Niin ja http://go.fi

Yök lyhytlinkkipalvelut, häviää se vähäkin metatieto joka urlissä on :(

Niillähän on joku suunnitelma tehdä lyhytlinkkiarkisto 301works.com. Mutta saa nähdä saako kaikki palvelut puhaltamaan samaan hiileen . Pari lisää vielä palveluista: http://is.gd , http://tr.im & http://ow.ly (varmaan kaikki tuolla dmoz:n listalla.) ;)

@eholmila: Varmasti asia ei ole kovin yksinkertainen toteuttaa, mutta kannattaa laittaa muhimaan, sillä elegantti ratkaisu korjaisi aika keinotekoisen ongelman. Toki tuossa on myös se, että hiiren oikean napin valikkoa tuntemattomalle URLin kopiointi suoraan vaikeutuu (mutta ainahan voi avata sivun ja kopioida sitten, jos on niin käsi).

@LauriN: www:nkin voisi varmaan pudottaa, vai tuleeko ongelmia kun kaikki sivut ei aukea ilman www-alkua (vaikka pitäisi).

@pni: Pitkät URLit ovat kieltämättä hankalia mailissa, mutta vika (sivuston url-rakenne ja paska email-palvelu/ohjelma) ei korjaannut purkkapalvelulla.

@mace: aamen

Sinällään voin kyllä keksiä montakin perusteltua käyttötapaa lyhytlinkkipalveluille, mutta ne kaikki liittyvät verkon ulkopuoliseen mediaan. Esim. radio-ohjelmassa tai podcastissa puhuja voi pitkän rimpsun sanelun sijasta typistää linkin ja sanoa vain menkää osoitteeseen "linkki.yle.fi/134".

@erkka: ai sä et saa auki sitä linkkiä, huono juttu, mutta en mä sille mitään voi kun toi on se verkko-osoite... mitä jos ottaisit niihin yhteyttä ja pyytäisit vaihtamaan julkaisujärjestelmää johonkin parempaan?

Lähdin pohtimaan, miksi joku haluaa rakentaa lyhyturlipalvelun. Tai jos on rakentanut palvelun jolla on käyttöä, miten sen voisi muuttaa rahaksi? Mieleen tuli yksi ehkä jopa pelottavakin konsepti joka liittyy yksityisyydensuojaan.

-- warning -- scientific content --
Ensin kuitenkin vähän taustaa cookie-tekniikasta. Kaikki varmaan tuntevat, miten http cookiet toimivat: Kun menen osoitteeseen www.abc.com, serveripää voi kysyä, onko ko. palvelin jättänyt cookie-tiedoston aiemmalla käynnillä. Jos ei ole, palvelin lähettää cookien (mitä tahansa dataa) selaimelle joka tallentaa sen levylle. Näin voidaan toteuttaa esim. se, että käyttäjä pysyy palvelimeen kirjautuneena. Varsin harmitonta ja hyväksyttyä toimintaa, esim. Qaiku pitää kirjautumistiedon näin tallessa, jos ruksii ko. toiminnon kirjautuessa.
Banner-mainostajat ottivat aikoinaan käyttöön tästä vähän ovelamman väännöksen: Kun palvelin www.abc.com näyttää ylhäällä bannerkuvaa, se haetaan osoitteesta www.bannerfirma.com. Vaikka olen menossa www.abc.comiin, myös www.bannerfirma.comista haetaan websisältöä (bannerkuva). Heille menee samalla myös tieto, miltä sivulta ollaan tultu (http-headerin referer). Bannerifirma voi myös jättää cookien. Jos cookieta ei jo ole, he laittavat siihen yksilöllisen koodin, jonka selain lähettää aina, kun näytetään heidän banner. Ovelampi juttu on se, että aina kun ladataan banner, heidän palvelimelleen kirjoitetaan, millä sivulla ko. asiakas on. Toisaalta jos klikkaa banneria tallennetaan myös tämä. Mitä useammalle firmalle www.bannerfirma.com myy palvelunsa, sitä isompi markkinointikanta heille syntyy (tämä henkilö joka käy saitilla abc, käy myös saitille ccc ja myös ddd:ssä jossa hän on klikannut tällaista banneria). He myös myyvät takaoven kautta tätä tunnistetietoa sekä bannereita näyttäville että bannerien kohdesivustoille, jotka sen mukaan voivat säätää sisältöä ko. asiakkaan näköiseksi. Yksi kuuluisimmista bannerfirmoista on doubleclick, jonka Google omistaa.
Tämä ns. "3rd-party-cookie"-tekniikka aletaan nähdä joskus yksilönsuojan vastaisena. Siksi selaimiin on rakennettu 3rd-side-cookie-estotekniikkaa, eli silloin cookien saa kirjoittaa vain se palvelu, josta varsinaista websivua ollaan lataamassa.
Tämän eston takia monet saitit ovat siirtyneet käyttämään flashcookieta, johon ei taas nämä estot pure...
-- warning -- scientific content ends --

Lyhyturl-palveluissahan on ideana, että selain hyppää lyhyturlipalvelimelle, joka hakee tietokannasta ko. lyhyturlia vastaavan pitkän urlin ja pyytää selaimen lataamaan sivun uudestaan ko. osoitteella. Tähän ei siis tarvita cookieta.
Mitä jos käy niin, että ko. lyhyturlifirma alkaa käyttämään tuollaista 3rd-side-cookie-tekniikaa, mutta tällä kertaa he ovatkin 1st-side, johon lähes aina saa cookien tallennettua? He voivat siis katsoa, onko ko. käyttäjälle jo annettu tunnistecookie. Jos ei ole, generoidaan yksilöllinen tunniste.
Tämän tunnisteen perusteella voidaan aina ko. lyhyturlitarjoajan lyhyturlia käytettäessä tallentaa seuraavaa:

• Miltä sivustolta käyttäjä tuli (ja kaikkea tästä mutkan kautta johdettua, esim. mitä twitter-virtaa näyttäisi seuraavan jne)
• Minne sivustolle käyttäjä meni

Tällaista tietoa kertyy siis samasta käyttäjästä pitkältä ajalta. He eivät tiedä, kuka olet, mutta he voivat profiloida sinut. Nyt heillä on kiinnostavaa dataa, joka kiinnostaa kohdesaittia! He voivat myydä tätä tietoa tyyliin "maksa meille xxx dollaria kuussa, niin lisäämme urlin perään tunnisteen, jolla voit hakea palvelimeltamme käyttäjästä profiilin".

En tiedä, onko näin jo käynyt.

Katsoin läpi nuo tässä ketjussa mainitut muutamat lyhyturlipalvelut. Osa niistä jätti cookien. Miksi? Nekin, jotka eivät jätä vielä, voivat mikä tahansa päivä muuttua "likaiseksi" tässä mielessä.

Tässä vielä lista pikaisen testin perusteella:

• tinyurl - Ei cookieta, ok
• bit.ly - Ei cookieta, ok
• ➡.ws - Teki cookien, miksi?
• ow.ly - Teki cookien, miksi?
• tr.im - Teki cookien, miksi?
• is.gm - Ei cookieta, ok

@erkka, yksi syy lisää vihata lyhyturleja?

@Ile... Sulla on rikollinen mieli.
Tykkään susta.

@Ile dy.fi taitas kans olla.

@Herra Mitä on turvallisuus? Se on tunne. Hyvä ja luottavainen tunne siitä, että olemme elimoinoineet kaiken turvattoman. Hyvin suhteellinen käsite siis. Joskus pitää pähkäillä "rikollisen aivoin", jotta voi vetää viivan turvallisuuden/turvattomuuden välille.

@ferrix Tarkistin dy.fi:n, he eivät tee cookieta. He tosin myös poistavat viittauksen, jos sitä ei käytetä 6 kuukauteen. Onko sekään ihan ok?

Mulla turvallisuus on varmuutta siitä että jotakin yllättävää, odottamatonta ja hämmästyttävää tulee tapahtumaan.

@erkka, @eholmila Jos Qaiku sallisi >140mki:n aloitus-Qaikut, tulisiko ongelmaa siinä vaiheessa, kun halutaan agregoida Qaikuja joihinkin muihin microblogeihin? Pitääkö tästä syystä mennä huonoimman palvelun mukaan...

Toki yksi ovela tapa voisi olla sellainen, että Qaiku itse generoisi lyhyturlit feedeihin. Homma toimisi näin:

• Aloitusqaiun maksimimäärää pitkät urlit verottavat vain esim. 12 merkkiä, mutta Qaiku näyttää urlit oikein
• Kun tehdään Qaikusta feedi ulos tai haetaan aloitus-Qaikuja API:lla, kaikki linkit korvataan Qaiku-järjestelmän omalla lyhyturlilla

--> Näin esim. twitteriin aggregoitu Qaiku-viesti (joo, tiedän ettei tällaista vielä taida olla) mahtuu 140 merkin tilaan ja linkit viittaavaat Qaiku-palveluun, jonka kautta redirect tehdään

Yksi tuoreehko: http://rt.nu/ ja sen seuralainen http://retweet.com, joka on jonkun lyhyturl vs. digg:n sekoitus (Joku noissa palvelussa tökkii, en tiedä vielä mikä).

Vai pitäisikö ylipitkät aloituskaiut, muuttaa jo luonnissa kommenttiketjuksi? Tekstiä voisi tuohon statusboxiin laittaa halutusti, mutta kun pitenee liikaa, loppu "valutetaan" 1. kommenttiin etc.

@pni: Joo. Ihan totta - todellisuutta on vaikea muuttaa. Hain lähinnä sitä, että vaikka ne paikkaa jotain, niin ne on silti perseestä.

@Ile: Spooky. Aggregointikysymys on muuten hyvä.

@vimma: Mielenkiintoinen ajatus tuo jako.

@eholmila: Liittyykö tuo uusi qaikutusmoodi tähän?

@erkka , ah, tähän oli jäänyt vastaamatta, mutta kuten olitkin mitä ilmeisemmin huomannut, niin liittyy kyllä :) Lisäsimme myös lähes samalla vauhdilla jokaiseen qaiku-viestiketjuun oman lyhyt-urlin sinne oikeaan laitaan.

@eholmila Hieno juttu tuo oma lyhyturlipalvelu, niin ei myöskään nuo mainitsemani riskit noiden 3-osapuolien palveluiden kanssa pääse yllättämään.

Kuva Hesarin lyhytlinkkimallista: http://www.qaiku.com/go/3wlt

+1 @mace