Merge lp://staging/~mbp/launchpad/798412-plusone into lp://staging/launchpad

Comments on BMPs do have URLs, we just don't expose them much. Mainly we expose the reply link.

Comment:
https://code.launchpad.net/~abentley/launchpad/person-bug-listings/+merge/83418/comments/180265

Reply link:
https://code.launchpad.net/~abentley/launchpad/person-bug-listings/+merge/83418/comments/180265/+reply

Questions comments do have a URL, but we have not registered a view to format them for the browser.
The URL is /<project>/+question/<question-id>/messages/<question-number> such as /launchpad/+question/168463/messages/1.

thanks guys, I will see about adding that.

https://answers.launchpad.net/launchpad/+question/168463/messages/1 is 404 even though there is a first message on that question.

I can see zcml that tries to set it up...

> Questions comments do have a URL, but we have not registered a view to format
> them for the browser.
> The URL is /<project>/+question/<question-id>/messages/<question-number> such
> as /launchpad/+question/168463/messages/1.

I had a go at trying to enable them, but I can't work it out :-(

Ok, the updates here add buttons on merge proposals, though not yet on answers, and factor some of it out into macros used across various pages.

This doesn't yet add or update tests. It probably needs some, probably written looking at the resulting html.

The biggest bug I know of is that it does not stay up to date well when the page is updated by ajax, either for privacy or for adding new comments.

So, this has rather significant private-object implications.

See for instance the discussions we had on-list about trust of third
party js API's that get access to our objects, and also consider that
publicy stating a private object exists is an issue itself.

I think that we can probably tolerate the external js without a
contract / DPA analysis IF and only IF it is not loaded where
personally identifying information and / or private data is accessible
on the page.

I'm not sure how deep that rabbit hole will go; I suggest consulting
with curtis or deryck about this.

(I realise my reply may look like I hadn't read the MP. I had :)).

You cover directly some private objects but not e.g. branch merge
proposals or their comments as being private (or even hidden). So
there is a risk that folk adding this won't cater for privacy in some
contexts, in the current implementation. I'd like to see *something*
done to reduce or mitigate that.

And there is no (apparent) consideration for personally identifying
data (which is a vague concept at best, but consider for instance that
a script running in our context can access an email address that a
script running from a different site cannot.

We also have the trust issue, which really isn't about the code, but
about whether we can trust the google plus API code with private data
(and this applies to non-private pages because a script can make API
calls and access anything you can access).

Hi,

I agree we need to get privacy (both data and people) right.

The benefit from all of this, hopefully, is
- more positive feedback for good work people do on Launchpad-hosted projects
- more visibility for Launchpad and projects in Launchpad on the web and on g+
- better search results about Launchpad

The biggest concern I have is not that Google will deploy malicious Javascript, but rather that people will accidentally click to share something that is meant to be private. So I want to hide the buttons on private pages -- and in fact I do, but it is not kept up to date after an ajax privacy change, but that can be done. We actually have belt-and-braces protection against that in that Google pings the page after you +1 it and it will refuse the plusone if the page is not accessible, which our private objects will be.

Showing the buttons in the page where we have control over them arguably makes it less likely people will accidentally click an external share button for a private object. It is more under our control.

My intention here is to provide, through the view.is_private check, a one-stop protection to make sure that these buttons are not rendered and the script is not loaded on views of private objects, without counting on people getting it right on each individual page. I think that means the current code will work ok even on bmps ... and I just tested, and in fact it does.

I ought to add tests that this is and stays correctly hooked up.

Personal data is hairy, arguably even including people's names, in which case every page of Launchpad is affected. What I'm trying to do here is to make it no worse than the current case combination of robots walking Launchpad public/anonymous pages, plus people sharing links through other means. The most relevant thing here is probably non-public email addresses. In a separate prior landing I add a meta description with the email addresses stripped out, so people shouldn't be accidentally sharing this. I'm also not putting this on any pages that are primarily about people, so the biggest risk is when personal information occurs within eg a public bug or mp description or comment.

To sum up the privacy requirements I am aiming for are:
 * do not share any private objects
 * do not encourage people to accidentally share things they shouldn't
 * the framework should be safe by default for new development
 * don't put email addresses into the shared content
 * don't run 3rd party javascript on pages containing private content (any more than we currently do)

There's some more discussion of this versus a builtin 'thanks' button in bug 798412.

I'm not sure about it.

It is smaller than a built in thanks mechanism would probably be.

On the other hand there is at least the perception of a privacy problem, perhaps an actual privacy problem, and perhaps ideally a builtin one would be better (though, we could always add this and switch later.)

Hi, sorry to need to reject this, but I've clarified some policy constraints IS have around externally hosted JS. I'll be working up proper policy docs etc soon, but the tl;dr is - we cannot run js that is hosted on a third party site in the LP webapp browser context.

One way to move this forward would be to investigate self hosted js that talks to the g+ servers - so a wire protocol rather than JS APIs.

> Hi, sorry to need to reject this, but I've clarified some policy constraints IS have around externally hosted JS. I'll be working up proper policy docs etc soon, but the tl;dr is - we cannot run js that is hosted on a third party site in the LP webapp browser context.

That's fine. It was interesting and educational to do this, but there
are enough tradeoffs here that I'm not sure I even want to land it. I
can see now how we could fairly easily hook a similar design in to the
notification system, once that exists. The metadata/microformat
changes make it easier for people to share pages using their own tools
if they want to.

There are some incidental cleanups in this branch that I will pick out
from the plusone bits.

I'm not being snarky by asking: does that policy mean that the
existing externally hosted scripts constitute bugs? Do we perhaps
want to at least squash them on private pages, using a similar check
to in this branch?

--
Martin

On Tue, Nov 29, 2011 at 11:39 AM, Martin Pool <email address hidden> wrote:
> I'm not being snarky by asking: does that policy mean that the
> existing externally hosted scripts constitute bugs?  Do we perhaps
> want to at least squash them on private pages, using a similar check
> to in this branch?

They will have to go from all pages, because of the access they get.
Yes, they will constitute bugs.

-Rob

On 29 November 2011 09:24, Robert Collins <email address hidden> wrote:
> One way to move this forward would be to investigate self hosted js that talks to the g+ servers - so a wire protocol rather than JS APIs.

I suspect that would be breaching their TOS, eg "You agree not to
access (or attempt to access) any of the Services by any means other
than through the interface that is provided by Google", and also that
it may be technically fragile.

It wouldn't deal with user concerns about tracking.

Perhaps we can just implement our own "thanks" concept more directly.

--
Martin

everything but the plusone bits is now in https://code.launchpad.net/~mbp/launchpad/888353-microformats-2/+merge/83856