m0dest

QUIC has some basic features for migrating a session to another link, but it doesn't support multipath in that sense. Multipath QUIC (MPQUIC) is a hot research area right now, and it's being standardized.

MPTCP's design was fundamentally incompatible with QUIC's UDP transport and session model.

From what I understand, neither MPTCP nor MPQUIC are designed to share multipath routing via a gateway (e.g. a bunch of devices sharing a multipath aggregation of 3 4G modems). It's all designed for a single device with multiple interfaces.

You choose 3 separate providers so that they don't have overlapping spectrum.

I've used 2 modems on the same provider, but with each modem locked to a different LTE band. This way, if the provider has one nearby tower on band 1 and another tower on band 2, you can use both of them.

(Note: If you're going to do this, make sure that you understand LTE carrier aggregation and have confirmed that the 2 bands are not being offered as a CA combination.)

At these throughput levels, you can also use a separate USB3 NICs for each port without any issues.

I can attest that Speedify in redundant mode will handle a link failure in the middle of a Zoom call without a single lost packet or other impact. This isn't failover, though, this is redundancy; it's like having a 1 disk fail in a RAID1.

(I have a similar setup to the OP, but using an array of M.2 4G/5G modem cards connected to external antennas.)

As someone with a similar setup to the OP, I should mention: OpenMPTCPRouter's networking is completely amateur compared to Speedify. It's a grab bag of half-baked multipath VPN experiments (glorytun over UDP, an outdated MPTCP-based fork of glorytun, and MLVPN), none of which approach the completeness of Spotify's implemention. They generally don't handle changing interface bandwidth, packet reordering, packet aggregation, header compression, mode switching between redundant and aggregation, or any other hard problems here. Hopefully this will save someone the pain of setting these up just to be disappointed.

Yes, it relies on a gateway server, effectively a VPN. The gateway server deduplicates packets, reorders them, and then forwards.

It adds a tiny amount of latency, but there are more important factors than latency.

If you are on a Zoom call, tunneling through Speedify in redundant mode will give you the minimum latency of n connections, reduce jitter (latency deviation), and eliminate packet loss.

Browser APIs are less stable than you might think. If you've ever had to develop web apps for smart TVs (Samsung, LG, Vizio, etc.), then you'll find that each model year is frozen on an old version of Chromium – some from 2016, some from 2017, some from 2018, etc. There are enough differences between them to make this painful. For example: multiple versions of the Media Source Extensions API, web components, CSS variables, ES6 modules, and web font loading patterns.

One elephant in the room:

The most ubiquitous and unblockable form of VPN is international cellular roaming. (While roaming, all traffic is tunneled back to the home carrier and blends in with their traffic.)

Of course, it's the most tedious VPN. It's also the most expensive. But what subset of traffic actually needs to go over the VPN? Like authentication and bot detection, these types of checks tend to be too expensive to perform on every request to every service endpoint.

Netflix likely spotted the behavior through one of the many other heuristics that can identify this, such as:

- Lower packet TTL than gateway

- Lower packet MTU than gateway

- Much higher latency than gateway

- WAN IP listening on well-known VPN ports for PPTP/IPsec/etc

- Ongoing sessions that suddenly teleported to a Chinese WAN IP when the VPN connection dropped

- Incorrect DNS configurations or stale caches that point toward inappropriate CDN edge nodes

- System time zone (via JavaScript or native app) not matching source region

- Unusual system language preferences for the region

- One of the hundreds of leaky data points revealed by Android devices and other native apps

Thanks for the write-up. One issue, though:

>You might have also noticed the “Encrypt local backup” checkbox. MVT only operates on decrypted backups, so there’s no point in encrypting your backup here and immediately decrypting it to scan it - just create an unencrypted backup and delete it after you’re done.

You should still do an encrypted backup even if you're going to immediately decrypt it for MVT. An encrypted backup contains more complete data; it's closer to a filesystem dump. The MVT docs actually explicitly recommend this, too:

>If you want to have a more accurate detection, ensure that the encrypted backup option is activated and choose a secure password for the backup.

And with the long development cycles required for silicon, any conceivable "M1X delay" wouldn't be related to disappointing performance surprises. The M1X would have already been "mostly done" at the moment when the M1 launched.

If Apple is dealing with any surprises relating to the silicon, those would most likely be security issues discovered/reported in the M1 platform after launch. Only Apple knows what's on that list – it's definitely not empty – and whether any of them must be fixed before M1X devices ship.

Can you elaborate? Why doesn't the traditional WPA1/WPA2 string work? What happens if a non-WPA3 client scans this new one?

That sounds like an unanswerable question.

I'm intrigued by that idea. Markdown or Markdown-like subsets have proven to be sufficient for communication in a variety of media (Slack, Wikipedia, forum comments, GitHub issues/comments, etc.)

Email clients are a bit of an oligopoly, so execution would depend on which player(s) are involved. Most of these initiatives would need an "everyone but Outlook" coalition to succeed.

A few thoughts on implementation:

- Multipart MIME is still a big part of HTML mail, so it would make sense to piggypack on that support. Instead of adding a new MIME attachment for Markdown, it would make sense to extend the existing support for text/plain renditions and find some way to signal that it's Markdown. (e.g. text/plain; charset=UTF-8; variant=MarkdownMail)

- For mail clients that aren't Markdown-aware, it would be important to produce an HTML-rendered variant with a reasonable style sheet.

- A Markdown-first mail client would either need to limit formatting to Markdown or soft-block access to non-Markdown formatting. ("Custom text colors will not be visible on some devices and may be lost when replying. Continue?")

- When viewing a Markdown-enabled message, a Markdown-first mail client would render the text/plain variant in its preferred style sheet, not the HTML-rendered variant.

- When replying to a Markdown-enabled message, a Markdown-first mail client would use the text/plain variant as the source of truth for quoted replies, not the HTML-rendered variant.

A few tricky areas:

- Mail clients would need to agree on a Markdown dialect, especially for extensions like tables.

- Markdown isn't very incompatible with quoting. There would need to be a solution for inline quoting.

- For everyone's sanity, it would seem important to agree on a delimiter to separate prior messages and their headers.

- To not be worse than HTML mail, we'd really need a way to signal that a paragraph is part of a mail signature so that it can be rendered in a subtle way. As much as we might wish that mail signatures would just go away, they will continue to be used, and rendering them as standard paragraph text just makes them more distracting.

Let's be real: getting legal and infosec to sign off on that is never going to happen. "We just need to borrow a subdomain of Microsoft.com, give control to our biggest competitor, and sign a contract with them... to get a vanity email address in their store."

How? I thought they blocked access to the native underlying document format. Or do you mean the HTML export?

I will never believe or respect Microsoft's supposed "open source" renaissance until they do something about reading and writing proper HTML/CSS in Outlook-Windows. The damage from the last 15 years of WordHTML has been irreversible.

>Also here's a solution with no app and no location tracking: detect when a phone has connected to on-premise WiFi.

I was about to suggest the same. Always-on location tracking is an extremely lazy and disrespectful way to replace a punch card.

Here's your replacement app:

- When arriving at work, you open the app while on employer's WiFi and tap "Start my shift"

- Before leaving work, you open the app and tap "End my shift" (but this is not required)

- During your shift, the service tries to periodically validate that your phone is still on WiFi (via LAN pings, silent push notifications that trigger checkins, or background polling)

- During your shift, if the service can't verify that your phone is still on the WiFi for 30+ minutes, it sends you a push notification asking you to open the app and check in. Otherwise, it ends your shift.

- If there's some WiFi dead zone in the workplace where they need to work for more than an hour, give the employee the option to respond with a one-time GPS location instead of joining the WiFi.

Boom. This was not hard. Doesn't even need internal infrastructure; can do this whole thing based on WAN IPs.

Geofencing vs. continuous location tracking is an implementation decision about power efficiency only. For data privacy and permissions, these are not distinguished.

A user cannot elect to grant "geofencing only" permission. And even if they could, users have no way to audit the geofence coordinates to verify that they are being used in the described manner.

Even if implemented exactly as described, it's not hard to see why this can still leak non-work-related personal data. If an employee walks past their workplace at 2 AM, that's not information that an employer should have.

The same is true of Whatsapp; this is not a major impediment to adoption for most people.

At one point, I owed a balance of $0.57 to AWS and started to get warning emails about my account being suspended. Just out of morbid curiosity, I waited to see what would happen.

2.5 years later, after dozens of automated mails, they finally suspended it.

>Various stakeholders actually participate in standardization efforts and thus also both already know the standard and are able to push it through.

And this is exactly the perverse conflict of interest. In those cases, the authors have no interest in actually attracting independent implementations that adopt the specification. The specification is a formality to bolster the credibility of their product or technology. The authors don't want some outside team to read this and actually build something on their own; they want that team to buy their [chip/component/patent license/product/service] that implements this.

It's not a solo endeavor. The coauthors and stakeholders tend to be complicit in this game, often as peers in the oligopoly.

When a spec author actually wants their specification to be independently implemented, you can tell. They don't make it exclusively for purchase in the dusty basement of the bureaucracy superstore. They put out guides, conformance tests, reference implementations, examples, and tooling.

And those materials often do exist for ISO standards... but as expensive, proprietary kits from one of the spec authors, only available to customers who buy their [chip/component/patent license/product/service]. That's part of the business plan. Why write a clear spec and give it away for free when you could be selling one of the only conformant implementations of your Public Standard™?

You can set this up with IFTTT.

I'm playing with it. This is cool. I can't wait for SFTP support. (I know that is difficult for a myriad of reasons, but that's also why it would be so rad. Don't be afraid to assist it using SSH POSIX commands like find when they're available and compliant. There's no prize for SFTP implementation purity.)

Does the File Provider integration support block-level random access? Like, if I have a 1 GB .mp4 video, does it need to download the full video file before playback? This has always been one of the tricky scenarios for high-level OS file APIs.

I think it's fair for few reasons:

- Without a valid SSL certificate, there's no way to tell whether you're actually visiting your UniFi controller or a honeypot. Ubiquiti isn't the risk here.

- UniFi features that depend on WebSocket and WebRTC are unavailable when using self-signed certificates. This includes live stats updating, device terminal, airView, etc. (Those features can be used in the cloud UI... if your Internet connection happens to be working fine.)

- Valid SSL certificates would be easy to auto-provision these days with LetsEncrypt. There are some minor challenges around port forwarding / relay, but that isn't rocket science. If Plex can figure it out, Ubiquiti can figure it out :)

>engaged in multiple interface redesigns with loss of features with no apparent gains

Yeah, this has been really baffling. Their settings UI has been in a transition state between "Classic Settings" and "New Settings" for years. Neither is complete. Some settings are only in New Settings (e.g. WiFi AI), while many more are only in the Classic Settings (e.g. allow multicast from Ethernet to WiFi).

Agree; from my experience with Pi SD cards, it’s straight-up irresponsible to recommend that anyone use an SD card with the Pi for their main computer.

Every Pi SD card has ended in irreparable disk corruption. The SD hardware’s wear-leveling and delayed allocation is fundamentally incompatible with any device without a battery, especially with frequent writes.

The “official” solution for the Pi is to use read-only SD cards with overlayfs. That’s not the default and it’s not how entry-level users will use this.

This is unfortunately the only way to operate an online service in China. It’s standard practice (and a legal requirement) to hand off the ownership and control of Chinese servers to a separate Chinese company. Apple has been pretty transparent about this.

One could argue that Apple should have just exited the Chinese market instead of letting the local government spy on their citizens. Google has taken that position.

Here’s something that I don’t understand: Why isn’t there more interest in compiling the Windows Embedded 7 source code that was included in the same leak? It seems like that would have a much more recent kernel and have fewer dependencies on missing components.