Category Archives: Privacy

exploits, malware, microsoft, MicrosoftSucksAss, Open Source, PowerShell, Privacy, Security, surveillance, sysadmin, Win10, Win11, Windows

Welcome to Winutil Documentation!

Welcome to the official documentation for Winutil, your go-to utility for optimizing and managing your Windows environment. Whether you’re an IT professional, power user, or regular user, Winutil provides a comprehensive set of tools to enhance your Windows experience.

Source: Welcome to Winutil Documentation!

coding, NowYouKnow, Privacy, programming, Security

pdf417-android/DriversLicenseKeys.md at master · PDF417/pdf417-android

Keys for obtaining US Driver’s license data

Standard for US Driver’s Licenses defines several different barcode standards with over 80 different fields encoded inside a barcode. Some fields exist on all barcode standards, other exist only on some. To standardize the API, we have structured the fields in the following sections:

  1. Determining Barcode version
  2. Personal data keys
  3. License data keys

Determining Barcode version

USDLScanResult.kDocumentType

Mandatory on all driver’s licenses.

  • All barcodes which are using 3-track magnetic stripe encoding used in the interest of smoothing a transition from legacy documents shall be designated as Magnetic.
  • All barcodes which are using compact encoding compliant with ISO/IEC 18013-2 shall be designated as Compact.
  • All barcodes (majority) compliant with Mandatory PDF417 Bar Code of the American Association of Motor Vehicle Administrators (AAMVA) Card Design Standard from AAMVA DL/ID-2000 standard to DL/ID-2013 shall be designated as AAMVA.

USDLScanResult.kStandardVersionNumber

Mandatory on all driver’s licenses.

AAMVA Version Number

This is a decimal value between 00 and 99 that specifies the version level of the PDF417 bar code format. Version “0” and “00” is reserved for bar codes printed to the specification of the American Association of Motor Vehicle Administrators (AAMVA) prior to the adoption of the AAMVA DL/ID-2000 standard.

  • All bar codes compliant with the AAMVA DL/ID-2000 standard are designated Version 01.
  • All barcodes compliant with AAMVA Card Design Specification version 1.0, dated 09-2003 shall be designated Version 02.
  • All barcodes compliant with AAMVA Card Design Specification version 2.0, dated 03-2005 shall be designated Version 03
  • All barcodes compliant with AAMVA Card Design Standard version 1.0, dated 07-2009 shall be designated Version 04
  • All barcodes compliant with AAMVA Card Design Standard version 1.0, dated 07-2010 shall be designated Version 05
  • All barcodes compliant with AAMVA Card Design Standard version 1.0, dated 07- 2011 shall be designated Version 06
  • All barcodes compliant with AAMVA Card Design Standard version 1.0, dated 06-2012 shall be designated Version 07
  • All barcodes compliant with AAMVA Card Design Standard version 1.0, dated 08-2013 shall be designated Version 08

Should a need arise requiring major revision to the format, this field provides the means to accommodate additional revision.

If document type is not “AAMVA”, this field defines version number of the given document type’s standard.

Personal data keys

USDLScanResult.kCustomerFamilyName

  • Mandatory on all AAMVA, Magnetic and Compact barcodes.

Family name of the cardholder. (Family name is sometimes also called “last name” or “surname.”). Collect full name for record, print as many characters as possible on portrait side of DL/ID.

USDLScanResult.kCustomerFirstName

  • Mandatory on all AAMVA, Magnetic and Compact barcodes

First name of the cardholder.

USDLScanResult.kCustomerFullName

  • Mandatory on all AAMVA, Magnetic and Compact barcodes.

Full name of the individual holding the Driver License or ID. This field contains four portions, separated with the delimiter ,:

  • Last Name (required)
  • delimiter (required)
  • First Name (required)
  • delimiter (required if other name portions follow, otherwise optional)
  • Middle Name(s) (optional)
  • delimiter (required if other name portions follow, otherwise optional)
  • Suffix Code (optional)
  • delimiter (optional)

USDLScanResult.kDateOfBirth

  • Mandatory on all AAMVA, Magnetic and Compact barcodes

Date on which the cardholder was born. (MMDDCCYY format)

USDLScanResult.kSex

  • Mandatory on all AAMVA and Magnetic barcodes
  • Optional on Compact encoding barcodes.

Gender of the cardholder.

  • Possible values and interpretations:
    • 1 = male
    • 2 = female

USDLScanResult.kEyeColor

  • Mandatory on AAMVA 02, 03, 04, 05, 06, 07, 08
  • Optional on AAMVA 01, Magnetic and Compact barcodes

Color of cardholder’s eyes.

  • Possible values and interpretations:
    • BLK = Black
    • BLU = Blue
    • BRO = Brown
    • GRY = Gray
    • GRN = Green
    • HAZ = Hazel
    • MAR = Maroon
    • PNK = Pink
    • DIC = Dichromatic
    • UNK = Unknown

USDLScanResult.kAddressStreet

  • Mandatory on all AAMVA and Magnetic barcodes
  • Not defined on Compact encoding, where you must use USDLScanResult.kFullAddress.

Street portion of the cardholder address. The place where the registered driver of a vehicle (individual or corporation) may be contacted such as a house number, street address etc.

