i2p.android.base/TODO

# Fixes

- Better twopane column widths
    <zzz> on the i2ptunnel and addressbook pages on the tablet, the columns are too skinny, they aren't as wide as the tab
    <zzz> only a few addressbook entries wrap but on i2ptunnel everything is wrapped and most of the screen is empty
- Create tunnel wizard
    <zzz> hmm would be nice if they could be shared-client or have an option
    <zzz> was setting up email tunnels
- Browser
    <zzzccc> Bug report: i2p browser treats 302 as an error
    <zzzccc> Bug 2: rotate screen in i2p browser seems to go back one page
- Console lights go out when navigating from addresses tab (tab or swipe)
- Better handling of FABs obscuring content
    <psi> str4d: the + button on the tunnels screen gets in the way of opening kytv's irc tunnel
- Fix race between RouterContext initialization and first console status update

# Short-term

- Disable uPnP when on cell networks
    <zzz> spewing UPnP out into cell networks is a waste of time at best and a security risk at worst, but you really want it for wifi
- I2PTunnel
  - Improve tunnel list status indicators
  - Show all messages somewhere
  - Improve detail page
- Progress feedback for addressbook subscriptions reload
- Display release notes directly on new router version
- Fill out help pages
- Rewrite release notes to be release-specific
- Fix release notes UI, either make back button use clear or add buttons
- NetDB tablet view fixes
  - Refresh detail fragment when changing tab
  - Move list to correct item when changing tab
  - Create nav history when viewing RI from LS
- Include GeoIP db for country info
- Maybe change router-off mechanic for various pages? Enable as they become available?

# Medium-term

- Network profiles
  - User selects profile in settings
  - Change network participation etc. based on profile
  - Also look at connection type: Connectivity.isConnectionFast()
- Expose log level overrides
- Improve graphs
  - Show time on bottom axis
  - Show fixed x range, not only available data
  - Think about pan/zoom
  - How to persist data across restarts?

# Silent Store approval checks to confirm/implement

- Known Vulnerabilities
  - Apps will be tested to ensure that they are not susceptible to known
    publicly disclosed vulnerabilities. For example:
    - Heartbleed
    - Poodle
    - MasterKey
    - Common Path Traversal attacks
    - Common SQL Injection attacks
- Network Security Protocols
  - All Apps that require transmission of data from the App to a system that
    does not exist on the device must use, at a minimum, TLS1.1 standards.
    However, Blackphone would prefer the usage of TLS1.2.
  - Apps must not use algorithms for cryptographic purposes that are considered
    obsolete or outdated i.e. MD5, SHA1, RC4, DES, or any encryption algorithm
    that is weaker than AES128.
- Transport Layer Protection
  - All network communication should be encrypted
  - Not vulnerable to SSl Strip
- Data Leakage
  - No storage of sensitive data outside of application sandbox
  - Files should not be created with MODE_WORLD_READABLE or MODE_WORLD_WRITABLE
  - Copy & Paste will be evaluated on a case by case basis
  - App logs should not contain sensitive information
- Authentication and Authorization
  - Validate that authentication credentials are not stored on the device
  - Must use an approved password-based key derivation function ie. PBKDF2, scrypt
- Data-at-rest Encryption
  - Must use at a minimum AES128 with modes CCM or GCM
  - Should not store the encryption key on the file system
- Permission Checks
  - The App must function with all permissions disabled
  - Apps must not hard crash if a permission is disabled
  - Apps should ask users to enable permissions that are disabled if needed to
    function properly and explain why the permission is necessary
- Privacy Policy
  - Apps must have a privacy policy that details how customer data is used,
    stored, shared, etc...
  - Apps must be configured with the customer opted out by default
  - App logs should not contain PII
- Error Handling
  - Apps should follow best-practices for error handling and logging

# Long-term

- Remote router support
  - Implement a "router wrapper" that can represent a local or remote router
  - Implement/use client APIs to talk to remote router
    - I2CP
    - I2PControl