text:
# Final-Project

## Final Project Script in R Markdown
The final project script documents how I conducted a principal component analysis (PCA) on RNA Sequencing Data from the Allen Brain Atlas study on Aging, Dementia, and TBI. This data enabled me to explore clinical and neuropathological metrics of aged brains using clusters of genes enriched in individuals diagnosed with dementia. The sequencing data was extracted from 107 brains, including 377 samples from cortical grey and white matter, as well as the hippocampus.  The PCA was performed using normalized gene-level FPKM values. I correlated clincial features/variables based upon the csv files based on clinical information for all donors to illustrate on my shiny app.

### Load in Libraries
```
library(ggplot2)
library('RColorBrewer')
library(dplyr)
library(plotly)
library(tibble)
```

### Set Working Directory
```
setwd("~daniellecollins/TRGN 510 Final Project")
```

### Load in CSV Files from Aging, Dementia, and TBI Study
```
samples <- read.csv('columns-samples.csv',header = TRUE, sep = ",",  quote = "\"", dec = ".", fill = TRUE, row.names = 1)
donor_information <- read.csv('DonorInformation.csv',header = TRUE, sep = ",", quote = "", dec = ".", fill = TRUE, row.names = 1)
normalized_fpkm <- read.csv('fpkm_table_normalized.csv',header = TRUE, sep = ",",  quote = "\"", dec = ".", fill = TRUE, row.names = 1)
genes <- read.csv('rows-genes.csv',header = TRUE, sep = ",",  quote = "\"", dec = ".", fill = TRUE)
complete_data <- read.csv('complete_data.csv',header = TRUE, sep = ",", quote = "", dec = ".", fill = TRUE, row.names = 1)
```

### Preparation of Raw Data: Remove Commas Within Complete_Data File to Standardize Column Placement
```
complete_data_dc_final <- read.csv('complete_data_dc_final.txt',header = TRUE, sep = "\t", quote = "", dec = ".", fill = TRUE)
```

### Log FPKM Data
```
fpkm_log<-log2(normalized_fpkm+.000001)
```

### Compute PCA and Plot PCA Dataframe
This plot indicates how much of the overall variation can be explained by each principle component.
```
pca <- prcomp(fpkm_log)
plot(pca, type = "l")
```

### Choose Top Principle Components
The majority of global variation lies within the top 3 principle components.
```
std_dev<-pca$sdev
pr_var <- std_dev^2
pr_var[1:10]
prop_varex <- pr_var/sum(pr_var)
plot(prop_varex, xlab = "Principal Component", ylab = "Proportion of Variance Explained", type = "b")
```

### Create Dataframe to Graph PCA
```
pcadf<-data.frame(pca$rotation)
```

### Plot PCA
```
plot_ly(pcadf, x = ~PC1, y = ~PC2, z = ~PC3, color = ~PC4, colors = c('#BF382A', '#0C4B8E')) %>%
add_markers() %>%
   layout(scene = list(xaxis = list(title = 'PC1'),
 yaxis = list(title = 'PC2'),
 zaxis = list(title = 'PC3')))
```

### Create Column (rnaseq_profile_id) from the Row Names
```
complete_data$rnaseq_profile_id<-rownames(complete_data)
```

### Create Summary PCA Table
This dataframe contains RNA Sequence Profile ID Information matched with the top three principle components.
```
pca_row<-data.frame(pcadf$rnaseq_profile_id<-rownames(pcadf))
pca_row$PC1<-pcadf$PC1
pca_row$PC2<-pcadf$PC2
pca_row$PC3<-pcadf$PC3
colnames(pca_row)[1] <- "join_column_rnaseq"
```

### Combine Clinical Metrics with PCA
```
x<-complete_data_dc_final
y<-pca_row
combined<-inner_join(complete_data_dc_final,pca_row,a, by = "join_column_rnaseq")
```

### Plot with Clinical Variables Determining Color
```
plot_ly(combined, x = ~PC1, y = ~PC2, z = ~PC3, color = ~structure_name, colors = c('#BF382A', '#0C4B8E')) %>%
add_markers() %>%
   layout(scene = list(xaxis = list(title = 'PC1'),
 yaxis = list(title = 'PC2'),
 zaxis = list(title = 'PC3')))
```

## Publishing to Shiny Apps

### Load in Libraries
```
library(shiny)
library(plotly)
library(ggplot2)
```

### Load in CSV File of Merged Datasets
```
combined_csv <- read.csv('combined_csv.csv',header = TRUE, sep = ",",  quote = "\"", dec = ".", fill = TRUE)
```

### Determine Layout of Shiny App and Allow for Clinical Variable Inputs
```
ui <- fluidPage(
  plotlyOutput("plot"),

  titlePanel("PCA of RNA-Seq within the Aging, Dementia, and TBI Study"),

  sidebarPanel(
    selectInput('variables', 'Variables', c("Age" = "age", "Sex" = "sex", "Apo E4 Allele" = "apo_e4_allele", "Years of     Education" = "education_years", "Age At First TBI" = "age_at_first_tbi", "DSM IV Clinical Diagnosis" = "dsm_iv_clinical_diagnosis", "NINCDS ARDA Diagnosis" = "nincds_arda_diagnosis", "Demented Actions" = "act_demented", "Structure Name" = "structure_name", "Hemisphere" = "hemisphere"),"structure_name")
  )
)
```

### Plot Interactive PCA
```
server <- function(input, output) {

  output$plot <- renderPlotly({

    plot_ly(combined_csv, x = ~PC1, y = ~PC2, z = ~PC3, color = ~get(input$variables), colors = c('#BF382A', '#0C4B8E')) %>%
      add_markers() %>%
      layout(scene = list(xaxis = list(title = 'PC1'),
                          yaxis = list(title = 'PC2'),
                          zaxis = list(title = 'PC3')))
  })

}

shinyApp(ui, server)
```

### Publish Shiny App to Create URL

repository: daniellecollins/Final-Project

repo_name: daniellecollins/Final-Project


