Simpelt er bedre - Kkloud

Indrømmet - jeg er nem at begejstre, men Kkloud er altså også et cool koncept. Den utroligt simple funktionalitet dækker et behov hos mig, som jeg for nyligt igen er blevet påmindet om - hvordan udveksler man nemt filer med dem man samarbejder med, når email-attachments bare ikke er nok?

Som nørd kan man jo altid finde en vej, men for ikke-nørder kan det være en besværlig proces, som kan kræve at man registrerer sig på forskellige fil-udvekslingssites, som så til tider viser sig at have begrænsninger på hvilke filer der kan deles og som ofte spammer en efter transaktionen.

En af mine studiekammerater har (sammen med en anden udvikler) netop vundet Software-sektionen af Venture Cup (og dermed 50.000 kr.) med en løsning til dette problem: Kkloud - super-simpel fildeling.

Jeg vil lade deres promotion-video tale for sig selv:

Utroligt simpelt - ikke?

Jeg tror på Kklouds succes og med den forhåbentlige succes er der noget at lære:

  1. Simpelt er bedre
  2. Nogle gange er begrænsninger en feature (ligesom på Twitter)
  3. Selv om et problem er løst før, kan du løse det endnu bedre

Forhåbentlig finder Kkloud nogle gode indkomstkilder som ikke er baseret på at vinde startup-konkurrencer og så er der endnu en læresætning: "If you build it they will come". Som med Twitter og Facebook er det vigtigere at have et sejt produkt og en stor brugerbase end en forretningsmodel.

Der er sikkert endnu flere gode pointer gemt i Kkloud, men indtil videre vil jeg lade sitet tale for sig selv. Hvad synes du om ideen og udførslen?

Kommentarer (56)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Yoel Pedersen

Ganske enkelt og overskueligt.

Til andre, der måtte være interesseret i teknikken bag:

http://www.prosa.dk/aktuelt/nyhed/artikel/kklouddk-teknikken-bag/

Dog ser jeg en enkelt svaghed i det her system - nemlig at serveren i praksis er nødt til at håndtere samtlige filer, også selv om de kun eksisterer i begrænsede bidder mens de er i transit. Det giver to problemer:

  1. Tjenestens kapacitet er lig med halvdelen af den tilgængelige båndbredde - intet er gratis, heller ikke båndbredde (eller servere, for den sags skyld)
  2. Med de sindssyge domme vi har set fra bl.a. Københavns fogedret vil folkene bag kkloud komme ind under bestemmelserne om "eksemplarfremstilling" i lov om ophavsret - det kan blive et problem, hvis nogen skulle finde på at bruge kkloud til deling af musik eller film

Jeg går ud fra, selve servicen blot fungerer vha. simpel HTTP - POST og GET - og en Java-applikation på serveren, der foretager selve bit-flytningen?

Kunne man ikke lave en browserapplet i Java (fy-ord, jeg ved det) eller en Flash-applikation, der vha. hole-punching laver en direkte P2P-forbindelse mellem de to brugere, hvis det er netværksmæssigt muligt? På den måde ville man kunne komme uden om begge de problemer, jeg har nævnt (om end man muligvis ville skabe et par nye).

  • 0
  • 0
Tobias Baunbaek
  1. Korrekt :) Men man skal overføre det samme trafik ligegyldigt hvad, tænker jeg. Filen skal vel altid både op på serveren og nedad igen.
  2. Det vil jeg godt høre lidt mere om hvis du ved mere. Hvad er forskellen på kkloud og så f.eks det at være et hosting center som one.com? Og hvad hvis serverne ikke er i Danmark?

Du har nogenlunde ret i det med arkitekturen. At få det til at virke i browseren er dog en smule tricky. Serveren har vi så selv skrevet for at kunne understøtte netop den måde vi benytter det på.

Da vi først lavede kkloud var det en applet. Men der var lige det ene krav at man skulle have java. Det følte vi ikke fungerede særlig godt - pludseligt var det ikke noget som "bare" virkede, men i stedet noget som virkede for det meste. Vi har faktisk haft set på en flash-applikation, men der er nogle underlige begrænsninger. Flash vælger at loade hele filen ind i hukommelsen, så store filer er pludseligt ikke interessante - og så har den samme bagside som fra før. Der er en del af disse sites online allerede nu, og de fungerer fint, men ikke til specielt store filer.

Så vi har gået efter simplicitet. Det skal kræve få kliks, og så lidt viden som muligt. Vi er stadig ikke der hvor vi helt vil være mht. simpliciteten, men næsten :)

Mvh
Tobias Baunbæk,
kkloud.com

  • 0
  • 0
Michael Rasmussen

Hvad er forskellen på kkloud og så f.eks det at være et hosting center som one.com?

