Issue Details (XML | Word | Printable)

Key: MBS-5708
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Normal Normal
Assignee: Robert Kaye
Reporter: Wieland Hoffmann
Votes: 0
Watchers: 4
Operations

If you were logged in you would be able to see more operations.
MusicBrainz Server

It's not possible to disable the display of cover art but the privacy policy claims it is

Created: 22/Dec/12 11:57 PM   Updated: 07/Jun/13 02:16 PM   Resolved: 07/Jun/13 02:15 PM
Component/s: None
Affects Version/s: None
Fix Version/s: None


 Description  « Hide

http://musicbrainz.org/doc/About/Privacy_Policy says "If you have created an account and logged-in, you may opt out of displaying cover art images if you wish" but no such option exists on http://musicbrainz.org/account/preferences .



Sort Order: Ascending order - Click to sort in descending order
Robert Kaye added a comment - 28/Dec/12 12:17 AM

For this one as well, how should we fix it?

1. Amend the privacy policy to remove the conflicting statement
2. Create such a preference.
3. Remove all support for cover-art from the site.

#3 would make our lives a lot easier in a lot of ways.


Ian McEwen added a comment - 28/Dec/12 01:34 AM

I vote #2. Pre-empting the inevitable uproar about how we can't possibly add more preferences because they're evil, #1 is also fine with me (but inferior, I think).

Though you're right about #3 making things easier


Karl C. Kupsch added a comment - 28/Dec/12 03:20 AM

#3 would be a DISASTER!

How many users identify the right artist, release, etc. just by a look at the cover-art? Removing the cover-art feature would do a great harm to MB's usability! MB isn't a database of Social Security numbers or something. Without cover-art feature, it would become a rather dry stuff. Folks would leave MB for Dicogs. Not to mention that today's kids can barely read and images are urgently needed! Moreover, what about cover-art feature in Picard?

No, there must be a way to keep the cover-art feature, either by technical means (adding such a preference), or by changing the privacy policy, maybe completely shifting the responsibility on the user regarding that special term, or a combination of all that, or something else... I just don't know, honestly. But don't remove the cover-art feature, plz!!!


Robert Kaye added a comment - 28/Dec/12 03:26 AM

Karl: We were not really serious about #3. Afterall, we've just spent months creating the CAA.


Frederik "Freso" S. Olesen added a comment - 28/Dec/12 03:26 AM

Karl, don't worry. Robert didn't actually present #3 as a serious suggestion.

That said, I also vote #2. This would also allow people to not load cover art if they're on a limited connection and don't feel like they need the covers to navigate or whatever.


Karl C. Kupsch added a comment - 28/Dec/12 04:24 AM

Thank God!


nikki added a comment - 28/Dec/12 05:30 AM

I would vote #1. Browsers have their own options for disabling images if you don't want to load images.


Karl C. Kupsch added a comment - 28/Dec/12 10:18 AM

@Nikki: Really?

How about Mobiles? Do all mobile browsers, or Apps using MB, have such an option? - I suppose: yes; however, I'm not sure. If not so: Regarding speed, for wired broadband it shouldn't play a role, nowadays, while for mobile or modem connections it does. Moreover, it's a matter of data volume. If you reached the limit, you'll probably have a problem.

Anyway, I thought it is a copyright issue, first, and finally. (That's why I took Robert's proposal for real, at the beginning.) Presumably, most of the cover-art will not be licensed under Common Creative, and you don't have any control regarding the origin of user uploads. However, as long we are talking about thumbnails, there shouldn't be a problem, not really.


nikki added a comment - 28/Dec/12 10:43 AM

All three browsers on my mobile have an option to disable image loading, as do all my desktop browsers. It's a pretty standard option, since requiring every single site the user wants to visit to have an option to disable images would be completely unrealistic.
I would expect apps using MB to implement their own data display and therefore be completely unaffected by the user's website settings.


Frederik "Freso" S. Olesen added a comment - 28/Dec/12 10:59 AM

There's a difference between browsing completely image-free and disabling cover art though. AFAICT, no images on the website itself are >= ~250x250px in size, plus, they're repeated elements. Cover art images aren't repeated across the site and are (hopefully!) ~250x250 or larger.


Oliver Charles added a comment - 28/Dec/12 12:06 PM - edited

The issue here is fundamentally one of privacy I would have thought. Loading images an an external domain leaks a bit of your privacy to the site you are requesting the image off.