USDLScanResult.kAddressCity

  • Mandatory on all AAMVA and Magnetic barcodes
  • Not defined on Compact encoding, where you must use USDLScanResult.kFullAddress.

City portion of the cardholder address.

USDLScanResult.kAddressJurisdictionCode

  • Mandatory on all AAMVA and Magnetic barcodes
  • Not defined on Compact encoding, where you must use USDLScanResult.kFullAddress.

State portion of the cardholder address.

USDLScanResult.kAddressPostalCode

  • Mandatory on all AAMVA and Magnetic barcodes
  • Not defined on Compact encoding, where you must use USDLScanResult.kFullAddress.

Postal code portion of the cardholder address in the U.S. and Canada. If the trailing portion of the postal code in the U.S. is not known, zeros will be used to fill the trailing set of numbers up to nine (9) digits.

USDLScanResult.kFullAddress

  • Mandatory on all AAMVA and Magnetic barcodes.
  • Optional on Compact barcodes.

Full address of the individual holding the Driver License or ID. The full address field contains up to four portions, separated with the , delimiter:

  • Street Address (required)
  • , (required if other address portions follow, otherwise optional)
  • City (optional)
  • , (required if other address portions follow, otherwise optional)
  • Jurisdiction Code (optional)
  • , (required if other address portions follow, otherwise optional)
  • ZIP – Postal Code (optional)

USDLScanResult.kHeight

  • Mandatory on AAMVA version 02, 03, 04, 05, 06, 07, 08 and Compact barcodes.
  • Optional on AAMVA version 01 and Magnetic barcodes.

Height of cardholder, either in Inches or in Centimeters.

  • Inches (in):
    • number of inches followed by  in. Example. 6'1'' = 73 in
  • Centimeters (cm):
    • number of centimeters followed by  cm. Example. 181 centimeters = 181 cm

USDLScanResult.kHeightIn

  • Mandatory on AAMVA 02, 03, 04, 05, 06, 07, 08 and Compact barcodes.
  • Optional on AAMVA 01 and Magnetic barcodes

Height of cardholder in Inches.

Example: 5'9'' = 69

USDLScanResult.kHeightCm

  • Mandatory on AAMVA 02, 03, 04, 05, 06, 07, 08 Compact barcodes.
  • Optional on AAMVA 01 and Magnetic barcodes.

Height of cardholder in centimeters.

Example 180 Centimeters = 180

USDLScanResult.kCustomerMiddleName

  • Mandatory on AAMVA version 04, 05, 06, 07, 08
  • Optional on AAMVA 01, 02, 03, Magnetic and Compcat barcodes.

Middle name(s) of the cardholder. In the case of multiple middle names they shall be separated by space.

USDLScanResult.kHairColor

  • Optional on all AAMVA. Magnetic and Compact barcodes

Bald, black, blonde, brown, gray, red/auburn, sandy, white, unknown. If the issuing jurisdiction wishes to abbreviate colors, the three-character codes provided in ANSI D20 must be used.

  • Possible values and interpretations:
    • BAL = Bald
    • BLK = Black
    • BLN = Blond
    • BRO = Brown
    • GRY = Grey
    • RED = Red/Auburn
    • SDY = Sandy
    • WHI = White
    • UNK = Unknown

USDLScanResult.kNameSuffix

  • Mandatory on AAMVA 02 barcodes.
  • Optional on AAMVA 01, 03, 04, 05, 06, 07, 08, Magnetic and Compact barcodes.

Name Suffix (If jurisdiction participates in systems requiring name suffix (PDPS, CDLIS, etc.), the suffix must be collected and displayed on the DL/ID and in the MRT).

  • Possible values and interpretations:
    • JR = Junior
    • SR = Senior
    • 1ST or I = First
    • 2ND or II = Second
    • 3RD or III = Third
    • 4TH or IV = Fourth
    • 5TH or V = Fifth
    • 6TH or VI = Sixth
    • 7TH or VII = Seventh
    • 8TH or VIII = Eighth
    • 9TH or IX = Ninth

USDLScanResult.kAKAFullName

  • Optional on all AAMVA and Compact barcodes.

Other name by which cardholder is known. ALTERNATIVE NAME(S) of the individual holding the Driver License or ID. FORMAT same as defined in ANSI D20 Data Dictionary. (Lastname,Firstname,MI, suffix if any.)

This field contains four portions, separated with the delimiter ,:

  • Last Name (required)
  • delimiter , (required)
  • First Name (required)
  • delimiter , (required if other name portions follow, otherwise optional)
  • Middle Name(s) (optional)
  • delimiter , (required if other name portions follow, otherwise optional)
  • Suffix Code (optional)
  • delimiter , (optional)

USDLScanResult.kAKAFamilyName

  • Optional on all AAMVA and Compact barcodes
  • Not defined on Magnetic barcodes

Other family name by which cardholder is known.

USDLScanResult.kAKAGivenName

  • Optional on all AAMVA and Compact barcodes.
  • Not defined on Magnetic barcodes

Other given name by which cardholder is known

USDLScanResult.kAKASuffixName

  • Optional on all AAMVA and Compact barcodes.
  • Not defined on Magnetic barcodes