Nu er forskellen temmelig evident derhen, at kkloud er udviklet udelukkende med fildeling for øje, og dermed kan det sidestilles med Kazaa mm. I må derfor påregne et væld af sagsanlæg fra IFPI

Og hvad hvis serverne ikke er i Danmark?

Sagen mellem antipiratgruppen og tele2 om piratbay.org og tidligere sager om AllofMP3 har vist, at placeringen af server ikke automatisk sikre en mod sagsanlæg ved en dansk domstol.

  • 0
  • 0
Tobias Baunbaek

Hvad så med youtube, wikipedia, imgur.com... altså alle steder på nettet med en upload-knap. Hvordan kan disse sider slipper igennem det?

Det kan ikke sidestilles med kazaa, da alt hvad man delte var delt med resten af verden. På kkloud er det delt på en hemmelig lokation som du kun deler ud til dem som skal have det.

Vi har ikke lavet det i en en-til-mange øjemed. Og uden at vide meget om jura'en i det så tror jeg også sidens intention spiller en stor rolle. KKloud er ikke skabt til ulovlig fildeling, men har det formål at det at sende en fil fra a til b skal være så nemt som muligt.

  • 0
  • 0
Therese Hansen

For mig er det primært at filerne forsvinder, når du lukker browservinduet - jeg skal ikke bekymre mig om hvem der ellers med tiden får adgang til mine filer.

Simpeltheden i brug er der flere der har, men mange af de eksisterende services giver dig nok lov til at uploade en fil, men så skal du altså også lige registrere dig før du får delelinket. Kkloud er registreringsfrit.

  • 0
  • 0
Yoel Pedersen

Hej Tobias

Tak for dine svar.

Vedr. pkt. 1: Nej, I er selvfølgelig ikke ringere stillet end rapidshare, youtube og alle de andre steder, hvor man uploader en fil for at hente den igen fra en anden PC. Men grunden til at jeg betragter det som en svaghed er, at der ikke umiddelbart er en synlig forretningsmodel, der kan understøtte systemet på længere sigt. Hvilken garanti har jeg for, at I ikke bliver nødsaget til at tage en kopi af mine filer, jeg sender igennem, for at bruge mine data til profilering, der sælges til højstbydende reklameannoncør (modellen bag gmail)? Jeg ved godt, det lugter af paranoia og sølvpapirshat, men I er vel nødt til at tjene penge til servere og internetforbindelse - eller skal det være på donations-vilkår ligesom Wikipedia?

Vedr. punkt 2: Som en anden skriver, er det netop sagerne mod danske internetudbydere, jeg tænker på. Umiddelbart burde man jo mene, at en internetudbyder burde være en neutral partner, der ikke kan gøres ansvarlig for brugernes handlinger (i stil med jeres service), men forældede regler om eksemplarfremstilling (som fx kopiering af fysiske copyrightede bøger) gjorde at internetudbyderne (Tele 2 m.f.) blev pålagt at begrænse adgangen gennem deres netværk. Dommen lagde så vidt jeg husker op til, at selve bit-flytningen i ISP'ens routere skulle sidestilles med fysisk eksemplarfremstilling.

Du har formentlig ret i, at det hjælper gevaldigt, at en fil kun bliver delt mellem 2 parter - det vil i hvert fald gøre det svært for trediepart at bevise, at der er delt copyrightede filer.

Og mht. hvorfor Youtube o.l. ikke løber ind i problemer - tja, det har nok noget at gøre med, at de er tilstrækkelig store til at ingen tør lægge sig ud med deres advokater - for ret beset kan jeg ikke se forskel på om jeg henter en ulovlig film fra Pirate Bay eller ser den på Youtube.

Anyway - hvis I kan påvise en fornuftig forretningsmodel, der garanterer mig at de filer, jeg måtte finde på at sende over jeres service, ikke bliver kompromitteret, kan jeg sagtens se en berettigelse for jeres produkt - og jeg vil ønske jer al mulig held og lykke med det.

  • 0
  • 0
Jacob Christian Munch-Andersen

Nu er der er en del andre services som tillader upload uden registrering.

At filen forsvinder når man lukker vinduet, det havde jeg faktisk ikke lige spottet, men det betyder så at man skal have sin computer tændt indtil modtageren har fået snøvlet sig sammen til at hente filen, det forekommer egentlig ikke så praktisk.

  • 0
  • 0
Tobias Baunbaek

Tak for kommentarerne.

Punkt 1. Du har ret :-) Uden en tydelig forretningsmodel kan man blive i tvivl om hvad vi helt gør med filerne. Og det er en forståelig tanke. Vi arbejder i øjeblikket på forretningsmodellen så der skal nok komme noget inden sådan ALT for længe. Dog vil jeg sige at som så meget andet på nettet så kræver det meget at du stoler på tjenesten. Hvis ikke du gør det skal du nok ikke ligge dine bankdata der. Ellers skal du lige selv kryptere det først - tjenesten kan af gode grunde ikke gøre det for dig.

