Today we conclude reading up on how Google protects data.Google has incredible expertise in this area. Security is an integral part of their operations. They scan for security threats using tools, they use penetration testing, quality assurance processes, security reviews and external audit. They have a rigorous incident management process for security events that affect the confidentiality, integrity or availability of systems of data. They apply defense-in-depth perspective to securing their custom-designed servers, proprietary operating systems and geographically distributed data centers. Data is encrypted in transit, at rest and on backup media, moving over the internet or traveling between the data centers. They build redundancy into their server design, data storage, network and internet connectivity and even the software services.Their audits cover compliance standards and we reviewed some of them. We also reviewed some of the tools used to empower users and administrators to improve security and compliance. We were discussing user authentication, data management and email management features. We reviewed data detention which is facilitated by the eDiscovery feature.Administrators can specify retention rules that specify how long certain messages are retained before they are removed from user mailboxes and expunged from all Google systems. Administrators can enforce policies over mobile devices in their organization, encrypt data on devices, and perform actions like remotely wiping or locking lost or stolen devices. Administrators can also recover data by restoring a deleted user account or restoring a user's drive or gmail data. They can publish reports that provide transparency to their actions.
Thus Google protects data in its infrastructure, applications and personnel operations. The same security considerations are acknowledged by the industry. We mentioned comparision to Adobe's efforts in this regard. While Google is an innovator in two-step authentication and encryption methods and may even have more scale of operations than many other companies, all that other companies need to do is to ensure that they don't fall short of the considerations from Google's security efforts.  Their implementations can vary but the threats will have been mitigated. Adobe has secured its data by virtue of the very same compliances that Google has made. These include  the SOC, ISO27001, FedRAMP and Payment card industry data security standard. In addition Adobe fulfils regulatory compliances such as Gramm-Leach-Bliley Act GLBA for financial institutions, HIPAA the health insurance portability and accountability act and protected health information PHI, the code of Federal regulation, Title 21 and the US Family educational rights and privacy act.
Adobe is able to meet these standards and regulations because it practices a bottom up physical layer securing approach called the Adobe Common Controls Framework and a top down software layer securing approach called the Adobe Secure Products Lifecycle. The former manifests as a set of Adobe specific controls that map to approximately a dozen security standards and the latter is a set of security activities that span several product development practices, processes and tools.
Where Adobe could become pioneer is to put together a security standard for using hybrid or public clouds for organizational use. While Google claims its public cloud has better security than on-premise computing, Adobe could become a pioneer to say that its embrace of public cloud is more secure than on-premise computing of many other companies.
#codingexercise
Yesterday we were discussing a codingexercise that attempted to sort a doubly linked list of 0 and 1.
It had a helper function to cut and insert element before or after the transition point. It goes like this:
dll CutAndInsertAfter(dll transition, dll current, dll root)
{
assert (current != null && root != null);
if (transition == null) return root; // nothing to do
if (transition == current) return root;
if (current == root) return root; // this op only when current > transition
// root == transition is acceptable
// cut current;
var temp = current.next;
if (temp)
     temp.prev = current.prev;
if (current.prev){
     current.prev.next = current.next;
     current.next = null;
}
// insert after
if (transition.next)
     transition.next.prev = current;
current.next = transition.next;
current.prev = transition;
transition.next = current;
// root remains unmodified for insertion after transition
return root;
}

The cutandinsertbefore method is similar to the one above except that the root might change.