New Email Services Recommendation: Skiff

Hi there,

We have done a lot of work to improve our services over the past few months to meet the requirements laid out to be listed on privacyguides for Email Services. We believe we have resolved the previous criticisms laid out in Github Issue #1363. However for reference, I have explicitly laid out what criteria we have met and where we might still have some work to do, but we do believe that we at least meet the minimum criteria for listing consideration.

After this submission, we will submit additional posts for consideration of Skiff services under the “Calendar & Contact Sync”, “File Sharing & Sync”, “Notebooks”, and “Cloud Storage” categories.

Technology

Minimum to Qualify:

[YES] Encrypts email account data at rest with zero-access encryption.

Best Case:

[YES] Encrypts all account data (Contacts, Calendars, etc) at rest with zero-access encryption.

[YES] Allow users to use their own domain name

[YES] ​Integrated webmail E2EE/PGP encryption provided as a convenience.

​[NO] Support for WKD to allow improved discovery of public OpenPGP keys via HTTP.

[YES - Done by link sharing an e2ee Skiff Page] Support for a temporary mailbox for external users.

[YES] Subaddressing support

[NO - In testing/imminent release] Catch-all or alias functionality for those who own their own domains.

[NO] ​Use of standard email access protocols such as IMAP, SMTP or JMAP.

Privacy

Minimum to Qualify

[YES] ​Protect sender’s IP address. Filter it from showing in the Received header field.

[YES] Don’t require personally identifiable information (PII) besides a username and a password.

[YES] ​Privacy policy that meets the requirements defined by the GDPR

[NO] ​Must not be hosted in the US due to ECPA which has yet to be reformed

Best Case:

[YES - cryptocurrency only] - Accepts Bitcoin, cash, and other forms of cryptocurrency and/or anonymous payment options (gift cards, etc.)

Security

[YES - TOTP] Protection of webmail with 2FA, such as TOTP.

[YES] Zero access encryption, builds on encryption at rest. The provider does not have the decryption keys to the data they hold.

[YES] DNSSEC Support

[YES - See note below] No TLS errors or vulnerabilities when being profiled by tools such as Hardenize, testssl.sh, or Qualys SSL Labs; this includes certificate related errors and weak DH parameters, such as those that led to Logjam.

Note: Currently, we use AWS SES as a backup solution as shown by the MX records showing AWS SES as a lower priority than our own servers. We have a plan to deprecate SES in the next 3-6 months as we build on our track record of operating a reliable email service.

[YES] ​A server suite preference (optional on TLSv1.3) for strong cipher suites which support forward secrecy and authenticated encryption.

[YES] A valid MTA-STS and TLS-RPT policy.

[YES] Valid DANE records.

[YES] Valid SPF and DKIM records.

[YES - DMARC reject] Have a proper DMARC record and policy or use ARC for authentication. If DMARC authentication is being used, the policy must be set to reject or quarantine.

[YES] A server suite preference of TLS 1.2 or later and a plan for Deprecating TLSv1.0 and TLSv1.1

[YES] SMTPS submission, assuming SMTP is used

[YES - HSTS enforced and preloaded] HTTP Strict Transport Security

[N/A] Subresource Integrity if loading things from external domains.

Best Case:
[NO - In development] Support for hardware authentication

[YES] DNS Certification Authority Authorization (CAA) Resource Record in addition to DANE support.

[NO - in development] Implementation of Authenticated Received Chain (ARC), this is useful for people who post to mailing lists RFC8617.

[YES - See Note.] Bug-bounty programs and/or a coordinated vulnerability-disclosure process.

Note: We accept security bug reports at security @ skiff.com. However, we do not issue bounties at this time.

[YES] CSP

[N/A - See Note.] Expect-CT

Note: This header has been deprecated and is no longer available in Firefox and Safari. Chromium browsers enforce CT by default. More info can be found at MDN [link removed to 2 link max limit]
Trust

Minimum to Qualify:
[YES - See Note] Public-facing leadership or ownership.

Note: Co-founders Andrew Milich (CEO) and Jason Ginsberg (CTO) have been profiled or referenced in major publications and a sample are referenced below:

https://www.fastcompany.com/90764245/id-love-to-dump-gmail-for-this-slick-private-email-but-theres-a-catch

<Links removed due to 2 link max limit>

Best Case:
[YES - See Above.] ​Public-facing leadership.

​[NO - On roadmap] Frequent transparency reports.

Marketing

Minimum to Qualify

[YES] Must self-host analytics (no Google Analytics, Adobe Analytics, etc).