Punkt 2. Det bliver lidt gætværk fra min side, men jeg har nogle kommentarer. Du kan nok godt sidestille os med en ISP i dette scenarie. Men for dem var det at de skulle begrænse deres service således at man ikke ikke kunne lave opslag til f.eks The Pirate Bay. Dette er ikke noget vi konkret kan gøre, så hvis vi skal begrænse os skal det defineres i en retssag hvad det vil sige. Jeg tror selv på at youtube undgår en masse retssager fordi de er med på at gøre noget ved problemet, og sletter det som ophavsretighedsindehaverne mener krænker dem. På samme kunne man forestille sig at vi skulle filtrere visse filer fra som Seinfeld.S01E03-CranKy eller hvad det nu skal hedde.

Om det er sandt ved jeg selvfølgelig ikke. Vi spekulerer bare lidt :)

Mvh
Tobias Baunbæk,
kkloud.com

  • 0
  • 0
Jesper Lund

Vedr. pkt. 1: Nej, I er selvfølgelig ikke ringere stillet end rapidshare, youtube og alle de andre steder, hvor man uploader en fil for at hente den igen fra en anden PC. Men grunden til at jeg betragter det som en svaghed er, at der ikke umiddelbart er en synlig forretningsmodel, der kan understøtte systemet på længere sigt. Hvilken garanti har jeg for, at I ikke bliver nødsaget til at tage en kopi af mine filer, jeg sender igennem, for at bruge mine data til profilering, der sælges til højstbydende reklameannoncør (modellen bag gmail)?

Hvis man bruger cloud services til at dele private filer, skal man naturligvis kryptere filerne først på klient siden. Hvis krypteringen er lavet ordentligt, kan Rapidshare eller PET/CIA/NSA til gengæld snage lige så meget som de har lyst..

  • 0
  • 0
Lars Ole Pontoppidan

Jeg kan forstå at filerne forsvinder når upload-vinduet lukkes. Er det en grundlæggende egenskab ved systemet, eller kunne man indføre et levetidskoncept hvor man vælger hvor lang tid filerne skal leve? F.eks. 1 dag som default og 7 dage som maksimum. Så ville det være en genial service der kunne bruges parallelt med en normal mail, a'la: "... Hent filerne på kkloud.com med logon xyz, de er til rådighed de følgende 7 dage".

  • 0
  • 0
Jesper Lund

Er det en grundlæggende egenskab ved systemet, eller kunne man indføre et levetidskoncept hvor man vælger hvor lang tid filerne skal leve? F.eks. 1 dag som default og 7 dage som maksimum. Så ville det være en genial service der kunne bruges parallelt med en normal mail, a'la: "...

Lidt ala den stil (men ikke helt..) findes i Vanish systemet
http://vanish.cs.washington.edu/

Interessant brug af et Bittorrent netværk (Vuze DHT).

  • 0
  • 0
Jacob Christian Munch-Andersen

I øvrigt trist at se hvor lidt der er gjort ud af tilfældighedsgeneratoren til at generere share navne (som jo også virker som kodeord). Helt åbenlyst er 25^5 muligheder jo for lidt. Hvis tjenesten bliver populær vil det give mange kollisioner. Prøv med 25^15 i stedet.

Dertil kan man ikke regne med entropien i JavaScripts Math.random, det er nødvendigt at tage fat i noget ekstra data, fx musebevægelse, for at få en ordentlig entropi.

  • 0
  • 0
Tobias Baunbaek

I dit eksempel vil jeg også mene man skal tage hensyn til hvor mange kklouds der er i live på én gang (normalt) og hvor længe en kkloud er i live (normalt). Så kan se på de faktorer og se på sandsynligheden for at man kan ramme en.

Når tjenesten er populær kan vi forlænge og gøre noget. Men det tager ikke lang tid at lave, og kan nemt rettes til. Hvis vi endelig skal gøre mere kan vi bare sende et kald op på serveren, og så have en generator der som kan være lavet i et sprog som har en større tilfældighedsgenerator.

Men som sagt synes jeg ikke det er så presserende.

  • 0
  • 0
Henrik Schmidt

, selvom jeg foretrækker DropBox, men der skal man jo registrere sig.

Der er jo allerede en del browsere, der supporter HTML5 drag'n'drop fil upload, så det synes jeg da I skulle tage at implementere. Det ville gøre det endnu simplere.

  • 0
  • 0
Tobias Baunbaek

Det har vi allerede gjort. Når du har lavet en kkloud, kan du bare trække filer over i den.

Mht. dropbox synes jeg ikke selv den er så god til fildeling. Dropbox handler også om backup så det er helt fair.

Et problem er at den håndterer store filer skidt, ved at man skal uploade det hele før det er tilgængeligt. Og hvis det er filer som skal benyttes lige nu kan man ikke vente.