Other suffix by which cardholder is known. The Suffix Code Portion, if submitted, can contain only the Suffix Codes shown in below (e.g., Andrew Johnson, III = JOHNSON@ANDREW@@3RD).

Possible values and interpretations

  • JR = Junior
  • SR = Senior or Esquire
  • 1ST = First
  • 2ND = Second
  • 3RD = Third
  • 4TH = Fourth
  • 5TH = Fifth
  • 6TH = Sixth
  • 7TH = Seventh
  • 8TH = Eighth
  • 9TH = Ninth

USDLScanResult.kWeightRange

  • Mandatory on AAMVA 02 barcodes.
  • Optional on AAMVA 01, 03, 04, 05, 06, 07, 08, Magnetic and Compact barcodes.

Indicates the approximate weight range of the cardholder:

Possible values and interpretations:

  • 0 = up to 31 kg (up to 70 lbs)
  • 1 = 32 – 45 kg (71 – 100 lbs)
  • 2 = 46 – 59 kg (101 – 130 lbs)
  • 3 = 60 – 70 kg (131 – 160 lbs)
  • 4 = 71 – 86 kg (161 – 190 lbs)
  • 5 = 87 – 100 kg (191 – 220 lbs)
  • 6 = 101 – 113 kg (221 – 250 lbs)
  • 7 = 114 – 127 kg (251 – 280 lbs)
  • 8 = 128 – 145 kg (281 – 320 lbs)
  • 9 = 146+ kg (321+ lbs)

USDLScanResult.kWeightPounds

  • Mandatory on AAMVA 02 barcodes.
  • Optional on AAMVA 01, 03, 04, 05, 06, 07, 08, Magnetic and Compact barcodes.

Cardholder weight in pounds Ex. 185 lb = 185

USDLScanResult.kWeightKilograms

  • Mandatory on AAMVA 02 barcodes.
  • Optional on AAMVA 01, 03, 04, 05, 06, 07, 08, Magnetic and Compact barcodes.

Cardholder weight in kilograms Ex. 84 kg = 084

USDLScanResult.kCustomerIdNumber

  • Mandatory on all AAMVA and Compact barcodes
  • Not defined on Magnetic barcodes

The number assigned or calculated by the issuing authority.

USDLScanResult.kFamilyNameTruncation

  • Mandatory on AAMVA 04, 05, 06, 07, 08 barcodes.
  • Optional on Compact barcodes.

A code that indicates whether a field has been truncated (T), has not been truncated (N), or unknown whether truncated (U).

USDLScanResult.kFirstNameTruncation

  • Mandatory on AAMVA 04, 05, 06, 07, 08 barcodes.
  • Optional on Compact barcodes.

A code that indicates whether a field has been truncated (T), has not been truncated (N), or unknown whether truncated (U).

USDLScanResult.kMiddleNameTruncation

  • Mandatory on AAMVA 04, 05, 06, 07, 08

A code that indicates whether a field has been truncated (T), has not been truncated (N), or unknown whether truncated (U).

USDLScanResult.kPlaceOfBirth

  • Optional on AAMVA 02, 03, 04, 05, 06, 07, 08 and Compact barcodes
  • Not defined on Magnetic barcodes

Country and municipality and/or state/province

USDLScanResult.kAddressStreet2

  • Optional on all AAMVA barcodes
  • Not defined on Compact encoding, where you must use USDLScanResult.kFullAddress.

Second line of street portion of the cardholder address.

USDLScanResult.kRaceEthnicity

  • Optional on AAMVA 02, 03, 04, 05, 06, 07, 08 and Compact barcodes

Codes for race or ethnicity of the cardholder, as defined in ANSI D20.

Possible values and interpretations:

  • Race
    • AI = Alaskan or American Indian (Having Origins in Any of The Original Peoples of North America, and Maintaining Cultural Identification Through Tribal Affiliation of Community Recognition)
    • AP = Asian or Pacific Islander (Having Origins in Any of the Original Peoples of the Far East, Southeast Asia, or Pacific Islands. This Includes China, India, Japan, Korea, the Philippines Islands, and Samoa)
    • BK = Black (Having Origins in Any of the Black Racial Groups of Africa)
    • W = White (Having Origins in Any of The Original Peoples of Europe, North Africa, or the Middle East)
  • Ethnicity
    • H = Hispanic Origin (A Person of Mexican, Puerto Rican, Cuban, Central or South American or Other Spanish Culture or Origin, Regardless of Race)
    • O = Not of Hispanic Origin (Any Person Other Than Hispanic)
    • U = Unknown

USDLScanResult.kNamePrefix

  • Optional on AAMVA 01

PREFIX to Driver Name. Freeform as defined by issuing jurisdiction.

USDLScanResult.kCountryIdentification

  • Mandatory on AAMVA 02, 03, 04, 05, 06, 07, 08 and Compact barcodes

Country in which DL/ID is issued.

Possible values and interpretations:

  • USA = United States
  • CAN = Canada

USDLScanResult.kResidenceStreetAddress

  • Optional on AAMVA version 01.

Driver Residence Street Address 1.

USDLScanResult.kResidenceStreetAddress2

  • Optional on AAMVA version 01.

Driver Residence Street Address 2.

USDLScanResult.kResidenceCity

  • Optional on AAMVA version 01.

Driver Residence City

