[itsibitzi]

Tech lead on the project here.

I would certainly recommend that readers not use a work phone, not only for the reasons you've stated but also that a lot of work devices use mobile device management software which is functionally spyware. To your point, dealing with having a very small anonymity set is tricky regardless of the technology used.

We do go to great lengths to make usage of the app to blow the whistle plausibly deniable. Data is segmented to "public" and "secret" repositories, where any secret data is stored within a fixed-sized/encrypted vault protected by a KDF technique that was developed by one of the team in Cambridge (https://eprint.iacr.org/2023/1792.pdf)

But of course, all this could be for nothing if you've just got corporate spyware on your device.

This is certainly something we've talked about internally but I've double checked the in-app FAQs and I think we could be more clear about recommending users not use on a work device, especially with MDM. We'll get that updated as soon as possible. Thanks!

-- edit

I should add that we do some basic detection devices that have been rooted or are in debug mode and issue a warning to the user before they continue. I'd be interested in what we can do to detect MDM software but I fear it might become a cat-and-mouse game so it's preferable that folks not use their work devices at all.

[mdhb]

Yeah besides that bit of feedback, I think the project is brilliant and actually has a lot of nice parts to it that go way beyond the technical aspects but really show a sophisticated understanding of what you actually want out of a real life somebody might end up seriously harmed if this goes wrong covert communications system so kudos to you and the team on that!

Edit: you might want to consider putting that warning about work devices in the app itself right before someone pushes forward with making potentially life changing decisions and doesn’t rely on them reading an FAQ. I see you already have an onboarding flow in place. It would be really simple to make that the first screen of it.

[itsibitzi]

I agree, it should certainly be front-and-centre, either the landing page or the on-boarding carousel.

I'll see if we can get something together before the next app release. Thanks again!

[irq-1]

Any plans for spam? Does the app have a device id or account, so you can disable them?

If the message is encrypted for the reporter and they're the only ones who can read it, what does the organization do to manage this? Are passwords for private keys saved with the org, or are the keys saved with multiple accounts? What do you do when someone forgets their password?

Cool app; just encryption management when it comes to human users must have lots of trade-offs.

[itsibitzi]

On spam:

We’ve got some basic filtering for full on DoS type attacks already.

The difficulty here is that a user can produce a reasonable amount of spam from a spread of IP addresses which would be disruptive to our journalist users but below threshold to be considered a DoS attack.

It’s tricky because we can’t have anything that could link a given message to a given user as that would break anonymity.

We’ve got some ideas with anonymous credentials from app attentions for the more long term. E.g. if you’re expected to submit 1 message an hour from your queue you can request 24 single use tokens from the API by performing an attestation that you’re running a genuine app. You then spend these as you send messages. We don’t have a full spec for this right now such that it can be fully anonymous but that’s the general idea.

There’s also some possible spam detection we can do in the journalist GUI which we’re interested in exploring. Right now the spam control is quite basic (muting) but the message rate is low due to the threshold mixer anyways so not so bad.

On key management:

Each journalist has an encrypted vault which requires a key derived from a password. If this password is lost and the journalist has no backup then it’s game over. We need to regenerate their identity in the key hierarchy as if they were a new user and messages they’ve not seen are lost, there is no way to pick up those sources again.

We have some plans on using MLS as an inter-journalist protocol which should enable having multiple actual humans per journalist/desk listed in the app. That would depend on the journalists agreeing to have their vault be shared of course. Once multiple humans are backing a single vault then the risk of password loss becomes smaller as if one journalist loses their password the other journalist should be able to share their back messages to them.