• 0 Posts
  • 159 Comments
Joined 3 years ago
cake
Cake day: June 19th, 2023

help-circle



  • What technical limitations?

    I’d guess it was the small battery in the watch. A lot of features on Apple’s smartwatch cause serious battery life problems unless they can be offloaded to your phone at least most of the day.

    For example if you have the weather conditions on your watch face… the watch can lookup the weather but it generally will ask your phone to do that. Stuff like that is a lot easier if you control the phone operating system and aren’t just running an app.

    … for example if you never launch the weather app on your phone, both Android and iOS will reduce it’s ability to drain the phone’s battery by running in the background. Apple makes an exception to that rule for weather apps where the user has a widget an Apple Watch face. How could the Android battery management systems know what widgets are on your Apple Watch?


  • API requests are usually encrypted with SSL and protected against unauthorised use with something along the lines of a JWT: https://jwt.io/

    Breaking through the SSL might be possible, if the developer doesn’t pin certificates, but you don’t know the secret used to generate the HMAC signature (blue section of that website), then you can’t simulate the API request. And the secret shouldn’t be sent over a network connection.

    You could probably access the secret with enough work, but it would be a lot of work. You’d have to do it separately for each app. And the developer can change the secret whenever they want. The developer will change the secret at the slightest hint of anything like this being used with their app. And possibly also take additional steps to keep it from being accessed (e.g. store it in the Trusted Platform Module or equivalent on Android/iPhone). Even the CIA can’t access that - it’s mostly intended for payment processing and protecting data on a stolen phone, but there’s nothing stopping a weather app from using it to prevent unauthorised access to their API (weather data is very expensive, and often billed per API request).

    Running the real app on a real phone though… basically nothing an app developer can do to stop that.




  • I dunno about you, but I would love to get a notification on my watch when the machine has finished it’s cycle. The stupid high pinched repeated beeping noise sucks… especially when it’s the next door neighbour’s washing machine and they’re not even home, so it goes on and on for fucking hours. And I’d like to see proper error descriptions on my phone, instead of just “UE” on the timer LCD. WTF is a “UE” error?

    If we’re going to get really fancy… I’d love to be able to load the machine in the morning, but tell it to actually start running several hours later while I’m at work. I obviously don’t want clean wet clothes going mouldy in the washing machine all day… but I don’t really want to run the washing machine when I’m home either, because it’s noisy.

    Remote activation would also be better for the environment and also better for my clothes - I’d use the the slow gentle economy cycle every time if I could remotely trigger it at 3pm on a weekday. I’m definitely not going to use that on the evenings (when I’ll be asleep in 3 hours) or on weekends (when I don’t know if I’ll be home in 3 hours time).

    A wifi connected washing machine sounds like a great feature to me, and I’d happily pay for it (with dollars, not with an invasion of privacy). I guess that means I won’t be buying an LG.



  • In short: The per message AES key is derived from the contacts public RSA key.

    Erm that’s not how it actually works. Though in your defence, “in short” is pretty hard to achieve here.

    The real headache though isn’t encrypting the messages. It’s making sure that only the intended recipient has the decryption key for your message. That’s where E2EE messaging gets complex and frankly Apple doesn’t do the best job.

    It’s theoretically possible with iMessage, especially in a nation state level attack, for a compromised device to be one of the recipients your encrypted message is sent to. Wether “theoretically” is “actually in practice” happening is hard to judge, because nation state attacks are normally hidden by court mandated disclosure suppression orders.

    The way Signal is architected, it wouldn’t be possible to comply with a court order like that. Unfortunately that means some Signal based messaging services will be forced to exit the UK since laws coming into effect next year will give them no other choice. It’ll be interesting to see if signal based services (like Google RCS) also walk or will they weaken their encryption in order to be able to comply.

    The fact at least one nation state is passing laws that force “encrypted” messaging services to have the vulnerability that iMessage has is a pretty strong smoke signal that attacks like that are happening…




  • Oof that’s bad.

    Although it should be noted that in well designed apps this should only be metadata. The push notification should just tell the phone that “content is available”, which will power up the CPU, launch the app in the background, download your actual message/etc, decrypt it, and finally put a notification on the lock screen.

    Metadata is obviously useful to law enforcement, but unless the app is really poorly written they shouldn’t be getting your actual notification alerts. Those should be E2EE and therefore can’t be disclosed.

    Unfortunately the notification system does allow messages to be sent without encryption. Perhaps they should remove that feature.


  • No… When you send a “blue bubble” photo on an iPhone the file size is around 1.5MB. When you send a “green bubble” photo I think they’re resized down to less than 300KB.

    Any photo larger than that won’t be delivered by some carriers. Also while iMessage photos default to HEIF format - the same compression algorithm as Blue Ray videos - MMS uses JPEG which doesn’t have a target file size feature. All you have is the width/height in pixels and an arbitrary “quality” scale.

    To guarantee your photo will never be over 300KB you need to set the width/height/quality to a number that will often be under 100KB… and that’s what Apple does.

    Android has a size setting, and you’ll get a delivery failure error if you set it too high for the recipient’s carrier… a lot of carriers do support larger photos… But Apple doesn’t bother with that - they want it to “just work”. Which means 100KB for green bubble photos.

    The reality is quality is always going to suffer - converting an image from HEIF to JPEG is a bad idea - it’ll never look anywhere near as good as the original no matter what resolution or quality the compression is set to.

    Also… iPhones don’t even take ordinary photos… by default every “photo” is a short video. When you send those to another iPhone, they get the video. Green bubbles either get a still image or worse a 100KB five second video.