Wicher

Great idea! I'd love this, but as an open source app. Out of interest (not a criticism), what made you decide to do this closed source, especially considering there doesn't seem to be a commercial interest involved (for now)?

A networking-over-DNS client and server, in Go. https://sr.ht/~nullenenenen/ShrewDNS/

A bit like iodine in the basic idea, but the execution and network topologies you build with it are different. It's more of a building block; you get your DNS channels represented as UDP endpoints, and take it from there, ie you can run Wireguard over it, or SSH or a SOCKS5 proxy (using quicmux, so over QUIC), or run Mosh straight over DNS if you're crafty.

It has an Android app too! I tried to submit it to F-Droid but they're so swamped in spammy or low-quality apps that they're not taking any brand new apps :-( A sad state of affairs, that.

It did yesterday, for me. Sometimes it doesn't work for a while and the dev needs some time catching up to what Google deliberately or inadvertently or indifferently put in the way of access to the place where apps are published (and they are published there, not because app creators deliberately chose Google out of many app distributors in some healthy competitive market; there is no choice).

The Aurora project accepts donations, if you want to hurry things along some time! And they have a donation button right there in the app listing, try doing that for yourapp in the PlayStore and see who comes knocking in 3...2..1 to make you a non-person.

> sent from a legitimate government agency email domain,

DMARC-verified-sent from a legitimate [...] domain? -> Someone pwned a mailbox at an agency? I'm sure they would've spun the story into "the government was hacked, not us" in that case.

Or "sent from" a legitimate [...] domain? -> Spoofed envelope sender / FROM? Then Revolut's simply been had by the nose. If the domain is indeed a government domain, and does not publish DMARC records, then a due diligence check on who they're sending such personal info (ie, call that purported government agency up on the phone) would suit them.

After all, they're very pedantic about me running their app on a phone with an unlocked bootloader. I'd then hope that they'd be symmetrically pedantic about verifying whoever they're sending my info to.

It'd be hard to detect from structure. Episode descriptions can and do legitimately have links. And if/when it comes to deep inspection, instead of a dummy audio file one could use a TTS-ed audio version of the post, there's some legitimacy there. You can even flip it around and claim that the blogpost is the "audio transcription" "for those who want it".

But yeah let's not underestimate the power we're giving these platforms. If down the road it doesn't match the monetization strategy? Platform giveth, platform taketh.

RSS is great for informing readers of new content. Sadly only a few actually use it, except (unknowingly, for a large part of the population) for... Podcasts.

So, thinking out loud: you could offer people to subscribe to your website by publishing a RSS feed with dummy audio, using a link in the the episode description to get people to hop through to your website. And then you offer the appropriate "subscribe in iTunes / Spotify / generic podcasting app" buttons on your website page.

And then suddenly the masses can sign up to your updates! And they can easily unsubscribe! And you don't have to deal with email, and can use static file hosting! There'd even be a discovery inroad as presumably the Apples and Spotifies of this world will push it through the personalized recommendations pipe just as they would for any other podcast.

It's a bit subversive but it would work wouldn't it?

Turning shoes into carpet padding is probably "downcycling". I think recycling would mean most of the shoe would be used for new shoes or something of similar complexity, retaining the grade and value of the input materials.

Downcycling is when you reuse something for a less refined purpose. For instance you can use contaminated plastics (im the sense of somewhat mixed types, bits and bobs of labels etc) to make humble park benches, but you won't be then reusing that low grade park bench plastic to make the Hubble space telescope with.

Still, downcycling into carpet is better than dumping the shoes on a coral atoll of course. Yet it's a step below recycling.

This is kind of already the case on Android.

If you've installed RealActualBankApp (with the ID of real.actual.bank.app) once (from whatever source!) then there cannot be another app installed with that same id but signed with a different public key (oversimplified version of the story, there is a key rollover scheme).

You can however install an imposter app that's also called RealActualBankApp, with the same icon. It'll need to go by a different ID.

So then we're down to the same problem, or pseudo-problem, of identity confusion, as we have for banking website URLs. Where is the ID/URL shown, and does the user know that it should be mybank.com and not mybank-incorporated.com ?

Wear on the chain is greatly increased though on a 1x12 versus a 2x10, because of alignment.

Tolerances on a 1x setup are also much tighter, not ideal for long distance cycletrekking adventures.

Also, with a front derailer, dropping the chain to a smaller cog in the front to get to a lighter gear results in much happier shifting than having to lift the chain to a larger cog on the rear derailer when going uphill.

When MTB racing you can really get some advantage out of shifting combination discipline using a front derailer, when going from a downhill into an uphill.

I'm sad it's hard to find a 2x setup on new bicycles nowadays :-/

Hmmmmm, a visor? I suppose it'll get steamed up pretty easily when hillclimbing on a cold damp morning.

> "The victim" of using a certain operating system? Please.

Perhaps "victim" in the sense of not having much choice/agency? Neither in the choice of operating system (due to sparsely restrained anticompetitive behaviour of incumbents over decades) nor in how they're treated (entrapped) by the operating systems. The OSes are really POS (point of sale) terminals for media and cloud services.

Thus consider most operating system users aren't really users. They're "usees", they're being used. One could surmise that the Microsoft/Apple/Google shareholders are the real users of the operating systems.

If you'd left the commercial OS world in the Win2K/OSX 10.4 era for, say, Gentoo Linux, and would come back now to look over someone's shoulder while they're using (or rather, being used by) their operating systems, you could be forgiven for coming away with the impression that some kind of authority inversion has taken place in the meantime.

Thanks, I wrote them. I'm curious as to what will come of it.

Or rather – one of the downsides of many hosted Postgres installs, notably AWS RDS, is that you're not able to use the extensions you want.

Yeah, so, it's not injecting? To inject something into X, X needs to exist. X does not exist yet when execve is set up.

I'm not being pedantic. I just want to read about injection when I'm promised injection :-) because that'd be technically interesting for me. Plainly calling execve isn't so much, I have the manpage here already :-)

