anchor.diff:  Defining New Artifacts
   ~~~~~~~~~~~~~~~~~~~~~~
   
  -New artifacts can be added to the link:https://code.google.com/p/grr/source/browse/artifacts[grr/artifacts] directory, which will be
  -imported on server restart.  Artifacts can also be uploaded via the Artifact
  -Manager gui and used immediately without the need for a restart.
  +New artifacts should be added to the link:https://github.com/ForensicArtifacts/artifacts/tree/master/definitions[forensic artifacts repository].  The changes can be imported into grr by running *make* in the *grr/artifacts* directory.  This will delete the existing artifacts, checkout the latest version of the artifact repository, and add all of the yaml definitions into GRR's directory.  Running *python setup.py build* will have the same effect.  The new artifacts will be available once the server is restarted.
  +
  +Artifacts can also be uploaded via the Artifact Manager gui and used immediately without the need for a restart.  When developing a new artifact you can use the *grr/artifacts/local* directory as a temporary home for testing (see next section).
  +
  +Private Artifacts
  +~~~~~~~~~~~~~~~~~
  +
  +Artifacts that are specific to your environment or need to remain private can be added to the *grr/artifacts/local* directory.  This directory will remain untouched when you update the main artifacts repository.  You can also use this directory to test new artifacts before they are added to the main public repository.
  +
  +GRR-Specific Artifacts aka "Flow Templates"
  +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  +
  +We currently support using the artifact format to call GRR-specific functionality, such as invoking a GRR client action, listing processes or running a rekall plugin.  These "artifacts" are grr-specific so they remain in the GRR repository under *artifacts/flow_templates*, which is a temporary working name.  We intend to rework this functionality into a more general, powerful, and configurable way to call GRR from YAML.
   
   GRR's FUSE layer
   ----------------
  
positive.code: pieces of information that include items such as logs, configured services, cron
  jobs, patch state, user accounts, and much more.  These pieces of information
  are known as forensic artifacts, and their location and format vary drastically
  across systems.  We have built a framework to describe forensic artifacts that
  allows them to be collected and customised quickly using GRR.
  link:https://code.google.com/p/grr/source/browse/artifacts[The collection of
  artifacts] is intended to be a centralized, free, community sourced, knowledge
  base of forensic artifacts that the world can use both as an information source
  and within other tools.
  
  The goals of the GRR artifacts implementation are:
  
  
negative.code:     collect them immediately.
  
  GRR artifacts are defined in YAML, with a style guide
  link:https://github.com/ForensicArtifacts/artifacts/blob/master/docs/style_guide.adoc[available here].  We use a standard set of machine information collected from the host for variable interpolation.  This collection
  of data is called the Knowledge Base (see link:https://github.com/google/grr/blob/master/proto/knowledge_base.proto[proto/knowledge_base.proto])
  and is referenced with a %%variable%% syntax.
  
  The artifact defines where the data lives.  Once it is retrieved by GRR a
  link:https://github.com/google/grr/tree/master/parsers[parser] can optionally
  be applied to turn the collected information into a more useful format, such as
  parsing a browser history file to produce URLs.
  
  