When annotating local documents, remove paths from public annotations

[csillag]

See previous discussion starting here.

[dwhly]

Wondering if the path is perhaps good enough. It might be useful to still show filenames.

UPDATED the issue name.

[csillag]

Maybe we should retain the filenames, but don't expose them to anybody else, except the user who created the annotation? That would make it possible for him to access the document by clicking on the source link, but would hide it from others. (Who don't have access to the document either way.)

[csillag]

See also some other ideas in #1664.

[aron]

@csillag rather than linking to a previous discussion could you update the description to include a summary rather than force someone landing on this issue to read through a discussion for context.

[gergely-ujvari]

Q: Is it necessary to keep the path for local files, for private annotations?
What I mean here, that considering that the edit flow can change the privacy from public to private and vica versa, it'd require adding additional logic to remove to path when turning from private to public and reinsert it if we change the annotation from public to private.

Of course it is doable, I'm only asking if is it worth doing it?

[gergely-ujvari]

I've edited my last comment because I left out the key part from my question (That the question was referring to private annotations in local files)

[gergely-ujvari]

@dwhly: What do you think?

[dwhly]

Is it necessary to keep the path for local files, for private annotations?

Pros:

• For private annotations on Local PDFs, keeping the path means that people could potentially click on the link of an annotation in their stream and fetch the PDF associated with it from their hard drive.

Cons:

• Local file locations are probably fairly like to change with more regularity than things like URLs.
• There's little chance that clicking on the link, even if it found the file, would actually fetch the PDF into the browser, since most OS file-type defaults are probably set for desktop PDF reader apps (Adobe Reader, Preview, etc).
• As you suggest: What happens if they edit their annotation and change the visibility of it to public (or a future group mode), should the path be stripped? What then happens if they change the visibility back to private?
• But mostly: If we have an issue with storing paths we probably shouldn't be storing them at all. Don't send them to our service.

I'd vote for stripping paths (not filenames)-- keeps things simple.

[gergely-ujvari]

An another question here. Where should we store the remaining filename?

Currently, the document part looks like this:

    "document": {
        "link": [
            {"href": "file:///home/ujvari/Let%C3%B6lt%C3%A9sek/pdf-test.pdf" }, 
            {"href": "urn:x-pdf:c21f21ea44c1e2ed2581435fa5a2dcce" }
        ], 
        "title": "PDF Test Page"

First option: we can change the href with file URI scheme to only the filename {"href": "pdf-test.pdf" }, then our store plugin will try to load annotations for that filename. (Which is not good for trivial file names like: test.pdf or downloaded-(x).pdf)

Second option: we can change the annotator.document plugin to have a new field (maybe: 'filename') for collection the filenames for file URIs respectfully and storing it there. But does this seem useful for the Document plugin?

Third option: Just store the filename in annotation.filename (a new field of our own). But it is a bit out of place.

What do you think, which should be done?

[aron]

document.filename seems sensible to me.

[tilgovi]

The discussion concluded with the resolution to remove the paths. Why do we need the filenames? Shouldn't the title of the PDF be enough for the user to identify it? Why store the filename at all?

[gergely-ujvari]

About filename, @dwhly mentioned in one of his comments (I just can't find it right now) that storing the filename would be good to search for the pdf name in the local file systems.

Leaving the title does not grant this opportunity.
(I've no strong opinion here.)

[tilgovi]

As a case study, if I were a Mac user, the title would actually be sufficient. Spotlight will index the titles of PDFs, and I should be able to search for the title without ever knowing the filename.

I consider filenames an implementation detail of filesystems. It's really a tragedy that as users we are ever still required to even be aware of such a thing.

[csillag]

As a case study, if I were a Mac user, the title would actually be sufficient.

I have seen PDF files with empty or null titles. Not even Spotlight can fix that...

[dwhly]

Why do we need the filenames? Shouldn't the title of the PDF be enough for the user to identify it?

Here are a few of my reasons:

• The title, when present, would be helpful too. Having both is better.
• The filename is a visual string that I probably recognize. It's short and symbolic.
• The title may often be long. What's visible, until truncated with ellipses on our cards, may not be uniquely distinctive, or may be more difficult to quickly distinguish..
• I, like many if not most folks probably, encode the filenames of journal articles that I save in a way that specifically records the name, year and sometimes title of the document, like an abbreviated bibliographic reference (if it's not already saved this way, which it often is). e.g. "Watson_and_Crick_1953.pdf" That info is not likely to be what is returned by title metadata for the paper.
• Sometimes titles aren't there (including particularly with scanned PDFs for when we support image annotation). Filenames always are.