På et tidspunkt fik jeg tilsendt et link til nogle "sikre" filer på dropbox. For at se dem skulle jeg så lave en account først. Det syntes jeg egentlig ikke var en god idé, for hvorfor skulle jeg oprette mig fordi en anden ville sende filer til mig?

Dermed ikke sagt at Dropbox er dårligt, for det er det bare slet ikke. Jeg synes bare formålet er et andet.

  • 0
  • 0
Henrik Schmidt

Ups, ja man skal huske at gennemteste applikationen før man foreslår noget :)

Jeg er enig i, at Dropbox er mere omstændelig og har et bredere anvendelsesområde.

Man kan dog sende public filer via et URL, og jeg bryder mig alligevel ikke om, at sende sikre filer over en ekstern service, som jeg ikke rigtig aner noget om. Der er sikrere muligheder, men nu er jeg jo også nørd :)

  • 0
  • 0
Jacob Christian Munch-Andersen

Det forekommer ikke at du tager sikkerheden særligt alvorligt, jeg har konstateret at den er ringe alene til at undgå tilfældige kollisioner, det bliver meget værre hvis vi først snakker om et rigtigt angreb.

I øvrigt burde I også fjerne muligheden for selv at vælge share navn, så I undgår dårlige passwords. Man sender alligevel bare et link, der er ikke behov for at folk kan huske navnet.

  • 0
  • 0
Tobias Baunbaek

Vi tager skam sikkerheden ret alvorligt. Som du nævnte før er det en mulighed at sætte det tilfældige navn op til nogle flere tegn. Men vi har ment at lige nu så er sandsynligheden stadig meget lille, og stort set kun teoretisk for at to skulle ramme hinanden. I et evt. angreb kan vi gå efter at lukke klienter nede som pounder for meget, og på den måde skal de distribuere sig ud på flere maskiner for at kunne angribe. Det er ikke helt så enkelt, og vi må her tænke hvad man kan få ud af det til gengæld: man kan finde tilfældige folks filer, for du kan ikke lave et målrettet angreb på en enkelt persons hemmelig sharename.

Helt enig med dig i at vi skal fjerne muligheden for at vælge sharenavn. Det er noget vi er ved at lave, men der er noget mere presserende lige i første omgang.

Grunden til at vi lavede det sådan at man selv kan vælge navn er at man har bedre mulighed for at give en url over telefonen. Det er kan være svært med ajfelfju i forhold til abemad. Men det er også noget vi fjerner inden længe.

  • 0
  • 0
Yoel Pedersen

Hjælper det overhovedet at lave et ApS? Hvis man overtræder loven (også selv om den er åndssvag) hæfter man vel personligt?

Men ved nærmere eftertanke tror jeg nu ikke, at jeg ville være så bekymret i forhold til ophavsret m.v. - nøglen er, som du også selv var inde på, at man jo kun deler mellem 2 personer - så selv hvis nogen skulle finde på at dele en ulovlig fil, de alligevel ville have delt på anden vis, hvordan skulle der så nogensinde blive et problem ud af det? Hvis et træ falder i skoven...

Forresten, hvis I er ved at stifte et ApS, så vil jeg lige give jer et råd fra bitter erfaring: Husk at bede advokaten, der opretter firmaet, om at indskrive i vedtægterne, at revision er fravalgt. For nystartede ApS'er er det spild af gode penge (og advokater og statsautoriserede revisorer er ca. lige skruppelløse og tager godt ved, når først de får fat).

  • 0
  • 0
Ulrik Gammelby

Ro på med den der fantastiske brændende version2-kommentator optimistiske attitude... Det er vel en ok strategi at starte med at fokusere energien på at skabe noget interessant og så i første omgang nøjes med en grovskitse for hvordan de skal klare evt. ondskabsfulde angreb.

  • 0
  • 0
Tobias Baunbaek

@Jacob: Jeg er lidt enig med Ulrik her. Først lav noget der virker og så put sikkerhed på. Det er en umulig opgave at lave det "endelige" produkt til at starte med. Det tror jeg ikke der kommer noget godt ud af. Vi har tænkt på de ting du siger og har en god idé om hvad vi vil gøre ved det. Men rent faktisk at gøre det ligger ikke øverst.

Det er rigtig rart at folk kommer med forslag og kritik, og vi tager den til os. Men det er ikke muligt at implementere alting på én gang.

  • 0
  • 0
Tobias Baunbaek

Jeg ved faktisk ikke om det hjælper at lave et ApS ift. lovgivning. Men hvis man bliver dømt til at betale noget så ligger det (måske) i firmaet og ikke i ejerne. Er ikke sikker på noget dog.

Mht. revisor så har vi en statsautoriseret revisor i familien, og ja, de tager kassen når man betaler dem. Heldigvis koster det os ikke noget, så det gør det hele lidt lettere :) Desværre bliver vi nødt til at betale en advokat, og han kommer nok til at koste en hel del.

