added DMCA notice to shot page

[dannycoates]

This adds a dmca field to the data table and shows a notice on the shot page when that field is not null. It could also be used for a link to specific info but is currently only used as a flag for a general message.

[ianb]

Something that we're planning on for new updates (that we haven't done before) is to make the code tolerant of different database versions. So for our purposes, 6.3.0 is the current production and runs with database version 15. We should ensure that 6.3.0 can run with database version 16, and that master can run with database version 15. Or, if we can't do that, then we are supposed to release (to production) another version which can do that. We haven't done this yet, so I don't actually know quite what the migrations should look like!

[ianb]

After discussion, we're not going to worry about the migration/database compatibility stuff for now.

[ianb]

I'm pretty sure this is leaky, it'll send all the data but just hide it on render. Expiration jumps through some lame hoops to avoid this, but it's really just a bad approach.

I think it would be better to do something in shot/model.js to split things between these cases (expired, blocked, and normal). It's not easy to instantiate a different component based on this, but the main component should just dispatch immediately to a more view-specific component (each of which will take different properties).

Also DMCA is just one reason for blocking something. I think we should have a blocked boolean, a separate TEXT explanation field, and maybe a loose enum for the explanation. The explanation below would be "dmca", there might be another for "abuse" or something. That would let us do some reporting later too, to look for individual users based on category of being blocked.

So in sum I would say we should have a scheme change like:

ALTER TABLE data ADD COLUMN blocked BOOLEAN DEFAULT FALSE;
ALTER TABLE data ADD COLUMN blocked_code TEXT;
ALTER TABLE data ADD COLUMN blocked_reason TEXT;

And then a block would be like:

UPDATE data SET blocked = TRUE, blocked_code = 'dmca', blocked_reason = 'For more information see https://somelocation.com/dmca-notice-1023.pdf'

[dannycoates]

I'm pretty sure this is leaky, it'll send all the data but just hide it on render

It never actually fetches the image. The prerendered html has the block inlined. The json contains all the data, including the image url, but never fetches it. I updated the image url to 404 on blocked images (technically not "not found" but whatevs). So whatever is "leaked" isn't useful. It might be nice to refactor things in the future, but this keeps the changes pretty minimal for now.

I went with a single block_type column and an enum to represent unblocked (none) and DMCA. We can add more with ALTER TYPE shot_block_type ADD VALUE 'abuse' for example. I didn't add a blocked_reason column yet because I'm not clear on its use. Is there already a place where dmca notices are hosted? If not I'd rather wait to add that column.

[dannycoates]

@ckprice screenshots

Owner sees:

Others see:

[ckprice]

@dannycoates thanks! Just passed this around to legal.

[ckprice]

There are two asks from legal

1. Update the "creator" view copy to (note the change in the 2nd sentence).

This shot is no longer available due to an intellectual property claim.
Please email dmcanotice@mozilla.com to request further information. If your Shots are subject to multiple claims, we may revoke your access to Firefox Screenshots.
Please include the URL of this shot in your email: {link}

2. Update the "non-creator view" to be the generic not available page.

Thanks!

[dannycoates]

@ckprice updated. I'm not exactly sure what "generic not available page" means so I used the 404 page as is shown for any unknown shot url. cool?

creator:

non-creator:

[clouserw]

@dannycoates that's fine, thanks (cory is pto today)

[ianb]

I guess I would have used NULL as not-blocked, but I suppose this is fine too.