181–190 of 192 posts
Earlier quoted context omitted.
That's still too many steps - the trouble with bi/tri-lingual life is you often interject words (places, addresses, proper nouns) in the local language into sentences in any of the other two languages. Constantly opening and closing settings dialogs gets on your nerves in the long run.
Adding a language to your phone (once) is too much work? Or is a “button” press to swap out the keyboard too much? I don’t understand. I use English, Swedish accents and Russian with no issue. :s
The article focuses on making calls, but moxie (from Signal) had this to say: "PushKit is the only way to do e2e encrypted messaging in iOS. If they take that away, they're disabling the ability for messaging apps to function with e2e encryption. I don't see how Apple can frame that as "enhancing user privacy and security?" " https://twitter.com/moxie/status/1158852855291269120 So it's not only about being able to an…
>A UNNotificationServiceExtension object provides the entry point for a Notification Service app extension, which lets you customize the content of a remote notification before it is delivered to the user. A Notification Service app extension doesn't present any UI of its own. Instead, it is launched on demand when a notification of the appropriate type is delivered to the user’s device. You use this extension to modify the notification’s content or download content related to the extension. For example, you could use the extension to decrypt an encrypted data block or to download images associated with the notification.
https://developer.apple.com/documentation/usernotifications/...
The article focuses on making calls, but moxie (from Signal) had this to say: "PushKit is the only way to do e2e encrypted messaging in iOS. If they take that away, they're disabling the ability for messaging apps to function with e2e encryption. I don't see how Apple can frame that as "enhancing user privacy and security?" " https://twitter.com/moxie/status/1158852855291269120 So it's not only about being able to an…
Earlier quoted context omitted.
Facebook aren’t obliged to make a change just because they can. Taking something that works and changing it for its own sake is something people very often get annoyed about.
> Taking something that works and changing it for its own sake That's a somewhat misleading way to characterize this: VoIP apps are still going to be just fine using the VoIP API. The question is whether legacy code should preclude Apple taking steps to act on their users' behalf. Given the number of people I know who uninstalled Messenger so their phone could make it through the workday without a charge, I'm pretty…
Earlier quoted context omitted.
Have you tried messenger.com from your browser? Edit: Just went on it. On a browser you have to enable desktop mode for login to show. Also if you login this way and disable desktop mode it forces you out. If you reenable it renders the chat. Theres no reason the chat wouldnt work on Mobile desktop mode isnt using a different browser just lying to the web server and frontend JS. Amazing. I already rarely use Facebook…
I actually believe part of it is that they rely on this editor[1] for the messenger and anyone who tries to use it on any device that supports IME (like phones) will find that it does not work at all. [1] https://github.com/facebook/draft-js
I've been bitten by it too much. It's typically the auto-complete feature of mobile keyboards that fails. Something that you don't always see in emulators.
The article focuses on making calls, but moxie (from Signal) had this to say: "PushKit is the only way to do e2e encrypted messaging in iOS. If they take that away, they're disabling the ability for messaging apps to function with e2e encryption. I don't see how Apple can frame that as "enhancing user privacy and security?" " https://twitter.com/moxie/status/1158852855291269120 So it's not only about being able to an…
You still have the ability to use an extension that decrypts push notifications on the device when your app is not running. >A UNNotificationServiceExtension object provides the entry point for a Notification Service app extension, which lets you customize the content of a remote notification before it is delivered to the user. A Notification Service app extension doesn't present any UI of its own. Instead, it is lau…
This could include responding to a message retry request, uploading new keys, handling receipts, etc.
Earlier quoted context omitted.
> Taking something that works and changing it for its own sake That's a somewhat misleading way to characterize this: VoIP apps are still going to be just fine using the VoIP API. The question is whether legacy code should preclude Apple taking steps to act on their users' behalf. Given the number of people I know who uninstalled Messenger so their phone could make it through the workday without a charge, I'm pretty…
I don’t get what you’re trying to say? The GP says the new api which Facebook should use has been available 3 years, implying that fb ought to have made the change long ago. I say they had no reason to make the change in the last three years [because Apple are dropping support for the old api now and only announced this recently]. And you say that’s wrong (so FB should have made the change 3 years ago) because ... th…
Earlier quoted context omitted.
It has nothing to do with end-to-end encryption: they’re abusing the VoIP feature to stay running in the background, which is trading battery life for better surveillance of your activities. Apple is doing it to _protect_ privacy by closing one of the ways unscrupulous app developers keep trackers running.
It has everything to do with end-to-end encryption. Prior to iOS 10, the only way to display notifications for end-to-end encrypted chat without giving Apple a plaintext copy of everything in the notification was to abuse the VoIP feature. More specifically, the "PushKit VoIP API" Facebook's spokesperson mentioned allowed services to push down an opaque blob of data and have their apps immediately wake up in the back…
Hey, I just noticed that I never responded to you directly: my objection to the comment I replied to wasn’t because it didn’t affect some end-to-end encryption apps but that Apple wasn’t acting against them because they implemented encryption. They’re going against everything using the VoIP API for non-VoIP features and there’s an official replacement API available, so the language casting it as a threat to privacy seemed unfounded.