Har du selv erfaring med at lave et ApS?

  • 0
  • 0
Baldur Norddahl

Det vil være muligt at overføre direkte udenom serveren med IPv6 eller med IPv4 NAT traversal. Dog ikke med javascript+HTML5 - det vil være nødvendigt med java (evt. webstart) eller anden form for applikation. Serveren vil kun have brug for minimal båndbredde for at koordinere overførslen.

I forhold til jura vil min vurdering (som ikke jurist!) være at der ingen problemer er. Alle de tjenester der har været i problemer har haft en søgemaskine, med et klart fokus på at søge på beskyttet indhold.

Som modeksempel kan man fremhæve bittorrent protokollen. Det er søgemaskinerne, som thepiratebay.org, der er i problemer. Selve protokollen, programmerne og sider der benytter teknologien til lovlige formål har ingen problemer.

Der er kun tale om eksemplarfremstilling hvis tjenesten gemmer en kopi på serveren. Ellers er der kun tale om midlertidige flygtige kopier, som for eksempel opstår i en switch eller routers ram men filen overføres. Det er eksplicit undtaget i ophavsretsloven.

Så der kan højst være tale om at hjælpe andre med at lave kopier. Og den tror jeg altså ikke på er aktuelt.

Jeg tror slet ikke tjenesten er særlig egnet til piratkopiering og derfor kommer diverse onde trolde fra plade og filmbranchen slet ikke på at sagsøge nogen.

  • 0
  • 0
Jacob Christian Munch-Andersen

Først lav noget der virker og så put sikkerhed på.

I den konkrete problemstilling kan det godt lade sig gøre. Men generelt er det en rigtigt dårlig fremgangsmåde. Hvis du ikke tænker sikkerhed ind når du programmerer så vil det resultere i alverdens former for huller, ofte vil du have brugt fundamentalt forkerte metoder som ikke bare kan lappes men må skrives helt om. Men den diskussion forudsætter at du overhovedet husker at få lavet din sikkerhed, og finder alle de huller du har lavet.

Men din største fejl rent sikkerhedsmæssigt er at du undlader at gå i kødet på din egen applikation, du stiller dig tilfreds med skøn af chancen for at nogen kan få noget ud af et angreb. Frem for at kode så du ved at applikationen er sikker lader du nogle huller være ud fra det skøn at de ikke er store nok til at være praktisk anvendelige. Det er set før, og det er gået galt utallige gange da en hacker alligevel har fundet en praktisk anvendelse. Så er det at man for alvor kan føle sig dum, når en hacker har brugt et hul som man godt vidste var der.

Ingen forlanger at det "endelige" produkt er klart endnu, men når I har valgt at udgive det må man forlange at det virker, og det inkluderer at det er sikkert.

  • 0
  • 0
Yoel Pedersen

Har du selv erfaring med at lave et ApS?

Jeps - det var dog som holdingselskab, og ikke som driftsselskab (selv om der ikke burde være den store forskel, ud over at et driftsselskab bør momsregistreres).

Jeg gav lige knap 5.000 kr. for at få registreret selskabet. Jeg har set priser fra mellem 3.000 kr. og helt op til 12-13.000 kr (i Kbh selvfølgelig). Dybest set virker det besynderligt, at det skal være så dyrt at få en advokat til at vidne på, at man på et givent tidspunkt har haft 125.000 kr. stående på en konto. Teknisk set burde et gratis kontoudtog fra banken være lige så godt. Anyway, det viste sig at advokaten havde skrevet revisionspligt ind i vedtægterne, og jeg fandt først senere ud af at det slet ikke er nødvendigt for mindre selskaber - se http://www.revisionsyddanmark.dk/index.php?p=./modules/article/article&a...

Der skal selvfølgelig stadig laves regnskab osv, men det kan man selv gøre i et egnet bogføringsprogram - og så har man muligheden for at lade sin onkel eller hvem der nu ellers måtte være regnskabskyndig varetage den del, uden at skulle betale for det officielle Statsaut.-stempel.

Lige et par eksempler på hvad en statsautoriseret kan finde på at tage:

Trykning af regnskab (udskrivning af ledelsesberetning m.v. - alt i alt måske 50 ark papir + et par ringbind): 2.500 kr.

Registrering i forb. m. lov om hvidvaskning (revisoren tager et kopi af direktørens kørekort el. lign.): 1.150 kr.

Og så er der naturligvis prisen for selve regnskabet - for et nystartet ApS med 3-4 poster i løbet af første regnskabsår skulle det tilsyneladende koste omkring 8.000 kr. excl. moms.

