Show HN: SlikSafe – A decentralized, end-to-end encrypted alternative to Dropbox
We are the team behind Slik.
Over the past year, we have been hacking on SlikSafe [1] a Dropbox alternative where all your data is first encrypted on your own device and then stored on decentralized storage.
Some features we're most excited about are -
- multi-device data sync,
- auto-backups via desktop apps,
- search your docs by name or contents with end-to-end encryption,
- easy sharing via email, QR-code or private-link,
- Password-less login using MetaMask/Phantom
You can use our web app [2] and macOS app [3] today. Our desktop app for Windows is currently in beta, and will be launched in early Jan.
You can read our WhitePaper [4] for the technical implementation, or see a quick demo [5] of the product.
Would love to hear what you think.
Arpit, Charvi
[1] SlikSafe: https://www.sliksafe.com
[2] Web app: https://app.sliksafe.com
[3] macOS app: https://sliksafe.com/downloads
[4] WhitePaper: https://sliksafe.com/whitepaper.pdf
[5] Demo video: https://www.loom.com/share/abe133c4ce874655a952a30601e99408
193 comments
[ 2.4 ms ] story [ 231 ms ] threadFeel free to read more implementation details in our WhitePaper - https://sliksafe.com/whitepaper.pdf
(A malicious employee could do such a thing, or you could be legally obligated to do so in order to continue operating in certain jurisdictions.)
How do you prevent yourself from serving a compromised iOS/Android/Mac/Windows app? Same answer.
For app store based distribution, the developers can set up a deterministic build, and end users can verify the checksum of the package matches the developer’s published source code (signal supports this).
Additionally, a regular app can be signed by a key from the developers that you can verify. With a web app you don't even know if it comes from the developers or if you're being MITM-ed because someone managed to get a SSL certificate for your domain. The certificate isn't the only angle of attack either, your CDN or hosting provider might be hacked. Yes the CDN that hosts the regular app can also be hacked, but that will only work against brand new users, because existing users can already know the signing key and the hacked binary won't have the correct signature.
The keywords (along with other file metadata) are also encrypted using the user's key, so analyzing access patterns of the chunks, would not be possible for us.
The encrypted file metadata (and the search indices) are downloaded at once. It is then decrypted using the user's key on device. The user then performs a client side search to get the relevant file-ids. The file-ids are then used to retrieve retrieve the file from the decentralized storage.
Not that every leakage is critical, for example if you write chunks when the user uploads a file the client just leaked that an upload happened, it also leaked how much data was written. Depending on the use case this might not lead to sensitive information leakage. It however might, for example if a hospital has an app that let's you download information about your disease an adversary could leak which disease you have without compromising the encryption.
The most advanced technique of hiding which chunks are accessed, or whether they are written or read is called ORAM. ORAM makes chunk accesses indistinguishable, however this technique has a logarithmic overhead, it fails to hide how many chunks are accessed, and it is also hard to design a search protocol on top of it that does not create patterns in the ORAM accesses, which can be also analyzed.
A practical solution is a search protocol that tries to decouple the results from the accesses.
https://www.researchgate.net/publication/356077294_Access_Pa...
This paper is just an idea, I'm designing a different protocol that is more efficient, but requires persistent client cache, which is just becoming a reality for web clients.
Until you all are coerced by some legal authority to code a passphrase intercept into the client ala ProtonMail, right?
We're using Storj and IPFS as the only storage layer behind user data, not as a CDN.
If a passphrase was lost, the security of every past file would be at risk.
This is what has kept me from approaches like this in the past.
For me the problem with IPFS is - it is just not interesting enough. It's not a storage solution, it is distribution and caching mechanism. You can't really upload to IPFS, you can only publish via IPFS - the same way you publish via HTTP.
I looked at this briefly for a security module for my MSc and from what I vaguely recall they were tapping roughly half of all data going through AT&T on the West coast
Hopefully, though, they unpin it.
I think the bigger problem is that both iOS and Android are doing everything they can to deprecate the concept of a filesystem. Android has a history of killing filesystem features, receiving tons of developer backlash, and then hacking in workarounds with reduced performance. I think the writing is on the wall.
In my experience, porting general purpose tools to Android is a nightmare.
Hopefully something like pinephone gets good enough before things are too bad.
[1] https://github.com/termux/termux-packages/tree/master/packag...
[0]: https://www.xda-developers.com/termux-terminal-linux-google-...
Maybe it's possible to implement that as an extra app though, without even touching Syncthing. Android seems to have some concept of virtual file systems provided by apps so perhaps one could on-demand un-ignore files then block until they're available. (But yeah, that's definitely more than a quick hack.)
In Dropbox, if I want a file I haven't synced yet, I just browse to it and open it. I can also mark folders as available offline.
I'm using Seafile for that now, but I don't like that it needs hosting and I'd love to switch to something P2P and get rid of the server.
We currently have a macOS app available and are targeting January for a Windows launch and a Linux launch soon after. We also have an iOS and Android app with a few beta users, and will release it around Jan/Feb'22.
Slik’s desktop apps have the ability to automatically detect changes in your local connected folder and sync those changes.
About On-demand syncing - we built Slik in a way that, once backed up, no files are required on your local machine. This doesn't prevent you from searching through all your files, and you can selectively download files based on your need.
However, I have added an item on our roadmap that would selectively download folders for offline syncing and faster access. Thanks again!
[1] https://apps.nextcloud.com/apps/end_to_end_encryption
I'm trying to decode the trend for decentralized services. If you have a sec:
Q1: In your case, why did you opt for decentralized storage?
Q2: Which benefits do I get as a consumer that I wouldn't if this was encoded, but centralized with a lot of redundance?
Don't take me the wrong way, really trying to understand where this is all going.
Cheers
However, we also have an email sharing solution already integrated into the app which uses public-key cryptography. This is protected from accidental leaks as you correctly pointed out.
Thanks for the feedback, we would update our WhitePaper with the details from above, and also indicate that to users in the UI - so that it scares people less! ;)
https://en.m.wikipedia.org/wiki/EncFS
Also, mega.nz
And, perhaps more interestingly, why would this become popular where BT Sync failed to live up to the hype?
Furthermore, storage can be paid for by crypto. Does this mean the storage is linked to some kind of cryptocurrency, or is there some kind of central payment system that converts crypto into actual value in the system?
I still use Resilio but am looking for an alternative since development seems pretty dead at this point (no updates for months).
It’s working just fine for me.
It all truly just works and it works well.
On the other hand you can use any other service and encrypt your data first if you just need an off-site backup.
Edit: If this is/was a trully decentralized tool (which would imply some sort of open source code to host it) i would be stoked
Is that maybe a bit misleading? Probably, but a lot of people who search for decentralized are looking for something "off grid" in the sense of no one is watching vs "off grid" in the sense of roll your own grid.
Not depending on a single node to me sounds more like distributed like Tor or clustered like Ceph or in some cases federated like Mastadon or Matrix.
Here were our goals when we started this out -
The above two goals help us achieve a working solution that users can start adopting.Next few near-term goals are -
Hope that gives you a reason to be stoked! :)Isn't it a bit sketch to be calling it decentralized if that's merely a goal though?
How does that work? Are people sharing storage? I.e. is it truly using "p2p storage" even if the transfers (at this point) are centralized?
* centralized - a single funnel by which all traffic is managed, such as a web server
* federated - various disparate nodes comprising a centrally managed/governed network. This is blockchain and IPFS where the network is an application layer protocol. The more appropriate description is pseudo-decentralized or semi-autonomous. It is not centralized but it is also not fully decentralized.
* decentralized - disparate nodes communicating directly using agreed upon conventions. There is no centrally managed network. Think in terms of snail mail, IPv6, or phone numbers. This could be as simple as people using an agreed upon application to abstract away the transmission concerns but that application does not route traffic through a third party server.
The greatest misconception, or rather abuse of the term decentralized, I am seeing on HN is confusing it with a federated scheme. Federated schemes are not decentralized. Web3 is not decentralized. They are distributed.
In some cases the abuse of these terms is accidental, but it seems in many cases it is intentional. I suspect some large organizations, yes I am looking at you Facebook and Andreesen-Horowitz, are fearing functional obsolescence, either in their investments or their properties, in the near future and so are attempting to validate their existence by muddying the waters. By functional obsolescence I mean what would you need Facebook for if you can directly transmit media, or micropayments, between friends and family without some sinister third party destroying your privacy. The commercial web has become very hostile to its users, so pending a proper convenient end-user application, there is little incentive to continue using the web.
Obviously I know some people do, but I've yet to work on a project that doesn't just stick with the one.
But, as you're saying, rightfully, hosting of the remote repository is in the hands of Github. So its not decentralized.
These discussions tend to be like the ones involving 'conciousness'. Until a clear definition of the term is agreed upon, it is impossible to talk about it. Going around measuring with a yard stick requires that the stick is calibrated to a yard and everyone agrees it is a yard. May be you can do some probabilistic measurement (consensus of people whether something is decentralized or not), but it's pretty useless.
https://www.sqlite.org/whynotgit.html
Centralized: most of the data and compute lives in one place and is controlled by one entity. This is standard issue SaaS, etc.
Federated: anyone can run a server and the servers can talk to each other somehow and either propagate messages or replicate data, but still centralized from the client point of view since each client connects to one or more servers. While anyone could run a server it often requires a lot of administration overhead, storage, and often "peering" permission from at least one other server.
Decentralized: clients are servers and everything connects in some kind of mesh graph.
It's not a binary thing, more of a gradual shift. Bitcoin for instance is somewhere between federated and fully decentralized. Technically anyone can run a node and they connect in a full mesh, but most users don't use it like this and the cost of running a node is at least "annoying" for most people (a lot of bandwidth and storage).
Centralized systems are the easiest to engineer by far but come with the obvious downsides of single point of failure, moral hazard, censorship, lock-in, latency issues if you are not near the servers, etc.
Federated used to be very very common. Classical e-mail, Usenet, FidoNET, UUCP networks, etc. are all federated systems. The old school file server with mirrors paradigm is also a simple from of federated network. It declined in popularity when all the old systems fell victim to spam but is rising again in the form of things like Mastodon.
There are not very many fully decentralized systems in common use. The most well known is probably the BitTorrent magnet network. Fully decentralized systems that are secure, robust, fast, and light on resources are incredibly difficult to engineer.
Edit: if you look deeper it gets more complicated though. Google, Facebook, and most of the other "hyperscalers" are federated systems under the hood but this is all hidden from the user. They are still "logically centralized" though.
It's possible to further break things down by what is decentralized. You can have decentralized or centralized compute, storage, trust, control/administration, and so on.
You can have a system that is decentralized in one way but not another. A peer to peer system where every object must be signed by a centralized authority has decentralized compute/storage and centralized trust. The Apple ecosystem is probably the best example of that. Apple has to sign or notarize most things but these things are then sprayed across a huge diaspora of machines.
A physically and computationally centralized repository of objects that anyone can create is the opposite. GitHub is a good example of that.
The BitTorrent magnet network and most cryptocurrencies are examples of systems that are decentralized in both respects.
Eliminating all forms of centralization without making huge sacrifices in areas like security or efficiency is really hard. I would say it's an unsolved problem since even if you try really hard centralization tends to creep in... e.g. how proof of work economies of scale create centralized mining cartels in cryptocurrencies. PoW is also very expensive, making it inefficient but moving that inefficiency "out of band" and hiding it in an externality.
Decentralization is a big rabbit hole.
Now if you store your atomic bomb schematics in Storj, FBI can't delete it because it's distributed across thousands of computers whose owners don't even know what they are storing.
I'd love to like this because imo decentralized private storage is an important issue that urgently needs solutions. But how can you convince people this is better than trusting dropbox when you don't even tell them how it works? And how do you guarantee lifetime storage through a small one time payment? Surely Storj disk space providers aren't going to host files for free.
We're constantly improving our WhitePaper to provide as much clarity as possible about our systems and algorithms.
We had set lifetime storage for 10 years, and have clarified it on our website to prevent it from being misleading. Thanks a lot for your inputs! :)
That plus the high level overview of the algorithms seems fair enough for a whitepaper
Although I don't get what additional security is gained from using an additional symmetric sharing key in protocol two. Isn't the key gonna be encrypted anyways with the temporary public key from Bob? Also which protocol is used for the asymmetric encryption?
If you say it's lifetime and then have to explain it as being 10 years, it's still misleading. Just take out the word 'lifetime'.
The chances of me trusting a technology company, especially a startup, especially especially one doing anything on blockchain, to provide a lifetime service is effectively zero. Annual pricing is fine; if you want to go crazy offer two or three years.
The only way to be sure would be to physically self-host with the option to air gap the storage from the Internet.
If you have a solution we should be trusting, I would avoid "buzzword bingo" and just be straightforward with your customers.
you're just relying more middle-man but giving false sense of p2p network to the end-user
no bueno
MetaMask is ethereum non-sense
i know what you doing in gibraltar, SEC might be interested to know
Why did you all decide to go with Storj, a fairly centralized distributed storage aggregator, rather than a decentralized storage network like Filecoin or Sia/Skynet?
Who pays for the storage on Storj? For a tool to be decentralized, the user needs a means to pay a node directly and the ability to seamlessly move between providers, ie interchangeable and zero lock-in. Does Storj allow crypto payments and this type of mobility?
Also noticed the app runs on Firebase/Google, are there plans to move away from this?
It looks like this may be an existential threat to the current Tech Giants since their data is centralized whereas these new DApps are not.
Looks like they use FileCoin and Storj
1. Users pay for their own storage, as directly as possible, otherwise they are not in control.
2. Any centralized APIs are fully interchangeable, ideally you can literally select a different gateway in the app, and keep working all within 5 seconds.
Reliability, performance, and a scalable infrastructure were strong selling points of Storj for us, and hence, we decided to go with them to provide a more seamless experience in terms of data upload and fetch. We also use Filecoin for immutability of user data, and as another layer of global redundancy.
Currently, we pay for storage/egress to Storj. Users can pay using dollars/crypto on our platform and we convert it to relevant Storj tokens to pay for storage. It is not automated yet, but yes we plan to automate it soon. Also, Storj does accept Storj tokens as payments.
About interchangeability, we plan to provide the migration functionality on our end to users.
We started with Firebase/Google because it was easy to setup. However, our team has been experimenting with different blockchains to sync the different file-ids and file-hashes. This would provide even more dApp developers to develop apps on top of Slik. We have a potential fit, and expect that to be integrated in H1'2022.
As many other comments suggest, I think it would be great to provide clear documentation to users that they can:
1. Run the entire app themselves, with their own chain/storage nodes etc - its the only way to really guarantee/prove the software is decentralized.
2. Access your data from both any centralized providers (such as yourself) or a local instance, ideally its so transparent you can literally select a different gateway in the app and keep working all within 5 seconds.
This is the bare minimum I would personally require before adopting a "decentralized" software tool.
Looks like you all are taking an incremental approach and not quite there, its a tough problem to solve but I wish you luck!
With Storj I cannot say I have run a node but the first (required) step is literally registering an account and providing all your personal details on the Storj website, if there is an advanced way around this, its not easy to find in the documentation.
Do you know anyone in their team? and if so, could you connect me with them? Thank you!