USDLScanResult.kResidenceJurisdictionCode

  • Optional on AAMVA version 01.

Driver Residence Jurisdiction Code.

USDLScanResult.kResidencePostalCode

  • Optional on AAMVA version 01.

Driver Residence Postal Code.

USDLScanResult.kResidenceFullAddress

  • Optional on AAMVA 01 barcodes.

Full residence address of the individual holding the Driver License or ID. The full address field contains up to four portions, separated with the , delimiter:

  • Residence Street Address (required)
  • , (required if other address portions follow, otherwise optional)
  • Residence City (optional)
  • , (required if other address portions follow, otherwise optional)
  • Residence Jurisdiction Code (optional)
  • , (required if other address portions follow, otherwise optional)
  • Residence ZIP – Residence Postal Code (optional)

USDLScanResult.kUnder18

  • Optional on AAMVA 05, 06, 07, 08

Date on which the cardholder turns 18 years old. (MMDDCCYY format)

USDLScanResult.kUnder19

  • Optional on AAMVA 05, 06, 07, 08

Date on which the cardholder turns 19 years old. (MMDDCCYY format)

USDLScanResult.kUnder21

  • Optional on AAMVA 05, 06, 07, 08

Date on which the cardholder turns 21 years old. (MMDDCCYY format)

USDLScanResult.kSocialSecurityNumber

  • Optional on AAMVA version 01.

The number assigned to an individual by the Social Security Administration.

USDLScanResult.kAKASocialSecurityNumber

  • Optional on AAMVA version 01.

Driver “AKA” Social Security Number. Format same as driver social security number. Alternative numbers(s) used as SS NUM.

USDLScanResult.kAKAMiddleName

  • Optional on AAMVA 01
  • Not defined in other standards

ALTERNATIVE MIDDLE NAME(s) or INITIALS of the individual holding the Driver License or ID. Hyphenated names acceptable, spaces between names acceptable, but no other use of special symbols

USDLScanResult.kAKAPrefixName

  • Optional on AAMVA 01
  • Not defined in other standards

ALTERNATIVE PREFIX to Driver Name. Freeform as defined by issuing jurisdiction.

USDLScanResult.kOrganDonor

  • Optional on AAMVA 01, 06, 07, 08
  • Not defined in other standards

Field that indicates that the cardholder is an organ donor.

Possible values and interpretations:

  • 1 – cardholder is an organ donor
  • anything else – cardholder is not an organ donor

USDLScanResult.kVeteran

  • Optional on AAMVA 07, 08

Field that indicates that the cardholder is a veteran.

Possible values and interpretations:

  • 1 – cardholder is a veteran
  • anything else – cardholder is not a veteran

USDLScanResult.kAKADateOfBirth

  • Optional on AAMVA 01

ALTERNATIVE DATES(S) given as date of birth. (MMDDCCYY format)

License data keys

USDLScanResult.kIssuerIdentificationNumber

  • Mandatory on all AAMVA, Magnetic and Compact barcodes.

This number uniquely identifies the issuing jurisdiction and can be obtained by contacting the ISO Issuing Authority (AAMVA)

USDLScanResult.kDocumentExpirationDate

  • Mandatory on all AAMVA, Magnetic and Compact barcodes.

If document is non expiring than Non expiring is written in this field.

Date on which the driving and identification privileges granted by the document are no longer valid. (MMDDCCYY format)

USDLScanResult.kJurisdictionVersionNumber

  • Mandatory on all AAMVA and Compact barcodes
  • Optional on Magnetic barcodes

Jurisdiction Version Number

This is a decimal value between 00 and 99 that specifies the jurisdiction version level of the PDF417 bar code format.

Notwithstanding iterations of this standard, jurisdictions implement incremental changes to their bar codes, including new jurisdiction-specific data, compression algorithms for digitized images, digital signatures, or new truncation conventions used for names and addresses. Each change to the bar code format within each AAMVA version (above) must be noted, beginning with Jurisdiction Version 00.

USDLScanResult.kJurisdictionVehicleClass

  • Mandatory on all AAMVA and Magnetic barcodes.
  • Not defined on Compact encoding, which has no compatible field.

Jurisdiction-specific vehicle class / group code, designating the type of vehicle the cardholder has privilege to drive.

USDLScanResult.kJurisdictionRestrictionCodes

  • Mandatory on all AAMVA barcodes.
  • Optional on Magnetic barcodes.
  • Not defined on Compact encoding, which has no compatible field.

Jurisdiction-specific codes that represent restrictions to driving privileges (such as airbrakes, automatic transmission, daylight only, etc.).

USDLScanResult.kJurisdictionEndorsementCodes

  • Mandatory on all AAMVA barcodes.
  • Optional on Magnetic barcodes.
  • Not defined on Compact encoding, which has no compatible field.

Jurisdiction-specific codes that represent additional privileges granted to the cardholder beyond the vehicle class (such as transportation of passengers, hazardous materials, operation of motorcycles, etc.).

USDLScanResult.kDocumentIssueDate

  • Mandatory on all AAMVA and Compact barcodes.

Date on which the document was issued. (MMDDCCYY format).

USDLScanResult.kFederalCommercialVehicleCodes

  • Mandatory on AAMVA versions 02 and 03.

