BSD Cafe Billboard

The root of it all is Hola VPN / Luminati (Bright Data's predecessor). In May 2015, it was discovered that Hola — a free "VPN" — was quietly turning users' devices into paid exit nodes sold through a sibling brand, Luminati, at up to $20/GB. The discovery came after 8chan's admin, Frederick Brennan, traced a wave of DDoS/spam attacks against his site back to Hola users being abused as a botnet, and outlets like The Register, Fortune/Motherboard, and TechRadar covered it within days. Hola's Luminati brand was described as "the world's largest VPN network," routing HTTP, HTTPS, or TLS requests through millions of idling end-user devices. Luminati (founded 2014) was Hola's mechanism for selling access to its userbase as exit nodes, charging $20 per gigabyte for bandwidth from its free VPN users, and it later rebranded as Bright Data. So the general "your free app is secretly selling your connection as a proxy" pattern is a 2015 story, not a 2026 one.

The smart-TV-specific angle: February 2026

The TV angle specifically is much newer, and predates the IncludeSecurity teardown by about three and a half months. Independent tech journalist Janko Roettgers broke it in his Lowpass newsletter (syndicated by The Verge) in late February 2026: with Bright's SDK, a viewer's smart TV becomes part of a massive global proxy network that crawls and scrapes the web, alongside apps on desktop PCs and mobile devices, with the company claiming roughly 150 million such residential proxies worldwide, gathering data later resold to train AI models. Multiple later write-ups explicitly credit this as the origin point: "Lowpass, syndicated by The Verge, first surfaced the smart-TV angle in February, and this is the technical teardown."

The AI-scraping tie-in and platform response: 2025–early 2026

Around the same period, the broader AI-scraping-via-residential-proxy story was already building: Krebs reported in October 2025 on botnets like Aisuru fueling large-scale AI data harvesting, and Google dismantled the criminal IPIDEA proxy network in January 2026. By April 2026, FlatpanelsHD was reporting that Amazon, Google and Roku had restricted Bright Data and similar residential proxy networks from their app SDKs (Fire TV, Google TV, Roku OS), while Bright Data continued listing LG's webOS and Samsung's Tizen as partners, with over 200 apps on webOS alone.

Your June 2026 post: the deep technical teardown

The IncludeSecurity/Buchodi post you linked was the first to actually reverse-engineer the SDK rather than just report on the business model — documenting the peer channel's weak authentication and the iOS VPN bypass — which is why it got picked up so widely (Hacker News, Krebs, CyberSecurityNews, etc.) even though the underlying phenomenon was already known.

Aftermath

A follow-up Spur.us platform scan in June 2026 quantified the scale: Bright Data, Bright Data Ltd, and Bright SDK accounted for 367 proxy-flagged apps in their dataset, with residential proxy SDKs found in nearly half of scanned LG webOS apps and over a quarter of Samsung Tizen apps. And just last week, Krebs on Security reported LG moving to ban these SDKs from its smart TV apps entirely.

So the short answer: the general practice (apps quietly monetizing users' devices as residential proxy exit nodes) was first exposed in 2015 with Hola/Luminati; the smart-TV-specific version of that story broke in February 2026 via Lowpass/The Verge; and your June 2026 link is the deep technical forensic follow-up, not the original discovery.

grahamperrin

Here's the title:

above the editing toolbar.

The position is unexpected.

grahamperrin

@tomaoki

Perhaps the title is difficult to perceive when, for example, the screen is busy.

I had this difficulty more than once in the past.

An example:

grahamperrin

https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/ via https://mastodon.social/@bagder/116448188069484288 (2026-04-22) – not recent, but it's news to me.

From today's post about last month's Ottawa FreeBSD Developer Summit:

Michael Winser – Alpha Omega – The Changing Landscape of Open Source Software Security

AI has entered the chat

A frame from Winser's presentation:

Daniel Stenberg on AI in security ― sentiment over time

From Stenberg's blog post:

…

Everything is AI now

Almost every security report now uses AI to various degrees. You can tell by the way they are worded, how the report is phrased and also by the fact that they now easily get very detailed duplicates in ways that can’t be done had they been written by humans.

The difference now compared to before however, is that they are mostly very high quality.

The reporters rarely mention exactly which AI tool or model they used (and really, we don’t care), but the evidence is strong that they used such help.

We are not unique

I did a quick unscientific poll on Mastodon to see if other Open Source projects see the same trends and man, do they! Friends from the following projects confirmed that they too see this trend. …

Additional tag: AI

― #ai is currently not possible in (NodeBB) BSD Cafe Billboard.

grahamperrin

https://wiki.freebsd.org/DevSummit/202606

Reddit posts for five recently published videos

LLM-driven kernel vulnerability research – Nicholas Carlini, Anthropic

Michael Winser – Alpha Omega – The Changing Landscape of Open Source Software Security

AI has entered the chat

FreeBSD Foundation Technology Team Update – Joe Mingrone

AI-assisted Vulnerability Discovery – Ed Maste

The Cloud Exists – Colin Percival and Gordon Tetlow

Originals

https://www.youtube.com/@FreeBSDMeetings

grahamperrin

@CiotBSD said:

⇒ Dev accidentally commits Copilot binary to FreeBSD ports repo

https://mastodon.scot/@kim_harding/116980725539794502 with a link to discussion in r/freebsd.

grahamperrin

@CiotBSD said:

⇒ Anti-AI open source has an enemy in common, but almost nothing else

https://mastodon.bsd.cafe/@grahamperrin/116987441637631045 quotes https://mastodon.social/@buckfiftyseven/116980631827143297 with comments from @lproven@social.vivaldi.net (and I'll have more for @buckfiftyseven@mastodon.social later) …

grahamperrin

@CiotBSD OT = off topic

grahamperrin

No response to normal keyboard or mouse input at ttyv8, so login to a desktop environment is impossible.

Using Virtual Machine Manager to key Ctrl+Alt+F2 (pictured below) does not switch to ttyv1.

Weird.

This machine did previously work.

Comparison

I'm reminded of a bug that sometimes prevents use of vt(4) in VirtualBox, however I doubt that the root causes are the same:

FreeBSD-RELEASE in VirtualBox: vt no longer visible when switching away from a desktop environment at ttyv8 : r/freebsd

grahamperrin

An example

root@freebsd-15-amd64-qemu:~ # pkg upgrade -Fqy
root@freebsd-15-amd64-qemu:~ # pkg upgrade -U
New version of pkg detected; it needs to be installed first.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        pkg: 2.7.5 -> 2.8.0_1 [FreeBSD-ports]

Number of packages to be upgraded: 1

The process will require 25 MiB more space.

Proceed with this action? [y/N]: y
[1/1] Upgrading pkg from 2.7.5 to 2.8.0_1...
[1/1] Extracting pkg-2.8.0_1: 100%
pkg: need to re-create repo FreeBSD-ports to upgrade schema version
pkg: Repository FreeBSD-ports cannot be opened. 'pkg update' required
pkg: need to re-create repo FreeBSD-ports-kmods to upgrade schema version
pkg: Repository FreeBSD-ports-kmods cannot be opened. 'pkg update' required
Checking for upgrades (0 candidates): 100%
Processing candidates (0 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.
root@freebsd-15-amd64-qemu:~ # pkg update
Updating FreeBSD-ports repository catalogue...
pkg: need to re-create repo FreeBSD-ports to upgrade schema version
Fetching meta.conf: 100%     168 B   0.2 kB/s    00:01    
Fetching data: 100%    12 MiB 907.0 kB/s    00:14    
Processing entries: 100%
FreeBSD-ports repository update completed. 38008 packages processed.
Fetching files: 100%    41 MiB   1.3 MB/s    00:33    
Processing file entries: 100%
Updating FreeBSD-ports-kmods repository catalogue...
pkg: need to re-create repo FreeBSD-ports-kmods to upgrade schema version
Fetching meta.conf: 100%     179 B   0.2 kB/s    00:01    
Fetching data: 100%    35 KiB  36.0 kB/s    00:01    
Processing entries: 100%
FreeBSD-ports-kmods repository update completed. 240 packages processed.
All repositories are up to date.
root@freebsd-15-amd64-qemu:~ # pkg upgrade -Fqy
root@freebsd-15-amd64-qemu:~ # pkg upgrade -U
Checking for upgrades (124 candidates): 100%
Processing candidates (124 candidates): 100%
Checking integrity... done (0 conflicting)
The following 123 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        boost-libs: 1.89.0_2 -> 1.89.0_3 [FreeBSD-ports]
        …
        xwud: 1.0.7 -> 1.0.8 [FreeBSD-ports]

Installed packages to be REINSTALLED:
        xorg-docs-1.7.3,1 [FreeBSD-ports] (ABI changed: 'FreeBSD:15:amd64' -> 'FreeBSD:15:*')

Number of packages to be upgraded: 122
Number of packages to be reinstalled: 1

The operation will free 5 MiB.

Proceed with this action? [y/N]: y
[  1/123] Upgrading boost-libs from 1.89.0_2 to 1.89.0_3...
[  1/123] Extracting boost-libs-1.89.0_3: 100%
…
[123/123] Upgrading xwud from 1.0.7 to 1.0.8...
[123/123] Extracting xwud-1.0.8: 100%
==> Running trigger: desktop-file-utils.ucl
Building cache database of MIME types
==> Running trigger: gtk-update-icon-cache.ucl
Generating GTK icon cache for /usr/local/share/icons/oxygen
Generating GTK icon cache for /usr/local/share/icons/breeze-dark
Generating GTK icon cache for /usr/local/share/icons/breeze
Generating GTK icon cache for /usr/local/share/icons/hicolor
==> Running trigger: gdk-pixbuf-query-loaders.ucl
Generating gdk-pixbuf modules cache
==> Running trigger: shared-mime-info.ucl
Building the Shared MIME-Info database cache
==> Running trigger: glib-schemas.ucl
Compiling glib schemas
Warning: Schema “org.gnome.crypto.cache” has path “/desktop/gnome/crypto/cache/”.  Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated.
Warning: Schema “org.gnome.crypto.pgp” has path “/desktop/gnome/crypto/pgp/”.  Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated.
Warning: Schema “org.gnome.system.locale” has path “/system/locale/”.  Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated.
Warning: Schema “org.gnome.system.proxy” has path “/system/proxy/”.  Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated.
Warning: Schema “org.gnome.system.proxy.http” has path “/system/proxy/http/”.  Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated.
Warning: Schema “org.gnome.system.proxy.https” has path “/system/proxy/https/”.  Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated.
Warning: Schema “org.gnome.system.proxy.ftp” has path “/system/proxy/ftp/”.  Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated.
Warning: Schema “org.gnome.system.proxy.socks” has path “/system/proxy/socks/”.  Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated.
root@freebsd-15-amd64-qemu:~ # history 7
   363  19:03   exit
   364  7:17    pkg upgrade -Fqy
   365  7:22    pkg upgrade -U
   366  7:23    pkg update
   367  7:27    pkg upgrade -Fqy
   368  7:27    pkg upgrade -U
   369  7:31    history 7
root@freebsd-15-amd64-qemu:~ # exit
logout
blah@freebsd-15-amd64-qemu:~ % freebsd-version -kru ; uname -mvKU
15.1-RELEASE-p1
15.1-RELEASE-p1
15.1-RELEASE-p1
FreeBSD 15.1-RELEASE-p1 releng/15.1-n283582-0f691888dc56 GENERIC amd64 1501000 1501000
blah@freebsd-15-amd64-qemu:~ % pkg repos -el | sort -f ; sleep 5 ; pkg repos -e | grep -B 1 -e url
FreeBSD-ports
FreeBSD-ports-kmods
FreeBSD-ports: { 
    url             : "pkg+https://pkg.FreeBSD.org/FreeBSD:15:amd64/latest",
--
FreeBSD-ports-kmods: { 
    url             : "pkg+https://pkg.FreeBSD.org/FreeBSD:15:amd64/kmods_latest_1",
blah@freebsd-15-amd64-qemu:~ % date
Sun Jul 26 07:32:34 BST 2026
blah@freebsd-15-amd64-qemu:~ %

Note:

…
[1/1] Extracting pkg-2.8.0_1: 100%
pkg: need to re-create repo FreeBSD-ports to upgrade schema version
pkg: Repository FreeBSD-ports cannot be opened. 'pkg update' required
pkg: need to re-create repo FreeBSD-ports-kmods to upgrade schema version
pkg: Repository FreeBSD-ports-kmods cannot be opened. 'pkg update' required
Checking for upgrades (0 candidates): 100%
Processing candidates (0 candidates): 100%
Checking integrity... done (0 conflicting)
Your packages are up to date.
…

grahamperrin

A sequence of commands:

pkg upgrade -Fqy
pkg upgrade -U
pkg update
pkg upgrade -Fqy
pkg upgrade -U

Normally

If updates are available – and if there are no solver conflicts in response to the first command:

all updates will be listed following the second command.

With the upgrade of pkg from 2.7.5 to 2.8.0_1

The second command is followed by:

a prompt to run pkg update
"Your packages are up to date."

– and the packages are not necessarily up-to-date.

For the truth, you must run pkg update and then again pkg upgrade …

grahamperrin

redbsd@redbsd:~ $ pkg leaf
7-zip-26.02
ImageMagick7-7.1.2.25_1
aircrack-ng-1.5.2_4
apache-ant-1.10.15_2
apache24-2.4.68
automake-1.18.1
bind-tools-9.20.24_1
ca_root_nss-3.125
cherrytree-1.7.0
cmake-3.31.12
crunch-3.6_1
doas-6.4
dotnet-9.0.14
dotnet8-8.0.27
engrampa-1.28.2_1
firefox-esr-153.0,2
freerdp3-3.30.0
gcc-14_5
gdb-15.1_5
geany-2.1
git-2.54.0
go-1.25_20,2
gradle-9.6.1
hashcat-7.1.2_11,1
hs-pandoc-3.10
htop-3.5.1
john-1.9.0.j.1_1
kismet-2016.07.r1_2,1
kubectl-1.36.1_2
libtool-2.5.4_1
lighttpd-1.4.84_1
linux-rl9-libxkbcommon-1.0.3_2
linux-rl9-xcb-util-0.4.0_2
llvm-19_1,1
lsof-4.99.5,8
mariadb1011-client-10.11.18
maven-3.8.9_3
mercurial-7.1.2
nano-9.0
nginx-1.30.4,3
ninja-1.13.2,4
nmap-7.99_1
node-24.18.0_3
noto-basic-2.0_4
npm-11.18.0
open-vm-tools-13.1.0,2
openjdk17-17.0.18+8.1
openjdk21-21.0.10+7.1_1
openssl-3.0.21,1
papirus-icon-theme-20250501
pavucontrol-6.1
php83-curl-8.3.32_1
php83-mbstring-8.3.32_1
php83-mysqli-8.3.32_1
php83-pdo_sqlite-8.3.32_1
php83-zip-8.3.32_1
pixiewps-1.4.1
podman-5.8.4_1
postgresql16-client-16.14
proxychains-ng-4.17
py312-certbot-4.2.0,1
py312-podman-compose-1.5.0
py312-pwntools-4.15.0_1
py312-virtualenv-21.2.3
python3-3_4
radare2-6.1.4
reaver-1.6.6_1
redis-8.8.0
ripgrep-15.1.0_6
ristretto-0.14.0
rizin-0.9.1
rsync-3.4.4_1
ruby-3.4.9_2,1
rust-1.96.1
screen-5.0.1_6
sddm-0.21.0.36_3
socat-1.8.1.3
sqlitebrowser-3.13.1
subversion-1.14.5_1
sudo-1.9.17p2_2
tcpdump-4.99.6
thunar-archive-plugin-0.6.0
tmux-3.7b
tree-2.3.2
trivy-0.72.0_1
vim-9.2.0738
virtualbox-ose-additions-72-7.2.14.1500068
vscode-1.127.0_1
wget-1.25.0
whois-5.5.7_1
xf86-video-vmware-13.4.0
xfce-4.20_2
xfce4-screenshooter-plugin-1.11.3
xmlstarlet-1.6.1_5
xorg-7.7_3
yq-4.1.1
zig-0.16.0
zip-3.0_5
zsh-5.9.1
redbsd@redbsd:~ $

grahamperrin

Note

Without the changes to /boot/loader.conf and /etc/rc.conf:

SDDM failed to start
the virtual display was too large for my screens.

SDDM fails to start after installation in VirtualBox · Issue #5 · shanefarris/RedBSD

General information

redbsd@redbsd:~ $ redbsd-version
RedBSD 1.0 - Initial Release
Based on FreeBSD 15.1-RELEASE
Kernel: FreeBSD 15.1-RELEASE
Architecture: amd64

FreeBSD base: 15.1-RELEASE
Kernel: FreeBSD 15.1-RELEASE
Architecture: amd64

OS release file: /etc/os-release
redbsd@redbsd:~ $ freebsd-version -kru ; uname -mvKU
15.1-RELEASE
15.1-RELEASE
15.1-RELEASE
FreeBSD 15.1-RELEASE releng/15.1-n283562-96841ea08dcf GENERIC amd64 1501000 1501000
redbsd@redbsd:~ $ pkg iinfo virtualbox
virtualbox-ose-additions-72-7.2.14.1500068
redbsd@redbsd:~ $

/boot/loader.conf

redbsd@redbsd:~ $ cat /boot/loader.conf

# Console resolution + font (set by 07_set_console_resolution.sh)
# efi_max_resolution="1920x1080"
# kern.vt.fb.default_mode="1920x1080"
# vt.font="/usr/share/vt/fonts/spleen-8x16.fnt"
loader_logo="redbsd"
loader_color="YES"
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
zfs_load="YES"
hw.efi.poweroff=0
redbsd@redbsd:~ $

/etc/rc.conf

redbsd@redbsd:~ $ cat /etc/rc.conf
hostname="redbsd"
keymap="uk.kbd"
ifconfig_em0="DHCP"
ifconfig_em0_ipv6="inet6 accept_rtadv"
lightdm_enable="NO"
sddm_enable="YES"
# vmware_guest_vmblock_enable="YES"
# vmware_guest_vmhgfs_enable="YES"
# vmware_guest_vmmemctl_enable="YES"
# vmware_guestd_enable="YES"
moused_enable="YES"
allscreens_flags="-f /usr/share/vt/fonts/spleen-8x16.fnt"
linux_enable="YES"
# vmware_guest_vmxnet_enable="YES"
wlans_iwm0="wlan0"
sshd_enable="YES"
ntpd_enable="YES"
ntpd_sync_on_start="YES"
moused_nondefault_enable="NO"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"
zfs_enable="YES"
vboxguest_enable="YES"
vboxservice_enable="YES"
redbsd@redbsd:~ $

Bonus

This line in /boot/loader.conf is for FreeBSD to truly power off, when required, in a VirtualBox guest that uses UEFI:

hw.efi.poweroff=0

Not just VirtualBox. It's sometimes required with real hardware.