Amsterdams bedrijf start dienst voor het veilig opvragen van bestanden

Een Amsterdams ontwerpbureau is een dienst voor het veilig uitwisselen van bestanden gestart. Met SafeRequest kunnen gebruikers veilig bestanden opvragen bij andere gebruikers. Deze bestanden kunnen alleen met een lokale privésleutel geopend worden.

De werking van de dienst is volgens Woost Technologies, het bedrijf achter SafeRequest, vergelijkbaar met betaaldienst Tikkie. Gebruikers kunnen een aanleververzoek voor bestanden aanmaken via de dienst, waarna een unieke link naar een uploadpagina wordt aangemaakt. Die link kan via bijvoorbeeld e-mail of WhatsApp verstuurd worden. De ontvanger kan vervolgens de benodigde bestanden uploaden in een beveiligde omgeving, waarna ze versleuteld worden met een willekeurige 256-bit aes-sleutel, die wordt gegenereerd in de browser van de uploader.

Deze aes-sleutel wordt op zijn beurt versleuteld met de publieke key van een rsa-4096-keypair die bij registratie in de browser van de verzoeker wordt gegenereerd. De versleutelde aes-sleutel kan alleen ontsleuteld worden met de privésleutel van het rsa-keypair. Deze privésleutel wordt lokaal in de internetbrowser van de ontvanger opgeslagen, en dus niet op de servers van SafeRequest. Hierdoor kan Woost Technologies niet bij de privésleutel, en dus ook niet bij de bestanden die geüpload worden.

Sebastiaan de Stoppelaar, co-oprichter van Woost, vertelt aan Tweakers dat het bedrijf bij het maken van deze dienst 'veel heeft gesproken met bevriende privacyadviseurs'. Volgens hem 'blijkt daaruit dat het systeem veilig is'. Dit was als antwoord op de vraag of de dienst securityaudits heeft ondergaan. In de toekomst wil het bedrijf nog proberen officiële keurmerken te ontvangen voor de dienst. Er wordt ook nog gewerkt aan een whitepaper, maar voorlopig staat op de site uitgelegd hoe de encryptie werkt. In de toekomst wil het bedrijf ook de encryptietoepassing open source maken.

De dienst is in principe bruikbaar voor particuliere gebruikers, maar De Stoppelaar vertelt zelf dat het bedrijf 'de meerwaarde ziet voor bedrijven die met gevoelige gegevens werken, zoals hypotheekadviseurs'. De dienst voldoet volgens Woost 'aan de AVG-eisen voor het versturen van persoonlijke gegevens', terwijl e-mail dit niet doet.

De dienst is gratis te gebruiken, maar er zijn Pro- en Premium-varianten beschikbaar voor respectievelijk 19 en 49 euro per maand. De Pro-versie biedt geen limiet aan het aantal verzoeken, waar gratis gebruikers slechts drie openstaande verzoeken kunnen hebben. Ook heeft de Pro-variant geen bewaartermijn voor bestanden, een eigen custom uploadpagina en 200GB opslag tegenover de 2GB voor gratis gebruikers. De Premium-variant hoogt dit op naar 1TB, en maakt het mogelijk om een eigen domeinnaam te koppelen.

Update, 21:21: De titel van het artikel is aangepast om te verduidelijken dat deze dienst bedoeld is voor het veilig opvragen van informatie.

Het bestand kan niet geopend worden op een browser zonder private key

Reacties (77)

[martijntechno]

Er zijn al zo veel tools die dit doen. Zoals ffsend (Rust en door een NLer gebouwd ffsend). En dan hebben ze nog geen keurmerken en whitepaper gepubliseerd. Begrijp niet echt waarom dit dan nieuws is. Zoals al eerder gezegd mega.nz doet dit ook.

En over het email gedeelte is ook niet waar, want dan kan je gewoon PGP gebruiken (maker: Zimmermann werkt aan de TU Delft). Een gebruikers vriendelijkere variant voor PGP is protomail.

