Several years ago I was looking for something to use as a family chat server. Many of my friends/coworkers were using Slack/etc., but since my immediate family members didn't already have a preferred chat app, I was hoping to self-host something open-source. Matrix was under very active development at the time and I was pretty excited about the prospect of using it. Matrix didn't even have E2EE yet (I think it was under development), and that really wasn't a feature I needed or cared about (disappointing to read about all the trade-offs involved in this post though). The computational/storage costs for Matrix really were way too burdensome though. I ended up going with Jabber (Snikket). A jabber server costs essentially nothing to run. Highly recommend.
I don’t really have a dog in the fight so to say (aside from running a relatively large IRC network for the passed 22 years)…
But I really do wish we had doubled down on XMPP. It was nearly everywhere in the late-00’s early-10’s. If we could have just solved the mobile case (which, was solved, just not in popular server versions) then we would have been in a better place today.
Hatred of XML has cost us so many wonderful things, the one that hurts me most is SMF (the solaris init system) which obviated the major issues people have with systemd. Except because it’s using XML people would rather carve off a limb over seriously considering porting it.
Now that i'm looking back at xmpp, i agree that i wish we would have doubled down on xmpp - either to make some things easier for hosting, etc. And, yeah, its funny that you mention about the hatred of xml...i never loved it, but never hated it. Same with json, etc....To me they're just data formats...but so much dislike seemed the cool thing to do back in the day. Ah, well.
It’s so easy to host, and I once implemented a partial in-browser client (using, basically, a web bridge that I also wrote on the other side) in no time, starting from not knowing a single thing about it aside from having used xmpp chat clients in the past. Like getting to the point of status online/offline indicators showing up and messages passing was so easy. I get that I was a far cry from supporting things like encryption extensions, but it’s a great sign when going from nothing to having at least some of a protocol working takes very little time.
The web platform’s still (for now) really good and fast at working with xml. Kinda wild we ended up with json everywhere.
My point was that "lack of investment" doesn't explain the standstill. If that would be the determining factor IRC should not have seen or should not be seeing any progress either. But we actually do have IRCv3 extensions and quite a few new implementations here and there.
There's something else hindering XMPP that it stands so still, alternatively it simply can't be improved.
> ...The computational/storage costs for Matrix really were way too burdensome though. I ended up going with Jabber (Snikket). A jabber server costs essentially nothing to run...
Your experience seems to mirror my own. I still use matrix very little, but have defaulted to use xmpp. Well, really returned to it after so many, many years away from xmpp. I tried prosody, but then after a multi-server cleanup killed it off. I think it was fine. Up next, i'd like to try either self-hosting my own ejabberd server, or if i don't want manage yet another host might consider the paid option of Snikket...or maybe go through jmp.chat which if i recall correctly includes xmpp hosting with some jmp chat paid plan, etc.
> my immediate family members didn't already have a preferred chat app
I am curious, how is this possible? Most non-techies seem to use the app that matches the app that is the most popular one in their area/demographics. For most, that would be Whatsapp i guess. How did you sell your app to your family?
I agree with you to a degree. I considered that as a reason as well, and "meeting people where they are" in communication design is something I think about a lot.
But if using an approachable format to deliver an alternative message was the strategy, I think we'd see a few places where the author tried to stretch the format slightly, to give a few core ideas more chance to resonate. In which case it could have been a masterful use of an antithetical format, to prove and point and enrich the message.
Instead, since the entire post conforms, it feels much more like an internalized autopilot, or purposefully manipulative technique.
Hah, that’s a good point. It’s always interesting to see somebody find a clever little bit of redemption for a widely disliked aspect in an article—nice.
Picture me in 2007. "The iPhone. Psh. Like I'm going to switch to Cingular and pay thirty dollars for a data plan!" (Keep in mind that's $47 in today's dollars!)
I would use my N800 and Bluetooth-tether to my Verizon flip phone when on the go. It was mildly useful for things like LiveJournal and I'm sure the Twitter of that time would have worked on whatever browser Maemo had. But I had to admit by 2008 that I wanted a smartphone instead of this second device with a stylus.
In those days though, browsing the web as though you were on a desktop was thought to be the goal to aspire to. Even the iPhone launched with the default behavior in Safari being showing whole desktop webpages, and you zoomed in to the parts you wanted to use. It took a year or two for people to figure out 'responsive' and within 4 years most sites were starting to be designed for small portrait screens. At that point the landscape N800 style was at a disadvantage since the mobile sites being designed to be a little leaner, were the wrong layout, but the desktop sites were pretty heavy for a mobile device to handle. And as "apps" ate the world that probably put the final nail on our little N-series.
I remember running around campus looking for WiFi hotspots with my N810, using Google Voice to text my friends ($0.10 per text, no thank you!). Learned so much Linux admin skills that became so useful later in life. Favorite device ever! Eventually moved to Android smartphones but the ease of hacking, the amazing community (internettablettalk.com, looks like its gone now :( unfortunately...)
Back in the day I just had a cheap dumb phone with the $15/mo unlimited 3G data add-on and popped that SIM into whatever other device I was feeling at the time. It seemed like if it wasn't a common phone in the US, Cingular/AT&T never noticed.
Does IDEA count? It's the same server underneath. I've been using it since support for it became available, maybe four months ago, and it's been pretty OK. Much faster, but there are some occasional crashes at least with incremental type checking enabled. The speed difference more than makes up for it.
Native phone apps give me the creeps. I assume the developer's are able to track me in various ways even without my giving permissions. Is that an unfounded fear on my part?
Can an app uniquely identify me if I don't give it
control over my phone number / nearby devices?
Can apps geo-locate me if the location permission has not been granted? (seems like they could just make a network request to their servers and use the IP address of the request for a rough idea).
I _really_ wish using the network was a permission (even if it was an "advanced mode" thing).
Android 15 supports Private Space [0] that is essentially a separate profile you can install apps into that you can put to sleep. Basically I put all low trust apps into it, but can still access easily enough.
Network is a permission on Android, it's just that phone manufacturers and likely Google don't want you to be able to control it. Most custom ROMs, including GrapheneOS expose it properly, often at the install dialog.
Some time ago, I used a module for Xposed on Android called XPrivacy which did exactly that. Yes, creepy app, you can have my location. It's Antarctica.
It does look like Xposed has successors, but my current approach is to just be selective about installing apps.
I use netguard and forbid network access by default for all apps. Mildly annoying for apps that need network access as I have to approve, but it's worth it.
The vast majority of apps need to use the network, at least sometimes. Eg turning network on to download podcasts then off to listen to them is annoying.
Depends on what apps you are installing. I love denying access to the network for games. It removes almost all ads from them. Even beyond full deny access, NetGuard gives you a lot around the conditions in which an app can access the network. I'd prefer if I didn't have to do any of this and the OS was on my side though.
On an unrooted Android you could use App Ops to do some of that with Shizuku.
I assume they don't expose it to users because once most people start to do that apps would start to implement detections, like if it spoof your location to a certain area then that area will get you "permission denied" error anyway, or I believe some apps do check that if your contact book is empty it assume you didn't give the permissions. It'd become a lot of work to implement a convincing spoof for most permissions to be blocked.
On play store you can see the permissions that an app uses and they are grouped by category. Have full network access is set in the "others" category, same as notifications and vibration. This is a category where (supposedly) permissions are automatically granted.
But to be honest, other similar dangerous permissions like "view network connections" and "receive data from internet" are also there, categories are for "camera", "microphone" etc.
I suppose that the average user is more concerned about specific features, and since basically almost all apps require internet it may be there to avoid noise.
Still, an "internet" category would have been nice...
The reason why internet access/downloading from the internet isn't a "major" permission is that asking about it would let people conveniently disable it for any offline apps with ads in them to remove the ads. Google doesn't like that, obviously. Of course, you can still disable your wifi/mobile data connection entirely, but it has friction that most average consumers won't trouble themselves with. But if the app asked if you wanted to give it internet access on launch, Google's ad revenue would probably be visibly affected.
In the beginning of Android / iOS, just installing an app and registering was enough for the company to get your device's MAC address and thus your indoor location with accurate precision.
They could access your Wi-Fi network's BSSID (whose location is often public due to wardriving databases), and in public places, they had partner companies (malls, airports, etc.) whose routers would triangulate your position based on Wi-Fi signal strength and share information like "John is in the food court near McDonald's."
All of this happened without you even needing to connect to their Wi-Fi, because your phone used to broadcast its MAC address if the Wi-Fi was simply on. But now your MAC is now randomized, but it took a lot of time for Google / Apple to this.
What do you mean? The MAC address is used to identify the device within the same network segment. A program running on the device cannot derive location information just from the MAC address. It's a meaningless number. What the MAC address can do is make you visible to other devices in the same network segment. So for example, a wireless router can know you're nearby because your known MAC address has joined the network, but this is a problem regardless of what apps your phone is running.
That's what the GP was saying, I think. Once they get the MAC address, they can find you. Not via software on the phone, from exfiltrating and using shady third parties that collect data from access points, etc.
Okay, but if there's collusion between the app developers and external routers then it doesn't matter if the MAC is randomized. The app can still see the current MAC address and report it, and you can still be located, if nothing else, to within the range of a wireless router. Nothing is solved by randomizing the MAC address.
An app can use the VPN API to intercept network traffic. This is all done with plenty of security popups (one to inform you an app is trying to register as a VPN, the another popup when it's first activated, and the while it's active there's a permanent notification that says "your connection may be monitored" with a quick button to kill the VPN).
The API is supposed to let apps do things like "route intranet/corporate app traffic over a VPN, let other traffic go through", but you can just as easily use it to drop traffic destined for certain addresses (such as ad servers), or to drop all traffic for specific apps. It's also possible to make decisions like "let this app connect to the internet on wifi but not on data".
It should be noted that system applications (phone OS, Google, sometimes carrier apps) can bind to specific network interfaces bypassing this API entirely. This means you can't use this API to 100% block internet access to preinstalled apps, even though apps will need to explicitly implement networking code to bypass such firewalls.
It should be noted that Google doesn't really like apps abusing the VPN API like this, in past because of the massive privacy risk. Google cut a bunch of these apps from Google Play, though there's not much they can do about APKs you download from F-Droid or github.
> should be noted that Google doesn't really like apps abusing the VPN API like this
Not really.
Only apps that use the VpnService and have VPN as their core functionality can create a secure device-level tunnel to a remote server. Exceptions include apps that require a remote server for core functionality such as:
- Parental control and enterprise management apps
- App usage tracking
- Device security apps (for example, anti-virus, mobile device management, firewall)
- Network-related tools (for example, remote access)
- Web browsing apps
- Carrier apps that require the use of VPN functionality to provide telephony or connectivity services.
> It should be noted that system applications (phone OS, Google, sometimes carrier apps) can bind to specific network interfaces bypassing this API entirely
Whilst this is true for Android (connectivity checks bypass VPNs, as do VoWiFi and Hotspot traffic) [0], other OSes are known to do the same thing: https://news.ycombinator.com/item?id=24838816
Their official policy (can't find the up-to-date link because Google's documentation bitrots faster than any other website on the net) over at https://archive.is/OPg2g clearly stated:
The VPNService cannot be used to:
•Collect personal and sensitive user data without prominent disclosure and consent.
•Redirect or manipulate user traffic from other apps on a device for monetization purposes (for example, redirecting ads traffic through a country different than that of the user).
•Manipulate ads that can impact apps monetization.
Google has also removed/threatened to remove prominent firewall VPNs for bullshit reasons (claims that apps violate random policies), though that may just as easily be random Google bullshit fallout every Android developer needs to deal with.
> Whilst this is true for Android (connectivity checks bypass VPNs, as do VoWiFi and Hotspot traffic) [0], other OSes are known to do the same thing: https://news.ycombinator.com/item?id=24838816
You're right, of course. Unless you own the kernel on every SoC running on your system (including the modem), you should always assume there's a possibility of network traffic leaking through firewall APIs.
On Android specifically, though, there is a significant chunk of users that will want to restrict the built-in apps because carrier-installed apps or shady Chinaware that come with cheap phones cannot be disabled by default. Other platforms usually don't have this type of malware baked into the OS in a way that cannot be removed. Apple's questionable privacy decisions are a lot less worse than what some people try to block with these firewalls.
> Google has also removed/threatened to remove prominent firewall VPNs for bullshit reasons (claims that apps violate random policies) ...
I co-develop one such open source "firewall app" for Android, and you're right that apps like ours have been previously removed for blocking ads out-of-the-box. But, removals also happen due to stricter rules/policies that apply to apps using VPN APIs.
Note that, of late, many a popular apps ad-blocking out-of-the-box (like the DuckDuckGo browser with app tracking protection) haven't been removed.
> Unless you own the kernel on every SoC running on your system (including the modem)
I get your point but don't think even a rooted (supervisor) Kernel gets you much guarantee as there always could be a higher privileged hypervisor controlling it.
> Apple's questionable privacy decisions are a lot less worse
They've improved post Celebgate yeah, but the duality is such that... Apple is one of the largest buyers of user data aka "market intelligence" (per folks I know who work in this domain) that (presumably) these other shady apps collect.
No, not generally. A firewall app could include an OpenVPN/WireGuard/etc. client to serve both purposes, but by default you'll have a hard time getting more than one VPN app to work at the same time.
Simply your IP address can be used to track you so any app or website you visit knows roughly where you are with every http request unless you use an always on VPN. It can also fingerprint you in various ways without the need for any special permissions.
Agree with you about fingerprinting (also a bummer). I guess the difference here though is that I must be actively engaging with a website in order for it to be tracking me, but an app (I assume) can be tracking me basically whenever it wants.
An app on iOS doesn’t just run constantly in the background unless it’s playing sound or using the GPS. For almost everything else you can explicitly turn off “allow background refresh” on a per app basis
At the very least the VPN provider promises not to and their reputation depends on their not being caught doing this. Whereas your ISP and various sites you visit will already be collecting this data no matter what.
iOS always asks for permissions. I suspect the same is true for unrooted Android.
But the general pattern is that you install some stupid vendor crapplet, and the first thing it does, is ask for every permission on your phone. Native apps can access a lot more stuff than ones restricted to a WebView sandbox. That's why they want you to use them.
They can "fingerprint" devices more easily. They have access to all kinds of subsystems, like Bluetooth, NFC, gestures (at low level), etc. Many require the user to give permission, but the first thing the app does, is ask for permission. As long as the statement in the request passes Apple muster, the app won't fail review, I seriously doubt that Apple will test after the app has shipped, to make sure that they stick to their word.
Some of this can be caught by the App Review process, if they do things like access private APIs, but we keep reading about clever app developers (and there are a lot of really smart crooks out there) that can fool the App Review testers. I read about a dodgy app that detected when it was in review, and modified its behavior (ala Volkswagen).
Really, I am not sure if there's a way to ensure the app works the same after review, than during. I would probably put a 4-day timer on it, starting the day of submission. After the timer expires, the app starts accessing private APIs via a hand-coded assembly interface. I would hope that Apple has already thought about this (It wouldn't be too difficult to test -just run it on a device with an advanced clock).
> They can "fingerprint" devices more easily. They have access to all kinds of subsystems, like Bluetooth, NFC, gestures (at low level), etc. Many require the user to give permission, but the first thing the app does, is ask for permission
So it’s a great conspiracy that apps have permission to do things after you explicitly give it permission?
No one is claiming that the app review process helps protect your privacy. The challenge is find something a native app can do surreptitiously to track you more than a website without you giving it permission bypassing OS safeguards.
And on iOS an app can’t access your NFC chip without you giving it permission.
“Running machine code” is not a security vulnerability. If your browser isn’t secure all sorts of exploits can happen from a web browser. That’s how a lot of the early iOS jailbreaks worked.
I used to write machine code, but I don’t, anymore. I am quite aware of how powerful it is, so I have to assume that the very smart people at Apple -who deal with current-day machine code- have a handle on dealing with it.
You didn’t state one example where it bypassed the sandbox. All apps on iOS are compiled to assembly. If writing in assembly magically bypasses a well designed OS’s security model, we are in trouble
You realize that if you are concerned about apps tracking you without you explicitly giving it your location, a website could do the same since there are browser APIs that can retrieve the same information only gated by the same OS controls?
When you go to a website, they have always known the originating IP address.
Not entirely true. Browsers are paranoid by default (because visiting a website is as easy as clicking a link). Operating systems aren't (because the user explicitly installed an app, it's been "vetted" by app store experts, and because... well, the OS vendor wants you to build native apps and not a website, so they have to make it worth the extra trouble of building a separate app for each platform instead of one website that works everywhere).
Also, browsers tend to bring their own sandbox (on top of what the OS already does). For example, Chromium was able to mitigate Meltdown/Spectre before OS vendors shipped an update (except on iOS where browsers can't bring their own engines, so iPhone users had to wait for Apple to ship an OS update...)
Again why would you think Apple the browser maker would be any more or less careful about Safari not allowing websites to access your camera, GPS, photos than Apple the operating system maker?
No one thinks that app review is what stops malicious apps from circumventing permissions. It’s the operating system itself.
And you really don’t want to compare the state of iOS updates to the state of Android updates do you?
Controlled by the same company that wrote the OS in case of Chrome on Android and Safari on iOS. If you don’t trust the operating system to do the right thing on the OS level why do you trust the same company to do the right thing in the browser?
I also use backtick for my tmux leader key. It doesn't create issues for me in the terminal (but you need to tap it twice when you want a literal backtick). This became natural for me pretty quickly.
What's the best way to get started with Blender these days? I'm mostly interested in making art and possibly even 3d printing some stuff (do these skills overlap at all?).
Here is one of my most successful classes, a complete workflow "From Sketch to (printable) Model": https://skl.sh/3219zVE (from 2020 but still 100% doable with current Blender version!)
Or my "Blender for Absolute Beginners" class that is a bit more recent, a thorough introduction to Blender and creation of a simple 3D printable bird :)
https://skl.sh/3xw8S77
(Both links give you a one month free trial of Skillshare, and you can watch the intro video without logging in)
As for 3d printing there are other software which is simpler if you need to do simpler things. But you can not go wrong in learning Blender for 3d printing as well.
I'd say that depends a lot on what you want to print. Some people might be able to use Blender for technical parts, but
for most people traditional CAD software would be the better choice here.
CAD is great when you want to make a nice parametric model that you can edit as requirements change. But for a simple one-off part, I can often whip one up in Blender in a third the time it would take me to dimension everything in a CAD sketch.
You and I must make very different parts. Unfortunaley even my one-off 3D prints are never one-offs. I almost always have to go back and tune a dimension or two.
I think to get an expert answer on the topic you'll need to listen to what a beginner has to say, so I believe the link I provided is a good source to look into.
Depends on what you want to 3D print. If you’re going for functional parts, then you probably want a CAD package rather than something like blender. If you want to 3D print art than by all means blender is your friend
Best way is to steal somebody else's model and improve it to your taste. That is the main use of Blender in 3D-printing, because parametric modelling is not the best property in Blender. Although it is almost feasible to define OpenSCAD model and ask AI to redefine in blender-python.
Hey ChatGPT, how you define an empty box in Blender Python?
It seems to be "empty" in name only. Lets try again.
ChatGPT: The OpenSCAD statement difference(){ cube(11); cube(10); } creates a shape by subtracting a smaller cube (10x10x10) from a larger cube (11x11x11). Here's how you can create the same effect in Blender using its Python API:
import bpy
import bmesh
# Create the larger cube
bpy.ops.mesh.primitive_cube_add(size=11, location=(0, 0, 0))
cube1 = bpy.context.object
# Create the smaller cube
bpy.ops.mesh.primitive_cube_add(size=10, location=(0, 0, 0))
cube2 = bpy.context.object
# Add a Boolean modifier to subtract the smaller cube from the larger cube
mod_bool = cube1.modifiers.new(name="Boolean", type='BOOLEAN')
mod_bool.operation = 'DIFFERENCE'
mod_bool.object = cube2
# Apply the Boolean modifier
bpy.context.view_layer.objects.active = cube1
bpy.ops.object.modifier_apply(modifier=mod_bool.name)
# Remove the smaller cube from the scene
bpy.data.objects.remove(cube2)
I'm really happy with the quality of WiFi in my house with the eero (works much better than the smattering of hard-wired access points I used to use ... not sure if that's better steering or what?).
The fact that it's constantly trying to sell me a monthly subscription leaves a real bad taste in my mouth though. Hard to recommend.
(Would love it if someone did figure out how to get a shell on here and give me a bit more control).