Federally established codes for vehicle categories, endorsements, and restrictions that are generally applicable to commercial motor vehicles. If the vehicle is not a commercial vehicle, NONE is to be entered.

USDLScanResult.kIssuingJurisdiction

  • Mandatory on Compact barcodes
  • Optional on all AAMVA barcodes.

Jurisdictions may define a subfile to contain jurisdiction-specific information. These subfiles are designated with the first character of Z and the second character is the first letter of the jurisdiction’s name.

For example, ZC would be the designator for a California or Colorado jurisdiction-defined subfile; ZQ would be the designator for a Quebec jurisdiction-defined subfile. In the case of a jurisdiction-defined subfile that has a first letter that could be more than one jurisdiction (e.g. California, Colorado, Connecticut) then other data, like the USDLScanResult.kIssuerIdentificationNumber, USDLScanResult.kAddressJurisdictionCode or USDLScanResult.kFullAddress must be examined to determine the jurisdiction.

USDLScanResult.kStandardVehicleClassification

  • Mandatory on Compact barcodes
  • Optional on all AAMVA barcodes.

Standard vehicle classification code(s) for cardholder. This data element is a placeholder for future efforts to standardize vehicle classifications.

USDLScanResult.kIssuingJurisdictionName

  • Optional on all AAMVA and Magnetic barcodes

Name of issuing jurisdiction. For example: Alabama, Alaska, …

USDLScanResult.kStandardEndorsementCode

  • Optional on all AAMVA barcodes.

Standard endorsement code(s) for cardholder. See codes in D20. This data element is a placeholder for future efforts to standardize endorsement codes.

Possible values and interpretations:

  • H
    • Hazardous Material
    • This endorsement is required for the operation of any vehicle transporting hazardous materials requiring placarding, as defined by U.S. Department of Transportation regulations.
  • L
    • Motorcycles
    • Mopeds
    • Motorized Bicycles.
  • N
    • Tank
    • This endorsement is required for the operation of any vehicle transporting, as its primary cargo, any liquid or gaseous material within a tank attached to the vehicle.
  • O
    • Other Jurisdiction Specific Endorsement(s)
    • This code indicates one or more additional jurisdiction assigned endorsements.
  • P
    • Passenger
    • This endorsement is required for the operation of any vehicle used for transportation of sixteen or more occupants, including the driver.
  • S
    • School Bus
    • This endorsement is required for the operation of a school bus. School bus means a CMV used to transport pre-primary, primary, or secondary school students from home to school, from school to home, or to and from school sponsored events. School bus does not include a bus used as common carrier (49 CRF 383.5).
  • T
    • Doubles/Triples
    • This endorsement is required for the operation of any vehicle that would be referred to as a double or triple.
  • X
    • Combined Tank/HAZ-MAT
    • This endorsement may be issued to any driver who qualifies for both the N and H endorsements.

USDLScanResult.kStandardRestrictionCode

  • Optional on all AAMVA barcodes
  • Not defined on Compact barcodes, which have no compatible field.

Standard restriction code(s) for cardholder. See codes in D20. This data element is a placeholder for future efforts to standardize restriction codes.

Possible values and interpretations:

  • B = Corrective Lenses
  • C = Mechanical Devices (Special Brakes, Hand Controls, or Other Adaptive Devices)
  • D = Prosthetic Aid
  • E = Automatic Transmission
  • F = Outside Mirror
  • G = Limit to Daylight Only
  • H = Limit to Employment
  • I = Limited Other
  • J = Other
  • K = CDL Intrastate Only
  • L = Vehicles without air brakes
  • M = Except Class A bus
  • N = Except Class A and Class B bus
  • O = Except Tractor-Trailer
  • V = Medical Variance Documentation Required
  • W = Farm Waiver

USDLScanResult.kJurisdictionVehicleClassificationDescription

  • Optional on AAMVA 02, 03, 04, 05, 06, 07, 08 and Compact barcodes

Text that explains the jurisdiction-specific code(s) for classifications of vehicles cardholder is authorized to drive.

USDLScanResult.kJurisdictionEndorsmentCodeDescription

  • Optional on AAMVA 02, 03, 04, 05, 06, 07, 08 and Compact barcode

Text that explains the jurisdiction-specific code(s) that indicates additional driving privileges granted to the cardholder beyond the vehicle class.

USDLScanResult.kJurisdictionRestrictionCodeDescription

  • Optional on AAMVA 02, 03, 04, 05, 06, 07, 08 and Compact barcodes

Text describing the jurisdiction-specific restriction code(s) that curtail driving privileges.

USDLScanResult.kInventoryControlNumber

  • Optional on AAMVA 02, 03, 04, 05, 06, 07, 08 barcodes

A string of letters and/or numbers that is affixed to the raw materials (card stock, laminate, etc.) used in producing driver licenses and ID cards. (DHS recommended field)

USDLScanResult.kCardRevisionDate

  • Optional on AAMVA 04, 05, 06, 07, 08 and Compact barcodes

DHS required field that indicates date of the most recent version change or modification to the visible format of the DL/ID (MMDDCCYY format)

USDLScanResult.kDocumentDiscriminator

  • Mandatory on AAMVA 02, 03, 04, 05, 06, 07, 08 and Magnetic barcodes
  • Optional and Compact barcodes

