From 72f6b9399b245aac324661237dae8e8fc8bdd2cd Mon Sep 17 00:00:00 2001
From: Raymond Hill <gorhill@users.noreply.github.com>
Date: Fri, 7 Aug 2015 09:50:44 -0400
Subject: [PATCH] Updated Dynamic filtering: Benefits of blocking 3rd party
 iframe tags (markdown)

---
 ...mic-filtering:-Benefits-of-blocking-3rd-party-iframe-tags.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Dynamic-filtering:-Benefits-of-blocking-3rd-party-iframe-tags.md b/Dynamic-filtering:-Benefits-of-blocking-3rd-party-iframe-tags.md
index 383cfc1..13b1e59 100644
--- a/Dynamic-filtering:-Benefits-of-blocking-3rd-party-iframe-tags.md
+++ b/Dynamic-filtering:-Benefits-of-blocking-3rd-party-iframe-tags.md
@@ -18,7 +18,7 @@ Using 3rd-party-sourced `<iframe>` to inject exploit on a user's computer is qui
 
 **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.
+Blocking 3rd-party scripts is generally even better, as the malicious code would have been prevented from executing 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.
 
 Blocking 3rd-party `iframe` tags will typically cause little web page breakage, far less than the more thorough alternative of blocking 3rd-party javascript, so blocking 3rd-party `iframe` tags is an approach that can work even for less advanced users.