text:
This specification defines the DNT request header field as an
HTTP mechanism for expressing the user's preference regarding tracking,
an HTML DOM property to make that expression readable by scripts, and
APIs that allow scripts to register site-specific exceptions granted by
the user. It also defines mechanisms for sites to communicate whether
and how they honor a received preference through use of the
response header field and well-known resources that provide a
machine-readable tracking status.
Readers may review changes from the previous Working Draft; in particular, recent changes have updated definitions, requirements on determining a user preference and introduced a media type. An issue tracking system is available for recording issues regarding this document and their resolutions.
This document is published as a Last Call Working Draft, which invites broad community review of technical requirements and dependencies. The Tracking Protection Working Group encourages people to comment on the extent to which technical requirements of the group's charterhave been met and how significant dependencies with groups inside and outside W3C have been satisfied. The Working Group will evaluate all comments received and determine whether or how the specification needs to be modified in light of the comments. Comments will be evaluated on whether they identify technical problems with the TPE, whether the TPE fulfills its requirements, and whether the TPE creates or does not otherwise resolve dependencies with other technical standards, practices or processes. The Chairs of the Working Group will issue written responses to all comments received.
Of note, this document does not define site behavior for complying with a user's expressed tracking preference, but does provide sites with a mechanism for indicating compliance. The Tracking Compliance and Scope [[TCS]] specification which standardizes how sites should respond to Do Not Track requests, including what information may be collected for limited permitted uses despite a Do Not Track signal, is under discussion. The Tracking Protection Working Group expects that specification to proceed to Last Call in the summer of 2014. Both specifications are currently scheduled to go to Candidate Recommendation in December 2014.
The World Wide Web consists of billions of resources interconnected through the use of hypertext. Hypertext provides a simple, page-oriented view of the information provided by those resources, which can be traversed by selecting links, manipulating controls, and supplying data via forms and search dialogs.
A Web page is often composed of many information sources beyond the initial resource request, including embedded references to stylesheets, inline images, javascript, and other elements that might be automatically requested as part of the rendering or behavioral processing defined for that page. The user's experience is seamless, even if the page has been composed from the results of many network interactions with multiple servers. From the user's perspective, they are simply visiting and interacting with a single Web site: all of the technical details and protocol mechanisms used to compose a page to represent that site are hidden behind the scenes.
It has become common for Web site owners to collect data regarding the usage of their sites for a variety of purposes, including what led the user to visit their site (referrals), how effective the user experience is within the site (web analytics), and the nature of who is using their site (audience segmentation). In some cases, the data collected is used to dynamically adapt the content (personalization) or the advertising presented to the user (targeted advertising). Data collection often occurs through the insertion of embedded elements on each page, which connect the user's activity across multiple pages. A survey of these techniques and their privacy implications can be found in [[KnowPrivacy]].
Users need a mechanism to express their own preferences regarding tracking that is both simple to configure and efficient when implemented. However, merely expressing a preference does not imply that all recipients will be able to comply. In some cases, a server might be dependent on some forms of tracking and is unwilling or unable to turn that off. In other cases, a server might perform only limited forms of tracking that would be acceptable to most users. Servers need mechanisms for communicating their tracking behavior and for storing user-granted exceptions after the user has made an informed choice.
This specification defines Hypertext Transfer Protocol [[!HTTP]] elements for communicating the user's tracking preference (if any) and communicating the server's tracking behavior (if any). The DNT request header field is defined for communicating the user's tracking preference for the request target. A well-known URI for a tracking status resource and the Tk response header field are defined for communicating the server's tracking behavior. In addition, JavaScript APIs are defined for enabling scripts to determine DNT status and register a user-granted exception.
This specification does not define requirements on what a recipient needs to do to comply with a user's expressed tracking preference, except for the means by which such compliance is communicated. Instead, the tracking status provides the ability to identify a set of compliance regimes to which the server claims to comply, with the assumption being that each regime defines its own requirements on compliant behavior. For example, [[TCS]] is a work-in-progress that intends to define such a compliance regime.
Tracking is the collection of data regarding a particular user's activity across multiple distinct contexts and the retention, use, or sharing of data derived from that activity outside the context in which it occurred. A context is a set of resources that are controlled by the same party or jointly controlled by a set of parties.
A user is a natural person who is making, or has made, use of the Web.
A user agent is any of the various client programs capable of initiating HTTP requests [[!HTTP]], including (but not limited to) browsers, spiders (web-based robots), command-line tools, custom applications, and mobile apps.
A network interaction is a single HTTP request and its corresponding response(s): zero or more interim (1xx) responses and a single final (2xx-5xx) response.
A user action is a deliberate action by the user, via configuration, invocation, or selection, to initiate a network interaction. Selection of a link, submission of a form, and reloading a page are examples of user actions. User activity is any set of such user actions.
A party is a natural person, a legal entity, or a set of legal entities that share common owner(s), common controller(s), and a group identity that is easily discoverable by a user. Common branding or providing a list of affiliates that is available via a link from a resource where a party describes DNT practices are examples of ways to provide this discoverability.
With respect to a given user action, a first party is a party with which the user intends to interact, via one or more network interactions, as a result of making that action. Merely hovering over, muting, pausing, or closing a given piece of content does not constitute a user's intent to interact with another party.
In some cases, a resource on the Web will be jointly controlled by two or more distinct parties. Each of those parties is considered a first party if a user would reasonably expect to communicate with all of them when accessing that resource. For example, prominent co-branding on the resource might lead a user to expect that multiple parties are responsible for the content or functionality.
For any data collected as a result of one or more network interactions resulting from a user's action, a third party is any party other than that user, a first party for that user action, or a service provider acting on behalf of either that user or that first party.
A party collects data received in a network interaction if that data remains within the party's control after the network interaction is complete.
A party uses data if the party processes the data for any purpose other than storage or merely forwarding it to another party.
A party shares data if it transfers or provides a copy of that data to any other party.
A user-granted exception is a specific tracking preference, overriding a user's general tracking preference, that has been obtained and recorded using the mechanisms defined in .
The key words must, must not, required, should, should not, recommended, may, and optional in this specification are to be interpreted as described in [[!RFC2119]].
This specification uses Augmented Backus-Naur Form [[!ABNF]] to define network protocol syntax and WebIDL [[!WEBIDL]] for defining scripting APIs.
The goal of this protocol is to allow a user to express their personal preference regarding tracking to each server and web application that they communicate with via HTTP, thereby allowing recipients of that preference to adjust tracking behavior accordingly or to reach a separate agreement with the user that satisfies all parties.
Key to that notion of expression is that the signal sent MUST reflect the user's preference, not the choice of some vendor, institution, site, or network-imposed mechanism outside the user's control; this applies equally to both the general preference and exceptions. The basic principle is that a tracking preference expression is only transmitted when it reflects a deliberate choice by the user. In the absence of user choice, there is no tracking preference expressed.
A user agent MUST offer users a minimum of two alternative choices
for a
Do Not Track preference:
unset or
A user agent MAY offer a third alternative choice:
If the user's choice is
DNT:1 or
DNT:0, the
tracking preference is enabled; otherwise, the
tracking preference is not enabled.
A user agent MUST have a default tracking preference of
unset (not enabled) unless a specific tracking preference
is implied by the user's decision to use that agent. For example, use
of a general-purpose browser would not imply a tracking preference
when invoked normally as
SuperFred, but might imply a
preference if invoked as
SuperDoNotTrack or
Implementations of HTTP that are not under control of the user MUST NOT add, delete, or modify a tracking preference. Some controlled network environments, such as public access terminals or managed corporate intranets, might impose restrictions on the use or configuration of installed user agents, such that a user might only have access to user agents with a predetermined preference enabled. However, if a user brings their own Web-enabled device to a library or cafe with wireless Internet access, the expectation will be that their chosen user agent and personal preferences regarding Web site behavior will not be altered by the network environment (aside from blanket limitations on what resources can or cannot be accessed through that network).
An HTTP intermediary MUST NOT add, delete, or modify a tracking
preference expression in a request forwarded through that intermediary
unless the intermediary has been specifically installed or configured
to do so by the user making the request. For example, an Internet
Service Provider MUST NOT inject
DNT:1 on behalf of all
users who have not expressed a preference.
User agents often include user-installable extensions, also known as add-ons or plug-ins, that are capable of modifying configurations and making network requests. From the user's perspective, these extensions are considered part of the user agent and ought to respect the user's configuration of a tracking preference. The user agent as a whole is responsible for ensuring conformance with this protocol, to the extent possible, which means the user agent core and each extension are jointly responsible for conformance. However, there is no single standard for extension interfaces. A user agent that permits such extensions SHOULD provide an appropriate mechanism for extensions to determine the user's tracking preference.
A user agent extension MUST NOT alter the tracking preference expression or its associated configuration unless the act of installing and enabling that extension is an explicit choice by the user for that tracking preference, or the extension itself complies with all of the requirements this protocol places on a user agent.
Likewise, software outside of the user agent might filter network traffic or cause a user agent's configuration to be changed. Software that alters a user agent configuration MUST adhere to the above requirements on a user agent extension. Software that filters network traffic MUST adhere to the above requirements on an HTTP intermediary.
Aside from the above requirements, we do not specify how the tracking preference choices are offered to the user or how the preference is enabled: each implementation is responsible for determining the user experience by which a tracking preference is enabled.
For example, a user might select a check-box in their user agent's
configuration, install an extension that is specifically
designed to add a tracking preference expression,
or make a choice for privacy that then implicitly includes a
tracking preference (e.g.,
Privacy settings: high).
A user agent might ask the user for their preference during startup,
perhaps on first use or after an update adds the tracking protection
feature. Likewise, a user might install or configure a proxy to add
the expression to their own outgoing requests.
When a user has enabled a tracking preference, that preference needs to be expressed to all mechanisms that might perform or initiate tracking.
When enabled, a tracking preference is expressed as either:
|This user prefers not to be tracked on the target site.
|This user prefers to allow tracking on the target site.
A user agent MUST NOT send a tracking preference expression if a tracking preference is not enabled. This means that no expression is sent for each of the following cases:
In the absence of regulatory, legal, or other requirements, servers MAY interpret the lack of an expressed tracking preference as they find most appropriate for the given user, particularly when considered in light of the user's privacy expectations and cultural circumstances. Likewise, servers might make use of other preference information outside the scope of this protocol, such as site-specific user preferences or third-party registration services, to inform or adjust their behavior when no explicit preference is expressed via this protocol.
The DNT header field is a mechanism for expressing the user's tracking preference in an HTTP request [[!HTTP]].
DNT-field-name = "DNT" DNT-field-value = ( "0" / "1" ) *DNT-extension
A user agent MUST NOT generate a DNT header field if the user's tracking preference is not enabled.
A user agent MUST generate a DNT header field with a
field-value that begins with the numeric character "1" (%x31) if the
user's tracking preference is enabled, their preference is
DNT:1, and no exception has been granted for the
request target (see ).
A user agent MUST generate a DNT header field with a
field-value that begins with the numeric character "0" (%x30) if the
user's tracking preference is enabled and their preference is
DNT:0, or if an exception has been granted for the
request target.
A proxy MUST NOT generate a DNT header field unless it has been specifically installed or configured to do so by the user making the request and adheres to the above requirements as if it were a user agent.
GET /something/here HTTP/1.1 Host: example.com DNT: 1
The remainder of the field-value, after the initial character, is reserved for future extensions. DNT extensions can only be transmitted when a tracking preference is enabled.
DNT-extension = %x21 / %x23-2B / %x2D-5B / %x5D-7E ; excludes CTL, SP, DQUOTE, comma, backslash
For example, additional characters might indicate modifiers to the
main preference expressed by the first digit, such that the main
preference will be understood if the recipient does not understand
the extension. Hence, a field-value of "1xyz" can be thought of
do not track, but if you understand the refinements defined by
x, y, or z, then adjust my preferences according to those
User agents that do not implement DNT extensions MUST NOT send DNT-extension characters in the DNT field-value. Servers that do not implement DNT extensions SHOULD ignore anything beyond the first character.
The extension syntax is restricted to visible ASCII characters that can be parsed as a single word in HTTP and safely embedded in a JSON string without further encoding (). At most one DNT header field can be present in a valid request [[!HTTP]].
doNotTrack property enables a client-side script
with read access to the Window object to determine what DNT
header field value would be sent in requests to the
document-origin, taking into account the user's general preference
(if any) and any user-granted exceptions applicable to that
origin server.
window, in the browser context of the current
top-level origin.
The value is
null if no DNT header field would be
sent (e.g., because a tracking preference is not enabled).
A user's tracking preference is intended to apply in general, regardless of the protocols being used for Internet communication. However, it is beyond the scope of this specification to define how a user's tracking preference might be communicated via protocols other than HTTP.
In addition to expressing the user's preference regarding tracking, this protocol enables servers to communicate machine-readable claims regarding their own tracking behavior. Since a personalized tracking status on every response would disable caching, a combination of response mechanisms are defined to allow the tracking status to be communicated prior to making a trackable request and without making every response dynamic.
A tracking status value (TSV) is a single character response to the user's tracking preference with regard to data collected via the designated resource. For a site-wide tracking status resource, the designated resource is any resource on the same origin server. For a Tk response header field, the target resource of the corresponding request is the designated resource, and remains so for any subsequent request-specific tracking status resource referred to by the Tk field value.
The tracking status value is case sensitive, as defined formally by the following ABNF.
TSV = %x21 ; "!" - under construction / %x3F ; "?" - dynamic / %x4E ; "N" — not tracking / %x54 ; "T" — tracking / %x43 ; "C" - tracking with consent / %x50 ; "P" - tracking only if consented / %x44 ; "D" - disregarding DNT / %x55 ; "U" - updated
A tracking status value of ! means that the origin
server is currently testing its communication of tracking status.
! value has been provided to ease testing and
deployment on production systems during the initial periods of
testing compliance and during adjustment periods due to future
protocol changes or shifting regulatory constraints. Note that
this value does not indicate that the user's preference will be
ignored, nor that tracking will occur as a result of accessing
the designated resource.
A tracking status value of ? means the origin server needs more information to determine tracking status, usually because the designated resource dynamically adjusts behavior based on information in a request.
? is present in the site-wide tracking status,
the origin server MUST send a Tk header field in all
responses to requests on the designated resource.
? is present in the Tk header field,
more information will be provided in a request-specific
tracking status resource referred to by the status-id.
An origin server MUST NOT send
? as the
tracking status value in the representation of a
request-specific tracking status resource.
A tracking status value of N means the origin server claims that data collected via the designated resource is not used for tracking and will not be combined with other data in a form that would enable tracking.
A tracking status value of T means the origin server might perform or enable tracking using data collected via the designated resource. Information provided in the tracking status representation might indicate whether such tracking is limited to a set of commonly accepted uses or adheres to one or more compliance regimes.
A tracking status value of C means that the origin
server believes it has received prior consent for tracking this
user, user agent, or device, perhaps via some mechanism not
defined by this specification, and that prior consent overrides
the tracking preference expressed by this protocol.
An origin server that sends the
C tracking status
value for a designated resource MUST provide a reference
for controlling consent within the
property of its corresponding tracking status representation
A tracking status value of P means that the origin
server does not know, in real-time, whether it has received prior
consent for tracking this user, user agent, or device, but
promises not to use or share any
DNT:1 data until
such consent has been determined, and further promises to delete
or de-identify within forty-eight hours any
data received for which such consent has not been received.
Since this status value does not itself indicate whether a
specific request is tracked, an origin server that sends a
P tracking status value MUST provide a
config property in the corresponding tracking
status representation that links to a resource for obtaining
consent status.
P tracking status value is specifically meant to
address audience survey systems for which determining consent at
the time of a request is either impractical, due to legacy systems
not being able to keep up with Web traffic, or potentially "gamed"
by first party sites if they can determine which of their users
have consented. The data cannot be used for the sake of
personalization. If consent can be determined at the time of a
request, the
C tracking status is preferred.
A tracking status value of D means that the origin
server is unable or unwilling to respect a tracking preference
received from the requesting user agent. An origin server that
sends the
D tracking status value MUST detail within
the server's corresponding privacy policy the conditions under
which a tracking preference might be disregarded.
For example, an origin server might disregard the DNT field received from specific user agents (or via specific network intermediaries) that are deemed to be non-conforming, might be collecting additional data from specific source network locations due to prior security incidents, or might be compelled to disregard certain DNT requests to comply with a local law, regulation, or order.
This specification is written with an assumption that the
D tracking status value would only be used in
situations that can be adequately described to users as an
exception to normal behavior. If this turns out not to be the
case, either the server's decision to send the
signal needs re-examination, or this specification, or both.
A tracking status value of U means that the request resulted in a potential change to the tracking status applicable to this user, user agent, or device. A user agent that relies on a cached tracking status SHOULD update the cache entry with the current status by making a new request on the applicable tracking status resource.
An origin server MUST NOT send
U as a tracking status
value anywhere other than a Tk header field that is in
response to a state-changing request.
The Tk response header field is hereby defined as an OPTIONAL means for indicating the tracking status that applied to the corresponding request and as a REQUIRED means for indicating that a state-changing request has resulted in an interactive change to the tracking status.
Tk-field-name = "Tk" Tk-field-value = TSV [ ";" status-id ]
The Tk field-value begins with a tracking status value
optionally followed by a semicolon and a
that refers to a request-specific tracking status resource
For example, a Tk header field for a resource that claims not to be tracking would look like:
Tk: N
If an origin server has multiple, request-specific tracking policies, such that the tracking status might differ depending on some aspect of the request (e.g., method, target URI, header fields, data, etc.), the origin server MAY provide an additional subtree of well-known resources corresponding to each of those distinct tracking statuses. The OPTIONAL status-id portion of the Tk field-value indicates which specific tracking status resource applies to the current request.
status-id = 1*id-char id-char = ALPHA / DIGIT / "_" / "-" / "+" / "=" / "/"
For example, a response containing
Tk: T;fRx42
indicates that data collected via the target resource might be used for tracking and that an applicable tracking status representation can be obtained by performing a retrieval request on
If a Tk field-value has a tracking status value of
? (dynamic), then the origin server MUST also
send a
status-id in the field-value.
The status-id is case-sensitive.
Interactive mechanisms might be used, beyond
the scope of this specification, that have the effect of asking
for and obtaining prior consent for tracking, or for modifying
prior indications of consent. For example, the tracking status
resource's status-object defines a
property that can refer to such a mechanism. Although such
out-of-band mechanisms are not defined by this specification,
their presence might influence the tracking status object's
response value.
When an origin server provides a mechanism via HTTP for
establishing or modifying out-of-band tracking preferences,
the origin server MUST indicate within the mechanism's response
when a state-changing request has resulted in a change to the
tracking status for that server. This indication of an
interactive status change is accomplished by sending a
Tk header field in the response with a tracking status
value of
U (updated).
Tk: U
A site-wide tracking status resource provides information about the potential tracking behavior of resources located at that origin server. A site-wide tracking status resource has the well-known identifier
relative to the origin server's URI [[RFC5785]].
An origin server that receives a valid
GET request
targeting its site-wide tracking status resource MUST send either
a successful response containing a machine-readable representation
of the site-wide tracking status, as defined below, or a sequence
of redirects that leads to such a representation. Failure to
provide access to such a representation implies that the target
origin server does not implement this protocol.
The representation can be cached, as described
in .
See for examples of how tracking status resources can be used to discover support for this protocol.
If an origin server has multiple, request-specific tracking policies, such that the tracking status might differ depending on some aspect of the request (e.g., method, target URI, header fields, data, etc.), the origin server MAY provide an additional subtree of well-known resources corresponding to each of those distinct tracking statuses. The Tk response header field () can include a status-id to indicate which specific tracking status resource applies to the current request.
A tracking status resource space is defined by the following URI Template [[URI-TEMPLATE]]:
where the value of
status-id is a string of URI-safe
characters provided by a Tk field-value in response to a
prior request. For example, a prior response containing
Tk: ?;ahoy
refers to the specific tracking status resource
Resources within the request-specific tracking status resource space are represented using the same format as a site-wide tracking status resource.
When sending a request for the tracking status, a user agent SHOULD include any cookie data [[COOKIES]] (set prior to the request) that would be sent in a normal request to that origin server, since that data might be needed by the server to determine the current tracking status. For example, the cookie data might indicate a prior out-of-band decision by the user to opt-out or consent to tracking by that origin server.
An origin server MUST NOT retain tracking data regarding requests on the site-wide tracking status resource or within the tracking status resource space, regardless of the presence, absence, or value of a DNT header field, cookies, or any other information in the request. In addition, an origin server MUST NOT send Set-Cookie or Set-Cookie2 header fields in responses to those requests, including the responses to redirected tracking status requests, and MUST NOT send a response having content that initiates tracking beyond what was already present in the request. A user agent SHOULD ignore, or treat as an error, any Set-Cookie or Set-Cookie2 header field received in such a response.
If the tracking status is applicable to all users, regardless of the received DNT-field-value or other data received via the request, then the origin server SHOULD mark the response as cacheable [[!HTTP-cache]] and assign a time-to-live (expiration or max-use) that is sufficient to enable shared caching but not greater than the earliest point at which the service's tracking behavior might increase.
For example, if the tracking status response is set to expire in seven days, then the earliest point in time that the service's tracking behavior can be increased is seven days after the tracking status representation has been updated to reflect the new behavior, since old copies might persist in caches until the expiration is triggered. A service's tracking behavior can be reduced at any time, with or without a corresponding change to the tracking status resource.
If the tracking status is only applicable to users that have the same DNT-field-value, the origin server MUST send a Vary header field that includes "DNT" in its field-value or a Cache-Control header field containing one of the following directives: "private", "no-cache", "no-store", or "max-age=0".
If the tracking status is only applicable to the specific user that requested it, then the origin server MUST send a Cache-Control header field containing one of the following directives: "private", "no-cache", or "no-store".
Regardless of the cache-control settings, it is expected that user agents will check the tracking status of a service only once per session (at most). A public Internet site that intends to change its tracking status to increase tracking behavior MUST update the tracking status resource in accordance with that planned behavior at least twenty-four hours prior to activating that new behavior on the service.
A user agent that adjusts behavior based on active verification of tracking status, relying on cached tracking status responses to do so, SHOULD check responses to its state-changing requests (e.g., POST, PUT, DELETE, etc.) for a Tk header field with the U tracking status value, as described in .
For each tracking status resource, an origin server MUST provide a
valid representation using the
application/tracking-status+json media type.
This media type is defined as a JSON format [[!RFC7159]] that
conforms to the ABNF for
status-object (below)
except that the properties within a property-list can be provided in
any order. More information about the
application/tracking-status+json media type can be
found in .
A tracking status representation consists of a single
status-object containing properties that describe
the tracking status applicable to the designated resource.
status-object = begin-object property-list end-object property-list = tracking-p ns tracking-v [ vs compliance ns compliance-v ] [ vs qualifiers ns qualifiers-v ] [ vs controller ns controller-v ] [ vs same-party ns same-party-v ] [ vs audit ns audit-v ] [ vs policy ns policy-v ] [ vs config ns config-v ] *( vs extension )
The following example tracking status representation illustrates a status object with all of the properties defined by this specification, most of which are optional.
{ "tracking": "T", "compliance": ["https://acme.example.org/tracking101"], "qualifiers": "afc", "controller": ["https://www.example.com/privacy"], "same-party": [ "example.com", "example_vids.net", "example_stats.com" ], "audit": [ "http://auditor.example.org/727073" ], "policy": "/privacy.html#tracking", "config": "http://example.com/your/data" }
status-object always has a property named
tracking with a string value containing
the tracking status value
applicable to the designated resource.
tracking-p = %x22 "tracking" %x22 tracking-v = %x22 TSV %x22
For example, the following demonstrates a minimal tracking status representation that is applicable to any resource that does not perform tracking.
{"tracking": "N"}
An origin server MAY send a property named
compliance with an array value containing
a list of URI references that identify specific regimes to which
the origin server claims to comply for the designated resource.
Communicating such a claim of compliance is presumed to improve
transparency, which might influence a user's decisions or
configurations regarding allowed tracking, but does not have any
direct impact on this protocol.
compliance = %x22 "compliance" %x22 compliance-v = array-of-refs
An origin server MAY send a
property named
qualifiers with a string value
containing a sequence of case sensitive characters corresponding
to explanations or limitations on the extent of tracking.
Multiple qualifiers indicate that multiple explanations or forms
of tracking might apply for the designated resource.
The meaning of each qualifier is presumed to be defined by one
or more of the regimes listed in
qualifiers = %x22 "qualifiers" %x22 qualifiers-v = %x22 *qualifier %x22 qualifier = id-char
An origin server MAY send a property named
controller with an array value containing
a list of URI references indirectly identifying the party or
set of parties that claims to be the responsible data controller
for personal data collected via the designated resource. An origin
server MUST send a
controller property if the
responsible data controller does not own the designated resource's
domain name.
An origin server that does not send
is implying that its domain owner is the sole data controller;
information about the data controller ought to be found on the
designated resource's site root page, or by way of a clearly
indicated link from that page (i.e., an absent controller property
is equivalent to:
If the designated resource has joint data controllers
(i.e., multiple parties have independent control over the
collected data), the origin server MUST send a
controller property that contains a reference
for each data controller.
Each URI reference provided in
controller ought to
refer to a resource that, if a retrieval action is performed on
that URI, would provide the user with information regarding (at a
minimum) the identity of the corresponding party and its data
collection practices.
controller = %x22 "controller" %x22 controller-v = array-of-refs
Since a user's experience on a given site might be composed of
resources that are assembled from multiple domains, it might be
useful for a site to distinguish those domains that are subject to
their own control (i.e., share the same data controller as the
referring site).
An origin server MAY send a property named
same-party with an array value containing a
list of domain names that the origin server claims are the same
party, to the extent they are referenced by the designated
resource, if all data collected via those references share the
same data controller as the designated resource.
A user agent might use the
same-party array,
when provided, to inform or enable different behavior for
references that are claimed to be same-party versus those for
which no claim is made. For example, a user agent might choose to
exclude, or perform additional pre-flight verification of,
requests to other domains that have not been claimed as same-party
by the referring site.
same-party = %x22 "same-party" %x22 same-party-v = array-of-refs
An origin server MAY send a property named
audit with an array value containing a list of
URI references to external audits of the designated resource's
privacy policy and tracking behavior.
Preferably, the audit references are to resources that describe
the auditor and the results of that audit; however, if such a
resource is not available, a reference to the auditor is
audit = %x22 "audit" %x22 audit-v = array-of-refs
An origin server MAY send a property named
policy with a string value containing a
URI reference to a human-readable document that describes the
relevant privacy policy for the designated resource.
The content of such a policy document is beyond the
scope of this protocol and only supplemental to what is described
in the machine-readable tracking status representation.
If no
policy property is provided, this
information might be obtained via the links provided in
policy = %x22 "policy" %x22 policy-v = string ; URI-reference
An origin server MAY send a property named
config with a string value containing a
URI reference to a resource for giving the user control over
personal data collected via the designated resource (and possibly
other resources).
If the tracking status value indicates prior consent
C), the origin server MUST send a
config property referencing a resource that
describes how such consent is established and how to revoke that
A config resource might include the ability to review
past data collected, delete some or all of the data, provide
additional data (if desired), or
or otherwise modify an out-of-band consent status regarding
data collection. The design of such a resource,
the extent to which it can provide access to that data, and
how one might implement an out-of-band consent mechanism are
beyond the scope of this protocol.
config property is provided, this
information might be obtained via the links provided in
controller or
config = %x22 "config" %x22 config-v = string ; URI-reference
An origin server MAY send additional extension
properties in the
status-object to support future
enhancements to this protocol. A recipient MUST ignore
extension properties that it does not recognize.
extension = object array-of-refs = begin-array [ string *( vs string ) ] end-array ns = <name-separator (:), as defined in [RFC7159]> vs = <value-separator (,), as defined in [RFC7159]> begin-array = <begin-array ([), as defined in [RFC7159]> end-array = <end-array (]), as defined in [RFC7159]> begin-object = <begin-object ({), as defined in [RFC7159]> end-object = <end-object (}), as defined in [RFC7159]> object = <object, as defined in [RFC7159]> string = <string, as defined in [RFC7159]> true = <true, as defined in [RFC7159]> false = <false, as defined in [RFC7159]> null = <null, as defined in [RFC7159]>
If an origin server receives a request with
does not have out-of-band consent for tracking this user, and
wishes to deny access to the requested resource until the user
provides some form of user-granted exception or consent for tracking,
then the origin server SHOULD send a 409 (Conflict) response with a
message payload that describes why the request has been refused and
how one might supply the required consent or exception to avoid this
conflict [[!HTTP-semantics]].
The 409 response ought to include a user authentication mechanism in the header fields and/or message body if user login is one of the ways through which access is granted.
This section is for collecting use cases that describe questions a user agent might have about tracking status and how the protocol can be used to answer such questions. More cases are needed.
Deployment of this protocol for a given service can
be discovered by making a retrieval request on the site-wide
tracking resource
to the service URI.
If the response is an error, then the service does not implement this standard. If the response is a redirect, then follow the redirect to obtain the tracking status (up to some reasonable maximum of redirects to avoid misconfigured infinite request loops). If the response is successful, obtain the tracking status representation from the message payload, if possible, or consider it an error.
A key advantage of providing the tracking status at a resource separate from the site's normal services is that the status can be accessed and reviewed prior to making use of those services.
A user agent MAY check the tracking status for a
designated resource by first making a retrieval request for
the site-wide tracking status representation, as described above,
and then parsing the representation as JSON to extract the
If the retrieval is unsuccessful or parsing results in a syntax
error, the user agent ought to consider the site to be
non-conformant with this protocol.
status-object is supposed to have a property
tracking containing the tracking status
value. The meaning of each tracking status value is defined in
If the tracking status value is N, then the origin server claims that no tracking is performed for the designated resource for at least the next 24 hours or until the Cache-Control information indicates that this response expires.
If the tracking status value is not N, then the origin server claims that it might track the user agent for requests on the URI being checked for at least the next 24 hours or until the Cache-Control information indicates that this response expires.
User-granted exceptions to Do Not Track, including site-specific exceptions, are agreed between the site and the user, and stored by the user agent. A resource ought to rely on the DNT header it receives to determine the user's preference for tracking with respect to that particular request. An API is provided so that sites may request and check the status of exceptions for tracking.
We envisage that the exceptions may also be usable as a consent mechanism.
The following principles guide the design of user-agent-managed exceptions.
opt back into tracking for behavioral advertising or similar purposes when they arrive with the Do Not Track setting enabled.
When asking for a site-specific exception, the top-level origin making the request may be making some implicit or explicit claims as to the actions and behavior of its third parties; for this reason, it might want to establish exceptions for only those for which it is sure that those claims are true. (Consider a site that has some trusted advertisers and analytics providers, and some mashed-up content from less-trusted sites). For this reason, there is support both for explicitly named sites, as well as support for granting an exception to all third-parties on a given site (site-wide exception, using the conceptual wild-card "*").
There are some cases in which a user may desire a site to be allowed to track them on any top-level origin. An API is provided so that the site and the user may establish such a web-wide exception.
The call to store an exception MUST reflect the user's intention to grant an exception, at the time of the call. This intention MUST be determined by the site prior to each call to store an exception, at the time of the call. (This allows the user to change their mind, and delete a stored exception, which might then trigger the site to explain, and ask for, the exception again). It is the responsibility solely of the site making the call to determine that a call to record an exception reflects the user's informed consent at the time of the call.
Sites MAY ask for an exception, and have it stored, even when the user's general preference is not enabled. (This permits recording a permission to allow tracking in jurisdictions where such permission cannot be assumed – see .)
The user agent MAY provide interfaces to the user:
If the user revokes the consent by deleting the exception, the site MUST respect that revocation (though it may ask again for the exception). The exception mechanism MUST NOT be used when the site will deem consent to exist even after the exception has been revoked.
This section describes the effect of the APIs in terms of a logical processing model; this model describes the behavior, but is not to be read as mandating any specific implementation.
This API considers exceptions which are double-keyed to two domains: the site, and the target. A user might — for instance — want AnalytiCo to be allowed to track them on Example News, but not on Example Medical. To simplify language used in this API specification, we define three terms:
For instance, if the document at
references the resources
http://exnews.analytico.net/1x1.gif and
the top-level origin is
exnews.analytico.net and
widgets.exsocial.org are both
The domains that enter into the behavior of the APIs include:
Domains that enter into the decision over what DNT header to be sent in a given request include:
Note that these strict, machine-discoverable, concepts may not match the definitions of first and third party; in particular, sites themselves need to determine (and signal) when they get 'promoted' to first party by virtue of user interaction; the UA will not change the DNT header it sends them.
The calls cause the following steps to occur (subject to user confirmation of the exception, if the user agent asks for it):
A pair of duplets [A,B] and [X,Y] match if A matches X and B matches Y. A pair of values A and X match if and only if one of the following is true:
In addition, responses to the JavaScript API indicated should be consistent with this user preference (see below).
User-agents MUST handle each API request as a 'unit', granting and maintaining it in its entirety, or not at all. That means that a user agent MUST NOT indicate to a site that a request for targets {a, b, c} exists in the database, and later remove only one or two of {a, b, c} from its logical database of remembered grants. This assures sites that the set of sites they need for operational integrity is treated as a unit. Each separate call to an API is a separate unit.
It is left up to individual user agent implementations how to determine and how and whether to store users' tracking preferences.
When an explicit list of domains is provided through the API, their names might mean little to the user. The user might, for example, be told that there is a stored exception for a specific set of sites on such-and-such top-level origin, rather than listing them by name; or the user agent may decide to store, and show to the user, a site-wide exception, effectively ignoring the list of domain names, if supplied.
Conversely, if a wild-card is used, the user may be told that there is a stored exception for all third-parties that are, or will be, embedded on the indicated the top-level origin.
storeSiteSpecificTrackingException method takes
a dictionary argument of type StoreSiteSpecificExceptionPropertyBag that allows optional information to be provided.
If the request does not include the
arrayOfDomainStrings, then this request is for a
site-wide exception. Otherwise each string in
arrayOfDomainStrings specifies a
target. When called,
storeSiteSpecificTrackingException MUST return
If the list
arrayOfDomainStrings is supplied, the
user agent MAY choose to store a site-wide
exception. If it does so it MUST indicate
this in the return value.
domain is not specified or is null or empty then
the execution of this API and the use of the resulting permission
(if granted) use the 'implicit' parameter, when the API is called,
the document origin. This forms the first part of
the duplet in the logical model, and hence in operation will be
compared with the top-level origin.
If permission is stored for an explicit list, then the set of duplets (one per target):
[document-origin, target]
is added to the database of remembered grants.
If permission is stored for a site-wide exception, then the duplet:
[document-origin, * ]
is added to the database of remembered grants.
domain is supplied and not empty then it is treated
in the same way as the domain parameter to cookies and allows setting
for subdomains. The
domain argument can be set to
fully-qualified right-hand segment of the document host name, up to
one level below TLD.
For example, www.foo.bar.example.com may set the
domain parameter as as
"bar.example.com" or
"example.com", but not to
If the document-origin would not be able to set a cookie on the
domain following the cookie domain rules [[!COOKIES]]
domain is not a right-hand match or is a TLD)
then the duplet MUST NOT be entered into the database and
a SYNTAX_ERR exception SHOULD be thrown.
If permission is stored for an explicit list, then the set of duplets (one per target):
[*.domain, target]
is added to the database of remembered grants.
If permission is stored for a site-wide exception, then the duplet:
[*.domain, * ]
is added to the database of remembered grants.
A particular response to the API — like a DNT response header — is only valid immediately, and users may choose to edit the list of stored exceptions and revoke some or all of them.
If domain is not supplied or is null or empty then this
ensures that the database of remembered grants no longer
contains any duplets for which the first part is the current
document origin; i.e., no duplets
target] for any target.
If domain is supplied and is not empty then this
ensures that the database of remembered grants no longer
contains any duplets for which the first part is the
domain wildcard; i.e., no duplets
[*.domain, target]
for any target.
There is no callback. After the call has been made, it is assured that there are no site-specific or site-wide exceptions for the given top-level origin.
When this method returns the database of grants no longer contains the indicated grant(s); if some kind of processing error occurred then an appropriate exception will be thrown.
If there are no matching duplets in the database of remembered grants when the method is called then this operation does nothing (and does not throw an exception).
If the call does not include the
arrayOfDomainStrings, then this call is to confirm a
site-wide exception. Otherwise each string in
arrayOfDomainStrings specifies a
If the list
arrayOfDomainStrings is supplied, and the
user agent stores only site-wide exceptions, then the user agent
MUST match by confirming a site-wide exception.
If the
domain argument is not supplied or is null or empty
then the execution of this API uses the 'implicit' parameter,
when the API is called,
the document origin. This forms the first part of
the duplet in the logical model.
If the user agent stores explicit lists, and the call includes one, the database is checked for the existence of all the duplets (one per target):
[document-origin, target]
If the user agent stores only site-wide exceptions or the call did not include an explicit list, the database is checked for the single duplet:
[document-origin, * ]
If the user agent stores explicit lists, and the call includes one,
and the
domain argument is provided and is not empty then the
database is checked for the existence of all the duplets (one per target):
[*.domain, target]
If the user agent stores only site-wide exceptions or the call did
not include an explicit list, and the
domain argument is
provided and is not empty then the database is checked for the single
[*.domain, * ]
The returned boolean has the following possible values:
true all the duplets exist in the database;
false one or more of the duplets does not
exist in the database.
[ * , document-origin] or
[ * , *.domain] (based on if
is provided and is not null and not empty)
is added to the database of remembered grants.
The properties of the
dictionary are as described
above in the
request for site-specific exceptions.
This API requests the addition of a web-wide grant for a specific site, to the database.
[ * , document-origin]
[ * , *.domain] (based on if
is provided and is not null and not empty).
There is no callback. After the call has been made, the
indicated pair is assured not to be in the database. The same
matching as is used for determining which header to send is used
to detect which entry (if any) to remove from the database.
This API confirms the existence of a web-wide grant for a specific site, in the database.
The returned boolean indicates whether the duplet
[ * , document-origin] or
[ * , *.domain]
(based on if
domain is provided and is not null and
not empty) exists in the database.
true indicates that the web-wide exception exists;
false indicates that the web-wide exception
does not exist.
A site may request an exception for one or more third party services used in conjunction with its own offer. Those third party services may wish to use other third parties to complete the request in a chain of interactions. The first party will not necessarily know in advance whether a known third party will use some other third parties.
If a user agent sends a tracking exception to a given combination of origin server and a named third party, the user agent will send DNT:0 to that named third party. By receiving the DNT:0 header, the named third party acquires the permission to track the user agent and collect the data and process it in any way allowed by the legal system it is operating in.
Furthermore, the named third party receiving the DNT:0 header acquires at least the right to collect data and process it for the given interaction and any other use unless it receives a DNT:1 header from that particular identified user agent.
The named third party is also allowed to transmit the collected data for uses related to this interaction to its own sub-services and sub-sub-services (transitive permission). The tracking permission request triggered by the origin server is thus granted to the named third party and its sub-services. This is even true for sub-services that would normally receive a DNT:1 web-wide preference from the user agent if the user agent interacted with this service directly.
For advertisement networks this typically would mean that the collection and auction system chain can use the data for that interaction and combine it with existing profiles and data. The sub-services to the named third party do not acquire an independent right to process the data for independent secondary uses unless they, themselves, receive a DNT:0 header from the user agent (as a result of their own request or the request of a first-party). In our example of advertisement networks that means the sub-services can use existing profiles in combination with the data received, but they can not store the received information into a profile until they have received a DNT:0 of their own.
A named third party acquiring an exception with this mechanism MUST make sure that sub-services it uses acknowledge this constraint by requiring the use of the appropriate tracking status value of 'C' (consent), and the qualifier "t", from its sub-sub-services.
The permission acquired by the DNT mechanism does not override retention limitations found in the legal system the content provider or the named third party are operating in.
As described above, it is the responsibility solely of the site making the call to determine that an exception grant reflects the user's informed consent at the time of the call.
It is expected that the site will explain, in its online content, the need for an exception, and the consequences of granting or denying an exception, to the user.
User agents are free to implement exception management user interfaces as they see fit. Some agents might provide a notification to the user at the time of the request, or even not complete the storing of the exception until the user approves. Some agents might provide a user-interface to see and edit the database of recorded exception grants. The API parameters siteName, explanationString, and detailURI are provided so that the user agent may use them in their user interface.
A user agent that chooses to highlight when tracking exceptions have been stored might provide an interface like the following.
In some user agent implementations, decisions to grant exceptions may have been made in the past (and since forgotten) or may have been made by other users of the device. Thus, exceptions may not always represent the current preferences of the user. Some user agents might choose to provide ambient notice that user-opted tracking is ongoing, or easy access to view and control these preferences. Users may desire options to edit exceptions either at the time of tracking or in a separate user interface. This might allow the user to edit their preferences for a site they do not trust without visiting that site.
To obtain an exception, a document (page, frame, etc.) that loads the Javascript is needed. The user may visit the site that desires an exception directly, the first party site could load a frame of the site desiring the exception, or that frame might be part of some other page containing a number of frames, which allows aggregation of requests for exceptions.
In all these ways, the site is contributing to informing the user and getting their consent, and is also able to call the Javascript API when it is granted.
Sites might wish to request exceptions even when a user arrives without a DNT header. Users might wish to grant affirmative permission to tracking on or by certain sites even without expressing general tracking preferences.
User agents MAY instantiate
even when
window.doNotTrack is null. Scripts SHOULD
test for the existence of
storeSiteSpecificTrackingException before calling
the method. If an exception is granted and the
user agent stores that preference, a user agent may send a DNT:0
header field even if a tracking preference isn't expressed for other
requests. Persisted preferences MAY also affect which header is
transmitted if a user later chooses to express a tracking
Users might not configure their agents to have simple values for DNT, but use different browsing modes or other contextual information to decide on a DNT value. What algorithm a user agent employs to determine DNT values (or the lack thereof) is out of the scope of this specification.
This section is to inform the authors of sites on some considerations in using the exceptions APIs to best effect; sites of particular interest here are those that need an exception in order to allow the user to perform some operation or to have some access.
The 'Store' calls do not have a return value, and return immediately. If there is a problem with the calling parameters, then a Javascript exception will be raised. In addition, it may be that the user agent does not immediately store the exception, possibly because it is allowing the user to confirm. Even though the site has acquired the user's informed consent before calling the 'Store' API, it is possible that the user will change their mind, and allow the store to proceed but then later ask it be removed, or even by denying the storage in the first place.
Sites can call the 'Confirm' APIs to enquire whether a specific exception has been granted and stands in the user agent. This is the call to make to determine whether the exception exists, and hence to control access to the function or operation; if it fails (the exception has been deleted, or not yet granted), then the user is ideally again offered the information needed to give their informed consent, and again offered the opportunity to indicate that they grant it. As stated in the normative text, the site needs to explain and acquire consent immediately prior to calling the Store API, and not remember some past consent; this allows the user to change their mind.
If they do grant it (using some positive interaction such as a button), the site can return to checking the 'Confirm' API.
In this way the site:
By storing a client-side configurable state and providing functionality to learn about it later, this API might facilitate user fingerprinting and tracking. User agent developers ought to consider the possibility of fingerprinting during implementation and might consider rate-limiting requests or using other heuristics to mitigate fingerprinting risk.
This specification consists of input from many discussions within and around the W3C Tracking Protection Working Group, along with written contributions from Adrian Bateman (Microsoft), Justin Brookman (CDT), Nick Doty (W3C/MIT), Marcos Caceres (Mozilla), Rob van Eijk (Invited Expert), Roy T. Fielding (Adobe), Vinay Goel (Adobe), Tom Lowenthal (Mozilla), Jonathan Mayer (Stanford), Aleecia M. McDonald (Stanford), Mike O'Neill (Baycloud Systems), Matthias Schunter (Intel), John Simpson (Consumer Watchdog), David Singer (Apple), Rigo Wenning (W3C/ERCIM), Shane Wiley (Yahoo!), and Andy Zeigler (Microsoft).
The DNT header field is based on the original Do Not Track
submission by Jonathan Mayer (Stanford), Arvind Narayanan
(Stanford), and Sid Stamm (Mozilla).
The JavaScript DOM property for
doNotTrack is based on the
Web Tracking Protection submission by Andy Zeigler,
Adrian Bateman, and Eliot Graff (Microsoft).
Many thanks to Robin Berjon for ReSpec.js.
The Internet media type application/tracking-status+json is used for tracking status representations ().


