It is well known that the only reliable way to enforce a unique property in a Google Cloud Datastore kind is through a key property. So let's say we were building a Google AppEngine (GAE) application using the Google Users API to authenticate users, and we wanted to create a kind called Profile. There can only be one profile per user. It would make sense to store the User object id as the key property in order to enforce this uniqueness, right? In fact, the Google App Engine User API documentation even says this:
Using User Values With the Datastore
The user ID is stable; you can use it in a key name or as a string property. Therefore, when using user values, you want to store the user ID
But suppose our app needs to show, in the browser, hyperlinks to these user profiles. Is it appropriate to form the url with the user.user_id() string? Shouldn't the user id be treated as sensitive information? A person's Google account user_id is the same across all Google applications. Leaking to a browser doesn't seem right, but I can't find any prohibitions in the GAE docs (unless I am missing something).
Now if the user id should not be leaked to the client, is it supposed to be hashed? Or is there some other way to design a kind in which the Google user id should be unique?
Note: I'm fine using the user id as a key and comparing it to the current user in authenticated endpoints, for example. The question has to do with whether it can be exposed to a browser (doesn't feel right) and if not, how one in general handles cases where the owner (application user) of a resource (such as a blog post) needs to be visible within the application.
Google Security seems to be ok with it being exposed through the browser.
Google+ uses it in the URL when showing a user's profile and as part of the URL for their posts.