Obligatory reference to desire paths: !desire_paths@sh.itjust.works

Traffic – under foot or otherwise – is one way to keep a path in decent shape

My understanding is that the de minimis tariff treatment for import shipments is different than the duty-free personal exemptions that apply for “accompanied baggage” when re-entering the USA and has the imported items with them.

Assuming this CBP page is accurate, the $800 exemption is one of three possible exemptions that can still apply. The $1600 exemption only applies when returning with stuff from Guam, American Samoa, or USVI, and the $800 can only be claimed every 30 day. The last resort is the $200 exemption, which is always available, and ostensibly is there to allow Americans living near Canada or Mexico to not have to deal with border taxation just because they had to buy lunch or gasoline during day trips.

Yep, sometimes acetone will do that. But other times, another solvent like gasoline might do the trick. Or maybe a heat gun.

I see it as an engineering challenge, how to best remove intrusive logos from stuff. IMO, all this is part-and-parcel to the second part of: reduce, reuse, recycle. Also, sometimes certain logos can be clipped in very creative ways haha

It doesn’t work for backpacks that might have the company name embroidered on, but for cheaper print-on-demand items like hats and water bottles, acetone will cause the logo to dissolve or shift.

That says, I have personally removed embroidered logos from clothes before, when the product itself is excellent but aesthetically ruined by a logo. It’s very finnicky work with a seam ripper, and has gained me a lot of nice thrift store finds.

I agree with this comment, and would suggest going with the first solution (NAT loopback, aka NAT hairpin) rather than split-horizon DNS. I say this even though I have a strong dislike of NAT (and would prefer to see networks using flat IPv6 addresses, but that’s a different topic). It should also be fairly quick to configure the hairpin on your router.

Specifically, problems arise when using DNS split-horizon where the same hostname might resolve to two different results, depending on which DNS nameserver is used. This is distinct from some corporate-esque DNS nameservers that refuse to answer for external requests but provide an answer to internal queries. Whereas by having no “single source of truth” (SSOT) for what a hostname should resolve to, this will inevitably make future debugging harder. And that’s on top of debugging NAT issues.

Plus, DNS isn’t a security feature unto itself: successful resolution of internal hostnames shouldn’t increase security exposure, since a competent firewall would block access. Some might suggest that DNS queries can reveal internal addresses to an attacker, but that’s the same faulty argument that suggests ICMP pings should be blocked; it shouldn’t.

To be clear, ad-blocking DNS servers don’t suffer from the ails of split-horizon described above, because they’re intentionally declining to give a DNS response for ad-hosting hostnames, rather than giving a different response. But even if they did, one could argue the point of ad-blocking is to block adware, so we don’t really care if SSOT is diminished for those hostnames.

Is this question about drivers that turn off their indicators while still mid-turn? Or about drivers that turn or change lanes in very little time at all?

IMO, the correct time to use indicators is precisely when in preparation for a turning or lane-change manoeuvre, during such manoeuvre, and that’s it. Once the manoeuvre is done, the indicators should be extinguished to avoid ambiguity, unless a follow-up manoeuvre is planned.

I see no logical reason to enforce a prescribed minimum for indicator time, and it’s why I see minimum-three-blink on some modern cars as an anti-feature. After all, there’s no minimum (nor maximum) time to prepare and make a turning manoeuvre.

To use a USA example, the driving style of Los Angeles inter-city freeways is – for better or worse – going to necessitate fairly quick lane changes, because of the tighter spacing between cars. In hard figures, a lane change might be prepped and done in 3 seconds. Some might say that all these drivers are violating good driving behaviors for following each other so closely, but it’s sadly a practical necessity when no amount of “just one more lane” can solve the systemic issues with regional road transportation there; it’s why LA is doubling down on public transit building.

Compare this with changing lanes on a rural Interstate freeway to pass a semi-truck, where a lane change can be more sedate because there might not be any other traffic in sight except for the two vehicles involved. Smooth driving on a road-trip might have this manoeuvre prepped and completed over 10-15 seconds, as the car might also be slowly accelerating while also changing lanes. Sometimes on these two-lanes-in-each-direction roads, the driver might even continue using the left indicator, but it now unambiguously indicates that they intend to fully overtake the semi-truck, and will switch on the right indicator once fully ahead and they intend to return to the right-hand lane.

