chiisana @ chiisana @lemmy.chiisana.net

Posts

4

Comments

500

Joined

2 yr. ago

There is no “hard” limitation differentiating guzzling down a gallon of gasoline vs a gallon of red wine; nor is there any “soft” limitation of deploying your own OS.

Vast majority of people do not possess knowledge to extract consumable ethanol from gasoline, doesn’t mean it is impossible.

Vast majority of people do not possess knowledge to attempt to deploy their own OS onto an iPad, doesn’t mean it is impossible. Very talented individuals have been hacking iOS boot loader since original iPhone (no version, no suffix) days.

If one are so inclined, there’s plenty of places to learn, and expand one’s knowledge to attempt what most aren’t able to do. The alternative? Bitch whine complain and repeat until a multi-trillion company give a damn. I ain’t holding my breath.

Both 87 grade gasoline and typical red wine contains about 10% in ethanol. The limitation isn’t the ethanol. Let the users decide whether they want to consume it…? No! Just like the gasoline refineries did not make it with intention for human consumption, Apple designed the iPad hardware for a different use case than what you’d like.

Just like how the gas station attendant will tell you that you cannot consume gasoline at the gas station, Apple will tell you that you cannot run macOS at the Apple Store. If someone wishes to attempt it, there’s nothing preventing them from buying gasoline, taking it home, and attempt to consume it in their home. If someone wishes to attempt running macOS, there’s nothing preventing you from buying it, taking it home, and attempt to hack macOS onto it.

Gasoline isn’t the product for someone wanting to get drunk; just like how the iPad is not a product for you because it doesn’t fit your use case, and that’s fine. You can always wait for when they inevitably release the M4 variant of MacBook (or MacBook Air if weight is a concern), which will fit your use case better.

There’s two ways around the symptoms you’re trying to treat:

1. Don’t bother with internal vs external. Always route through external which gets encrypted by the origin cert to CloudFlare and then CloudFlare to your browser. This is simplest in that you don’t need to manage two sets of DNS records and you don’t end up with different certificates for the same domain (in the odd event where you end up needing to do something like certificate pinning). Or;
2. Just add the origin cert to your systems’ trust store. You know the certificate, it will encrypt the traffic anyway, also you’re accessing the service via intranet so there’s really no attack vector here.

Probably worth calling out that although 1 feels like there’s more hops (and there absolutely are), with any decent internet, you’re probably not going to feel it. This is because the edge server is probably situated very close to your ISP (that’s how they make sure everything responds quickly) so your over all round trip should only be affected by a negligible amount of time that you most likely won’t notice.

There was similar things done on Reddit during the big exit. I doubt it achieved what people expected it to achieve. Even if they’re not visible externally, I’m sure they can easily access (thereby make deals to license) the data out of their backend / backup; just a matter of how hard they want to try (hint: it’s really not very hard).

PoGo model update has entered the chat.

The RAID rebuild time is going to be longer than the OEM warranty… love it!

When I was younger, I bought a fair bit of music CDs, mostly for the sake of collecting. To this day, most are still unopened in their original plastic wrap. I no longer have a disc player in any of my computers, nor any functional discman left in my possession, so listening/ripping them is probably never going to happen.

Sometimes I see people complaining about digital versions, but looking back, it probably really don’t matter nearly as much for vast majority of the cases…

Fortunately, you’d be very hard pressed to find bandwidth pricing from 18 years ago.

The point is the claimed issue is really a non issue, and there are much more effective ways to stress websites without needing the intermediary of fediverse.

AWS charges $0.09/GB. Even assuming zero caching and always dynamically requested content, you’d need 100x this “attack” to rack up $1 in bandwidth fees. There are way faster ways to rack up bandwidth fees. I remember the days where I paid $1/GB of egress on overage, and even then, this 100MB would’ve only set me back $0.15 at worst.

Also worth noting that those who’d host on AWS isn’t going to blink at $1 in bandwidth fees; they’d be hosting else where that offers cheaper egress (I.e. billed by megabits or some generous fixed allocation); those that are more sane would be serving behind CDNs that’d be even cheaper.

This is a non-issue written by someone who clearly doesn’t know what they’re talking about, likely intended to drum up traffic to their site.

