diff --git a/zip-0315.rst b/zip-0315.rst
index 6abe6f9a..5b93a331 100644
--- a/zip-0315.rst
+++ b/zip-0315.rst
@@ -25,10 +25,6 @@ Auto-shielding
     The process of automatically transferring transparent funds to the most recent
     shielded pool on receipt.
 
-Opportunistic shielding
-    The process of transferring previously received transparent funds to the most
-    recent shielded pool as part of a user-initiated transaction.
-
 Auto-migration
     The process of automatically transferring shielded funds from older pools to the
     most preferred (usually the most recent) pool on receipt.
@@ -121,13 +117,32 @@ Long-term storage of funds
 It is RECOMMENDED that wallets only hold funds as shielded in the long term;
 that is, if a wallet supports receiving transparent funds (or supports
 importing a seed from another wallet that might have done so), then it SHOULD
-either auto-shield or opportunistically shield such funds by default.
+auto-shield such funds by default.
 
-Following this recommendation improves both collective privacy and the user's
-individual privacy, by maximizing the size of the note anonymity set over time.
+A shielding transaction is always linked to the transparent addresses it
+spends from. This can cause undesirable information leaks:
+a) if there are multiple transparent addresses, they will be linked to each
+   other;
+b) a link between the input transparent address(es) and the payment will be
+   visible to the recipient(s), or to any other holder of an Incoming Viewing
+   Key for the destination address(es).
 
-The remainder of this specification assumes a wallet that follows the above
-recommendation, except where explicitly noted.
+Despite the fact that it is not possible to achieve strong privacy guarantees
+from *any* use of transparent addresses, it is undesirable to reveal this
+additional information. In particular, issue b) motivates ruling out the use
+of "opportunistic shielding", i.e. shielding previously received transparent
+funds as part of a user-initiated transaction.
+
+Wallets SHOULD NOT auto-shield from multiple transparent addresses in the
+same transaction, and SHOULD NOT use opportunistic shielding.
+
+Following all of the recommendations in this section improves both collective
+privacy and the user's individual privacy, by maximizing the size of the note
+anonymity set over time and minimizing the potential linkage of shielding
+transactions to other transactions.
+
+The remainder of this specification assumes a wallet that follows all of these
+recommendations, except where explicitly noted.
 
 A wallet MAY allow users to disable auto-shielding.