In both circumstances, the indicators should remain blinking while mid-manoeuvre. Anything short of that is “too quick” in my book.

But if your question is how far in advance should drivers begin indicating before the manoeuvre, that’s a joint matter of regional convention and of law. And the former usually is the strongest influence.

TL;DR: indicators indicate intent, but some people have quick intent.

which means DNS entries in a domain, and access from the internet

The latter is not a requirement at all. Plenty of people have publicly-issued TLS certs for domain named services that aren’t exposed to the public internet, or aren’t using HTTP(s). If using LetsEncrypt, the DNS-01 challenge method would suffice, or can even issue a wildcard certificate for subdomains, so additional certificate issuance is not required.

If after acquiring a domain, said domain can be pointed to one of many free nameservers that provide an API which can be updated from an ACME script for automatic renewal of the LetsEncrypt certificate using DNS-01. dns.he.net is one such example.

OP has been given a variety of options, each of which come with their own tradeoffs. But public access to Jellyfin just to get a public cert is not a necessary tradeoff that OP needs to make.

Not “insecure” in the sense that they’re shoddy with their encryption, no. But being free could possibly mean their incentives are not necessarily aligned with that of the free users.

In security speak, the CIA triad stands for Confidentiality, Integrity, and Availability. I’m not going to unduly impugn Proton VPN’s credentials on data confidentiality and data integrity, but availability can be a legit security concern.

For example, if push comes to shove and Proton VPN is hit with a DDoS attack, would free tier users be the first to be disconnected to free up capacity? Alternatively, suppose the price for IP transit shoots through the roof due to weird global economics and ProtonVPN has to throttle the free tier to 10 Mbps. All VPN operators share these possibilities, but however well-meaning Proton VPN and the non-profit behind them are, economic factors can force changes that aren’t great for the free users.

Now, the obv solution at such a time would be to then switch to being a paid customer. And that might be fine for lots of customers, if that ever comes to pass. But Murphy’s Law makes it a habit that this scenario would play out when users are least able to prepare for it, possibly leading to some amount of unavailability.

So yes, a holistic analysis of failure points is precisely what proper security calls for. Proton VPN free tier may very well be inappropriate. But whether it rises to a serious concern or just warrants an “FYI”, that will vary based on individual circumstances.

Don’t. OP already said in the previous post that they only need Jellyfin access within their home. The Principle of Least Privilege tilts in favor of keeping Jellyfin off the public Internet. Even if Jellyfin were flawless – and no program is – the only benefit that accrues to OP is that the free tier of ProtonVPN can access Jellyfin.

Opening a large attack surface for such a modest benefit is letting the tail wag the dog. It’s adding a kludge to workaround a different kludge, the latter being ProtonVPN’s very weird paid tier.

I previously proffered some information in the first thread.

But there’s something I wish to clarify about self-signed certificates, for the benefit of everyone. Irrespective of whichever certificate store that an app uses – either its own or the one maintained by the OS – the CA Browser Forum, which maintains the standards for public certificates, prohibits issuance of TLS certificates for reserved IPv4 or IPv6 addresses. See Section 4.2.2.

This is because those addresses will resolve to different machines on different networks. Whereas a certificate for a global-scope IP address is fine because it should resolve to the same destination. If certificate authorities won’t issue certs for private IP addresses, there’s a good chance that apps won’t tolerate such certs either. Nor should they, for precisely the reason given above.

A proper self-signed cert – either for a domain name or a global-scope IP address – does not create any MITM issues as long as the certificate was manually confirmed the first time and added to the trust store, either in-app or in the OS. Thereafter, only a bona fide MITM attack would raise an alarm, the same as if a MITM attacker tries to impersonate any other domain name. SSH is the most similar, where trust-on-first-connection is the norm, not the outlier.

There are safe ways to use self-signed certificate. People should not discard that option so wontonly.

Physical wire tapping would be mostly mitigated by setting every port on the switch to be a physical vlan

Can you clarify on this point? I’m not sure what a “physical VLAN” would be. Is that like only handling tagged traffic?

I’m otherwise in total agreement that the threat model is certainly not typical. But I can imagine a scenario like a college dorm where the L2 network is owned by a university, and thus considered “hostile” to OP somehow. OP presented their requirements, so good advice has to at least try to come up with solutions within those parameters.

