From 2bba2bbee2a38bd23e51a9c0c09a3d7ffed8b1cf Mon Sep 17 00:00:00 2001
From: gorhill <rhill@raymondhill.net>
Date: Thu, 9 Oct 2014 10:21:36 -0700
Subject: [PATCH] Updated Dynamic filtering: Examples of usefulness of blocking
 3rd party iframe tags (markdown)

---
 ...Examples-of-usefulness-of-blocking-3rd-party-iframe-tags.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Dynamic-filtering:-Examples-of-usefulness-of-blocking-3rd-party-iframe-tags.md b/Dynamic-filtering:-Examples-of-usefulness-of-blocking-3rd-party-iframe-tags.md
index 2a24b73..72fe992 100644
--- a/Dynamic-filtering:-Examples-of-usefulness-of-blocking-3rd-party-iframe-tags.md
+++ b/Dynamic-filtering:-Examples-of-usefulness-of-blocking-3rd-party-iframe-tags.md
@@ -14,4 +14,5 @@ Simply blocking 3rd-party `<iframe>` by default foils such exploit.
 
 In the above case, blocking 3rd-party scripts would have been even better, as the malicious code would have been prevented from creating the malicious `<iframe>` in the first place. But for users with low tolerance to site breakage, blocking 3rd-party `<iframe>` by default (i.e. on all sites by default) is really the best solution.
 
-Ultimately, if a site breaks because it really does need legitimate 3rd-party `<iframe>`, than un-blocking for that specific site is only one click away.
\ No newline at end of file
+Ultimately, if a site breaks because it really does need legitimate 3rd-party `<iframe>`, then un-blocking `<iframe>` for a specific site is only one click away:
+