On Wed, Feb 4, 2015 at 5:59 AM, Erik Romijn <erom...@solidlinks.nl> wrote: > > On 03 Feb 2015, at 16:44, Jon Dufresne <jon.dufre...@gmail.com> wrote: >> However some URLs are accessed by a unique URL >> containing a nonce without a login. Login is not an option for these >> URLs. Sharing this URL is considered very bad and I would like to >> avoid it happening unintentionally. > > I'm not following this: to prevent this case, you are actively > instructing all your users to disable referer headers in their browsers? > If not, how are you controlling what referrers your users send?
I am not instructing my users to do anything with their headers. This would never be feasible for me. I mentioned some users may do so independently. I *want* to help control referrers using the new meta referrer tag. This is a new feature not yet supported in all major browsers. See: https://blog.mozilla.org/security/2015/01/21/meta-referrer/ https://w3c.github.io/webappsec/specs/referrer-policy/#referrer-policy-delivery-meta https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta (search referrer on page) > > URLs without login, which contain a secret nonce, are indeed sensitive > to the nonce leaking through the referer. Dropbox ran into this a > while ago: > https://blog.dropbox.com/2014/05/web-vulnerability-affecting-shared-links/ > > This also affected Evernote for some time. The common resolution seems > to be not to disable referer headers, which is a client-side issue, but > to mask it by sending all external links through a specific URL first > without the nonce, which works as a simple redirector. > > Far from ideal, especially when dealing with more complicated links like > when sharing office documents. But it seems to work for Dropbox and > Evernote. You'll notice for example that when viewing a PDF on Dropbox, > you're not using your in-browser PDF viewer but Dropbox' custom viewer, > which I imagine also modifies all external links. Thanks. Aymeric suggested a similar scheme to me earlier. I will take it under consideration. However, In my opinion, the user's privacy needs go beyond this one scenario. When going cross origin, it is never the business of the final destination where I started. Interestingly enough, the links above have an "origin-when-crossorigin" mode (but not "no-referrer-when-crossorigin"). However, this is not supported on Chrome and so it defaults to "no-referrer" which, once again, breaks Django POST over HTTPS. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CADhq2b7MYsFmnXdbOREzmv-5HtnzEdEr0ci8%2B7EfbGx%3DABSjPQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