text:
Intel and Nokia, two of tech's biggest titans, today announced the new Linux-based software platform called MeeGo, which merges the popular Moblin and Maemo projects and sets the companies' sights on a new generation of computing devices, applications and services. The first release of MeeGo is expected in the second quarter of 2010 with devices launching later this year.
This move is significant given the companies' market leadership positions. Recent reports indicate that Intel enjoys 79.7 percent of the microprocessor market while Nokia commands 40 percent of the worlwide smartphone market, though MeeGo is being positioned for much more than smartphones.
MeeGo will be hosted by The Linux Foundation where it will aim to build broad industry collaboration using the open source development model. The world's largest chip maker and largest mobile device company say that by working collaboratively and merging the technologies, they can accelerate product innovation and expand market opportunities for developers. The companies report that MeeGo supports multiple hardware architectures across the broadest range of device segments.
Nokia's CEO, Olli-Pekka Kallasvuo, said, "Through open innovation, MeeGo will create an ecosystem that is second to none, drawing in players from multiple industries." He added, "Simply put, MeeGo heralds a new era of mobile computing."
The announcement was unveiled today at a press conference at Mobile World Congress in Barcelona where details were provided by Intel senior executives Renee James and Doug Fisher and Nokia's Executive Vice President of Devices, Kai Öistämö, and Vice President, Maemo Devices, Ari Jaaksi. Linux Foundation Executive Director Jim Zemlin, Intel CEO Paul Ottelini and Nokia CEO Olli-Pekka Kallasvuo were also in attendance.
MeeGo is expected to power new devices that include pocketable mobile computers, netbooks, tablets, mediaphones, connected TVs and in-vehicle infotainment systems. It appears that Symbian will remain, at least for now, a platform for Nokia's phones, especially their entry-level phones. Intel and Nokia define next-generation computing devices as ones that are pocket-sized, based on open standards and combine multi-tasking and ubiquitous connectivity to deliver a transformative user experience.
Intel President and CEO Paul Otellini said, "Our vision for seamlessly communicating between computing devices from the home, auto, office, or your pocket is taking a big step forward today with the introduction of MeeGo."
MeeGo uses the Qt application development envrionement, which should help bridge development among Symbian, Windows, Mac and other platforms. The cross-platform application and UI framework is well known and widely used because of how easy it makes it for developers to write their apps once and deploy them across devices and platforms. Skype for example, used Qt to create its application, which is available on Windows, Mac and Linux.
The Linux Foundation's Jim Zemlin said, "MeeGo has been built from the ground up for rich, mobile devices and will deliver choice to consumers without lock-in. For developers, they will have the power of the Qt platform across a multitude of devices and architectures giving them an incredible opportunity to innovate and reach uses."
MeeGo initially includes two reference UI implementations, one for netbooks and one for pocketable mobile computers. Intel and Nokia say they will continue to contribute to upstream open source projects such as X.org, D-BUS, tracker, GStreamer, Pulseaudio and Mozilla.
Get more details in this video interview with Intel's Doug Fisher and Nokia's Ari Jaaksi:
More information can be accessed at http://www.linuxfoundation.org/meego.
* Disclosure: Linux.com is a Linux Foundation web property.

