chiisana

You didn’t wreck the big corps. You opted yourself out of their warranty thereby saving them any money they would’ve had to spend on repairing your purchase during the defined warranty window. If anything you lined their pockets by making yourself a cheaper customer.

The anon user could be used by an advanced alien specie, trying to understand the technology underpinning operating systems in order to launch an attack against the humanity. Thus, the developer is specist against non human entities.

No? Too extreme? Where do we draw the line between leaping to conclusions and labeling people? Refusing to change a gendered pronoun to a gender agnostic one isn’t a great look. One can most certainly make an argument that it’s a sexist view of the landscape in favouring male users over others; but no where in the discourse that I could see did they attack transgenders, so it wouldn’t be fair to label the developers as transphobic. I think it’d be prudent to address the issue as they are, not leap to conclusions and apply labels.

It’s a general language (though primarily adopted by web as backend engine), so you can basically expect people already have had this idea.

The article linked to the analysis and on a quick glance, it seems to be done entirely against the Android variant of the app. This makes sense because if the alleged actions are true, they’d never have gotten on to the App Store for iOS Apple users… or at least as of a couple months ago. Who knows what kind of vulnerability is exposed by Apple only doing limited cursory checks for 3rd party App Stores.

I don’t suppose you mean Altered Carbon, where the premise is people don’t die as their entire memory and consciousness could be captured in a tiny tube the size of a modern day fuse; and opens where they’re investigating the suicide of a young woman who jumped to her death but have registered as DNR or something like that?

They didn’t because it’s not their problem. Other platforms’ users have that problem; Apple users have iMessage.

You buy a Windows phone, you buy a blackberry, you buy a flip phone, you’re using carrier messaging, or whatever app you can run on those platforms.

You buy an Android and suddenly you feel entitled to demand Apple to go to bat for you on carrier messaging? That’s a very entitled hot take.

Apple users have iMessage… amongst other third party chat apps that works fine across different platforms. Apple doesn’t have any obligations to go to bat for other platforms on carrier messaging that they already support.

Again, Android problem, not Apple problem.

Apple stated clearly they’re keen on working with GSM Consortium (who owns RCS and has more sway on carriers than Google does) on bringing E2EE to the masses.

If Google’s reputation of finding new and exciting ways to sell targeted ads doesn’t precede them, then they might have a better chance of getting a first party solution like Apple does with iMessage. But alas, Apple is not responsible for Google’s business plan or public image, and that problem is Google’s to solve.

That’s the point. It’s not Apples problem. Apple supports basic carrier messaging. If someone buys an Android, Apple users can message them just as anyone who buys a Windows Phone or BlackBerry.

It’s either an Android problem — getting fragmented service and no E2EE — at which point don’t buy an Android; or a user preference problem — “Inprefer iMessage” — at which point buy an iPhone.

Vendors on both sides have gone up and down the market to cover the spectrum, it’s not even a “can’t afford the premium feature” problem anymore as it were decade ago.

WhatsApp (EU/LatAm), WeChat (China), Kakao Talk (Korea), Line (Japan/Taiwan) are the main ones I’ve encountered. I think Telegram is used more in Russosphere and Signal has a footing in some niche circles as well.

There is no E2EE in RCS, so no amount of EU push would’ve enabled that. Also RCS was not a EU play, it’s a China play. RCS features are dependent on carrier implementation against GSM consortium’s spec.

So no, everything there is basically wrong… but hey, it goes well with the echo chamber vibes so upvotes to you!

People trying to claim capitalism / consumerism is missing the point — no one is getting a magical piece of PCB for free; vendors on both sides have gone up and down market that they’ve basically all covers the spectrum, and people make their own choice as to which platform they’re on.

People trying to assign blame on Apple is missing the point — it’s the android users having sub par fragmented (depending on carrier) service that doesn’t have E2EE by default, whom desperately needs something better.

If people chose Android are finally realizing they don’t have proper service, then they need to petition their platform vendor to put in something better (arguably Google has, but their reputation precedes them in these circles), or vote with their wallet when it comes time for their next device.