Selv om jeg ikke er jyde, synes jeg ovenstående priser er helt hen i hegnet, især fordi alle tekster m.v. er standard-tekster, revisoren bruger igen og igen. Konfronteret med spørgsmålet om hvorfor der overhovedet var indskrevet revisionspligt i selskabets vedtægter kunne revisoren ikke give andet svar end "det har man gjort i mange år". Får advokaten mon returkommision fra revisoren?

Nå, anyway, det var en historie fra det virkelige liv, og hvis I har en statsaut. revisor i familien, der vil varetage jeres regnskab, er I jo sikret, men personligt ville jeg nu fravælge revisionspligten alligevel.

  • 0
  • 0
Ulrik Gammelby

Jo, generelt skal sikkerhed tænkes ind fra starten, hvis du vil have et sundt design. Men hvis du sidder to mand i en kælder med en fed ide og skal udnytte den aktuelle opmærksomhed, kan man ikke forvente, der er tid til at lave en tilbundsgående analyse og et skudsikkert design (med mindre sikkerhed selvf. er en core-feature ved dit produkt).

Det er da bedre at komme ud over stepperne, få noget feedback og opmærksomhed og risikere at få en over nallerne end at sidde og polere på noget, som måske kan redde systemet fra et angreb. I det mindste så længe du ved hvor de svage sider er og har en ide om, hvor der kan sættes ind for at udbedre disse.

  • 0
  • 0
Tobias Baunbaek

Det vil være muligt at overføre direkte udenom serveren med IPv6 eller med IPv4 NAT traversal. Dog ikke med javascript+HTML5 - det vil være nødvendigt med java (evt. webstart) eller anden form for applikation. Serveren vil kun have brug for minimal båndbredde for at koordinere overførslen.

Det har du helt ret i. Der er også tjenester som allerede gør dette i Flash. Men der er nogle problemer som vi ikke kan komme uden om.

Det første, og største, er at det kræver noget af vores brugere. Idéen med kkloud er at det skal være nemt og så skal det stort set altid virke (vi er ved at lave en nyere version som måske endda kan køre på ie6). Hvis det krævede installation af noget vil det blive lidt besværligt for nogen, hvilket vi vil undgå.

Et andet problem er at netværksproblemer gør at det bare ikke altid virker. Det kan jeg også læse om er problemet på de Flash-sider som benytter hole punching.

I html5 har der været snak om noget p2p, men så vidt jeg ved er det ikke blevet konkretiseret endnu.

I forhold til jura vil min vurdering (som ikke jurist!) være at der ingen problemer er. Alle de tjenester der har været i problemer har haft en søgemaskine, med et klart fokus på at søge på beskyttet indhold.

Det er også mit bud. Formålet med siden er ikke at dele ulovligt indhold og der er ingen søgemaskine. Så tror jeg bare der skal en del til før man kommer i søgelyset.

  • 0
  • 0
Tobias Baunbaek

Hvad synes I er fair at vi logger på sitet?

Jeg spørger fordi vi selv har haft overvejelserne. Man vil godt kunne lave noget statistik og sige at ens brugere gør "sådan her" eller "sådan her", hvornår de gør det og hvordan. Men på den anden side har vi ikke lyst til at overvåge.

Filnavne, filstørrelser, antal filer, navnet på kkloud, ip... osv. Hvad er fair at kæde sammen?

Mvh
Tobias Baunbæk,
kkloud.com

  • 0
  • 0
Yoel Pedersen

Så lidt som overhovedet muligt.

Overvågning er en grim tendens, og hvis I ønsker en trofast brugerskare er det vigtigt at I tager deres privatliv seriøst. Logning er filnavne bør være 100 % udelukket (desuden siger det ikke nødvendigvis noget om hvad der er i filerne).

Men man kunne forestille sig at I fx loggede hvis en bruger forsøger at gætte sig frem til et navn for at hente en fil, der ikke tilhører ham. Derudover kan I fx logge antallet af samtidige klienter for at kunne bruge det til at måle performance o.l.

  • 0
  • 0
Tobias Baunbaek

Overvågning er en rigtig grim tendens. Grunden til at jeg spørger her i plenum er også fordi vi tager privatlivet meget seriøst og derfor godt kunne tænke os andres holdning til det.

Hvad synes du om at logge filnavne, men ikke logge hvilken ip eller kkloud-navn det kom fra. Således at man ikke kan kæde de to sammen. Og som du selv siger er det kun et navn, så jeg tvivler på at der kommer noget træls jura ind over. Det er kun til statistik.

Sagen er at vi ofte er blevet spurgt "hvad benytter folk det til" - og har ikke noget godt svar. Det er jo lidt en skam.

Mener du at man logger de "angreb" som der bliver forsøgt, for at kunne lave noget statistik over hvor mange der prøver at misbruge det?

Logge antallet af samtidig klienter er en god idé. Den må vi have på :-)

  • 0
  • 0
Claus Stovgaard

Jeg er nok lidt modsat i forhold til mange her.