Number must uniquely identify a particular document issued to that customer from others that may have been issued in the past. This number may serve multiple purposes of document discrimination, audit information number, and/or inventory control.

USDLScanResult.kLimitedDurationDocument

  • Optional on AAMVA 04, 05, 06, 07, 08 and Compact barcodes

DHS required field that indicates that the cardholder has temporary lawful status.

Possible values and interpretations:

  • 1 – cardholder has temporary lawful status
  • anything else – cardholder does not have temporary lawful status

USDLScanResult.kAuditInformation

  • Optional on AAMVA 02, 03, 04, 05, 06, 07, 08 and Compact barcodes

A string of letters and/or numbers that identifies when, where, and by whom a driver license/ID card was made. If audit information is not used on the card or the MRT, it must be included in the driver record.

USDLScanResult.kComplianceType

  • Optional on AAMVA 04, 05, 06, 07, 08 and Compact barcodes

DHS required field that indicates compliance.

Possible values and interpretations:

  • M = materially compliant
  • F = fully compliant
  • N = non-compliant.

USDLScanResult.kIssueTimestamp

  • Optional on AAMVA version 01.

Issue Timestamp. A string used by some jurisdictions to validate the document against their data base.

USDLScanResult.kPermitExpirationDate

  • Optional on AAMVA version 01.

Driver Permit Expiration Date. MMDDCCYY format. Date permit expires.

USDLScanResult.kPermitIdentifier

  • Optional on AAMVA version 01.

Type of permit.

USDLScanResult.kPermitIssueDate

  • Optional on AAMVA version 01.

Driver Permit Issue Date. MMDDCCYY format. Date permit was issued.

USDLScanResult.kNumberOfDuplicates

  • Optional on AAMVA version 01.

Number of duplicate cards issued for a license or ID if any.

USDLScanResult.kHAZMATExpirationDate

  • Optional on AAMVA 04, 05, 06, 07, 08 and Compact Encoding

Date on which the hazardous material endorsement granted by the document is no longer valid. (MMDDCCYY format)

USDLScanResult.kMedicalIndicator

  • Optional on AAMVA version 01.

Medical Indicator/Codes. STATE SPECIFIC. Freeform; Standard “TBD”

USDLScanResult.kNonResident

  • Optional on AAMVA version 01.

Non-Resident Indicator. Y. Used by some jurisdictions to indicate holder of the document is a non-resident.

USDLScanResult.kUniqueCustomerId

  • Optional on AAMVA version 01.

A number or alphanumeric string used by some jurisdictions to identify a “customer” across multiple data bases.

USDLScanResult.kDataDiscriminator

  • Optional on compact encoding.

Document discriminator.

USDLScanResult.kDocumentExpirationMonth

  • Optional on Magnetic barcodes

Date on which the driving and identification privileges granted by the document are no longer valid. (MMYY format)

USDLScanResult.kDocumentNonexpiring

  • Optional on Magnetic barcodes

Field that indicates that the driving and identification privileges granted by the document are nonexpiring.

  • Possible values and interpretations:
    • 1 – document is nonexpiring
    • anything else – document expires at given date (see USDLScanResult.kDocumentExpirationMonth and USDLScanResult.kDocumentExpirationDate)

USDLScanResult.kSecurityVersion

  • Optional on Magnetic barcodes

Security version beeing used.

Source: pdf417-android/DriversLicenseKeys.md at master · PDF417/pdf417-android

Browser, DNS, Privacy, Security, thunderbird

Inside Firefox’s DOH engine | daniel.haxx.se

INSIDE FIREFOX’S DOH ENGINE

  14 COMMENTS

DNS over HTTPS (DOH) is a feature where a client shortcuts the standard native resolver and instead asks a dedicated DOH server to resolve names.

Compared to regular unprotected DNS lookups done over UDP or TCP, DOH increases privacy, security and sometimes even performance. It also makes it easy to use a name server of your choice for a particular application instead of the one configured globally (often by someone else) for your entire system.

DNS over HTTPS is quite simply the same regular DNS packets (RFC 1035 style) normally sent in clear-text over UDP or TCP but instead sent with HTTPS requests. Your typical DNS server provider (like your ISP) might not support this yet.

To get the finer details of this concept, check out Lin Clark’s awesome cartoon explanation of DNS and DOH.

This new Firefox feature is planned to get ready and ship in Firefox release 62 (early September 2018). You can test it already now in Firefox Nightly by setting preferences manually as described below.

This article will explain some of the tweaks, inner details and the finer workings of the Firefox TRR implementation (TRR == Trusted Recursive Resolver) that speaks DOH.

Preferences

All preferences (go to “about:config”) for this functionality are located under the “network.trr” prefix.

network.trr.mode – set which resolver mode you want.

0 – Off (default). use standard native resolving only (don’t use TRR at all)
1 – Race native against TRR. Do them both in parallel and go with the one that returns a result first.
2 – TRR first. Use TRR first, and only if the name resolve fails use the native resolver as a fallback.
3 – TRR only. Only use TRR. Never use the native (after the initial setup).
4 – Shadow mode. Runs the TRR resolves in parallel with the native for timing and measurements but uses only the native resolver results.
5 – Explicitly off. Also off, but selected off by choice and not default.

