No, metadata is not data. It's metadata.
Also, whatever the unusual definition of data you use that results in metadata being excluded is irrelevant (and it is unusual, look up the definition of data in any dictionary). The important part is that 1Password was not making it clear that it does not encrypt certain parts of the "information" you put into it.
And I'm not using an unusual definition of data, that begs the question. My point is just because it's about you, doesn't mean you own it.
Is there, actually, in this context? What is the reason you're drawing this distinction? What makes generated passwords 'data', but password reset urls and hand-typed entry names 'metadata'?
Why shouldn't my password reset urls be private? They are... in the password database I use.
Why shouldn't my database entry names be private? They are... in the password database I use.
Are you saying that these things are metadata in 1Password by virtue of the fact that they weren't secured? Because that would seem like circular reasoning - that you can never leak data, because leaked data is metadata. I don't share your definition of metadata in such a case.
Are you saying that these things are metadata in 1Password because they shouldn't be private? I just plain strongly disagree if so.
Are you saying that these things are metadata because users shouldn't expect a password database to secure them properly? Then I could at least see where you're coming from. But I don't think it makes sense to tie the definition of metadata to that - among other complaints, I think it lets off companies/software that leak your (meta)data off far too easily, and that such word games absolve them of too much responsibility.
I've been intentionally vague so as to discuss this in more macro terms rather than the specific case as presented here, because I feel there's a panicked "deer in the headlights" attitude that comes with talking about data and metadata, and I'd like to try and help folks think a little more rationally around the topic rather than simply "EVERYTHING RELATED TO ME IS MINE AND NEEDS TO BE ENCRYPTED AND HIDDEN".
I regularly forget about how closed-minded the HN userbase is when it comes to privacy.
You may want to lead with that next time - I'm not the only one attempting to interpret your vagueness in-context (that is, in the specific case as presented here) which apparently isn't your intent. Hopefully it'll generate productive discussion instead of a confused chorus attempting to clarify terminology.
> I feel there's a panicked "deer in the headlights" attitude that comes with talking about data and metadata
Are you seeing that in this thread? Or is this more of a generalized feeling of HN? Or of the internet?
I feel like I'm mostly seeing discussions about what specific data was involved, what alternatives are out there, and the severity and history of the problem (which I'm seeing as mostly "not as severe as your initial kneejerk to the title might imply, but not ideal either" - pretty levelheaded and accurate, IMO?)
None of them seemed particularly frozen, unable to move forwards, or panicking beyond the time it took them to evaluate what specific (meta)data was leaking - to me, at least. And given that password databases secure the keys to the castle, so to speak, I'm not sure a little panicking isn't warranted in this specific context.
> I regularly forget about how closed-minded the HN userbase is when it comes to privacy.
If that's in response to this thread, keep in mind that, in-context, the "privacy" many professionals in here are concerned about, is the "privacy" of their amazon account keys, to avoid their servers being subverted into part of a malware distribution botnet. And the "privacy" of their user database - to avoid the reputation hit that comes when all your customer's passwords are cracked, and their inboxes are flooded with porn spam. I think it'd be a mistake to overgeneralize that response.
In the future, remember this when you decide to dissect someone's writing.
Quoting entire paragraphs may not be sufficient to provide proper context, and especially if being willfully misinterpreted, can be potentially harmful.
But well intentioned quotes, immediately under a post providing them in their full context - which is the case in my post you replied to? I'm hard pressed to see that as distorting your meaning and harming discourse. If you have specific grievances as to how I have, please state them. If my understanding is distorted, there is harm to discourse regardless of whether or not it's visible in the form of distorted quotes.
The many questions I'm asking are my attempts at understanding the context of your statements, to avoid such distortions. The couple that you've answered have clarified some things. A couple more have been mooted by indirect responses. Many others are still relevant and unanswered.
Even now, I'm a bit unsure if you're saying that I've done harm, in the specific post I made that you were responding to - or if you're making vague generalizations again, this time about sentence level quoting on the internet in general. I'm assuming the former for now - but please correct me if I'm wrong. I would ask, but that's clearly not working out for me.
Public metadata isn't mine. Private metadata is. And in fact, around here it's illegal to record my metadata, even if publicly viewable - anti-piracy groups have been fined for producing databases of IP addresses+shared files taken from the Bittorrent network.
That's lots of metadata, but probably doesn't help you in the slightest in guessing my password. Agree with you that its problematic that 1password was leaking things like site names and URLs though.
I personally typed or copy-pasted all the entries in my keepass vault, it's primary information associated with the passwords, highly personal, and that it's not the definition of metadata. The fact that a tool automates the gathering of some data (URLs) for the user doesn't automatically make it metadata.
Metadata would the character encoding, version, encryption, ids required to read the file, as well as added/modified dates (potentially sensitive metadata).