4 ms·

Can you explain how that sandboxing would work? Can the malicious app not just transcode/encrypt email, and transmit it back to their server? How would that be

Can you explain how that sandboxing would work? Can the malicious app not just transcode/encrypt email, and transmit it back to their server? How would that be detected? Also, depending on the email client and its purpose, siphoning the email to the server might as well be a valid use case. e.g., I can think of an app which manages my email by smartly figuring out which email is important and/or urgent. For the app to achieve this, having access to the email body is critical and a valid use case.

pacala 8y ago
Sandboxing. There is no network access, other than access to Google IMAP/SMTP servers. The app must operate locally on the device, full stop. What desktop apps have been doing since forever [I hope!]. This is about peace of mind. As a user, I would appreciate the option of "lock data to device" and knowing that my data stays on my device no matter what apps I install, no matter what permissions they ask for, no matter what they fine print says, no matter how good at securing their servers they are. I'm OK to have some apps not working anymore. You only leak data once, but there are thousands of apps to choose from. Unless I explicitly take the action to "unlock data on device", which hopefully is accompanied by messaging about the high potential risks to privacy, "are you really sure" kind of UI experience. Make data protection a BigDeal[TM]. Ninja edit: added SMTP on the list of whitelisted servers.
- Lazare 8y ago
  > There is no network access, other than access to Google IMAP server. If it can't fetch arbitrary images from the internet, it can't render HTML email which (even if you don't want it) is a feature many people require. Even worse, if it can't talk to Google's SMTP servers, then it can't send email, which again is a feature most people require from an email client. (I mean, it's one of the two fundamental features of an email client, so...) But if you can do either of those, you can exfiltrate data. And since data to arbitrary third parties is fundamentally what an email client does, that's probably unavoidable. :) (And keep in mind that when dealing with third party email clients, it's very much a one click experience to configure them to both send and receive email.) > What desktop apps have been doing since forever [I hope!]. That's never been a technical restriction placed on desktop apps. Historically they've had no restrictions, and more recently with app store sandboxes they don't have that kind of restriction. The most restrictive sandbox mode applied to desktop apps that I know of (the OS X app store sandbox) is designed around allowing apps to talk to the network freely, but restricting their access to local resources, the exact opposite of what you want. > Make data protection a BigDeal I endorse this goal, but I don't think this is an avenue that leads to a solution.

pacala 8y ago

Sandboxing. There is no network access, other than access to Google IMAP/SMTP servers. The app must operate locally on the device, full stop. What desktop apps have been doing since forever [I hope!]. This is about peace of mind. As a user, I would appreciate the option of "lock data to device" and knowing that my data stays on my device no matter what apps I install, no matter what permissions they ask for, no matter what they fine print says, no matter how good at securing their servers they are. I'm OK to have some apps not working anymore. You only leak data once, but there are thousands of apps to choose from. Unless I explicitly take the action to "unlock data on device", which hopefully is accompanied by messaging about the high potential risks to privacy, "are you really sure" kind of UI experience. Make data protection a BigDeal[TM]. Ninja edit: added SMTP on the list of whitelisted servers.

Lazare 8y ago
> There is no network access, other than access to Google IMAP server. If it can't fetch arbitrary images from the internet, it can't render HTML email which (even if you don't want it) is a feature many people require. Even worse, if it can't talk to Google's SMTP servers, then it can't send email, which again is a feature most people require from an email client. (I mean, it's one of the two fundamental features of an email client, so...) But if you can do either of those, you can exfiltrate data. And since data to arbitrary third parties is fundamentally what an email client does, that's probably unavoidable. :) (And keep in mind that when dealing with third party email clients, it's very much a one click experience to configure them to both send and receive email.) > What desktop apps have been doing since forever [I hope!]. That's never been a technical restriction placed on desktop apps. Historically they've had no restrictions, and more recently with app store sandboxes they don't have that kind of restriction. The most restrictive sandbox mode applied to desktop apps that I know of (the OS X app store sandbox) is designed around allowing apps to talk to the network freely, but restricting their access to local resources, the exact opposite of what you want. > Make data protection a BigDeal I endorse this goal, but I don't think this is an avenue that leads to a solution.