Glossary

Little Snitch app

The app Little Snitch.app in the Applications folder. Its main window is the Rules window, where you manage rules, blocklists, rule groups, and profiles. The settings are in its Settings window. To open the app, start it from the Applications folder like any other app.

Rules window

The main window of the Little Snitch app. It shows your rules, blocklists, rule groups, and profiles. For a tour of the window, see Rules window.

Network Monitor

The app that shows the connections of your Mac, their traffic, and the locations of the servers on a map. To open it, click the traffic chart in the Control Center. See Network Monitor.

Control Center

The panel that opens when you click the Little Snitch icon in the menu bar. It shows the current network activity and gives you quick access to the operation mode, the profiles, and the network filter. See Control Center.

Connection alert

The window in which Little Snitch asks you to allow or deny a connection. Little Snitch shows it in Alert Mode, when no rule matches a connection. See Connection alert.

Little Snitch Agent

The user component of Little Snitch. macOS starts it for each user at login. It shows the connection alerts and notifications, and it manages the Control Center. See Background items.

Daemon

The system-wide background component of Little Snitch, through which all of its other components communicate. See Background items.

Network Extension

The macOS system extension of Little Snitch that contains the network filter. The network filter applies your rules to connections. You allow the Network Extension in System Settings when you install Little Snitch.

Little Snitch Endpoint Security

An optional system extension of Little Snitch. It controls the access to the Berkeley Packet Filter. You install it separately in Settings > Advanced.

Command line utility

The command littlesnitch, which you use in Terminal. It changes settings, makes backups, and shows information that helps analyze problems. See Command line utility.

IP address

An IP address, sometimes called an “internet address”, is like the phone number of a computer: to send it anything, you need to know it.

In version 4 of the Internet Protocol (IPv4), each computer on the public internet has a unique 32-bit number between 0 and about 4 billion. That’s its IP address. Version 6 (IPv6) has room for many more computers.

To make IP addresses easier to read, they’re written in groups. An IPv4 address has 4 groups of up to 3 digits, separated by dots, for example 78.46.114.187, and each group has a value from 0 to 255. An IPv6 address has 8 groups of up to 4 hexadecimal digits, separated by colons, for example 2a00:1450:4016:801:0000:0000:0000:1013.

Since IPv6 addresses are long, there’s a short form: a run of groups that contain only zeros can be written as a double colon. The example above then becomes 2a00:1450:4016:801::1013. Likewise, 0000:0000:0000:0000:0000:0000:0000:0001 becomes ::1, and an address of only zeros becomes ::.

Port number

A computer can offer many services at once, so its IP address alone isn’t enough to reach a particular one. Each service runs on a port, identified by a 16-bit number from 0 to 65535. In the phone call analogy, the IP address is the phone number of a large company, and the port number is the extension that connects you directly to one person.

Well-known services use well-known port numbers, for example HTTP (websites), HTTPS (secure websites), SMTP (sending email), and SSH (secure shell). The Internet Assigned Numbers Authority (IANA) keeps a long list of well-known services and their assigned port numbers.

Protocol

A protocol is an agreement about how computers exchange data. It defines what an address looks like, for example a 32-bit IP address plus a 16-bit port number, what other information the data contains, in which order the parts travel over the wire, and more. There are connection-oriented protocols, such as TCP, and connectionless protocols, such as UDP.

A connection-oriented protocol works like a phone call. One computer starts the connection (dials the number), and the other accepts it (answers the phone). The connection lasts until one of them closes it (hangs up). While it’s open, either computer can send data at any time (speak), in any format or sub-protocol (language) that they agree on.

A connectionless protocol works more like postal mail or text messages. The sender sends the data in packets to the address of the other computer, and the protocol may or may not tell it whether they arrived. Each packet (letter, message) travels in one direction only. The other computer can send a packet back, but it doesn’t have to.

Internet Protocol (IP)

Protocols are stacked in layers (OSI model), and each layer uses the services of the layers below it. The lowest layer that matters here is the Internet Protocol (IP), which the whole internet is built on. IP defines what IP addresses look like (see above) and how computers send data packets to each other. On its own, it isn’t enough: it always needs another protocol layer on top.

Transmission Control Protocol (TCP)

TCP is a protocol on top of IP. It adds ports, and it carries streams of data in both directions over a connection. If packets get lost on the way, TCP sends them again, so all data arrives, and it arrives in the right order. That’s why almost all services on the internet use TCP, such as web pages, email, and file sharing.

User Datagram Protocol (UDP)

UDP is the smallest addition to IP that makes it useful for apps: it adds ports, but doesn’t make sure that packets arrive, or that they arrive in the right order. Apps use UDP for real-time media such as Voice over IP, and wherever losing a packet is better than waiting for it to be sent again.

Internet Control Message Protocol (ICMP)

ICMP is another small addition to IP, but unlike UDP, it has no port numbers. Apps rarely use it. Mostly, the kernel of the operating system (the IP stack) uses ICMP itself, to control the data transfer of other protocols, for example with “destination port unreachable” messages. The best-known exception is the Unix command ping: it sends an ICMP request to another computer, waits for the response, and shows you both. That’s useful for tracking down network problems.

Domain Name System (DNS)