I would also go with #1, but it needs to be discussed in the broader scope, the blog is probably the best place. Are users happy with what we're doing now? Would they be ok with an amended privacy policy? How do we tell them we've violated the privacy policy? That sort of thing is what would need to be communicated.


Ian McEwen added a comment - 04/Jan/13 09:02 PM

re: data volume, our site is already basically unusable on a mobile browser. That's a different discussion entirely. This ticket, as oliver mentions, is about privacy.

I think, upon further thought, that I would actually prefer a combination of #1 and #2, which also helps with MBS-5709: add a preference that says "do not include any third-party content" (with, probably, a list of what that includes), and update the privacy policy to say that we include third-party content at our discretion but that logged-in users can opt out of all of it.

There's a potential issue here with the CAA – coverartarchive.org isn't strictly third-party, but s3.us.archive.org probably is. Where do we categorize CAA images?

Oliver is, however, correct that we should probably figure out appropriate fora for discussing this generally – I'd say we should start threads on the forum and mb-users as well as make a blog post.

Finally: we should write a test for the server codebase that confirms whatever assertion we make about third-party domains and privacy, probably by ensuring we actually check HTML for all our pages and including a third-party-domain checker to our HTML tests, plus any needed testing for preferences and such.


Frederik "Freso" S. Olesen added a comment - 05/Jan/13 04:00 PM

FWIW and IMHO, we have no control what so ever about *.archive.org - thus I'd classify that as 3rd party. I think we have control of caa.org, so that'd be 1st party.

But let's continue the discussion elsewhere.


nikki added a comment - 23/Jan/13 07:10 PM

FWIW I don't think an option to block third-party content is useful.

It's not a realistic solution to privacy issues for users. MusicBrainz is not the only site on the internet and an option on our site is just a drop in the ocean. Anyone who is serious about blocking third-party content is going to need something at browser-level (an extension, most likely, e.g. https://www.requestpolicy.com/ ) to handle all the other sites they visit. If they have that, they don't need an option on musicbrainz.org.

We've also been very reluctant to add new options for things, even for things people want. Adding an option for something that nobody has actually said yet that they would use seems like a waste of our developer time.


Kuno Woudt added a comment - 25/Jan/13 02:47 PM

I think people who care about this are more concerned about companies like amazon knowing what musicbrainz page they visited than an outfit such as the internet archive.

If we amend the privacy policy to allow third-party content I think we should be explicit about which third parties get their images or other content embedded into our pages. We should probably also link to the privacy policy of those third parties.

#2 seems like the easy way out (user preferences usually are . Option #2 somewhat implies that we do not care about the user's privacy, but if they care they can disable some features and hopefully we won't leak anything.

We do need to care about our user's privacy, and be more mindful of which third party content we embed.


Alan Jenkins added a comment - 26/Jan/13 03:05 PM

What's the aim of the CAA?

Maybe it's purely to supplement Amazon etc. for images they lack. But I've seen art uploaded where there was already an ASIN.

If the CAA would like to be comprehensive, then maybe that's another reason to have the option, "only show art if it's in CAA". For people who are keen to have a comprehensive CAA, they could enable the option & tell at a glance, whether CDs they look at are well-covered or not. At the moment I think you have to click over to the Cover Art tab to find out.

Especially as I've seen images cited as being from Wikipedia? So when you notice an image missing from the CAA, you might be able to "fix" it even if it's a CD you don't own. (But strictly speaking I'm not sure about this - how do you know the image is the same release?)


nikki added a comment - 26/Jan/13 03:22 PM

The CAA does intend to be comprehensive and not just for filling in the gaps where we have no Amazon images.

I still don't think that justifies an option though - if people want to be able to tell where the cover in the sidebar is from, we should simply improve how we display covers in the sidebar, e.g. display "Image from Amazon" or "Image from hostname" (for cover art relationships) underneath the image if it's not a CAA image.


Robert Kaye added a comment - 12/Mar/13 08:15 PM

I am editing a revised policy here:

http://wiki.musicbrainz.org/User:RobertKaye/Revised_Privacy_Policy

The proposed solution for this ticket: Remove "If you have created an account and logged-in, you may opt out of displaying cover art images if you wish."


Robert Kaye added a comment - 28/Mar/13 07:15 PM

Robert Kaye added a comment - 07/Jun/13 02:16 PM

Closed and transcluded live on the site.