VK WorkSpace Federation Enables Secure Multi-Organization On-Premise Messaging Without Infrastructure Merge
VK Tech has introduced federation support for VK WorkSpace that links separate On-Premise installations while ensuring each organization retains complete sovereignty over its servers, databases, and security policies.
The solution addresses the common requirement for project teams to communicate with contractors, partners, and subsidiary companies without moving work conversations to public services. In the initial November 2025 pilot, two installations could exchange messages after one side issued an invitation and the other confirmed the trust relationship. The July 2026 release 26.2 removed the pairwise limitation, allowing a single group chat to include participants from multiple independent On-Premise environments.
Access is governed at two levels. First, a mutual trust is established between installations. Second, each administrator explicitly grants external-communication rights to selected employees for that specific trust. Only approved users see external contacts and can initiate dialogues or join federated group chats. The corporate directory is not replicated; only minimal profile data—name, work email, and organization flag—is shared.
Three architectural approaches were evaluated. A single-host model with proxy access was rejected because loss of the host would break history availability for all other parties. Adoption of the open Matrix protocol was also declined because it would have required extensive remapping of existing entities, rights, and APIs. The chosen design replicates only federation-related objects and events at the application layer so that each installation stores its own copy of permitted messages and files.
This local-replication model delivers several security and operational benefits: data remains under each organization’s control, local DLP, audit, and retention policies continue to apply, and no user session is created in a foreign environment. When a trust is revoked, already-received history stays in the local instance.
Client applications continue to connect exclusively to their own installation. A dedicated federation layer intercepts relevant operations, forwards them through secure gateways, and replays them via the local messenger API on the receiving side. The core messenger logic remains unchanged, although every new feature must still be validated for multi-party federation compatibility.
Extensive dogfooding on internal test stands helped refine both the protocol and the user interface, particularly the hiding of unsupported actions to prevent user errors. The feature is now deployed in production On-Premise environments at several customer sites.
Related articles
Detecting Suspicious Processes in Linux: How to Investigate Unknown Services, Network Connections and Startup Tasks
This practical guide helps Blue Team beginners investigate unexpected resource usage, unknown network connections, and processes that restart after reboot on Linux systems. It explains how to examine running processes with ps and top, identify executable paths via /proc, and review network sockets using ss and lsof without installing additional tools. The article covers checking systemd services with systemctl, reviewing cron jobs and timers, auditing SSH keys, and correlating events from journalctl logs. Emphasis is placed on gathering multiple indicators rather than jumping to conclusions about compromise, as high CPU usage or unfamiliar services can stem from legitimate misconfigurations or maintenance tasks. Readers learn safe evidence preservation steps if suspicious activity is confirmed, including logging observations and avoiding immediate reboots that could destroy forensic data.
TLS Fingerprinting Explained: From Handshakes in TLS 1.2/1.3 to JA3, JA4, HTTP/2 Analysis and uTLS Evasion
The article provides an in-depth examination of how TLS handshakes reveal client identity even before any HTTP data is sent. It traces the evolution from early SSL versions developed by Netscape to modern TLS 1.3, highlighting how elliptic curve cryptography and AEAD ciphers reduced latency while increasing observability challenges for defenders. Detailed breakdowns show why JA3 hashes became unreliable due to GREASE randomization and extension ordering changes, prompting the shift to the more robust JA4+ family that uses sorted, GREASE-resistant blocks for stable fingerprints. The piece also covers HTTP/2 fingerprinting signals and practical tools such as uTLS in Go for mimicking browser TLS stacks and Finch for traffic analysis. Real Wireshark captures of Client Hello packets to GitHub illustrate how Cloudflare and WAF systems detect scripted clients despite matching User-Agent headers. Overall, the content serves as both a historical overview and a hands-on guide for security engineers working on bot mitigation and traffic obfuscation.
Centralized Secret Management: Comparing Eight Tools for DevOps and Spring Boot Applications
The article examines the challenges of managing secrets such as passwords, API tokens, and SSH keys across development, CI/CD pipelines, and production environments. It explains how centralized secret registries solve issues like scattered .env files, outdated credentials, and lack of audit trails while emphasizing that delivery mechanisms to applications must be chosen separately. Key concepts including static versus dynamic credentials, leases, rotation, and machine identities are defined to help teams implement least-privilege access. The review compares Infisical, HashiCorp Vault, OpenBao, Doppler, 1Password CLI, Bitwarden Secrets Manager, Passbolt, and Yandex Lockbox across deployment models, offline support, and integration options. Special attention is given to CLI run commands that avoid plaintext files, Spring Cloud Vault integration, and the trade-offs between SaaS convenience and self-hosted control. Practical recommendations focus on separating developer and machine access as well as development and production environments.
Opera Rolls Out Local AI Processing via WebAI Standard in Opera One Browser
Opera has introduced an early implementation of WebAI, a proposed web standard that enables websites and extensions to run AI models directly on the user's device instead of relying on remote servers. The feature debuts in Opera One and will later expand to Opera GX and Neon. Supported models include Google's Gemma as well as Apple's local foundational model on compatible Mac hardware, with no vendor lock-in. Key capabilities cover text generation, content classification, and analysis of relationships between information fragments. Developers gain the ability to add AI features without building server infrastructure or incurring per-query cloud costs, while users avoid subscriptions to external AI services. All processing occurs locally on an opt-in basis, keeping data off cloud providers, although performance depends on the device's hardware capabilities.