Jeg vil sige at det ikke er hvor meget i logger som er afgørende, men hvordan der er adgang til loggen, hvem der har adgang til den og hvad den bliver brugt til!

I forbindelse med opklaring af sager, der er underlagt offentlig påtale, her taler jeg ikke om overtrædelse af en eller anden copyright, men meget mere alvorligere sager, vil alt den dokumentation der kan skaffes være en god ting. Gerne komplete session oplysninger for folk der har tilgået den problematiske data.

God fornøjelse med projektet.

  • 0
  • 0
Jacob Christian Munch-Andersen

Jo, generelt skal sikkerhed tænkes ind fra starten, hvis du vil have et sundt design. Men hvis du sidder to mand i en kælder med en fed ide og skal udnytte den aktuelle opmærksomhed, kan man ikke forvente, der er tid til at lave en tilbundsgående analyse og et skudsikkert design (med mindre sikkerhed selvf. er en core-feature ved dit produkt).

Det er da bedre at komme ud over stepperne, få noget feedback og opmærksomhed og risikere at få en over nallerne end at sidde og polere på noget, som måske kan redde systemet fra et angreb. I det mindste så længe du ved hvor de svage sider er og har en ide om, hvor der kan sættes ind for at udbedre disse.

Alt det ævl for at undskylde at der mangler noget så simpelt som en ordentlig tilfældighedsgenerator. Du har fået din feedback, prøv at følge op på den i stedet for at argumentere imod den, ellers holder din virksomhed ikke længe.

  • 0
  • 0
Therese Hansen

Prøv lige at se hvem der står som afsender på den kommentar du citerer - det er ikke Kkloud-folkene, men Ulrik Gammelby.

Derudover kan jeg kun give Ulrik Gammelby fuldstændig ret og ærligt talt Jacob Christian, så synes jeg at du skulle overveje din tone i dine indlæg. Din nuværende tone hjælper ikke på min velvillighed til at overveje om du har en valid pointe.

  • 0
  • 0
Yoel Pedersen

Sagen er at vi ofte er blevet spurgt "hvad benytter folk det til" - og har ikke noget godt svar. Det er jo lidt en skam.

Kunne det så være en løsning kun at logge fil-endelserne? Det vil kunne bruges et stykke ad vejen til at fastslå, om folk bruger tjenesten til billeder, word-dokumenter, film eller noget helt tredie, uden at gå på kompromis med brugernes privatliv (overvej at filnavne ofte indeholder noget ganske sigende om filens indhold - fx "Husven på besøg.avi" eller "Behandling af bændelorm.pdf").

Hvor relevant det er at vide, hvor ofte I bliver angrebet, kan diskuteres, men der er nok ingen tvivl om, at det er ganske rart at vide, hvor I er blevet angrebet fra, hvis uheldet skulle være ude.

Jeg vil sige at det ikke er hvor meget i logger som er afgørende, men hvordan der er adgang til loggen, hvem der har adgang til den og hvad den bliver brugt til!

Det er jeg ikke helt enig i - faktum er, at uanset hvor meget man sikrer sig, vil der altid være en risiko for, at systemets sikkerhed kan brydes. Så medmindre man har en rigtig god grund til at opbevare oplysninger om andre mennesker, bør man undgå at ligge inde med dem.

  • 0
  • 0
Tobias Baunbaek

Har I overvejet hvilke forretningsmodeller der kunne være interessante i forbindelse med Kkloud, Tobias? Eller gør I det bare fordi I kan :-)?

Vi gjorde det fordi vi kunne. Men den periode er efterhånden gået :-)

Nu overvejer vi forskellige modeller. Det næste stykke tid kommer der ikke til at ske alverden på siden, men måske nogle små opdateringer. Vi bruger i stedet tiden på at implementere vores næste større skridt. Her kommer der til at ske nogle ting hvor vi mener vi kan gøre "noget smart" ved måden man sender filer på. Mere om det senere.

  • 0
  • 0
Tobias Baunbaek

Og har I forresten kontakt til nogle interesserede investorer? Har Venture Cup givet nogle gode kontakter?

Ja, vi har snak med nogle stykker allerede. Vi har henvendt os til nogle stykker, men der er også nogen som har henvendt sig til os. Så der er interesse i teknologien og vi prøver at bygge en forretning op omkring det.

  • 0
  • 0
Claus Wøbbe

Stor ros for noget, der ligner en fin service!

En mulighed kunne være: gratis for øjeblikkelig deling, betaling for forlænget "levetid" for filen.
Eller: betaling for indbygget, automatisk kryptering af filen

  • 0
  • 0
Tobias Baunbaek

Kunne det så være en løsning kun at logge fil-endelserne? Det vil kunne bruges et stykke ad vejen til at fastslå, om folk bruger tjenesten til billeder, word-dokumenter, film eller noget helt tredie, uden at gå på kompromis med brugernes privatliv (overvej at filnavne ofte indeholder noget ganske sigende om filens indhold - fx "Husven på besøg.avi" eller "Behandling af bændelorm.pdf").

