Direct connect

[backkem]

The goal of this project is to introduce new building blocks for the web in a LAN context. The current spec ties together service discovery and connecting quite heavily. We way want to rewrite this so the service discovery becomes optional. E.g.: if you know the address of what you connect to, you can try to connect directly.

[guest271314]

I have filed several feature requests at implementers and specification issues for what you propose. Unfortunately those issues and feature requests have largey been closed. (TL;DR https://groups.google.com/a/chromium.org/g/web-transport-dev/c/njMLrjHdyLs; https://github.com/guest271314/captureSystemAudio; https://bugs.chromium.org/p/chromium/issues/detail?id=1214621). This is what I am currently doing using API's already shipped with the latest browser, in this case, Chromium, and only using Native Messaging to turn the local server (services; devices; applications; shell scripts) on and off https://github.com/guest271314/NativeTransferableStreams.

[guest271314]

Any progress on this?

[backkem]

I've not been able to get enough eyes on this to get anything moving.

[guest271314]

Native Messaging provides solutions to the requirements.

[guest271314]

One way to connect to localhost from any origin on Chromium 100 is to

1. Remove Content-Security-Policy response header from the site
2. Set localhost Access-Control-Allow-Private-Network: true (https://wicg.github.io/private-network-access/) response header

[guest271314]

See https://github.com/GoogleChrome/developer.chrome.com//blob/main/site/en/blog/private-network-access-preflight/index.md

[guest271314]

Minimal verifiable complete example of directly connecting to localhost on any origin, using a browser extension https://developer.chrome.com/docs/extensions/reference/declarativeNetRequest/

manifest.json

{
  "name": "Remove Content-Security-Policy header",
  "manifest_version": 3,
  "version": "1.0",
  "declarative_net_request" : {
    "rule_resources" : [{
      "id": "ruleset_1",
      "enabled": true,
      "path": "rules_1.json"
    }]
  },
  "permissions": [
    "nativeMessaging",
    "declarativeNetRequest"
  ],
  "host_permissions": [
    "<all_urls>"
  ],
  "author": "guest271314"
}

rules_1.json

[ 
  {
    "id": 1,
    "priority": 1,
    "action": {
      "type": "modifyHeaders",
      "responseHeaders": [
        { 
          "header": "content-security-policy", 
          "operation": "remove" 
        },
        { 
          "header": "content-security-policy-report-only", 
          "operation": "remove" 
        }
      ]
    },
    "condition": { 
      "regexFilter": "^*://*/*", 
      "resourceTypes": [
        "main_frame"
      ] 
    }
  }
]

index.php

<?php 
header("Access-Control-Allow-Origin: *");
header("Access-Control-Allow-Methods: GET, POST");
header("Access-Control-Allow-Headers: Access-Control-Request-Private-Network");
header("Access-Control-Allow-Private-Network: true");
header("Content-Type: application/octet-stream");
header('Vary: Origin');
header("X-Powered-By:");
echo "localhost";
exit();

[guest271314]

After testing both fetch() to localhost from arbitrary sites and using Native Messaging https://github.com/browserext/native-messaging, from my perspective Native Messaging requires at least 1 less step and achieves the requires using less memory consumption.

You can test the two approaches for yourself.