Dayton's Den

First I am really excited at the idea of the Google's Project ARA phones, I think this is a great option for users to allow for growth on demand.  It could also extend life of batteries by only having what is required in the modules to reduce the power requirements.  Project ARA could provide a great deal of capabilities to the device, from a phone to a mobile medical monitoring device, to data collection and gathering systems.  Think of having a mobile device that can be configured for EMT's for collecting vital medical statistics, and the modules could then be removed and sterilized, or anything else that can be made into a module.

Google Nexus phones

With the release of the Nexus 6, many of my past desires still apply.  But it would be nice to have 2 size versions, not everyone needs or wants a massive phone.  In the case of the Nexus 6, this would be very easy as Motorola has made other models such as the Motorola X and Motorola S, that could be upgraded from their current specs.

Improved antenna design would be great, and this goes with ergonomic design, to design locations for the antenna's based on how people would use the device, this would ultimately give an ideal position fo antenna location to be less impacted by hand interference, this can be done with smart reconfigurable antenna arrays with software programmable radios, I can see this as a saving on power, and provide with an option to relocate the antenna to improve signal quality.

Google should make the Nexus as a Flagship of the Flagship's, they should be creating the line as an example of future technology, and be closer to the cutting edge, and pushing the edge of the technology and the OS.

Android

Again Enterprise view, having an enterprise package to allow for an enterprise to manage their employees work supplied cell phones, and to push default software and policies.  Online phone backups and restores, right now the only method of backup without root access is via access to the bootloader.

Another feature would be to imbed "Security" priviledge, that would have sub-priviledges, for example a program may need special permission to turn on the GPS and Location features for device recovery, or an option to update the IPTables configuration, but without needing root permissions.  This priviledge level would require code audits before being placed into Google Play.

Linux

This is a wish of Linux as a whole, a migration to "User Kernel Modules", taking a similar approach as FUSE (Filesystem in Userspace).   The idea with this system would be to allow for drivers for hardware to be upgradable outside of the Kernel level, this would also allow for features such as the Android phone to have drivers which are kernel agnostic, this would allow for device manufacturers to provide drivers for their hardware, without the requirement of rebuilding the complete kernel.

There is so much worrying about Ebola, and the rapid spread that has happened recent weeks.  The problem isn't that people aren't being isolated, of such a serious virus, but the lack of knowledge.  Both the general population and the professional health care workers have very little knowledge when it comes to this virus. 

Ebola is a very serious virus, but most of the precations that are recommended will protect most people.  Though the virus can survive for many days on a surface, this doesn't mean that if you touch it, you will come down with ebola, it requires that the virus to reach a point of ingress that can allow the virus to enter directly inside of the body.  Basically for most, hand washing for the general population would be sufficient, just like any other virus or bacteria.  You should be washing your hands anyways, to help in the prevention of the spread of germs.

For medical professionals, this is drastically different, as they are going to come into contact with a great deal of the virus in body fluids. These are the people that need to be protected, and must be protected from head to toe all clothing must not allow the body fluids through, and must be disposable and must be destroyed after use.  Putting on the protective gear and then removing it should be done in a proper format, and people who are treating theill should limit their travel for a period of 3 weeks after treating the last patient.

One interesting read, also would be The Hot Zone by Richard Preston

In recent years there have been many IT Security mistakes, but these mistakes are not necessarily a problem with IT personel.  But you still see a large number of people who will blame the employee themselves, without knowing the whole environment or corporate culture behind the webpage.  This entry is meant to try to educate the lay person of what issues surround IT Security, which is often larger and wider scoped then what most believe.

For most there are only 2 things that are IT Security, which is Network Security and Host Security, but these are not the only areas that must be managed to make a secure environment.  There is also physical security, and this is a very complex, because you have to weigh, access with security, if you are too secure the user may not be able to do their work, but you also can't give full access either.  But you also have to weigh in the risk of your information being available to the people involved, because with enough money, all physical, network or host security could be bypassed, with the access to the right person or people.

Risks

• Firewall Configuration
• Network Configuration
• Network Design
• Host Configuration (Computer and Server)
• Employees
  • Management
  • Employees
  • Contractors
  • Foreign Workers
• Financial Constraints

Well anyone who has looked at this page,which I will guess is close to no one, might notice a few changes, I have been busy upgrading everything, and have gotten everything back up

So OpenSSL has released their Project Roadmap, to many this seems to be a push in the right direction after many notable vulnerabilities in the past, which has caused at least to forks to be created. 

