Pastebin-variant slaat data op met aes256-versleuteling
Een ontwikkelaar heeft in antwoord op de aankondiging dat Pastebin geplaatste inhoud actiever gaat controleren, het versleutelde Zerobin ontwikkeld. Tekst die op Zerobin wordt geplaatst zal automatisch met aes256 worden versleuteld.
Zerobin stelt dat Pastebin, dat regelmatig door hackers wordt gebruikt om database-dumps online te zetten, door zijn opzet wel genoodzaakt is om content actief te controleren omdat alle data op het platform zonder enige vorm van encryptie wordt opgeslagen. Zou Pastebin geen of onvoldoende controle toepassen, dan zou de site aansprakelijk gesteld kunnen worden als er gevoelige informatie wordt geplaatst. Bovendien vreest de ontwikkelaar van Zerobin voor toenemende censuur op Pastebin.
Het mechanisme dat Zerobin - momenteel als alfaversie beschikbaar - heeft ontwikkeld, moet het 'Pastebin-probleem' verhelpen. Een tekstbestand dat op de site wordt geplaatst, zal automatisch worden gecomprimeerd en versleuteld. Dit gebeurt client-side: de browser zal met behulp van enkele javascript-libraries de data comprimeren en versleutelen met het aes256-algoritme. Vervolgens genereert Zerobin een url waarin naast de locatie van de tekst ook de benodigde sleutel is te vinden. De tekst kan alleen op Zerobin leesbaar gemaakt worden als de url zowel de locatie als de sleutel bevat, waarbij opnieuw de browser de data zal ontsleutelen.
Door de encryptieslag in de browser heeft Zerobin naar eigen zeggen geen enkele mogelijkheid om de content op zijn server te kunnen inzien. Daarmee zou geposte data niet alleen veilig zijn mocht de server gekraakt worden, maar de beheerders zouden mogelijk ook niet gedwongen kunnen worden om de inhoud actief te controleren omdat zij deze niet kunnen lezen. Zerobin kent echter ook enkele nadelen: de site werkt niet in browsers waarin javascript is uitgeschakeld en het systeem is niet bestand tegen man-in-the-middle-aanvallen.
De broncode van Zerobin zal worden vrijgegeven, waardoor andere websites ook van het opensourceplatform gebruik kunnen maken. Daarnaast zegt de ontwikkelaar dat hij bezig is om Zerobin ook te voorzien van syntax highlighting en wachtwoordbeveiliging.
Reacties (60)
Klinkt niet verkeerd, maar dat betekent dus ook dat straks niet zoals nu bij pastebin iederen zomaar alles kan meelezen en de database dumps dus ook een stuk minder aantrekkelijk worden om te posten.
Waarom moeten die gepost worden. Informatie van onschuldige mensen op internet plaatsen?
Ik zeg niet dat die gepost moeten worden, daar ben ik overigens volledig tegen!
Alleen proef ik uit het artikel dat dit wel een van de redenen is om dit type systeem te bouwen om dit soort gebruikers (hackers) toch van een platform te voorzien waar pastebin deze inhoud filtert.
Alleen proef ik uit het artikel dat dit wel een van de redenen is om dit type systeem te bouwen om dit soort gebruikers (hackers) toch van een platform te voorzien waar pastebin deze inhoud filtert.
Deze mooie encryptie maakt het posten van illegaal materiaal natuurlijk wel erg makkelijk - niemand die er achter kan komen tenzij de URL ergens wordt gelekt! Ik weet niet hoe groot de bestanden mogen zijn, maar met wat usenet achtige technieken (uuencode?) is het natuurlijk prima mogelijk ook plaatjes in text formaat op te slaan - een nieuwe KP-uitwissel platform?
Dat is mogelijk bij alles wat tekstuitwisseling mogelijk maakt..
Waarom niet? Het helpt blijkbaar niet om bedrijven aan te schrijven dat ze iets aan hun beveiliging moeten doen. Dan maar aan de schandpaal. En tja, in elke strijd vallen onschuldige slachtoffers anders is er namelijk geen strijd. Helaas leven we niet in een perfecte wereld dus moet er soms weleens worden opgetreden om iets te veranderen.
Vooral Nederlanders hebben blijkbaar nog steeds de illusie dat ze de wereld vanuit hun luie stoel kunnen veranderen en dat iedereen lief voor elkaar is. Helaas zullen ze toch eens met hun luie geraamte uit die luie stoel moeten komen en beseffen dat ze de wereld alleen kunnen veranderen als ze zelf actief er iets aan doen.
Vooral Nederlanders hebben blijkbaar nog steeds de illusie dat ze de wereld vanuit hun luie stoel kunnen veranderen en dat iedereen lief voor elkaar is. Helaas zullen ze toch eens met hun luie geraamte uit die luie stoel moeten komen en beseffen dat ze de wereld alleen kunnen veranderen als ze zelf actief er iets aan doen.
Eens.
Bovendien: de gegevens lagen dus kennelijk al op straat... Alleen is het op pastebin, door verspreiding via meer toegankelijke media, kenbaar aan een groter publiek.
Bovendien: de gegevens lagen dus kennelijk al op straat... Alleen is het op pastebin, door verspreiding via meer toegankelijke media, kenbaar aan een groter publiek.
[Reactie gewijzigd door gevoelig op 16 april 2012 08:19]
Jawel, de linkjes naar zerobin bevatten namelijk altijd ook de sleutel 
het enige verschil is dat zerobin niet zelf moet zoeken naar illegale inhoud...
ze zullen echter nog steeds takedown requests krijgen, daar ben ik zeker van...
gewoon een url met de key erbij en dan is het werk hetzelfde...
ze moeten niet denken dat hun oplossing zaligmakend is ... het maakt het gewoon iets lastiger, maar verre van onmogelijk om takedown requests te moeten opvolgen...
ze zullen echter nog steeds takedown requests krijgen, daar ben ik zeker van...
gewoon een url met de key erbij en dan is het werk hetzelfde...
ze moeten niet denken dat hun oplossing zaligmakend is ... het maakt het gewoon iets lastiger, maar verre van onmogelijk om takedown requests te moeten opvolgen...
Nee je mist het punt. Tuurlijk krijgen ze een takedown request, maar dit krijgen ze pas _nadat_ de text gepubliceerd is. Eer dat her takedown request is ingediend is de betreffende text al lang en breed een eigen leven aan het leiden op het internet.
Daar boven op kunnen ze niet gedwongen worden de content te filteren (zelfcensuur) omdat ze het ook niet kunnen lezen.
Anti-censuur dus. Geweldig!
Daar boven op kunnen ze niet gedwongen worden de content te filteren (zelfcensuur) omdat ze het ook niet kunnen lezen.
Anti-censuur dus. Geweldig!
Totdat er wetgeving komt die juist dit verbiedt: Het opslaan van onbekende data van (onbekende?) herkomst.
Maar dan hebben we een heel andere discussie.
Eigenlijk zou het uitgangspunt moeten zijn dat data een eigenaar heeft. Hier heb je te maken met data die aan de eigenaar onttrokken is.
Maar dan hebben we een heel andere discussie.
Eigenlijk zou het uitgangspunt moeten zijn dat data een eigenaar heeft. Hier heb je te maken met data die aan de eigenaar onttrokken is.
Veel informatie is al beschermd door het auteursrecht of vergelijkbare intellectuele eigendomsrechten. Die geeft de eigenaar het recht om controle uit te oefenen over de informatie. Veel eigenaren proberen nu partijen die faciliteren bij de doorgifte van informatie de verplichting op te leggen om alle informatie vooraf te controleren. Zie bijvoorbeeld de recente kwesties tussen Ziggo/xs4all en Brein met betrekking tot TPB. Deze controle vooraf is op deze manier technisch feitelijk onmogelijk gemaakt. Het zorgt er dus voor dat het gangbare notice and take-down principe niet verder ten gunste van de rechthebbende kan worden uitgebreid.
Ligt er aan of de uploader de key verspreid.
Zo te zien zit hij gewoon in een url, dus zo moeilijk is het niet om daar een korte url van te maken en op twitter te zetten.
Dit is echt alleen om de hoster te beschermen, maar of het juridisch stand houdt?
Zo te zien zit hij gewoon in een url, dus zo moeilijk is het niet om daar een korte url van te maken en op twitter te zetten.
Dit is echt alleen om de hoster te beschermen, maar of het juridisch stand houdt?
[Reactie gewijzigd door Soldaatje op 15 april 2012 15:53]
Als de key in de URL zit dan krijgt de server de key ook. Immers tijdens een HTTP get de gehele path van een URL meeverzonden.
En laat nou ook zo zijn dat de meeste http server software ook default logging aan heeft staan waarin je kan zien welke URL op welk tijdstip door welk IP adres is opgehaald.
Dus het lijkt me niet als hij juridisch veilig wilt zitten als hoster dat de key van de geencrypte data in de URL zit...
@ T_E_O
Oh ja, ff vergeten dat het fragment part niet meegezonden naar de server werdt.
voorbeeldje
En laat nou ook zo zijn dat de meeste http server software ook default logging aan heeft staan waarin je kan zien welke URL op welk tijdstip door welk IP adres is opgehaald.
Dus het lijkt me niet als hij juridisch veilig wilt zitten als hoster dat de key van de geencrypte data in de URL zit...
@ T_E_O
Oh ja, ff vergeten dat het fragment part niet meegezonden naar de server werdt.
voorbeeldje
Houd alleen niet tegen dat diegene de service gaan gebruiken een bezoekje van de politie kunnen verwachten om zodoende de key te verkrijgen...~$ sudo nc -l -p 1000
GET /secured?key=woot HTTP/1.1
Host: localhost:1000
Connection: keep-alive
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.79 Safari/535.11
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,nl;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
[Reactie gewijzigd door Phoenix_the_II op 15 april 2012 16:16]
De key zal als anchor in de URL worden opgenomen, dus achter een #-teken. Zodoende komt dit gedeelte van de URL niet op de server aan en krijgt de hoster niet zomaar de key in handen.
Als je de encryptiesleutel als anchor meestuurt (het deel achter # in een URL) dan krijgt de server die sleutel niet te zien, want anchors worden niet meegestuurd in het HTTP-request. Vandaar dat je javascript ingeschakeld zal moeten hebben: met javascript kan wel de anchor worden opgevraagd en daarmee dus de encryptiesleutel om het bestand te decoderen.
En hoe laat je anderen dan weten wat de key is? Anders heeft iets op Zerobin plaatsen geen enkele zin.Als je de encryptiesleutel als anchor meestuurt (het deel achter # in een URL) dan krijgt de server die sleutel niet te zien, want anchors worden niet meegestuurd in het HTTP-request. Vandaar dat je javascript ingeschakeld zal moeten hebben: met javascript kan wel de anchor worden opgevraagd en daarmee dus de encryptiesleutel om het bestand te decoderen.
Die staat in de URL die je verspreid.
http://sebsauvage.net/pas...uSU1w7epl3+jHA1k3nNWgUo5M=
Zoals dit. En de anchor staat duidelijk in de url.
Zoals dit. En de anchor staat duidelijk in de url.
Verschil is echter dat Zerobin het encrypted ontvangt, opslaat en vervolgens dat ook zo doorgeeft aan de browser. De browser vertaald het dan weer naar leesbare tekst.Klinkt niet verkeerd, maar dat betekent dus ook dat straks niet zoals nu bij pastebin iederen zomaar alles kan meelezen en de database dumps dus ook een stuk minder aantrekkelijk worden om te posten.
Hierdoor is Zerobin juridisch gezien niet verantwoordelijk meer voor het openbaren van bepaalde informatie, zij hebben het ten eerste encrypted gekregen en ook zo opgeslagen.
De browser vertaald het dan weer naar leesbare tekst. Hierdoor is het onmogelijk om er op te modereren zoals dat bij Pastebin momenteel wél kan.
Je kunt voor deze functionaliteit binnen de korste keren wel een Greasemonkey (of dergelijks) verwachten voor Pastebin.
[Reactie gewijzigd door CptChaos op 15 april 2012 16:50]
Vrees er wat voor of dit juridisch zo effectief gaat zijn.
Zerobin maakt een link met locatie en wachtwoord. Dus als dat geshared wordt, kan iedereen het bestand lezen (wat de bedoeling is).
Maar als het om een bestand gaat dat bijvoorbeeld op PasteBin moet verwijderd worden, dan kan dat op Zerobin toch ook? De locatie van het bestand staat gewoon in de url, dus ze kunnen het gewoon via FTP van hun server weggooien. Inkijken kan dan misschien wel niet, maar als iedereen het gaat gebruiken zoals ze PasteBin gebruiken, is het voor de hoster net hetzelfde.
Zerobin maakt een link met locatie en wachtwoord. Dus als dat geshared wordt, kan iedereen het bestand lezen (wat de bedoeling is).
Maar als het om een bestand gaat dat bijvoorbeeld op PasteBin moet verwijderd worden, dan kan dat op Zerobin toch ook? De locatie van het bestand staat gewoon in de url, dus ze kunnen het gewoon via FTP van hun server weggooien. Inkijken kan dan misschien wel niet, maar als iedereen het gaat gebruiken zoals ze PasteBin gebruiken, is het voor de hoster net hetzelfde.
Hier heb je het over een passief mechanisme. Als de hoster een seintje krijgt dat een bestand illegaal is, kan het verwijderd worden. Met actief wordt bedoeld dat een hoster zelf bestanden gaat controleren en niet alleen reageert op een klacht.
Hier kan nog wel eens iets leuks achterweg komen. Stel je voor dat een hoster een takedown-verzoek krijgt voor een bepaald bestand. Hij kan dat verzoek niet controleren omdat hij de inhoud van het bestand niet kan zien. Ik kan me voorstellen dat een hoster daarom maar niet zomaar bestanden gaat verwijderen, de klagende partij zal dan echt iets van bewijs moeten gaan leveren dat die link illegaal materiaal bevat. Ik ben heel benieuwd...
Als ie de url opent die in het takedownrequest staat ziet ie het gewoon net als een ieder ander. Hij zal alleen niet zonder verzoek in actie komen. Straks gaat het allemaal zoals Silkroad via Tor, en worden de takedown verzoeken met de rest van de spam verwijderd.
Het verzoek zou kunnen komen van een autoriteit, een instantie die aangewezen is en daarmee bevoegd is die take-down opdrachten te geven. Dan hoeft er geen bewijs meer geleverd te worden.
Het zou kunnen dat bij het leveren van een dienst (zoals zerobin) het verplicht wordt een interface naar zo'n autoriteit aan te leveren die zelf de take-downs kan registreren en automatisch laten uitvoeren.
Het zou kunnen dat bij het leveren van een dienst (zoals zerobin) het verplicht wordt een interface naar zo'n autoriteit aan te leveren die zelf de take-downs kan registreren en automatisch laten uitvoeren.
Iets verwijderen op last van de rechter, of eventueel op verzoek van een rechthebbende, is nog altijd minder ingrijpend dan actief controleren en censureren. Ik denk dat je het meer moet zien als een significante verbetering en niet zozeer als een perfecte oplossing.
Volgens mij verschuift jurisich nu de verantwoordelijkheid naar degene die de link plaatst. De link plaatsen is nu de openbaar maken actie geworden. De data is immer zonder de (http) link onmogelijk te lezen. de link bevat immers de decryptie sleutel.
Mensen die zich tot zover verborgen hebben achter het feit dat links plaatsen niet verboden is komen dus nu opeens in een ander daglicht te staan. De link bevat immers de enige manier hoe het openbaar gemaakt is. Je kunt er op geen andere manier komen.
Meest interresante onderdeel: hoe komt google dan vervolgens weg met links naar die site?
Mensen die zich tot zover verborgen hebben achter het feit dat links plaatsen niet verboden is komen dus nu opeens in een ander daglicht te staan. De link bevat immers de enige manier hoe het openbaar gemaakt is. Je kunt er op geen andere manier komen.
Meest interresante onderdeel: hoe komt google dan vervolgens weg met links naar die site?
Volgens mij laat Google het Fragment identifier niet zien in de zoekresultaten, althans ik ben ze nog nooit tegen gekomen (tenzij het als hash-bang (#!) voor ajax-state gebruikt wordt). Mocht Google dus links naar bijvoorbeeld ZeroBin laten zien, dan mist de decryptie sleutel, waardoor de link waardeloos is. Google kan dan niet verantwoordelijk gehouden worden voor het verspreiden van de desbetrefende link, aangezien je er niks mee kan.
[Reactie gewijzigd door ThomasG op 15 april 2012 18:31]
Eigenaardig concept, mogelijk zouden ze het niet zelf moeten controleren, maar ze kunnen waarschijnlijk wel alsnog gevraagd worden een bestand offline te halen.
Dit geeft natuurlijk wel een soort semi-veiligheid, iemand hoeft alleen de url te achterhalen om bij een bestand te komen, dus de encryptie is echt puur zodat ze moeilijker aan te klagen zijn. Ik ben erg benieuwd hoe een rechter hierover denkt, want het opslaan van de url is voor zerobin waarschijnlijk geen enkele moeite, waardoor de bestanden niet echt onleesbaar zijn.
Dit geeft natuurlijk wel een soort semi-veiligheid, iemand hoeft alleen de url te achterhalen om bij een bestand te komen, dus de encryptie is echt puur zodat ze moeilijker aan te klagen zijn. Ik ben erg benieuwd hoe een rechter hierover denkt, want het opslaan van de url is voor zerobin waarschijnlijk geen enkele moeite, waardoor de bestanden niet echt onleesbaar zijn.
Zoals ik het begrijp:
- Aanpassing -
Zoals T_E_O opmerkt komt alles achter een # niet aan op de server dus daar kan de sleutel worden gezet. Neemt niet weg dat met een simpele pingback de locatie van de gepubliceerde url kan worden gevonden en daarmee ook de anchor.
- De uploader versleuteld zelf zijn bestand en krijgt een url naar het geuploade bestand op Zerobin waar tevens de sleutel in zit. Deze url publiceert de uploader op de twitterblogwebs.
- Bezoekers klikken er op en komen bij het versleutelde bestand op de site van Zerobin.
- De webserver van Zerobin krijgt de gebruikelijke html headers binnen van de bezoeker, waaronder een eventuele referrer en uiteraard de beklikte url. Waarin dus de sleutel zit.
- Aanpassing -
Zoals T_E_O opmerkt komt alles achter een # niet aan op de server dus daar kan de sleutel worden gezet. Neemt niet weg dat met een simpele pingback de locatie van de gepubliceerde url kan worden gevonden en daarmee ook de anchor.
[Reactie gewijzigd door Kalief op 15 april 2012 16:16]
Zoals in de afbeelding uitgelegd staat, gebeurd de versleuteling in de browser. Dat zal ook de reden zijn waarom javascript moet aanstaan.
Nee, zoals in de afbeelding te zien is wordt de sleutel als een Fragment identifier meegeven, namelijk na de #. In het HTTP protocol is Fragment identifier puur client side, en wordt helemaal niet eens opgenomen in de HTTP header.
Het valt met javascript wel uit te lezen, en via een ajax request op de server op te slaan, maar ik denk niet dat ze dit zullen gaan doen.
Het valt met javascript wel uit te lezen, en via een ajax request op de server op te slaan, maar ik denk niet dat ze dit zullen gaan doen.
Je zou anders nog twee hosters kunnen nemen. Als je data uit N bits bestaat, dan sla je N random bits bij de ene hoster op en de paarsgewijze XOR van deze bits met je data bij de andere hoster. De twee individuele hosters hebben dan vervolgens data waar absoluut geen structuur in zit. Echter, als je beide combineert door weer de XOR te nemen dan krijg je wel de oorspronkelijke data terug.
Uiteraard, je moet nog steeds ergens de links naar deze twee hosters hebben, en er kan dus geklaagd worden op de plaats waar je deze aanbiedt.
Uiteraard, je moet nog steeds ergens de links naar deze twee hosters hebben, en er kan dus geklaagd worden op de plaats waar je deze aanbiedt.
Ik lees het zo:
De sleutel staat dus op je eigen PC. (Bijvoorbeeld in mapX).
En als ik het goed lees wordt alles encrypted en decrypted op je eigen PC.
Het opgeslagen bestand op Zerobin bevat behalve de encrypted gegevens alleen een verwijzing naar de lokatie van mapX.
Als je de sleutel op een andere PC wilt gebruiken moet je niet alleen de sleutel hebben, maar ook de sleutel op dezelfde lokatie plaatsen dus moet je een mapX aanmaken en daar dus de sleutel naar toe kopieren.
(tenzij ze een mogelijkheid inbouwen, om indien de sleutel ontbreekt, op te geven waar de sleutel dan wel staat op je PC, en/of een default map op te geven waar alle sleutels staan)
De sleutel staat dus op je eigen PC. (Bijvoorbeeld in mapX).
En als ik het goed lees wordt alles encrypted en decrypted op je eigen PC.
Het opgeslagen bestand op Zerobin bevat behalve de encrypted gegevens alleen een verwijzing naar de lokatie van mapX.
Als je de sleutel op een andere PC wilt gebruiken moet je niet alleen de sleutel hebben, maar ook de sleutel op dezelfde lokatie plaatsen dus moet je een mapX aanmaken en daar dus de sleutel naar toe kopieren.
(tenzij ze een mogelijkheid inbouwen, om indien de sleutel ontbreekt, op te geven waar de sleutel dan wel staat op je PC, en/of een default map op te geven waar alle sleutels staan)
Ik vrees dat je het niet helemaal begrepen hebt. Er wordt door zeroBin alleen je file ge-encrypt met een random key. Je kan door te navigeren naar domain.com/zerobin/?id_van_je_upload#decryptie_key de gedecrypte versie opvragen.
Leuk bedacht, maar de laatste jaren hebben rechters meermaals aangetoond dat ze niet van dit soort slimme truukjes houden en er geen enkel probleem mee hebben een vonnis uit te spreken waarmee een site of bedrijf feitelijk om zeep wordt geholpen.
Ik ben benieuwd hoe lang zerobin het vol gaat houden.
Ik ben benieuwd hoe lang zerobin het vol gaat houden.
Dat idee had ik ook:
Zerobin: "tja, wij kunnen de inhoud niet screenen, want hebben geen sleutel"
Rechter: "en wie heeft die sleutel dan wel, en wie heeft die sleutel gegeven?"
Zerobin: "eh... wij... maareh...maareh..."
Kan je wel volhouden dat je de sleutel niet zelf opslaat, maar dit voelt overduidelijk als een truc om de rechtbank te misleiden.
Zerobin: "tja, wij kunnen de inhoud niet screenen, want hebben geen sleutel"
Rechter: "en wie heeft die sleutel dan wel, en wie heeft die sleutel gegeven?"
Zerobin: "eh... wij... maareh...maareh..."
Kan je wel volhouden dat je de sleutel niet zelf opslaat, maar dit voelt overduidelijk als een truc om de rechtbank te misleiden.
Ze maken de sleutel niet zelf (dat doet de browser van de bezoeker) en ze slaan de sleutel zelf niet op. Dat is gewoon mogelijk, dus Zerobin kan terecht vermelden dat ze de sleutel niet weten.
Wat dat betreft is het vrijgeven van de broncode ook een goede zaak omdat het mogelijke twijfels weg kan nemen. Al is de clientside code natuurlijk altijd al door te lezen om te kijken of de sleutel toch naar de server gestuurd wordt.
Wat dat betreft is het vrijgeven van de broncode ook een goede zaak omdat het mogelijke twijfels weg kan nemen. Al is de clientside code natuurlijk altijd al door te lezen om te kijken of de sleutel toch naar de server gestuurd wordt.
[Reactie gewijzigd door dcm360 op 15 april 2012 17:47]
Helaas zal een rechter daar waarschijnlijk geen boodschap aan hebben, die zal zeggen: Zorg maar dat je de berichten controlleerd, hoe je dat doet is jouw probleem.
Dat wordt dan een mooie rel, want in feite zegt de rechter op dat moment dat het product dat Zerobin aanbiedt illegaal is. Overigens zal daar dus ook uit afgeleid kunnen worden dat als ik een TrueCrypt-container opsla bij een clouddienst, dat de clouddienst de inhoud ervan zal moeten controleren. Nou, ik wens ze succes 
Om nog even op de broncode terug te komen. Deze is al in te zien op de bijbehorende wiki.
Maar komt het er dus op neer dat niet iedereen meer de geposte content kan zien? Als dat het geval is ben ik het eens met wat hier eerder gezegd werd en zal dit niet veel gebruikt gaan worden aangezien dan toch niemand het kan zien.
Je kan het alleen zien met de juiste decryption key, en die krijg je via de URL na het plaatsen van je paste.
Zodra je de URL verliest, is het niet meer mogelijk om de data op te halen.
Zodra je de URL verliest, is het niet meer mogelijk om de data op te halen.
Nadeel is wel dat google de data ook niet meer kan lezen, en de pastes dus ook niet meer gevonden kunnen worden via google. (Google voert volgens mij geen javascript uit.)
[Reactie gewijzigd door pvcholten op 15 april 2012 20:38]
Niet per definitie, aangezien de meeste gebruikers van pastebin helemaal niet willen dat hun data geindexeerd wordt door google. Je zou het dus ook als een feature kunnen zien.
Waarom zou je willen dat Google zoiets (ook) indexeert? Het wordt niet voor niets encrypted naar Zerobin verstuurd.Nadeel is wel dat google de data ook niet meer kan lezen, en de pastes dus ook niet meer gevonden kunnen worden via google. (Google voert volgens mij geen javascript uit.)
Gaan we dan nu een brein-crawler krijgen die wel deze indexen opbouwt?
Op dit item kan niet meer gereageerd worden.
Onderwerpen
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