Apple has no obligation for users outside of their ecosystem. Apple saw the landscape of carrier messaging being terrible, and they made iMessage to help their customers communicate with one another better, while continue to maintain support for basic carrier communication. They have now updated to offer RCS, the current modern carrier messaging standard, which as demonstrated is still fragmented and outright garbage.

There is a Google proprietary protocol that’s based off of RCS, but as demonstrated by the Android market, even Android devices doesn’t do that — so Apple isn’t likely to (and frankly shouldn’t) do it to give more information to Google (even on the alleged promise of E2EE, it allows Google to know who is communicating with who at what time, and potentially roughly where via cell tower origination).

Apple is not a charity and has no need to open up their proprietary protocol designed to better their clients’ communications to non-clients. Want to make a phone call? Pay your carrier. Want to have electricity? Pay your power provider. Want to use iMessage? “Buy your mom an iPhone”.

Strictly speaking, they’re leveraging free users to increase the number of domains they have under their DNS service. This gives them a larger end-user reach, as it in turn makes ISPs hit their DNS servers more frequently. The increased usage better positions them to lead peering agreement discussions with ISPs. More peering agreements leads to overall cheaper bandwidth for their CDN and faster responses, which they can use as a selling point for their enterprise clients. The benefits are pretty universal, so is actually a good thing for everyone all around… that is unless you’re trying to become a competitor and get your own peering agreement setup, as it’d be quite a bit harder for you to acquire customers at the same scale/pace.

I tend to recommend sticking with more reputable providers, even if it means a couple of dollars extra on a recurring basis. Way too many kiddie hosts popping up, trying to make a quick buck during spring break/summer and then fail to provide adequate services when it actually comes time to provide service.

It may also be a good idea to check LET/WHT before committing into paying longer than month-to-month term with a provider.

I already answered this. Please read better.

Judging by the community response here… no, you have not, please write better.

I won’t bother replying anymore.

Apple offers first party E2EE messaging for their clients, via iMessage.

As part of China’s certification requirements, Apple has been tasked to support RCS, which, per the spec, does not have E2EE feature.

I’ll say this again: RCS does not support E2EE.

If that’s not registering: RCS does not support E2EE.

Come to the think of it, it would actually be surprising if China is mandating an E2EE capable implementation, but I digress.

In order to comply with this requirement, Apple implemented RCS per the specs of RCS. Again, RCS does not support E2EE. There is no specification of RCS that supports E2EE at this time.

Google runs a proprietary system that they’ve built based off of RCS, but is not RCS. This proprietary protocol, which is not RCS, has custom extensions of their own to offer E2EE. Apple is under zero obligation to implement against this, because this is not RCS. In fact, as demonstrated, even other Android systems don’t do this. They use the carrier RCS, which while fragmented and incomplete, consistently does not have E2EE, because, again, RCS does not support E2EE.

There are plenty of cross platform E2EE solutions available: Matrix, Signal, and WhatsApp, are a few major players that popped to mind. I’m sure there are plenty of others that I didn’t call out. They are cross platform which means they already exist on both iOS and Android platforms.

Neither Apple nor Google have any reason to implement those protocols, as, again, they already exist on platform.

How is Apple not implementing Google’s proprietary extension malicious compliance as you called it?

COPPA is pretty straight forward — the tl;dr is that websites are not allowed to collect personal info from children under age of 13.

If TikTok have users under the age of 13, and they’re profiling those users the same as they are with adult users (adult users of TikTok? This sounds so weird and foreign to me; I must be too old), then they’re in hot water. I don’t see how there’s any minority report style of thought crime going on here. It’s pretty cut and dry…

You do not strictly need to open a port – tunnelling through another server could be a solution, but let’s park this for a moment.

What you are describing as “open a port in my firewall” is actually many smaller parts, some key ones that may be relevant are:

1. (Firewall) Telling your gateway to not drop traffic when someone outside is request to connect to the specified port; and
2. (Port Forwarding) Telling your gateway to forward traffic from that port to a specific computer’s specific port within the network (i.e.: your computer, port 80)
3. (Running a service) Having a service (say for example, a web server) running on the specified computer’s specific port answering requests

