4·
11 months agoI feel like this would result in so many broken phones that most companies would not want to enter this market. Wouldn’t be surprised if you could find something on Alibaba or Amazon, but I doubt it’s much of a market.
- 0 Posts
- 26 Comments
Joined 1 year ago
Cake day: June 12th, 2023
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
2·1 year agoThis distinction only exists in your head.
https://privacyis1st.medium.com/abuse-of-the-mac-appstore-investigation-6151114bb10e
Those are apps that got through app review and silently did malicious things in the background with no user action aside from the initial download.
Who cares what the technical exploit was? The net result is that there’s an app in the store that if you download it, does harm to you in a way you can’t prevent except for uninstalling the app.
https://www.washingtonpost.com/technology/2021/06/06/apple-app-store-scams-fraud/
https://www.wired.com/story/chatgpt-scams-apple-app-store-google-play/
I could keep going down the rest of page one of the search results, but why?
Pretty sure Samsung guarantees 4 years of upgrades and support.
Honestly the only thing Apple vets is that the app maker isn’t trying to weasel their way around Apple’s cut of the revenue. They’ll 100% catch it if you have a link to your sign-up page instead of using in-app purchase, but if you want to make an app called Threads and scam 300,000 people’s info, go nuts.
The Google Store is no better, but if I gave 1000 people money to spend on software, the ones who would be scammed out of the most are the people using these app stores. It’s an absolute travesty that Apple continues to get so much mileage out of their bullshit claims about their strict and thorough review process.
Also, I think it’s kind of hilarious that you just want a phone to work without you needing to mess with it, and then your phone cycle with Android sucked because you apparently picked something called the WileyFox Swift and started fucking around with bootloader replacements.
Going from one app (iMessage) to two isn’t an unambiguous win though. All the iPhone users’ experience got worse.
To be clear, this is such minor shit that the real answer is, “ok, I guess we’ll live with it because that’s how we communicate with our friends now”, but it is certainly nicer for them if everyone is on an iPhone and they don’t have to solve that problem.
It’s the same software on completely different back ends though.
What specifically do you want Apple to do? Let’s take one specific feature – sending video to an Android user at high quality. What would you tell Apple engineers to do to “fix” that? Because here’s how it works today. If you’re an Apple programmer, you have two options that exist today to send that video through iMessage. You can write code that leverages the iMessage IP protocol, or you can write code that leverages the MMS protocol. Those are all that exist. Nothing else is “broken”, because nothing else exists. If you pick the iMessage protocol, then Android users can’t get the message at all, because there’s no iMessage for Android. If you pick the MMS protocol, then the video sends in potato quality because MMS doesn’t support anything else. In the app today, those are your only two choices. That’s all the code that’s ever been written in the iMessage app, and you don’t have a magic wand to make more code just appear out of thin air to do anything else. So pick one. And we all generally would agree that “potato quality” is better than “never got the message”, so it picks MMS.
That’s the world that exists right now. You want them to “fix” it. Ok…how? I can throw out the options that I see.
-
They could implement an iMessage app for Android, put it in the Google Play Store, and have all messages go over the IP data protocol and bypass SMS/MMS completely (for iPhone/Android users at least). The main reason they don’t do this is vendor lock in – I agree with you there, and they’ve admitted as much in emails that have been surfaced in lawsuits over the years. But let’s say they changed their mind and decided to do it. They can’t just flip a switch. You can’t compile a Swift/Objective-C/UIKit code base into an Android app. You just can’t. The platforms don’t work that way. There are probably 10 million lines of code in each of those platforms that don’t exist on the other one. Your app might, for example, create an array of pictures to be attached to a message. That code, if it were old Objective-C, might have something like
pics = [[NSMutableArray alloc] init];. That’s Objective-C calling methods on objects that are defined in libraries. Android apps can’t be written in Objective-C. There’s no library available on Android that defines anallocmethod on a type calledNSMutableArray. You may as well be trying to run a Perl script in a Python interpreter. Apple would need to write a new app in Kotlin or Java that kind of did the same things that iMessage did. But even then, you want differences. Android has different UI paradigms. Maybe you need a hamburger menu. The “new message” button should be a floating “plus” icon or whatever. You have to write an Android app, not just recompile an iOS app that’s written in a language you can’t recompile anyway. -
They could change the existing iMessage code to support RCS as a protocol. That way, Android users still couldn’t run the iMessage app itself, but instead of sending potato quality video over MMS, Apple would send decent video over RCS. So what does that look like? Well again, you can’t just recompile an app. It’s not “fixing” a bug to make this work. This means adding an entirely new protocol, where by “protocol” we mean “implement these 100 or whatever defined message types”. Here’s the data you write over the socket to tell the cellular provider to deliver this picture. Here’s the data you write over the socket to tell the cellular provider to deliver this video. Here’s the data you write over the socket to tell the cellular provider to show the receiving user that I’m actively typing right now. Here’s the data you write over the socket to tell the cellular provider to tell the recipient that I “Liked” their message. And so on. Each of those things that the messaging app needs to support will have a different way of communicating to some server what the activity was, and Apple has to write all that code.
That’s all I’m realistically aware of. They could do other things like replace the entire code base with a web app and that would be cross platform, or they could write an emulation suite that lets UIKit apps run on Android, but they’re not going to do those things. These are the options. Both are completely doable, and Apple is making a choice not to do them. Part of that choice surely involves what they perceive as benefits for themselves from lock-in effects. My whole point is that also, neither of them are easy. Both are pretty large software projects that would take a lot of people, money, and time to do. We’re not talking about them just refusing to make easy “fixes”.
-
It’s software…these are computable problems, and we can solve them with Turing machines. No one is saying Apple is incapable of porting them. I’m saying that it’s work to port them. It’s nowhere near just clicking the compile button in Xcode and having it spit out a binary that speaks RCS or runs natively on Android or whatever. That is work for human programmers to sit down at blank editor windows and start building. Can they do that work? Again, obviously, yes they can.
Someone could sit down and make Vim interpret my .emacs file. It’s software. Emacs isn’t magic, and the Vim programmers aren’t stupid. We could make this happen if we wanted to. But it’s foolish to say that because it doesn’t work today that “Vim is deliberately breaking Emacs compatibility”.
If you can’t join or leave a chat, that’s a bug and they should address it. But that’s different than the whole “blue/green bubbles” conversation where people complain about terrible MMS quality and limitations on group chats and all that stuff. Those things happen because Apple currently speaks two protocols: SMS/MMS as a fallback and the iMessage IP protocol as a primary. To solve those problems cross platforms requires a third protocol (RCS), and that’s firmly back in “why doesn’t Vim interpret my .emacs file” territory.
Otherwise Microsoft would never be able to provide Office for macs.
Two points here. First, Microsoft has 220,000 employees. They absolutely could support two completely separate sets of Office apps if they want to, and in fact they did exactly that until 2018. They could support 200 separate code bases if they wanted to. Second, at best you have provided evidence that Microsoft uses some common code for Office, and that evidence is just that Office for Mac exists. iMessage for Android doesn’t exist, so there’s no such evidence. If I have a million line Windows app that I wish I could make available natively on Linux, but it’s all Win32 from top to bottom, you obviously can’t tell me that “all modern software requires a common code base and portability” therefore I could easily do it. My code base isn’t common or portable, so what Microsoft did doesn’t help me any.
But beyond all that, you’ve just papered over a vast amount of complexity by just declaring it doesn’t exist. Most portable apps today are web apps. You can write Electron and it’ll probably run on just about any platform. You could write Java and it’ll mostly run on any platform. But none of Apple’s stuff is either of those things. iMessage is a UIKit app, probably with a boatload of Objective-C behind the scenes and maybe some Swift for the more modern parts. It runs on Macs because of Catalyst, which is emulates the iPad version of UIKit on the Mac. But that’s it. There’s no UIKit for Android. iMessage simply isn’t portable, as far as any of us know. It’s just factually nowhere close to true to say “Apple just needs to compile it”. The frameworks it’s based off of just aren’t there. It’s exactly like saying that Adobe just needs to compile Photoshop as a KDE app. Photoshop doesn’t use Qt or the KDE libraries to do anything. The code just isn’t portable. (Full disclosure I guess, I have no idea if Photoshop uses Qt or not, but it’s a reasonable illustrative example).
And supporting a protocol isn’t just parsing, encoding, and decoding. HTTP is a protocol. So is IMAP. But you can’t just write a web browser that uses IMAP. The concepts don’t map 1-1 to each other. It’s not like for every HTTP action, there’s a matching IMAP action. You can’t just say, “I’ll just use FETCH instead of GET and everything will be great”. HTTP has redirects, for example. How are you going to make redirects work over IMAP? In the case of iMessage vs RCS, for example, iMessage has the ability to message someone without a phone number. RCS doesn’t. There’s literally nothing in the RCS protocol that makes that possible. So what do you want this mythical compiler to do when you tell it to compile iMessage for Android and use RCS? Should it just core dump if you try to message an email address?
Sure, but one of those things is fixing a bug in the protocol they already use for core functionality, and the other is an entirely new software development project. Adding RCS support to iMessage is adding support for an entirely new protocol. That’s what I’m getting at here. It’s not “broken”. Apple doesn’t have to “fix” RCS support. They have to build RCS support, from scratch.
This is like saying that Microsoft Windows should be able to run programs compiled for Apple Silicon on Mac OS. That might be a cool feature, and I have no problem with someone saying they think it should happen, but it’s not Microsoft being “evil” or refusing to “fix it”.
RCS is not completely compatible. For one thing, it requires a carrier and a phone number. You can go out today, buy a Mac or an iPad with no cell modem, and start using iMessage purely as an IP messaging app. So they can’t just replace the existing protocol with RCS, because RCS is a bag of flaming shit. They could spend the money to develop RCS fallback in addition to their protocol, and that would be awesome, but it costs them money, and I get why they don’t want to do it.
The reality is that this is Google’s fault more than anything. They spent half of my adult life repeatedly inventing and then fucking up the act of sending 200 bytes of text to one person at a time.
I’d love for the modern world to have a great way of messaging people that just worked – used IP connections with SMS fallback, a login you could manage from anywhere, full support for all the real-time typing stuff, the rich media support, the whole thing. That would be great. Someone get on that. But if I have to listen to fucking Google whine about it one more time, I’m out. They’re like a guy with one finger left. If you didn’t know any better, you’d feel pretty sympathetic for him. But if you’ve spent the past two watching him slowly chop the other nine off one at a time with a hatchet and then whine about his bad luck for 12 hours after each chop, the sympathy starts to ebb a bit.
They’re not deliberately breaking it – they just don’t support it. “Deliberately breaking” has the connotation that it would have worked just fine, except they took some extra action to stop it. That’s not true here. It would only work the way people want it to work if Apple spent a lot of money paying developers to make it work.
It does matter. Take iMessage. It’s cross platform enough for most people. You can text an Android-using friend and they can text you back. There are annoying limitations, but if you use a Mac, having the same messages available on your computer while you’re sitting at your desk at work is a feature that you may use, and if so, that feature is probably more important to you than whether you can directly share a video clip at full quality versus having to share a link or whatever.
That all depends on Apple’s ability to run it effectively, and they have basically no demonstrated ability to do that.
App Review is an absolute joke. Listen to last week’s Accidental Tech Podcast. One of the hosts is developing an IMDB competitor app, and he’s been rejected three times as of that episode. One rejection was for playing copyrighted video without permission – in an app that doesn’t have any code that can play a video. One was for not having a link to his T&Cs in a field in the app store that can’t render links. And the third was for displaying copyrighted media in his screenshots (maybe? no one really knows), and that media was the cover art for movie and TV shows. None of those even pass the sniff test. We all know that you’re allowed to show the cover art for a movie in an app that has information about movies. We all know that’s Fair Use, but beyond that, a third grader knows that literally everything in the world that presents information about movies does it. At the exact same time that all this is happening, Apple happily published some scammer’s app called “Threads” and let it collect 300,000 people’s information who thought they were downloading the actual Threads app from Meta.
It’s always been this way. I personally wrote the original iPhone app for a large US retailer in 2008 – the first year the App Store existed. App Review’s only purpose then was to detect your use of private APIs, usually because that would let you build things Apple didn’t want you to build. That’s the only purpose it serves today, 15 years later. Everything else is random noise that just punishes you unpredictably for no reason. I had an update of that app rejected once for using our own company logo as the icon. They don’t catch obvious scams. They never have. The people doing these reviews know nothing or are given so little time that the way to game their metrics is to just randomly reject sometimes without analysis. Unless they change something, it’ll just be a thing that scammers fill out however they want with no consequence to them at all, and a random 5% of legitimate developers will waste a few weeks arguing over when it’s applied to them with no logical basis in reality.
There’s always a router, and there’s always a DNS server. Normally, your device is asking to join a network, and something on that network assigns it an IP address, a DNS server, and a gateway router to use. That’s true whether you’re connecting to WiFi or a cellular network. The difference is just which device is assigning you those things. You can also override that on your side by specifying a static configuration that can break things, but I don’t think that’s your problem.
“Private DNS Mode” here is only referring to whether or not you want to encrypt the DNS lookup traffic. That’s certainly not a bad idea, but it’s a separate issue from whether or not you have a working DNS setup at all. From the screenshot below, it looks like you do have a working DNS configuration. To connect to a server, you type the server’s name (e.g., mobile.pornhub.com), your browser sends a DNS request to your DNS server asking it to return the IP address of that server, and then it uses that IP address to ask the server to send it a web page. You’re getting to the part where you’ve asked the server to send you a web page, but the server is refusing because your browser didn’t make the request over HTTPS (i.e., using encryption).
I don’t know why that is, but I’d try the steps outlined here.
I think there are probably some ways to cross over a bit, but really, LLMs aren’t necessarily aimed at the kind of things we want a virtual assistant to do today. Siri falls down mostly on its ability to correctly do things quickly and reliably. Generating 5000 words of convincingly human sounding explanations isn’t what I want from a thing I quickly trigger on my phone. What I want is very short or no reply accompanying the action I wanted to take. Call this person. Start navigation to an address. Turn on the lights. Play the version of a song I like from this specific live album. Some of those things are things Siri really sucks at today, and none of them are likely to get a lot better with an LLM in place. Maybe playing music benefits from a more robust understanding of the language of my query, but the rest of it are things where the suckage is more that Siri takes 8 seconds for the server to respond or just inexplicably decides that today it doesn’t know how to turn on a light.
At this point it feels like a great LLM would let Siri fail to respond to a much more varied set of ways for me to ask my question in English, but that’s not really the target we’re shooting for here.
You could do it with custom development work – write your own iOS and/or Mac app that uses Apple’s Maps API, but this becomes a fairly substantial software project that you need a programmer to create. It’s not doable just using the Maps app on your device as a user.
41·1 year agoIt’s more, “oh, that video clip looks like shit, and every time anyone on this chat likes something, everyone gets spammed a repetitive long-form explanation, and we can’t add Jimmy to the chat because it’s SMS now and AT&T limits it to 10 people, and …”
In the bad old days, SMS was incredibly limited. Apple came out with iMessage, which was both a full IP messaging client with rich features, but seamlessly fell back to SMS, and that was amazing, because a lot of the people you wanted to talk to only had SMS. Google briefly had a similar thing, but whoever ran that product lost the weekly pistols at dawn match that Google uses to set corporate strategy, and hangouts lost SMS integration, which meant you needed two message apps — one for IP messages that was good and a separate one for SMS that sucked. And they were completely separate — no shared threads or history or anything. And then hangouts was killed anyway to make room for chat, or meet, or duo, or allo, or jello, or J-Lo, or Oreos, or who the fuck knows anymore-oh. And so for several years, if you wanted the only thing anyone in the US ever wanted from a messaging app, you had to get an iPhone, because Google kept killing their apps every year like, “hey guys, our new app still can’t talk to your mom, but we integrated the “hot dog or not” feature from Silicon Valley into it, and isn’t that amazing?”
Now, it doesn’t matter, because no one is limited to SMS anymore. Everyone could be on whatever IP platform. But Google still picked a fucking standard built by the phone company with crappy baggage attached like requiring a phone number to use it, and anyway, they’re so late that everyone already picked iMessage. Even if RCS was as good, no one wants to change a bunch of stuff to be no better than when they started, and RCS also still isn’t as good.
The green vs blue bubble thing is just a shorthand way of talking about it. The average person either doesn’t care or cares because mixed-platform group chats have lots of rough edges and limitations, so if you’re the lone Android user, it feels like your fault.
Anyone who seriously escalates this stuff to being a real life problem is crazy, but it is more than just the color of the bubble.
I miss more on iOS because if that. The eight things I cared about are mixed in with the 94 that I don’t.