subset: commoncrawl


text:
Recently the MDHE had the opportunity to distribute grants through the federal College Challenge Access Grant program. We provided more than $700,000 to nine groups that help low-income students attend college. The grant recipients do amazing work. College Bound of St. Louis received $100,000. We spoke with Lisa Orden Zarin, who founded College Bound in 2006.
Lisa told us that she is the daughter of a teacher, a single mom, who instilled in her the belief that education is the engine that can transport people out of poverty. "It's something that no one can take away," Lisa said. "It is society's most important value."
College Bound has a 100 percent success rate. All 80 of the students they have assisted so far are either in college or have letters of admission in hand. This year, the students received non-need-based scholarships worth $3.6 million. But it wasn't easy.
A few of the students described their obstacles to colleges. Ayriel's father died, her mother couldn't find a job, their utilities were cut off and they bounced from one relative's house to the next. Devon's list included threats from drugs and street crime. Alexis said her hopeless attitude spilled over to her school work and relationships with other people. But they all found support and persistence in the staff of College Bound.
"As a person of privilege, we have little idea how difficult it is for these students to persevere," Lisa observed. "Once they get to college, they can feel as if they've been transported to Mars. That's why we start in the 9th grade to build a true sense of transformation so that, when they reach college, they know they've earned the status to be there."
The students, in turn, mentor younger students and help with service projects such as Habitat for Humanity. College Bound's motto, Lisa says, is "To whom much is given, much is required."