network.trr.uri – (default: none) set the URI for your DOH server. That’s the URL Firefox will issue its HTTP request to. It must be a HTTPS URL (non-HTTPS URIs will simply be ignored). If “useGET” is enabled, Firefox will append “?ct&dns=….” to the URI when it makes its HTTP requests. For the default POST requests, they will be issued to exactly the specified URI.

“mode” and “uri” are the only two prefs required to set to activate TRR. The rest of them listed below are for tweaking behavior.

We list some publicly known DOH servers here. If you prefer to, it is easy to setup and run your own.

network.trr.credentials – (default: none) set credentials that will be used in the HTTP requests to the DOH end-point. It is the right side content, the value, sent in the Authorization: request header. Handy if you for example want to run your own public server and yet limit who can use it.

network.trr.wait-for-portal – (default: true) this boolean tells Firefox to first wait for the captive portal detection to signal “okay” before TRR is used.

network.trr.allow-rfc1918 – (default: false) set this to true to allow RFC 1918 private addresses in TRR responses. When set false, any such response will be considered a wrong response that won’t be used.

network.trr.useGET – (default: false) When the browser issues a request to the DOH server to resolve host names, it can do that using POST or GET. By default Firefox will use POST, but by toggling this you can enforce GET to be used instead. The DOH spec says a server MUST support both methods.

network.trr.confirmationNS – (default: example.com) At startup, Firefox will first check an NS entry to verify that TRR works, before it gets enabled for real and used for name resolves. This preference sets which domain to check. The verification only checks for a positive answer, it doesn’t actually care what the response data says.

network.trr.bootstrapAddress – (default: none) by setting this field to the IP address of the host name used in “network.trr.uri”, you can bypass using the system native resolver for it. This avoids that initial (native) name resolve for the host name mentioned in the network.trr.uri pref.

network.trr.blacklist-duration – (default: 60) is the number of seconds a name will be kept in the TRR blacklist until it expires and can be tried again. The default duration is one minute. (Update: this has been cut down from previous longer defaults.)

network.trr.request-timeout – (default: 3000) is the number of milliseconds a request to and corresponding response from the DOH server is allowed to spend until considered failed and discarded.

network.trr.early-AAAA – (default: false) For each normal name resolve, Firefox issues one HTTP request for A entries and another for AAAA entries. The responses come back separately and can come in any order. If the A records arrive first, Firefox will – as an optimization – continue and use those addresses without waiting for the second response. If the AAAA records arrive first, Firefox will only continue and use them immediately if this option is set to true.

network.trr.max-fails – (default: 5) If this many DoH requests in a row fails, consider TRR broken and go back to verify-NS state. This is meant to detect situations when the DoH server dies.

network.trr.disable-ECS – (default: true) If set, TRR asks the resolver to disable ECS (EDNS Client Subnet – the method where the resolver passes on the subnet of the client asking the question). Some resolvers will use ECS to the upstream if this request is not passed on to them.

Split-horizon and blacklist

With regular DNS, it is common to have clients in different places get different results back. This can be done since the servers know from where the request comes (which also enables quite a degree of spying) and they can then respond accordingly. When switching to another resolver with TRR, you may experience that you don’t always get the same set of addresses back. At times, this causes problems.

As a precaution, Firefox features a system that detects if a name can’t be resolved at all with TRR and can then fall back and try again with just the native resolver (the so called TRR-first mode). Ending up in this scenario is of course slower and leaks the name over clear-text UDP but this safety mechanism exists to avoid users risking ending up in a black hole where certain sites can’t be accessed. Names that causes such TRR failures are then put in an internal dynamic blacklist so that subsequent uses of that name automatically avoids using DNS-over-HTTPS for a while (see the blacklist-duration pref to control that period). Of course this fall-back is not in use if TRR-only mode is selected.

In addition, if a host’s address is retrieved via TRR and Firefox subsequently fails to connect to that host, it will redo the resolve without DOH and retry the connect again just to make sure that it wasn’t a split-horizon situation that caused the problem.

When a host name is added to the TRR blacklist, its domain also gets checked in the background to see if that whole domain perhaps should be blacklisted to ensure a smoother ride going forward.

Additionally, “localhost” and all names in the “.local” TLD are sort of hard-coded as blacklisted and will never be resolved with TRR. (Unless you run TRR-only…)

TTL as a bonus!

With the implementation of DNS-over-HTTPS, Firefox now gets the TTL (Time To Live, how long a record is valid) value for each DNS address record and can store and use that for expiry time in its internal DNS cache. Having accurate lifetimes improves the cache as it then knows exactly how long the name is meant to work and means less guessing and heuristics.

When using the native name resolver functions, this time-to-live data is normally not provided and Firefox does in fact not use the TTL on other platforms than Windows and on Windows it has to perform some rather awkward quirks to get the TTL from DNS for each record.

Server push

Still left to see how useful this will become in real-life, but DOH servers can push new or updated DNS records to Firefox. HTTP/2 Server Push being responses to requests the client didn’t send but the server thinks the client might appreciate anyway as if it sent requests for those resources.

These pushed DNS records will be treated as regular name resolve responses and feed the Firefox in-memory DNS cache, making subsequent resolves of those names to happen instantly.

Bootstrap

