The part about ISP routers broadcasting an alternate "hotspot" SSID is documented [1] and can be easily observed. Walk around any city, open your phone's wifi settings and see networks like "xfinitywifi" or "optimumwifi". As an end user, if you connect to one of these networks from your device, you'll get a captive portal web page that makes you sign in to your ISP account. Once signed in, you get internet access courtesy of the router sitting in whatever home or business you happen to be near to.
In addition to ISPs allowing their own subscribers access, there are examples of corporations cutting deals with ISPs for hotspot network access. For example, Google's MVNO Google Fi has a deal with unnamed partners that allows subscribers' phones to connect to hotspot wifi networks for extra coverage, branded "Wi-Fi Auto Connect+" [2].
From the user's perspective (and personal experience), this connection is handled seamlessly and outside of the OS' normal wifi UI flow. If your phone sees no saved wifi networks but does see xfinitywifi (et al), it auto-connects in the background. Authentication with the captive portal happens automatically and non-interactively, presumably with some keys provisioned to your device. Your traffic is VPNed back to Google, so the router and ISP don't see anything. The only indication that any of this happened is that the "5G" icon changes to "W+"; the normal WiFi icon never shows up.
In the case of Google Fi, this is actually a pretty great deal for users. You get better coverage (especially indoors in cities, where cell service can be spotty) with no real downsides to you – your traffic isn't meaningfully exposed to another third party, it doesn't cost you extra, and you don't have to bother the staff for a wifi password.
But given all that, it's not a huge leap to believe that ISPs are also more than willing to quietly take LG's money in exchange for an all-access pass to their hotspot network.
It's easy to imagine that an evil company could ship their TV with a key that allows it on an ISP's hotspot network. No extra suspicious hardware like a 5G modem needed, and no MAC address spoofing required. The TV software could easily connect to the hotspot network with zero indication in the UI, and then use the surreptitious connection only to transmit your kompromat back to HQ.
If done intelligently, you'd never notice. By only transmitting spy reports (and not downloading new ads), even a keen observer wouldn't notice any behavior on the TV that would trigger "how tf did this thing get a network connection?" Even more insidious, you couldn't really see what traffic was happening, since IP packet captures on your network are useless in this scenario. You'd need special hardware to capture what the TV is actually doing on the air.
If truly evil, the software could do this hotspot dance even if you've configured your own WiFi network on the TV. If the software finds it can't reach ad HQ because you've firewalled it off, then despite your best efforts to contain the disease, it still can spy effectively thanks to your neighbor's router with its default-enabled ISP hotspot. Just do a daily upload while you're sleeping and otherwise sit innocuously on your locked-down VLAN.
Everyone evil wins: ISP collects that sweet bonus revenue at zero marginal cost, TV manufacturer doesn't have to foot the hardware bill for millions of 5G modems or (relatively) expensive cellular agreements, and advertisers get to be that much more creepy targeting you. I'm sure the wanna-be despots of the world don't mind the spy apparatus being built for them either, conveniently under the control of easily-compelled corporations.
--
Now to be clear, I have no proof that any TV manufacturer is surreptitiously connecting to an ISP's hotspot network in order to exfiltrate your data. But all of the building blocks to make that happen provably do exist, and I seriously doubt that capitalism will allow them to go unused.
My (possibly uninformed) understanding at the time was that it was Docker, not solely filesystem performance.
WSL1's file performance is pretty much as good as it gets on Windows, since open(2), read(2), etc are all translated directly in-kernel from Linux to Windows API calls. It's still slower than a real Linux kernel since Windows' filesystem filter drivers add a lot of overhead to every operation, and Windows Defender and its realtime scanning in particular makes it 10x worse. (NTFS itself is fine.)
WSL1's filesystem situation is now "fixed" by Dev Drive, which is just a new partition with most filters disabled and Defender is put in to a different mode where scanning is asynchronous instead of blocking every open(2).
WSL2's mounts of Windows disks still has to deal with all of the above, plus the overhead of serializing every operation over a VM socket, which is largely fixed by what this article describes. So even if you've enabled virtiofs to speed up WSL2's cross-VM transfers, you're still going to hit the same Windows filesystem caveats that apply to WSL1 and native Windows apps.
On the other hand, the WSL2 in-VM ext filesystem (ie, the / mount) will be the fastest to Linux apps since it never touches the Windows side, but accessing those files from Windows sucks since they're buried in a VHD image, accessed over a slow 9p (I think) network-like mount on \\wsl.localhost\distro\
All of that to say filesystem perf may or may not have been a factor in the switch from WSL1's very cool NT persona architecture to WSL2's decidedly more boring VM design, but it was pretty clear that Docker was the real showstopper.
Devs needed to run containers, and WSL1 couldn't (and still can't) do it.
I imagine Microsoft took a look at what it would take to implement container support in the NT kernel to the point that Docker would work, and decided it was simply too much work when they could just slap a VM in and get the entire Linux kernel API surface for free. So thus we got WSL2.
I still use WSL1 for light work like running ssh, since there's basically no overhead at all (5 MB of RAM total to run ssh), compared to needing to run an entire second OS in WSL2. And as long as you don't need any containers, even heavier work runs nicely on WSL1 since there's no VM overhead or network NAT shenanigans.
> Windows' filesystem filter drivers add a lot of overhead to every operation, and Windows Defender and its realtime scanning in particular makes it 10x worse. (NTFS itself is fine.)
Are there a lot of Microsoft operating systems that feature NTFS without filesystem drivers and Windows Defender?
It's the filesystem filter drivers that slow things down, not the filesystem drivers (ie NTFS) themselves.
Filter drivers sit a layer above the filesystem driver and allow you to hook file operations to do things like antivirus scanning, transparent encryption and compression, realtime backups, and implement virtual files (à la Dropbox and OneDrive cloud files that are deleted from local storage and JIT downloaded when accessed).
Those are all useful features, but you pay for the extensibility with performance.
To answer your question, obviously no—at least not in a default configuration—but all that stuff can be disabled if you're so inclined, which would leave you with a Microsoft operating system featuring NTFS without the filters and Defender.
But I'm not sure what point you're trying to make. Different operating systems make different trade-offs?
NTFS itself is actually pretty good, but unless you disable the filter drivers and Windows Defender, overall system performance of NTFS isn't great. Except that you can't really run NTFS without those things. Technically you can, but you're not running without Windows Defender enabled except in very very specific circumstances. So the performance of NTFS itself without those things is a moot point because of that.
What wasn't immediately clear to me is that you're meant to set up Raspberry Pis with a Pi camera attached, and that serves as the camera device. This then provides E2E encryption directly between the Pi and the Secluso mobile app via a cloud relay service that just shovels the encrypted bytes.
Contrast with https://frigate.video/, which is a locally installed NVR server that pulls camera feeds over the LAN (from a very wide range of off-the-shelf IP cameras) and does all kinds of really neat local processing to do things like (optionally hardware-accelerated) object and audio detection, face recognition, ALPR, semantic search over recorded video, and more — while still maintaining similar privacy guarantees.
It's great that you've done reproducible builds for camera firmware, since that means you don't have to trust a shady IP camera vendor to be competent. Of course, with off-the-shelf stuff, you can largely avoid the security issues there by putting your cameras on a VLAN that can only reach your NVR.
What I don't get is why there needs to be a cloud relay involved at all. If you're fully E2E encrypted anyway, just have the app communicate directly with the camera via STUN.
I see you're planning on selling the preassembled hardware. There's definitely something to be said for "buy this device, download app, done" ease of setup for the wider market that meaningfully improves their privacy over Ring/Nest/et al. But for the power user and self-hosting crowd, I think Frigate makes a lot more sense.
There are two comments/questions here and I'll try to address them one by one.
Secluso vs. Frigate: I think you correctly mentioned some of the differences. We intend Secluso to be replacement for Ring-like WiFi cameras. Therefore, it needs to be easy to set up and use and provide similar functions to a Ring camera: the user plugs in the camera, opens the app, scan a QR code and perform a pairing process, and the camera is ready to use with its strong end-to-end encryption. The self-hosted version of Secluso requires a few more steps, but we've tried to automate it as much as possible. Home Assistant and Frigate are great platforms that are capable of providing good privacy (although they don't support advanced end-to-end encryption that Secluso does with forward secrecy and post-compromise security through MLS), but they require several steps, e.g., prepare/configure the IP camera, install and configure Frigate, integrate Frigate with Home Assistant, and configure remote viewing via cloud relay or VPN. Also, they are typically used with wired (Ethernet) IP cameras. WiFi IP cameras are possible but the RTSP stream between the camera and hub will be unencrypted, which might be vulnerable to eavesdropping.
Need for cloud relay: We have considered STUN and we are planning to deploy MLS over WebRTC for livestreaming (using the DAVE protocol) to improve the livestream performance. But this doesn't completely eliminate the need for a relay. If a STUN connection cannot be made due to some restrictions in one of the networks (that the camera and app are connected to), we will need to fall back to the relay. Also, if the phone is off/disconnected when an event video is recorded, we would like to transfer it (encrypted) to the relay ASAP in case something happens to the camera (e.g., it's taken by the intruder).
> the company prevent you from working in any open source work, including personal ones without a written permission, and everything you do will be the company property on or off duty
PSA: If you're in California, these kinds of employment contract terms are (mostly) illegal and unenforceable.
Labor Code 2870 outright invalidates any employment contract provision which attempts to claim ownership of IP rights to anything “that the employee developed entirely on his or her own time without using the employer’s equipment, supplies, facilities, or trade secret information” unless it relates to the employer's business or results from other work performed for the employer.
Labor Code 96(k) prohibits employers for disciplining or firing an employee who engages in “lawful conduct occurring during nonworking hours away from the employer’s premises,” with an exception for contracts that prohibit conduct by the employee that is in direct conflict with the employer’s “essential enterprise-related interests.”
So blanket prohibitions are out. If you're doing something that closely relates to your employer's products/business or could be construed as a conflict of interest, that's when you should consider written permission, but a company can't say “no” unless it actually relates to the company's business.
California is relatively unique in these worker protections, and they're a big reason why Silicon Valley became what it is.
It has been a long time since I've done this, but:
If your Android is rooted, it's pretty easy to get tethering working. There's magisk modules that can fix the TTL problem and/or disable the hidden carrier-installed software that Android will ask for permission before enabling tethering.
> Tvheadend is the leading TV streaming server and recorder for Linux supporting ATSC, DVB-C/C2, DVB-S/S2, DVB-T/T2, ISDB-T, IPTV, SAT>IP and HDHomeRun input sources. Tvheadend outputs HTTP (VLC, MPlayer), HTSP (Kodi, Movian) and SAT>IP streams, and can ingest multiple Electronic Program Guide (EPG) formats including over-the-air (OTA) broadcast data for DVB and ATSC, and OpenTV extensions like XMLTV and PyXML.
So it's a DVR project in the vein of TiVo and Windows Media Center.
Oh, I must be misremembering. I also used to use it with XBMC/Kodi, but I recalled kodi itself being the dvr element. Or maybe I’m even conflating it with plex. It has been a minute :D
Having read that thread, I guess one of the small upsides of the world I live in is that "FIFA Peace Prize" is now available as a joke award reference. FIFA really hit it out of the park there in a way that even their normal legendary levels of corruption couldn't imagine.
Edited: In hindsight I notice that "hit it out of the park" is the wrong sport metaphor for FIFA, but I stand by it anyway.
> Edited: In hindsight I notice that "hit it out of the park" is the wrong sport metaphor for FIFA, but I stand by it anyway.
For future reference, you can use: "knocked it into the top corner", "put it in the back of the net" or "smashed it past the keeper". Not a native football-talker, but hang out too much with a few.
"Back of the net" doesn't feel the same to me even though (I learn after reading far too much about a sport I do not play) "Out of the park" is basically the same thing.
In my mind "out of the park" had meant the ball leaves the actual stadium but in fact (I read) "the park" in this context is actually the field of play and so "out of the park" represents in fact the vast majority of home runs and not the over-achievement I had imagined.
True, "back of the net" is more "someone kicked the ball really hard and it hit the back of the net really hard" instead of "the ball came across the goal line" which can be very different, so in my mind that's as close to "out of the park" as you can get in soccer :)
There's no reason you have to run ESPHome on your Home Assistant server.
It's offered as a HA a̵d̵d̵o̵n̵ app for ease of use (makes it a one-click install), but you can also just `pip install esphome` or use the provided Docker image and get the exact same UI, but with everything (including compilation) running on your much beefier laptop.
So your binaries get compiled quickly and you can still do the OTAs directly from your laptop. HA needn't be involved.
> You can still install the whole kit and caboodle using pip in a Python virtual environment, but why would you?
This is how I did it, instead of the container or HA OS in a VM.
If you want the simplicity of everything preconfigured, managed, and hands-off, go with HA OS, whether in a VM on a beefier machine, standalone, or the HA Green/Yellow dedicated hardware.
But if you already have a home server and want to add HA, I found just pip installing to be easier than dealing with the container.
Maybe I'm just the silly type that enjoys fiddling with Linux, but I'd argue that it actually makes more sense to install HA bare metal over a container. HA doesn't actually have any major dependencies outside of what pip installs, so setup wasn't any more annoying than via container. And then you never have to deal with container annoyances like passing hardware through to it or weird failures and misconfigurations.
Contrast this with https://frigate.video/, which has so many fragile native dependencies and a super complex stack that trying to install manually is an exercise in futility. I gave up and used the container.
The much more likely culprit is your VPN server's port. If it's running on some no-name port (such as the default 51820), that's likely to get throttled.
I'd bet that switching your VPN server port to 443 would solve the problem, since HTTP/3 runs on 443/udp.
The part about ISP routers broadcasting an alternate "hotspot" SSID is documented [1] and can be easily observed. Walk around any city, open your phone's wifi settings and see networks like "xfinitywifi" or "optimumwifi". As an end user, if you connect to one of these networks from your device, you'll get a captive portal web page that makes you sign in to your ISP account. Once signed in, you get internet access courtesy of the router sitting in whatever home or business you happen to be near to.
In addition to ISPs allowing their own subscribers access, there are examples of corporations cutting deals with ISPs for hotspot network access. For example, Google's MVNO Google Fi has a deal with unnamed partners that allows subscribers' phones to connect to hotspot wifi networks for extra coverage, branded "Wi-Fi Auto Connect+" [2].
From the user's perspective (and personal experience), this connection is handled seamlessly and outside of the OS' normal wifi UI flow. If your phone sees no saved wifi networks but does see xfinitywifi (et al), it auto-connects in the background. Authentication with the captive portal happens automatically and non-interactively, presumably with some keys provisioned to your device. Your traffic is VPNed back to Google, so the router and ISP don't see anything. The only indication that any of this happened is that the "5G" icon changes to "W+"; the normal WiFi icon never shows up.
In the case of Google Fi, this is actually a pretty great deal for users. You get better coverage (especially indoors in cities, where cell service can be spotty) with no real downsides to you – your traffic isn't meaningfully exposed to another third party, it doesn't cost you extra, and you don't have to bother the staff for a wifi password.
But given all that, it's not a huge leap to believe that ISPs are also more than willing to quietly take LG's money in exchange for an all-access pass to their hotspot network.
It's easy to imagine that an evil company could ship their TV with a key that allows it on an ISP's hotspot network. No extra suspicious hardware like a 5G modem needed, and no MAC address spoofing required. The TV software could easily connect to the hotspot network with zero indication in the UI, and then use the surreptitious connection only to transmit your kompromat back to HQ.
If done intelligently, you'd never notice. By only transmitting spy reports (and not downloading new ads), even a keen observer wouldn't notice any behavior on the TV that would trigger "how tf did this thing get a network connection?" Even more insidious, you couldn't really see what traffic was happening, since IP packet captures on your network are useless in this scenario. You'd need special hardware to capture what the TV is actually doing on the air.
If truly evil, the software could do this hotspot dance even if you've configured your own WiFi network on the TV. If the software finds it can't reach ad HQ because you've firewalled it off, then despite your best efforts to contain the disease, it still can spy effectively thanks to your neighbor's router with its default-enabled ISP hotspot. Just do a daily upload while you're sleeping and otherwise sit innocuously on your locked-down VLAN.
Everyone evil wins: ISP collects that sweet bonus revenue at zero marginal cost, TV manufacturer doesn't have to foot the hardware bill for millions of 5G modems or (relatively) expensive cellular agreements, and advertisers get to be that much more creepy targeting you. I'm sure the wanna-be despots of the world don't mind the spy apparatus being built for them either, conveniently under the control of easily-compelled corporations.
--
Now to be clear, I have no proof that any TV manufacturer is surreptitiously connecting to an ISP's hotspot network in order to exfiltrate your data. But all of the building blocks to make that happen provably do exist, and I seriously doubt that capitalism will allow them to go unused.
It's anything but far-fetched.
[1] eg https://www.xfinity.com/support/articles/xfinity-wifi-hotspo... and https://www.spectrum.net/support/internet/spectrum-mobile-wi... and https://www.optimum.net/pages/internet/hotspots/faq.html
[2] https://fi.google.com/about/wi-fi-auto-connect-plus and https://support.google.com/fi/answer/10091529?hl=en
reply