Update good-policies.md

stacyspiva · web-flow · commit f610c1435bfd · 2018-10-05T08:10:09.000-07:00
diff --git a/docs/programs/good-policies.md b/docs/programs/good-policies.md
@@ -13,10 +13,10 @@ Bounty Program | Define the vulnerability types you care about most and provide
 Exclusions | Create exclusions for the vulnerabilities hackers should ignore. 
 Scope | List the URLs in scope for your program.
 
-Some successful security pages you can refer to as examples are: [Twitter](https://hackerone.com/twitter), [Dropbox](https://hackerone.com/dropbox), [Square](https://hackerone.com/square), [Yahoo](https://hackerone.com/yahoo).
+Some successful security pages you can refer to as examples are: [Twitter](https://hackerone.com/twitter), [Dropbox](https://hackerone.com/dropbox), [Yahoo](https://hackerone.com/yahoo).
 
 Other best practices to keep in mind are:
-* **Keep your policy succinct.** Longer policies may lose leadership toward the end. 
+* **Keep your policy succinct.** Longer policies may lose readership toward the end. 
 * **Set clear expectations with hackers.** If your response time or fix time is much longer than recommended, state it in your policy. It's good practice to respond to researchers within 3-5 days and to have complete fixes within 45 days. 
 * **Give responses updating a hacker that you're still reviewing a report.** Such actions let hackers know that their work hasn't gone into a black hole.
 * **Re-evaluate your policy on a recurring basis.** Your policy will and should change as your bug bounty program matures. 