The Domain Name System translates names such as www.obdev.at into IP addresses, much like a phone book. Before a process can connect to a name, it asks a DNS server (the resolver) for the IP address. This is called a DNS lookup. By default, DNS lookups aren’t encrypted, but Little Snitch can encrypt them. See DNS encryption.

Hostname and domain

A hostname is the name of a single computer on the internet, for example www.obdev.at. A domain is a name together with all names below it: the domain obdev.at includes obdev.at, www.obdev.at, and every other name that ends in .obdev.at. The parts between the dots are called labels. So a rule for a domain matches more servers than a rule for a hostname.

When a process connects, Little Snitch sometimes knows only the IP address. To learn how it finds the hostname, see How hostnames are determined.

Remote endpoint

The part of a rule or of a blocklist entry that says which servers it matches. It’s a pattern, not a server: a hostname, a domain, an IP address or a range of IP addresses, a list of these, a kind of address (local network, multicast, broadcast, Bonjour), the Berkeley Packet Filter, or Any Server. In the rule editor, it’s the setting To:. In short: a connection goes to a server, and the remote endpoint of a rule matches this server. See Remote endpoint.

Global rule

A rule that affects all users of your Mac. Rules for the process owners Anyone and System are global, while rules for Me affect only your own processes. See Process owner.

CIDR notation

CIDR notation (Classless Inter-Domain Routing) is a compact way to write a range of IP addresses: an address, a slash, and the number of leading bits that all addresses in the range share. For example, 192.168.1.0/24 stands for the 256 addresses from 192.168.1.0 to 192.168.1.255, and 10.0.0.0/8 for all addresses that start with 10..

Server Name Indication (SNI)

When a process opens an encrypted connection with TLS, for example for HTTPS, it sends the hostname of the server in its very first message, before the encryption starts. This part of the message is the Server Name Indication. Servers that host many websites on the same IP address need it to know which website is meant. Since the SNI is usually not encrypted, Little Snitch can read the hostname from it.

Deep packet inspection (DPI)

Deep packet inspection examines the content of data packets, not only their addresses. Little Snitch uses it for one thing only: to find a hostname. If it can’t find a unique hostname any other way, it looks at the first request of the connection, for example at the HTTP headers or at the SNI. See How hostnames are determined.

Code signature

A code signature is a cryptographic signature over an executable, such as an app, and all its resources.

On macOS, a code signature contains:

A code signature has two purposes:

  1. It reveals any change to the signed code or resources, malicious or not. A change can happen before the download (on a malicious website), through malware on your Mac (such as a virus), or by you: deleting unused localizations from an app changes it, too.
  2. It shows who really signed the code, usually the developer. The issuer of the certificate “guarantees” to check this identity before it issues a certificate. So if the app does something malicious, a real person or company is accountable.

Learn more about how Little Snitch handles code signatures…

Certificate (in cryptography)

A certificate ties a public key to a set of properties, in a small text file. The issuer, which for code signatures is Apple, confirms that whoever holds the matching private key has these properties, by signing the public key and the properties with a digital signature.

But the issuer’s signature needs a certificate too. Who issues that one? Either another authority, which makes a certificate chain, or nobody: the certificate is signed with its own private key, which makes it a root certificate. Your Mac comes with a list of trusted root certificates, and macOS doesn’t trust root certificates that aren’t on this list.

Code ID

The Code ID identifies the code of a process, wherever it is on disk. Little Snitch derives it from the code signature, usually from the developer’s Team Identifier and the identifier in the signature, for example MLZF7K7B5R/at.obdev.littlesnitch. Rules can refer to a process by its Code ID instead of its path. See Code identity (Code ID).

Notarization

Before developers distribute software outside the Mac App Store, they upload it to Apple, which scans it automatically for malware and for some technical errors. If it passes, Apple issues a ticket for it, which macOS checks before it runs the downloaded software for the first time. This process is called notarization.

App Translocation

A security mechanism of macOS: if an app isn’t properly installed, macOS runs it from a random path, usually somewhere in /private/var/folders/. Rules that refer to the app by its path may then not work. See App Translocation warning.

Internet Access Policy (IAP)

Information that the developer ships with an app: what the app is for, what each of its connections is for, and what happens if you deny a connection. Little Snitch shows it in the connection alert, in Network Monitor, and in the Rules window. See Internet Access Policy.

Private network

A network that uses IP addresses reserved for local use, which routers on the internet don’t forward. Most home and office networks are private networks. The private IPv4 address ranges are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, see Private network. Little Snitch counts connections to these addresses as connections to the local network. To add more address ranges, see Advanced settings.

Apple Location Services

Macs don’t have GPS, so they can’t determine your location directly. But the Wi-Fi networks around you are enough to find it with surprising precision, without knowing any of their passwords.

That takes a database of all Wi-Fi hotspots on earth and their locations. Such a database wouldn’t fit on your Mac, and it would be out of date quickly, because people install, remove, and move hotspots all the time. Apple keeps such a database and offers it online as a service, Apple Location Services.

When you use this service, your Mac sends the technical properties and signal levels of all Wi-Fi stations around you to Apple, and Apple sends back an estimate of your location.

Keep in mind that this lets Apple keep statistics of where you are and which Wi-Fi hotspots are around you.


© 2016-2026 by Objective Development Software GmbH