6 ms·

ICEBlock, an iOS Exclusive

40 points by Bogdanp 1y ago

piperswe 1y ago
GrapheneOS's response to ICEBlock's claims about Android security: https://grapheneos.social/@GrapheneOS/114789276549546469 https://grapheneos.social/@GrapheneOS/114789276549546469
- jajuuka 1y ago
  There is a developer who is working on a multiplatform app to report ICE as well and they made a response too. ICEBlocks dev just immediately blocked them. So clearly they don't take criticism well and would rather believe Apple marketing. Or maybe want to hide a lack of knowledge about Android development. It's not a problem if they just want to make an iOS only app. Your skillset is your skillset. But to push misinformation to justify it is just arrogant.
  - bitpush 1y ago
    > But to push misinformation to justify it is just arrogant. It seems like the developer is relying on incorrect Apple vs Android stereotypes to market their app, when the truth might be less charitable.
billy99k 1y ago
[flagged]
- unsui 1y ago
  the whataboutism is strong in this one
  - CaptWillard 1y ago
    [flagged]
bitpush 1y ago
> To send push notifications on Android, it is necessary to use a mechanism that requires storing device IDs. [..] > [..] Apple’s ecosystem allows for push notifications to be sent without requiring us to store any user-identifiable information. This ensures that ICEBlock remains completely anonymous and secure. So in one case the developer stores the mapping, and in the other case Apple stores the mapping. And that's a good thing? It takes 1 subpoena to get access to that data from a large company.
- thewebguyd 1y ago
  Yeah, I never understood the argument. You're just trusting Apple vs. trusting the dev, either way you are trusting an entity that may or may not act in your best interest, and both entities are subject to subpoena. They could also just use firebase cloud messaging and treat it just like APNS. There's nothing magical about Apple's services that makes them immune to government requests for data, despite Apple's privacy marketing.
  - ludwigschubert 1y ago
    I’m not disagreeing, but the magical difference to me seems that Apple _users themselves_ decided ahead of time to trust Apple, whereas _the developer_ would make the decision to trust a third party? (My more jaded view is that such arguments are merely rationalizations, and that in 90% of these cases it’s mostly about which stack the people building an app have previous experience with… even though they explicitly claim the decision was made on technical grounds. ¯\_(ツ)_/¯)
    - thewebguyd 1y ago
      I think your jaded view is likely correct, at least in this case but I can see the other argument. After all, even myself I choose to use iPhone over Android purely because I align more with their practices/policies around data vs. Google, which I guess means I also have decided ahead of time to trust Apple over another entity. But I also have no illusions when it comes to law enforcement access, outside of Apple's Advanced Data Protection, which Android/Google currently offers no alternative to.
486sx33 1y ago
[dead]

40 points by Bogdanp 1y ago

GrapheneOS's response to ICEBlock's claims about Android security: https://grapheneos.social/@GrapheneOS/114789276549546469 https://grapheneos.social/@GrapheneOS/114789276549546469

jajuuka 1y ago
There is a developer who is working on a multiplatform app to report ICE as well and they made a response too. ICEBlocks dev just immediately blocked them. So clearly they don't take criticism well and would rather believe Apple marketing. Or maybe want to hide a lack of knowledge about Android development. It's not a problem if they just want to make an iOS only app. Your skillset is your skillset. But to push misinformation to justify it is just arrogant.
- bitpush 1y ago
  > But to push misinformation to justify it is just arrogant. It seems like the developer is relying on incorrect Apple vs Android stereotypes to market their app, when the truth might be less charitable.

billy99k 1y ago

[flagged]

unsui 1y ago
the whataboutism is strong in this one
- CaptWillard 1y ago
  [flagged]

bitpush 1y ago

> To send push notifications on Android, it is necessary to use a mechanism that requires storing device IDs. [..] > [..] Apple’s ecosystem allows for push notifications to be sent without requiring us to store any user-identifiable information. This ensures that ICEBlock remains completely anonymous and secure. So in one case the developer stores the mapping, and in the other case Apple stores the mapping. And that's a good thing? It takes 1 subpoena to get access to that data from a large company.

thewebguyd 1y ago
Yeah, I never understood the argument. You're just trusting Apple vs. trusting the dev, either way you are trusting an entity that may or may not act in your best interest, and both entities are subject to subpoena. They could also just use firebase cloud messaging and treat it just like APNS. There's nothing magical about Apple's services that makes them immune to government requests for data, despite Apple's privacy marketing.
- ludwigschubert 1y ago
  I’m not disagreeing, but the magical difference to me seems that Apple _users themselves_ decided ahead of time to trust Apple, whereas _the developer_ would make the decision to trust a third party? (My more jaded view is that such arguments are merely rationalizations, and that in 90% of these cases it’s mostly about which stack the people building an app have previous experience with… even though they explicitly claim the decision was made on technical grounds. ¯\_(ツ)_/¯)
  - thewebguyd 1y ago
    I think your jaded view is likely correct, at least in this case but I can see the other argument. After all, even myself I choose to use iPhone over Android purely because I align more with their practices/policies around data vs. Google, which I guess means I also have decided ahead of time to trust Apple over another entity. But I also have no illusions when it comes to law enforcement access, outside of Apple's Advanced Data Protection, which Android/Google currently offers no alternative to.

486sx33 1y ago

[dead]