Hvor relevant det er at vide, hvor ofte I bliver angrebet, kan diskuteres, men der er nok ingen tvivl om, at det er ganske rart at vide, hvor I er blevet angrebet fra, hvis uheldet skulle være ude.

Vi har overvejet lidt som du siger med kun endelserne.

Noget som jeg selv tænker over er hvor vi skal bruge vores kræfter henne - og det er her statistikken skal hjælpe os. Hvis vi f.eks ud fra loggen kan se at de fleste benytter sitet til at dele billeder, så ved vi at vi skal fokusere vores tid på at lave et godt interface til at understøtte dette.

Vi vil bare være sikre på at vores brugere ikke føler sig overvåget. Det er nok ikke så forskelligt fra alle mulige andre sites. Vi logger kun for at kunne gøre tjenesten bedre - og er meget enige om aldrig at kunne kæde filer sammen med kkloud-navne og ip'er.

Det er jeg ikke helt enig i - faktum er, at uanset hvor meget man sikrer sig, vil der altid være en risiko for, at systemets sikkerhed kan brydes. Så medmindre man har en rigtig god grund til at opbevare oplysninger om andre mennesker, bør man undgå at ligge inde med dem.

Jeg er enig med Claus i at det ikke skal være alle som har adgang til loggen.

Samtidig er jeg også enig med det i at det stadig er vigtigt hvad man logger. Det er også rart at høre andres holdninger til dette. Jeg tænker at minimum er at man ikke kan kæde filnavne sammen med personen bag ved. Men som du selv siger kan filnavnet i sig selv have en betydning, så det er måske bedst kun at logge extension.

Så er dette eksempel fra en log ok?

CREATED $id $timestamp
SHARING $id $extension $timestamp
SENDING $id $extension $timestamp
CLOSED $id $timestamp

  • 0
  • 0
Tobias Baunbaek

Stor ros for noget, der ligner en fin service!

Taaark :-)

En mulighed kunne være: gratis for øjeblikkelig deling, betaling for forlænget "levetid" for filen.
Eller: betaling for indbygget, automatisk kryptering af file

De to muligheder du nævner er også noget vi selv har tænkt over, så det er med i vores overvejelser. Levetiden indebærer også at vi begynder at gemme filerne på serveren og det kræver en ændring af infrastrukturen som vi arbejder på i øjeblikket.

Hvad synes du eller andre at det skal koste at man kan gemme en fil på serveren? Og hvordan har man lyst til at det skal foregå? Laver man en bruger og så knytter penge/credits til denne bruger som man benytter når man lader en fil ligge på serveren. Eller skal man betale for hver gang man gør det?

  • 0
  • 0
Frank Olieu

Grunden til at vi lavede det sådan at man selv kan vælge navn er at man har bedre mulighed for at give en url over telefonen. Det er kan være svært med ajfelfju i forhold til abemad.

Det kan godt lade sig gøre at generere tilfældige strenge som er nogenlunde nemme at udtale.
Her er der én der roder med emnet:
http://www.terminally-incoherent.com/blog/2010/05/10/generating-random-p...

  • 0
  • 0
Yoel Pedersen

Så er dette eksempel fra en log ok?

CREATED $id $timestamp
SHARING $id $extension $timestamp
SENDING $id $extension $timestamp
CLOSED $id $timestamp

Den kunne jeg nok godt acceptere ;-)

By the way - når I sammensætter jeres forretningsstrategi, så husk at holde fast i jeres grundidé (at simpelt er bedre) - ellers bliver I bare endnu en rapidshare-lignende side.

Måske I skulle skele lidt til Wikipedias forretningsstrategi? Den består i sin enkelhed af et godt produkt, som mange har gratis glæde af. En gang om året spørger de deres brugere, om de vil donere en slat til holdet bag, og det ser tilsyneladende ud til at løbe rundt. Det har gjort det muligt at køre verdens største online-leksikon helt uden reklamer og spam - og med en kæmpe mængde tilfredse brugere til følge. :-)

  • 0
  • 0
Venligst Slet Min Bruger

Jeg prøvede kkloud.com her til aften, da jeg skulle sende 1.6 GB ferie-billeder til en kammerat.

Det burde ikke være noget problem med min linje (60/60), men den ville ikke hente filen hos min kammerat. Lidt synd. Det virker ellers som et fint koncept.

Istedet brugte jeg http://sprend.se/ - den virkede fantastisk og har ikke throttle på up-/download som mange andre gratis sites har.

Hvis udviklerne fortsat læser med her, så skal jeg gerne opgive det ID jeg brugte, hvis i kan se noget i loggen, om hvad der gik galt.

  • 0
  • 0
Log ind eller Opret konto for at kommentere