@sarahjamielewis@mastodon.social
@sarahjamielewis@mastodon.social avatar

sarahjamielewis

@sarahjamielewis@mastodon.social

Cryptography and Privacy Researcher. Executive Director @ Open Privacy Research Society (https://hachyderm.io/@openprivacy).

Founder @ Blodeuwedd Labs (https://mastodon.social/@blodeuweddlabs)

Building free and open source, privacy-enhancing, surveillance-resisting tech like Cwtch (https://fosstodon.org/@cwtch)

This profile is from a federated server and may be incomplete. Browse more on the original instance.

sarahjamielewis, to random
@sarahjamielewis@mastodon.social avatar

I'm somewhat perplexed by the new SecureDrop protocol - https://securedrop.org/news/introducing-securedrop-protocol/

Specifically: "The server is “untrusted” in the sense [it] learn[s] nothing about users & messages besides what is inherently observable from its pattern of requests, and it should not have access to sensitive metadata, or sender or receiver information"

Seems like a very weak definition of "untrusted", especially when two comparison techniques explicitly attempt to restrict knowledge derived from access patterns.

sarahjamielewis,
@sarahjamielewis@mastodon.social avatar

Further...doesn't the servers ability to produce arbitrary valid ciphertexts (not really forgeries as it's an explicit requirement) allow a range of active attacks against recipients?

I'm not entirely sure of the consequences there, but it seems incompatible with the optimized decrypt-fetch message id (as it allows the server to test and trigger).

Removing the optimization effectively brings you back to download-all and trial decryption (with server forgeries there becoming effectively noise)

sarahjamielewis,
@sarahjamielewis@mastodon.social avatar

The motivation for private server state is "there isn't enough traffic going through the system to provide a reasonable anonymity set to any observer so we want to minimize observers"

Which is reasonable, but then the server is explicitly not "untrusted" - it can perform all the same statistical attacks...you effectively limit the adversary space to the server.

And if so (and you are unwilling to trust the server) then your risk model becomes that addressed by PIR or OMR.

sarahjamielewis,
@sarahjamielewis@mastodon.social avatar

But instead the protocol explicitly allows the server additional capabilities by granting it participation in generated receiver key material (and bloating the ideal communication cost)

Any optimization you make to reduce that cost grants the server additional information. Either making the server trusted in arbitrary ways or compromising one of the desired properties.

sarahjamielewis,
@sarahjamielewis@mastodon.social avatar

The protocol itself is interesting, involving the server in that way has that nice property of hiding valid ciphertexts from all other parties - I feel like I've seen a flow like it before, somewhere, but nothing immediate comes to mind.

I suspect you could probably hack in authentication into that flow somehow which could have useful applications.

But the protocol doesn't feel like it solves the problem? Or rather, the strengths of the protocol don't nicely map to desired properties.

sarahjamielewis, to random
@sarahjamielewis@mastodon.social avatar

I had a chance to sit down and read Tor: From the Dark Web to the Future of Privacy by Ben Collier (@susansegfault) - https://mitpress.mit.edu/9780262548182/tor/

I highly recommend it. I think it captures the history beautifully and its a nice reminder of how these projects play out over decades.

It can be very easy to get caught up in the day-by-day/week-by-week rush/drama/critiques/effort and having a history like this puts that nicely in perspective.

Go read it.

sarahjamielewis, to random
@sarahjamielewis@mastodon.social avatar

Please steal these project ideas: https://sarahjamielewis.com/entry/privacy-projects.html

A list of research/project ideas that I have no time to pursue fully, but which I would be very interested in helping out/mentoring. If any of these sound interesting then please get in touch.

sarahjamielewis, to random
@sarahjamielewis@mastodon.social avatar

People have a right to access and use secure tooling that enables them to leverage modern cryptography.

The alternative is absurd. A demand to deliberately subvert foundational economic infrastructure. A position that should be laughed out of any sensible room.

sarahjamielewis,
@sarahjamielewis@mastodon.social avatar

If, through some twist of fate, the printing press had arrived after the internet we'd be reading op-eds about the dangers of "anonymous reading" and demands for "accountable bookselling"

sarahjamielewis, to random
@sarahjamielewis@mastodon.social avatar

For a while now I've been thinking about where microblogging/blogging fits in my life.

After various experiments over the years, I settled on going back to writing my website in a text editor, without regard for consistency or categories.

But inspired by @molly0xfff Activity feed, I spent this evening implementing one for my own personal site: https://sarahjamielewis.com/feed.html

A place for me to microblog, collect thoughts, post links, document updates, new papers etc. all in one place.

sarahjamielewis, to random
@sarahjamielewis@mastodon.social avatar

On reviewing privacy preserving tools:

This is not a new discipline.

We have mathematical and engineering tools to do analysis.

We have decades on decades of research literature, rooted in cryptographic analysis, statistical methods, probability theory, and computer science detailing how privacy preserving system are broken.

Just how one can tell that a badly engineered bridge will collapse before it is built, one can assess that a "privacy preserving" tool will not preserve privacy.

sarahjamielewis, to random
@sarahjamielewis@mastodon.social avatar

I really, really don't want to be calling out specific people or projects, I don't think it's a useful thing to do - but it makes me so sad to see people, whose work I deeply respect, volunteering/writing/promoting a tool whose privacy claims are fundamentally unsound.

Privacy tools that a metadata resistant are essential, but please technically vet the projects you a promoting.

sarahjamielewis,
@sarahjamielewis@mastodon.social avatar

I feel like the one major lesson I learned from the crypto-hype era is that most people don't care about technical arguments, at all.

There are projects tackling hard problems using sound methodologies, there are projects talking about hard problems and selling a story (either intentionally, or because they don't know any better).

There is a difference between those two kinds of projects and I wish more people cared about that.

sarahjamielewis,
@sarahjamielewis@mastodon.social avatar

I don't want to "name and 'shame' such projects because it doesn't work, they thrive on the attention and few listen to the actual arguments anyway.

The system I see people promoting is "not-even wrong", it cannot do what it claims to do because that is not how the universe works. The key claims rest on axioms that are not practically possible.

I too could claim miraculous system properties if I could assume everyone magically and securely exchanged key material before using my system.

sarahjamielewis,
@sarahjamielewis@mastodon.social avatar

Usually I wouldn't say anything, there are so many bad privacy projects out there, I get asked about them all the time and are just a fact of life in this space.

But there is a blog post going around, advertising this project and it's gained enough traction within a community a deeply care about that I need to at least say something.

Please do some due diligence before promoting unsound privacy tools. People rely on these tools. People trust their lives to these tools.

sarahjamielewis,
@sarahjamielewis@mastodon.social avatar

And as experts and participants in this space you have a responsibility to give a damn about that.

sarahjamielewis,
@sarahjamielewis@mastodon.social avatar

A few people have asked for specific details, and I'm not going to call out a specific project; However, someone asked about general red flags and I will list a few here:

Beware of "metadata resistant" privacy apps that:

  • Advertise Real time Audio / Video.
  • Have Offline messaging on mobile / without self hosting some kind of server
  • Have "No Identities"
  • Rolled their own onion-routing
  • Rolled their own mixnet
  • Implement offline storage with 3rd party servers that is somehow efficient.
sarahjamielewis, to random
@sarahjamielewis@mastodon.social avatar

A topic I would love to read a deep analysis on is how certain actions e.g. blocking, moderation/filtering, "self-deleting" messages etc. transform from passive server-side actions to client active actions in decentralized systems and if/how that breaks down against existing ingrained metaphors and expectations.

sarahjamielewis,
@sarahjamielewis@mastodon.social avatar

I have frequent conversations that fit under this topic; typically either attempting to clarify user expectation or debating implementation in light of that expectation.

My general speculation is that our current nomenclature is insufficient and too rooted in, and shaped by, existing, centralized systems.

sarahjamielewis, to random
@sarahjamielewis@mastodon.social avatar

Something that does trouble me is that most people who try out @cwtch try out the Android version - it is the way of the world that mobile computers are far more numerous than others.

But this does give a terrible first impression because as much as we have invested into Android over the years it still does not come close to the stability and usefulness of the desktop versions.

Metadata resistant communication is hard. Metadata resistant communication on mobile is harder.

sarahjamielewis,
@sarahjamielewis@mastodon.social avatar

And that approach also means that communication will likely always have strong limitations like both parties being online at the same time, dealing with the latency of onion services, and the need to run background services - the latter being a particular challenge on mobile devices.

sarahjamielewis,
@sarahjamielewis@mastodon.social avatar

And while I understand all of this, I am also disheartened.

I've poured my soul in Cwtch these last few years because I fundamentally believe that that is how an application should be - locked down by default, open to extension, free and open source, based on sound cryptography, no centralized servers or magic peers or any other surveillance chokepoint.

And it's hard to see Cwtch failing in comparisons because those things are not features, they are limitations.

sarahjamielewis,
@sarahjamielewis@mastodon.social avatar

I also tend to bite my tongue these days because the space is filled with messengers who make similar promises regarding metadata resistance while also offering real-time video chat and transparent offline messaging - feats which, if true, I would hail as academic breakthroughs.

sarahjamielewis,
@sarahjamielewis@mastodon.social avatar

Clearly I need to do a better job at distinguishing what makes @cwtch good - and I wish we had the budget to really try and solve some more of the harder problems in the space.

Cwtch needs more champions, and more volunteers. People who can tackle those problems, and to bug me to focus on fixing specific issues.

The code is here: https://git.openprivacy.ca/cwtch.im/cwtch-ui

The user/security/dev handbooks are here https://docs.cwtch.im/

sarahjamielewis,
@sarahjamielewis@mastodon.social avatar

If you would like to get involved, then please reach out to me (details in profile or on my website) I will happily help find you some way to contribute (see also https://docs.cwtch.im/docs/category/contribute).

I really, deeply believe that the world needs metadata resistant applications - not just chat, but everything. The push for end-to-end encryption was a great start, but we need stronger security models for all kinds of communication.

Help us build that in the open.

sarahjamielewis,
@sarahjamielewis@mastodon.social avatar

Lastly, I saw a few comments today in the vein of "not much progress has been made recently" and I would like to refute that.

While @openprivacy had to make some significantly cut backs in recent years due to a decline in funding, everyone on the Cwtch team has contributed so much over the last few years.

We have put out a new version on average every 6-8 weeks, consistently for the last 2.5 years while making major improvements to all aspects of Cwtch (see the devlog https://docs.cwtch.im/blog)

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • anitta
  • Durango
  • magazineikmin
  • InstantRegret
  • hgfsjryuu7
  • vwfavf
  • Youngstown
  • slotface
  • thenastyranch
  • ngwrru68w68
  • rosin
  • kavyap
  • PowerRangers
  • DreamBathrooms
  • cisconetworking
  • khanakhh
  • mdbf
  • tacticalgear
  • ethstaker
  • modclub
  • osvaldo12
  • everett
  • tester
  • cubers
  • GTA5RPClips
  • normalnudes
  • Leos
  • provamag3
  • All magazines
    •