Surely there is something interesting that can be done with something that has such unusual properties, even if it's a corner case. It's basically a single-use "transistor" or "valve" for mechanical force.
Does the glass explode with enough force to be used as the primary detonator for a high explosive? I'm no explosives engineer, but seems like having an all-mechanical (no chemicals, no electricity) primary detonator could be useful in some situations where the system should be very stable for decades, like car airbags.
What about emergency release valves? Plug the release channel with the tough end of the drop. Use a simple mechanical system to break the weak end if the emergency conditions are met. e.g. a lever attached to a float that snaps the weak end if the fluid level is too high. That should work safely even in an environment full of flammable material.
Getting into more fanciful territory, could a professional assassin create one that was large enough to work as a hand grenade? Or encase the weak end in a jacket and then use it as a bullet with the tough end being seated in the case?[1] Seems like it could almost be a real-world version of the mythical "ice bullet", where after use there wouldn't be enough left for forensic analysis.
[1] Here's a video of someone shooting them from a shotgun, but there's no jacket or spin-stabilization to keep the weak end pointed at the target: https://www.youtube.com/watch?v=lc9pPOrZ_0Q
It's only useless if you consider all art, games, and educational tools to be useless. Which is a very sad outlook.
Art: they look beautiful and can be displayed.
Game: breaking it, or watching it being broken, is a lot of fun.
Education: I would say that a huge number of people have been inspired to take up glassblowing after seeing one of these. But not only that, they also serve as a great tool to demonstrate that an object's physical properties are often unexpected based on appearance. I would say a decent amount of people have been inspired to study physics because of this too.
Sounds like you had better luck than I did. After about a year of getting DMCA notices, Hetzner told me to remove my IPFS gateway from their network or they would kick me off.
I followed the DMCA process, added nginx block rules to make all the content mentioned in the DMCA notices impossible to access, and even submitted "statements" to Hetzner for each DMCA notice they got. None of that saved me.
i prototyped this using two windshield motors (powerful worm gears for cheap) and two slip rings to transfer power / position data between the arms
it looks awesome but I need to work on making it easier to produce by figuring out a better way to sense where the connecting arm is (hall effect?), and do more work to account for backlash in the relatively inexpensive / tolerant worm drives
i built one that rotates about the hour hand and another the rotates about the minute hand to try both ways out; it's pretty cool to see the whole thing swing around once an hour but probably not something you want in a home...
This is impressive, but if you care about privacy then why are you using MacOS to begin with? It seems like you could never be completely certain that it is safe.
Rather than starting with a closed system and ripping out the parts that spy on you, why not start with an open system like Linux or OpenBSD?
I don't think privacy is such a simple scale like this. I actually trust my macbook to be more secure than my Linux desktop. Apple has spent orders of magnitude more securing this device, while my Linux desktop setup is mostly only ensured to be generally working.
If anyone with the smallest amount of skill had physical access to my desktop, they could replace the bootloader with a malicious one and get everything when I next log in. While my macbook is secured against basically everyone but top tier federal agents. If I left my macbook in a hotel room, I can reasonably expect it has not been tampered with.
There doesn't seem to be any real version of SIP on Linux. Basically every program I run requires full access to everything. Flatpak is sort of tightening things up but it still has a long way to go to close all the loose ends.
So while I might have more control over my linux machine, I still trust my macbook more.
Out-of-box, you're generally right. "Hacking" the average Linux user with Secure Boot disabled and a default GRUB configuration with unencrypted ext4 root is like taking candy from a baby.
It does beg the question of which system can be more secure, though. Apple has a decently high bar out-of-box, but they could certainly do more to make MacOS a trustless ecosystem. The simple fact that all of MacOS is basically unaccountable from a programming perspective is both a security flaw and a privacy concern. Whereas a public codebase like Linux receives constant intersectional scrutiny, closed systems like MacOS can't have that same attention. Non-transparent codebases cut both ways: they can hide embarassing bugs from people reading the source, but it can also protect zero-days and backdoors that would have otherwise been identified and fixed. Transparent systems only seek a ground truth.
So... it's a toss-up. I wouldn't put my life on the line if I was a political dissident considering a Macbook, but Joe Shmoe and his wedding photo editing business should have all the security it needs.
GNU Linux desktop can’t be made more secure than a Mac in my opinion, without having to rewrite the whole thing to the point where calling it general linux desktop is a stretch. But this is not an OS property - if one would install Android, then the security would improve severalfold, likely better than OSX (mobile OSs are much more modern and security oriented). The reason is that the old-school UNIX permission system is way too crude. The minimum is to run every process under a new user, so that its permissions would even start to make sense. SELinux is also important, as well as secure IPC. Android has all that solved.
GrapheneOS on sufficiently secure hardware (! Unfortunately open-source laptops are very bad in this category), which has to be a Pixel for now trades blows with iphones.
The Linux security model was designed for a time when you had multiple humans sharing one machine, and every program either came from the OS, or was sourced from a reputable origin. It's almost useless in the current landscape. Some efforts like Flatpak, Wayland, Pipewire, and immutable OSs are starting to improve things, but it still seems like we are years away from having the level of security MacOS had a long time ago.
And I just can't see how any security measure which requires hardware can come to Linux desktop.
> And I just can't see how any security measure which requires hardware can come to Linux desktop.
Why? TPM works just fine. Secure Boot is perfectly usable on most OSes. Hell, even fprintd supports biometric authentication if you're a weirdo. Nothing inherently stops this stuff from being made, certainly not the kernel.
All hardware-based security measures will probably never be supported by Linux, but if your benchmark for disbelief is "any" then boy have I got a boat to sell you!
It's not the same. There are definitely people who try to exploit both OSes, but the conversation around securing them couldn't be more different. MacOS is developed in the "Cathedral" style - closed source, with a small group of contributors who assume responsibility for everything (including security response). Linux is developed in the "Bazaar" style, with patches being freely distributed and incrementally contributed by the community for each release. This represents a fundamental change in how security is handled; Linux can merge a fix as soon as it's available and passes review. Mac issues must be reported by a user, passed to an Apple engineer, located in the codebase, fixed, and then reviewed before it can make it into a Rapid Security Response patch. Apple's system is less transparent, often slower, and overall more convoluted than developers and users pointing to the spot that's broken.
I want things to work this way, but often they do not. Often what happens on the Linux side is that the security patch, if any, gets silently put into the tree without disclosing that it's a security patch, and downstream never pulls it in. There have been numerous instances of kernel maintainers asking people to water down their commit messages so they don't sound as bad as they are :/
This doesn't mean Apple does everything right, of course, but the situation on the other side frequently sucks too even though it nominally should not. And given various choices in their ecosystem (lack of fragmentation, for example) they can and do end up with a better security story in some areas.
Definitely, there are pros and cons to each process. They are markedly different, though - Apple wants secrecy, whereas Linux demands transparency. Sometimes patches are rejected or ignored, but transparency is never compromised. This gives insight into how patches are accepted or rejected (eg. the Paragon NTFS), information that isn't public in Apple's process. The separation of users and "blessed" developers remains an enormous roadblock to effectively scrutinizing and quickly fixing Apple's software platforms. It offers some protection, too, but it is a night-and-day difference to how things are handled in the Linux world, dysfunction and all.
I'm not sure if the MacOS codebase gets as much review as Linux, but what makes MacOS more secure is that they utilize multiple layers of security. Finding a bug in a single component is often not enough. Which is why even after countless bugs found in macos and ios, we never see things like the secure enclave and encryption keys compromised, because they are layered out and unaffected by bugs in the OS.
We are at the point where being bug free is impossible and patching after discovery is not good enough. Secure designs must protect against undiscovered bugs.
You could custom-build a special version of MacOS that runs entirely in userspace, but unfortunately it would never be as secure as a properly-configured Linux system. The default on MacOS is a venerable effort, and a powerful standard to enforce across an entire line of devices. Apple does not give the user enough control to protect them against Apple themselves, though.
There are certainly security and convenience scenarios where MacOS is hard to beat, but no trust-based system can ever be the final say in security.
And I'd happily run them if the hardware situation wasn't so damn grim. There's no Arm booting standard so you have to re-invent the kernel for each model of chip vs just booting an x86 PC and let the kernel poke at discoverable hardware and figure it out. Arm has old-school ISA like configuration for your non-discoverable hardware with devicetrees preventing generalized kernels from existing.
Someone please make open booting and hardware configuration for a general OS on Arm a reality. Without standard booting I feel that open source OS phones will never exist. They're always behind on driver development leaving users with buggy battery murdering devices that are missing features. Dev's don't want to bother with messy alpha quality platforms. They move slow as they don't have FAANG money so the platforms never gain momentum. Simple general booting will change that - no more recompiling a kernel using some byzantine labyrinth build system - just write an image to SD or USB and boot.
I am wrong there, they describe non-discoverable hardware so they are useful.
I am confusing them with the issue of getting a kernels built for a lot of the poorly documented hardware that varies a bunch which device trees try to solve but don't. No two vendors agree on how to boot things. I cant just download ubuntu or even openbsd for my phone or tablet as each of those has its own boot loader. Too splintered of a platform.
Thanks for your response. It’s an interesting perspective. From my point of view the idea of having incompatible boot protocols is a feature, not a bug. Fundamental differences must exist at some point in the hierarchy. Why not the boot mechanism?
The SoC is its own static architecture - each vendor sells its own little computer system complete with booting methods. Since the hardware is static there is no need to implement a configuration mechanism which also acts as a discovery mechanism (like PCI). So we can't build a kernel that asks the SoC "Whats inside", instead, the device tree is a list of what hardware exists and where it is mapped in memory.
And that hardware might not be standard or use weird register layouts that don't match other commonly used layouts in other similar devices further complicating the porting effort. The SoC might have a unique USB controller or Ethernet MAC or whatever that needs a new driver. Just lots of duplicated effort for each "new computer" when its all the same hardware inside. And its like this because SoC's are low cost disposable chips - no one cares if you cant port a new kernel because by the time you want a new kernel the thing is already obsolete and expected to be disposed of and replaced with a new gadget.
What could be done? Setting standards for hardware registers - similar to how PC vendors like Intel and Microsoft standardized the dumb basics like ATA, USB, Ethernet, Serial ports and so on. Set standards so we don't need to re-write drivers for every new chip released. Then standardize the boot firmware so the device can boot-strap the hardware to the point where it can load a kernel image via a debug interface, thumb drive, emmc, sd etc. Let the device boot hand the OS its device tree - done.
Why wouldn’t they? They can analyze it as much as they want even if it’s encrypted (by them), while not doing so would just open them up to to the legal ramifications of data leaks.
> not doing so would just open them up to to the legal ramifications of data leaks.
They can already protect themselves by using pseudonymous IDs, and by not storing SSN and full names on the same system/network as your browsing history.
I'm struggling to come up with a general example where an adversary would be prevented from accessing the data if they had already compromized the network, so to me, it's just obfuscation with extra steps. Maybe if an adversary, by some miracle, had a non-root shell in database server, but somehow did not have read-permission on the crypto store ???
Physical theft of drives is a valid argument, but even that is a weak one. The data center facilities are very secure.
End-to-end encryption doesn't secure anything if you don't control the keys. I'd believe they encrypt the data at rest, but I wouldn't ever dupe myself into believing that makes it safe. So... we're back around to square one. Apple will steamroll over your privacy (along with 10s of thousands of other freedom-loving Americans) without a second thought.
It could be worse, though. If you're a Chinese iCloud user, your data just gets uploaded right into state-owned servers: https://support.apple.com/en-us/HT208351
Why not start with an open system like Linux or OpenBSD?
Probably because they were traumatized by how much extra work that was (and for a sub-par desktop experience overall), last time they went down that rabbit hole.
> Probably because they were traumatized by how much extra work that was (and for a sub-par desktop experience overall), last time they went down that rabbit hole.
I’m in that camp. I ran Slackware on a Compaq laptop in the early 2000’s and it was more work than I would have liked — though I did have more free time then as a student.
I swapped to macOS and have been using that since for work and personal productivity projects, though I do use windows to play games. When my MacBook went on the fritz, I was forced to become acquainted with WSL. And I find it to be pretty usable for my use cases.
My MacBook is a bit aged at this point and probably needs replacement before too long. But now instead of comparing OSes (Linux or windows with WSL vs macOS), I need to think about hardware: battery life, build quality, and performance; my needs in these categories may still favor Apple in the laptop and small form factors.
If you mean the default experience, no. Gnome, Xfce, KDE, LXQt, Lumina, DWM, etc are all in ports and packages and fairly straightforward to get set up.
It wouldn't matter if you used a filter and your gateway didn't host copyrighted content.
The ciu-online.net application doesn't check whether or not the content is accessible through your server before sending a notice. It sends notices for all content that might be on the IPFS network.
Yeah, I took ipfs.slang.cx down after Hetzner threatened to kick me off their service.
I was able to stay on top of the takedowns by writing a script to create & deploy nginx block rules for each URL in the DMCA emails. Obviously I had no time for manual review of the URLs. But I guess that didn't matter and Hetzner got annoyed with all the emails and decided my business wasn't worth the trouble.
How did Hetzner become aware of the notices? Were they CC'd to them?
I ask because I'm building a web site currently hosted on Hetzner that will provide access to files that have fallen into the public domain, but also files that for all intents and purposes appear to copyright orphans. I will take down anything where an entity asserts a valid copyright against anything where a mistake has been made, but I don't want Hetzner just arbitrarily shooting down my site.
First the ciu-online.net people sent DMCA notices to myself and Cloudflare, since I used Cloudflare as a caching proxy. Eventually Cloudflare gave them the IP address of my server and the ciu-online.net people were able to determine that IP address was owned by Hetzner.
Now they send DMCA notices to myself, Cloudflare, and Hetzner. I think the goal is to annoy as many people as possible. Even after I shut off my IPFS gateway they continued sending notices.
Anyway, if you're hosting anything that might generate a DMCA notice, don't use Hetzner. They will kick you off even if you're complying with the DMCA process. Also, they make you submit a statement on abuse.hetzner.com for every single DMCA notice that gets sent to them. If you don't submit the statement in 24 hours they threaten to block your IP address. It is extremely tedious and annoying.
>Eventually Cloudflare gave them the IP address of my server and the ciu-online.net people were able to determine that IP address was owned by Hetzner.
Wait... isn't the point of paying cloudflare to prevent DoS attacks?
I guess if you want to do a DoS attack, send a few bogus DMCA notices to Cloudflare first to get the real IP of the server they're supposed to be protecting. Then you can hammer the server directly without Cloudflare getting in the way.
No trail leading to the DDoS attack, which would be executed by a botnet from compromised home computers, and paid for in bitcoin passed via a mixer, or something.
>Wait... isn't the point of paying cloudflare to prevent DoS attacks?
Hahahahahaha..
Cloudflare exists to get in the way of your users from accessing your site and you who are trying to run a site. They claim to be an anti-DoS service but I've never seen any evidence they actually do that. I still get Cloudflare messages a plenty that the website is down. And of course that moronic time waster where it wants me to perform a captcha constantly without actually serving the captcha.
They do provide a pretty decent anti-ddos service. They regularly sink gigabytes of traffic before it hits our origin servers. There's lots to complain about them, but this is something they actually do well.
Don't know why it didn't work for you, but there are a few things that can trip up ops.
That has not at all been my experience with Cloudflare. At a previous job, it took us just a few hours to set up and configure all the options and WAF details, etc., then they took our drive-by probes and bot spam from thousands per day to near zero. Over the course of the next year, we had less than 3 reports of blocked access from real humans; one was traveling and another was behind a shared IP organization. Is it possible some customers were blocked and left frustrated without ever telling us? Yes, but that business kept growing, and it was in an industry where most of our customers were repeat dealers that would let us know very quickly if they couldn't access the website. So if there were false positives, there weren't many.
Cloudflare saved us immeasurable time vs manually configuring firewalls and blackholes and honeypots and open-source lists -- all for $20/mo. It was an amazing service. And they blew their competitors at the time out of the water (Imperva, etc.)... much higher quality blocking at like 1/10 the cost.
If you see a Cloudflare message that the website is down, well, chances are the website is down. If they set it up a certain way, Cloudflare may have been able to cache some pages beforehand, or not... but either way, it's probably not Cloudflare's fault. The site probably would've been down even more often without Cloudflare, just without the CF error page. (That said, DNSSec is a pain and can often cause issues with Cloudflare and other proxies)
As for hCaptcha, I don't think I've ever had an issue with it (besides being unable to tell what something was, I mean)... did you have JS turned off or strict third-party blocking, perhaps?
Weirdly most of my pirated IPFS content is hosted by and served directly by Cloudflare’s own IPFS cache. I can choose which IPFS gateway to download the content from and I always click “Cloudflare” because it’s ridiculously faster than the rest (thanks to Cloudflare caching/serving it).
Didn't they voluntarily ban The Daily Stormer? And while horrible, I don't recall there being anything illegal about that, whereas IPFS likely requires them to take manual action repeatedly to avoid legal penalty.
It wasn't exactly "voluntarily" -- more like "banned it after sustained public pressure", I think. They were reluctant at first but eventually caved after pressure continued to mount. The CEO wasn't happy about it.
They defended them for a long time, and then banned them shortly after one of the Stormer admins started bragging that they had Cloudflare in their pocket.
CloudFlare will sometimes go to the court to actively protect their abusive customer from being exposed to legal liability. But apparently they don't do that unless you're really nasty and exposing you would mean they are actually able to provide information about their customers - that's a line they won't cross even for attempted murders.
Would it be unethical to send additional nonsensical take down requests to Hetzner? I mean, if you are going to be like a child and pretend every email is both true and in good faith the thing you really need is more outlandish nonsense so that one might mature? (make it less fun to host and more like hard work) Then again, Germany is just about the worse place to host "infringing" content.
Perhaps one should send regular take down requests to ones own host complaining about ones own website and point at example.com/<php echo $website[0]; ?> as the proof. Then change hosts if they chose to act weird on it.
I read "good" things about Hosted Network Pty. Ltd who in 2018 had a complaint response time near 20 days. "Worse" in the industry.
Thank you for the advice. I will shop around. The trouble is that Hetzner are almost an order of magnitude cheaper than the next best. You get what you pay for.
I would take a look around for eastern european hosters that dont really care for western bs and pick up a vps from there to use as a reverse proxy. You can continue enjoying hetzner and still be insulated by putting it behind a different server that will get (and toss) any abusive takedown requests.
The lowendtalk forums are a good place to find any number of hosters that will fill your need.
Don't directly expose your servers to the web, proxy them through some other provider so that whenever that provider falls under pressure you already have the infrastructure to move to different ip addresses and you don't have to deal with the hassle of migrating your data to other servers.
In this case the URLs contain valid IPFS hashes. The ones that I've tried all resolve to real files with the IPFS CLI.
The issue is they've never been requested from the gateway that the DMCA notices are being sent to. They might be blocked by the gateway, they might fail to resolve on the gateway for other reasons, or they might work. Nobody checked before sending the complaint.
These are actual hashes for books that exist somewhere on the IPFS network. You can get a lot of them to resolve. They've just never been requested from the site the DMCA notices are being sent to.
It's more likely that someone downloaded an IPFS hash list from LibGen and started sending emails generated from that.
These comments are easy to identify as ChatGPT because their style makes no sense in the context of a GH issue discussion. They're overly verbose and contain unnecessary caveats like "there may be other solutions that would be more appropriate depending on the specific needs of the project". Nobody who knows about the project they're commenting on would write that. They would mention what the other solutions are rather than being intentionally vague.
In another context, like SEO blogspam, this text wouldn't look out of place.
