Chrome.socket.* APIs in SecureShell

[Giovanni Pezzino]

Hi there,

I am working on the deprecation of Chrome Apps, and I am currently removing Chrome Apps APIs from WML builds.

While working on the chrome.socket.* APIs, I found that the Secure Shell extensions are in the API allowlist on all platforms.

I am reaching out to understand whether the extensions still require the use of the chrome.socket.* APIs, if the tools are still in use on WML, and if there are any plans to use a different API in the future.

More in general, I'd like to check if the allowlist could be removed.

Many thanks

--

Giovanni Pezzino

Software Engineer

gio...@google.com

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[Mike Frysinger]

your e-mail says chrome.socket.*, but you've linked to chrome.sockets.*.  we migrated off chrome.socket.* to chrome.sockets.* years ago.  they are not the same thing.

https://developer.chrome.com/docs/apps/reference/socket

https://developer.chrome.com/docs/apps/reference/sockets/tcp

i don't recall when exactly, but we don't care about chrome.socket.* if it's still active.

wrt chrome.sockets.*, there's already an internal thread/spreadsheet discussing this in general & for Secure Shell.  yes, it's still actively used.

Secure Shell itself already supports Direct Sockets, and that's been enabled by default in the dev version since Jan 2026.  i could promote that to the stable version since we've received no bug reports about it.

Terminal doesn't yet support Direct Sockets because it was (is?) tied strongly to Isolated Web Apps (IWAs) inside of Chrome itself.  that logic was reworked recently (like in the last quarter), so i (or someone else) need to find time to try and enable it for the Terminal app.

until that happens, the API needs to exist on CrOS at least, and as long as that's the case, i don't think there's value in dropping it from WML.  dropping it on Linux at least would make testing more difficult.

-mike

--
You received this message because you are subscribed to the Google Groups "chromium-hterm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-hter...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/CAJMrbMXXB%3D0FuF3iALsf89-eSbyY0hfS2ntk0aoSaWsQkreqzQ%40mail.gmail.com.

[Giovanni Pezzino]

Hi Mike

thanks for the reply, and apologies for the socket vs sockets confusion.

Based on the API configurations, chrome.socket is not allowlisted for any extension, so it is safe to remove from WML Chromium builds.

However, most of the implementation is reused by chrome.sockets.tcp, chrome.sockets.udp and chrome.sockets.tcpServer APIS, and in minor part by IWA DirectSockets.

As the 3 chrome.sockets.* APIs are allowlisted for the SecureShell extension on all platforms, but IIUC your email, SecureShell has already moved to DirectSockets (caveat the promotion to stable), while the Terminal app is still using the sockets APIs.

If my understanding is correct, and assuming that Terminal is a Chrome App, then I think it would be safe to remove the Chrome App code from WML builds after the promotion lands. In fact, Chrome Apps are already completely blocked from execution in WML.

I am currently removing the code ONLY from WML builds. The full Chrome Apps Deprecation from ChromeOS is scheduled to be completed in 2028Q1.

About the testing on Linux you mention, are you talking about the Terminal app, or the SecureShell extension?

The value of dropping the WML implementations comes from the Chrome teams on WML: they have been requesting the removal of Chrome Apps related code for years, as they are after the simplification of the codebase and the removal of dependencies to simplify adding new features.

Giovanni

[Mike Frysinger]

Secure Shell & Terminal share the same codebase.  there's very little Terminal-specific logic when it comes to SSH.  the vast majority of development happens in Linux, and Terminal is only checked under CrOS as a last step.  which means dropping Linux will significantly impact development/verification.

Terminal is not a Chrome app.  it's a custom WebUI.

which is why i want Terminal migrated to Direct Sockets before considering dropping chrome.sockets.* from WML.

while i understand the general argument of Chrome APIs incurring maintenance cost, wrt Chrome Sockets specifically, i don't think the argument holds.  as you say, a lot of the sockets code is shared, and the folks actually on the hook for maintaining the APIs is low (which includes me), and doesn't see a lot of updates.

-mike

[Giovanni Pezzino]

I do not see a problem in waiting for the Terminal app to migrate to DirectSockets before proceeding with the code removal for WML builds.

Do you already have a timeline in mind for this migration?

[Mike Frysinger]

ah looks like support landed less than a month ago.  i refreshed https://crrev.com/c/7500739 as it seems to work.

since R149 just branched, i think it's fine to land as soon as it's ready.  i'd wait for R150 to hit beta in June to get user feedback, but i don't expect issues.  when we could drop Chrome Sockets entirely for Secure Shell & Terminal.

-mike