Prepare for new Forum Sharing Client
Methods for creating, adding and removing forums have been moved to the
`ForumManager`. In order to still handle removing forums properly, a
`RemoveForumHook` has been introduced.
Methods for sharing forums with all current and future contacts have
been removed along with the localGroup where this information was saved.
The `ShareForumActivity` now has the proper label.
The `SessionId` and the `ProtocolEngine` have been moved to the
`clients` package.
This addresses part of #322 and part of what has been discussed in #320.
See merge request !156
Methods for creating, adding and removing forums have been moved to the
`ForumManager`. In order to still handle removing forums properly, a
`RemoveForumHook` has been introduced.
Methods for sharing forums with all current and future contacts have
been removed along with the localGroup where this information was saved.
The `ShareForumActivity` now has the proper label.
The `SessionId` and the `ProtocolEngine` have been moved to the
`clients` package.
This addresses part of #322 and part of what has been discussed in #320.
PanicKit does distinguish between two kinds of panic responses:
* default responses such as logging out which are non-destructive and
do not require user interaction, so that the basics work without
configuration
* destructive responses such as deleting user data. These require
some sort of authentication to make sure they are not triggered
by malicious apps
The second type of responses is implemented with this commit.
Authentication is done by comparing the package name
which is very weak. It requires the user to opt-in to
destructive responses and to configure from which app
to receive those (since there might be many different panic
trigger apps).
While possible to uninstall an app and install one with the same
package name afterwards, this always triggers notifications to
the user (if the attacker does not have root access).
Still that is no sufficient security for Briar's requirements,
so that TrustedIntents are used as well to make sure that the
app sending the destructive trigger is signed by a signing key
that we specified before. Currently, that is the one from the
GuardianProject and from IilabEngineering who does the Amnesty
International Panic App.
The responsibility of checking that the panic TRIGGER is
legitimate lies with the app responding to the trigger, so Briar
in this case. This commit checks whether the TRIGGER comes from
a trusted app before performing destructive actions,
but does perform the default action even when triggered from
untrusted apps.
Closes#210
improved the crash handler and refactored the manifest
Improved the CrashReportActivity by putting the activity within its own process, making it a single instance and making sure it won't show up on the recent app list.
The old structure could create endless crash-loops and might not start the CrashReportActivity on process-related exception such as OutOfMemory because the process simply will not have the resources to do so. This problem is now fixed.
Concerning Roboguide: the problem is that every time a new task is started the xml file will be reloaded, at least with this branch there will not be an endless loop. By updating to Roboguice 3 the problem will be eliminated completely as that version has stopped using the xml file and reverted to manifest tags instead. It is getting very tempting to update.
Closes#67
See merge request !22
The text of the startup failure notification is unhelpful due to lack of
space. Touching the notification now launches an activity that gives details
of the problem and what can be done about it.
Closes#38
