• 0 Posts
  • 57 Comments
Joined 1 year ago
cake
Cake day: June 19th, 2023

help-circle
  • chiisana@lemmy.chiisana.nettoTechnology@lemmy.worlddon't use ladybird browser lol
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    8
    ·
    edit-2
    3 hours ago

    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.





  • 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.




  • 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”.


  • 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.



  • 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.



  • 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…


  • Honestly I think this is a standards issue not an Apple or Google issue.

    Apple needs to serve their clients and iMessages is great for that. Google needs to serve their clients and they’re putting forward their RCS extension, which could be good if they can gain traction, but their reputation precedes them, so thats going as well as anyone would expect. Neither parties really have obligations beyond, as the standard beyond their own offering is SMS MMS which they both support.

    GSM is responsible for the next evolution of the carrier level messaging, which is RCS (without the E2EE extension Google is putting forth), and it’s their job to make that the standard implemented by all carriers. It’d be great if they add E2EE to the standard, but the fragmentation ant carrier level isn’t going to magically resolve if they cannot get carriers to implement it properly.