text:
Harold Covington is back and starts with his now regular election commentary. He remains convinced that Trump will not be allowed near the Oval office and points out some of the various conspiracies to ensure that Clinton wins instead. America now has a one-party state with an entirely loyal and controlled opposition, who are content to remain perpetually as the opposition. If Trump does get close to the prize, then Harold is convinced he will be assassinated by a loner who hears voices in his head and so we need to plan now, for what happens once our hero is gone.
Gretchen reviews 1924 – The Year That Made Hitler, by Peter Range. It deals with the turmoil in Germany at that time and the rise of Hitler from being asked to investigate the fledgling NSDAP to being adored by thousands at his speeches. Gretchen gives a good synopsis of the 4 years leading up to this point including the intricate relations between the various characters involved in the pustch and what Hitler was trying to achieve with Mein Kampf. She really recommends that people read this book and feels she cannot do it justice in a short review.
The Trucker is now in California and talks about how BLM are now blocking interstates and roads and that this is eventually going to be happening nation-wide.
This leads on to Harold encouraging people to think about the future and what it is likely to hold for us, if the Donald is taken from us. Could there possibly be a revolt, when people realise that their votes really do not matter? We may see a large coalition of different groups united in their disgust at this, but they would require a leader. We may get an Amon Bundy type who has read the right books and finds himself in a situation where he actually points a firearm at one of the dictator's servants and then tells the world to grab their weapons and follow his lead. Harold believes that a revolt will happen and that if it does, then it will happen like this.
Presented by Harold Covington
Radio Free Northwest: Preparing for the Future – RFN 042816
Download (01:01:51)
Radio Free Northwest will be back on Radio Aryan next Thursday at 3pm EDT/8pm BST
See the daily schedules for more nationalist audio available to download.
Aryan chatroom, Aryan bootlegs, Aryan feed.
Northwest Front


