Patryk Adamczyk [:patryk] UX Reporter
	Description • 10 years ago

Whenever a user clicks on link from an email, they get presented with an annoying "this could be a malicious link" dialog. Its a good warning to have, however there are ways around this that are not so user facing.

If we can't implement smarter security technology like our competitors by 2.2, than atleast please let us implement a "Remember my choice" checkbox in the dialog to "never show this again".

	Andrew Sutherland [:asuth] (he/him)
	Comment 1 • 10 years ago

Juwei and I had some email discussion about this, first message:


On 10/06/2014 11:15 PM, Juwei Huang wrote:
> Visual team is asking why we need a confirm window before accessing the hyperlink in email message.
> They think it's bothersome that every time they have to go through the pop-out window to go to the website.

The primary concern is security / phishing.  For an HTML email where we're dealing with a hyperlink of the form <a href="actual-url">thing to display</a>, the user only sees "thing to display".  When they click on the link, if we don't prompt them, they will only see "actual-url" for fractions of a second before the web browser replaces the URL with the title provided by the page.

Right now an attacker can easily fashion an email that, based on how our UI works:
- Looks like it's from "official-person@yourbank.com" but is not.
- Includes a link whose display text makes it seem like the user is browsing to "https://yourbank.com/" but is really browsing to "https://evil-bad-bank.com/"
- Has https://evil-bad-bank.com display a document title of "Your Bank"

While the web browser is slowly improving the situation for users who care, the main problem we have with email is that it's basically unsolicited and so it's a very different context from using our web browser.  If you type something random into our search box, you're going to get data provided by Google or everything.me.  While attackers can purchase Google ads and create fake sites, Google uses various heuristics to help protect users and is involved in the process.

In the case of the email app, we do basically nothing to protect the user and so leave it up to them so that confirmation UI is our only line of defense.

