The marketing site says there’s full text search. The paper doesn’t cover this. How is this being solved here?
Seems trivial enough to do client-side on modern hardware, especially if you exclude attachments.
Skiff – Privacy-first end-to-end encrypted email
41–50 of 201 posts
Re: Skiff – Privacy-first end-to-end encrypted email
#42The marketing site says there’s full text search. The paper doesn’t cover this. How is this being solved here?
Seems trivial enough to do client-side on modern hardware, especially if you exclude attachments.
Without producing confirmation side channels and so on? Doesn’t seem that trivial- at least it needs more thought than assumption of simplicity
Re: Skiff – Privacy-first end-to-end encrypted email
#43The marketing site says there’s full text search. The paper doesn’t cover this. How is this being solved here?
Seems trivial enough to do client-side on modern hardware, especially if you exclude attachments.
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.
Re: Skiff – Privacy-first end-to-end encrypted email
#44I’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.
Re: Skiff – Privacy-first end-to-end encrypted email
#45The marketing site says there’s full text search. The paper doesn’t cover this. How is this being solved here?
Done completely client side. We actually have multiple blogs on this - https://skiff.com/blog/private-search
Re: Skiff – Privacy-first end-to-end encrypted email
#46Earlier quoted context omitted.
> 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 ex…
Signal doesn’t have a web client. Most of the stores it is distributed through have fairly strong resistance to compel orders.
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.
Re: Skiff – Privacy-first end-to-end encrypted email
#47So 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
Re: Skiff – Privacy-first end-to-end encrypted email
#48Earlier quoted context omitted.
Founding engineer at Skiff here. >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…
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 he…
It would be far more illogical to warp Matrix into an end-to-end encrypted calendar, note-taking product, file storage product, and email platform.
Re: Skiff – Privacy-first end-to-end encrypted email
#49Earlier quoted context omitted.
Seems trivial enough to do client-side on modern hardware, especially if you exclude attachments.
Without producing confirmation side channels and so on? Doesn’t seem that trivial- at least it needs more thought than assumption of simplicity
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.
Re: Skiff – Privacy-first end-to-end encrypted email
#50The marketing site says there’s full text search. The paper doesn’t cover this. How is this being solved here?
Done completely client side. We actually have multiple blogs on this - https://skiff.com/blog/private-search
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.