text:
A day after New Jersey banned executions, newly released figures show that capital punishment dropped this year to a 13-year low.
Forty-two people have been put to death this year, according to the Death Penalty Information Center (DPIC), a Washington-based group that opposes the practice. That figure is down 57 percent from what it was in 1999, when 98 inmates were executed.
Next year's figures are expected to drop further. The Supreme Court is to hold oral arguments January 7 about whether lethal injection protocols in 36 of the 37 states with the death penalty are constitutional. See how the rates have dropped Read full article »
All About Capital Punishment • Criminal Sentencing and Punishment • New Jersey


text:
Dress lengths will plummet to the floor, and rise to the event to disclose numerous leg. The most well-liked length will probably be just above or just beneath the knee. This length seems to compliment nearly all of girls. One thing happens if you eat, and chat, and complain, and snicker, and even cry over a meal with mates. And this past Saturday all the above occurred and it was grand. In June of 1943, Los Angeles was the scene of riots instantly associated to the zoot suit. On account of Battle Manufacturing Board laws, zoot suits had been only obtainable by bootleg tailors dealing in black market items. Wearing one was to defy the laws of rationing, to problem the established order, and to snub mainstream White culture.
Thanks for the website suggestions – there is a couple in here I've by no means seen before. Should examine them out for certain! An enormous trend this summer time would be the lengthy to just above the knee boyish lengthy shorts – paired with female tops. Add an important flip flops or heels, you're good to go. Hello Anne – it's fairly however still pretty uncomfortable. This corset can be advised for exercise. Positive. I'd reasonably simply exercise. Tea robes might feature Empire waists, trains, flounces and Watteau pleats (a large pleat extending from the top of the dress). Some tea gowns came in floral patterns. They could possibly be sensible or elegant.
What an incredible lens, packed with information … Read More