[YES] Must not have any marketing which is irresponsible

Best Case

[YES - Youtube Channel] - Clear and easy to read documentation.

Does Skiff optionally support CardDAV and/or CalDAV? Or otherwise offer a way to sync contacts with a phone and share calendars with others?

2 Likes

We do not yet support CardDAV or CalDAV, but we hope to in the future. They have been requested frequently.

CardDav and CalDav protocols do not support end-to-end encryption AFAIK

1 Like

Correct, but a contacts service isn’t useful to most people if it has no way to sync with devices, like on your phone.

This can either be via (optional) non-encrypted sync like with CardDAV, or with a workaround like EteSync uses.

2 Likes

I noticed that, and am having a look at it now.

@nishil I see that you still have some outdated ciphers accepted, this is likely a misconfiguration. Nothing too big but maybe good to look into:

Also please consider to add a security.txt see https://securitytxt.org/ so that people can actually find where to report vulnerabilities.

As for email:

DNSSEC is not correctly configured, therefore you do not meet the requirements of PG.

Also TLS for email allows 1.0 this version should not be accepted. I wonder generally why inbound-smtp.us-west-2.amazonaws.com is used. This seems to have a weak configuration also DANE is missing.

Hi, so I’m doing a bit of a review on this now.

More clarification on E2EE to users

I think many users are going to simply think “Encrypted” means that it is “E2EE” when it’s not. Most users are going to be emailing non-skiff users. I think Proton Mail for example makes this really obvious: How to check encryption status using lock icons | Proton Mail. That article is linked from the compose window.
2173304711
I also did not see an option there to send a Temporary Inbox, style message to non-Skiff users. Notably this is something that Proton Mail, Tutanota and Mailbox have.

This gives the ability for external users to reply E2EE in their web browser. While not ideal it’s better than nothing.

I realize email encryption is hard and really the only standard is PGP. I know you’re really not going to want to hear that seeing as you wrote PGP is dead. What's next? - Read more but it is an unfortunate truth that PGP will probably never entirely die until something replaces it, that can be federated across email providers.

What Skiff is right now, is certainly not going to replace it. It also won’t be the The Signal Protocol either, as this requires key exchange which isn’t possible on an asynchronous communication protocol like SMTP. There has been an attempt (and you might remember criptext, which hasn’t seen any activity in ages). Signal Messenger isn’t going to replace email, as there is still a workflow for “letter” style immutable responses as opposed to transient back-forward conversation.