I couldn't find the technique used above the fold (or a short way below).

Is this something more (and something more interesting) than just standard spawned process inheriting the parent process environment?

IOW is this actually injecting in the true sense of the word? Because that'd be interesting.

Totally.

Ideally it'd go like this:

Offer services for free (eg cross-subsidized by another business arm) in order to carve out a gigantic kingdom with millions of users, smothering any competition (only few use an indie email provider when there's "free" email, only few try to make a stand not using Whatsapp in whatsapp-saturated locales), and... Congratulations, now you've become too big too fail! And now you'll be treated as such. You're a critical part of society's functioning, and are to be regulated as such. Whether by accident, whether intentionally, whether it's because you're simply awesomely innovative or maybe you just massively cross-subsidized from another business branch, is irrelevant.

Once market capture has reached a certain point, yes, you need a physical grievance office, with state-backed arbitration/escalation. For instance.

Maybe you also can't just change the TOS anymore just like that, making people choose between coordinating a hasty move of the families' 4 TB of photos to... ? and being slowly boiled while $BIGBOY AI-trains on the family photos.

As a big boy, don't like this kind of regulation? Just shrink by selling off some business arms. Or stop hooking people by giving out "free" stuff. Or maybe don't base your growth strategy on gatekeepership and moats.

I surmise that big rules for big boys (while not burdening small players, thus, differential legislation) will actually massively help competition and innovation. But even if it doesn't — government, by the people, for the people, should get the final say in how we let citizens be treated. People with beating hearts over emotionless corps, always.

From memory from working with these a couple of years ago:

Firefox extension asset URLs are random and long (there's a UUID in there iirc). The extension itself can discover its randomized base so that it can output its asset URLs, but webpage code can't.

Use fans. They don't like flying around in wind and they don't know where to fly to anymore because the fan disperses the CO2 you produce so quickly that there's no gradient for them to follow to the source (you).

There's GeckoView which one'd use for embedding Firefox in an Android app. Can't use that on Sailfish OS of course, but it'd help in figuring out what of core Firefox to bind to to make a similar layer.

As for the permissions, using ACLs would work better here. Then you don't need a separate group for every grouping.

try:

  sed 's:SSH/HTTP/3:SSH over HTTP/3:g'

At least with GNU sed, you can use different separators so dodge the need for exscaping. | works as well.

Totally. Furthermore one can input that (now broken) URL into the Internet Archive to see if they might have snapshotted that red stapler page.

For SSH specifically (ssh user@host "command with args") I've written this workaround pseudoshell that makes it easy to pass your argument vector to execve unmolested.

https://crates.io/crates/arghsh

Great, but I would've been happier if I'd had some dead simple dependency tracking 10 years ago. Just enough to create metabug functionality with. Like Bugzilla, Trac, Mantis etc have sported for at least two deades. I've always wondered why Github didn't have such basic functionality. (No, just the ability to reference other issues is not enough; I want to get an email for the metabug when all blocking issues are resolved).

I'm running LineageOS, rooted, with MicroG' Safetynet emulation (of sorts?). So a build signed with userdebug keys.

Some banking apps just work - two with warning on first launch, and one just doesn't care at all.

Two refuse to run and I have an old unrooted phone for them. Resulting in me being a good customer of those three banks that are not fussy.

So try and see, perhaps things just work!

Even if you enforce SSL-only on inbound mail, you're still vulnerable to the downgrade attack (or rather: the "prevent upgrade to TLS attack") - someone can MITM, and the sender will be speaking non-SSL to the MITMer, who'll speak SSL to you. To you things would look fine. Enter MTA-STS, with which the sending mail server can deduce that no, things are not OK.

Or are you saying you're not doing STARTLS at all and servers delivering mail to you have to do an SSL handshake before getting to speak SMTP to you? I'm quite surprised if that's compatible with the wider SMTP world.

I think the use case is ad-hoc, as described on the page. I think the author may know about syslog, but this ad-hoc approach is useful when something such as syslog is not set up correctly and you can't fix it right there and then. This allows you to investigate and fix some bug over the weekend without having to involve others or other bureaucratic domains.

One can resolve "localhost" (even via an upstream resolver) to an arbitrary IP address. At least on my Linux system "localhost" only seems to be specially treated by systemd-resolved (with a cursory attempt I didn't succeed in getting it to use an upstream resolver for it).

So it's not a rock-hard guarantee that traffic to localhost never leaves your system. It would be unconventional and uncommon for it to, though, except for the likes of us who like to ssh-tunnel all kinds of things on our loopback interfaces :-)

The sweet spot of security vs convenience, in the case of browsers and awarding "secure origin status" for .internal, could perhaps be on a dynamic case by case basis at connect time:

- check if it's using a self-signed cert - offer TOFU procedure if so - if not, verify as usual

Maaaaybe check whether the connection is to an RFC1918 private range address as well. Maybe. It would break proxying and tunneling. But perhaps that'd be a good thing.

This would just be for browsers, for the single purpose of enabling things like serviceworkers and other "secure origin"-only features, on this new .internal domain.

From the first three lines of the linked-to paragraph:

> Hurl can run HTTP requests but can also be used to test HTTP responses. > Different types of queries and predicates are supported, from XPath and JSONPath on body response, to assert on status code and response headers.