There are things we could do to help eliminate the need for the confirmation UI and even provide advice to the user.  For example, Thunderbird has anti-phishing heuristics.  If the display text for a URL is the same as the actual URL, Thunderbird is happy.  If the display text for the URL looks like a URL but is not the same as the actual URL (for example, some Mozilla emails say they are to https://mozilla.com/blah but are actually to a link shortener like http://mzl.la/u2o345 or something like that), Thunderbird throws up a phishing warning.

A big concern for the email app is that a lot of the protection of the user potentially needs to happen on the server-side, but our mail client has no idea what the capabilities of the server are or what defenses it is enforcing.  For example, the Sender Permitted From (SPF) and Domain Keys (DKIM) mechanisms allow a mail server to verify that an email was actually sent from the domain it claims to be from.  Some servers enforce this when possible, some don't.  Our mail client could attempt to perform secondary verifications in some cases.


The secondary concern has historically just been that the touch-screens on our devices are not great and that the pinch-to-zoom or double-tap-to-zoom heuristics might sometimes result in a click firing when the user didn't mean it.  Especially on the lower end devices we've used, it can be a hassle for the user to accidentally trigger the web browser; it's much faster for us to do the prompt.


But it's mainly the security/phishing thing.  A heuristic I like to use in these cases is whether I, an expert at these things, have a chance of telling the difference between a legitimate email and a phishing email from an attacker.  And whether I would notice this in the normal course of operations or whether I would have to go out of my way to determine if I was being attacked.  I believe that given the rest of the current design of the email app and the browser subsystem of Firefox OS, removing the confirmation prompt would tip us into the case where even informed users would have no idea whether they were being subjected to a phishing attack or not.


There are definitely things we could do to improve the situation, especially in the cases where legitimate URLs from legitimate advertisements are very long and confusing to users.  Specifically, we could do something like the Firefox desktop URL bar does and show the TLD+1 domain with special highlighting.  Like when I am at "https://docs.google.com/blah/blah/blah", "google.com" is displayed in black and everything else is in gray.  The most important thing for the user is to know what the root of the domain they are accessing is.  Especially since attackers can create situations like "google.com.hahaha-i-am-actually-an.evil-attacker.com" and naive users may see "google.com" and think that's what they're dealing with.

	Andrew Sutherland [:asuth] (he/him)
	Comment 2 • 10 years ago

Second message:

On 10/07/2014 05:17 AM, Juwei Huang wrote:
> Hi Andrew!
>
> Thanks for your explanation, very helpful!
>
> I'm also thinking that maybe we could have some mechanism to review whether the link is safe or not.
> As you said, if the "actual link" is what it displayed on the screen, then we could let it go.
> But I'm wondering there's still some possibilities that the link is exactly as it displayed such as "https://evil-link.com" but users don't know it's evil...
> Or can we let Browser to handle this case? (such as showing a "This connection is untrust" on browser as every browser does)

== Existing Phishing / Malware detection support

So, Firefox desktop does have some support for checking with a Google database about reported phishing and malware sites.  The support page on that is https://support.mozilla.org/en-US/kb/how-does-phishing-and-malware-protection-work. However, I have no idea whether Firefox OS actually uses that mechanism right now or not.

The key thing to be aware of is that the database of reporting phishing/malware sites is not complete, and is probably most useful for cases where attackers can't control the URL the users sees on a per-user basis (which is not the case for email).  For email, spammers/phishers/etc. have gotten very good at creating new domains for each spamming run and just like advertisers can at least fashion unique URLs.

It's also useful to keep in mind that there are also targeted (spear-phishing) attacks which users are more likely to click on links.  And in these cases we don't expect the Google phishing/malware URL-mechanism to protect the user.  Coincidentally, this is also a case where it would probably be good to be proactive and indicate that a mail looks suspicious.

== Untrusted Connections

This warning is for cases where a site is serving an invalid SSL/TLS certificate.  As you say, all browsers do this, which is why most phishing attacks won't try and actually send a user to "https://yourbank.com".  They'll send them to an unencrypted site via http or via encrypted https to a different URL that they can make look like the real site.

== Letting the browser handle it

It's still important that the user knows the actual URL they are browsing to, since we can't depend on the phishing/malware detection alone to handle things.  Additionally, the entire security model of the web is based on origins/domains and thereby the user actually understanding what origin/domain they're actually seeing.  This is not innately obvious to users which is why we also need our design patterns to help make users aware of this at least on an ambient level.

The current browser doesn't do enough that we could hide our dialog.  There are things the browser could do to let us hand off responsibility:

- Have the browser display the URL in the URL bar with the TLD+1 (top-level-domain + 1, see more context at https://publicsuffix.org/) given visual priority by being rendered with emphasis (black instead of gray) and being centered. (Currently the document's document-controlled title is displayed.) For security purposes, it would be preferable to do this at all times, but heuristics could also be used to only do this in cases where a change of origin-domain is occurring.  For example, any link opened by the email app, or any link from a webpage that changes domains.  A timeout could also be used to cross-fade the origin back to the document.title after some amount of time.

There are also things we could do that could also make sense if done by the browser:

- The email app could display an interstitial sort of whole-screen display that says "opening link to TLD+1" for a second or some amount of time long enough to convey the actual website the user is going to.  The web browser could also do this for us, but since that type of transition is one that webpages might be able to conceivably spoof, it might make sense to only do it from the email app.  (It really depends on how the transition/etc. is implemented and how obvious it is that it's beyond the reach of content.)  And we would want to *always* do it so the user expects it and understands what it means.


> Just want to clarify it before they file a bug to us :P

It's fine for them to file a bug.  We just wouldn't want to fix the bug / change the email app until we have a plan that both protects the user by informing them of the origin/domain/TLD+1 and improves their UX experience.  Our current solution is ugly/not great UX and opens the user to some confusion because it shows so much more than the origin/domain/TLD+1 and fails to emphasize the TLD+1.

	Andrew Sutherland [:asuth] (he/him)
	Comment 3 • 10 years ago

(In reply to Patryk Adamczyk [:patryk] UX from comment #0)
> Whenever a user clicks on link from an email, they get presented with an
> annoying "this could be a malicious link" dialog. Its a good warning to
> have, however there are ways around this that are not so user facing.

And for clarity, the string we use to populate the contents of the confirm dialog is:

browse-to-url-prompt = Browse to URL?: {{ url }}

	Juwei Huang[:juwei] Assignee
	Comment 4 • 10 years ago

I think we need to seek for the balance between secure & user friendly.
The pop-out window definitely a last line for security protection, yet it also bothersome for users in most of the cases.
Here I have some ideas...

A. Set up a mechanism to review whether the link is what it display. If the link is what it display, access the link directly without pop-out window. If not, pop out a warning window.

B. Add a check box "Remember my choice" on the pop-out window. User can choose not to show the window every time.

I think both plan A & B can reduce the times of pop-out window, yet we also want to make sure that users won't expose in high risk environment.
It would be great if Andrew you can help to evaluate these two ideas in terms of developer perspective, then we can see how we can improve the behaviour.
Thank you!

	Andrew Sutherland [:asuth] (he/him)
	Comment 5 • 10 years ago

This is really a comprehensive system-wide security thing, so I'm needinfo-ing :freddyb for security, :djabber for browser UX (based on the functional teams wiki), and Ben Francis as the owner of the FxOS browser sub-module.

I think the best/most important fix is for the browser app to make sure that it emphasizes the TLD+1 when triggered by a view activity (and possibly just changing origins, although that does not involve email).  The pseudo-code for this would be:

- In the URL bar / header, show the URL in grey text with the TLD+1 in black text.
  - Do not show the title yet
  - Do not hide the URL bar if we do some auto-hiding thing
  - Make sure to align the text display so that in the event of overflow the TLD+1 is right aligned with overflow going out the left.  (So in the event that domain is google-com-haha-evil.com, on a small screen we see "aha-evil.com" rather than "google-com")
- After N seconds of visible display (only start the timer when visible, reset the timer if we go hidden), only then let the document title be displayed or the URL bar be hidden.
- Don't let redirects bypass the mechanism.


This establishes the pattern that the user knows what link they've opened in all cases and they aren't dealing with any additional clicking or delays/etc.  Arguably the only cost is that they can't see the document.title immediately.  While a truncated document title is frequently more useful than a truncated URL, arguably this is a desirable trade-off.

And this lets us avoid the boilerplate popup.  An anti-phishing enhancement we could track separately is to show a popup when the visible text for a link resembles a URL but the underlying link is not to the actual URL.

	James Burke [:jrburke]
	Comment 6 • 10 years ago

In addition to enhancements in the domain display for the browser app, and the "hey this link looks like a URL but actually goes to a different URL":

One of my concerns is jumping over to a site that may use the request itself to gather info, or use XSS vulnerabilities to steal cookies, or to just use the request details. I fully appreciate my awareness of possible issues and level of paranoia may be above a more typical user, but I would like a way to do inspection before jumping into the browser app.

What I like to do in the other mobile OS I have used, is to long tap on the link, and that brings up an overlay that shows the URL and gives some options for what to do with the URL (like open, copy). This is particularly handy when words, and not a URL, are hyperlinked.

	Frederik Braun [:freddy]
	Comment 7 • 10 years ago

Andrew's suggestion to show eTLD+1 for a certain amount of time and then switch to a real title is a really nice idea. But it may be bad if the <title> says fakedomain.com and I can't come up with a wayto address this safely :|. We talked about emphasizing eTLD+1 in bug 1066477 comment 17 (and before) in the past.
(I keep saying eTLD+1, for *effective* Top-Level-Domain + 1, because the top-most-thing may be more than just one dot away, e.g., 'co.uk' and 'pvt.k12.ma.us')


The problem we are facing here exists for all links in Firefox OS but is just a bit worse for email, where link spoofing is just more common. I think we should keep showing the URL for links in emails unless the href attribute is *exactly* the same as the link text.
We *might* tone down the message towards a simple "Do you want to visit <url>" instead of "this could be bad" - I am not entirely convinced here.

I really  like where James' suggestion from comment 6 is going, i.e., providing a way to look up the full URL if desired. I'm just concerned that the long-press handler could be hijacked by the app. We would need to prevent this.

	Ben Francis [:benfrancis]
	Comment 8 • 10 years ago

I like the idea of highlighting TLD+1 of the URL like desktop Firefox does, but this is currently incompatible with the UX requirements of the Rocketbar which are:
* Display title in unfocused state
* Display selected URL in focused state, and show the end of URL by default for easier editing

Note that Firefox for Android doesn't do this either.

I hope Security + UX can figure out a solution between them.

	Andrew Sutherland [:asuth] (he/him)
	Comment 10 • 9 years ago

The browser app now seems to be displaying the loaded URL (focused on the left-hand of the URL) rather than the document.title of the loaded document.  This isn't perfect yet, but I think it's good enough for us to remove the prompt.

	BMO Automation
	Comment 11 • 6 years ago

Firefox OS is not being worked on