[Reactie gewijzigd door martijntechno op 23 juli 2024 14:41]

[Jan-Remco]

Het is wel nieuws, en gezien de reacties hier vooral ook een waarschuwing om het niet te gebruiken
Al had ik die waarschuwing liever in het artikel gezien, een persberichtje overnemen en wat vragen stellen, maar de kritische analyse aan de lezers overlaten, tja.

[DomusCasa]

Voor mijn gevoel (en ik ken niet alle tools die hier aangehaald worden) probeert deze dienst zich te onderscheiden door het het proces om te keren. Je hoeft niet aan een klant te vragen om een veilige dienst te kiezen en daarmee een bestand te versturen, maar stuurt die klant een link waarmee hij of zij het bestand beveiligd naar jou kan toesturen. Als dit ook daadwerkelijk veilig is (waar nu terecht aan wordt getwijfeld) kan dit mijn inziens heel nuttig zijn. Maar nogmaals, ik ken niet alle tools, dus misschien is dit wel een handig iets, maar is het alsnog niet uniek.

[Bonazzo]

Maar nogmaals, ik ken niet alle tools, dus misschien is dit wel een handig iets, maar is het alsnog niet uniek.

Niks unieks - wel handig om te hebben. ZIVVER biedt dit bijvoorbeeld al geruimte tijd aan als toevoeging op een beduidend completere dienstverlening. Zij noemen het een
'Conversatiestarter'. Hier een voorbeeld daarvan (https://www.medlon.nl/contact/) en hier de eigen ZIVVER toelichting: Zie https://www.zivver.eu/nl/blog/conversatiestarter.

Vanuit de NTA7516 wetgeving (zie https://www.zivver.eu/nl/blog/8-feiten-en-fabels-over-de-nta-7516) is een dergelijke functionaliteit zelfs verplicht dus 100% niet onderscheidend en 0 reden om dit charmante '10-in-een-dozijn' initiatief nou te promoten hier op Tweakers.

[nrg]

Hoi, ik ben één van de makers van SafeRequest. Het klopt dat er veel tools zijn om te verzenden,maar voor zover wij weten zijn er nog niet veel (en geen simpele) tools om bestanden te ontvangen. ZIVVER en Skotty bieden inderdaad wel die functionaliteit, maar zijn veel uitgebreider dan SafeRequest. Wij zien SafeRequest meer als een soort 'Tikkie' waar je zonder implementatie- en opleidingstrajecten makkelijk en snel mee aan de slag kunt.

[Reactie gewijzigd door nrg op 23 juli 2024 14:41]

[martijntechno]

Je moet nog steeds een account aanmaken. Je key wordt lekker in je local opgeslagen in je browser. Het hele systeem is nog steeds omslachtig en niet een soort van 'Tikkie'.

Het is ook handig als je ineens naar een andere browser gaat en dan de priv-key op een of andere manier moet bewaren ergens (een backup file unenqrypted op een pc). Of als je een short-cut indrukt die de browser data wist. De hele reden dat PGP email enqryptie nooit echt door geslagen is op de markt, is de key management die een gebruiker moet bijhouden.

En genoeg applicaties zoals eerder genoemde send.firefox.com bestaan. Ik hoop dat de white-paper zich snel gaat melden.

[Reactie gewijzigd door martijntechno op 23 juli 2024 14:41]

[nrg]

Precies zo makkelijk als Tikkie is het nog niet, maar we doen ons best het zo makkelijk mogelijk te maken We hebben nog wel wat ideeën, maar ideeën vanuit hier zijn ook altijd welkom!

Zoals hierboven(/-onder?) ergens aangegeven overwegen we aan te bieden (optioneel) de private key AES-encrypted serverside op te slaan: dan zou de gebruiker de key altijd terug kunnen zetten vanaf de server (en net zoals bij de bestanden: encrypted downloaden, clientside password intypen en clientside decrypten), maar we willen nog even wat meer nadenken of en wat voor downsides daar aan zouden kunnen zitten.

[martijntechno]

Doen jullie aan bug-bounty's

[ArranChace]

Zoiets heb ik al jaren, was ook wel bekend systeem bij menig tweaker
Vermoed een vergeten ouderwets systeem, zo's ftp server met beperkte toegang

Alleen diegene die de link hadden, en het wachtwoord, en de account konden erop, kan in logs precies zien, welk IP, welke tijd en wie wat downloadde..

Maarja, je moet er wel zelf wat voor doen, en volgens mij is dat eigenlijk de enige toevoeging wat zo'n externe dienst als voordeel heeft.

[joenevd]

Net zoals zivver is er ook filecap en die heeft ook een wetransfer oplossing die voldoet aan de avg.

[Cergorach]

Er zijn al zo veel tools die dit doen.

Mijn eerste gedachte was dan ook dat de bedrijfsnaame 'OneOfMany' zou zijn...

[vliegendekat]

En over het email gedeelte is ook niet waar, want dan kan je gewoon PGP gebruiken (maker: Zimmermann werkt aan de TU Delft). Een gebruikers vriendelijkere variant voor PGP is protomail.

Nog beter: Gebruik de AES256 versleuteling van PGP/GnuPG en verstuur de key over een ander veilig kanaal, zoals bijvoorbeeld Signal, of tegenwoordig zelfs WhatsApp.

Dan maakt de gekozen uitwisselingsdienst ook gelijk niet meer uit en kan men ook de hele public/private-sleuteluitwisseling overslaan.

Overigens denk ik dat er maar weinig documenten zijn waarvoor dit niveau van beveiliging echt een vereiste is... Voor veel mensen komt cryptografie namelijk niet heel veel verder dan een speeltje.

[Verwijderd]

Net zoals e2e en password managers via browsers is dit niet helemaal veilig.

Webpagina's worden in basis bij ieder bezoek opgehaald, en kunnen dus ook bij ieder bezoek ineens aangepaste javascript bevatten waardoor de private keys worden geupload. De gebruikte encryptie protocollen zijn hierbij volledig irrelevant.

[The Zep Man]

Dit is het probleem, en de reden dat bijvoorbeeld Signal geen web-interface heeft. Zolang er tussen jou en de ontvanger een man-in-the-middle zit die code kan beinvloeden zal het niet veilig zijn.

Je kan beter kijken naar iets als OnionShare. Ja, de code kan gecompromitteerd zijn, maar het aanvalsoppervlak is een stuk kleiner omdat je niet voor elk gebruik opnieuw de code ophaalt.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 14:41]

[Gropah]

In principe heb je een punt, maar er zijn redelijk wat mechanieken om het veiliger te maken. Alle javascript zelf hosten en een hash includen scheelt al een hoop.

[YopY]

Dat is vooral om wijzigingen 'op de lijn' te voorkomen, dwz, MitM aanvallen; dit wordt deels al door HTTPS afgevangen natuurlijk. Deze techniek is vooral voor 3rd party scripts (bijvoorbeeld jquery van een CDN); jij als consument van zo'n script hebt een hash ervoor berekend op het moment dat je hem in je pagina hangt, zodat het niet meer werkt als een aanvaller dat script (en die versie) vervangt.

Werkt ook wel met je eigen scripts maar daarbij is het ietwat overbodig. Belangrijker dan is dat het releaseproces van de partij die de website onderhoudt hierbij te vertrouwen is.

Zou natuurlijk fijn zijn als je als consument dit zelf kunt beheren, dwz dat je een .js file en / of de bijbehorend webapp kunt locken op een bepaalde versie.

[Theone098]

Eerst viel mij het type bedrijf ("ontwerpbureau") op. Niet echt core business lijkt mij van zo'n bedrijf.
Bij "gesproken met bevriende privacyadviseurs" haak ik af.

Privacy <> Security.

[mschol]

vertelt aan Tweakers dat het bedrijf bij het maken van deze dienst 'veel heeft gesproken met bevriende privacyadviseurs'. Volgens hem 'blijkt daaruit dat het systeem veilig is'. Dit was als antwoord op de vraag of de dienst securityaudits heeft ondergaan.

dat komt een beetje over als vooral geen antwoord willen geven

[timvisee]

Ik zie dan ook niet hoe je zoiets als dit veiliger kan achten dan bijvoorbeeld Firefox Send.

- Informatie over de encryptie methode.
- ffsend: shameless plug naar een zelf ontwikkelde CLI tool voor Firefox Send

[Reactie gewijzigd door timvisee op 23 juli 2024 14:41]

[Dorank]

Dit artikel zelf geeft de werking als:

De ontvanger kan vervolgens de benodigde bestanden uploaden in een beveiligde omgeving, waarna ze versleuteld worden met aes 256-encryptie en naar de aanvrager worden verstuurd.

Deze dienst ziet de bestanden dus unencrypted en is dus onveilig.

https://skotty.io/ is ook een NL dienst en noemen hun product e2e encypted. Geen idee of dat een beter alternatief is.

[Reactie gewijzigd door Dorank op 23 juli 2024 14:41]

[nrg]

Hoi, ik ben één van de makers van SafeRequest. Je antwoord is niet helemaal volledig: naast AES gebruiken we ook RSA. Kortgezegd werkt het proces als volgt:

1. De verzoeker (bijvoorbeeld een notaris) registreert bij SafeRequest. Tijdens de registratie wordt in de browser van de notaris een RSA-4096 keypair gegenereerd. De public key wordt geüpload naar onze server en bij het account opgeslagen. De private key wordt in de local storage van de browser opgeslagen en komt dus niet bij ons.
2. Als de verzoeker een bestandsverzoek stuurt, ontvangt de uploader een unieke link. Met die link komt hij/zij op een speciale uploadpagina voor dat verzoek.
3. Als de uploader een bestand uploadt, wordt er in zijn/haar browser een nieuwe random AES-key gegenereerd. Daar wordt het bestand mee geëncrypt en vervolgens wordt het encrypted bestand geüpload.
4. De random AES-key wordt vervolgens in de browser van de uploader geëncrypt met de *public key* van het RSA keypair van de verzoeker. Daarna wordt de RSA-encrypted AES-key opgeslagen bij het verzoek.
5. Als de verzoeker vervolgens het bestand wil downloaden, wordt de RSA-encrypted AES-key opgehaald van onze server, evenals het AES-encrypted bestand. De encrypted AES-key wordt in de browser van de verzoeker gedecrypt met de private key uit het RSA-keypair, en vervolgens wordt het bestand in de browser met de decrypted AES-key gedecrypt.

Aangezien niemand anders dan de verzoeker de private key heeft, kan niemand anders de encrypted AES-key decrypten, en dus kan niemand anders het bestand decrypten.

[Dorank]

Zorg dan deze info bij de auteur van het artikel komt, dit is immers zoals PKI normaal gesproken werkt. De vraag blijft alleen hoe deze dienst dit gaat bewijzen

Wat er wel nog mist in de besproken werking is het signen door de uploader zodat de ontvanger de bron kan bevestigen.

[nrg]

Dit verhaal staat in iets andere vorm ook op onze site: https://saferequest.net/nl/techniek . Voor de site moeten we een balans vinden tussen technisch juist maar wel begrijpelijk, dat is nog best lastig gezien onze doelgroep. Maar daarom willen we binnenkort ook een whitepaper publiceren voor diegenen die de echte technische achtergrondinfo willen lezen

Signen is inderdaad iets wat hoog op de backlog staat. Dat hebben we in v1 achterwege gelaten omdat dit bij de meest voorname use cases wat ons betreft niet essentieel is (bijv in het geval van een paspoort: mocht de aanleverlink uitlekken, dan kan hooguit een verkeerd persoon z'n paspoort uploaden).

[rolandverh]

Verlies van de machine/browser betekent dat je sleutels verdwijnen.
Je kunt dan niet meer bij je eigen private keys en dus niet meer bij je data.
Misschien wel veilig, maar niet wenselijk.
Export van de keys naar een eigen 'storage' is een oplossing, maar meteen een kwetsbaarheid.

[nrg]

Klopt, omdat wij de private keys niet hebben ligt de verantwoordelijkheid om ze goed en veilig te bewaren bij de eindgebruiker. We overwegen een optie aan te bieden je private key wel (AES-encrypted) serverside op te slaan, maar willen eerst nog even goed nadenken over de eventuele downsides daarvan.

[supersnathan94]

Maar de encryptie vind dus plaats in de browser en niet serverside? Dat is wel belangrijke info die nu mist in het artikel.

[nrg]

Versleuteling en ontsleuteling gebeurt inderdaad in de browser!

[Q]

Waarom wordt het bestand van de zender niet meteen versleuteld met de public key van de ontvanger?

En in hoeverre is 'lawfull intercept' hier relevant?

[Reactie gewijzigd door Q op 23 juli 2024 14:41]

[Alex3]

Ontsleutelen met RSA is erg traag. Daarom waarschijnlijk die tussenstap met AES.

[nrg]

Correct

Iz lawful interception: omdat wij de private keys niet hebben, is het voor ons onmogelijk om de aes-keys te decrypten, en dus om de bestanden te decrypten.

[Reactie gewijzigd door nrg op 23 juli 2024 14:41]

[djc]

De technische informatie-pagina geeft me nog niet erg veel vertrouwen in jullie systeem. "AES" kan allerlei soorten encryptie aanduiden, waarvan sommige bekend staan als onveilig (bijvoorbeeld AES-CTR). RSA is nou ook niet een toonbeeld van moderne encryptie (ik zou eerder EdDSA 25519 gebruiken), en het gebruik van 4096-bit keys wordt door de experts meestal niet aangeraden.

Cryptografische routines in de browser implementeren is vaak maar moeilijk echt veilig te krijgen, zie bijvoorbeeld hier: https://security.stackexc...wser-cryptography-in-2017.

Het opslaan van een long-term private key in local storage klinkt ook als een usability-risico, in de zin dat het me makkelijk lijkt om die key per ongeluk kwijt te raken, waarna de notaris niet meer bij zijn/haar documenten kan komen.

Kortom, ik zou niemand adviseren van jullie systeem gebruik te maken voordat het een audit heeft ondergaan (bijvoorbeeld van Cure53, Radically Open Security of soortgelijke partijen).

[Reactie gewijzigd door djc op 23 juli 2024 14:41]

[Q]

Ik mis ook de expliciete vraag: "kan het bedrijf achter SafeRequests bij de onversleutelde bestanden komen, eventueel op verzoek van de overheid?".

Security van bedrijfsprocessen en procedures
Verder gaat het niet eens alleen om de security van deze web-app maar om de security van het *hele bedrijf*, tot aan de bedrijfscultuur omtrent security.

Hoe zijn de processen en procedures zo ingericht dat niemand bij de klant-data kan komen? Van screenings van personeel, tot vier-ogen princiepes, etc. Wat is het verhaal hier?

[Reactie gewijzigd door Q op 23 juli 2024 14:41]

[Superstoned]

Natuurlijk kunnen ze bij de bestanden, het gebeurt allemaal in de browser met java script die direct van hun server komt. Als een rechter hen dwingt om die java script aan te passen om die private key te uploaden naar de politie dan doen ze dat.

[Ro-Maniak2]

Jawel hoor het antwoord is juist duidelijk: “nee”

[la cucaracha]

'bevriende privacyadviseurs' Mooi dat ze bevriend zijn maar dat zijn niet altijd de meest kritische....
Laat er een bedrijf op los met no-nonsence testmethodes. Als daar een positieve conclusie uitrolt dan heb je technisch 'goud' in handen. Sterkte en wijsheid gewenst iig!

[OxWax]

Inderdaad, ik sprak daar straks ook met een bevriende slager en die garandeert me de kwaliteit van zijn vlees

[spasma]

Dan gaat het moeten gaan om jouw vlees, niet die van de bevriende slager zelf.

Het blijft een beetje een vaag verhaal, dat zeker.

[UPPERKEES]

Hoeveel beter is dat dan SURFfilesender eigenlijk? Of de vele andere alternatieven?

SURFfilesender:
✔ Send files of up to 500 GB
✔ Free for you as a user
✔ Sent via Dutch servers
✔ End-to-end encryption (up to 2 GB)

[nrg]

Hoi, ik ben één van de makers van SafeRequest. Er zijn inderdaad veel tools om bestanden veilig te verzenden, maar niet veel om bestanden veilig te ontvangen. Wij denken dat het laatste relevant is voor doelgroepen als makelaars, hypotheekadviseurs, makelaars et cetera.

[daroger]

als je FileSender zelf installeert, ben jij ook degene die bepaalt wie iets mag uploaden via een unieke url toch?

ps ik ben betrokken bij dit FileSender project

[daroger]

De SURFfilesender is gebaseerd op het FileSender open-source project: https://github.com/filesender/filesender

Dit open-source product wordt door onderzoeksnetwerken over heel de wereld gebruikt. Zie bijvoorbeeld de known installs:
https://github.com/filese...er/docs/known-installs.md

Unieke features:
-integratie met je eigen identity management systeem via SAML
-parallele upload (Gigabit lijnen voltrekken)
-end-to-end encryptie met je eigen password is mogelijk, password moet je out-of-band verstrekken aan ontvanger

[nrg]

Dank voor de links! Ik kende FileSender nog niet maar ga het morgen even goed bekijken

[RobbyTown]

Gebruik nu deze

https://filetransfer.kpn.com/bg/card/upload
Heb je geen account nodig en 4GB
Your files are secured.
Your files will be encrypted before upload

Of is saferequest nog veiliger?

[Caayn]

Misschien leuk voor de geïnteresseerde, whitepaper over de KPN dienst: https://filetransfer.kpn.com/assets/pdfs/whitepaper.pdf

Of is saferequest nog veiliger?

Gezien ze op dit moment weinig informatie en ontwijkende antwoorden geven zou ik het nog even afwachten.

[nrg]

Hoi, ik ben één van de makers van SafeRequest.

Met de dienst van KPN verstuur je bestanden, en krijg je een unieke link om de bestanden mee te downloaden en te decrypten (de decryption key zit in de URL, na de #). Als iemand anders die link te pakken krijgt (bijv uitlekkende email), dan kan die persoon ook bij je 'secure' bestanden.

Bij SafeRequest draaien we het om en stuur je een link om bestanden te uploaden. In die link zit geen key (alleen een obfuscated request ID en een token ter validatie). Als die link uitlekt, lekken er geen bestanden uit, maar alleen de mogelijkheid om bestanden te uploaden. Als een notaris bijv een verzoek om een paspoort verstuurt, ontvangt hij in het ergste geval een paspoort van een verkeerd persoon. Maar in alle gevallen kan alleen de notaris bij de geüploade bestanden (tenzij hij z'n accountgegevens én private key lekt, die verantwoordelijkheid ligt bij hem).

Wat nog niemand heeft benoemd maar wat er bij ons nu nog 'mis' kan gaan is dat de tool gebruikt kan worden voor phishing. Daar zijn we nu mee bezig: dat jij als uploader kan valideren dat een verzoek daadwerkelijk van je notaris komt en dus ook daadwerkelijk alleen door hem ontvangen wordt.

[edit]
Kleine toevoeging op bovenstaande:

Als je met je verzoek bijlages meestuurt, dan zit er bij ons ook een AES-key in de URL (net zoals bij KPN) waarmee de bijlages gedecrypt kunnen worden.

[Reactie gewijzigd door nrg op 23 juli 2024 14:41]

[SinergyX]

Internet Explorer wordt niet ondersteund door SafeRequest.

Leuk als 21% van onze bezoekers nog steeds IE gebruikt.

De dienst voldoet volgens Woost 'aan de AVG-eisen

Voldoet? Vastgesteld door externe audit? Of toch helemaal niet, zoals de website omschrijft?

Ontworpen conform AVG regelgeving
De AVG stelt een aantal eisen waaraan een organisatie moet voldoen als deze met persoonlijke gegevens werkt.
SafeRequest maakt het makkelijker om aan een aantal van deze regels te voldoen.

Voldoet? Nee, het is conform regelgeving, 'aantal van deze regels'. 'Ja volgens mij vriend kan dit'.

[YopY]

Wie zijn "onze" bezoekers? Alle browser share websites die ik bekijk zeggen dat het marktaandeel van IE op dit moment minder dan 3% is (in Nederland); wereldwijd is ie al niet eens meer in de stats op https://gs.statcounter.com/browser-market-share.

maw, je kunt redelijkerwijs aannemen dat je IE support achterwege kunt laten.

[SinergyX]

Bezoekers van onze site, veel kantoorpersoneel blijkbaar met nog IE.

[Kafka]

21% is veel te hoog. Hoogstens 8% en dalende. IE gebruikers moet je als ontwikkelaar 100% negeren.

[morphje]

Heb je enig idee van de inhoud van de AVG? Zo ja, dan weet je dat een "externe audit" niet een van de eisen is. Je moet op papier hebben staan wat je verwerkt, waarom je het verwerkt en of je het soort van zinnig beveiligd. Let wel, je hoeft niet te specificeren HOE je het beveiligd.
In het geval van deze dienst zeggen ze "wij kunnen de inhoud niet zien en wel hierom". In andere woorden: wat wij niet weten kunnen wij ook niet lekken en daarmee is het "gedekt" door de AVG. Sterker nog, ze verwerken helemaal geen persoonsgegevens, ze verwerken onleesbare binaire blobs en die zijn niet gedekt door de AVG.

Dus door bestanden onleesbaar te maken hebben ze geen verplichtingen meer vanuit de AVG. De gebruiker is de (eventuele) verwerker en die dient zichzelf voldoende in te dekken van de kwaliteit van de dienst. Tenzij jij uiteraard meer intieme kennis hebt van de AVG, dan hoor ik graag welk artikel jij denkt dat van toepassing is en waarom.

Oh voordat je verwijst naar de ISO27001, dat is ook een papieren tijger. Er komt een consultant langs, ouwehoert een paar dagen. Kopieert een standaard template en voila je hebt op papier een ISO valide procedure. De auditor neemt de papieren door, stelt een paar vragen en zolang je organisatie maar enigzins zinnig opereert heeft de auditor ook geen bezwaar.

[Despen]

Sowieso altijd bestandje met een wachtwoord lokaal encrypten en het wachtwoord middels ander kanaal opsturen dan de link naar het bestand.

Security werkt met lagen. Hoe meer lagen, hoe veiliger.

[Banpei]

Security werkt met lagen. Hoe meer lagen, hoe veiliger.

Daarom moet je ook altijd triple-DES gebruiken

Iets serieuzer: natuurlijk werkt jouw methode prima voor jouw vrienden/kennissen/etc, maar het idee van de service is natuurlijk om het zo makkelijk mogelijk te maken. Even snel een linkje sturen via Whatsapp en dan bestanden delen, net zo makkelijk als, om Woost te quoten, een Tikkie. Alleen jammer dat Whatsapp weer een NSA backdoor heeft.

[nrg]

[...]
Iets serieuzer: natuurlijk werkt jouw methode prima voor jouw vrienden/kennissen/etc, maar het idee van de service is natuurlijk om het zo makkelijk mogelijk te maken. Even snel een linkje sturen via Whatsapp en dan bestanden delen, net zo makkelijk als, om Woost te quoten, een Tikkie. Alleen jammer dat Whatsapp weer een NSA backdoor heeft.

Hoi, ik ben één van de makers van SafeRequest. Je slaat de spijker op z'n kop Zelf versleutelen is natuurlijk heel mooi en goed, maar voor de gemiddelde persoon is dat veel te ingewikkeld.

[Bundin]

Geen externe audit door een erkende toko? Geen vertrouwen. Op het moment is de mate van veiligheid een wc-eend verhaal (wij zeggen dat anderen zeggen dat het veilig is) , dus commercieel totaal niet relevant/interessant.

Dan liever later de markt op, zonder issues als deze.

[Zenomyscus]

Dan liever later de markt op, zonder issues als deze.

Waarschijnlijk helemaal niet dan. Zoiets kost bakken met geld. Zeker als er nog veel ontwikkeld wordt. Als het product niks wordt heb je duizenden euro's uitgegeven voor niets. Maar er zullen nu zeker minder mensen het product gaan gebruiken door het ontbreken van die scan. Als startup is het lastig om dergelijke dingen te financieren.

[CyBeRSPiN]

Hoe verschilt dit van https://mega.nz? Die doen volgens mij ook encrypten aan de client kant: https://help.mega.nz/webc...-does-the-encryption-work

[The_Greater]

Kijk maar eens naar https://filecap.com
Deze beschikt over veel meer functies.

[fanSte]

Dat vroeg ik me ook af...

[Indir]

"The website and service was launched on 19 January 2013, by Kim Dotcom, who had founded the now-defunct service Megaupload. However, in 2015 Kim Dotcom disassociated himself from the service and stated that the New Zealand government had seized the shares of a Chinese investor and has control of the site. Mega Limited responded that the authorities have not interfered with its operations."
Bron

[CyBeRSPiN]

Ik doelde op het concept. Dat het hier een NL bedrijf betreft is natuurlijk een belangrijk verschil.

[Indir]

Ik begreep je initiële vraag en intentie maar was even vergeten te vermelden waar ik op doelde, namelijk dat het misschien alsnog verstandiger is om gebruik te maken van een bedrijf dat gebonden is aan de Europese en Nederlandse wetgeving. In plaats van een mogelijk dubieus bedrijf dat voorheen banden had met Kim, Chinezen en nu zelfs de Nieuw-Zeelandse overheid die het zelf ook niet te nauw neemt om een heel bedrijf (het voormalige Megaupload) om zeep te helpen wanneer de FBI daartoe een verzoek indient.

[Indir]

Zie mijn nieuwe reactie.

[jpfx]

Ok, dat snap ik. Maar waar het mij om ging is hetgeen de veiligheid in grote mate bepaald niet zozeer de locatie of leverancier is, maar vooral ook de mogelijkheid op controle van code en algoritme. Beter een controleerbare Chinese encryptie dan een oncontroleerbare Nederlandse encryptie.

[nrg]

Hoi, ik ben één van de makers van SafeRequest. Alle encryptie gebeurt in de browser in de Javascripts en is dus op zich al te controleren, maar omdat we begrijpen dat minified Javascript niet zo lekker leest, zetten we die code binnenkort ook op Github. En dan mag iedereen erop schieten want daar leren wij alleen maar van!