I had a small typo where “untrusted” was written as “I trusted”. That said, I think we’re suggesting different strategies to address OP’s quandary, and either (or both!) would be valid.

My suggestion was for encrypted L3 tunneling between end-devices which are trusted, so that even an untrustworthy L2 network would present no issue. With technologies like WireGuard, this isn’t too hard to do for mobile phone clients, and it’s well supported for Linux clients.

If I understand your suggestion, it is to improve the LAN so that it can be trusted, by way of segmentation into VLANs which separate the trusted devices from the rest. The problem I see with this is that per-port VLANs alone do not address the possibility of physical wire-tapping, which I presumed was why OP does not trust their own LAN. Perhaps they’re running cable through a space shared with other tenants, or something like that. VLANs help, but MACsec encryption on the wire paired with 802.1x device certificate for authentication is the gold standard for L2 security.

But seeing as that’s primarily the domain of enterprise switches, the L3 solution in software using WireGuard or other tunneling technologies seems more reasonable. That said, the principle of Defense In Depth means both should be considered.

Prior-gen Epyc boards show up on eBay from time to time, often as CPU+mobo bundles from Chinese datacenters that are upgrading to latest gen. These can be had for a deal, if they’re still available, and would provide PCIe lanes for days.

I agree with the idea of not using a 10 Gbps network for GPU work. Just one small nitpick: PCIe Gen 1 in an x1 slot is only capable of 2.5 GTransfers/sec, which translates to about 2 GBits/sec, making it about 5x slower than a 10 Gbps line-rate network.

I sincerely hope OP is not running modern AI work on a mobo with only Gen 1…

After reviewing the entire thread, I have to say that this is quite an interesting question. In a departure from most other people’s threat models, your LAN is not considered trusted. In addition, you’re seeking a solution that minimizes subscription costs, yet you already have a VPN provider, one which has a – IMO, illogical – paid tier to allow LAN access. In my book, paying more money for a basic feature is akin to hostage-taking. But I digress.

The hard requirement to avoid self-signed certificates is understandable, although I would be of the opinion that Jellyfin clients that use pinned root certificates are faulty, if they do not have an option to manage those pinned certificates to add a new one. Such certificate pinning only makes sense when the client knows that it would only connect to a known, finite list of domains, and thus is out-of-place for Jellyfin, as it might have to connect to new servers in future. For the most part, the OS root certificates can generally be relied upon, unless even the OS is not trusted.

A domain name is highly advised, even for internal use, as you can always issue subdomains for different logical network groupings. Or maybe even ask a friend for a subdomain delegation off of their domain. As you’ve found, without a domain, TLS certificates can’t be issued and that closes off the easy way to enable HTTPS for use on your untrusted LAN.

But supposing you absolutely do not want to tack on additional costs, then the only solution I see that remains is to set up a private VPN network, one which only connects your trusted devices. This would be secure when on your untrusted LAN, but would be unavailable when away from home. So when you’re out and about, you might still need a commercial VPN provider. What I wouldn’t recommend is to nest your private VPN inside of the commercial VPN; the performance is likely abysmal.

deleted by creator

But outside it’s a very different story especially in places where the language isn’t English.

What is the demonym for something that can be found or belongs to “The Americas”, comprising both North and South America (and potentially Central if you go by the Three Americas way of splitting the continent)?

This is a fair question, and I suspect there simply is no generally accepted demonym in English. One could be introduced, but contrast that fairly simple exercise with the replacement of the broadly-recognized demonym for USA residents: “American”. Quickly, it becomes apparent that replacement is far harder than introducing a new demonym, even if the to-be-replaced demonym itself isn’t very logical within the English language.

English is the same language that calls people from Deutschland as “German”, and then American English specifically might also call them “Dutch”, as in, the Pennsylvania Dutch, whom immigrated from Germany. Consistency is not strong in the English language, even over only a few hundred years.

I’ve not known any USA residents that call the continent as “America”. Instead, the continent – which in this case basically just means USA + Canada – would be “North America”. And if they meant the whole post-1490s “New World”, it would be “The Americas” for both North and South America together.

I’m reminded of Matt Parker demonstrating recursion in Microsoft PowerPoint:

https://www.youtube.com/watch?v=b-Fa6HtvGtQ

Thank you for your kind words!