text:
Since 1949 different Karen ethnic armed groups have been fighting against the Myanmar government's army (Tatmadaw). Arguably it is the world's longest-running civil war. In 2011, former President Thein Sein opened the door for ethnic groups to negotiate peace with the government. Then, in January 2012, the Myanmar government, led by Railway minister U Aung Min, and the Karen National Union (KNU) met for the first time to have peace talks in Hpa-an. As a result, the KNU signed a preliminary ceasefire agreement with the Myanmar government on January 12th 2012. Further talks between the government and the KNU were held and finally on October 15th 2015, a Nationwide Ceasefire Agreement (NCA) was signed between the government and eight of the fifteen ethnic armed groups originally invited to the negotiation table, including the Karen National Union/Karen National Liberation Army (KNU/KNLA), KNU/KNLA-Peace Council (KNU/KNLA-PC), and the Democratic Karen Benevolent Army (DKBA Benevolent). While embraced by the United Nations (UN), the decision to sign the NCA was criticised by some members of the Karen armed resistance and Karen civil society groups in southeast Myanmar who felt that the NCA was a superficial agreement that risked undermining a genuine peace process. The current situation is that of a ceasefire; a long lasting peace is yet to be achieved, so the world's longest running civil war cannot be said to have ended yet.
We have all witnessed, in November 2015, a landslide victory of Daw Aung San Suu Kyi's National League for Democracy (NLD) party, which further heightened expectations for enduring peace and stability. It must be noted however that the military-drafted Constitution still appoints 25% of the Hluttaw (Parliament) seats to the military and the key security ministries of defense, home affairs, and border affairs are military-controlled. Daw Aung San Suu Kyi, who now holds the offices of Myanmar State Counsellor, Minister of Foreign Affairs and Minister of the President's Office, met with the NCA Joint Monitoring Committee (JMC) for the first time on April 27th 2016.
More recently, on August 31st 2016, the 21st Century Panglong conference began. The new peace conference strived to include groups that have not yet signed the NCA, but only partially succeeded as the Arakan Army, Myanmar National Democratic Alliance Army (MNDAA), also known as the Kokang Army, and the Ta'ang National Liberation Army were barred from participation even though they expressed willingness. A non-signatory group that did participate initially, the United Wa State Army (UWSA) reportedly withdrew from the conference because they were only given 'observer' status and not an equal status as the other participants. Another major concern on the 21st Century Panglong conference was the lack of women's participation, a trend which Karen Human Rights Group (KHRG) also pointed out in its recently published report 'Hidden Strengths, Hidden Struggles'.
Locally defined Karen State, which covers most of southeast Myanmar, has felt the continued presence of military actors despite these recent changes in the national framework. KHRG has documented militarisation and its impacts on local communities in Karen areas since 1992. Now, just after the NCA's first anniversary (October 15th 2016), in this detailed militarisation commentary, KHRG will highlight how the path towards a long lasting peace in Myanmar continues to be threatened by ongoing militarisation and clashes in southeast Myanmar. This commentary is based on reports and information gathered in Karen areas in southeast Myanmar since January 2012 up and until October 2016. The focus of the commentary is on the more recent reports, especially since 2014 and special attention is paid to the incidents which have occurred after the signing of the NCA in October 2015.
'Militarisation' in the context of this commentary is taken to mean any activity that villagers perceive as intended for military purposes. This category includes the building of new bases, including land confiscation, by armed groups, the strengthening of existing bases and military training exercises, as well as the ongoing rotation of troops, re-supply of rations, weapons and ammunition, ongoing landmine contamination, unexploded ordnance and remnants of war, and recurring skirmishes between armed actors. The ongoing displacement of communities and the effect militarisation has on their livelihoods is also described.
Conclusion and Recommendations
While the situation of safety and security for communities in southeast Myanmar has noticeably improved after the NCA there are still legitimate concerns by villagers that need to be addressed before a real stable and long term peace can be achieved. Some of the most common recommendations coming directly from the affected communities are displayed below, after which KHRG will give its own recommendations.
"What I want is, as they [the Myanmar government] are the parents/leaders, I want them to order all of the soldiers who are spread out to go back. Order the BGF and Tatmadaw soldiers to go back. If they are called back, the civilians will be able to live peacefully."
Naw M---, (female, 46), K--- M--- village, Kawkareik Township,
Dooplaya District/south Kayin State, March 2016
"They [the villagers] want the Tatmadaw to remove [their camps]. If the Tatmadaw remove [from the villagers' area], they [villagers] will be able to return to their village. They [the villagers] want us [village tract leaders] to talk to the Tatmadaw to not disturb them when they work in their working places so that they will be able to have freedom and live peacefully. They report that it will be the best if there is no place [for the Tatmadaw to base in the area]."
Saw S--- (village tract secretary), (male), H--- village, K--- village tract,
Lu Thaw Township, Hpapun District/northeast Kayin State, April 2016
"Regarding the armed groups, if the situation is getting better, I would like them to go back to live in their own place. Please do not live in the village."
Saw N---, (male, 51), K--- N--- village, K--- N--- village tract,
Kawkareik Township, Dooplaya District/south Kayin State, March 2016
"If the Tatmadaw stay near us, the villagers have to be afraid of them. They [villagers] also have been oppressed. Therefore, they do not trust the Tatmadaw. If they withdraw their camps in the ceasefire period, the villagers might have some trust for the Tatmadaw. Now, they do not trust the Tatmadaw so they reported to us that they want the Tatmadaw's camps to be withdrawn. […] Therefore, we want the international community to help us and advocate for us so that the Tatmadaw's camp will be withdrawn."
Saw B--- (village tract leader), (male, 43), T--- village, H--- village tract,
Lu Thaw Township, Hpapun District/northeast Kayin State, April 2016
KHRG recommends:
The Myanmar government, Tatmadaw, Border Guard Forces, Karen National Union/Karen National Liberation Army, Democratic Karen Benevolent Army, Democratic Karen Buddhist Army and other armed groups in southeast Myanmar should work to make the Nationwide Ceasefire Agreement (NCA) sustainable and work towards a long lasting peace as this is the only way to ensure the most violent human rights abuses will not reoccur.
To ensure a peace process that is stable and long lasting all armed actors, but especially the Tatmadaw and BGF, should begin to demilitarise former conflict areas by removing troops and camps, particularly those positioned close to villages and livelihood areas, and immediately cease the confiscation of land in southeast Myanmar for the purposes of: constructing military facilities, which include camps, barracks, and housing for the families of soldiers; or leasing the confiscated land back to villagers in order to generate income.
To prevent any further armed conflicts, all development actors (local and international businesses and investors, including international financial institutions such as the Asian Development Bank and the World Bank) should conduct environmental, human rights and conflict impact assessments before implementing any mega projects such as constructing dams, highways and mining. These assessments should be carried out independently of the actor's interests, in consultation with project-affected communities, respecting the international principle of 'Free, Prior and Informed Consent', and made publicly available in local languages.
The Myanmar government as well as development actors should ensure fair and adequate compensation is provided to communities affected by past and present land confiscations and avoid confiscating land in the future.
The Myanmar government, Tatmadaw, Border Guard Forces, Karen National Union/Karen National Liberation Army, Democratic Karen Benevolent Army, Democratic Karen Buddhist Army and other armed groups in southeast Myanmar are obligated to ensure that all armed forces under their control observe their responsibilities under domestic and international humanitarian and human rights law and hold military personnel accountable for abuses committed in fair and transparent judicial processes.
The Myanmar government, Tatmadaw, Border Guard Forces, Karen National Union/Karen National Liberation Army, Democratic Karen Benevolent Army, Democratic Karen Buddhist Army and other armed groups in southeast Myanmar should agree to and enforce a comprehensive ban on the new use of landmines and hold meaningful consultations with all relevant actors before starting systematic demining efforts, as demining without consultation in conflict-sensitive areas could lead to further conflict.
For more information, please contact:
Way Lay
Advocacy Coordinator
+66 061-383-7257
Eh Thaw
Advocacy Coordinator
+95 09 787-104-659 / +95 09 421 031 144


