Feature request: Sending dummy short messages

[stefanb]

TextSecure could mask meaningful communication between people by occasionally sending dummy random messages to random recipients at random times:

• Recipients would be chosen randomly between contacts that knowingly use TextSecure, so it could be recognized as such after decryption and automatically discarded by recipient.
• "Randomness" should be tweaked to level-out the legitimate messages, spoiling the traffic analysis of traffic retention data, preventing to weigh connections in the deducted social network graph or guessing sleeping/activity patterns.

People often have many unused messages in their monthly quota, so those could easily be used with no extra cost, or they value their privacy more than some money. Sender would need to enable this feature (opt-in) and define desired quantity (eg max 100 dummy messages per month, 2 dummy messages for every legitimate one, max 500 messages total counting legitimate and dummy ones...). The feature would need to be aware of roaming (disabled by default, optionally enable) and battery level (do not send if bellow eg. 30%).

http://en.wikipedia.org/wiki/Traffic_analysis#Countermeasures

Possible extensions:

• Recipients could be able to let their peers know, that they do not want to participate in this and do not want to receive messages for whatever reason (opt-out).
• Recipients could also be chosen randomly between other contacts (those not using TextSecure yet) to promote its use (default message) or a custom explanation by sender. Those messages would be in clear text. As this might be annoying it should be very limited (eg max 1 message to a single recipient per month, only during daytime...) to not be too intrusive spam.
• Dummy messages could contain other peer's phone numbers (random selection from those participating in dummy messaging, not just their contacts), never to be shown to user, just to send dummy messages to, to further mask the real social network. It would be tricky to opt-out later on once your number starts circulating, so opt-outs would need to be spread this way as well and by direct reply dummy message or by defining a TTL of each such number.

[mitar]

I really like this idea.

[generalmanager]

+1
great idea to thwart traffic analysis!
With the data channel now working that's not even going to cost anything. The ability to limit this feature to the data channels is important tough.

[geileszeuch]

Even with data this is going to cost battery life and data volume for people not having unlimited data, but a restricted amount of mb per month. And if this is really going to happen, then not only the sender, but also receiver should be optional, since his battery/data plan is going to suffer, too.

[generalmanager]

@geileszeuch I don't think making the reception of those messages optional is a viable option, as it would greatly reduce the usefulness - hardly any users ever go into the advanced settings, where this option would surely be hidden away and only a miniscule percentage of users will ever activate the random sending . Even if everybody who randomly sends also randomly receives, the userbase is simply not going to be big enough to make any significant impact.

If this feature sends a few (<25) messages each day at max, the influence on battery drain and transferred data would be so miniscule on both ends that it shouldn't play a role.

[stefanb]

This was designed with SMS in mind, where traffic data retention makes it very easy to re-create social graphs. The same principles may apply also to data connection.

To have big enough peering group the option should be enabled by default, but allowing users to opt-out or set their preferred caps (SMS, WiFi, 3G...).

The real issue remaining with this is that real to dummy rato should be very high in order to hide the real social graph in enough noise, otherwise such white noise could easily be filtered out. Alternatively the peer choices shouldn't be truly random, but artificially building a stronger fake network (eg randomly weighing the random contacts initially, then choosing them based on their weight. Weights can be adjusted slowly over time and sometimes randomly introducing new peers...)

It is also important that the fake network is built not only from user's own contracts, but also from contacts' contracts' ... contacts. This data could be distributed as payload of dummy messages, together with TTLs, distance (hop count for limitation) and opt-outs.

Fake network's statistics (peer, hop & message count, data usage) could be shown to user to help him adjust the limits or decide to opt-out.

[ncruces]

You guys speak of 25 random texts a day as if it was minimal usage.

I live in a EU country and my plan includes 100 outgoing texts+minutes and 200MB a month. Data is also charged in 100KB increments (so, there are about 2000 "buckets of data" to spend every month). It's a mighty cheap but limited plan.

Not everyone in the world is on a $50+ a month everything unlimited and gigabytes of data plan. Some people pay for every single text and data connection, incoming or outgoing. Doing this by default is a big no.

[generalmanager]

@stefanb I like your ideas about the fake network with adjusting weights.
But we simply can't activate this feature by default for the average user, the cost for SMS in Europe is just too high. I'd like to choose this as a default setting for highly endangered users as I explain in #838 but hide it away in the advanced settings from the W***sap people.
Maybe we can activate a low message data/wifi only version for moderately security concious folks.

@ncruces I think this should be off by default for most users. When I threw the number of 25 into the room, I was talking about instant messages, not SMS. I should have been more clear about that. And the amount of data even 100 instant message produce is miniscule.

Do you mean that data is basically accounted like calls aka every minute you begin counts?
If that's true and translates to:

