Problem/Motivation
Drupal 8 will ship with far more JavaScript. Drupal 8 will need to perform well on mobile.
This means we must allow JavaScript code to apply smart client-side caching strategies in order to provide a fast experience. Two of the most obvious things to cache are: 1) user-specific data, 2) permission-dependent data.
Proposed resolution
Allowing JS to have access to the user ID is a non-problem, as per http://drupal.org/node/1004778.
Allowing JS to have access to the precise list of permissions might be problematic, especially when combining that data with security announcements which often mention specific permissions. However, what really matters is to know whether the permissions have changed at all for a given user, which would force us to invalidate whatever has been cached client-side. So, a hash of the hash salt plus the serialized list of permissions is a secure, yet sufficiently informative identifier.
Remaining tasks
Reviews needed, tests need to be written.
User interface changes
None.
API changes
User ID and a "permissions hash" are provided to Drupal JavaScript.
Related Issues
#1872264: Minimize metadata HTTP requests triggered by Edit's JS