X-Git-Url: https://gerrit.automotivelinux.org/gerrit/gitweb?a=blobdiff_plain;f=docs%2F2_Architecture_Guides%2F2.2_Security_Blueprint%2F6_Application%2F1.2.6.0_Abstract.md;h=2925efbaebc4315431114c2a4e8a3ff53cc7e228;hb=refs%2Fchanges%2F98%2F25498%2F2;hp=ae7b7dcdac5a242d95cb5b042c1d45dd2315672c;hpb=eefc3ab6cbb8a5901632f46d99e13c8d90b2415d;p=AGL%2Fdocumentation.git

diff --git a/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.0_Abstract.md b/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.0_Abstract.md
index ae7b7dc..2925efb 100644
--- a/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.0_Abstract.md
+++ b/docs/2_Architecture_Guides/2.2_Security_Blueprint/6_Application/1.2.6.0_Abstract.md
@@ -1,12 +1,7 @@
 ---
-edit_link: ''
 title: Introduction
-origin_url: >-
-  https://raw.githubusercontent.com/automotive-grade-linux/docs-sources/master/docs/security-blueprint/part-6/0_Abstract.md
 ---
 
-<!-- WARNING: This file is generated by fetch_docs.js using /home/boron/Documents/AGL/docs-webtemplate/site/_data/tocs/architecture/master/security_blueprint-security-blueprint-book.yml -->
-
 # Part 6 - Application
 
 ## Abstract
@@ -38,35 +33,40 @@ AGL provides a framework for applications to be written in different forms:
 - Native application: in C
 
 While there is no harm in providing multiple types of applications, from a
-security perspective this does increase the attack surface for an intruder.
-The application framework (**AppFw**) consists of a number of utilities and
-daemons which provide context for the applications.
-Isolation is provided through **SMACK** labels.
+security perspective this does increase the attack surface for an intruder. The
+application framework (**AppFw**) consists of a number of utilities and daemons
+which provide context for the applications. Isolation is provided through
+**SMACK** labels.
 
 ## Application Store
 
-Although the Tizen system has defined a [system of App signing and signing flow](https://wiki.tizen.org/Security/Tizen_3.X_Overview#Application_Singing_and_Certificates)
-to avoid the spread of unauthorized Apps that might contain malware.
-At this point, it is unclear how much of this flow AGL will adopt.
-However, judging from the experience, it is an essential topic. For example,
-the Google Play Store controls the authorization of Apps through signing, and still,
-there are [many accounts of Apps containing malware on the store](http://www.eweek.com/mobile/researchers-find-132-malware-infected-android-apps-on-google-play).
-
-Tizen defines 5 levels of certificates and signing at each level, including an author,
-testing distributor, public level store distributor, partner level store distributor,
-and platform level store distributor. AGL may define a different number of third parties,
-but at a minimum an author and store distributor should be defined.
+Although the Tizen system has defined a [system of App signing and signing
+flow](https://wiki.tizen.org/Security/Tizen_3.X_Overview#Application_Singing_and_Certificates)
+to avoid the spread of unauthorized Apps that might contain malware. At this
+point, it is unclear how much of this flow AGL will adopt. However, judging from
+the experience, it is an essential topic. For example, the Google Play Store
+controls the authorization of Apps through signing, and still, there are [many
+accounts of Apps containing malware on the
+store](http://www.eweek.com/mobile/researchers-find-132-malware-infected-android-apps-on-google-play).
+
+Tizen defines 5 levels of certificates and signing at each level, including an
+author, testing distributor, public level store distributor, partner level store
+distributor, and platform level store distributor. AGL may define a different
+number of third parties, but at a minimum an author and store distributor should
+be defined.
 
 ![App Signing Flow](App_signing_flow.png)
 
-Once the number of signatures has been established, verification of those signatures needs
-to be done at a minimum at installation time on the AGL device. It is important to ensure
-the robustness/integrity of the public key used for signature verification. If the public key is modified,
-then this compromised key can be used to verify an attacker's private key signature.
+Once the number of signatures has been established, verification of those
+signatures needs to be done at a minimum at installation time on the AGL device.
+It is important to ensure the robustness/integrity of the public key used for
+signature verification. If the public key is modified, then this compromised key
+can be used to verify an attacker's private key signature.
 
-Further to this, installation-time verification is limited. Attacks can happen to apps in-memory
-at runtime. Any modifications made after installation will be missed by installation-time verification.
-Integrity verification that runs during execution makes for a more complete security story.
+Further to this, installation-time verification is limited. Attacks can happen
+to apps in-memory at runtime. Any modifications made after installation will be
+missed by installation-time verification. Integrity verification that runs
+during execution makes for a more complete security story.
 
 --------------------------------------------------------------------------------