• continuous surfing, using 1MB od data costs you 10 packages of 100kB
• 10 bursts of 1kB each with a long period of time between them only uses 10kB but you're accounted 10 packages of 100kB

This would be the most atrocious data plan I have ever heard of. And it'be completely useless for smartphones, because push messages for mail notifications and similar stuff always produce short bursts of only a few kB every now and then.

I have a plan with 1GB of data volume, after that it's capped to 128kbit/s but I don't get charged any more. I pay for every SMS and minute, but I don't call or text much and at 7 cent each they aren't that expensive either.
Many people I know either have a similar plan, or a student plan with ~200-500MB data, ~200 minutes and ~200 SMS for 8-12€/month

[ncruces]

Yes @Lindworm, that's what I'm saying. Some operators use 100KB, others 10KB, all do it.

I pay €15, but I know others on €7.50 prepaid "plans". I see no point in paying more, regardless of being able to afford it.

This is in the EU. Mobile operators around the world have the craziest billing rules. Users must be in charge over these things.

[stefanb]

I too am in EU and pay each SMS,call, and kB individually, because i still have a very old, cheap pay-as-you-go plan. However newer plans in recent years include 1000s of SMSes, that (IMO) cannot possibly be used manually (people take it for various reasons - subsidized phones, included data or minutes...).

Having this preference as part of a setup wizard #838 is also fine, as long as wizard complexity won't deter users from setting up the app.

[generalmanager]

@stefanb I want to accomplish the opposite of what people appear to associate with setup wizards. That's why I just changed the headline. I just want to ask the user if he wants:

• high convinience + high security
• medium convenience + very high security
• low convinience + paranoid security

Depending on the user choice, we'll activate a bunch of more complex features.
This one would be a prime example.

[GAS85]

Small comment how to increase battery live time. In EU some of operators get an agreement with google and other app developments to use background data traffic no more than once in a half an hour, even google advertisements are cached to do this. And yes, feature should be tunable and in default off (who needs paranoid security knows how to enable it).

[monreal]

This is one of the ideas that sounds great first but can turn out into a very bad thing pretty quickly... at least when implemented on top of the SMS transport. I am not even talking about costs here.

Let's see:

• This kind of feature mostly makes sense to protect users from their own state/government/regime.
• In such a scenario the mobile communications infrastructure is very likely to be controlled and monitored by "the enemy".
• In order to mask meaningful traffic, you would need to send a lot of fake messages. Maybe something like 10 times the normal amount. If you don't do this then it is way too easy to check all recipients for plausibility manually.
• The "random" contacts cannot be very random. After all you are more likely to text people near you and not some hundreds or thousands of miles away. If in doubt, "the enemy" would just pick the closest ones first and most likely find at least some of your real contacts.
• Finding random unknown TextSecure users that live near you (= plausible communication) is not possible because mobile numbers are not bound to locations.
• Faking communication with random users could also put those users in danger. Imagine someone being monitored and seen to be texting a low with some random contact. Surely that random contact will be monitored as well now and he couldn't even know why.

Things are a bit different for push, but at least for SMS this should not be implemented.

[stefanb]

Tnx, all doubts are welcome so we can discuss them before (if ever) rushing to implementation.

• The "random" contacts cannot be very random. After all you are more likely to text people near you and not some hundreds or thousands of miles away.

How about putting nearby users in the same location bucket? Eg if users exact lat,lon is 1.234567,-9.876543, rounding it (for privacy and appropriate bucket diameter) to 1.23,-9.87, then name the bucket someHash("1.23,-9.87"). It needs to be adjusted so that neighboring buckets are overlapping a bit and that bucket name is short enough.

• Faking communication with random users could also put those users in danger. Imagine someone being monitored and seen to be texting a low with some random contact. Surely that random contact will be monitored as well now and he couldn't even know why.

Exactly. Imagine repressive regime suddenly "having to" keep a close eye on 10-times more individuals or risk losing the "suspect" in the noise of fake social graphs. It is a lottery, similar to hosting a Tor exit node.

Things are a bit different for push, but at least for SMS this should not be implemented.

Is there any documentation about how the push messages are travelling? Over a central server or directly between peers? I havent seen that in ProtocolV2 documentation.

Other things to consider:

