Their website describes this as open source but their linked repo is under CC BY-NC-SA 4.0 [1] so not commonly regarded as open source, but instead source available. They have been made aware of this [2]. Additionally, I think it may only be the front-end parts of their apps that are source available, I'm not sure the server-side parts of their app have sources published.
I always end up with MPL whenever I do these kinds of selection guides and always wonder why it isn't more widely used. Is it because the lgpl covers a lot of the need for it, or because once you allow static linking you might as well go BSD?
Actually I'm doing something related to this. So considering e2ee by definition doesn't require the messenger/middleman to co-operate, you can turn any communication medium into an end to end encrypted one. So I made a fully offline, client-side browser extension (it can also be a copy paste console snippet) that hooks into the send button of a POC malicious chat app and performs a key exchange for you. Then it sets up hooks to automatically encrypt messages before sending it, and also decrypt messages you receive.
So visually it looks just like you're chatting normally, but the server gets only encrypted messages.
It is too late to change the name. Just because you and I would have chosen a different name if we could go back in time does not make it OK for you to assert that the name "does not mean anything in the first place".
Since the 1990s there has existed an entire non-profit organization dedicated to clarifying the meaning of the name.
From the white paper, it appears as if this system requires its users to trust the server. That's not end-to-end encryption. What do I have wrong here?
Further, it looks like the email encryption provided by this system only works between users of Skiff. At that point, why use email at all? Why not use a real secure messenger? Instead of building an "encrypted email service", you could literally just build an email-flavored frontend to Matrix; either way, you're proxying to SMTP, not speaking it directly.
>From the white paper, it appears as if this system requires its users to trust the server. That's not end-to-end encryption. What do I have wrong here?
It doesn't. All data is encrypted client side across all apps - Skiff Mail, Drive, Pages, and Calendar. For sending external, the whitepaper is very clear how this case is handled in section 8.2 as securely as possible (without having PGP in place. Though this is something we are looking at based on community feedback).
>Further, it looks like the email encryption provided by this system only works between users of Skiff. At that point, why use email at all? Why not use a real secure messenger? Instead of building an "encrypted email service", you could literally just build an email-flavored frontend to Matrix; either way, you're proxying to SMTP, not speaking it directly.
Lots of folks are sick of getting sold their data sold based on their email. Even corporations are sick of largely giving more information about their customers to Google even notoriously Amazon that stopped sending purchase receipts via email.
So even if not end to end encrypted, we do encrypt the emails with the recipient's keys ensuring that only the recipient can access this data. This is a strong privacy guarantee not just backed by a flimsy privacy policy but actual cryptography.
Section 8.2 seems to talk about how you send plaintext email via SMTP to users who aren't using Skiff.
But that's not what I'm talking about with respect to end-to-end encryption. The white paper refers repeatedly to "browser" users. Your server can feed arbitrary Javascript to browsers and subvert encryption in a variety of ways, can't it?
I'm still not clear why you designed a new, simplistic cryptosystem at all here; can't you do everything you're trying to do here on top of Matrix? Again: the cryptography promises you're making only work between users of your system.
> Your server can feed arbitrary Javascript to browsers and subvert encryption in a variety of ways, can't it?
That's how literally any website works. How do you encrypt in the browser if the server doesn't send JavaScript to encrypt data? You also trust Signal not to issue an update that sends data in plaintext over the network. Unless you're building an app from source, you implicitly trust the developer to some extent.
Yep, but Signal is still a potential adversary, and could roll out a backdoor.
A couple of things that are easier in a web-delivered tool is deliver a backdoor to a user or group of users (which Skiff can track), or deliver a backdoor over a particular window of time across many users to decrease the chance of detection.
I know Skiff uses IPFS in some of parts of their solutions, and there's something they could do with that for the first -- essentially making visiting a particular version of the code part of how it is accessed, but there's some real UI challenges, which maybe they're looking into (it's been a while since I checked them out: they have some great UX in other parts of their suite).
The other tactic I've seen is to bundle the page into a browser extension, which moves you closer to Signal's status.
Not directly. They would have to roll out an update with the backdoor to the App Store. But as a user I’d be none the wiser.
I wish there was some way on iOS to prove that some particular version of an app was built from a certain git hash. That way these sort of attacks would be easier to detect.
However there is still one advantage of even appstor: They have to push the backdoored version to everyone (or large set of users). So that drastically increases risk of being caught. Website under their control can backdoor one specific user or even just one session, making detection harder.
> So that drastically increases risk of being caught.
Only if someone out there is extracting, decompiling and auditing each version of the Signal iOS app in the app store. But I doubt anyone is doing this. If a backdoor is ever snuck into the signal ios app for a few users for a few weeks, I highly doubt anybody would notice.
You can change remote configuration flags post-release (e.g. to enable diagnostics).
Even “secure” softwares like Google Chrome can capture your whole browsing history if they suddenly decide to enable a flag on your IP address. No need for conspiracy or update, though Chrome is considered perfectly secure.
In Android you can also distribute updates to specific e-mail addresses, which is very convenient.
> In Android you can also distribute updates to specific e-mail addresses, which is very convenient.
Yes but this requires the user to opt-in, you can't do it silently:
> After clicking the opt-in link, your testers will get an explanation of what it means to be a tester and a link to opt in. Each tester needs to opt in using the link.
As for the Chrome thing, I'm a Firefox user but I would be surprised if it shipped with the option to remotely upload whole history without user's knowledge or consent, do you have a source to back that up?
You can disable updates. As long as the servers (and the OS) don’t break compatibility, you can continue to use the same old likely-non-backdoored version.
At least when downloading from the Play store, Google requires the application be updated every 90 days or so. I've run into this multiple times where the application ceases to function after the 90 day window until I go update.
Not for Signal. I was periodically prompted to update with the warning that I would lose access to signal if I didn't. Then I upgraded and they robbed me of SMS features. I would have been happy to remain on a previous version.
Group invite links in Signal work similarly to Skiff: they reveal a key to the client side js so it can either present users with a Signal download link or open a URI, depending on whether they already have Signal or not. (Signal chooses not to use a URI in this case because it would break for anyone without Signal.)
So if a Signal group is using group invite links they have the same problem Skiff does.
What I would like to exist is something like Subresource Integrity [1] but for a URL itself, so that you could include a hash in a URL and let the browser warn you if the page source doesn't match the hash.
I built something that solves this problem. It uses an open source program installed on the client to encrypt and store data in a way that doesn't allow the website to access the plaintext data. https://redact.ws
> How do you encrypt in the browser if the server doesn't send JavaScript to encrypt data?
Meta has done some work along with Cloudflare on this for WhatsApp Web, specifically. In general, JS crypto is always going to be suspect if the threat model involves distrusting the server (like in e2ee protocols like Signal).
Huh? It is very concerning to hear this from a founder. It is the same exact level of security as it is executing the same code, just at a different level. Really does not matter what crypto lib you are using if at the end of the day the surrounding code dictates all the security.
Regardless of all this, your open source crypto library doesn't even use the Web Crypto APIs at all, but rather the dreaded js based crypto you are badmouthing (tweetnacl, stablelib)
That's just false. Downloading crypto libraries over the web plagued Javascript crypto for years. We use tweetnacl, stablelib, and webcrypto - and tweetnacl also uses webcrypto!
From your source, chacha20 is used, which is literally not supported by web crypto apis. Again, this makes 0 difference as higher level implementation makes or breaks your crypto.
What do you think of Lavabit? I think they operated in the same way, but the US government forced them out of business for refusing to hand over their TLS keys to allow the US to spy on Snowden.
I don't understand how you don't have exactly the same access they did. I feel like I've invested a fair bit of time to understanding how this stuff works, and the story you're telling doesn't make sense. What am I missing?
What amilich said is correct. However, what he is leaving out is that both have access to unencrypted email at send and recieve time, so you are taking Skiffs word that they dont log emails - since you have to trust the server this is not e2ee.
Lavabit is the one that used user passwords to encrypt the messages, thus ensuring that they had access to all the necessary secrets to decrypt user messages any time the user was viewing them?
And that had complied previously with US government subpoenas to provide metadata and data for users?
No. Lavabit had fundamental flaws where passwords were sent to the server so anyone who could decrypt the HTTPS traffic could basically access the content [1].
Skiff's password mechanism actually solves this flaw cryptographically using known, established primitives.
We use argon2id to take password and turn it into two cryptographic keys. One key is used for an SRP scheme to prove you have the password in a signing flow that bootstraps session management. The other key is actually the data encryption key. These keys are never sent to Skiff's servers and this generation happens all in the browser.
Lavabit really failed fundamentally in having actual end to end encryption because the password was sent to the server.
That's all moot though, since your server has access to plaintext emails when sending and recieving (99.99999% of email addresses would be outside skiff), which completely subverts the whole point of encryption. A vulnerability on the server could leak all user emails, without needing their keys.... This is a solution theoretically only as strong as encryption at rest.
It really is not backed by cryptographic security at all. Since your server has access to plaintext emails when sending and recieving (99.99999% of email addresses would be outside skiff), which completely subverts the whole point of encryption. A vulnerability on the server could leak all user emails, without needing their keys.... This is a solution theoretically only as strong as encryption at rest.
Again, only between users with skiff emails, which is a negligible portion of all emails. This needs to be made clear as it is very misleading to the average user who probably thinks all emails are end to end encrypted.
No: Skiff does not have access to a single email stored on our platform, including ones received externally. All are public-key encrypted, including subjects and content.
This is encryption at rest, with the user holding the keys, and not end to end to end encryption, since the server recieves emails coming outaide of akiff in unencrypted form to begin with.
As a simple demonstration, even if client side code is perfectly secure, an adversary with server control can simply log all emails passing through the server and instantly have access to all new user emails that way. This means users have to trust the server, contradicting any notion of E2EE.
Worth noting that Google does not do what you're describing. Google has never literally "sold" data from Gmail and stopped using it for their own ads ~6 years ago.
Except there is a reason. Encrypting email has very little to no benefit, since it is transmitted in plaintext and usually stored in plaintext on the recipient's side, your emails almost always exist in unencrypted form. On top of that it has major usability drawbacks, for example you cant ask the server to search emails for you anymore - all emails have to be downloaded on all your devices to be able to search - which is what skiff does. It will be okay at the start, and progressively get slower and use more space on your drive the more you use it.
> Except there is a reason. Encrypting email has very little to no benefit, since it is transmitted in plaintext and usually stored in plaintext on the recipient's side, your emails almost always exist in unencrypted form. On top of that it has major usability drawbacks, for example you cant ask the server to search emails for you anymore - all emails have to be downloaded on all your devices to be able to search - which is what skiff does. It will be okay at the start, and progressively get slower and use more space on your drive the more you use it.
This are just old technical problems which are already solved, for example by Tutanota. Mails are not send in plaintext if they are encrypted, and mailbox can be encrypted too. Plaintext version of your data exist only in the memory of your computer while the session for your mail client is open.
What it comes to the search - it does not matter anymore. We have enough computational power these days and storage to hold emails on devices. User experience is about the same. Increasingly, it is just optimisation problem which can be done right. Just don’t use Electron for your email app.
Unfortunately not even close. When the server gets the email it is not encrypted (unless the sender has a skiff address too, which is a very tiny portion...). And when you send an email to anyone outside skiff it is the same problem, the email has to be unencrypted so the server can send it in a form readable by the recepient. Without anything like PGP the server does not know the reciepent's public key, so it is impossible to encrypt it.
We might be talking about different encryption, since that does not sound E2EE at all.
The point of the encryption is that server never sees the content.
But that is true that if you use skiff to send message for someone, who is not using skiff, the message is unencrypted because receiver has no means to decrypt it.
That is standrdisation issue. Apparantly PGP is not considered good enough.
But if we had standards, we have techology to provide E2EE emails.
Totally agree... it is just disappointing that services like Skiff advertise total E2EE to unsuspecting users with no mention of this in their marketing, luring users into a false sense of security
European based Tutanota offers possibility for send E2EE for non-Tutanota users. It works by setting password for the content, and you need to deliver the password in other means. But usability suffers on this case, but at least there is a possibility.
Skiff encrypts all received emails with user public keys immediately on receipt. This is quite clear in our security model page and whitepaper. Skiff does not have access to any user emails, including external received ones.
Unfortunately this does not matter, since the trust model is same as it would not be encrypted at all. We still need to trust the third party.
Somehow the infrastructure should be transparent so that outsider can verify indeed at any time, that you don't collect logs from that traffic, or have no other means to inspect traffic if you want to.
There are currently no other means than just to use E2E encryption.
There is also another almost there, but that would mean that you should open-source your whole infrastructure, and use reproducible builds. Somehow there should be way to get access for outsiders, that you indeed use your infrastructure as you describe in your source code. But this is very complicated and also changeable at any time, unlike E2EE.
We use an open-source mailserver (Haraka), but security audits are the most trustworthy way to do this. We've had 4: skiff.com/transparency. Audits cover infrastructure.
i have 2.5 million emails in a 32GB datastore. no mailprovider is going to allow me to store that much mail, and search is actually quite fast. if it isn't for you, then get a better mail client.
Google's cheapest paid plan ($6/month) gives you 30GB. The $12/month plan is 2TB of storage. I currently have over 30GB of email in Gmail and everything works fine.
I have around 17GB of pop3fetchallnokeep in the mail folder and the backup is somewhere in the btreeflatfile heap in that UtahDataCenter free of charge training darkgpt 5.8
> That's not end-to-end encryption. What do I have wrong here?
Apparently, email may not their main e2ee usecase. The CEO at Skiff wrote this on PrivacyGuides forums:
Our solution for external sharing was not intended for email. It is much more powerful to share E2EE real-time collaborative docs/files with subpages, embedded E2EE files, and so much more.
Curiously, in the same thread, there's is a mention of Trail of Bits auditing their codebase twice.
You haven't published the reports, scope, and full findings. We don't even know what Trail was testing. I don't think the security audit stuff matters at all, and Trail is a fine firm, but you can't use the mere existence of a pentest project this way.
Any security engineer would have a heart attack if any employee, friend, or colleague said "security audit stuff [doesn't] matter." I wouldn't use software that doesn't undergo security audits.
I am a security engineer. You can go reach out to whoever managed your assessment at Trail and ask them about me by name if you like. What you're saying doesn't make sense. Maybe you could make it make sense! But you'd need to start by disclosing what the actual project scopes for each of these projects was.
It is misleading to tell about audits in this context.
Your transparency statement clearly says that Security audits. This is different than privacy audits. You cannot audit privacy, since you can intentionally change the functionality of your software right after the audit.
For the same reason, you cannot share open-source version of your software and say that it respects privacy. That can be only said if you use reproducible builds, and for client software only.
Both security audits and sharing your software as open, is about security, not the privacy. Open-source software and security audits help to reduce unintentional issues. And in this context it means a lot.
Actually, that's completely false. Security audits are a standard, reputable process for software. Trail of Bits is probably the best (or one of very few top) firms in this category. Check out: https://github.com/trailofbits
Is Trail of Bits doing random checks on your running infrastucture to verify that you are not changing your software against your users?
No. That is not what security audits are. Security audits ensure that software does safely what you, as service orderer claim, in a single moment. Usually including checklist.
But they cannot guarantee that you don’t change software between audits.
That is why E2EE exists as then it does not matter and we don’t need to trust.
Open-source, security audited client for E2EE communication with reproducible builds is the magical, correct combination to ensure both security and privacy.
What exactly got tested in each of these assessments, and what conclusions did those assessments draw? I asked this upthread and I'm asking here again, because "we've had 4 audits" doesn't mean anything without that detail.
After getting fed up with ProtonMail recently I went on a quest to find an alternative. Unfortunately Skiff doesn't have SMTP or even an export feature so once you go Skiff you can't go back, you're locked in.
ProtonMail does have import/export and the SMTP bridge (for paid users) and those things work but ProtonMail mangles emails: it removes plaintext body where there's a HTML body and it screws with headers.
Ultimately the best option I could come up with was self-hosting my email address. Incoming emails go directly to a box sitting in my office, with TLS enforced.
I put this off for years fearing deliverability issues but finally realised that incoming and outgoing email can be hosted in different places. So though the box in my office receives my email, I send email through either a Hetzner box or Mailgun (with retention disabled). Haven't encountered any issues with this so far.
> After getting fed up with ProtonMail recently I went on a quest to find an alternative. Unfortunately Skiff doesn't have SMTP or even an export feature so once you go Skiff you can't go back, you're locked in.
wow, an e-mail service without smtp nor imap?? no thanks
You can't have SMTP if it's fully end-to-end encrypted.
That's why proton has a bridge, it decrypts messages locally, then runs an SMTP server for your local clients.
You can if the service doesn't handle encryption with a proprietary protocol and instead helps you set up PGP. It certainly has its issues and limitations, but after trying ProtonMail/Tutanota/what-have-you, I have _never_ actually used their E2E encryption except when contacting support for that mail service.
Meanwhile with PGP I can post up my public key on my personal sites / resume / social accounts, and people actually have reached out. I also like that you don't even need to include your email address to prevent scrapers from harvesting it. If it's on one of the public keyservers, their client will find the email address for the respective public key.
Well, ProtonMail isn't end-to-end encrypted anyway, even with Bridge. Unless you use PGP encryption. Emails are encrypted in-flight with TLS, but ProtonMail terminate that TLS connection.
I'm talking about zero knowledge encrypted email storage.
Proton mail doesn't have access to your messages, and SMTP doesn't support that type of encryption.
Do you have a write-up about this? I've been wanting to host my own almost entirely for the extra control over incoming mail and have been held back by the same worries. I'd like to see what a success story looks like.
I don't, sorry. The short story is that I use Docker Mailserver [0] with some customised config for SMTP relaying, spam filtering and Gmail fetching with spam filtering. I also have a Roundcube container.
Underneath though, it's a pretty standard Postfix + Dovecot setup and there are plenty of those around.
The pricing page is confusing to me. It doesn’t mention anything about email in the free tier. It just says:
> Unlimited pages
> Desktop, tablet, and mobile access
> IPFS support
> Full text search
Which seems to be all about the document service, but it also doesn’t mention how much storage I get. I assume it’s not unlimited despite saying “Unlimited pages.”
Also, I can see that Skiff has raised over $14M in VC funds[1], so as a privacy-focused product with a free-tier I think it’s fair to ask what they see as their path to profitability is without compromising either their privacy or their free offering.
Are you possibly on a different or old page (or article)? Check out https://skiff.com/pricing and scroll down, it has 20+ features. We have thousands of paid users!
Interesting. No, I went to that page but on mobile. I didn’t scroll all the way down past the tiers. You have to scroll way down to see that info. It’s probably fine on desktop but less than ideal on mobile. My 2-cents anyway.
..Personally, this looks promising. I am going to say it though- Skiff needs some sort of mechanism to use PGP if for nothing else, then to communicate with Protonmail email addresses specifically. I see they are taking the stance its's time to move to something beyond PGP- but given the extremely large userbase that is Protonmail- I think their target market would feel better being able to communicate with their protonmail contacts- using PGP.
Also, i'm having trouble seeing if Skiff has a way to 'send secure emails' to other external email providers, like Tutanota ,Mailbox, and Protonamil do for their users to securely contact people outside their ecosystems(like peeps with gmail).
Solve those issues- and the pain/difficulty/unease of convenience will disappear for their market which likely already uses Protonmail/Tutanota, etc. And Skiff would be very attractive at that point, positioning itself as a successor to those two possibly.
This is a system that appears to have long-term identity keys, for which "forward security" or "forward secrecy" appears a total of zero times in its white paper. If this is an improvement on PGP, it's not totally clear to me how. Maybe one of its authors will clear that up.
Right now, you can use Skiff Pages for this. You can share public links that have E2EE using link fragments, add passwords, and collaborate in real-time.
Is the benefit of this over something like Protonmail or Tutanota the enterprise focus products? As an individual user seems like I may as well pocket the difference, right?
Hello! I'm one of the founders. We do end-to-end encrypt email subjects. Sender/receiver addresses are not to ensure email goes to the right person. 10 GB drive is used across all Skiff products.
I've been using my personal domain on Skiff and been loving it personally! Simple to setup (nothing different to the usual) and it all works seamlessly!
Just that, it's one inbox in the Free tier. Since I'm using on my own domain, I prefer having one inbox for all addresses!
I use FastMail but would consider moving. Can I have unlimited aliases when using my own domain? I use their MaskedEmail function to generate aliases for each service and have > 150 at this point.
I opened an account at Skiff a few weeks ago and have used it in limited amount since then. But sending an email to my outlook.com address and my wife's gmail they both went right to inbox on first try. That was pretty impressive considering some long established email providers still go right to my spam at times.
Deliverability is a constant challenge for us to improve on. We have rate limits that do try to protect email deliverability. Things should be good today but it will always be something to watch.
@Amilich, what's your approach to companies wanting to use Skiff? I'm starting a company of my own and while I'd love to use Skiff, there are a bunch of blockers including email inbox warming. Without SMTP/IMAP support, no warming tool will work, and no API means no one can build scripts to do the same. This small case itself will be a blocker around adoption for companies right?
So what's the state of the art with respect to end-to-end email these days? Lavabit is back, but it seems like everyone uses Protonmail these days? But didn't they get into some sort of controversy a while back that made some people drop them?
And now I'm seeing Skiff, which is great, it's clear that people want this. I just no longer know who the players in the space are.
Unfortuantely they have become nothing more than snake oil. Huge bloated front-ends with 1000s of npm packages makes it very hard to trust anything like this. Add to this the lack of convenient search without having everything stored locally, and it becomes useless to go with an "encrypted" email provider over just a normal provider with emails stored locally encrypted on your device
The data is still located in the US so honestly for email I would not see the benefit since so much of it will pass through unencrypted on a cloud provider (AWS?).
I personally use mailfence with IMAP on Thunderbird (so its not full E2E encryption despite the marketing) but I much prefer the Belgian privacy law.
Though the mobile/destop apps looks very nice and overall kudos for what seems like a coherent ecosystem (something I miss from my patching of sync.com and mailfence). Also concerned by VC money in that space, hopefully you are profitable. Nobody wants to have to move their life (calendar, drive, emails) because they trusted a startup that ran out of money...
Yet the web UI downloads remote images by default.
Granted, it hides your IP address by proxying the request. But it still leaks that the message was read. I used https://www.emailprivacytester.com to test this. No image was fetched until I clicked the email to read it.
> There is no foolproof way to load any remote content without possibly exposing email open information.
Also, this is false. You could download all remote content at time of delivery. That way it would be impossible for a sender to differentiate between an email simply being delivered and one being read.
Even more worrying, I just went into the settings and toggled on "Block remote content" and then sent my self another test through https://www.emailprivacytester.com, and it still triggered a remote content load when I viewed the email.
It's saying that the images were blocked, but that didn't stop them being fetched. Entirely defeating the point of the setting.
My point was that defaults matter, and your default is not privacy preserving. Yet you claim to be a "privacy first" service. There are many email clients which do not download remote content by default. I would argue that they preserve privacy better than Skiff does.
Yes - privacy focused mail providers offer this as an option but do not enable it by default. Mainstream mail providers do not even have it as an option.
Are you joking? I've never even come across an email client or provider that doesn't have options to toggle loading remote images. What mainstream mail providers don't have this option?
The only difference between your option and other providers are:
1. Yours doesn't even work. It still loads the remote images. It just doesn't display them
2. Yours has the wrong default.
Your "block remote content" option is even worse than just forcibly loading remote images and not even having the option in the first place, because it tricks the user into thinking that it will preserve privacy, like it does for other providers, but it does not preserve privacy in your case as it still loads the images.
No, I'm not joking. We do have this option, and it's consistent with the defaults across private mail providers. Still waiting for your list of the ones that don't load images by default.
It does not load the images. That's just patently false disinfo.
> No, I'm not joking. We do have this option, and it's consistent with the defaults across private mail providers. Still waiting for your list of the ones that don't load images by default.
If you read back, you'll see I wrote email clients and providers. But I'll note that you have not provided a list of clients or providers with privacy defaults that are worse than yours.
> It does not load the images. That's just patently false disinfo.
It absolutely does. You have no idea how your own product works. I literally showed you a tool where you (or anyone else) can verify this yourself in a few minutes: https://www.emailprivacytester.com - By the way, I am the author of this tool, and your email product is the least privacy preserving email product on the market right now.
I'll be blogging this up unless it's acknowledged and fixed.
I assume that once you've fixed the bug you'll be contacting all of your users to let them know that they've been exposed to this privacy flaw. At least the ones that may have disabled remote content at some point.
I just tested Tutanota and it does not have the same bug that skiff has. I think you must be having trouble understanding what the bug is. In skiff, even if you choose to not load remote images, when you view an email that has remote images, although it doesn't show the images, it does fetch them. I look at my web server logs, and I can see it happen. Emailprivacytester.com also shows it happen. I have tested this several times now.
I do not know what your difficulty is. Perhaps you should pass this on to somebody more technical than yourself at your organisation who can actually understand and diagnose the problem.
> by default, does not load external content from other servers (pictures and videos in emails). The user can choose to have external content shown with a single click or tap, if they trust the sender.
So there you go. An email company that does not load images by default. Whereas the default setting for Skiff is to load images automatically. So in this respect, Tutanota puts "privacy first" and Skiff doesn't.
I am not sure how the identity management works for encrypted email for Skiff. The white paper[1] seems to imply that a user has to send a URL with a secret in it as with document sharing. Every time? How is the user expected to get this secret URL to their correspondents? Does it require the use of a second messaging system with identity management? PGP for instance?
Generally, how does Skiff allow the user to ensure that the message is being sent to their actual correspondent and not the Skiff server? Signal messenger for instance uses "Safety Numbers" for this purpose.
So if I have 15gb of email, I have to process all of that on every client bootstrap?
How do you plan on scaling your service with respect to this problem? once you have a non-trivial user base with non-trivial data volumes this is likely to become a substantial problem.
To put this in context, the trivial example of a user with a 15gb account, say you happened to be using s3 for storage. They buy a new phone, that costs you ~$1.50 that month, or 50% of your revenue at current pricing. They buy a new iPad and a new laptop? You’re 50% in the red.
Similarly you’ll have some users who are, say, content creators. They shove a 10gb video in their drive. Let’s say they have a laptop, a workstation, a phone and an iPad. Their upload is downloaded at least 3 times, costing you ~$4.50.
This isn't how it works at all? We don't pay for storage on users devices... buying the device = buying the storage. It's actually much more efficient than doing search through some massive database.
I upload a large document to your drive product from my workstation.
I go to search on my phone.
My phone needs to download the content in order to index it.
My phone downloads the content from you. You pay for the bandwidth.
If I provision a new device, and it needs a new search index, it needs to download all of my content once, in order to populate the local index of the content.
If I'm something like a youtube content producer, I might put extremely large files in the drive. Per the blog post all the other devices signed into drive will see this new file and pull it down to index it.
So if I upload a 15gb video from my iphone to later process it on the workstation, my laptop, ipad and workstation will all download it. That means you need to serve up 45gb of bandwidth. Cost of operation as described in post above.
Depends, on an older phone, downloading all emails just to allow for searches locally won't be very efficient. Log out also becomes a problem, if emails are stored on one device that gets stolen, adversary now has access to the local index since all the keys or on the device usually with no FDE. Meanwhile with gmail a log-out would clear all traces instantly.
Also, not really true of Gmail. Try turning your WiFi off, then deleting your Gmail account. You might have mail stored offline on your phone (let alone any other device), as well as any IMAP or other clients. It's the same or worse.
This step is what I was expecting you to talk about, and it has some tricky subtleties to get right, which is why I looked for it in the whitepaper.
A trivial problem with a naive implementation is being able to perform presence proofs using side channel information: send someone mail containing a terms you want to verify, and watch for the associated high level costs affecting operations that are likely to be incremental index change uploads.
To do this you would have to download all emails on all devices all the time to index them. Kind of makes the whole point of a cloud based email moot, if everything is on my device anyway, and logging in and out resets it all - might as well use an email client app.
We do it in a fairly straightforward manner right now. Check out the blog I linked to above - generate an in-memory index, end-to-end encrypt it, and store it browser storage. It's only decrypted in memory.
I’ve seen this provider used by bad actors to create accounts on one of the worlds largest social media platforms. That’s how I learned about skiff. Very hard problem to solve.
I noticed on your home page near the bottom under the "Getting the Latest in Privacy" subheading your list of scrollables begins to duplicate entries if you keep clicking the right arrow after the "Brave Talk X Skiff" panel. From that point on, most of the entries are twinned until you reach the end of the list.
As another perspective, I personally prefer products that are paid because it makes me less concerned that my data is the product, and less concerned that the product will disappear or stop improving.
From the whitepaper, it seems search is done by downloading all emails on every device to index them locally. Curious how well this works with a large amount of emails?
[1] https://creativecommons.org/licenses/by-nc-sa/4.0/ [2] https://github.com/skiff-org/skiff-apps/issues/94