title: Workaround for Firebase's "Rules Are Not Filters" constraint
body: <p>I’d like a security rule that lets anyone get a list of users and read their names, but only allows logged in users to view their own email.</p>
  
  <p>Here’s an example data structure:</p>
  
  <pre><code>    "User" : {
          "abc123" : {
            "name" : "Bob",
            "email" : "bob@hotmail.com"
          }   
      }
  </code></pre>
  
  <p>A naive approach to a security rule might be to do the following:</p>
  
  <pre><code>"User" : {
      "$user" : {
          "name" : {
              ".read" : true
          },
          "email" : {
              ".read” : "auth.uid === $user"
          }
      }
  }
  </code></pre>
  
  <p>However because there is no read rule at the User level, requests to read the list will be denied. But adding a read rule at the User level will override the email rule, and make every child node readable (see <a href="https://www.firebase.com/docs/security/guide/securing-data.html#section-cascade" rel="noreferrer">Rules Cascade</a> in Firebase's Security Guide).</p>
  
  <p>The Security guide does point out that <a href="https://www.firebase.com/docs/security/guide/securing-data.html#section-filter" rel="noreferrer">Rules Are Not Filters</a>, but doesn’t offer much guidance as to what to do about it.</p>
  
  <p>Should I just split my User entity up into PrivateUser and PublicUser?</p>