I have noted in the past, many issues with the OpenSSL code base, which has finally been brought to light, these consist of a constantly changing API, poor or non-existant documentation, complexity of the code, readability of the code, and the shear number of versions.

Changing API

The API in a release should never change, for any version of 0.9.8*, they API should be unchanging.  Once the version has been released no new features should be added, only security fixes.  This reduced the headache of refactoring code when some major change has occurred.  API Changes should occur in phases as well, with deprecation of previous functions occuring over a long period, this would allow for updating to newer major versions with little impact to the third party code.

Poor or Non-Existant Documentation

This is a pretty annoying issue.  There is little in the way of useful documentation, this is more of a problem for new users to using OpenSSL,  many of these questions aren't answered on the OpenSSL site at all, but are elsewhere, on potentially less reliable or trusted sites.  Now some of the questions have been answered, but still not in such a way that a lay-person could easily understand what they are doing, why they are doing it, or the potential risks?  These are such questions

• How to create a self-signed certificate?
• How to generate an SSL Key?
• How to generate an SSL Certificate Request?
• How to revoke an SSL Certificate, or Key?
• How to remove the passphrase from a Key?
• Descriptions of each encryption, random number generation, and hashing methods, and the pro's and con's of each.
• As a developer, How to use each function?  (This can also have a wrapper to simplify development, by having 1 or 2 functions that do the required steps for the developer, this means that common security mistakes can be avoided, for the less advanced)

These are all very important questions, and not always covered by the developer, but often through third party sources.  Mind you, I have noticed more information cropping up in recent months and years.  For functional documentation, the POD files generated should be on the website, and documented inline, if it isn't already.

Complexity of the Code 

The OpenSSL code is notoriously, complex to browse through with the multitude of files.  Many things should be done to simplify the code tree.

• Group together similar items in the source.
  • Encryption routines
  • Hashing routines
  • Formatting routines
  • Configuration routines
  • Platform Specific code (for adding missing functions from a platform, or Assembler code)
  • Applications
• Abstract functions to allow for a single code base to support multiple platforms, don't ifdef the crap out of the code
• Standardize on coding practices
• Code reviews
• Internal and External Audits
• Modular coding style, this would then allow for functions/features to be stripped away, with very little change to the base code, such as delete a directory, and a single line change in the base code.
• Remove the external engines, as useful as it can be, this should be part of the OS, and if you are keeping them use them as a data source for RNG not as the RNG.

A major thing is that is missing that should be implemented would be

Number of Versions

This has always been a sticking point for me, there shouldn't be the number of versions on the go as OpenSSL currently has, this creates code complexity, as a change for one might have to be back ported and forward ported to the various releases, right now there's at least 5 in development if not more. 

• 0.9.8* series that dates back to 2005
• 1.0.0* series that dates back to 2010
• 1.0.1* series that dates back to 2012
• 1.0.2* series is in Beta
• 1.1.0* is in development
• Two FIPS modules for OpenSSL

Of these 0.9.8* should have been retired awhile ago. 1.0.0* should be in a stage of critical bug fixes.  1.0.1* should be fixes and usability improvements. 1.0.2* should be still changing, with creating wrappers for the new API to port the old code to using it. and 1.1.0* should be in API flux.

I have the same wish list as last time

1) Mini SD Card Slot, I do understand the reasoning to make it easier for developer support, but having the option is a big benefit for even for the storage of backp of files.

2) Enterprise direction in support, Google may make a worthwhile partnership with RIM, to take advantage of BES.  Biggest benefit for business, is that they could control all aspects of the phone, business would appreciate this option.

3) Virtualization of seperate environments for business and home.

One item not really for Google, but in general for Java is to take an idea from VMWare with their Bubble Memory idea, where duplicate applications with the same libraries do not use up anymore memory but threads are isolated from corruption.   This would be probably done with a Java Hypervisor, that runs the JRE's as seperate threads of the Java Hypervisor, instead of  the JRE

For the past year or 2, I've been on the hunt for an Optical Jukebox that could load DVD's as required for both near-line and offline storage.  This is could be useful to backup Information and Recovery of information, without having to have spinning drives unless it is required. 

This is until I found Digistore Solutions, with their Centurion DiscHUB product line, this seems to fit the bill, the only issue I can see is that it would be nice to have Blu-ray disc's but I can't complain.  I do know there are also other similar options, but I have yet to find any even in the $600 price range.