Access to data over the P2P connection in this app is open to anyone with the same app and service name. Posts are shared across P2P based on newsfeed ids and mutual friend ids. In any scenario in which a peer is capable of acquiring overlapping newsfeed ids or friend ids, that peer will have access to any posts that match those ids.
This app relies on Facebook authentication to prevent users from accessing newsfeed ids and friend ids that do not belong to them. However, on a rooted phone, users have access to both the database and the shared preferences that this app uses to cache friend ids. With the capability of modifying this file, rooted users are capable of accessing all the posts visible to other peers from specific Facebook users. A potential solution to this security issue is the implementation of privacy settings on sharing posts. If only a particular set of Facebook users are allowed to see a post, a rooted user will not be able to access that post even if the rooted user has manually modified the friends ids.
In the case of managing who is or is not authorized to connect via P2P, a user can choose who not to share data with. The app uses client’s IP address and MAC address to identify peers. If a user accepts the connection of peer, the Wi-Fi Direct device remembers that connection and automatically accept future requests from that phone. Again, with a rooted phone, another user can spoof a phone’s MAC Address to match one that has been authorized to connect P2P in order to connect to another phone automatically. A way this can be addressed in the future is using the Facebook user ID of each phone as well to judge whether or not a peer is allowed to connect on another layer of security built into the app.
Currently peers will have access to public and mutual friend posts. Public posts do have privacy permission issues, but mutual friend posts may have some complications. In the case that a post by a mutual friend has been set to be visible only to the original receiver of the post, a peer will still be sent that post because the app does not address privacy settings.
Each peer needs to know what they can share with who. The Facebook API could include privacy settings of each post. For example, if a post on someone’s newsfeed is available to friends A, B, and C, that phone would share the post with peers who identify themselves as A, B, and C.
The overall quality of a newsfeed will be extremely hard to control for an offline version of Facebook because the phone will be accepting all posts from peers it is allowed to view including public posts. Implementing a client-side newsfeed ranking system could help.
A client-side newsfeed ranking system would need to be implemented to rank newsfeed items in an order suitable for viewing. Factors to consider in a client-side newsfeed ranking system include:
One idea is that the caching algorithm is dependent on whether or not the phone is charging, how much space it has available, and what type of network connection it has. Facebook could design a caching algorithm to cache content that is likely to be shared with peers down the road. Over time, the app could learn which peers it is most likely to connect to, and could adapt its cache to increase the hit rate.
Another system can be implemented wherein the app should cache entire newsfeed posts, not simply individual photos and videos. Caching individual photos and videos is helpful because they are costly to obtain, but peers that are completely offline will want to see context, such as the newsfeed post the photo appears in.
Finally, we can have a caching policy where in a phones caches items solely for the purpose of transmitting to peers (data which the cache phone user doesn't have access to see). The server could potentially give a client items that it doesn’t have permission to view, but encrypt them so the client who holds them doesn’t have access to them, but instead only has access to IDs. If a peer then asks our client for those IDs, that peer could download them via a P2P connection, and decrypt the items that it has access to via a key it gets from Facebook servers.
Most mobile developers know that battery life is crucial for the success of a mobile application. Because our app relies heavily on WiFi P2P connections, the app spawns a service that is persistent after closing the activity. This service will use the WiFi antenna to find nearby peers and transfer data, which will consume battery life.
We can modify the behavior of the app depending on the current state of the battery. If the phone is charging, we can constantly search for peers and transmit data as shown in android's battery monitoring guide .
Peer service discovery uses the WiFi antenna, which consumes roughly 200mA. At that rate, a 2,000 mAh phone battery would die after 10 hrs (not even taking into account the power consumption due to CPU use, or the power consumption due to any other app, or the screen). Compare this to a phone in standby with WiFi idle, which would consume roughly 10mA, and last 20 times as long on a single charge.
We can minimize the impact on battery life by batching all our requests, so as not to keep the WiFi antenna on. We can wake up all our apps every ten minutes to do a quick peer search, then let the antenna go back to sleep. Assuming all the apps wake up at the same time (based on Android’s clock) we will find new peers to connect to every ten minutes. Because P2P speeds are substantially better than a normal LAN connection, the both time and load of WiFi usage that is actively used by the app is lower.
Sources:
https://www.youtube.com/watch?v=OUemfrKe65cYes. If we are caching data for other peers, as well as ourselves, the app would use more disk space and memory, however we could cap the cache size depending on the available space on the phone on which it is installed. That would insure that app would never consume too many resources.