text:
MapR Cluster Configuaration:
* Create Albums/Artists changelogs(Descibed here: https://github.com/mapr-demos/mapr-music/blob/master/doc/change-data-capture.md)

Dev machine configuration:
1. Install and run the ElasticSearch
2. Go to 'mapr-music/core-application/webapp' and run 'mvn clean install -Dmaven.test.skip=true'
3. Go to 'mapr-music/core-application/streaming/elasticsearch-service/target' and run jar: 'java -jar elasticsearch-service-1.0-SNAPSHOT.jar'
(It will start service with listens Artists/Albums changelogs and publishes the changes to the ElasticSearch)

4. Deploy MapR Music app
5. Change one of the album's name to be for exampple 'TEST ALBUM'
5. Change one of the artists's name to be for exampple 'TeST Artist'
(You will be able to see that changes are sent to the ES at 'elasticsearch-service' logs)

6. Perform GET /mapr-music-rest/api/1.0/search/name?entry=test

You will be able to see something, similar to:

```
{
    "total": 2,
    "albums": [
        {
            "name": "TEST ALBUM",
            "_id": "a92fec84-2aec-4a07-b065-4e6e56999e15"
        }
    ],
    "artists": [
        {
            "name": "TeST Artist",
            "_id": "0a6f7d33-e760-4bbf-9173-ca749fee77c5"
        }
    ]
}
```

repository: mapr-demos/mapr-music

branch_name: refs/heads/master

extension: md

gha_language: Java

license_type: permissive

repo_name: mapr-demos/mapr-music


text:
---
layout: post
title: This Coffeescript
date: '2013-11-26 05:26:02'
excerpt: "I like coffeescript, well sort of, its a bit of a love hate, but this one little trick saved me tons of typing."
---

Today I stumbled upon something that I found while working on a rails project that uses coffeescript. If you have never heard of coffeescript before, [check out coffeescript right now!](http://coffeescript.org/)
Coffeescript is basically a nice DSL on top of regular ol javascript which is just much nicer to write, plus theres some great little helpers in there for some common functions which can be a bit nasty, at least IMHO.

So what the fuss is about today is this, this as in the **this** statement in javascript. You can accomplish the same thing by using **@** in coffeescript.

Here is an example of a [jQuery](http://jquery.com/) this object used normally and then in coffeescript.

Jquery
`$(this)`

Coffeescript
`$(@)`

This just looks much nicer to me, even though it was like uhh whats that at first, but the code following after made perfect sense in the scope of the action.

license: MIT

repository: pixelstack/pixelstack-bk-old

extension: markdown

repo_name: pixelstack/pixelstack-bk-old


text:
# AWS Config with Terraform

This example shows enabling [Config](https://aws.amazon.com/documentation/config/). It includes setting up
a role for Config to use, an S3 bucket for logging, and uses a pre-existing SNS topic to send alerts.
In reality, it would be expected that the resources used by [terraform-aws-cloudtrail](https://github.com/LeapBeyond/terraform-aws-cloudtrail)
and [terraform-aws-guardduty](https://github.com/LeapBeyond/terraform-aws-guardduty) would be shared in a coordinated
fashion rather than creating independent S3 and IAM resources.

This example uses a reasonably complete set of [managed Config rules](https://docs.aws.amazon.com/config/latest/developerguide/managed-rules-by-aws-config.html),
but does not include an example of writing your own rules to be managed by Lambda.  Be cautious as well,
the [pricing](https://aws.amazon.com/config/pricing/) on this service gets pretty exciting if you are just experimenting!

## Usage
It is assumed that:
 - appropriate AWS credentials are available
 - terraform is available

Make a `terraform.tfvars` file using the `terraform.tfvars.template`, and then

```
terraform init
terraform apply
```

Eventually you should see output similar to

```
bucket_arn = arn:aws:s3:::config20180319151029294700000001
recorder_id = config-example
```

## License
Copyright 2018 Leap Beyond Emerging Technologies B.V.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

   http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

repository: asmtal/terraform-aws-config

repo_name: asmtal/terraform-aws-config


text:
### Backbone Todo App

In order to run this, it is best to put it on some sort of web server.
Accessing this through a file:// URL fails due to RequireJS and protocol relative URL's.

Handlebars (*.hbs) files need to be served as text.  If this is run in IIS, the included web.config file
takes care of this automatically.

### Release history

**1.0.0** - 11-4-2014 - *Jon Onstott*

 - Initial version

license: Unlicense

repository: onstottj/Backbone-Todo-App

branch_name: HEAD

repo_name: onstottj/Backbone-Todo-App


text:
Description
===========

Installs SAS-2 Integrated RAID Configuration Utility (sas2ircu)

Requirements
============

* Chef 0.8+
* [ark](https://github.com/opscode-cookbooks/ark)

Attributes
==========

* default['sas2ircu']['url'] - URL to sas2ircu archive.
* default['sas2ircu']['checksum'] - The sas2ircu checksum.
* default['sas2ircu']['dir'] - Base directory to install sas2ircu.
* default['sas2ircu']['cmd'] - Path to the sas2ircu command.

Usage
=====

```json
"run_list": [
    "recipe[sas2ircu]"
]
```

default
----

Installs sas2ircu

License and Author
==================

Author:: John Dewey<EMAIL_ADDRESS>
Copyright 2013-2014, John Dewey

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.


text:
---
layout: default
---

# 1994-01-07 - Crypto Controls in the USA

## Header Data

From: Michael Johnson<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: 77448fcb4dbb7ea04e7ea2e8f4196fb9524037ad6f120df0df3b978be46333d1

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1994-01-07 13:34:41 UTC

Raw Date: Fri, 7 Jan 94 05:34:41 PST

## Raw message

```
{% raw  %}From: Michael Johnson<EMAIL_ADDRESS>Date: Fri, 7 Jan 94 05:34:41 PST
To<EMAIL_ADDRESS>Subject: Crypto Controls in the USA
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

                 Data Encryption Software
                         and
                 Technical Data Controls
                        in the
                 United States of America

Copyright (C) 1994 Michael Paul Johnson
PO Box 1151
Longmont CO 80502-1151
USA

<EMAIL_ADDRESS>
303-447-7302

Distribute unmodified copies freely.

7 January 1994

1.   Introduction
2.   Problems with the Status Quo
2.1.   Regulations Ignore Technology
2.2.   Overly Broad Definition of "Encryption Software"
2.3.   Overly Broad Definition of Export
2.4.   Censorship and the First Amendment
3.   National Security Issues
3.1.   Signals Intelligence
3.1.1.    Enemy Signals
3.1.2.    Bugs & National Technical Means
3.2.   Counter-Intelligence Activities
3.3.   Our Military and Diplomatic Communications
3.4.   Banking Transactions
3.5.   Domestic Personal and Corporate Communications
3.6.   Authentication in the Private Sector
3.7.   Upholding the Constitution
3.8.   Law Enforcement
3.9.   Technology Base Migration and Loss
4.   Technology Issues
4.1.   Availability of Computers
4.2.   Telephone Lines and Modems
4.3.   The Internet
4.4.   Information Services and Bulletin Boards
4.5.   Books and Magazines
4.6.   Availability of Encryption Software
4.7.   DES is Dying
4.8.   Unbreakable Encryption
5.   Economic Issues
5.1.   International Trade
5.2.   Cryptographic Competition
5.3.   Domestic Chilling Effect
6.   Regulatory Issues
6.1.   Clarity of Regulations and their Intent
6.2.   The First Amendment
6.3.   Enforcement
6.4.   Consistency with Technology
7.   Recommendations
7.1.   Reevaluate National Security Impact
7.2.   Deregulate Publicly Available Information
7.3.   Deregulate Research and Publication
7.4.   Replace DES with Better Public Standard
7.5.   Control NSAs Cryptographic Technology
7.6.   Alternate Intelligence Methods
7.7.   Alternate Law Enforcement Methods
7.8.   Clarify & Repair Export Regulations

1.  Introduction

The current status of the regulation of encryption software in
the United States of America is, at best, confusing and harmful
to business.  At worst, the current status is harmful to
National Security and violates U. S. Constitution.  I invite you
to study this issue with me.  I present what I perceive to be
the problems and the issues that must be considered, then
suggest some solutions.  Even if you don't fully agree with all
of my statements, I hope that they prove helpful to your own
understanding of this situation.

2.  Problems with the Status Quo

I perceive several problems with the current International
Traffic in Arms Regulations (ITAR) far beyond typos like the
reference to $120.10(d), which doesn't exist, in $120.10(1).
These problems are severe enough that I hope that they will be
rectified soon before they do even more damage.  All of the
problems with the ITAR mentioned here have to with encryption
software, as defined in the ITAR.

2.1  Regulations Ignore Technology

The ITAR ignores the fact that software, like other technical
data, can exist in a multitude of forms, many of which know no
national boundaries.  The ITAR ignores the fact that much of
what is prohibited to be exported exists in unlimited quantities
outside the USA.  The ITAR hurts U. S. Business but doesn't
significantly reduce the availability of strong encryption
technology outside the USA.  The ITAR ignores the widespread use
of purely electronic means to distribute software, such as the
Internet, Computer Bulletin Board Systems (BBS), and commercial
information services (such as CompuServe).  The ITAR ignores the
fact that shareware publishing, which is a form of
Constitutionally protected publication, propagates software all
over the world with no formal distribution mechanism.

2.2  Overly Broad Definition of "Encryption Software"

"Encryption software" is defined in $121.8(f) and $121.1,
Category XIII(b) to include not only computer programs designed
to protect the privacy of information, but all of the technical
data about those programs.  This naturally includes a great deal
of material in any large library or book store.  William B.
Robinson, Director of the United States Department of State,
Bureau of Politico-Military Affairs, Office of Defense Trade
Controls, states in his letter to me of 30 November 1993, that
"the exemptions listed in $125.4 for technical data do not apply
to cryptographic software and source code."  I conclude,
therefore, that the ITAR implies that the majority of the
libraries and larger bookstores in the United States stock
"munitions" on their shelves for anyone to read.

2.3  Overly Broad Definition of Export

$120.17 of the ITAR makes it clear that allowing a foreign
person to read a book containing encryption software constitutes
export.  Therefore it seems possible that some perverse person
might state that all of the libraries and bookstores that
contain any book on cryptography must register as an exporter of
munitions.  This situation gets even more interesting in its
electronic analogies.  However, restricting domestic
distribution of technology that is perfectly legal and useful
within the USA just because a foreigner might see it is not only
unreasonable, it could probably not stand a Constitutional
challenge.

2.4  Censorship and the First Amendment

The ITAR does make some acknowledgment of the fact that not all
of the publications that it calls "encryption software" need be
subject to export restrictions, but doesn't even come close to
defining the difference.  All it does is set forth a censorship
procedure called a "Commodity Jurisdiction Procedure" (see
$120.4).

From what I know of the First Amendment and Constitutional case
law (I'm not a lawyer, but I took a class on the subject), the
only way the Federal Government can legally take away U. S.
Citizen's rights to freedom of speech or freedom of the press is
when there is a clear danger that is caused by that expression,
or a significant infringement of the rights of another person.
The classic examples of this are yelling "FIRE" in a crowded
theater, or committing libel or slander.  In the case of
technical data concerning encryption software that is already in
the "public domain" (as defined in the ITAR for technical data),
the damage (or benefit), if any, is pretty much already done and
further publication probably makes little difference.  I believe
that any definition of what is a munition that makes the
nation's bookstores and libraries appear to be exporters of
munitions is not just ridiculous, it is unconstitutional.

When I tried to get clarification from the Department of State
on what the rules that they applied when performing their
censorship role (Commodity Jurisdiction Proceeding) were, all I
got back was two letters, one that clarified a point made muddy
by a typo in the ITAR and gave no help beyond the ITAR itself,
and one form letter that said that the Department of State would
not deal with hypothetical questions (even though most of my
questions weren't purely hypothetical).

This serious Constitutional question casts doubt on the
enforceability of any of the regulations in the ITAR against any
encryption software.  It could be difficult to prove that the
publication of a particular piece of technical data or computer
program caused specific, measurable damage resulting from
intentional export without a license (even if you could figure
out who exported it).  Yet, there cannot be any restriction to
U. S. Citizen's freedom of speech and freedom of the press
unless it can be proved that damage resulted from that speech.

3.  National Security Issues

"National Security" means a lot of things.  It means maintaining
the integrity and safety of our Constitution, our people, our
land, and our environment.  It means the ability to defend
ourselves against anyone or any thing that would seek to harm
us.  Our freedom, constitutional democracy, and fairness to all
citizens are our greatest protection against internal threats.
This gives us the strength and will to have a strong diplomatic,
economic, and military force to protect us against external
threats.

3.1  Signals Intelligence

In the context of encryption software, the most obvious
connection to National Security (if you ask the NSA) is the
impact on intelligence operations.  In the process of spying on
enemies, it is a lot safer to listen to what they are doing
remotely than to send a person in to spy.  The two main ways of
doing this are (1) to listen to and/or alter signals that they
generate for their own purposes, and (2) to listen to signals
emanating from devices that we have placed for the purposes of
listening.

3.1.1  Enemy Signals

Enemy signals may include telemetry, radio transmissions on
various frequencies for various purposes, telephone
conversations, computer data links of various sorts, etc.  These
all may provide some kind of clue as to what evil deeds they may
try to perpetrate on us next, or may indicate significant
vulnerabilities for us to exploit in war time.  The enemy knows
that we know this, and will probably try to protect at least
some of their signals using encryption, deception, jamming, or
data hiding (steganography).

It is possible that an enemy might use some of our own
encryption technology against us.  The enemy may either directly
use a commercial product to hide the meaning of communications
from us, or use some published technology originated in the USA
and other free countries to build their own systems.  They may
also add their own secret innovations to what they learn from
us.  Of course, there is also the consideration that an enemy
would prefer to use cryptographic technology of their own
design.  This would give them the advantage of not letting us
know which algorithm they are using.  It would also deprive us
of the huge head start we have on cryptanalysis of things like
the ancient Data Encryption Standard (DES).  This may not be
enough to stop me from protecting a proprietary cookie recipe
with the DES algorithm (or the triple DES variant if the cookies
tasted good and weren't fattening), but it would be a
significant consideration for a nation planning to bomb Pearl
Harbor.  DES is probably a bad example, since everyone on planet
Earth who really cares already has a copy of a program that does
DES encryption, or can get one in a few minutes.

Using a commercial product like a spread sheet or data base
program that does encryption only as an extra feature against us
is something of a problem for an enemy, since such products are
not normally well suited to the applications needed in military
and diplomatic situations.  Imagine giving a field commander a
laptop computer with a U. S. commercial spread sheet program on
it to decrypt orders from his commander.  I may underestimate
the silliness of our enemies, but I don't think that this is
likely.  A much more tamper-resistant device with better key
management would be much more appropriate for a military or
diplomatic application.  Use of our publicly available
encryption design technical data in building more appropriate
military communications security devices is a more likely threat
in the case of a clever adversary.  The only consolation in this
case is that we also have access to this same data as an aid to
cryptanalysis.

In the extreme case, strong cryptographic technology could
become so readily available and easy to use that most of the
interesting signals generated by enemies for their own purposes
are encrypted in such a way that we cannot decrypt or subvert
the communications without stealing their keys.  In that case,
all nations might have to behave like gentlemen (and not open
the other's mail or read their electronic communications).  Then
again, that is probably too idealistic to expect.  It is more
likely that mankind will only figure out other ways of spying on
each other.

3.1.2  Bugs & National Technical Means

Even if the enemy takes great care to protect the secrecy and
integrity of their own communications channels, we can still spy
on them.  Listening devices can be made so small and have such
inconspicuous output that they can be almost impossible to
detect or jam when planted properly.  It takes very little power
to send a signal to a nearby relay to a satellite, and many
varieties of listening devices can be used.  Even if an enemy
becomes wise to one kind, another kind may be in use.  Suffice
it to say that all the encryption technology in the world could
not cut off this source of intelligence, since all valuable
intelligence exists in the clear at some point.  If it didn't,
it would be of no value to the originator and intended
recipient.

Public use of strong cryptographic technology may limit the
points where listening devices must be planted to be of value,
but can never totally cut off this sort of intelligence.
Increases in knowledge cryptography and steganography may help
this sort of spying more than hinder it.

3.2  Counter-Intelligence Activities

Increased public use of strong cryptography makes it easier for
a spy to obtain a good cryptosystem.  It also makes it easier to
send encrypted messages without arousing suspicion.  That is
good for our spies, but bad for detecting spies in our own
country.  Then again, it would be a pretty inept spy (ours or
theirs) who could not now obtain a good cryptosystem and send
messages home without arousing suspicion, under conditions much
worse than the USA right now.  Of course, increased public use
of strong cryptography also makes it harder for a spy to find
valuable data to send back home.  I think that the net effect
will be that spies in the USA (and some other developed nations)
will be harder to catch, but less effective.

3.3  Our Military and Diplomatic Communications

The greatest contribution of cryptography to our National
Security is in protecting our own military and diplomatic
communications from eavesdropping or alteration.  Communications
of this nature must be private, must be authentic (not an
alteration or forgery), and must not have been altered in
transit.  Increased public use of strong cryptography can only
help us to keep our most sensitive communications private.  This
is because there will be more encrypted traffic to attempt
attacks on, making traffic analysis harder.  It also may be that
discoveries made in the private sector help in the design and
evaluation of military and diplomatic cryptosystems.

3.4  Banking Transactions

We do so much banking electronically that failure to use strong
cryptography to protect these transactions would be criminally
negligent.  It would be like not locking the vault and bank
doors and not posting a guard.  The importance of the integrity
of our banking system to our economic well-being is obvious.
The cryptographic protection must also be economical, just as
the bank buildings, vaults, and other security systems must be,
or the banks will not remain competitive.  We must balance the
cost of protection with the value of what is being protected.
Strong cryptography usually doesn't cost much more to implement
than weak cryptography, and may save a whole lot of money if it
can prevent some fraud.

3.5  Domestic Personal and Corporate Communications

Although there are strict and fairly consistent guidelines for
the protection of U. S. Government classified information, the
private sector is much more vulnerable.  Some companies are very
security conscious, but some are not.  Those which are not are
easy targets for foreign and domestic spies, either working for
governments or competing corporations (or both).  Encouraging
good security practices in the private sector, including use of
strong cryptography, use of good crosscut shredders, etc., makes
the USA more secure against this threat.

Protection of personal communications with encryption is good
for privacy, just as locks on doors and curtains on windows are.
 It becomes very important in some cases, such as when a
battered person is hiding from a stalker that is still at large,
or when coordinating activities that might attract criminals
like shipping diamonds.  Encryption technology can help reduce
crime, just like dead bolt locks.    This isn't because I do
anything evil with my dead bolts or cryptographic software, but
because I love freedom.  This preference is nearly universal
among users of cryptography, and the countries and companies
that cater to this desire will have a big economic advantage.

3.6  Authentication in the Private Sector

Encryption technology is the only way to provide a signature on
a digital document.  Nothing is totally fool proof, but digital
signatures, when done properly, are much harder to forge or
refute than pen and ink signatures on paper.  Electronic
documents can be transmitted faster and with higher fidelity
than faxes, and the ability to sign them will be a great aid to
quickly and conveniently doing business with remote customers
and suppliers.  As contract case law and technology evolve, this
will become more and more important to our economy.

3.7  Upholding the Constitution

Citizens of the United States of America have a right to privacy
guaranteed by the Constitution's Bill of Rights.  This quaintly
stated right to be secure in our papers and effects is highly
cherished.  The advance of technology has eroded privacy.
Corporations like Tandy openly track their customer's names,
addresses, buying habits, then shower them with junk mail.
Credit bureaus keep massive amounts of (often incorrect) data on
people all over the country -- information that is supplied to
lenders and in the form of prescreened mailing lists for
solicitors.  Government organizations keep records of real
estate transactions, census data, and other such records that
are used by solicitors to pester owners of houses in selected
neighborhoods.  Hospitals keep your patient records on computer
systems that can be accessed by many people.  Cellular and
cordless telephones are trivial to monitor without physically
tapping any wires, and legislated privacy in these areas is
unenforceable.

Strong encryption can bring back part of the privacy that has
been lost to technology.  No law can keep spies and criminals
from listening to phone calls made over radio links (including
microwave and satellite links for normal phone calls), but
encryption can make those calls unintelligible to criminals and
other unauthorized listeners.

3.8  Law Enforcement

The proper use of encryption technology by law enforcement
officers helps deny knowledge of monitoring operations to
criminals and fugitives.  It helps them to keep records private
and protect under cover agents.  It helps prevent tampering and
deception from being used against them in their own
communications.  Unfortunately, this is a two-edged sword.
Strong encryption technology can also be used by criminals to
thwart the efforts of law enforcement officers to gather useful
information from court authorized wire taps.

Strong cryptography also provides a "safe" way for a criminal to
keep records of nefarious deeds that cannot be read by the
police and used as convincing evidence leading to a conviction.
Of course, fewer such records might be kept in the absence of
strong cryptography, and some records kept in this manner might
not be all that useful in obtaining a conviction.  This is not
very assuring to law abiding citizens and law enforcement
officers, who want dangerous criminals to be caught well before
they meet the Ultimate Judge in Heaven.  Fortunately, most of
the investigative tools available to law enforcement officials
are not affected by strong cryptography.
 Murder, terrorism, rape, and other violent crimes are not all
that hard to commit (for those devoid of conscience or with the
twisted conscience of a kamikaze), but these crimes are very
difficult to get away with.

3.9  Technology Base Migration and Loss

When a technology is discouraged by over-regulation, taxation,
or other means, that technology becomes less profitable in the
country where it is discouraged.  Less profitable technologies
are not invested in as heavily.  Therefore, the technology in
that country will tend to fall behind.  Right now, it appears
more profitable to develop an encryption product for sale in
many other countries than in the USA because export of this
technology from the USA is discouraged but import is not.  An
entrepreneur in New Zealand has an unfair advantage against one
in the USA.  The New Zealander is not required to cripple key
lengths or deal with unreasonable and unreadable regulations
like our ITAR.  This means that encryption technology in the USA
will tend to atrophy while it prospers in other countries.  This
is bad for National Security.

4.  Technology Issues

Any policy concerning encryption software that is to make sense
must take into account the realities of the current state of the
art in the applicable technologies.  Failure to do so could at
best lead to confusion, and at worst do much more harm than
good.

4.1  Availability of Computers

It doesn't take a lot of computing power to perform strong
encryption (locking data up).  It often takes a great deal of
computing power to do serious cryptanalysis (unlocking data
without the key).  Strong encryption can be done with almost any
microprocessor on today's market.  The original IBM PC (now
greatly outclassed by the current desktop computers) has more
than enough computing power to lock up significant amounts of
data so tight that all the spy organizations in the world
combined could not unlock it for thousands of years or more.
This class of computer is available in essentially any developed
or semi-developed country in the world.

4.2  Telephone Lines and Modems

There are still places in the world that don't have easy access
to telephone lines, but they are growing fewer all the time.
The places that do have telephones, computers, and modems are
those places where encryption technology is the most useful.  Be
they friend or foe, these places all have one thing in common.
They are only a telephone call or two away from strong
cryptographic software if they know where to call, and it isn't
that hard to find out.  Since many telephone connections are by
satellite, and since international telephone traffic is not
routinely monitored and censored by most free nations, any
technical data (including encryption software) can be
transmitted across almost any national border unhindered and
undetected.

4.3  The Internet

The Internet has grown to such a large, international collection
of high speed data paths between computers, that it has become,
among other things, one of the most effective examples of
international freedom of expression in existence.  Physical
distances and political boundaries become irrelevant.  I can
peruse data posted for public access on university and corporate
computer systems on five continents and many islands, no matter
if I'm in the USA or in Russia.  This is a powerful research
tool.  News groups provide discussion forums for subjects
technical and nontechnical, decent and obscene, conservative and
liberal, learned and ignorant, from Animal husbandry to Zymurgy,
and more.  The Internet provides easy access to lots of strong
cryptographic technology and software that can be reached from
any nation with a connection to the Internet.  A great deal of
this data originated from outside the USA.

The most complete and up to date collections of encryption
software on the Internet are published for anonymous ftp from
sites outside the USA.  (Anonymous ftp sites are computer
systems that allow anyone to log in with the name "anonymous"
using the file transfer protocol program called "ftp" to
transfer files to their own system).  There are several ftp
sites in the USA that carry some encryption software, and they
have varying degrees of barriers to export.  Some sites make no
attempt at all to limit access to encryption software.  Some
sites are very effective at not allowing export, but are totally
ineffective at distributing software domestically because of the
hassles they impose on users (who can just as easily get the
same stuff from Italy).

The strongest barrier to export that I've seen used at a U. S.
domestic ftp site for encryption software that doesn't totally
defeat most of the advantages of this form of software
distribution is the one used at rsa.com for the distribution of
their RSAREF package and RIPEM.  The idea is to force you to
read a text file containing an anti-export warning before you
can find the data you are after.  The text file that contains
the warning also contains the name of a hidden directory that
changes periodically.  The encryption software is in the hidden
directory.  Naturally, this doesn't prevent an unwelcome
intruder from stealing the data anyway, but the moral barrier
presented probably reduces the number of "exports" from that
site initiated by people in other countries.  I support RSA Data
Security, Incorporated's right to publish this data, even though
I have observed copies of this data on several foreign computer
systems.

I tried hard to think of a better solution (and even called the
Department of State and the NSA for ideas), but there is
basically no way to widely and freely publish any data in the
USA without making it possible for a foreigner to steal that
data out of the country.  Even if the data is confined to
physical packages and sold or placed in libraries only in the
USA, there is nothing to prevent someone (either a U. S. or
foreign citizen) from buying or borrowing a copy, then
transmitting a copy of that copy out of the country.  Even if
positive proof of citizenship is required before release of the
data, all it takes is one citizen to release a copy of the data
outside the USA.  You might argue that there would be a strong
moral barrier against this, but remember that all it takes is
one.  What does it matter to someone if they send a copy of
encryption software to a friend or relative in another country
so that they can send private electronic mail back and forth?
All it takes is one copy out of the country, and that copy can
be copied any number of times.  If rabbits multiplied so easily,
we would all quickly drown in them.

The bottom line is that the best solution to balancing freedom
of the press and the ITAR for encryption software ftp sites is
just an annoyance for the intended users and a way to make it
impossible to prove that the operators of the site intended to
break any valid law.  This may or may not have any bearing on
the proliferation of encryption technology outside of the USA.
I am not a lawyer, but I know RSA Data Security, Incorporated,
has lots of them, and I don't believe they would do anything
stupid.

4.4  Information Services and Bulletin Boards

CompuServe, America Online, Genie, Bix, Delphi, and other
similar services offer massive amounts of data, including
encryption software and technical data, to callers.  They often
act as common carriers between correspondents who carry this
data themselves, and really don't know the contents of what they
are carrying.  Other times, they are well aware of what they
have.  For example, CompuServe publishes a magazine promoting
some of the shareware that they carry, and featured some
encryption software in an article in their November 1993 issue.
These information services also serve customers outside of the
USA.  Indeed, it would be very difficult not to do so, even if
they didn't want to bring some foreign money into their hands.

Computer bulletin board systems vary in size from hobby systems
running on a single PC in a home to large commercial systems.
Some are run as a hobby, some as a means of providing technical
support to customers, and some as profit-making information
services.  A very large number of these systems have encryption
software on them with no export controls expressed, implied, or
implemented.  Indeed, many of the operators of these systems
would laugh in your face if you claimed they were trafficking in
arms.  These systems are normally accessible from anywhere with
a telephone, computer, and modem.

4.5  Books and Magazines

Encryption software and technical data about it can be found in
a large number of books and magazines in libraries, book stores,
and by subscription in and out of the USA.  Some of these have
companion disks that can be ordered separately or that are bound
in the back of the book.  Some have associated postings on an
information service.  Some have printed computer program source
code listings in them.  In those rare cases where the book and
disk sets are not distributed by the publisher outside the USA,
it is almost certain that the books and disks will appear
outside the USA, because most book stores don't restrict their
sales to U. S. Citizens.    This country is both more pleasant and a lot more
secure without such nonsense.

4.6  Availability of Encryption Software

There is already a large number of free or very inexpensive
software packages available internationally from various
information services, computer bulletin boards, Internet ftp
sites, and commercial packages available off the shelf.  These
include:

    o Many DES implementations originating from many
      countries.

    o Several packages that implement the Swiss IDEA cipher.

    o Several packages that directly implement triple-DES.

    o Assorted implementations of published algorithms, some
      of which probably exceed DES in strength.

    o Assorted programs (such as utility packages, spread
      sheets, database programs, and word processors) that
      include some form of encryption that is incidental to
      their main function.  The security of the encryption
      varies from so poor that it should be called false
      advertising (like that used in Microsoft Word), to
      probably good against all but professional cryptanalysts
      (like PKZIP), to fairly decent implementations of DES or
      better.

    o Numerous proprietary algorithms, many of which probably
      claim greater security than they merit, but some of which
      may be very good.

    o A few encryption packages that effectively use a
      combination of the RSA public key encryption algorithm and
      a block cipher (DES, triple DES, or IDEA) to encrypt
      electronic mail.

    o Several cryptographer's tool kits that implement large
      integer arithmetic over finite fields, fast DES, IDEA,
      and RSA implementations, and other data that facilitates
      including these functions in other programs.

There are also a few cryptanalytical programs floating
around internationally to assist in cracking insecure
cryptosystems like the password protected files of Microsoft
Word and WordPerfect.  In most cases, this software encryption
and cryptanalytical software cannot ever be eradicated (even if
you think it should be), because there are so many copies held
by people who think that this software is a Good Thing.  Any one
copy can be copied again as much as desired.  Hiding software is
much easier than hiding elephants.

The bottom line is that the cat is out of the bag, so to speak,
and no amount of regulation can ever put the cat and all its
millions of kittens back in again.

4.7  DES is Dying

DES was doomed to a limited lifetime from the beginning by
limiting its key length to 56 bits.  This was probably done
intentionally, since there was much opposition to this decision
at the time.  It is also possible that this key length may have
been an indication from the NSA that because of differential
cryptanalysis, the strength of the algorithm didn't justify a
larger key.  Now a paper has been published that shows how DES
can be cracked for an amount of money that is within the budgets
of many nations and corporations (Efficient DES Key Search, by
Michael J. Wiener, 20 August 1993).  Schematic diagrams of
showing how to build a device to accomplish this task are
included in the paper, which has been distributed
internationally electronically.  I would be very surprised if
one or more of the world's major intelligence gathering
organizations had not already built DES cracking machines of
greater sophistication than Michael Wiener's.  The only reason
that I say that DES is not totally dead is that it is still
useful in some cases, for the same reason that physical locks
that can be picked with a pocket knife or credit card in a
matter of seconds are still sold and used.  DES encryption does
help keep unauthorized, honest, ladies and gentlemen out of your
proprietary and personal data.  When used in its triple DES
variant, it might even keep dishonest people with big budgets
and lots of motivation out of your private data.

4.8  Unbreakable Encryption

One very well known algorithm (called the One Time Pad), when
properly used (i. e. with truly random keys used only once), can
never be broken by anyone, no matter what their computing power.
The One Time Pad has been known to the general public for many
years, but it has not caused the end of the free world.  I've
never heard of a case of it being used for any criminal activity
except for spying (and there, I suppose, the use by "us" and
"them" somehow balances out).  The One Time Pad is still used to
protect our most sensitive diplomatic communications.  An
implementation of the One Time Pad in software is trivial, as
the following complete, non-hypothetical, Pascal program
demonstrates:

program one_pad;
  uses dos;
  var infile, keyfile, outfile: file of byte;
      plain, key, cipher: byte;
begin
  if paramcount < 3 then
    begin
      writeln('Usage: one_pad infile keyfile outfile')
    end
  else
    begin
      assign(infile, paramstr(1));
      reset(infile);
      assign(keyfile, paramstr(2));
      reset(keyfile);
      assign(outfile, paramstr(3));
      rewrite(outfile);
      while (not eof(infile)) and (not eof(keyfile)) do
        begin
          read(infile, plain);
          read(keyfile, key);
    {The following single line does the encryption/decryption.}
          cipher := plain xor key;
          write(outfile, cipher);
        end;
      close(outfile);
      close(infile);
      close(keyfile);
    end
end.

The whole One Time Pad program is short enough to be written
from memory (for an experienced programmer, anyway).  (For
instructions on using the above program, see your local library
or check out the sci.crypt Frequently Asked Questions document
on the Internet.)  It could be argued that the trivial program
above isn't a complete encryption system, since it doesn't do
any key management.

Ladies and gentlemen, does this document contain a weapon of war
or other munition, or is it just free exercise of the author's
freedom of the press?  Would the ITAR prohibit the export of
this document or not?  I claim that the U. S. Constitution
specifically allows me to publish this document, no matter what
the ITAR says.

5.  Economic Issues

While it seems clear that it is impossible to exercise our right
to freely publish encryption technical data and software in the
USA and at the same time prevent its export, it is very easy to
economically damage the USA with encryption export controls.

5.1  International Trade

It seems that the only encryption software that can be legally
exported for profit from the USA is either (1) crippled to
provide weak security (i. e. only a 40 bit key with RC-2 or
RC-4), (2) limited in function to certain purposes that do not
cover all market needs, or (3) limited in distribution to a
limited market.  Therefore, encryption software export is not a
very lucrative field to enter.  How can you compete with foreign
competitors who need not cripple their products?

5.2  Cryptographic Competition

There are sources of cryptographic software outside the USA
where the encryption software is not crippled, and is available
at a competitive price.  Given a choice, the full-featured,
secure software is more likely to win.  This means that other
countries will grow in this area and the USA will suffer
economically.

5.3  Domestic Chilling Effect

Export controls on encryption software discourage distribution
of strong encryption software in the USA and encourage the
weakening of domestic software to the same inadequate standards
forced upon exported software.  It seems better to buy (real or
perceived) strong security from an external source than from a
domestic, persecuted supplier.  Even though it would be
unconstitutional for the ITAR to disallow domestic distribution
of encryption software, few people want to be harassed by the
federal government or become a test case where the
unconstitutionality of the ITAR is conclusively proven in
court.

6.  Regulatory Issues

The International Traffic in Arms Regulations are designed to
make the world a safer place by limiting the export of weapons
and military equipment.  It also regulates classified or
otherwise non-public technical data about those weapons.  Most
of the items regulated have a whole lot more to do with the
objective of limiting arms proliferation than encryption
software and technical data.  The subject of this document,
however, is limited to a discussion of the regulation of
encryption technical data and software.

6.1  Clarity of Regulations and their Intent

For a regulation to be effective and enforceable, it must be
clear.  No one should be compelled to guess what the state
requires or proscribes.  Indeed, how could you be expected to
follow a law you don't understand?  There should be a clear way
of telling what is and is not allowed without having to submit
an item for censorship.  The intent of the regulation should
also be clear, so that a citizen could reasonably understand
what the regulation is for.

6.2  The First Amendment

The ITAR cannot override the Constitution of the United States
of America, in spite of its current claims that indicate that it
does.  To the degree that it does violate the Constitution, it
is null and void.  Any limitation on the freedom of speech and
freedom of the press of U. S. Citizens must be clearly linked
with a severe danger or denial of rights to another person that
can be proven in court.  Worse things than encryption software
have been upheld in court as Constitutionally protected
expression.

When balancing defense and intelligence considerations with the
U. S. Constitution, it is important to remember that (1) the
whole point of defense and intelligence operations is to protect
and defend the Constitution and the people of the United States
of America, (2) the Constitution is the Supreme law of the land,
and (3) federal officials and military officers in the USA are
sworn to uphold the Constitution.

There is a theory among those involved in private sector
cryptography in the USA that there is an official or
semi-official policy of discouraging strong cryptography within
the borders of the USA, while giving the appearance of
supporting it.  There is evidence to support this theory in
certain documents recently obtained under the Freedom of
Information Act by John Gillmore and released to the public.
This theory also explains a whole lot of otherwise difficult to
explain circumstances.  Because such a policy, if openly stated,
would sound stupid at best and like treason against the
Constitution at worst, it is not openly stated as such.  Export
control regulations and patent law appear to have been used as
tools to carry out this policy of discouraging strong
cryptography for the general public.  In the event this scandal
is even partially true, then the policy must be reexamined.
This policy might not exist, but some alternate explanations for
some of the evidence is even more disturbing.

6.3  Enforcement

A regulation that cannot possibly be enforced is of questionable
value, at best.  Ideally, it should be possible to detect all
violations and demonstrate beyond the shadow of a doubt to a
judge and jury that the violation was perpetrated by a specific
person or persons.

6.4  Consistency with Technology

Regulations cannot ignore technology, math and science.
Regulations cannot redefine pi to be exactly 3, repeal the law
of gravity, or stop radio waves at national boundaries.  In the
same way, regulations (like the ITAR) that treat public
information like tanks, guns, and nuclear weapons make no
sense.

7.  Recommendations

So far, I have pointed out problems and considerations that
cannot be satisfied concurrently.  On the other hand, it is
possible to do much better than current regulations do.

7.1  Reevaluate National Security Impact

A study of the total impact of public use of strong encryption
software should be made that includes all of the considerations
mentioned above, as well as classified data concerning just how
much impact (if any) such software (which is widely available
now and projected to increase in both quality and quantity) has
on current U. S. and foreign intelligence operations.

7.2  Deregulate Publicly Available Information

Export controls on publicly available information, including
encryption software and technical data, are not only
ineffective, unenforceable, unclear, and damaging to U. S.
business interests, they are likely to be ruled unconstitutional
in any serious challenge.  Deregulating this information would
help the U. S. economy, increase the use of strong encryption
software in the places where it does the most good, and have
minimal negative effects.  Since so much strong encryption
technical data and software is available now, it is unclear if
any additional negative effects would even be enough to measure.
 The desired effects of better security and technology in the
USA and a healthier economy would, however, be substantial.

7.3  Deregulate Research and Publication

Research and publication of scholarly work in the international,
public forums benefit the USA.  The fact that this also benefits
other nations does not diminish the value to the USA.  This does
not prevent the NSA from conducting classified research within
its security boundaries that is not available to the
international community.  It does prevent the NSA or any other
government agency from interfering with or discouraging any work
in the field of cryptography outside its own facilities.  The
NSA should maintain technological superiority by its own merit,
not by crippling all domestic competition.

7.4  Replace DES with Better Public Standard

DES is old and its key length is too short.  The public wants a
more secure encryption standard that is fully public and can be
used in software implementations.  The Swiss IDEA algorithm is
one likely alternative, but it would be better if an algorithm
that is royalty-free (like DES) could be made an official
standard.  Clipper/Capstone key escrow is not the answer to this
need, although it might be useful within the Federal
Government.

Several possible replacements for DES have been suggested.  One
that is much stronger than DES (and slightly stronger than IDEA)
and can be used royalty-free is the MPJ2 Encryption Algorithm,
which has been donated to the Public Domain by the inventor.
Technical details on this algorithm have been published, and are
available to U. S. Citizens in the USA.

7.5  Control NSA's Cryptographic Technology

While it is unreasonable to think that the general public's
cryptographic technology could possibly be confined to any one
country, it is not so difficult to control the technology in a
single organization such as the NSA.  The NSA should be, with
very few exceptions, a trap door for information on cryptography
and cryptanalysis.  They should strive to stay ahead of the
general public in these fields, and should not confirm or deny
what they can and cannot do to the general public without a
conscious decision by competent authority to do so (for example,
to endorse a DES replacement).  In like manner, the NSA should
not discourage or encourage any cryptographic technology outside
of their walls but still inside the USA.  Of course, even an
endorsement by the NSA is suspect, since their charter includes
reading other people's encrypted traffic.  It would be better,
in my opinion, to preserve the NSA as a national treasure of
cryptographic expertise by dealing with public encryption
standards totally within the Department of Commerce, National
Institute of Standards and Technology (NIST).

It is probable that someone in the USA (or another country) will
independently invent something that someone inside the NSA has
invented, and that person will be honored with fame and fortune
publicly for what has already been done privately within the
NSA.  This should never be construed as an excuse to censure the
public invention.  Indeed, to do so would leak information about
the NSA's technology level and capabilities to the outside
world.

7.6  Alternate Intelligence Methods

To mitigate the effect of the inevitable improvement in both the
quality and availability of strong encryption software and
hardware all over the world, it would be wise to invest in
alternate intelligence methods, such as harder to detect and
easier to place bugs.  Subtle long range bug delivery
mechanisms, relay devices, etc., could pay back great dividends
in intelligence value for the money for use in those cases where
strong encryption makes cryptanalysis impossible.

7.7  Alternate Law Enforcement Methods

There are many ways to catch a crook, no matter how
cryptographically sophisticated.  After all, it is much easier
to plant listening devices around a suspected drug trafficker,
serial murderer, or whatever, in our own country (with a proper
search warrant) than it is to try to figure out how to bug the
command center of an enemy dictator surrounded by a loyal army.
An encrypted phone conversation may actually lull the bugged
suspect into a sense of false security, talking openly about
crimes on a secure line.  An encrypted telephone does a criminal
little good if the room or car the phone is in is bugged.

7.8  Clarify & Repair Export Regulations

My specific recommendations to clarify the export regulations
with respect to encryption software, keep the encryption
technology that we use for our own military and diplomatic
communications safe, allow all reasonable commercial uses of
encryption technology in the United States, to make the
regulations much more enforceable, and to bring these
regulations into compliance with the United States of America's
Constitution follow.

$ 120.10 (1) should be altered (by removing the exception for
software defined in a nonexistent section) to read:

(1) Information which is required for the design development,
production, manufacture, assembly, operation, repair, testing,
maintenance or modification of defense articles. This includes
information in the form of blueprints, drawings, photographs,
plans, instructions and documentation.

$ 121.1, Category XIII, subcategory (b), items (1), (2) and (3),
should be modified to read:

(b) Information Security Systems and equipment, cryptographic
devices, software, and components specifically designed or
modified therefor, including:

(1) Cryptographic (including key management) systems, equipment,
assemblies, modules, integrated circuits, components or software
with the capability of maintaining secrecy or confidentiality of
information or information systems originated by the U. S.
Government or persons working under contract to the U. S.
Government, except for those specific items intentionally
released by the U. S. Government to the general public or
independently developed by a person or persons outside of the U.
S. Government.  In case of any doubt about the status of any of
these items, see $120.4.

(2) Cryptographic (including key management) systems, equipment,
assemblies, modules, integrated circuits, components or software
which have the capability of generating spreading or hopping
codes for spread spectrum systems or equipment and which were
originated by the U. S. Government or persons working under
contract to the U. S. Government, and not independently
developed outside of the U. S. Government.

(3) Cryptanalytic systems, equipment, assemblies, modules,
integrated circuits, components or software originated by the U.
S. Government or persons working under contract to the U. S.
Government, and not independently developed outside of the U. S.
Government.

The above changes have the effect of maintaining strict controls
on the cryptosystems that we use in our own military and
diplomatic service, but has no ill effects on the U. S.
Constitution or economy.  It also has the effect of costing less
taxpayer money to support censorship (Commodity Jurisdiction)
proceedings.

$ 121.8 (f) should be modified to read (deleting the exception
for encryption software):

(f) Software includes but is not limited to the system
functional design, logic flow, algorithms, application programs,
operating systems and support software for design,
implementation, test, operation, diagnosis and repair. A person
who intends to export software only should apply for a technical
data license pursuant to part 125 of this subchapter.

{% endraw %}
```

## Thread

+ Return to [January 1994](/archive/1994/01)

+ Return to "[Michael Johnson <mpj@csn.org>](/authors/michael_johnson_mpj_at_csn_org_)"

+ 1994-01-07 (Fri, 7 Jan 94 05:34:41 PST) - Crypto Controls in the USA - _Michael Johnson<EMAIL_ADDRESS>

gha_license_id: MIT


text:
---

layout: default

style: |

  .slide p {
    margin-bottom: 24px;
  }

  .slide h3 {
    font-size: 30px;
    font-weight: bold;
  }

  .slide blockquote cite {
    font-weight: 700;
  }

  .slide table th,
  .slide table td {
    background: none;
  }

  .slide pre code {
    background-color: #efefef;
    padding: 0.5em;
    line-height: 1.5em;
    font-sizeL 20px;
  }

  .no-title h2 {
    display: none;
  }

  .two-codes table td {
    width: 50%;
  }

---

# Component development in CSS

*by [Varya Stepanova](http://varya.me/) from [SC5 Online](http://sc5.io/)*

![](pictures/cover.jpg)

## Me
{: .no-title }

### Now
Senior Frontend Develover for SC5 Online

### Before
TMG (Amsterdam, the Netherlands); Yandex (Moscow, Russia)

###Area of expertise
Components in web: libraries, SGDD, BEM. Techs: CSS, JavaScript, etc.

## Spoiler

You will learn:

TODO: List

## CSS

> *Cascading Style Sheets* (CSS) is a style sheet language used for describing the look and formatting of a document
> written in a markup language. [Wikipedia](https://en.wikipedia.org/wiki/Cascading_Style_Sheets)

First published in 1996
{: .note}

## Industry challenges
{: .no-title }

![](pictures/homepage.png)

## Bulletproof Web Desing
{: .bulletproof .no-title }

## Big CSS

* massive sites
* big teams of developers
* heavy UI
* long running projects

##Is this good?

    H1 { color: blue }
    P EM { font-weight: bold }
    A:link IMG { border: 2px solid blue }
    A:visited IMG { border: 2px solid red }
    A:active IMG { border: 2px solid lime }

## What makes CSS hard?

* …Vertical centring
* …Equal height columns
* …Browser inconsistencies
* …Unobvious tricks

## What are the real hard problems in CSS?

* Scoping
* Specificity conflicts
* Non-deterministic matches
* Dependency management
* Removing unused code

## CSS has no scoping

    a { /* Affects all the links */
      color: red;
    }
    ul li a { /* Affects all the links in lists */
      color: green;
    }

## Specificity

> Specificity is the means by which a browser decides which property values are the most relevant to an element and gets
> to be applied. Specificity is only based on the matching rules which are composed of selectors of different sorts.

## The most specific matters

      Text

<separator/>

    div#test span { color: green }
    span { color: red }
    div span { color: blue }

## How to overwrite?

Left floated sidebar

<separator/>

    .sidebar { /* Does not work?! */
      float: right;
    }
{: .next }

<separator/>

    body .sidebar { /* Overwrites 'div .sidebar {}' */
      float: right;
    }
{: .next }

## Specificity hell
{: .no-title }

    .navbar-inverse .navbar-nav>li>a {
      color: #999;
    }

    #home-menu-container #home-menu li a {
      color: red;
    }

    body #home-menu ul li a {
      color: blue !important;
    }

##Non-deterministic matches

    #content div div {
      float: left;
    }

## Dependency management
{: .dependency-management }

###No dependecies, sorry

### But what about?

    @import url('i-need-this.css');

### No, sorry again.
{: .next .sorry }

## Removing unused code

100 pages in projects

    .person div a {
      color: pink;
    }

Can I remove it? Will it break something? Maybe it is for a third-party HTML code?

## Where CSS is hard?
{: .no-title .hard-css }

This is not hard in CSS

This is!

    #sidebar ul li a {
      color: red;
      display: block;
      padding: 1em;
    }

    #sidebar ul li a {
      color: red;
      display: block;
      padding: 1em;
    }

*How do we architect encapsulated components?*
{: .next }

## Methodologies
{: .shout }

##OOCSS
{: .shout }

##Nicole
Sullivan
{: .nicole }

## SMACSS
{: .shout }

##Jonathan
Snook
{: .jonathan }

## BEM
{: .shout }

## Vitaly
Harisov
{: .harisov }

## Sergey
Berezhnoy
{: .veged }

## BEM eco-system

* CSS Methodology
* JavaScript framework
* Template engine
* Building system
* Suplimentary tools

## Harry & Nicolas
{: .no-title .harry-nicolas }

### Harry
Roberts
{: .harry }

###Nicolas
Gallagher
{: .nicolas }

## BEM

* Block
* Element
* Modificator

## Interface
{: .no-title .interface }

## Interface of blocks
{: .no-title .interface-blocks }

## Everything is a block
{: .no-title }

...

...

...

...

## Why not...?

Tab 1

Tab 2

<separator/>

    #menu {
      /* styles for element */
    }

## No IDs

Someday you will need to repeat the block at the same page

## Elements
{: .elements }

![](pictures/bem/elements.png)

## Elements markup
{: .no-title }

          <li class="tabbed-pane--tab">Tab1

          <li class="tabbed-pane--tab">Tab2

          <li class="tabbed-pane--tab">Tab3

          ...

## CSS for an element

    .block {
      /* styles for block */
    }
      .block--element {
        /* styles for element */
      }

## Why not...?

Tab 1

Tab 2

<separator/>

    .menu .item {
      /* styles for element */
    }

## No cascade

## Modified block
{: .no-title .modified-block }

## Modifier

    <ul class="menu menu_footer">

...

      ...

<separator/>

    .menu_footer {
      font-size: 0.8em;
    }

## CSS for modifier
    .block {
      /* styles for block */
    }
      .block_modifier {
        /* styles for modifier */
      }
      .block--element {
        /* styles for element */
      }

## Modified element

![](pictures/bem/menu-current-item.png)

## Element's modifier

Tab 1

      <li class="menu--item menu--item_current">Tab 2

Tab 3

## CSS for elements' modifier

    .block
      /* styles for block */
    }
      .block--element {
        /* styles for element */
      }
        .block--element_modifier {
          /* styles for modified element
        }
{: .css }

## Why not...?

...

<separator/>

    .menu.footer { /* combined selector */
      font-size: 0.8em;
    }

## Why not...?

Tab 2

<separator/>

    .menu--item.current { /* combined selector */
      background-color: red;
    }

## No overspecific selectors

You would suffer when redefining

    .menu--item.current {
      background: white;
    }
    .menu_dark .menu--item {
      background: black; /* Still white, baby */
    }

## BEM & CSS preprocessors

    .block {
      /* styles for block */
      &_modifier {
        /* styles for modifier */
      }
      &--element {
        /* styles for element */
      }
    }
{: .css }

## [getbem.com](http://getbem.com/)
{: .shout }

## This is solved

* Scoping
* Specificity conflicts
* Non-deterministic matches
* Dependency management
* Removing unused code

## Web Components
{: .shout }

## Technologies behind
{: .wc-behind }

* Shadow DOM
* Custom Elements
* HTML Templates
* HTML Imports

## Web Components

* [Navite component](demo/video.html)
* [Custom web component](demo/custom-button.html)
* [Templates](demo/templates.html)
* [HTML import](demo/html-import.html)

## HTML import, library

    <link rel="import" href="my-lib/google-map.html">

    <google-map lat="37.790" long="-122.390"></google-map>

## Are We Componentized Yet?
{: .componentized }

![](pictures/componentized.png)

## Web Components Polyfills
{: .wc-polyfills }

* [WebComponents.org](http://webcomponents.org/)
* [X-Tag](http://www.x-tags.org/)

## Make it work

    <link rel="import" href="google-map.html">

    <google-map lat="37.790" long="-122.390"></google-map>

## Ready-made components

* [Polymer](https://www.polymer-project.org/)
* [Google Web Components](http://googlewebcomponents.github.io/)

## Examples of usage

* [Toolbar](demo/toolbar.html)
* [Google map](demo/google-map.html)

## Style guide driven development

## Summary

repository: ingdir/component-driven-web

gha_language: Ruby

repo_name: ingdir/component-driven-web


text:
# openapigenlib

This internal library does the actual generating of an OpenAPI spec based on a RESTful endpoint.

## Using

To use in your Go program or library, simply get and import the openapigenlib module like this:

```
go get github.com/tyayers/openapigen/openapigenlib
```

Then generate an OpenAPI spec in your code by calling:

```
spec := openapigenlib.GenerateSpec("https://jsonplaceholder.typicode.com/todos")
```

The spec variable above will contain a string of the complete OpenAPI spec that fits the payload returned by the given URL.

## Testing

To test the module just run

```
go test
```

This will test the generation with some common REST endpoints.

repository: tyayers/openapigen

branch_name: refs/heads/main

repo_name: tyayers/openapigen


text:
# Base configuration
Anatomy of a minimal Terraform configuration using the Azure Resource Manager (AzureRM) provider.

## Resources
- Documentation:
  - conventions: https://www.terraform.io/docs/configuration/style.html
  - syntax: https://www.terraform.io/docs/configuration/syntax.html
  - Terraform configuration: https://www.terraform.io/docs/configuration/terraform.html
  - Providers: https://www.terraform.io/docs/configuration/providers.html
- Tutorial: https://learn.hashicorp.com/terraform/azure/configure_az#providers

## Goal
Understand:
- flat layout of a terraform project
- Terraform configuration
- provider notion (and the underlaying plugins based architecture)
- CLI base usage & workflow

## Setup
If not done already, login to Azure:
```bash
az login
```

Initialize your workspace once:
```bash
# Init cloud provider plugin & template plugin
terraform init
```

## Usage
Validate your configuration is working and you don't have any error:
```bash
# plan your deployment
terraform plan
# apply your deployment
terraform apply
```

## Teardown
Destroy resources when finished:
```bash
terraform destroy
```

repository: bgauduch/terraform-azure-demo

gha_language: HCL

repo_name: bgauduch/terraform-azure-demo


text:
v1.7.0 (2014-10-03)
-------------------

- Save timestamps in POSIX time instead of a user-specific string format; the
  format setting is now only used for displaying absolute timestamps in the
  panel (see #28)
- Remove doubled information in history file, namely 'action' key (#30)
- Fix a bug where quickly browsing through the reopen panel would cause some
  views to get mistaken for real views and added to the history (#31)
- Fix exception when timestamp could not be parsed (#28)

repository: FichteFoll/FileHistory

gha_language: Python

repo_name: FichteFoll/FileHistory


text:
# gfinance-portfolio-viz
Picture it, Sicily: 1922.  How to correct it? Picture it -- Visualize the sector composition of your Google Finance Portfolio by exporting to spreadsheet and loading the result into this page.

## See an example
The sector names are a little different between this shot and the current version -- particularly any ETFs you have, will come up "n/a", but whaddaya want for free!?
![Several views of my changing portfolio](https://github.com/masyukun/gfinance-portfolio-viz/blob/master/screenshots/Robinhood-Election.png)

## How to use it
### Export your portfolio
![Export your Google Finance Portfolio as a CSV spreadsheet](https://github.com/masyukun/gfinance-portfolio-viz/blob/master/docs/gfpexport.gif)

### Upload it to the app
 - Open the index.html file with your modern web browser. You can run it from your desktop; no need to put it on a webserver. Although if you do, tell me about it so I can admire it.
![Load the CSV into the viz app](https://github.com/masyukun/gfinance-portfolio-viz/blob/master/docs/gfpload.gif)

### Click the things
 - Clicking on a block drills down into it so you can see what it's made of.
 - Right-clicking zips you back out.

repository: masyukun/gfinance-portfolio-viz

repo_name: masyukun/gfinance-portfolio-viz


text:
---
title: Satisfaction
author: Kerim
layout: post
permalink: /archives/2004/06/09/satisfaction/
categories:
  - Info Tech
  - Law
---
I was contemplating purchasing a laser printer from a company called Legend Micro – until I read their return policy.

> Return Policy
>
> In order to remain competitive in today’s marketplace and continue to provide exceptional service to its customers, Legend Micro is instituting a new 100% Product Satisfaction Policy effective October 1, 2003:
>
> 1. 15 Day 100% Money Back Guaranty for retail and mail order customers.

Sounds great, doesn’t it? But read the list of excluded items (emphasis added):

> **Absolutely no refunds** on processors, memory chips, LCD monitors, notebooks, **printers**, fax machines and software

That seems to cover a pretty large swath of their product line. I thought there must be some mistake, so I e-mailed them. No reply. So then I called them. Michael informed me that “every agreement always has two sides” – yes it does: suckers and profiteers.

repository: kerim/keywords

repo_name: kerim/keywords


text:
# Deployment of FortiGate-VM HA on the Google Cloud Platform (GCP) with external load balancer and internal load balancer
## Introduction
A Terraform script to deploy FortiGate-VM HA (A-P) on GCP with both an external load balancer and internal load balancer.

## Requirements
* [Terraform](https://learn.hashicorp.com/terraform/getting-started/install.html) >= 0.12.0
* Terraform Provider for Google Cloud Platform 2.11.0
* Terraform Provider for Google Cloud Platform Beta 2.13
* Terraform Provider for random 2.2.1
* Terraform Provider for template 2.1.2
* A [GCP OAuth2 access token](https://developers.google.com/identity/protocols/OAuth2)

## Deployment overview
Terraform deploys the following components:
   - A Virtual Private Cloud (VPC) with one public subnet
   - A VPC with three private subnets
   - Two FortiGate-VM instances with four NICs
   - Four firewall rules: one for external, one for internal, one for sync, and one for HA management.
   - One external load balancer with two Fortigates's external port as targets
   - One internal load balancer with two FortiGate's private port as target.
   - One NAT and Router device for egress traffic.

## Deployment
To deploy the FortiGate-VM to GCP:
1. Clone the repository.
2. Obtain a GCP OAuth2 token and input it in the vars.tf file.
3. Customize variables in the `vars.tf` file as needed.
4. Initialize the providers and modules:
   ```sh
   $ cd XXXXX
   $ terraform init
    ```
5. Submit the Terraform plan:
   ```sh
   $ terraform plan
   ```
6. Verify output.
7. Confirm and apply the plan:
   ```sh
   $ terraform apply
   ```
8. If output is satisfactory, type `yes`.

Output will include the information necessary to log in to the FortiGate-VM instances:
```sh
External-Load-Balancer-Public-IP-Address = "XXX.XXX.XXX.XXX"
FortiGate-HA-Active-MGMT-IP = "XXX.XXX.XXX.XXX"
FortiGate-HA-Passive-MGMT-IP = "XXX.XXX.XXX.XXX"
FortiGate-Password = "<Password Here>"
FortiGate-Username = "admin"
Internal-Load-Balancer-Public-IP-Address = "XXX.XXX.XXX.XXX"
```

## Destroy the instance
To destroy the instance, use the command:
```sh
$ terraform destroy
```

# Support
Fortinet-provided scripts in this and other GitHub projects do not fall under the regular Fortinet technical support scope and are not supported by FortiCare Support Services.
For direct issues, please refer to the [Issues](https://github.com/fortinet/fortigate-terraform-deploy/issues) tab of this GitHub project.
For other questions related to this project, contact [github@fortinet.com](mailto:github@fortinet.com).

## License
[License](https://github.com/fortinet/fortigate-terraform-deploy/blob/master/LICENSE) © Fortinet Technologies. All rights reserved.

repository: fortinet/fortigate-terraform-deploy

repo_name: fortinet/fortigate-terraform-deploy


text:
# quantum-2

## Challenge Description
Let's increase the difficulty. Same algorithm, new circuit.

In practice, quantum compilers and programmers make use of techniques which don't exist in classical reversible computing, even for seemingly classical subroutines. While this circuit has more gates than the `quantum 1` circuit, it also requires much fewer qubits. In fact, the main computational step only uses [2n+3 qubits](https://arxiv.org/abs/quant-ph/0205095).

provided files
- ./circuit_parts.7z
- ./encrypted_message.rsa

## Challenge Overview

`quantum-2` is a harder version of the same challenge. While `quantum-1` used a purely classical reversible circuit to compute the modular exponentiation step of Shor's algorithm, `quantum-2` uses a quantum subroutine. Specifically, `quantum-1` used the [Cuccaro ripple-carry adder](https://arxiv.org/abs/quant-ph/0410184) to add two numbers stored in quantum memory.

However, in Shor's algorithm, you only ever need to add classical numbers to numbers to stored in quantum memory. You can save a lot of ancillary qubits by using a different quantum addition subroutine -- namely, addition based on the Quantum Fourier Transform (QFT).

Some relevant papers are:
- https://arxiv.org/abs/1411.5949
- https://arxiv.org/abs/quant-ph/9511018
- https://arxiv.org/abs/quant-ph/0008033

The QFT is used at the end of the circuit, so players should recognize the repitition, but I also explicitly linked the paper in the challenge desciption. It's also the top result if you google "quantum addition algorithm".

The QFT-adder performs addition by taking the QFT of the input qubits, and then performing controlled rotations. The controlled rotations are controlled against a classical register, not a quantum register, so there will either be a rotation or not. ie, the "controlled" part of it is optimized away during compilation. You can use this to figure out what the classical register bits are: if there is a rotation, then the control bit is 1. Compare against "the paper" to identify what the control bits should be to produce those rotations -- this is the classical number which is being added. There's a slight complication that we coalesce all the rotations of the same qubit together, so you have to do a bit of math.

Once you understand how the QFT-adder works and how to extract the classical numbers from the circuit, recovering `N` is actually easier than in `quantum-1`. This is because `N` is hardcoded the 2nd time the QFT-adder is called -- no baby number theory required! But the core approach is still seeing which numbers are being added and looking for a pattern. Obtaining the flag once you've found `N` is identical to in `quantum-1`.

## QFT analysis

Here's an example of how to analyze the quantum circuit to extract the number being added from the rotation angles.

Most of the phase / z-rotation gates in the circuit files are just implementing the QFT. However, all of the phase gates which actually encode the numbers being added are multiply-controlled phase gates. This is the only context in which `mcphase` gates appear in the circuit, so you can simply grep the circuit files to extract the rotation angles. Guessing this is not necessary, as you can simply analyze all consecutive sequences of phase gates whose length is near 64.

`grep mcphase ../challenge/circuit_parts/circuit_z_0.qasm -A 0 > output_z_0.txt`

The last few angles from the first such rotation are:
```
mcphase(0.96947586) q[128],q[0],q[201];
mcphase(1.9389517) q[128],q[0],q[200];
mcphase(3.8779034) q[128],q[0],q[199];
mcphase(1.4726216) q[128],q[0],q[198];
mcphase(15*pi/16) q[128],q[0],q[197];
mcphase(15*pi/8) q[128],q[0],q[196];
mcphase(7*pi/4) q[128],q[0],q[195];
mcphase(3*pi/2) q[128],q[0],q[194];
mcphase(pi) q[128],q[0],q[193];

```

The appearance of `pi` on the final angles indicates that you should convert divide each floating point number by (2 * pi), which will then give a fraction where the denominator is a power-of-2. This is also explained in the paper.

```
0.1542968753272663
0.30859374747143375
0.6171874949428675
0.23437500694389587
0.46874999999999994
0.9374999999999999
0.875
0.75
0.5
0
```

Trying out a few possible values for the denominator reveals that all of the new floating point numbers can be written as a fraction where the denominator is `2^12`. The corresponding numerators are `[0, 2048, 3072, 3584, 3840, 1920, 960, 2528, 1264]`, whose binary representation is:

```
[+] 8   1264<PHONE_NUMBER>00
[+] 7   2528<PHONE_NUMBER>00
[+] 6   960<PHONE_NUMBER>00
[+] 5   1920<PHONE_NUMBER>00
[+] 4   3840<PHONE_NUMBER>00
[+] 3   3584<PHONE_NUMBER>00
[+] 2   3072<PHONE_NUMBER>00
[+] 1   2048<PHONE_NUMBER>00
[+] 0   0<PHONE_NUMBER>00
```

The diagonal pattern is pretty clear. You can read off the binary representation of the number being added by looking at the most significant bit of the denominator, in this case (from bottom-to-top) `[0, 1, 1, 1, 1, 0, 0, 1, 0, ...]`. Read the paper to understand why.

## Extracting `N`

The [attached] solve script analyzes the first 20 additions present in the `circuit_z_0.qasm` file, and obtains:
```
1149389920988353694
1149785239057719001
395318069365307
395318069365307
1148994602918988387
1149785239057719001
790636138730614
790636138730614
1148203966780257773
1149785239057719001
1581272277461228
1581272277461228
1146622694502796545
1149785239057719001
3162544554922456
3162544554922456
1143460149947874089
1149785239057719001
6325089109844912
6325089109844912
...
```

The pattern here is `N-a, N, a, a, N-2*a, N, 2*a, 2*a, N-4*a, ...`, which is pretty similar to what appeared in `quantum-1`.

path: /Quantum Rev 2/solve/writeup.md


text:
---
# Display name
title: Reagan Mozer

# Is this the primary user of the site?
superuser: true

# Role/position/tagline
role: Assistant Professor of Mathematical Sciences at Bentley University

# Organizations/Affiliations to show in About widget
organizations:
- name: Bentley University
  url: https://www.bentley.edu/

# Short bio (displayed in user profile at end of posts)
bio: Assistant Professor of Mathematical Sciences
# Interests to show in About widget
interests:
- Filler
- Filler
- Filler

# Education to show in About widget
education:
  courses:
  - course: Ph.D. in Statistics
    institution: Harvard University
    year: 2019
  - course: A.M. in Statistics
    institution: Harvard University
    year: 2015
  - course: B.S. in Applied and Computational Mathematics
    institution: University of Southern California
    year: 2014

# Social/Academic Networking
# For available icons, see: https://sourcethemes.com/academic/docs/page-builder/#icons
#   For an email link, use "fas" icon pack, "envelope" icon, and a link in the
#   form<EMAIL_ADDRESS>or "/#contact" for contact widget.
social:
- icon: envelope
  icon_pack: fas
  link: '/#contact'
#- icon: twitter
#  icon_pack: fab
#  link: https://twitter.com/GeorgeCushen
- icon: google-scholar  # Alternatively, use `google-scholar` icon from `ai` icon pack
  icon_pack: ai
  link: https://scholar.google.com/citations?user=WiS6WtMAAAAJ&hl=en
#- icon: github
#  icon_pack: fab
#  link: https://github.com/gcushen
#- icon: linkedin
#  icon_pack: fab
#  link: https://www.linkedin.com/

# Link to a PDF of your resume/CV.
# To use: copy your resume to `static/media/resume.pdf`, enable `ai` icons in `params.toml`,
# and uncomment the lines below.
- icon: cv
  icon_pack: ai
  link: media/resume.pdf

# Enter email to display Gravatar (if Gravatar enabled in Config)
email: ""

# Highlight the author in author lists? (true/false)
highlight_name: false
---

I am currently an Assistant Professor of Mathematical Sciences at Bentley University. Prior to joining Bentley, I received my PhD in statistics at Harvard University, where I was a member of the CARES Lab led by Luke Miratrix and affiliate of the Institute for Quantitative Social Science.

My research is eclectic and I find myself constantly drawn to applied statistics problems in fields ranging from education to political science to pharmaceutical research. But underneath it all, I'm interested in the development and application of methods for causal inference with complex data, including text data, randomized experiments complicated by issues such as non-compliance, and observational studies with time-varying treatments.

{{< icon name="download" pack="fas" >}} Download my {{< staticref "media/resume.pdf" "newtab" >}}resumé{{< /staticref >}}.


text:
## ROLE: create/genesis_nodekey
This role generates genesis.json and nodekey/enode for each organization.
### main.yaml
### Tasks
(Variables with * are fetched from the playbook which is calling this role)
#### 1. Check if nodekey is present in vault
This task checks if nodekey is present in the vault or not
**include_tasks**: nodekey_vault_check
**loop**: loops over all the node in an organisation
**loop_control**: Specifies the condition for controlling the loop.
    loop_var: loop variable used for iterating over the loop.
##### Input Variables
     *component_ns: Organization namespace
     *vault: Vault uri and token read from network.yaml

#### 2. Fetching data of validator nodes in the network from network.yaml
##### Input Variables
    *node_name: Name of the node
**include_tasks**: It includes the name of intermediary task which is required for creating the ambassador certificates.
**loop**: loops over all the node in an organisation
**when**: vault_check count is greater than zero.
**loop_control**: Specifies the condition for controlling the loop.

    loop_var: loop variable used for iterating over the loop.

#### 3. Create build directory if it does not exist
This task creates the build directory if it does not exist.
**file** : This module will create the directory if it does not exist with 755 permissions.
**when**: vault_check count is greater than zero.

#### 4. Generate istanbul files
 This task generates the istanbul files
**shell**: This task generates the nodekey for each node placed in numerical directories
**when**: vault_check count is greater than zero.

#### 5. Rename the directories created above with the elements of validator_node_list
This task rename the above created directories to the org_name/node_name
**copy** : This module copies the content of numerical directories to org/node directory
**when**: vault_check count is greater than zero.

#### 6.  Call nested check for each node
This task calls nested_nodekey_vault_check to check if nodekey for each node is present or not
**include_tasks**: It includes the name of intermediary task which is required for checking the presence of nodekey.
**loop**: loops over all the node in an organisation
**loop_control**: Specifies the condition for controlling the loop.

    loop_var: loop variable used for iterating over the loop.

----------------
### nested_nodekey_vault_check
### Tasks
#### 1. Check if nodekey already present in the vault
##### Input Variables

    *VAULT_ADDR: Contains Vault URL, Fetched using 'vault.' from network.yaml
    *VAULT_TOKEN: Contains Vault Token, Fetched using 'vault.' from network.yaml
    ignore_errors: Ignore if any error occurs

##### Output Variables

    vault_nodekey_result: This variable stores the output of nodekey check query.

#### 2. vault_check variable
**set_fact**: This module sets the variable *vault_check* globally.
**when**: It runs when *vault_nodekey_result.failed* == True, i.e. nodekey of any of the node is not in vault.

--------------------------
### validator_node_data.yaml

#### 1. Get validator node data
This task fetch (org,node) pairs for each validating node present in all organizations of the network
**when**: peer.type == 'validator'
**loop_control**: Specify conditions for controlling the loop.

    loop_var: loop variable used for iterating the loop.


text:
---
layout: default
---

# 1993-06-09 - CERT: the letter from CERT to berkeley.edu admin

## Header Data

From: Eric Hughes<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: 323222d8ed7c538a53190173f189cfa5142159c4b62fb43634dcd0e2a3db1743

Message ID<EMAIL_ADDRESS>Reply To<EMAIL_ADDRESS>UTC Datetime: 1993-06-09 14:31:36 UTC

Raw Date: Wed, 9 Jun 93 07:31:36 PDT

## Raw message

```
{% raw  %}From: Eric Hughes<EMAIL_ADDRESS>Date: Wed, 9 Jun 93 07:31:36 PDT
To<EMAIL_ADDRESS>Subject: CERT: the letter from CERT to berkeley.edu admin
In-Reply-To<EMAIL_ADDRESS>Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

>For soda, the mail went to<EMAIL_ADDRESS>
The first CERT letter was sent to a contact for the berkeley.edu
domain, not to soda.  This original recipient then forwarded the mail
to root@soda, which is aliased to a number of people.  The root who
turned off the directory is not the same one who finally forwarded me
the CERT letter.

In short, they went over Julf's head, and they went over mine.

Eric

{% endraw %}
```

## Thread

+ Return to [June 1993](/archive/1993/06)

+ Return to "[Eric Hughes <hughes@soda.berkeley.edu>](/authors/eric_hughes_hughes_at_soda_berkeley_edu_)"
+ Return to "[Marc Horowitz <marc@GZA.COM>](/authors/marc_horowitz_marc_at_gza_com_)"
+ Return to "[peter honeyman <honey@citi.umich.edu>](/authors/peter_honeyman_honey_at_citi_umich_edu_)"
+ Return to "[Peter Shipley <shipley@tfs.COM>](/authors/peter_shipley_shipley_at_tfs_com_)"
+ Return to<EMAIL_ADDRESS>(Stig)](/authors/stig_at_netcom_com_stig_)"

+ 1993-06-08 (Tue, 8 Jun 93 13:34:23 PDT) - [Re: CERT: the letter from CERT to berkeley.edu admin](/archive/1993/06/43ca1dab3cb57c5a8e2f312e384d8b667560b02a851864999df5108b83bbda2c) - _peter honeyman<EMAIL_ADDRESS>  + 1993-06-08 (Tue, 8 Jun 93 13:54:48 PDT) - [Re: CERT: the letter from CERT to berkeley.edu admin](/archive/1993/06/c184c219901549766e4e6a854baeac44a27d7c87171171603f1db7150b29220a) - _Marc Horowitz<EMAIL_ADDRESS>    + 1993-06-09 (Wed, 9 Jun 93 01:43:09 PDT) - [Re: CERT: the letter from CERT to berkeley.edu admin](/archive/1993/06/b80b51c913dd6b8c67cc1707225de9981eeecb410eabfbc8ae37f8f4a78d0806) -<EMAIL_ADDRESS>(Stig)_
      + 1993-06-09 (Wed, 9 Jun 93 07:31:36 PDT) - CERT: the letter from CERT to berkeley.edu admin - _Eric Hughes<EMAIL_ADDRESS>  + 1993-06-08 (Tue, 8 Jun 93 14:11:19 PDT) - [Re: CERT: the letter from CERT to berkeley.edu admin](/archive/1993/06/6e5e04773fe7693d8749ff0f4930c40ba1747961d39ebffc8a70b1800d72192e) - _Peter Shipley<EMAIL_ADDRESS>


text:
# CQ Client Library.

This directory contains CQ client library to be distributed to other repos. If
you need to modify some files in this directory, please make sure that you are
changing the canonical version of the source code and not one of the copies,
which should only be updated as a whole using Glyco (when available, see
[chromium issue 489420](http://crbug.com/489420)).

The canonical version is located at
[https://chrome-internal.googlesource.com/infra/infra_internal/+/master/commit_queue/cq_client]().

When modifying cq.proto, consider adding checks to validator in
[https://chrome-internal.googlesource.com/infra/infra_internal/+/master/appengine/commit_queue/src/commitqueue/validate.go]().

## Updating depot_tools with the copy of this.

    make update-depot-tools

## Generation of Python and Go bindings

### tl;dr

    make

### Details

All commands below assume you are working in a standard infra_internal gclient
checkout (e.g., after you ran `mkdir src && cd src && fetch infra_internal`) and
are in current directory of this README.md (that is, in
`cd infra_internal/commit_queue/cq_client`).

To generate Python's `cq_pb2.py` you'll need to get and `protoc` of version
**2.6.1**. You can get it by `make py-prepare`.

    make py

To generate Golang's protobuf file `cq.pb.go`, you'll need to bootstrap
infra/infra repository and go utilities `make go-prepare`.

    make go

## Notes

1. Please make sure to use proto3-compatible syntax, e.g. no default
values, no required fields. As of this writing (Jan 2016),
the Go protobuf compiler has been upgraded to 3.0.0. So, if you can generate go
bindings, all is good.

2. If after generating Python binding, CQ tests fail with:

        TypeError: __init__() got an unexpected keyword argument 'syntax'

You've probably used 3.0.0 protoc generator. We should eventually switch to 3x
Python version as well, but it requires upgrading infra's Python ENV to newer
package. See [bootstrap/README.md](../../bootstrap/README.md) for more
information.  We may end up deprecating Python before all infra's Python code
can be moved to protobuf v3.

repository: Shouqun/node-gn

repo_name: Shouqun/node-gn


text:
---
layout: post
title: "Deep Residual Text Detection Network for Scene Text"
date: 2017-11-11 15:03:33
categories: arXiv_CV
tags: arXiv_CV Object_Detection CNN Classification Detection
author: Xiangyu Zhu, Yingying Jiang, Shuli Yang, Xiaobing Wang, Wei Li, Pei Fu, Hua Wang, Zhenbo Luo
mathjax: true
---

* content
{:toc}

##### Abstract
Scene text detection is a challenging problem in computer vision. In this paper, we propose a novel text detection network based on prevalent object detection frameworks. In order to obtain stronger semantic feature, we adopt ResNet as feature extraction layers and exploit multi-level feature by combining hierarchical convolutional networks. A vertical proposal mechanism is utilized to avoid proposal classification, while regression layer remains working to improve localization accuracy. Our approach evaluated on ICDAR2013 dataset achieves F-measure of 0.91, which outperforms previous state-of-the-art results in scene text detection.

##### Abstract (translated by Google)
场景文本检测是计算机视觉中的一个挑战性问题。在本文中，我们提出了一个基于流行的对象检测框架的新型文本检测网络。为了获得更强的语义特征，我们采用ResNet作为特征提取层，结合分层卷积网络开发多层特征。采用垂直提案机制来避免提案分类，而回归层仍在努力提高定位精度。我们对ICDAR2013数据集进行评估的方法实现了0.91的F-measure，其优于先前在场景文本检测中的先进结果。

##### URL
[https://arxiv.org/abs/1711.04147](https://arxiv.org/abs/1711.04147)

##### PDF
[https://arxiv.org/pdf/1711.04147](https://arxiv.org/pdf/1711.04147)


text:
# Stoic Quotes

A simple app that displays random Stoic quotes from Seneca, Marcus Aurelius, and Epictetus.

[stoic-quotes.com](https://stoic-quotes.com)

Please feel free to make a pull request if you want to add your favourite Stoic quote to the app 🙂

# Using the API

This app exposes a public API which you are free to use to fetch random Stoic quotes for use in your own applications.

### Endpoints

#### Get a random Stoic quote

```
GET https://stoic-quotes.com/api/quote
```

##### Example JSON response

```json
{
  "text": "All that exists is the seed of what will emerge from it.",
  "author": "Marcus Aurelius"
}
```

#### Get a list of random Stoic quotes

```
GET https://stoic-quotes.com/api/quotes
```

Optionally pass in a `num` param to change the number of quotes returned.
`num` defaults to `10`, and can not be higher than `100`.

```
GET https://stoic-quotes.com/api/quotes?num=10
```

##### Example JSON response

```json
[
  {
    "text": "All that exists is the seed of what will emerge from it.",
    "author": "Marcus Aurelius"
  },
  {
    "text": "If it doesn't harm your character, how can it harm your life?",
    "author": "Marcus Aurelius"
  }
]
```

repository: benhoneywill/stoic-quotes

gha_language: JavaScript

repo_name: benhoneywill/stoic-quotes


text:
# sso

[![CircleCI](https://circleci.com/gh/buzzfeed/sso.svg?style=svg)](https://circleci.com/gh/buzzfeed/sso)
[![MIT license](http://img.shields.io/badge/license-MIT-brightgreen.svg)](http://opensource.org/licenses/MIT)

<img src="https://user-images.githubusercontent.com/10510566/44476420-a64e5980-a605-11e8-8ad9-2820109deb75.png" width="128px">

----

BuzzFeed's **sso** is our single sign-on experience for our internal web services, lovingly known as the *S.S. Octopus* (octoboi) by our team. In addition to the source code, we publish an official [Docker image][docker_hub].

It is used to provide single-sign-on authentication and authorization for internal web applications behind it by ensuring that only people in a specific email domain (and optionally users in specific Google Groups) can access them. It consists of two processes - `sso-auth` and `sso-proxy`.

The main idea of **sso** is a "double OAuth2" flow, where `sso-auth` is the OAuth2 provider for `sso-proxy`, and Google (or another third-party provider), is the OAuth2 provider for `sso-auth`.

In a nutshell:

- If a user visits an `sso-proxy`-protected service (`foo.sso.example.com`) and does not have a session cookie, they are redirected to `sso-auth` (`sso-auth.example.com`).
   - If the user **does not** have a session cookie for `sso-auth`,
     they are prompted to log in via the usual Google OAuth2 flow, and then
     redirected back to `sso-proxy` where they will now be logged in (to
     `foo.sso.example.com`)
   - If the user *does* have a session cookie for `sso-auth` (e.g. they
     have already logged into `bar.sso.example.com`), they are
     transparently redirected back to `proxy` where they will be logged in,
     without needing to go through the Google OAuth2 flow
- `sso-proxy` transparently re-validates & refreshes the user's session with `sso-auth`

## Code of Conduct

Help us keep **sso** open and inclusive. Please read and follow our [Code of Conduct](CODE_OF_CONDUCT.md).

## Contributing

Contributions to **sso** are welcome! Please follow our [contribution guideline](CONTRIBUTING.md).

### Issues

Please file any issues you find in our [issue tracker](https://github.com/buzzfeed/sso/issues).

### Security Vulns

If you come across any security vulnerabilities with the **sso** repo or software, please email<EMAIL_ADDRESS>In your email, please request access to our [bug bounty program](https://hackerone.com/buzzfeed) so we can compensate you for any valid issues reported.

## Maintainers

**sso** is actively maintained by the BuzzFeed Infrastructure teams.

[docker_hub]: https://hub.docker.com/r/buzzfeed/sso/

repository: shrayolacrayon/sso

repo_name: shrayolacrayon/sso