All three things (amongst others that’s not immediately relevant here) must be properly setup for any network request to happen. What do I mean by that? I can have a port not drop traffic (i.e.: firewall down). When someone from outside of my network trying to access the port, they’d get to my router, but nothing happens because there’s no where for the packet to go. I can have my firewall down, and port forwarding enabled, but the web server isn’t running. When someone from outside of my network trying to access the port, they’d get to my router, get forwarded to my computer, but because the web server isn’t running, nothing happens. Someone from outside of my network can only gain access to my service (and only that service) only when all three are setup and working together.

“But what about the hackers?”

Yes, the untrusted networks, such as the internet, could be a bad place with people with bad intentions. There are many different things they could do to make things undesirable; let’s explore some of them together.

Say we want to run an instance of Lemmy using a new experimental server software (i.e.: not the official Lemmy server). Now, unfortunately, some racist people decided to come and make racist posts on our instance. A tunnel / proxy doesn’t solve this. Instead, we have to ban their accounts. It may not seem much, and it was completely innocuous to our system, but we’ve just dealt with our first attack.

One of those racist person happens to be the “scary hacker” type, so they came back and try to brute force our admin account’s password to unban themselves. This is not too bad, but we need to address this somehow. A tunnel / proxy doesn’t solve this; but something like Fail2Ban might be able to look at the login failures and put a temporary IP ban on the attacker.

They’re back! And this time, they decide to repeatedly hammer the search function, thereby taking all the resources from our database, so our instance cannot serve other users. A tunnel / proxy doesn’t solve this; but some rate limiting configurations in the server application might help.

They’re not happy about getting rate limited there. So this time, they decided to continuously post garbage to our instance, not even normal requests, just connect to our web server, and spam AAAAAAAAAAAAAA… non stop, at such a quick pace that it fully saturates our network connection, and we cannot do anything else on the network. A tunnel / proxy doesn’t solve this; we’d need to block them from the firewall. This is not entirely true; blocking them at the firewall doesn’t solve the problem, because the traffic still goes from the ISP to the firewall, which will still be saturated before the firewall could drop the traffic, but to use as an example it narrates a potential problem well enough.

They’re angry now, and they pay a few bucks to botnets to have many many many thousands of infected computers to spam AAAAAAAAA… non stop at our service. Again, a tunnel / proxy doesn’t solve this; we’d need to have something smarter than just our firewall and individually ban the IP addresses. This is where we’d need the professionals with typically commercial offerings.

It could escalade the other direction. Instead of attacking with aim to take the service down, they could do other damaging things. Say they found a problem with our server software. Instead of giving the /post/<postid> a numeric id, they can do something fancy like /post/1 AND 1 ==1; UPDATE users SET banned = FALSE WHERE username = 'racist-user' and unban themselves. A tunnel / proxy doesn’t solve this; but a Web Application Firewall (WAF) might.

Now it escalades more. Through a complex chain of intentionally malformed image uploaded to the instance, the image resizer attempting to resize the image, which gets tripped over by the malicious image, which causes a remote code execution, which they use to create a remote access trojan (RAT) shell so they can connect to our server and run commands. This is usually the “big bad” that most people are scared of… someone from outside of their network having access to their system and thus gains the ability to extract their documents or encrypt their photos etc. A tunnel / proxy doesn’t solve this; but a WAF or an anti-virus on the server itself might.

Through these albeit simplified but lengthy exploration, we see that none of these would actually be addressed by a tunnel / proxy. There are other possible attacks, and they’d require other solutions.

So, goes back to what I was saying earlier… it is important to know why you’re trying to do something. Blindly prescribing tunnel / proxy doesn’t actually solve the problem.

What kind of attacks, against what service?

DDoS? It’s cheaper to hire botnets to attack than to defend. You’d most likely still be knocked off even just by the amount of traffic that leaks through your proxy before the VM gets cut off at the data centre. Specifically: it is much more likely that data centres will give higher thresholds before null routing your VM than your residential ISP would be wiling to tolerate.

Brute force on shell? SQL injection? Remote shell execution? Deploying the extra layer will not protect you from these as your own proxy will not give you WAF.

It is always important to know why you’re doing something, before anyone can prescribe a solution.

Again, that’s what you’d like to achieve, but why?

Without the reason, there is no way to provide a useful answer that would adequately address the underlying reason.