• Overloading the networks during the time of crisis
• Operators suddenly introducing "fair usage policy" also for messages, as their business model now relies on selling never used-up quantities.
• Some sort of amplification attack crippling the communication, giving operators the legitimate excuse to block (or reduce priority of) all base46 encoded messages (regex, Steganography #167 )

[monreal]

How about putting nearby users in the same location bucket?

So TS users would send this information to a central server and it would be stored there for anyone to fetch?

Imagine repressive regime suddenly "having to" keep a close eye on 10-times more individuals

Well, it does not mean they would drop monitoring the original user and depending on how good "our" technology is compared to theirs, they would probably not lose much. On the contrary, just finding any other user of a "privacy tool" could be a "win" because those tools would probably be illegal to use in such a scenario.

[generalmanager]

@stefanb

This is horrible for SMS.

Faking communication with random users could also put those users in danger. Imagine someone being monitored and seen to be texting a low with some random contact. Surely that random contact will be monitored as well now and he couldn't even know why.
Exactly. Imagine repressive regime suddenly "having to" keep a close eye on 10-times more individuals or risk losing the "suspect" in the noise of fake social graphs. It is a lottery, similar to hosting a Tor exit node.

I think what he wants to say is, that they don't have a choice, as with for example bittorrent (TOR uses routers and not every client is a router) the user knows (or at least should know), that other peoples activities, if surveilled, may lead to him getting in trouble. But he can choose to use bittorrent or not.

And with special privacy tools like I2P, the prosecution/police knows, that they can't just bust somebody if his computer delivered a certain message, because it may well have come from somebody else, who the user doesn't know.

But the police in undemocratic countries doesn't currently know that users may get unsolicited messages from political activists and protesters.
So they will probably just "interrogate" them, which would basically be our fault.

Consider the current situation:
Only people who actually DO have something to hide install TS.

This would mean the state wouldn't even have to suveil all phone numbers to find activists with DPI (for SMS), they just start with one activist using TS and he'll text all the others. And they are unconnected, which means the police wouldn't even have found out about the other TS users (which probably also have something to hide)
They would only have to bag them all and throw them into some dark hole. First because they don't know about the technology, and later because they found that, even if the people aren't connected to the original suspect, they still confess to a lot of "crimes" when interrogated, because they assume the police found out about their political activities and is interrogating them because of those, not some random message they don't even know they even received.
And TS would pretty quickly be called a spy tool by the opposition, meaning that nobody will use it anymore.

How about putting nearby users in the same location bucket?
Then we would have a database on the server connecting phone numbers to TextSecure users.
That would mean not only the local cellphone provider and state could know who uses this "subversive tool" via DPI, but everybody who may compromise the servers.
I don't think that's too bad, because the information is only critical for the local authorities, who can get them the old fashioned way, but we should consider it.

What happens when TS becomes popular in a region?

When we have a significant userbase (maybe 3-5%) of all users in a country with TS installed, we could then activate this feature for the "paranoid" users, and tell them about it. The jump in traffic would be obvious and police would pretty quickly be aware of this feature and that the people somebody texts often aren't connected to them in any way.

Still, some people will get hurt, until the police understands this, but we at least minimized the effect.

That there are now also lots of innocent people using TS won't mean the government doesn't put them on a watch list, but the government probably doesn't have the resources to "interrogate" everybody.

For data we could probably turn it on without a problem, because the connection to the google push servers is encrypted and widely used.

For SMS however, we have to turn it off by default, until we have a big userbase.

[stefanb]

@monreal

How about putting nearby users in the same location bucket?

So TS users would send this information to a central server and it would be stored there for anyone to fetch?

Not for everyone, just between some peers until a certain degree of distance (logical as in contact hop count and geographical as within the same or nearby buckets). End-to-end encrypted as every other message.

@Lindworm
Police of the most stupid regime may be unaware of the feature at most until they interrogate one of the users. This was no different to first TueCrypt users (OTR vs. Plausible deniability) or first Tor exit node hosts.

Only people who actually DO have something to hide install TS.

What about CyanogenMod integration?

What happens when TS becomes popular in a region?

Media/activists become aware of this feature and advise users (who can afford it) to enable it en masse.

For data we could probably turn it on without a problem, because the connection to the google push servers is encrypted and widely used.

Then this feature is not critical for push messages at all, as Google's servers are considered trusted as long as the only official build is distributed trough their Play store ( #127 ). Data traffic metadata retention is not that detailed to allow such analysis.

[generalmanager]

Only people who actually DO have something to hide install TS.
What about CyanogenMod integration?

Good point, and it's great that this creates a bigger userbase. But still, most of CM users live in rather developed countries. CM's adoptance could help in India and Thailand, but in most African and Middle-Eastern coutries, people are happy if they can afford a smartphone in the first place.

In some South American countries like Argentina it may look different, but the usage of custom ROMs is still nowhere near the US and Europe.

Media/activists become aware of this feature and advise users (who can afford it) to enable it en masse.

Media won't say anything. In totalitarian countries, the media is controlled by the state and doesn't even report about big protests. See the current situation in Venezuela for example.

Activists may do so, but their reach is very limited.

[automated-signal]

GitHub Issue Cleanup:
See #7598 for more information.