3 ms·

How about sandboxing apps with access to sensitive private information from network access? I don't want my email to leave my desktop / mobile phone / Google's

by pacala 8y ago

How about sandboxing apps with access to sensitive private information from network access? I don't want my email to leave my desktop / mobile phone / Google's server, is it really that hard to have that as an option?

lern_too_spel 8y ago
> I don't want my email to leave my desktop / mobile phone / Google's server, is it really that hard to have that as an option? That option exists. It's called not adding a third party app to your Gmail and clicking its consent button.
- pacala 8y ago
  Absolutely. Even better, just not use GMail until they start taking data protection seriously.
  - sp332 8y ago
    How could gmail take it more seriously? They even encrypt the links between their datacenters.
  - lern_too_spel 8y ago
    Every other email provider also provides API access to email, typically via IMAP or POP. Your suggestion then is (instead of simply not authorizing third parties to have access to your email) to not use email at all?
    - pacala 8y ago
      There is quite a bit of friction when setting up IMAP/POP access to an email provider. If I go to the trouble of setting up IMAP/POP, it's likely I know what I am doing. To the best of my understanding, the article is about 1-click permission granting / data leak.
- fjsolwmv 8y ago
  That's a rather poor option. Mac App Store and Android for example offers much better sandboxing options.
Lazare 8y ago
> is it really that hard to have that as an option? Okay, so now you have a third party email app that...can't send and receive email? It's not that it's hard, it's that it's basically precluded by the nature of what we're trying to achieve. I installed a third party email app so that it could talk to the network. That's what email apps do! :) The solution for you, I think, is to just not use anything but the official gmail app while on a trusted device and network. Very sensible! But not a good option for everyone.
eh78ssxv2f 8y ago
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.
AstralStorm 8y ago
No need to sandbox, some android objects have permission and capability control. It is just not propagated (and enforced enough) so you get all kinds of confused deputy problems. If it were, you could have separate permissions for combining mail provider with network streams.

by pacala 8y ago

lern_too_spel 8y ago

> I don't want my email to leave my desktop / mobile phone / Google's server, is it really that hard to have that as an option? That option exists. It's called not adding a third party app to your Gmail and clicking its consent button.

pacala 8y ago
Absolutely. Even better, just not use GMail until they start taking data protection seriously.
- sp332 8y ago
  How could gmail take it more seriously? They even encrypt the links between their datacenters.
- lern_too_spel 8y ago
  Every other email provider also provides API access to email, typically via IMAP or POP. Your suggestion then is (instead of simply not authorizing third parties to have access to your email) to not use email at all?
  - pacala 8y ago
    There is quite a bit of friction when setting up IMAP/POP access to an email provider. If I go to the trouble of setting up IMAP/POP, it's likely I know what I am doing. To the best of my understanding, the article is about 1-click permission granting / data leak.
fjsolwmv 8y ago
That's a rather poor option. Mac App Store and Android for example offers much better sandboxing options.

Lazare 8y ago

> is it really that hard to have that as an option? Okay, so now you have a third party email app that...can't send and receive email? It's not that it's hard, it's that it's basically precluded by the nature of what we're trying to achieve. I installed a third party email app so that it could talk to the network. That's what email apps do! :) The solution for you, I think, is to just not use anything but the official gmail app while on a trusted device and network. Very sensible! But not a good option for everyone.

eh78ssxv2f 8y ago

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.

AstralStorm 8y ago

No need to sandbox, some android objects have permission and capability control. It is just not propagated (and enforced enough) so you get all kinds of confused deputy problems. If it were, you could have separate permissions for combining mail provider with network streams.