There are also efforts to modernize PGP such as draft-ietf-openpgp-crypto-refresh-07 - OpenPGP Message Format. In that article I would have personally used a better source than a sensationalist wired.co.uk article claiming that PGP is dead, (I would have used https://efail.de). There are a few loud voices that want to make that claim, but until another RFC with benefits over the current one is created, that’s unlikely to happen.

Efail was a “blip” in 2018, now that vulnerable clients are fixed, and developers are using gpgme instead of directly invoking gpg and trying to parse HTML emails, the issue really isn’t quite as dire to even bother mentioning. Modern versions of Thunderbird, don’t even use GnuPG anymore (where that proof of concept originally was discovered), instead they use OpenPGP.js.

Also forward secrecy may not be as important as you think: Op-ed: Why I’m not giving up on PGP | Ars Technica explains that quite well. Additional efforts such as using a security key can provide extra security against key theft. You can’t have your Skiff keys stolen because Skiff doesn’t give you access to them, so that is one way to solve that problem.

Even established providers like Tutanota have only come as close as providing a “Temporary inbox” where users put a message in a JavaScript implementation on the provider’s website, which I might add does introduce other security issues such as does it have the same guarantees as a client side implementation from a third party. This is important regarding the introduction of a backdoor or interception order (perhaps an NSL, remember Edward Snowden and LavaBit) for particular users. We may see something based on MLS but until then I think PGP is here to stay.

Marketing

I see many articles like this one End-to-end email encryption is the only way to communicate safely on the web - Read more which focus heavily on E2EE in a very general sense. The article leaves out that emails that are sent to non-skiff users are not E2EE. It feels like a point you’re striving to not highlight. This is the sort of thing we see networks like Telegram do a lot, leaving users to genuinely think that all their messages are E2EE, when they aren’t.

There does seem to be a fair bit of “marketing fluff”, on the blog as opposed “real content”. This kind of thing happened during the early days of CTemplar. I would like to see improved quality there, such as articles about real issues, (Proton has a section for this) and changes in the Skiff product. I would also suggest having more screenshots when providing guides of how to do particular things in Skiff. These are useful when third parties want to support users of your product.

With the above article it mentions “In this guide”, but it’s not really a guide, it’s a basic explainer on transport encryption vs end-to-end encryption.

One section there stuck out to me “The importance of end-to-end email encryption” talks about compliance in the business sector. An important part of Compliance and governance - besides sounding important is that your manager can actually audit what email you’ve been sending from the company domain which is why things like Google Vault exists. I would tone down the “this is good for business”, marketing because the reality is when you are a business, you have a right to know what your employees are doing with the company domain.

There is more to providing service to businesses than simply giving them bigger data caps or allowing more seats. Even Proton Mail is not perfect in this regard, and with their resources and time it’s taken a long time to get anywhere close. In Skiff’s defense, all privacy providers, that is ones which use E2EE in as many places as possible, are going to have to solve a lot of very difficult problems, and engineer a lot of custom solutions to meet existing business workflows. I haven’t seen a single one with commercial features like email routing, groups and distribution lists, shared calendars, shared inboxes, custom DKIM keys, and other functionality.

Please avoid outrageous claims like:

one of the most progressive providers in the data security industry

This simply is not true, while Skiff may be a good product some day, competitors do still lead in many areas, and that is to be expected as they’ve had longer for their products to mature. I think in general “honest marketing” goes a long way. An example of that would be what IVPN does (they’re a VPN provider), but they’re quite happy to tell you about the limitations of their product and what it should be used for. (As an example).

This might also explain why I see Skiff users constantly spruiking the product on Reddit. I had wondered about that.

Community

I noticed was that they only have a Discord community, which in general isn’t very privacy friendly. I would have like to have seen a Matrix community. Skiff could then make sure at least their data is stored on a server they own, (for example like Mozilla.org have an EMS instance). I’d actually like to see a Mastodon account too for announcements, as it is nice to have less commercial and invasive alternatives to Twitter.

Honestly I don’t think anyone uses LinkedIn these days. It does feel like “old school marketing firm” made those decisions.

Email

The email interface, is very basic, for example I noticed you cannot have nested folders unlike Proton Mail. Tutanota doesn’t support this either. I’d probably have a toolbar in the composition window though for users who don’t know they can use markdown.

I also noticed there’s no way to see email headers, which makes it impossible to really dissect an email to see if it’s not a phishing email. Gmail etc lets you see DMARC status and all headers. Both Tutanota and Protonmail, as well as all the other providers we list on the website have this.

Import

I noticed the import features in Skiff, support importing via EML, MBox, Outlook or an IMAP server. This has always been a struggle point for privacy providers, notably Tutanota is only thinking about that now after having an issue in their tracker for a very long time Email import · Issue #630 · tutao/tutanota · GitHub.

Meanwhile Proton Mail Easy Switch only came about rather recently. Before that users had the pleasure of dealing with the Import/Export and it’s unreliability.

Things should improve with Proton Mail, with the new v3 bridge, that has a completely re-implemented APIs, and IMAP implementation, and avoiding issues like Our ProtonMail Adventure - A Five Act Drama - sigma star gmbh.

Curious to know why there’s $10 credit from coming from Outlook, but not gmail or uploading email from another provider.

Export

There also seems to be no export feature, as this post also notes:
https://www.fastcompany.com/90764245/id-love-to-dump-gmail-for-this-slick-private-email-but-theres-a-catch

I do see features like “Connect a wallet to send and receive email from your Web3 identity” this I don’t consider an important feature. When you are missing key features like export I don’t know why Skiff is wasting time on this.

I’m now thinking of adding export as a requirement to the PG criteria. This is the first time we’ve come across a provider without that feature. Data liberty is as important and we don’t believe user data should ever be held hostage.

I also notice that article mentions:

But even if Skiff adds more of these features, it still has one inherent challenge: It’s a new, unproven service backed by venture capital. While Gmail isn’t going anywhere, I can’t confidently say the same about Skiff.

The concern there is, if the VC decides to not give it more funds and the product isn’t in as good health as it should be, viability may be an issue long term. Without an export feature that would make me very uncomfortable.

Filters

No add email filtering rules, ie a label or a folder. All mail must be manually organized/moved/labeled.

Pricing

Email doesn’t take up a lot of space, and most users won’t need 100GB of storage. The pricing of Proton Mail and Tutanota is quite different to Skiff’s pricing on the entry level accounts.

Calendar

So the calendar is simple with a nice design. It does appear that there are some fairly important features missing though - such as the ability to share calendars.

It would also be nice to be able to import calendars from a URL, rather than just an ICS file. Common usecase for this would be subscribing to public holidays etc.

I noticed that it said during the import that “Repeated events are not yet supported”, I would consider this a crucial missing feature.

Drive/Pages

This certainly seems to be the strong point. If we do go forward with listing Skiff, we’ll be mentioning this is the main reason you’d want to use Skiff. This would be one of the stronger features of the product. One of the weak points of things like Proton Drive is there isn’t really any way to author documents in your web browser, let alone collaborate with other users.

Privacy Policy

All information processed by us may be transferred, processed, and stored anywhere in the world, including, but not limited to, the United States or other countries, which may have data protection laws that are different from the laws where you live. We endeavor to safeguard your information consistent with the requirements of applicable laws.

Doesn’t seem to be anything about GDPR there. Typically these days even for non EU providers they will address that.

I did notice this piece which was a bit ambiguous:

De-identified and Aggregated Information. We may use information about you to create de-identified and/or aggregated information. We may use such aggregate or de-identified information for any purpose, and such information is not subject to the limitations set forth in this Policy.

Sometimes de-identified information is able to be reversed. I don’t particularly like to see open ended clauses in a privacy policy.

Skiff Acceptable Use Policy

I did notice in there:

  • scrapes content hosted on our Site or through the Services without prior Skiff’s prior written authorization;

This would imply one isn’t allowed to write a scraper to export their email.

Other questions:

As Skiff is using its own implementation to achieve E2EE within the service, is there a cryptographic audit for this? I see mention here Skiff Mail is Open Source - Read more

We have been committed to open source software since the very beginning of Skiff. We strongly believe that privacy cannot be just a promise; software must be available for anyone to independently audit and validate.

Realistically though this isn’t just “going to happen” because the product is open source. Is there funding available for a paid audit that encompasses the implementation, and network?

After having a look at the repo, particularly Commits · skiff-org/skiff-mail · GitHub it appears no development takes place in public, so this might as well be a public FTP. Also you should look at using .gitignore and not upload metadata like .DS_Store files. The issue with that is, it provides a lack of transparency around new features and potential regressions, essentially someone has to sit down and figure out what the codebase does, how it fits together etc.

The above statement really does feel like you’re hoping an audit will fall in your lap somehow.

6 Likes

Posting a few initial responses with more to come. This is super comprehensive feedback, and we appreciate the feature requests and constructive criticism.

  1. External mail sent and received to non-Skiff providers is still stored encrypted with user public keys, so it is not accessible by Skiff. It is quite hard to capture these nuances in tooltips, but the point is that even external mail is safe, and it is never unencrypted. I completely disagree that it is misleading.

  2. I think PGP is quite out of scope for the criteria here. Given the articles you linked to, if only 30,000 external users use it, it’s basically unused by the Proton user base, and Tuta does not support it. Both Skiff and Tuta also encrypt email subjects, which I think is an enormous privacy benefit.

  3. Sending encrypted content to other users is possible. You can use a Skiff document on view/edit mode, which is end-to-end encrypted with a link URL and also offers password protection (additional encryption) and watermarking. Proton, Tuta, and all other providers do not offer functionality like this, but I actually think it’s better because it offers real-time collaboration, commenting, and more.

  4. I think discussing our community channels is a bit out of scope. We had a Matrix community, but it was bombarded with drugs and crypto spam that made it completely unusable and safe for users. We do have a Mastodon at ioc.exchange. I honestly think this is quite of scope, particularly given many recommended services on PrivacyGuides (Proton, Tuta, Brave, etc.) use many of the same social channels (Twitter).

  5. Import from other providers is coming. MBOX and EML should also give you the same credit. We have Gmail import ready to launch as well.

  6. The funding discussion is a bit one-sided. Venture capital is simply capital, and all companies require it to survive. Brave, DuckDuckGo, Proton, and many other recommended companies have taken venture funding - including Brave + DuckDuckGo in the last year! Skiff has many years of capital and paying customers to keep our services running.

  7. Export is coming. We’re prioritizing everything we can, and we’re just building import options. There are super comprehensive export options on Pages/Drive - export to MD, DOCX, PDF, and ZIP for entire folders, or even exporting entire teams - so we have no bias against it.

  8. The blog is being reorganized, but a lot of it is written for content marketing and SEO. If you dig into the Proton/Brave sites, you’ll see similar content, just not as publicly visible. For example, see Learn | Brave Browser with “the best private browser.” These types of lines are typical to SEO optimized blog posts.

  9. I agree on the pricing comment, but the plans are optimized for using Skiff as a suite, where 100 GB is actually quite helpful for Drive/Pages storage. Also, the free plans are much more generous, and the paid plans more expensive.

  10. Repeating events are coming to Calendar soon.

  11. We have undergone 3+ audits, all from Trail of Bits. GitHub - trailofbits/publications: Publications from Trail of Bits. If you’d like more info, Dan Guido (TOB’s CEO) has Tweeted about us a bunch. The audits cover all Skiff products, security model, and infrastructure.

1 Like

The issue is that isn’t really E2EE. As soon as an email leaves Skiff’s system it no longer has E2EE. It is only E2EE while Skiff has it. Generally when people think of E2EE email they expect it to be E2EE on both ends, the recipient and the sender’s end point.

  • I’m not a Proton Mail customer, but I can send an E2EE email to one of their users.
  • I’m not a customer of Tutanota, but if one emails me with an encrypted email and provides the temporary password - say over the phone, I can make sure that email is E2EE when it leaves my browser.

Perhaps not with the same assurance as PGP, (for example Tutanota could in theory disable E2EE for a particular user), ie by changing the server side code so when a particular user sends me a temporary inbox link, there is no encryption.

If I am a Thunderbird user, Mozilla cannot be compelled in any way to target a specific user. PGP without forward secrecy still can provide the highest level of assurance because implementations don’t necessarily come from the provider. Key theft is basically impossible with a Yubikey.

For commercial providers even Proton wants to keep an encrypted copy of the private key, this is because of support requests they do not want to deal with. I accept responsibility that loss of my keys will mean a loss of my email.

The point I’m trying to make is that it is not accurate by any means to say “PGP is dead” or that it is “broken”, there are certainly improvements that could be made.

You really can’t know how many PGP users there are. It’s a decentralized protocol without reporting functionality. There are many implementations and many providers. I have run into Proton Mail (and occasionally Tutanota) users (outside of the privacy communities), but I’ve never run into a user of smaller privacy providers.

While this is important, it may not be as important as making sure the email body is encrypted on both the recipient’s server and your own. Email subjects can contain sensitive information and while there is Protected Headers for Cryptographic E-mail it’s unfortunately not widespread. Proton Mail for example doesn’t support it.

Email metadata is a lost cause, you’ll never be able to encrypt To, From, and that’s some of the most private data out there.

I would agree that is one of Skiff’s benefits, which I did mention above. For a small team that mostly keeps things internal that would be the strongest customer base, unfortunately by itself, it’s quite niche.

This doesn’t really help with incoming email from various sources or if you have to share something sensitive with an external user.

I’ve seen that on Telegram and Discord as well. The main concern is that Discord encourages users to hand out their phone number, and provides no E2EE on messages. While it could be argued there nothing is really private there, inevitably you’re probably going to field support requests from that source. Discord’s privacy policy is a bit opaque when it comes to collecting data for advertising, where it ends up, etc.

For user support I actually think a forum-styled system is better because bar of entry is low, and content can stay up there long term, and it certainly helps with SEO. Common go-to services for this are https://www.useresponse.com and https://uservoice.com.

They do, it was just something that I noticed. Might be worth adding that to the bottom of your page footer. This had no bearing on listing, but I thought it was worth mentioning anyway.

Okay, that wasn’t really obvious to me.

Just to clarify, I was not saying that VC funding is bad, or anything like that, only that it is cruicial to viability of a company to continue, especially during the early days. VCs do without a doubt want to see a ROI.

Yes I noticed that, and I figured as much. I do get that creating an email provider from scratch is hard because you basically have to provide what users of other services already have. Your competition is well resourced, Google, Proton etc.

Yes, I’m well aware they do that.

:+1:

Are any of them public? I would be curious to take a look.

3 Likes

They’re not in a publishable format today, but we are undergoing one with Cure53 (https://cure53.de) next that we plan to publish.

Also, to clarify the E2EE doc case, I agree the UX is worse but you could create a Skiff document, create an editable link, add a password, and send it out to get the same benefit as a password-protected email. We hope to add that feature soon.

I’m really glad to hear that :+1: .

You’d still have to send out the link, which would be difficult.

Couldn’t you just make a doc, make a public link, and send that via email? Doc stays E2EE (you can add password).

I agree this is more complex than an email password button, but we had originally made this use case with Pages (our first products) so you could share E2EE data externally.

I’m not sure why that site is replying with those results. If you look at hardenize.com, you can see it is a clean report.

I also reran the test on internet.nl and it shows the correct results when I ran it. I’m unsure why when you ran it, it didn’t show a lot of those protocols showing up.

The github issue mentioned that it was acceptable to have SES as long as there is a plan to deprecate and this is also reflected in the listing criteria.

However, I personally believe this is minimal risk as our servers with TLS 1.2 and ciphersuites are prioritized over SES. The SES server should only be used if our primary server is down as mentioned in the comment. This is also mitigated that email clients (sending servers in this case) will negotiate the highest possible TLS and cipher available to it and the server (Skiff’s mailserver in this case).

I believe that this poses a minimal risk to users but acknowledge that downgrade attacks can happen. For this reason, we have a plan over the next 3-6 months to deprecate SES as a backup solution.

I agree on the ciphersuite ordering issue and security.txt. I’ll get the security.txt in this week but hopefully sometime tomorrow along with the ciphersuite changes. Appreciate the help here!

Isn’t sending a link via signal or some other E2EE messaging platform more secure than a link sent over email? I would certainly think so. A user isn’t prohibited from sending over email and we can do some UX to make it more integrated for sure, but the ability at the end of the day is there along with using a more secure transmission mechanism like Signal. I would argue that is stronger.

This is a terrible user experience that in practice users will never do. Nowhere on the site instructs them to do this to circumvent limitations in the product. One of the main points of email is that it is an immutable copy, like a letter in the mail. It cannot be changed or revised after being sent.

The criteria on the site is very much an entry level bar (must pass to even consider discussion), it isn’t however exhaustive. Some things are more important than others.

Unlike other websites we do thoroughly test the products before adding them. It has to pass the “would I recommend this to my client test” as well. I work in an area, where I provide consulting services. It is often my job to find a solution to recommend to my clients that can solve their particular use case.

Not so sound paranoid, but I wouldn’t be at all surprised if there wasn’t a PRISM ingestion point on the SES network. Without E2EE to external users there will be a high chance that email won’t be so private.

I do see three major issues preventing Skiff Mail from being added at this time:

  • Not E2EE as soon as it leaves Skiff network, not warning to users about this, essentially leading users to believe everything is E2EE. The blog article on E2EE is a good explanation of what E2EE is, however the product does not reflect this description in practice unless, you’re a Skiff user sending to other Skiff users.
  • No ability for users to leave Skiff, if they decide it doesn’t work for them, there are going to be users who decide they need nested folders and filters to sort email.
  • No ability to get email header information, this is important for forensics or determining whether email received is phishing.

It however may be more appropriate to recommend this product on our Cloud Storage - Privacy Guides page or Notebooks - Privacy Guides section. Of course, I would really like to see that Cure53 report first.

I’m also keen to hear back from @amilich in regard to the other issues mentioned in my previous posts. I’m also curious to know where the “30,000 external users” data comes from, because I’ve noticed you say this a few times here, and on Reddit. I don’t believe that is true at all.

I do obviously understand that will take time to reply.

2 Likes

It is very worrying that you do not have an answer to why this occurred as it comes from your own DNS configuration. If it doesn’t show now it means that you have changed the config. I am happy if it is solved, but does that ensure it won’t happen again. Did someone test in production?

If TLS is set to preferring a certain version it is prone to downgrade attacks. Many evil governments make use of this to extract user meta data therefore it is better to enforce it. Nobody realistically relies on TLS 1.2

Also yet again it shows the issues mentioned above today: Email test: skiff.com

It’s quite demoralizing and frustrating from the corporate experience to be put in this position (I’m Skiff’s CEO). I see the greatest success for Privacy Guides to work with companies to make more privacy-respecting, secure services. We’ve done exactly that in good faith - respecting your criteria and allocating engineers on our team to get us to the point of recommendation. This costs an enormous amount for a product to implement.

We’ve now spent months implementing all of the best practices, both because we want Skiff to be as secure and private as possible, and because we want to be recommended on your guide. We’re becoming quite popular (almost half a million users in the last year) and would love to share and help grow your community while ensuring that products are held to high standards. Moving the bar constantly is extremely frustrating and demoralizing to our team. Transparently, it’s hard for us to even believe that the criteria are created in good faith.

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. It’s both confusing and frustrating to require that we implement a less powerful, worse experience that was never part of the original spec.

Email headers is a reasonable feature to look for, but password protected emails and feature requests (like nested folders) are completely out of place.

2 Likes