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.

On purchasing servers; I don’t know about Google specifically, but most media partners I’ve worked with doesn’t have global acquisition as an option for hardwares — not because they don’t have the purchase power/volume, but rather the vendors have region specific distributors with their own sales teams and pricing. Even if you have the personal contacts of VPs high up the chain, someone from IBM China cannot even sell to companies in Canada, and vice versa, for example.

On people side of things… With YouTube specifically, you’re also not only dealing with their own DC but getting their hardware into local ISPs centres. Logistics around that is not something cheap remote labor can arrange, need actual boots on the ground to facilitate.

Ad sales is also something that’s kind of localized. YouTube has American teams selling American creator inventories for example. Not something that’s outsourced out.

So yea… Although from the outset it’s all just “YouTube.com”, there’s actually a lot of localized touch points that creates different costs to provide service in different regions.

Without violating my NDA with media companies (YouTube being one of them, incidentally), all I can tell you is you’re wrong about these. I’ve been in this exact sector for over a decade and the operating expenses are much higher comparatively speaking, and the objectives are different depending on region.

If you’re so inclined to pay the discounted rate, make the narrative work so they have no way of flagging you. Otherwise don’t be surprised if you’re asked to pay local rates.

Service provider must acquire hardwares for the data centre at local vendor pricing.

Service provider must hire someone local to work in your local data centre.

Service providers need to pay local electricity and bandwidth rates.

List goes on. Just because you don’t interface with the local aspects of business doesn’t mean they don’t exist and add extra costs.

If you want to pay lower rate, as I stated earlier, make your narrative work: use local payment methods, billing address and use the service locally to the locality you’re paying in. Then they’ve got nothing to argue against you as you’re using services in that lower cost region.

Operation costs differently in different regions. Advertising spend differs in different regions. You’ve moved from a region with cheap operating expenses and no ad spend to another region with more expensive operating expenses and higher ad spend. Congratulations on your move, now the cost to provide you service is different, and you’d need to pay more to cover the operating expenses + expected margin.

Alternatively, procure a local credit card (I.e. the same one you used back home), billing address (i.e the last place back home), and always do everything through a VPN back home. Then you’re at least using services from where the operating expense reflects the pricing.

This is just business, and should be expected. Food is dirt cheap back in Asia, they’re more expensive here in North America. Like it or not, if I’m living here, I need to pay the prices here. If I don’t want to pay the prices here, I can move back to Asia.

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…

OP Currently has in their possession 2 drives.

OP has confirmed they’re 12TB each, and in total there is 19TB of data across the two drives.

Assuming there is only one partition, each one might look something like this:

Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 12345678-9abc-def0-1234-56789abcdef0

Device         Start        End            Sectors        Size      Type
/dev/sda1      2048         23437499966    23437497919    12.0T     Linux filesystem

OP wants to buy a new drive (also 12TB) and make a RAID5 array without losing existing data. Kind of madness, but it is achievable. OP buys a new drive, and set it up as such:

Device         Start        End            Sectors        Size      Type
/dev/sdc1      2048         3906252047     3906250000     2.0T      Linux RAID

Unallocated space:
3906252048      23437500000   19531247953    10.0T

Then, OP must shrink the existing partition to something smaller, say 10TB for example, and then make use of the rest of the space as part of their RAID5 :

Device         Start        End            Sectors        Size      Type
/dev/sda1      2048         19531250000    19531247953    10.0T     Linux filesystem
/dev/sda2      19531250001  23437499999    3906250000     2.0T      Linux RAID

Now with the 3x 2TB partitions, they can create their RAID5 initially:

sudo mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 /dev/sda2 /dev/sdb2 /dev/sdc1

Make ext4 partition on md0, copy 4TB of data (2TB from sda1 and 2TB from sdb1) into it, verify RAID5 working properly. Once OP is happy with the data on md0, they can delete the copied data from sda1 and sdb1, shrink the filesystem there (resize2fs), expand sda2 and sdb2, expand the sdc1, and resize the raid (mdadm --grow ...)

Rinse and repeat, at the end of the process, they’d end up having all their data in the newly created md0, which is a RAID5 volume spanning across all three disks.

Hope this is clear enough and that there is no more disconnect.