6 ms·

The protocol may be in good shape, but Signal's permission model is flawed for an application that handles sensitive data. A few examples of excessive permissi

The protocol may be in good shape, but Signal's permission model is flawed for an application that handles sensitive data. A few examples of excessive permissions: * Disable your screen lock * Location permissions * Set wallpaper ("kitchen sink" feature here) * External storage (why not use internal "app only" storage?) * System log data Android's sandbox will do its best to protect the user from compromised applications, but it can't do anything to protect you if the application already has full permissions. Based on recent events, I would assume that Signal users are at risk of targeting as a block -- their desire for privacy makes them interesting targets from an intelligence and LEO perspective. Many successful applications follow a plugin model, where intrusive permissions are split off into separate, optional applications. Signal should do the same.

AdmiralAsshat 10y ago
On Marshmallow or newer, can't these be blocked? I was alarmed at the Location permissions at first too, but I believe it's only used so that you can send someone your GPS location. If you simply deny the request, that feature will be disabled, but I don't think it prevents the app from working.
- iamnothere 10y ago
  Only some can be blocked. Unfortunately Android still groups permissions together, and all related permissions must be enabled or disabled as a block. (For instance, storage read and write permissions are technically separate, but they are placed together in a single "storage" group.) Most (all?) permissions in the catch-all "other" group cannot be disabled at all.
  - nitrogen 10y ago
    One of the interesting irrevocable permissions in that "Other" group is full network access, so any app can portscan your network or try to hack your IoT devices. Bluetooth pairing is also in Other. The Android permission model is terrible. What ever happened to Intents? Shouldn't photo sharing be a simple Intent rather than requiring a new UI and storage permissions for every single app?
    - angry_octet 10y ago
      Can I suggest a nice program called NetGuard? But yes, and this is a deliberate Google policy, also like the don't want ad blocking programs. You are an input to their revenue generating system, not a client.
codethief 10y ago
> A few examples of excessive permissions: > * Disable your screen lock I believe this is for the "call screen" (though it's never really worked for me and my phone gets or stays locked nonetheless when I call someone or someone calls me). > * External storage (why not use internal "app only" storage?) Because otherwise you can't extract photos you received (let alone view videos) which, from a security standpoint, is good but it's something you'll have a hard time selling to the average user. The same goes for sharing your location.
- iamnothere 10y ago
  I agree that there are legitimate reasons for these permissions, I just don't think they match up with everyone's use case for the product. This is why they should be split into plugins. Example of how the UX for this works: 1. User chooses "attach photo." 2. If user has not installed the plugin, Signal gives them an informational prompt and a button that opens the app store link. 3. User clicks the button to go to the app store. 4. User clicks "install." Application is installed (should be quick, small app) 5. User can now attach photos from external storage. Steps 2-4 are short and occur only one time. You would not want this kind of extra friction in a true mass market app, but I'd argue that Signal is not and never will be mass-market. (We can hope, but it's not likely.) Signal's target users, on the other hand, would be likely to appreciate this extra focus on security and user control.
  - tedks 10y ago
    Here's how the UX actually works: 1. User chooses "attach photo." 2. The user hasn't installed the plugin. Who does that? So signal doesn't work. 3. The user sends their contact a facebook message saying "signal isn't working" and attaches the photo. 4. Both users uninstall signal and tell everyone who mentions it that it can't even send picture messages.
    - iamnothere 10y ago
      That would be poor design. Are you saying that the Signal team would not be capable of implementing a more effective path? Other applications have followed this approach before; it's not rocket science.
lorenzhs 10y ago
> Many successful applications follow a plugin model Uhm, do you have examples to support your claim? None of the truly successful applications I know do this, as it's rather inconvenient from the user's perspective. All in all, I think your issue is with the Android permission model, not Signal, while suggesting workarounds how Signal could improve the situation a little.
- iamnothere 10y ago
  Automate (by Llamalab) is the best example that comes to mind. Tasker also uses plugins, but their "base" app has too many permissions. A few other applications that use plugins: * ES File Explorer * Trigger * FB Reader * Threema And there are others. Most of these don't do this for the explicit purpose of permissions management (Automate may be the only one), but there's no reason that security can't be the primary motivation for a plugin system. There's another bonus to this approach: a plugin architecture allows you to add controversial features without forcing them on your user base. Don't like a new feature? Don't install it. Yes, a plugin architecture adds complexity. However, Android's intent system is built to simplify this kind of design, so it's not like you have to build it all from scratch.
  - andrewpi 10y ago
    I could be wrong, but it seems like none of those apps are really mass marketed to consumers (versus power users). The goal for Signal is to make it something that could gain mass adoption, and requiring users to install plugins in order to do simple things like attach photos would be a serious hinderance there. It's hard enough to convince non-techie friends to install another messenger as it is.
    - qznc 10y ago
      Threema is a direct competitor to Signal.
      - lighthazard 10y ago
neves 10y ago
> * External storage (why not use internal "app only" storage?) I'm low on space in my 16Gb android phone. I'm moving everything I can to external storage. My greatest problem is some apps that doesn't allow it, like WhatsApp.
pstrateman 10y ago
It's open source. You can see exactly what it's doing. The issue with permissions is closed source apps that do shady things with extra permissions...
- iamnothere 10y ago
  The problem isn't whether you can understand the code or not. The problem is whether or not there are undiscovered exploits in the code that would allow attackers to take advantage of Signal's relatively open permissions. It's very hard to write bug-proof code. Restricted permissions would be a sensible countermeasure since Signal is a likely target.
  - angry_octet 10y ago
    I was down voted heavily for suggesting that! I don't really think that breaking out of its sandbox is the problem though, its touching and manipulating data from the network. All the data I worry about losing is inside the signal app. It would be better if features could be disabled. Sadly the only way to achieve that is to fork the code base and run your own dev build.
