Code review comment for lp:~thomas-voss/trust-store/fix-1504022

Revision history for this message
Thomas Voß (thomas-voss) wrote :

> The standard permission prompt message is of the form
> <appname> wants to access <property>.
> for example
> Frobnicator Turbo wants to access your location.
> so the attack you have in mind is for Frobnicator Turbo to pretend to be
> another app:
> Browser wants to access your location.
>
> Especially while people are used to hardly anything happening in the
> background, this might often fail. People would think, "Huh? I'm not using
> Browser at the moment. Why is it asking me now?"
>
> Showing the app icon would help now, but it would lose its effectiveness once
> bug 1453795 is fixed.
>
> Including the application id might protect geeks, but I expect most people
> would ignore it, or think it was a bug, on the grounds that it looks like
> code. If it was embedded in the prompt text,
> <appname> (<appid>) wants to access <property>.
> then an app could even explain it away with a devious name:
> Browser (downloadable from
> producing the prompt
> Browser (downloadable from (frobnicator-turbo.comorg) wants to access your
> location.
> The profusion of TLDs leaves that plausible even to geeks who aren't familiar
> with the exact format of the prompt. Few would notice the unmatched bracket.
> So if it's included at all, I think it should be secondary text, like in the
> "Details" section for PolicyKit prompts.
> <https://wiki.ubuntu.com/AccountPrivileges#Details>
>
> Meanwhile, an app could do much more devious things with its name. Maybe we
> can address these at the same time, or maybe they need to be tackled
> separately. For example, an app could give itself a name something like
> Browser wants to access only your bookmarks. It does not
> which would produce prompt text of the form
> Browser wants to access only your bookmarks. It does not wants to access
> your location.
> This would be slightly ungrammatical ("does not wants"), but would still fool
> many people.
>
> How to mitigate this? We could put the app name in quote marks:
> “Browser wants to access only your bookmarks. It does not” wants to access
> your location.
> But then the app could jimmy its own opposing quote marks into its name:
> Browser” wants to access only your bookmarks. It does “*not*
> producing the only-slightly-less-believable prompt:
> “Browser” wants to access only your bookmarks. It does “*not*” wants to
> access your location.
> (This idea adapted from <https://www.squarefree.com/dialogs2010/exec-warning-
> injected.png>.)
>
> (We couldn't prevent that by banning use of quote marks, because there are
> many other Unicode characters that look like quote marks, including
> apostrophes: Baldur’s Gate, Sid Meier's Civilization, Tony Hawk's Pro Skater
> 2, etc.)
>
> We could limit the length of app names to something like 30 characters:
> “Browser wants to access only
> That would put the kibosh on those obfuscation attacks ... in most languages.
> Not in kanji ones, unfortunately:
> 浏览器要访问您的书签。它不希望访问您的位置。
> But maybe mitigating the attack in most but not all languages is better than
> mitigating it in none of them.
>
> We could put the app name in color, while the rest of the text is the normal
> UI color. But apparently that hasn't stopped malware in the past.
> <https://www.squarefree.com/dialogs2010/activex.png>
>
> Perhaps a harmonious way of combining a bunch of these approaches is to
> present the app icon, and its name, using the same font, alignment, and
> ellipsis of long names as is used in the Apps scope of the Dash. The app id
> could be centered as secondary text below the app name.
>
> [#]
> App Name
> (app id)
>
> wants to access
> your location
>
> (Deny) (Allow)

I like the last proposal, it also gives some visual bling to an otherwise really boring dialog.

« Back to merge proposal