Can’t wait for all the other horror stories getting posted here :D

Off topic: Why is there a “gift” code and various tracking paramters in the url?

Url does seem to work without them: https://www.theatlantic.com/politics/archive/2025/03/trump-administration-accidentally-texted-me-its-war-plans/682151/

IP based blocking is complicated once you are big enough

It’s literally as simple as importing an ipset into iptables and refreshing it from time to time. There is even predefined tools for that.

While AI crawlers are a problem I’m also kind of astonished why so many projects don’t use tools like ratelimiters or IP-blocklists. These are pretty simple to setup, cause no/very little additional load and don’t cause collateral damage for legitimate users that just happend to use a different browser.

No need to do that, you can simply scroll down to the footer and find the current version there ;)

With F-droid you trust F-droid to build the binary from the developers’ source code

Not when using a self-hosted F-Droid Repo - which is the case for Ironfox.

because it takes a like 3 or 4 minutes to boot

What kind of PC is this? Does it have an SSD?

saying there are unspecified “known vulnerabilities” within Signal

His source: Trust me bro

There are some more privacy friendly forks of “Firefox for Android”, which have sponsored shortcuts disabled or minimized by default. For example:

• https://gitlab.com/relan/fennecbuild
• https://gitlab.com/ironfox-oss/IronFox

Feel free to give them a try :)

The same apps that have access to more of your data (because they’re not sandboxed in a browser), use electron (ships a browser) and include trackers that one can’t simply block with an extension?

Yeah but have you ever tried to install it directly?

There is stuff like notarization that’s literally designed in a way that only Apple approved software can be run on your machine.

Has since been removed.

Here’s the original.

Short answer: Google Play

Long answer: Google Play and/or people with special requests like https://lemmy.ml/post/12332630

I also want to highlight Florida - which has around 10 different electric grids…

Well from my personal PoV there are a few problems with that

1. You can’t detect all credentials reliably, they could be encoded in base64 for example
2. I think it’s kind of okay to commit credentials and configuration used for the local dev environment (and ONLY the local one). E.g. when you require some infrastructure like a database inside a container for your app. Not every dev wants to manually set a few dozen configuration entries when they quickly want to checkout and run the app

I also personally ask myself how a PyPI Admin & Director of Infrastructure can miss out on so many basic coding and security relevant aspects:

• Hardcoding credentials and not using dedicated secret files, environment variable or other secret stores
• For any source that you compile you have to assume that - in one way or another - it ends up in the final artifact - Apparently this was not fully understood (“.pyc files containing the compiled bytecode weren’t considered”)
• Not using a isolated build process e.g. a CI with an isolated VM or a container - This will inevitable lead to “works on my machine” scenarios
• Needing the built artifact (containerimage) only locally but pushing it into a publicly available registry
• Using a access token that has full admin permissions for everything, despite only requiring it to bypass rate limits
• Apparently using a single access token for everything
  • When you use Git locally and want to push to GitHub you need an access token. The fact that article says “the one and only GitHub access token related to my account” likely indicates that this token was at least also used for this
• One of the takeaways of the article says “set aggressive expiration dates for API tokens” - This won’t help much if you don’t understand how to handle them properly in the first place. An attacker can still use them before they expire or simply extract updated tokens from newer artifacts.

On the other hand what went well:

• When this was reported it was reacted upon within a few minutes
• Some of my above points of criticism now appear to be taken into account (“Takeaways”)

Just for further clarification, the API works like this:

• time is the local (client) time (in this case UTC-7)
• servertimezone is the time zone where the server is located
• timezoneoffset is the offset of the local time relative to the servertimezone (offset from the servers PoV)

To get the UTC date you have to do something like this:

time.minusHours(timezoneoffset).atZone(servertimezone).toUTC()

Well if it’s a 32bit timestamp you’re screwed after 19 January 2038 (at 03:14:07 UTC)

So just for additional context:

This meme was brought to you by the following API response scheme:

{
  "time": "2007-12-24 18:12",
  "servertimezone": "Europe/Vienna",
  "timezoneoffset": -8
}

when it could have just been

{
  "date": "2007-12-24T18:21:00-07:00"
}