You specify the DOH service as a full URI with a name that needs to be resolved, and in a cold start Firefox won’t know the IP address of that name and thus needs to resolve it first (or use the provided address you can set with network.trr.bootstrapAddress). Firefox will then use the native resolver for that, until TRR has proven itself to work by resolving the network.trr.confirmationNS test domain. Firefox will also by default wait for the captive portal check to signal “OK” before it uses TRR, unless you tell it otherwise.

As a result of this bootstrap procedure, and if you’re not in TRR-only mode, you might still get  a few native name resolves done at initial Firefox startups. Just telling you this so you don’t panic if you see a few show up.

CNAME

The code is aware of CNAME records and will “chase” them down and use the final A/AAAA entry with its TTL as if there were no CNAMEs present and store that in the in-memory DNS cache. This initial approach, at least, does not cache the intermediate CNAMEs nor does it care about the CNAME TTL values.

Firefox currently allows no more than 64(!) levels of CNAME redirections.

about:networking

Enter that address in the Firefox URL bar to reach the debug screen with a bunch of networking information. If you then click the DNS entry in the left menu, you’ll get to see the contents of Firefox’s in-memory DNS cache. The TRR column says true or false for each name if that was resolved using TRR or not. If it wasn’t, the native resolver was used instead for that name.

Private Browsing

When in private browsing mode, DOH behaves similar to regular name resolves: it keeps DNS cache entries separately from the regular ones and the TRR blacklist is then only kept in memory and not persisted to disk. The DNS cache is flushed when the last PB session is exited.

Tools

I wrote up dns2doh, a little tool to create DOH requests and responses with, that can be used to build your own toy server with and to generate requests to send with curl or similar.

It allows you to manually issue a type A (regular IPv4 address) DOH request like this:

$ dns2doh --A --onlyq --raw daniel.haxx.se | \
curl --data-binary @- \
https://dns.cloudflare.com/.well-known/dns \
-H "Content-Type: application/dns-udpwireformat"

I also wrote doh, which is a small stand-alone tool (based on libcurl) that issues requests for the A and AAAA records of a given host name from the given DOH URI.

Why HTTPS

Some people giggle and think of this as a massive layer violation. Maybe it is, but doing DNS over HTTPS makes a lot of sense compared to for example using plain TLS:

  1. We get transparent and proxy support “for free”
  2. We get multiplexing and the use of persistent connections from the get go (this can be supported by DNS-over-TLS too, depending on the implementation)
  3. Server push is a potential real performance booster
  4. Browsers often already have a lot of existing HTTPS connections to the same CDNs that might offer DOH.

Further explained in Patrick Mcmanus’ The Benefits of HTTPS for DNS.

It still leaks the SNI!

Yes, the Server Name Indication field in the TLS handshake is still clear-text, but we hope to address that as well in the future with efforts like encrypted SNI.

Bugs?

File bug reports in Bugzilla! (in “Core->Networking:DNS” please)

If you want to enable HTTP logging and see what TRR is doing, set the environment variable MOZ_LOG component and level to “nsHostResolver:5”. The TRR implementation source code in Firefox lives in netwerk/dns.

Caveats

Credits

While I have written most of the Firefox TRR implementation, I’ve been greatly assisted by Patrick Mcmanus. Valentin Gosu, Nick Hurley and others in the Firefox Necko team.

DOH in curl?

Since I am also the lead developer of curl people have asked. The work on DOH for curl has not really started yet, but I’ve collected some thoughts on how DNS-over-HTTPS could be implemented in curl and the doh tool I mentioned above has the basic function blocks already written.

Other efforts to enhance DNS security

There have been other DNS-over-HTTPS protocols and efforts. Recently there was one offered by at least Google that was a JSON style API. That’s different.

There’s also DNS-over-TLS which shares some of the DOH characteristics, but lacks for example the nice ability to work through proxies, do multiplexing and share existing connections with standard web traffic.

DNScrypt is an older effort that encrypts regular DNS packets and sends them over UDP or TCP.

Source: Inside Firefox’s DOH engine | daniel.haxx.se

Privacy, Security

Quicken 2013 blocks

%ProgramFiles% (x86)\Quicken\BindContent.exe
%ProgramFiles% (x86)\Quicken\RPMMigration\MigrationTool.exe
%ProgramFiles% (x86)\Quicken\QuickenOLBackupLauncher.exe
%ProgramFiles% (x86)\Quicken\qw.exe
%ProgramFiles% (x86)\Quicken\techhelp.exe
%ProgramFiles% (x86)\Quicken\qwul.exe

microsoft, Privacy, Security, sysadmin, Tech, VPN, Win10, Windows

openvpn – How to force all traffic through VPN?

How to force all traffic through OpenVPN

 

Add the following directive to the server configuration file:

push “redirect-gateway def1”

If your VPN setup is over a wireless network, where all clients and the server are on the same wireless subnet, add the local flag:

push “redirect-gateway local def1”

Pushing the redirect-gateway option to clients will cause all IP network traffic originating on client machines to pass through the OpenVPN server. The server will need to be configured to deal with this traffic somehow, such as by NATing it to the internet, or routing it through the server site’s HTTP proxy.

If you want to configure this on the client side, put

redirect-gateway def1

in your client.ovpn file.

Some stuff about things