We provide a wide range of track hub settings (https://genome.ucsc.edu/goldenPath/help/trackDb/trackDbHub.html). In this blog post, we will emphasize 10 track hub settings that users may find useful but are often omitted from hubs.

10 track hub settings

1. html
2. useOneFile
3. priority
4. searchIndex
5. filter
6. spectrum
7. mouseOver
8. detailsDynamicTable
9. labelFields
10. maxWindowCoverage

1. html setting

The html trackDb setting is an important setting that allows the display of a track description page in HTML format. Having a track description page provides more background, display details, and analysis that would help understand the data. The html setting is a requirement for a track hub to be considered listed in the UCSC Public Hubs (http://genome.ucsc.edu/cgi-bin/hgHubConnect). To add the setting, you add ‘html’ to the text block, or “stanza”, followed by either the relative path of the html file or the full path:

Relative path:
html path/docs/myTrack.html

Full path:
html https://server/path/docs/myTrack.html

You can also add the setting without the “.html” suffix:
html path/docs/myTrack
html https://server/path/docs/myTrack

In addition, the description html page should have the following sections: Track description, Display Conventions and Configuration, Methods, Credits, and References. More information on sections can be found on the template page: http://genome.ucsc.edu/goldenpath/help/examples/hubExamples/templatePage.html. Having a track description html page will save users time and minimize questions.

The following example shows a track using the html trackDb setting:

2. useOneFile setting

Conventionally, a track hub would consist of a minimum of three text files: trackDb.txt, genomes.txt, and hub.txt. The useOneFile trackDb setting allows the contents of all three files to be in one file, the hub.txt file. Using this setting limits the hub to only one assembly. The following stanza is a template for using the “useOneFile on” trackDb setting:

3. priority setting

The priority trackDb setting allows the ordering of tracks within a track group and the order within the browser graphic image. Typically the setting is used for tracks that are displayed by default. Default tracks are usually the most popular or helpful tracks available on a specific genome browser. The priority trackDb setting allows the selection of tracks to be displayed ahead of other tracks in ascending priority order. The setting can be useful for nesting tracks in a specific order, such as in a composite track. The default tracks are then followed by the unprioritized tracks which are sorted alphabetically by the short label. Adding priority followed by a floating point number to the stanza enables the setting:

priority 1

You can also add decimal values. For example, a track with priority 1.1 will display after a track with priority 1. The following example shows a track using the priority trackDb setting in a composite track:

4. searchIndex setting

The searchIndex trackDb setting allows field names to be searchable in the position search box of the browser. To enable the setting, you would first have to create a bigBed file using bedToBigBed with the -extraIndex setting. For example, using the following bigBed fields:

If you run the setting as -extraIndex=name, then you will be able to search on the “name” field by adding the “searchIndex name” setting to the stanza:

searchIndex name

You can also add multiple fields. If the name is found using the search box then the position of the term will be displayed. If there are multiple matches then a list of positions will be displayed. The following example shows a track using the searchIndex setting:

For more information on creating a bigBed file with extra (custom) fields, see the following help page: https://genome.ucsc.edu/goldenPath/help/bigBed.html#Ex3. While searchIndex expects a search string with an exact match, another setting for Track Hubs, searchTrix (https://genome.ucsc.edu/goldenPath/help/trackDb/trackDbHub.html#searchTrix) allows for a fast look-up of free text associated with a list of identifiers, such as in the name field.

5. filter setting

The filter trackDb setting allows you to enable filtering for numerical or text data within a field of a bigBed file. First, you would need to enable the configurable features of the bigBed, which is done by adding a period ” .” or plus ” +” to the type bigBed line in the stanza:

type bigBed 5 .
type bigBed 9 +

Then, to enable filtering of numerical data, you would need to add a filter.fieldName setting. Typically the score field is used as the fieldName in filter.fieldName setting. To enable filtering for the score field with a default value of 0, you would add “filter.score 0” to the stanza:

filter.score 0

The setting will then make the filter option on the track hub description page available:

If you want to add a minimum limit value to filter data then you can add the value to the filter.fieldName setting. For example, if the score field consists of data values from a range 1-10, and if you want to filter values from 4-10, you would add:

filter.score 4

In addition, you can also change the default filter message by the filterLabel.fieldName setting. You would add:

filterLabel.score Score (4-10)

The settings will display the following filter option on the track hub description page:

To enable text filtering, you would need to add a filterText.fieldName setting. Typically the name field is used as the fieldName in the filterText.fieldName setting. This will allow you to search and display exactly the searched term, or only part of the search term. To enable text searching for the name field with the default value, you would add “filterText.name *” to the stanza:

filterText.name *

The setting will then make the filter option on the track hub description page available:

The following example shows a track using the filterText trackDb setting with geneName as the fieldName and no default value:

For more information on filter settings and examples, see the following quick start guide: http://genome.ucsc.edu/goldenPath/help/hubQuickStartFilter.html

6. spectrum setting

The spectrum trackDb setting enables the score field to be used as a shading factor in the browser graphic. The lower score values are shaded in light gray by default, while higher scores are shaded towards black. The shading ranges from score values 0-1000. To enable the spectrum setting, you would add “spectrum on” to the stanza:

spectrum on

The upper and lower limits for the spectrum setting can be adjusted so the shading can be a range of specific values. The scoreMax setting defines the upper limit, and the scoreMin defines the lower limit. For example, the shading of a set of score values from 1-10 can be adjusted with an upper limit of 10 using the scoreMax setting.

spectrum on
scoreMax 10

7. mouseOver setting

The mouseOver trackDb setting allows bigBed files with 9 fields or more to have a mouse over text display.

To enable the mouseOver setting, you would need to add the “mouseOver” setting, then the “$” character followed by the fieldname:

mouseOver $fieldname

You can also add any combination of additional fields and plain text to display:
mouseOver Displaying $name which $gene is the gene at $chrom for mouseOver setting

The following example shows a track using the mouseOver trackDb setting:

8. detailsDynamicTable setting

The detailsDynamicTable setting allows for the display of a table in html format on an items’ description page. To enable the setting, you would first have to create a bigBed file with a field that will consist of specific characters, “|” and “;” used to make a table. For example,

row_name|data_value;row_name1|data_value1;row_name2|data_value2

The “|” splits the cell and “;” makes a new row:

For example, using a bed4+1, saving the following as example.bed:

chr1 100 200 itemOne row_name|data_value;row_name1|data_value1;row_name2|data_value2
chr1 300 400 itemTwo different_row|data_value;different_row_1|data_value1;different_row_2|data_value2

Making an AutoSql format (.as) file describing the fields and saving it as example.as:

table detailsDynamicTable
"detailsDynamicTable example 2 items" 
(
string  chrom;          "Reference sequence chromosome or scaffold" 
uint    chromStart;     "Start position of feature on chromosome" 
uint    chromEnd;       "End position of feature on chromosome" 
string  name;           "item" 
string  table;          "detailsDynamicTable table" 
)

Then converting the example.bed to a bigBed using bedToBigBed:
bedToBigBed -as=example.as -type=bed4+1 example.bed hg38.chrom.sizes example.bb

You can then use the setting by adding the “detailsDynamicTable” then the fieldName:

detailsDynamicTable table

The items description page with the table:

You can add a title by adding a ‘|’ and the table title after the field name:

detailsDynamicTable table|detailsDynamicTable example

The items description page with the table and a table title:

You can also use JSON format with detailsDynamicTable. More information on the detailsDynamicTable setting can be found on the Track Database Definition page: https://genome.ucsc.edu/goldenPath/help/trackDb/trackDbHub.html#detailsDynamicTable.

9. labelFields setting

The labelField trackDb setting allows the display of a specific bigBed field as the label of the item on the browser graphic. To enable the labelFields setting, you would need to add the “labelFields” setting, then a bigBed fieldName:

labelFields fieldName

For example, using the “chrom” field as a label:

labelFields chrom

The track displays the chromosome as the label:

You can also add additional field names:

labelFields chrom,gene,name,variantType

This will enable the additional field names as label options on the track hub description page:

You can also add the special value “none” if no labels are desired to be displayed on the browser graphic.

labelFields none

The following example shows a track using the labelFields trackDb setting:

10. maxWindowCoverage setting

The maxWindowCoverage setting allows for a track to switch into a density coverage graph when the graphic display window contains more than the specified number of bases. The maxWindowCoverage setting can be helpful when a track has too many individual bed items in a browser graphic display. To enable the maxWindowCoverage setting, you would need to add the maxWindowCoverage setting, then a specific integer.

maxWindowCoverage integer

For example, the following graphic display has 45 bed items over a span of 901 bases:

Then adding the maxWindowCoverage setting with the integer 900:

maxWindowCoverage 900

Switches the bed items display to a density coverage graph when the browser graphic has a span of over 900 bases. The following are the 45 bed items over a span of 901 bases:

The following example shows a track using the maxWindowCoverage trackDb setting:

For more information on track hub settings, please see the following page: Hub Track Database Definition

If you have questions about using track hub settings, please feel free to contact us!

If after reading this blog post you have any public questions, please email [email protected]. All messages sent to that address are archived on a publicly accessible forum. If your question includes sensitive data, you may send it instead to [email protected].

In this blog post, I’ll share the experience a user could be having where they have an existing text-based custom track that could be made into a more shareable bigBed version.

Let’s say the original track is in the bedDetail format that allows for BED12+ columns using tabs to define additional columns. This original track can  be made into a bigBed track to be put in a Track Hub or to be hosted alone and shared across multiple sessions, where the bigBed could act as a universal custom track.  If it were updated at the bigBed hosted location, all the related sessions that referenced the new bigBed remotely-hosted location of the data would have their representations of the data updated as well.

Let’s begin with the idea that Jerry’s Lab would like to host a primers track and share it between sessions for their lab group. The lab has already created a primers custom track in text files that can be updated and uploaded successfully.

The below steps will take Jerry’s lab from this uploading approach, to putting the data in a  shared online location and using a binary-indexed format of the custom track called bigBed. The bigBed is hosted at an online location defined by a bigDataUrl which allows Jerry’s entire lab to see the updated data as new primers are added.  This way each lab member in Jerry’s lab can use their early sessions, but get new data in their views, provided the bigBed is updated with the new information at the URL shared between all the sessions.

For this example, imagine Jerry’s lab is already using a tab-separated bedDetail custom track text file that might look like this:

track name=Primers type=bedDetail description=Primers visibility=2 color=221,55,118
browser position chr5:1405000-1448000
chr5    1413367    1413387    hDAT32061R    0    .    1413367    1413387    221,55,118    1    20    0    catggagtgggccctttcag
chr5    1414322    1414343    hDAT31086F    0    .    1414322    1414343    221,55,118    1    21    0    cctcaagcccaaatgcagctg
...

This track with type=bedDetail can upload  a text file to display BED12 items (http://genome.ucsc.edu/FAQ/FAQformat.html#format1) with an additional 13th column with sequence (making it a bedDetail format: http://genome.ucsc.edu/FAQ/FAQformat.html#format1.7). With bedDetail a user has either the first 4 or 12 columns of data in BED format, and can extend the format with additional fields, such as sequence data here, to enhance the track details pages.

By going to the My Data and Custom Tracks page, the above text can be pasted and will work (provided there are tabs between the columns, some cut and paste interfaces will remove tabs).

When this custom track is added to a session as a text file, it is uploaded one time and does not update further unless there is a new upload. If Jerry’s lab wanted to update the Primers tracks in their sessions, a future upload of the text-based track would be required in each individual session. Once created, the original sessions that have uploaded text data are static. To solve this issue for Jerry’s lab, an option is to make a URL-hosted location of the data and  turn the data into a binary-indexed bigBed format.  In this way the new URL-hosted bigBed could act as a universal custom track across many sessions.

Here are the steps to do that.

1. The first would be to edit the file and remove the top track and browser lines, they will be used again at a later step after the bigBed is created.

chr5    1413367    1413387    hDAT32061R    0    .    1413367    1413387    221,55,118    1    20    0    catggagtgggccctttcag
chr5    1414322    1414343    hDAT31086F    0    .    1414322    1414343    221,55,118    1    21    0    cctcaagcccaaatgcagctg
...

This link is an example of that file for those that want to follow along with the next steps.

curl -O https://data.cyverse.org/dav-anon/iplant/home/brianlee/Lab_Primers.txt

2. Next, in a command-line environment, you can use the UNIX sort command to sort the data in your file and call the file Lab_Primers.txt

sort -k1,1 -k2,2n Lab_Primers.txt > Lab_Primers_sorted.txt

The command creates a new file Lab_Primers_sorted.txt where all the entries are ordered correctly.

3. Next we will acquire the bedToBigBed utility assuming you are using a MacBook

curl -O http://hgdownload.soe.ucsc.edu/admin/exe/macOSX.x86_64/bedToBigBed.

4. Then we will make the bedToBigBed utility executable:

chmod 700 bedToBigBed

5. With this utility we will need a definitions file to explain what each column means. We will get an example that will work with these 13 columns, but we could edit this file or make our own.

curl -O https://genome-source.gi.ucsc.edu/gitlist/kent.git/raw/master/src/hg/lib/bed12Source.as

6. With the bedToBigBed utility and the bed12Source.as file, we can now use the tool to build from the Lab_Primers_sorted.txt file a new Lab_Primers.bigBed file for the hg19 genome, using a URL to find the chromosome sizes for the hg19 assembly.

./bedToBigBed -type=bed12+ -as=bed12Source.as -tab Lab_Primers_sorted.txt http://hgdownload.cse.ucsc.edu/goldenPath/hg19/bigZips/hg19.chrom.sizes Lab_Primers.bigBed

With the following three optional steps, we can get another tool called bigBedToBed to check the extraction of data from the file:

curl -O http://hgdownload.soe.ucsc.edu/admin/exe/macOSX.x86_64/bigBedToBed
chmod 700 bigBedToBed
./bigBedToBed -chrom=chr5 -start=1419444 -end=1445682 Lab_Primers.bigBed stdout

7. Now we need to host this data somewhere online so that it can be found by the Browser. One option is CyVerse, you can read more about them at this location: http://genome.ucsc.edu/goldenPath/help/hgTrackHubHelp.html#Hosting

8. Once you have an online location to the bigBed (for example: https://data.cyverse.org/dav-anon/iplant/home/brianlee/Lab_Primers.bigBed) you can add it to your sessions. Go to the custom track page and put in a track like the following, where you can use your track and browser lines again, but change type=bedDetail to type=bigBed and use a bigDataUrl:

browser position chr5:1405000-1448000
track name=Primers type=bigBed description=Primers visibility=2 color=221,55,118 bigDataUrl=https://data.cyverse.org/dav-anon/iplant/home/brianlee/Lab_Primers.bigBed

9. Save a session with this bigBed as a custom track. Example: https://www.genome.ucsc.edu/s/brianlee/Primers

10. Now anytime  the file has updates, the session that references this bigDataUrl location of the bigBed data should also update. If  CyVerse is used to host the bigBed data file online, this may require deleting and replacing your file to force a browser to reload (Control-Shift-R) the file to trigger caching to expire. Contact CyVerse directly for help.

Finding your own institution to host  your data is often the best solution as you can then work with your system administrators to have the best experience.

Once you have the bigBed, it is not much more work to take it to the next step and put it inside a Track Hub. Once in a Track Hub, many additional features are possible, such as using a searchIndex feature that allows finding unique named items within your custom track on the search bar or ultimately creating a Public Hub to share your data with the wider community.

---

This entry written by Brian Lee. If after reading this blog post you have any public questions, please email [email protected]. All messages sent to that address are archived on a publicly accessible forum. If your question includes sensitive data, you may send it instead to [email protected].

From biologists to computer scientists, the human genome has presented a grand puzzle. With regards to UCSC, the story began in 1985 when our chancellor, molecular biologist Robert Sinsheimer, proposed a bold endeavor – sequence the complete human genome. 5 years later the International Genome Project was launched. The next chapter took place in 1999 when computer science professor David Haussler was asked to join the project.  Haussler, in turn, enlisted then graduate student Jim Kent to help with assembling the genome. This collaboration culminated on July 7, 2000, when the first human genome assembly was made available on the UCSC servers. Over 500 GB were downloaded worldwide in 24 hours.  (Hey, back in 2000, that was a lot!)

Three months later, the UCSC Genome Browser came online as a resource to distribute and visualize the genome.  The first ten releases, hg1-hg10 were assembled at UCSC, after which the task was taken over by NCBI. As NCBI incremented the official releases and changed the naming scheme, UCSC released browsers at a slower rate, continuing to increment the hg* nomenclature.  By the time NCBI released NCBI33 in 2003, UCSC released it as hg15. After releasing so many browsers in under three years, the pace slowed, with each assembly taking around one year longer than the previous.

Patches: What are they and why are they important?

The early genome assemblies were largely aiming to increase the fidelity of the reference. However, with each release, research progress was temporarily hampered as scientists adjusted to sequence changes and shifted coordinates. This has often led to scientists continuing to use an older release as it may be better annotated and established. This is evident in the Genome Browser as a majority of our users continue to work on GRCh37/hg19 in spite of GRCh38/hg38’s release more than 4 years ago.

Looking at the numbers, however, we can see that GRCh38 is the most accurate human genome to date. With these benchmarks in accuracy, the GRC has shifted focus beyond fidelity to inclusion. The GRC  now strives to capture more of the genetic diversity present in the human population. The initial release of GRCh38/hg38 included 261 alternate haplotype sequences, nearly a 30-fold increase over GRCh37/hg19.

UCSC builds a new assembly database for each full release of a genome assembly, but the GRC also releases “patch” updates for genome assemblies. Through patch releases, the GRC adds new alternate haplotype sequences, and also corrected sequences, without changing the sequences or coordinate system of the initial assembly release.

To quote directly from the GRC:

Patches are accessioned scaffold sequences that represent assembly updates. They add information to the assembly without disrupting the chromosome coordinates. Patches are given chromosome context via alignment to the current assembly. Together, the scaffold sequence and alignment define the patch.

These patch sequences are more important now than ever before as the GRC has decided to indefinitely postpone the release of the next coordinate-changing assembly (which would have been GRCh39/hg39), instead opting for additional patches to GRCh38/hg38. There are two kinds of patch sequences:

Novel patches (alternative haplotypes): Chromosomal regions of the genome that exhibit sufficient variability to prevent adequate representation by a single sequence. Also referred to as alternate loci. UCSC labels these haplotype sequences by appending “_alt” to their names.

Fix patches: Error corrections (addressed by approaches such as base changes, component replacements/updates, switch-point updates or tiling-path changes) or assembly improvements, such as the extension of sequence into gaps. UCSC labels these fix sequences by appending “_fix” to their names.

These patch sequences, especially novel patches, have been increasing in number and will continue to do so.

A better approach to patches

Our approach thus far in the Genome Browser has been to make data tracks indicating the locations of these patch releases along the initial assembly chromosomes. While these are useful, they provide little in the way of annotations and are largely underutilized by users. With the increase of these patches and postponement of GRCh39, however, we have decided to switch our approach and add the new sequences, and annotations on the new sequences, to the UCSC hg38 database. This will allow patches to be visualized on the Browser as standalone reference sequences, not unlike a regular chromosome or the alternate haplotype sequences that were included in the initial assembly release. BLAT results may also include alignments to these sequences.

The addition of new genomic sequences to an existing UCSC database is a departure from our longstanding practice of building a new database every time we import a new genome assembly release.  To minimize disruption to pipelines that use our download files, especially those in the bigZips directory, we will leave the original bigZips/hg38.* files unchanged, and add a subdirectory when we incorporate sequences from a patch release; for example, bigZips/p12/ for patch release GRCh38.p12.  We will also add bigZips/latest/ which will link to the most recent patch release subdirectory, so that pipelines may stay up to date with UCSC’s patch sequence annotations if desired. In other words, the bigZips downloads will be “opt-in” for patch sequences.

Changes and improvements to hg38

Currently, we are in the process of adding these sequences to the GRCh38/hg38 genome database with the potential to do the same for GRCh37/hg19 and GRCm38/mm10 at a future date. Changes that users may see are as follows:

• BLAT/In-Silico PCR – Additional hits on _alt and _fix sequences
• Position searches in the hg38 browser may lead to _alt and _fix sequences in addition to or instead of initial assembly chromosomes
• Replacing the ‘GRC Patch Release’ and ‘Alt Map’ tracks with ‘Fix Patches’ and ‘Alt Haplotypes’ tracks which include alignments to alts/fixes with details pages and links to jump between main chromosomes and alts/fixes
• New subdirectories of bigZips download directory (initial, p12, latest)
• New sequences/annotations in /gbdb/hg38 download files (same file names, extended contents)
• SQL queries to genome-mysql.soe.ucsc.edu may include new results on _alt and _fix sequences

It is also worth noting what will not change. Existing sequences, and annotations on existing sequences, will not change. Download files in the bigZips directory, such as bigZips/hg38.2bit and bigZips/hg38.fa.masked.gz, will not change.

So what kind of annotations can be found on these hg38 patch sequences?

• Annotations generated by UCSC such as RepeatMasker, CpG Islands, AUGUSTUS, Human mRNAs and Pfam
• NCBI’s sequence alignments of patch sequences to chromosomes: Fix Patches, Alt Haplotypes
• External annotation sources such as RefSeq and GENCODE that include annotations on patch sequences (up to this point we have ignored those patch annotations)
• Select tracks have been lifted from main chromosomes onto the patches using NCBI’s alignments, most notably GTEx Gene and ENCODE Regulation

For additional information on these patch sequences, and a full list of sequences in hg38, you may visit the hg38 Genome Browser Gateway page.

We are always receptive to our users and their needs. If there are any specific track annotations you would like to see on these patches or if you have any questions regarding this implementation and how it may affect you, please write into our public mailing list ([email protected]) or our private mailing list if your message includes sensitive data ([email protected]).

The previous parts of this series (part 1 and part 2) focused on how to use the Genome Browser to obtain data, and for this third and final post we’re gonna divert from that theme and talk about how to control the track image itself. Note: We now have an API which can also perform many of these functions.

Standard procedure for obtaining images of the browser is to configure the view exactly as you want, and then use the “View->PDF/PS” option in the menu bar in order to download a PDF or PostScript of your image. In addition to this method, you can generate PNG images on the fly with the following hgRenderTracks template:
http://genome.ucsc.edu/cgi-bin/hgRenderTracks?parameters

Parameters should be replaced by the URL key-value pairs that the main track display, hgTracks, understands, like ‘db=hg19’ or ‘knownGene=pack’. For example, to compare the transcripts provided by NCBI to UCSC’s own alignments of the transcripts at the ABO locus, you can use the following URL and the cURL program to download a PNG file:

curl 'http://genome.ucsc.edu/cgi-bin/hgRenderTracks?db=hg19&position=chr9:136130563-136150630&hideTracks=1&refSeqComposite=pack&ncbiRefSeqCurated_sel=1&ucscRefSeqView=pack&refGene_sel=1&pubs=pack' > example.png

Opening example.png in your favorite image viewer will display the following image:

There are many additional parameters described on the Sharing your custom track section of the custom tracks help page. Using these parameters you can configure hgRenderTracks to display any combinations of tracks, and along the hgt.customText parameter, also show your custom tracks with them.

To illustrate, if I have the following custom track:

browser hide all
browser gold=pack
browser gap=pack
browser visibility=pack
chr1 1000 2000
chr1 2100 3000
chr1 3100 4000
…

Hosted on the web at http://genome-test.soe.ucsc.edu/~chmalee/exCustomTrack.bed, then I can tell hgRenderTracks to load this file with the hgt.customText parameter like so:

http://genome.ucsc.edu/cgi-bin/hgRenderTracks?db=hg38&position=chr1:1-100000&hgt.customText=http://genome-test.soe.ucsc.edu/~chmalee/exCustomTrack.bed

The “browser” lines at the beginning of the custom track indicate which native tracks to turn on along their visibilities, while the “hide all” line turns all the other native tracks off. In addition to these basic instructions there are many more examples on the UCSC Genome Browser Wiki.

What about when you want to view a genome and annotations not hosted on our site? If you have a FASTA file of your genome available, you can use faToTwoBit to convert your genome into a 2bit file, then make an assembly hub out of your data. Once you’ve created your hub, you can view the hub with the hubUrl setting. As an example, I have hosted an assembly hub for Arabadopsis thaliana here, and I can view the hub via a single URL like so:

https://genome.ucsc.edu/cgi-bin/hgTracks?genome=araTha1&hubUrl=https://genome-test.gi.ucsc.edu/~chmalee/araTha1/plantAraTha1/hub.txt.

If your data needs to stay behind your local firewall, then you can use the GBiB and GBiC products so you can set up your own “copy” of the UCSC Genome Browser that meets your privacy needs.

Further Reading:

• UCSC Genome Browser Downloads server
• GenomeWiki
• Track Image Parameters
• Custom Tracks
• Track Hubs
• Viewing private data on the Genome Browser

---

If after reading this blog post you have any public questions, please email [email protected]. All messages sent to that address are archived on a publicly accessible forum. If your question includes sensitive data, you may send it instead to [email protected].