From 74475f284c059137c702c8ddeae0cbe85c5e34a7 Mon Sep 17 00:00:00 2001
From: Raymond Hill <gorhill@users.noreply.github.com>
Date: Fri, 7 Aug 2015 09:35:39 -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 c859cfb..4dadf05 100644
--- a/Dynamic-filtering:-Benefits-of-blocking-3rd-party-iframe-tags.md
+++ b/Dynamic-filtering:-Benefits-of-blocking-3rd-party-iframe-tags.md
@@ -20,7 +20,7 @@ Using 3rd-party-sourced `<iframe>` to inject exploit on a user's computer is qui
 
 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 `iframe` tags will typically cause little web page breakage, far less than the more through alternative of blocking 3rd-party javascript, so blocking 3rd-party `iframe` tags is an approach that can work even for less advanced users.
+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.
 
 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: