Skip to main content

How Android OS should REALLY deal with privacy


I'll give you two design options that would improve OS privacy.  I am thinking of the Android Operating System, but these are design principles, so they would be just as applicable for a Windows 10 Universal Application (App) or an iOS App.  I am aware that this would be a huge undertaking, but it would be awesome!

1.  Handle-based access

This is not a new concept, but when you combine a system with pick-list controls and standard display controls, it is possible to allow an application to choose one or more contacts, display them and send a message without knowing the names or phone numbers.  The system would only expose a single handle to represent each contact.  Only isolated components would have the special privileges allowing access to the private details.  This would change the way applications create custom-drawn components, but would prevent even a HACKED system from leaking information as long as the process isolation subsystem was not compromised.  They could install "isolated" custom components that would be available only to a list of apps signed with a particular certificate.  This custom component could then access private information, but could not share memory back to the parent app, talk to the internet, write to the file system, etc. without gaining this permission just like an App.

This design would have a HUGE positive impact for persons with sight, hearing or other limitations, as they could select different components to serve their purpose (for example, the audio system could flash and buzz instead of playing sound, the display could talk over Bluetooth to an interactive Braille supplemental tablet or wristband).

2.  Information control

Allow the user to select the level of access for each application, with the option to select a default access level:
  • Dummy API, for example a list of dummy contacts with none, just you, or a small list of dummy phone numbers.
  • Limited API, only a tagged list of contacts is available.
  • Full API, same as today.

Another API example would be the network subsystem - we could have:
  • No connection
  • limited network
  • access over a specific WiFi only (only on the trusted HOME network)
  • access over Wifi only
  • access over 4G only
  • access over any network with certain white/blacklist active
  • unlimited access over any network

A combination of these two designs would make for an amazingly secure system, but it might start resembling the HURD kernel.  What does this design NOT prevent?  It would not prevent in-app advertising (unless you gave an App the no-connection, or the all-sites-blocked network API).  Applications that needed to serve advertisings might start requesting a working internet connection before they will allow you to play your game, so it wouldn't particularly break the ecosystem as it is today, but would give users amazing control over their system.

Along with a tightly controlled App Store, this might even allow Android to be used by some government agencies, or by users with privacy concerns.

Implementation

I think it would actually be pretty easy to implement a different limited contact list, and perhaps a dummy phone.  Tablets have to present a dummy phone after all.

Labels:

Comments

Post a Comment

Popular posts from this blog

Castle ActiveRecord with DetachedCriteria

My current development environment is Visual Studio Express C# Edition (read that as free ), Castle ActiveRecord's latest svn trunk(usually within a few days), and NHibernate svn trunk. As of NHibernate version 1.2.0, there is a very cool new class out there ... DetachedCriteria. This class lets you set all of your Castle relational attributes like BelongsTo, HasMany, etc. as lazy fetch, and over-ride this for searches, reports, or anytime you know ahead of time that you will be touching the related classes by calling detachedCriteria.SetFetchMode(..., FetchEnum.Eager). As a good netizen, I have tried to contribute to NHibernate and Castle ActiveRecord even if only in the smallest of ways . Oh yeah, I tried mapping to a SQL VIEW, and it worked GREAT! I received a comment after my last post, indicating that there is a better way, and I am sure of it, but the view guaranteed that I only have one database request for my dataset. NHibernate was wanting to re-fetch my missing as
1 comment
Read more

Castle ActiveRecord with Criteria and Alias

Update May 25, 2007: ActiveRecord now supports DetachedCriteria, which eliminates the need for the SlicedFindAll that I wrote below. It is nice when a library moves to add support for such commonly needed functions. So in summary, use Detached criteria instead of the code below. It is still a nice example of using NHibernate sessions. I have a history log, where each history record "belongs to" a service record. I have to treat this as a child-to-parent join, since some children are orphans. I wanted to use the FindAll(Criteria), but I wanted the option to have optional criteria, orders and aliases. My solution was to create an ARAlias class to represent an Associated Entity and an alias, and then build an ARBusinessBase class with the following method: public static T[] SlicedFindAll(int firstResult, int maxResults, Order[] orders, ARAlias[] aliases, params ICriterion[] criteria) { IList list = null; ISessionFactoryHolder holder = ActiveRecordMediator.GetSessionF
Post a Comment
Read more

Castle ActiveRecord calling a Stored Procedure

Update: I have contributed patch AR-156 that allows full integration of Insert, Update and Delete to ActiveRecord models . If you've been reading my blog lately, you know that I have been seriously testing the Castle ActiveRecord framework out. I really love it, but I have an existing Microsoft SQL Server database with many stored procedures in it. I have tested the ActiveRecord model out, and I am sure that I will learn enough to be able to use it for standard CRUD (create, read, update, delete aka. insert, select, update, delete) functionality. BUT ... If I really want to integrate with my existing billing procedures, etc, I will have to be able to call stored procedures. I have taken two approaches ... write the ARHelper.ExecuteNonQuery(targetType, dmlString) method that gets a connection for the supplied type, executes dmlString, and closes it. write the ARHelper.RegisterCustomMapping(targetType, xmlString) method that allows me to add mappings that refer to my auto-gener
2 comments
Read more