text:
On our first anniversary, Hydroxychloroquine took me to the ophthalmologist. We arrived at a small quaint building, painted white, the outside decorated with bright pink and orange flowers. Cherry blossoms lined the street with their crimson veils. Tiny petals speckled the sidewalks, leading us to our first analysis of our life together. I sat in... Continue Reading →
The Sole Mate
I scuttled across the wet ground, ducking beneath my umbrella as the rain pelted down. My left foot plunked into a shallow puddle; within moments, a distinct squishing sensation accompanied each new step and my foot grew cold and wet... A large selection of boots was displayed on one wall of the store. I looked... Continue Reading →
The Warm Bath
The water flowed from the spout crashing into the tub. Goosebumps danced on my skin in anticipation of dipping into a hot bath, liberating me from the pain of arthritis. A light mist drifted over the mirrors creating a pleasant haze with a sweet scent and a warming ambience. I lowered my body into the... Continue Reading →


text:
Hello, Beauts! So today's post is brought to you by the unfortunate makeup mishap- shattered powder makeup. Cue the slo-mo "NOOOO!!!!". I'm sure most of you have been there at some point! While I'm not one to really care too much about using a broken shadow or blush, it can get messy and quite frankly looks…crappy. And being careful to not get it everywhere is too much work. So here I wanted to share my experience of fixing a broken shadow by using the rubbing alcohol method. This method is pretty popular and by no means new-I just felt like playing around to see if it would actually work.
Things to note before starting-this is a messy process. Especially if it's your first time. Use a towel or mat underneath it all to catch makeup that will inevitably get everywhere. There will be some product loss since all that tossing and patting will do that, but you'd probably lose the same amount if it were to stay broken anyway. Lastly, it may not look factory perfect after this process but heck if you want your makeup back in one piece, this could be worth a shot!
So here's an E.L.F. shadow I ordered back in November that actually arrived broken. Isn't that nice? I probably could have returned it or just bought another one since it wasn't expensive, but I like a good project and had everything I needed to try this out. Even if a total fail, I didn't have much to lose.
Materials used: bowl, butter knife or small spatula, towel, and 70% Isopropyl alcohol that you can find in any drugstore.
Here are the steps:
1.Take your broken shadow, dump it into a container, and crush. For this dome shadow I dumped in only the broken pieces. If you have a regular flat-pan shadow, you can crush up the entire shadow right in the pan. Yes you heard me right. Crush it up as much as you can until you don't see any huge chunks.
2. Take a minute to cringe at the fact that it feels like you're pretty much attacking an eyeshadow. Just hold your breath and get it over with.
3. Add 4-5 drops of alcohol into the bowl and mix. You could use a dropper if you want more control, but I didn't. Stir it in. You can add more until it reaches an almost pasty/damp consistency. It looks strange seeing your makeup look muddy but trust the process. Don't put too much alcohol in or it'll get soupy. Remember that you want to be able to mold it.
4. Take the makeup "paste" you made and use a spatula or some type of small, flattened object (I used a butter knife) to mold it into the pan, or whatever shape it was originally. Since this shadow was dome-shaped, I tried my best to form it that way. I recommend using a paper towel to press down on it to get out the excess alcohol and even it out. It was actually much easier than I thought it would be!
5. Clean up the edges with makeup wipe or wet napkin if you want it to look nice and neat.
6. Leave open to dry for about 24 hours. It might be dry before that but it might depend on how much alcohol is in there. If possible, I'd wait just to be on the safe side!
7. Use your newly fixed eyeshadow!
So did it work?! I can say that I've used it after trying this and it's kept its shape and the formula didn't change when applied. This is a pretty good way to get your shadow looking functional again. As mentioned earlier, it's not going to look or be exaaaactly like it did when you first bought it, but having my broken makeup together again beats out the hot mess crumble it once was. I've tried this with blush as well and with similar results.
I would like to add that after this process my shadow seemed a little more fragile, so I wouldn't go at it too hard. Not sure if I needed to add more alcohol after all, or maybe less? I will have to experiment more, but hopefully I won't have to try this process out too many more times if you know what I mean lol.
Update: So my eyeshadow, after having been fixed for a few weeks now, is mainly still in tact but I do notice some fallout/some crumbling and I haven't really even used it since fixing. So again- it's a good method to keep it from being super broken, but it will be more fragile and prone to breakage again with or without a lot of use from my own personal experience. Again, I may have to play around with the amount of alcohol used and see if that makes a difference, or maybe even the type of product.
Have you ever used alcohol to fix a makeup product? Was it the same method or different? How did it go?
XX, Jen <3


text: St. Martin's Church Small 204×320 Medium 408×640 Large 653×1024 Download TIFF Original 1530×2400 | (2.8 MB) Description The old Byzantine church, St. Martin's Church was the beloved church of the poor. It stood by the Cathedral of Cologne and represented the old Catholic city of the Rhine. Keywords Byzantine churches, cathedral, Catholic Church, church, german churches, Martin's, st, St. Martin's church Galleries German Buildings and Monuments Source: DeColange, Leo The Heart of Europe from the Rhine to the Danube (Boston, MA: Estes and Lauriat, Publishers, 1883)


text:
Today was the first music workshop given by three members of the new MwB women group from Batir: Anaya, Rena and Hanan.
They did a wonderful job with the seven boys, age 12-14, that performed dabke, a traditional Palestinian dance, before the workshop started.
The workshop leaders made music with the children while singing, using body percussion and sticks. They finished the workshop with the "who is the leader" game, in which the children take turns in being the leader and showing the others movements and rhythms, while the child in the middle has to guess who is the leader.
Although the boys were a bit hesitating before we began the workshop ("what do you want to do with us….?") they immediately joined once we started, had lots of fun and asked us when the next workshop would be!


