1465557 - AS Router Remote Previewing without a pref

Status: RESOLVED FIXED

(Firefox :: New Tab Page, defect, P2)

Description

[Andrei Oprea [:andreio]]

Want to open the conversation and see if it would be possible to allow setting preview endpoints for snippets without having to toggle a preference.
It would make it easier for people writting snippets who are not technical and it would ease the process of sharing preview links easier.

Comment 1

[Andrei Oprea [:andreio]]

Some more information:
* User would open a tab, paste in "about:newtab#asrouter?endpoint=URL"
* Activity Stream would read the URL, check that it's https & whitelisted and then fetch the JSON payload from that endpoint in order to display the content in the snippets

Giorgos, is there anything you would like to add?

Comment 2

[Giorgos Logiotatidis [:giorgos]]

The main argument here is that content creators share snippets that they build with other teams. For example the Pocket team could have asked for a Snippet campaign for Q3. The content creators would build the snippets and share links with the Pocket team to preview before launching.

The people who receive the share link don't usually interact with the Snippets platform, therefore we won't to be it easy for them to just preview and forget.

On the security / anti-phishing front we will implement:

 1. Domain whitelisting, i.e. users will be able to load previews only from the official snippets admin domain
 2. URLs will contain long UUIDs, to make them hard to guess, e.g. 
    /preview/uuid/304a3d60-d424-4193-a7b4-4460469d931d/
 3. Clear banner on the AS page that this is a preview.

Comment 3

[Stephanie Ouillon [:arroway] (needinfo me)]

I did a first round at threat modeling the feature: https://docs.google.com/document/d/1z9faeuPEjs2vifnWSBQYOP5RqmARw6fCO5JSCD8MaEw/edit#

Having to flip a pref would mitigate two identified risks as I understand the current architecture: 

Risk 1: A malicious snippet is created and a way to access it is shared to wide audience (link, email).
Impact: Leading users to visit malicious websites.

Risk 2: Attacker sends URLs with second-guessed UUIDs to wide audience.
Impact: Leaking information about upcoming snippets (reviewed or not)

Comment 4

[Stephanie Ouillon [:arroway] (needinfo me)]

Adding some thoughts on that: it looks to me this feature will be used by a very limited number of people, compared to the potential impact it could have on all our users if it gets exploited in some way. That's why limiting the access to this about:newtab preview page makes sense to me.

I am also trying to really understand the usecase here. It seems to me there are two groups of people who would use this preview feature: the creators and people who would like to preview it in advance. 
I'm assuming that creators might be involved enough in the process of creating snippets so that it makes sense to them to flip a pref. 
But do every people who would like to preview one snippet from time to time (which I believe is the reason why it would be somehow a "burden" to flip a pref) need to preview it in their web browser? That might be a naive question, but wouldn't screenshots solve the use case here?

Comment 5

[Giorgos Logiotatidis [:giorgos]]

Thank you for writing this document Stephanie. Inline answers to your concerns follow:

(In reply to Stephanie Ouillon [:arroway] from comment #3)
> Risk 1: A malicious snippet is created and a way to access it is shared to
> wide audience (link, email).
> Impact: Leading users to visit malicious websites.

If one manages to gain access to our snippets service so they can create snippets they will be able to actually push real snippets out to all users and they won't limit themselves to sharing preview only links. The pref will not protect users in this case.

 
> Risk 2: Attacker sends URLs with second-guessed UUIDs to wide audience.
> Impact: Leaking information about upcoming snippets (reviewed or not)

This is rather unlikely given that we're generating 128bit UUIDs (using python's uuid4) and the risk here would be exposing marketing material earlier to users who now the link. 


(In reply to Stephanie Ouillon [:arroway] from comment #4)
> But do every people who would like to preview one snippet from time to time
> (which I believe is the reason why it would be somehow a "burden" to flip a
> pref) need to preview it in their web browser? That might be a naive
> question, but wouldn't screenshots solve the use case here?

We recently added this previewing functionality using UUID to the current system exactly b/c screenshots where a burden and wouldn't work. That said, we had no other way to preview, so having to flip a pref is still an improvement but still a step backwards to what we have now.

Comment 6

[Stephanie Ouillon [:arroway] (needinfo me)]

Thanks for the clarification Giorgos, I agree the main risk here is ultimately on the Snippets server, which is outside of the scope of this feature.

As I understand it from your comment, the code has already been implemented. If you can point me to the changeset regarding the remote previewing code, I'll take a look at it, but don't consider it a blocking point for moving forward with this.

Comment 7

[Andrei Oprea [:andreio]]

Code is here https://github.com/mozilla/activity-stream/pull/4173/files

Comment 8

[Giorgos Logiotatidis [:giorgos]]

(In reply to Stephanie Ouillon [:arroway] from comment #6)
> Thanks for the clarification Giorgos, I agree the main risk here is
> ultimately on the Snippets server, which is outside of the scope of this
> feature.
> 
> As I understand it from your comment, the code has already been implemented.
> If you can point me to the changeset regarding the remote previewing code,
> I'll take a look at it, but don't consider it a blocking point for moving
> forward with this.

Thanks for your reply Stephanie. The code development is two fold: on the addon site for which :andreio posted a PR in comment #7 and on the server side for which we don't have code yet as we wait for the addon site to settle. The server side work is tracked in https://github.com/mozmeao/snippets-service/issues/522

Comment 9

[Andrei Oprea [:andreio]]

Fixed by bug 1463836

Comment 10

[Ed Lee :Mardak]

https://hg.mozilla.org/mozilla-central/rev/0ef1451e9411