angry_octet 10y ago
Android does not have fine grained permissions(to be fair, neither does iOS), nor the ability to internally segregate components or define inter-app trust. So while you are correct, the only option is to disable features. Features are necessary to build usage out of the pgp using ghetto to the ordinary cell phone user.

AdmiralAsshat 10y ago

On Marshmallow or newer, can't these be blocked? I was alarmed at the Location permissions at first too, but I believe it's only used so that you can send someone your GPS location. If you simply deny the request, that feature will be disabled, but I don't think it prevents the app from working.

iamnothere 10y ago
Only some can be blocked. Unfortunately Android still groups permissions together, and all related permissions must be enabled or disabled as a block. (For instance, storage read and write permissions are technically separate, but they are placed together in a single "storage" group.) Most (all?) permissions in the catch-all "other" group cannot be disabled at all.
- nitrogen 10y ago
  One of the interesting irrevocable permissions in that "Other" group is full network access, so any app can portscan your network or try to hack your IoT devices. Bluetooth pairing is also in Other. The Android permission model is terrible. What ever happened to Intents? Shouldn't photo sharing be a simple Intent rather than requiring a new UI and storage permissions for every single app?
  - angry_octet 10y ago
    Can I suggest a nice program called NetGuard? But yes, and this is a deliberate Google policy, also like the don't want ad blocking programs. You are an input to their revenue generating system, not a client.

codethief 10y ago

> A few examples of excessive permissions: > * Disable your screen lock I believe this is for the "call screen" (though it's never really worked for me and my phone gets or stays locked nonetheless when I call someone or someone calls me). > * External storage (why not use internal "app only" storage?) Because otherwise you can't extract photos you received (let alone view videos) which, from a security standpoint, is good but it's something you'll have a hard time selling to the average user. The same goes for sharing your location.

iamnothere 10y ago
I agree that there are legitimate reasons for these permissions, I just don't think they match up with everyone's use case for the product. This is why they should be split into plugins. Example of how the UX for this works: 1. User chooses "attach photo." 2. If user has not installed the plugin, Signal gives them an informational prompt and a button that opens the app store link. 3. User clicks the button to go to the app store. 4. User clicks "install." Application is installed (should be quick, small app) 5. User can now attach photos from external storage. Steps 2-4 are short and occur only one time. You would not want this kind of extra friction in a true mass market app, but I'd argue that Signal is not and never will be mass-market. (We can hope, but it's not likely.) Signal's target users, on the other hand, would be likely to appreciate this extra focus on security and user control.
- tedks 10y ago
  Here's how the UX actually works: 1. User chooses "attach photo." 2. The user hasn't installed the plugin. Who does that? So signal doesn't work. 3. The user sends their contact a facebook message saying "signal isn't working" and attaches the photo. 4. Both users uninstall signal and tell everyone who mentions it that it can't even send picture messages.
  - iamnothere 10y ago
    That would be poor design. Are you saying that the Signal team would not be capable of implementing a more effective path? Other applications have followed this approach before; it's not rocket science.

lorenzhs 10y ago

> Many successful applications follow a plugin model Uhm, do you have examples to support your claim? None of the truly successful applications I know do this, as it's rather inconvenient from the user's perspective. All in all, I think your issue is with the Android permission model, not Signal, while suggesting workarounds how Signal could improve the situation a little.

iamnothere 10y ago
Automate (by Llamalab) is the best example that comes to mind. Tasker also uses plugins, but their "base" app has too many permissions. A few other applications that use plugins: * ES File Explorer * Trigger * FB Reader * Threema And there are others. Most of these don't do this for the explicit purpose of permissions management (Automate may be the only one), but there's no reason that security can't be the primary motivation for a plugin system. There's another bonus to this approach: a plugin architecture allows you to add controversial features without forcing them on your user base. Don't like a new feature? Don't install it. Yes, a plugin architecture adds complexity. However, Android's intent system is built to simplify this kind of design, so it's not like you have to build it all from scratch.
- andrewpi 10y ago
  I could be wrong, but it seems like none of those apps are really mass marketed to consumers (versus power users). The goal for Signal is to make it something that could gain mass adoption, and requiring users to install plugins in order to do simple things like attach photos would be a serious hinderance there. It's hard enough to convince non-techie friends to install another messenger as it is.
  - qznc 10y ago
    Threema is a direct competitor to Signal.
    - lighthazard 10y ago

neves 10y ago

> * External storage (why not use internal "app only" storage?) I'm low on space in my 16Gb android phone. I'm moving everything I can to external storage. My greatest problem is some apps that doesn't allow it, like WhatsApp.

pstrateman 10y ago

It's open source. You can see exactly what it's doing. The issue with permissions is closed source apps that do shady things with extra permissions...

iamnothere 10y ago
The problem isn't whether you can understand the code or not. The problem is whether or not there are undiscovered exploits in the code that would allow attackers to take advantage of Signal's relatively open permissions. It's very hard to write bug-proof code. Restricted permissions would be a sensible countermeasure since Signal is a likely target.
- angry_octet 10y ago
  I was down voted heavily for suggesting that! I don't really think that breaking out of its sandbox is the problem though, its touching and manipulating data from the network. All the data I worry about losing is inside the signal app. It would be better if features could be disabled. Sadly the only way to achieve that is to fork the code base and run your own dev build.

angry_octet 10y ago

Android does not have fine grained permissions(to be fair, neither does iOS), nor the ability to internally segregate components or define inter-app trust. So while you are correct, the only option is to disable features. Features are necessary to build usage out of the pgp using ghetto to the ordinary cell phone user.