<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 7, 2015 at 7:54 AM, Thomas Goirand <span dir="ltr"><<a href="mailto:zigo@debian.org" target="_blank">zigo@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12/04/2015 03:23 PM, Anne Gentle wrote:<br>
><br>
><br>
> On Fri, Dec 4, 2015 at 8:09 AM, Thomas Goirand <<a href="mailto:zigo@debian.org">zigo@debian.org</a><br>
</span><span class="">> <mailto:<a href="mailto:zigo@debian.org">zigo@debian.org</a>>> wrote:<br>
><br>
> Hi,<br>
><br>
> I've investigated a bit the openstackdocstheme, and tried to remove some<br>
> of the (numerous) javascript with external references. And it's *very*<br>
> ugly: it's full of google stuff, random CDN and so on.<br>
><br>
><br>
> I absolutely want to address these concerns.<br>
<br>
</span>Hi,<br>
<br>
Thanks for replying.<br>
<br>
Let me start by this. In Debian, I'm adding this patch:<br>
<br>
<a href="http://anonscm.debian.org/cgit/openstack/python-openstackdocstheme.git/tree/debian/patches/patch-out-external-references.patch" rel="noreferrer" target="_blank">http://anonscm.debian.org/cgit/openstack/python-openstackdocstheme.git/tree/debian/patches/patch-out-external-references.patch</a><br>
<br>
Now, let me explain why.<br>
<span class=""><br>
> Let's start with making sure I understand the concerns so we can start<br>
> tracking the work requirements with bugs.<br>
><br>
> 1. Google stuff, considered non-free. Can you list specifics? Fonts and<br>
> analytics js for starters, let me know if there are others?<br>
<br>
</span>It's not only about non-freeness, it's also about the fact that I don't<br>
want Google to know when I'm browsing my local hard drive HTML, which it<br>
would when browsing any OpenStack docs generated by OpenStack packages<br>
in Debian, without the Debian patch to openstackdocstheme.<br>
<br>
Also, look at this from<br>
openstackdocstheme/theme/openstackdocs/script_footer.html (@@ -50,17<br>
+50,3 @@ in my patch):<br>
<br>
gcse.src = (document.location.protocol == 'https:' ? 'https:' : 'http:') +<br>
<br>
Well, if I'm using file:// to browse some HTML docs, then it's going to<br>
fetch <a href="http://www.google.com/cse/cse.js" rel="noreferrer" target="_blank">www.google.com/cse/cse.js</a> over a non SSL connection. That's a<br>
security issue.<br>
<br>
I believe there is the same issue with google analytics.<br>
<span class=""><br>
> 2. Random CDN: maxcdn, which was provided to us by the Foundation's web<br>
> designer who gave us the design. We need CDN for performance reasons.<br>
> What CDN meets your requirements?<br>
<br>
</span>Users browsing the local hard drive documentation don't want to access<br>
an external resource, even on a CDN. It would even be slower.<br>
<br>
The idea to speed-up browsing on the <a href="http://openstack.org" rel="noreferrer" target="_blank">openstack.org</a> is a very good one,<br>
and I salute the effort to use such a CDN. But let's not forget that the<br>
generated docs also end up in the distribution FOO-doc packages.<br>
<span class=""><br></span></blockquote><div><br></div><div>I think that this falls into the category that we need a way to add in the CDN information for the related resources when generating the docs. The publish job that pushes this data up to the actual websites can handle the toggling this change. This should totally be both reasonable and accepted (will require an infra change as well long term). I agree that the use of the CDN for local docs is not the right choice. Clearly this is a bug/enhancement that should be made.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> 3. Non-minified JS, being worked on two bugs now. [1] [2]<br>
><br>
> Does that list capture your "ugly" claim in a measureable manner?<br>
><br>
> [1] <a href="https://bugs.launchpad.net/openstack-manuals/+bug/1501641" rel="noreferrer" target="_blank">https://bugs.launchpad.net/openstack-manuals/+bug/1501641</a><br>
> [2] <a href="https://bugs.launchpad.net/openstack-manuals/+bug/1502806" rel="noreferrer" target="_blank">https://bugs.launchpad.net/openstack-manuals/+bug/1502806</a><br>
><br>
> Not only this, but generated docs could potentially do call some of<br>
> these objects without using HTTPS (which is the case when browsing a<br>
> local *-doc package generated sphinx document using file://).<br>
><br>
> Could you list the calls in a bug please? That will help with triaging.<br>
<br>
</span>Well, last time I opened such a bug, it was closed and tagged "wontfix",<br>
and my patch was voted out. On patch [1], it was marked as low priority<br>
as well. I've seen no activity on #1502806 for a month and a half too. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If I open such bugs again, will there be actions on them?<br>
<span class=""><br>
> At the present moment, I would recommend projects to *not* use the<br>
> openstackdocstheme at all until all of this is fixed.<br>
><br>
><br>
> I'd like to understand your concerns further and specifically before<br>
> taking this type of action.<br>
><br>
> I'm also thinking: am I the only one in this community that cares about<br>
> browsing privacy?<br>
><br>
> Of course not, and with this line of reasoning and lack of clarity and<br>
> specificity you are not representing actual privacy concerns but trying<br>
> to manipulate emotions.<br>
<br>
</span>See above: I'm doing this after my bug + patch were closed, so I had no<br>
choice but to open this kind of thread on the dev list. On the list, it<br>
seems taken more seriously. I'm ok to take actions myself, and propose<br>
patches, only if I have the insurance it wont just be denied.<br>
<br></blockquote><div><br></div><div>There is never insurance that the patches wont be denied, but I think you've made some reasonable arguments as to why these should be updated/changed. I think that the non-free aspect is a bit more serious (in my world view) than the privacy aspect for google knowing I'm looking at docs on my local hard disk. I do also get that we all have different priorities and they are not guaranteed to be in-sync. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, even after your reply, I keep saying the same thing: until these<br>
issues are fixed, I am giving the advice to *not* use<br>
openstackdocstheme, because there's security concerns.<br>
<br>
Also, please don't accuse me of trying to "manipulate emotions" after<br>
filing explicit bugs about it: the issues are real, and I have been<br>
explicit and specific, opening bugs in launchpad for the use of Google<br>
Analytics.<br>
<div class="HOEnZb"><div class="h5"> <br></div></div></blockquote><div><br></div><div>I think we have all agreed so far that docs should be self-contained (for multiple reasons). Adding in Analytics could be handled in the same way as listed above for enabling the CDN. Statically enabling google analytics is about the same as always requiring the use of the CDN even for local browsing. Lets keep the accusations/defence of wording choices out of the rest of the thread and focus on getting the docs to a place that works for all the parties. I did see the earlier comment that the external resources (due to national firewalls) are a real impact, that alone should be enough to encourage the changes. <br></div><br></div><div class="gmail_quote">So in short, I think Anne's summary is good, but is missing two items, below I've tried to cover the things we should target to get the docs theme in shape:<br><br></div><div class="gmail_quote">1) CDN is not useful for local browsing (and may actually be a detriment). This can be enabled as a build-time job (as I described above)<br></div><div class="gmail_quote">2) Non Minified JS (actively being worked on).<br><br></div><div class="gmail_quote">The additional points are (as outlined by Thomas):<br><br>* We should not (regardless of free/non-free/etc) make sure that the docs are fully self-contained when built locally. This would address the privacy and security issues for the local docs. (Again Analytics can be enabled as a build-time job).<br>* We should ensure we are only loading any external sources via HTTPS rather than HTTP.<br><br><br></div><div class="gmail_quote">Cheers,<br></div><div class="gmail_quote">--Morgan<br></div><div class="gmail_quote"><br></div></div></div>