If you’ve skimmed over the original publication, it is actually worse: it is a non problem. Other users have pointed out already: ~100MB served over 5 minutes period is quite literally nothing for even one small VPS serving the content independently, let alone a site with CloudFlare in front like they claim to have.

Or 4) Ignore noise and do nothing; this is a case of user talking about things they don’t understand at best, or a blog intentionally misleading others to drum up traffic for themselves at worst. This is literally not a problem. Serving that kind of traffic can be done on a single server without any CDN and they’ve got a CDN already.

I think this might work, I haven’t done it for too long to know for certain if two same plain text encrypted with two same public key would yield two identical encrypted blobs.

I’ve self replied another possible implementation, that I’m pretty proud of figuring out literally 1AM. If you have time, please do give it a glance and see if you can spot any weakness.

Aha! Something just clicked — been thinking continuously since before the original reply. The answer is … more signing and maybe even more keys!

A message would be signed multiple times.

If Bob wants to send Alice “Hello, how are you?” the plain text would be signed with Bob’s general private key that could be verified with Bob’s general public key. This would allow Alice to forward this message to anyone while they could still verify it did indeed came from Bob.

The plain text and signature is then encrypted with one of Alice’s public keys, so only Alice could decrypt it to see the message and signature. This may be a thread specific key pair for Alice so they’re not re-using same keys between different threads.

The encrypted message is then again signed by Bob, using one of Bob’s private key, so that Alice can know the encrypted message has not been altered. This here could also be the thread specific key as noted above.

If Alice were to report Bob, Alice will need to include both the plaintext and the internal signature. This way the internally signed message could be reviewed if the plaintext and signature were forwarded to moderation for review by Charlie (just need to verify the signature against plaintext with Bob’s public key), while the exchange should be secure to only Alice and Bob.

Et voila!

Been forever since I did any work with cryptography, but if my memory is correct:

Alice needs Bob’s public key to verify a signed message from Bob haven’t been altered;

Bob needs Alice’s public key to encrypt a message that can only be decrypted by Alice;

If Bob sends Alice a message encrypted with Alice’s public key, signed with Bob’s private key, containing “Hello, how are you?” ; this message could be verified as authentic by Charlie using Bob’s public key but Charlie cannot see the contents of the message as Charlie does not have Alice’s private key.

Without Alice disclosing their private key, how can Charlie review the content of a reported message from Alice claiming Bob sent them something inappropriate?

I.e. how can Charlie be certain if Alice claims Bob sent “cats are evil” when Charlie cannot decrypt the original message, only verify the original message have not been altered via Bob’s public key.

If you’re feeling that it will take too much time to maintain something you’re deploying, then there may also be toolset/skillset mismatch. Take Docker/K8s that you’ve called out for example; they’re the graduated steps to deploy things in the industry. Things deployed via Docker drastically reduces the amount of time to get up and running by eliminating large swaths of dependency management, as well as gives option to use tools on platform to manage self updates if that’s something desired (though this could potentially introduce failures by manual upgrade steps where required). You’d graduate to k8s as your infrastructure footprints start to grow. Learning the correct tools could potentially reduce the barrier to entry and time requirements on the apps front.

Having said that, it is probably better to ask the inverse: what is it that you’re trying to achieve and why?

Without a reason that resonates well with you, you’re not going to find time in your allegedly already life to maintain to keep it working. Nor will you be willing to find the time to learn the correct tools to deploy these things.

I played with it forever ago, but from memory, that is most likely due to the way it is designed to conserve battery. The app waits for significant location update notifications from the OS and then sends the updated location to the tracking server. It doesn’t (or I should say it didn’t as I don’t know about now) actively poll the location on fixed intervals.

Have you seen OwnTracks?

Not necessarily just yaml — there are things yaml cannot do well, but even ignoring that, traefik can also use toml, or container labels — but rather, the entire concept of infrastructure as code is way better than GUIs. Infrastructure as code allows for much better linting, testing, and version controls thereby providing better stability and reproducibility.

Having seen some spicy pillows in my times… I’d hate to be onboard if any of the battery containers becomes a bouncy castle.

Most providers offer some kind of OS reload and you may be able to use custom ISOs for the process. However, that doesn’t change the fact that if you don’t want to change OS (especially if you’re already using something more commonly seen in production environments like Debian), then you shouldn’t change the OS.