Legacy Application Stats

The application block in the JSON payload provides general information about the given application: label, description, logos, tag name and more. See the application attribute documentation for more information on the JSON payload details.

"application": {
    "id": 120,
    "tag": "netify.twitter",
    "label": "Twitter",
    "full_label": "Twitter",
    "description": "Twitter is a ...",
    "home_page": {
        "url": "https://twitter.com",
        "text": "Twitter"
    },
    "category": {
        "id": 24,
        "tag": "social-media",
        "label": "Social Media"
    },
    "active": true,
    "favicon": "https://static.netify.ai/...",
    "icon": "https://static.netify.ai/...",
    "logo": "https://static.netify.ai/...",
    "favicon_source": "app",
    "icon_source": "app",
    "logo_source": "app"
}

The domain list contains all the domain definitions used to detect an application. For example, the following is a sample of domains used to match the Twitter application:

• t.co
• twimg.com
• twitter.com
• twimg.com.akahost.net
• twitter.map.fastly.net
• etc.

These domains are used to identify application network traffic flows via Netify DPI processing. The hostnames coming from TLS SNI, TLS certificate common names, HTTP headers, DNS requests, DNS hinting, and any hostname that pops out of deep packet inspection are compared to the domain lists.

Please note: for companies with large portfolios of applications, the subdomains can be important differentiators. For example, the googleapis.com domain is part of the Google domain list, but the youtubei.googleapis.com domain is part of Google-owned YouTube domain list.

If a domain belongs to a platform, the metadata is attached to the payload. See the Domain Object documentation for more information on the JSON payload details.

Domain List JSON Overview

"domain_list": [
    {
        "id": 2737771,
        "label": "twimg.com.akahost.net",
        "category": {
            "id": 24,
            "tag": "social-media",
            "label": "Social Media"
        },
        { Platform Object }
    }

Domain List JSON Example

"domain_list": [
    {
        "id": 2737771,
        "label": "twimg.com.akahost.net",
        "category": {
            "id": 24,
            "tag": "social-media",
            "label": "Social Media"
        },
        "platform": {
            "id": 1002,
            "tag": "akamai",
            "label": "Akamai",
            "category": {
                "id": 2,
                "tag": "cdn",
                "label": "CDN"
            },
        }
    },

Some applications run across large network blocks. For example, Microsoft Teams connects to specific network blocks for video conferencing. In these cases, the cidr_list and cidr_type properties will appear in the dataset. The cidr_type will be one of the following three values:

• dedicated
• hosted
• multiproduct

Dedicated: CIDRs in this category are dedicated to serving the application. For example, Telegram CIDRs are not used by any other application -- it's all Telegram.

Hosted: CIDRs in this category are hosting other applications. For example, the Amazon AWS CIDRs can be used to identify all of AWS, but many applications are hosted on his network.

Multiproduct: CIDRs in this category belong to one organization, but are shared amongst different products. For example, the Apple CIDR list will have traffic from the following applications: iCloud, Apple Mail, Apple TV, etc.

If an application does not have any defined CIDR blocks, the cidr_type and cidr_list keys will not exist.

CIDR List and Type JSON Example

"cidr_type": "dedicated",
"cidr_list": [
    {
        "network": "8.25.194.0/23",
        "version": "ipv4"
    },
    {
        "network": "8.25.196.0/23",
        "version": "ipv4"
    },
    ...

The network CIDR list is derived from data provided directly from application vendors, Netify-derived network traffic analysis, and autonomous system number (ASN) definitions. These networks are fairly static, but there are at least a few changes to network CIDR lists every week.

The stats IPs associated with the application are provided in the stats_ip_list part of the payload. The data is derived from Netify DPI network traffic analysis. See adjacent sample.

If an IP belongs to a platform, the metadata is attached to the payload. However, to minimize the size of the payload, a subset of the fields in the platform are provided. See the Platform Object documentation for more information.

Though most IP addresses serving applications are fairly static, IPs do get re-used. For example, most Amazon CloudFront CDN IPs for a specific application can change every week or so. This Application Stats data feed includes historical statistics (90 days) on IPs, including those IPs that are now used by a different application. If you are looking for a list of active IPs, please visit the Application IPs Data Feed page.

It is very common for applications to use shared IPs. Here are three common shared IP scenarios:

• Content delivery networks
• Third party platforms, e.g. a third-party mail services
• Multi-app organizations, e.g. the YouTube and Gmail apps both use shared Google infrastructure

IP List JSON Overview

"stats_ip_list": [
    {
        "address": "13.33.166.245",
        "version": "ipv4",
        "shared": false,
        "shared_score": 5,
        { Platform Object (minified) }
    }
}

IP List JSON Example

"stats_ip_list": [
    {
        "address": "13.33.166.245",
        "version": "ipv4",
        "shared": false,
        "shared_score": 5,
        "platform": {
            "id": 1006,
            "tag": "amazon-cloudfront",
            "label": "Amazon CloudFront",
            "category": {
                "id": 2,
                "tag": "cdn",
                "label": "CDN"
            },
            ...
        }
    },

The protocol_port_stats field provides some basic statistics about the protocols used by the application. Most apps use standard HTTP and HTTPS to communicate with server and web sites. However, IoT devices, TVs, mobile apps, and other examples use other ports and protocols. Here's an example from Blizzard's gaming environment:

You can customize the statistics available for applications. Please contact us for details.

"protocol_port_stats": [
    {
        "protocol_port": {
            "ip_protocol": {
                "id": 6,
                "label": "TCP"
            },
            "protocol": {
                "id": 196,
                "tag": "https",
                "label": "HTTPS"
            },
            "port": 443
        },
        "stats": {
            "flow_percent": "97.28",
            "byte_percent": "99.98",
            "average_bytes_per_flow": 175000
        }
    },
    ...
]