text:
Member News
September 2010
In This Issue
What About the Rest of Us?
Finding the Perfect Pace
Shoulder Pain and MRIs
'10 Summer Nationals Recap
RPC Tiburon Mile
SwimMAC Club Video
We've Got Spirit!
Follow us:
Really Cool Website of the Month
Check out this month's awesome website at:
To be considered for RCWOM, please make sure that your team's website includes the current USMS logo and Join/Renew membership button. You may submit your team name and web address to the USMS for consideration at
Swimmer of the Month
Nathan Dean
Fitness Article
of the Month
5,000 Miles and Still Going Strong
Special Offer!
Get your
USMS embroidered Chammyz
at a fraction of the retail price with our exclusive USMS offer of
$59.99 (plus embroidery)
. Chammyz are available in ten different colors and five different sizes so you can find comfort in whatever style that fits you.
Our Partners Support YOU!
Please Support Them
Affinity Partners
Media Partners
Exclusive info and content
Fitness/participation programs
Competition programs
Recognition and awards
Partner discounts
What About You?
Do you have a story to tell? We are always interested in hearing from our members about their swimming experiences. We may feature your story on the Web, in
, or in
magazine. Write to us at
Dear (Contact First Name),
Summer just flew past us. Many of you enjoyed our two big national championship pool meets and the great variety of open water and long distance events across the country. As we head into fall we have more events to look forward to. Additionally, Convention is this month, so we will have updates from our House of Delegates in the October issue of
Swimming for Life!
Your Friends at U.S. Masters Swimming
What About the Rest of Us?
By Kristina Henry
I am an average swimmer. As a child growing up in Vienna, Virginia I swam on our neighborhood swim team, the Shouse Village Sharks. In those halcyon days during the 1970s we all wore the Mark Spitz stars and stripes suits, ate raw Jell-O and basically swam because we hung out at the pool all day anyway and our parents didn't want to see us until dinner time. Swimming was just something to do.
[Read more]
3000/6000 Yard Championships
Masters of South Texas (MOST) will be hosting the 3000/
6000 yard Championships in 2010. The 3000-Yard and/or the 6000-Yard must be swum in its entirety on or between September 15 and November 15, 2010. The objective To swim 3000 yards and/or 6000 yards in any 25-yard pool. Some people do the events for competition, while others do it for fitness; all who wish to participate are welcome. The recorded time you submit determines the order of finish. If two or more swimmers report the same time, a tie will be declared. Get out during the "off season," challenge yourself and swim them both!
For more information, contact
Susan Ingraham
Online Registration
Paper Entry Form (Individual)
Relay Entry Form
Open Series
The final two events in this year's H
Open Series are upon us. This weekend,
Big Shoulders
in Chicago goes off -- a sold out race! Check back at the event website for updates and results.
There is still time to register for Tropical Splash on October 2nd. Sarasota, home to the USMS National Headquarters, is the perfect place for an October getaway. For those of you wanting to make it an active open water weekend, the
Siesta Key Triathlon
-- a sprint tri in its 27th year-- is held the day after Tropical Splash, October 3rd.
Online Registration
Finding the Perfect Pace
by Tim Elson, Finis, Inc.
As a former swim coach, I would say that one of the most fundamental functions a coach serves is to give immediate feedback to an athlete after a swim. The process goes something like this: "As soon as you finish your swim, make sure you loosen down then come look at your splits." That immediate feedback is dominated by numbers. After all, we race to achieve the lowest numbers.
[Read more]
Shoulder Pain - When to have an MRI
by Ross A. Hauser, M.D.
Shoulder pain is the most common pain complaints in swimmers. Studies have shown that between 47 and 73 percent of musculoskeletal problems in swimmers relate to their shoulders. It is no wonder these injuries are so common considering that an elite swimmer may log up to 20,000 yards per day. Or consider the college or high school swimmer who is averaging 5,000 yards per day, five days per week, for 10 months per year. If one has an estimated 15 individual arm movements per 25-yard pool, this would account for over 600,000 arm movements per year. Yes, it is easy to see why a swimmer may end up with shoulder pain.
[Read more]
2010 Summer Nationals Recap
U.S. Masters Swimming was well represented in San Juan with over 600 athletes competing. North Carolina Masters came out on top in the regional club competition, and in the local club category, Fort Lauderdale Aquatics ran away with the title. You can find their picture in the Spirit section below.
Complete scores and individual results
are posted. Video recaps of the event can be found on our
YouTube Channel
. Photos of the event can also be found online courtesy of
Leonardo Rivera
Start planning for the
2011 Spring Nationals
being held in Mesa, Ariz. from April 28 - May 1 and Summer Nationals will be in Auburn, Ala. August 3 - 6. Both of these are held at great venues and promise to be fun events.
RPC Tiburon Mile
by Alex Kostich
It has often been said that swimming the English Channel is the Mt. Everest of open water sport, and if that is the case then the RCP Tiburon Mile would be the equivalent to the world's most prestigious tower climb, The Annual Run Up Empire State Building in New York.
Each year in October, a short, intense, and star-studded open water swim takes place in the picturesque town of Tiburon, Calif., called the RCP Tiburon Mile.
[Read more]
SwimMAC Masters Club Video
Head coach Patty Waldron walks us through her North Carolina USMS program. Check out the video below.
We've Got Spirit!
Ft. Lauderdale Aquatic Masters
Ft. Lauderdale Aquatic Masters swimmer Adrienne Chin-Ogilvie sent this victory photo taken in San Juan. FLAQ had an amazing meet, taking the championship title in the local clubs division by over 2000 points. "As the largest team present, in red shirts, we were obviously the noisiest kids in the neighborhood - thunder sticks, shouting, dancing, cheering, clapping, whistling, etc. All 76 swimmers made Top 10 in at least one individual event ... Many personal bests were accomplished..." says Chin-Ogilvie.
During the meet, FLAQ swimmers kept in touch with each other and their teammates back home with regular Facebook postings-giving rise to their meet motto, "What Happens in San Juan Goes on Facebook." Coach Marty Hendrick celebrated along with his team by showing up at the natatorium each day with a new hairstyle: "From brown, sandy hair to platinum blonde hair, to a Mohawk and finally, a bald head!" says Chin-Ogilvie.
Congratulations to Ft. Lauderdale Aquatic Masters!
Dive in at
About U.S. Masters Swimming
U.S. Masters Swimming, founded in 1970, is a membership-operated national governing body that promotes adult health, fitness, wellness and competition through aquatics. It does so by partnering with more than 1,000 adult swim programs across the country; promoting information via the bi-monthly member magazine,
, monthly e-newsletter,
, and usms.org; and by sanctioning and promoting pool, open water and virtual competitions. More than 50,000 adults are registered members of U.S. Masters Swimming.
U.S. Masters Swimming encourages all U.S. Masters Swimming members to subscribe to
, however if you would rather not receive this update, please do not click the unsubscribe button, as that will remove you from all other U.S. Masters Swimming National Office mailings. Rather, please click on the "Update Profile/Email Address" link at the bottom of this email. Here you can select to discontinue your
service or sign up for the monthly coaches' newsletter,
for Coaches, and/or
for Volunteers, a quarterly publication
Header photo by Cokie Lepinski.
Email Marketing


text:
Musical robots can do amazing things, but in order to make them musical, it helps if they can communicate with other music software, like your favorite DAW. By creating Music Bots that understand MIDI they can be controlled in the same way as synthesized sounds or samples.
The Teensy microcontroller can be used as a MIDI device and combined with the MIDI Bots Motor Driver Board or other motor driver circuit can trigger motors with native MIDI support over USB.
Teensy makes it easy to create custom MIDI devices. This can be a controller that creates MIDI messages or an output that takes in MIDI messages and turns them into an action.
The Teensyduino add-on for Arduino includes a library to handle MIDI communications. In this tutorial I'll show you how you can use the Teensy as an output device that can control LEDs, motors or anything else you want to hook up to your Teensy.
Different coders for different motors
The control code used depends on the type of motor being driven. The Music Bots Driver Boards use a MOSFET circuit that is suitable for DC motors, vibration motors and solenoids.
Solenoids have a short quick movement. This makes them good and impulsive movements, like that of a drum stick. They only need to be turned on for a short pulse (typically 10-20 ms) in order to fully activate. Longer than that and their final position is simply held. Often a return spring is used to reset the solenoid after the voltage is removed. So to control a solenoid we only need a short pulse each time the motor is activated. For solenoids we will only use "note on" messages to trigger the solenoids. They will be pulsed for a predetermined time and then turned off automatically.
When using other DC motors such as hobby motors, geared motors and vibration motors, chances are you want to turn them on for more than 20ms each time you trigger them. For these motors we will use MIDI "note on" messages to activate the motor and they will remain on until the corresponding "note off" message is sent.
Velocity control
The MIDI velocity message typically controls the volume and perhaps timbre of a sound. With motors we will use this message to control the power used to engage the motor. In the code below the velocity message is mapped to a PWM value to control the effective voltage sent to the motor. Another way to control this for pulsing motors (i.e. solenoids) is to control the "on time" of the pulse. A short pulse will result in less velocity than a long pulse.
The code
Download the code here.
This zip file has 3 Arduino sketches
- musicBotsPulse – use for solenoids
- musicBotsSustain – use for DC / Vibration motors
- simpleMidiOutput – demonstrates the basics of using a Teensy as a MIDI output device.


text:
Below are a number of Kent Wedding Photography useful articles I have written to help you when it comes to different considerations for your wedding day. As and when new articles are written, I will add them to the list below.
Please check out my Wedding Photography Gallery for a selection of my favourite wedding photographs or for latest work visit my Blog Page.