A long and thought-provoking read. Here are a few I had while reading:
I love the paradigm of virtually "flipping" a photograph to read its extensive metadata on ImageSnippets because it reminds me so much of our old family photo albums. Those low-resolution black-and-white, two-photos-a-year-per-family-member rarities had handwritten metadata on the back. Sometimes, it'd be date and time, sometimes geolocation, sometimes PII, and sometimes highly personal blobs.
---
As far as malicious pics "metanalysis" at scale is concerned, one of the mechanisms of protection I was thinking about is the equivalent of spam protection, which is also the basis for blockchain. In this case, a bit of computational power is required to get access to metadata. This computational expense will be unnoticeable for normal use but will be prohibitive at scale.
---
Coming from an engineering background and dealing with data (and metadata) daily, I can't help but notice a similarity with data protection in the corporate world. Almost every piece of data can be access-controlled through IAM (Identity and Access Management). The data is always there and is never lost, but accessing it is not a free-for-all.
Therefore, dissociating metadata from the data and handling access to both separately could be a way to eat the cake and have it, too.
I can't stalk you as an individual Instagram user, but ImageSnippets can be granted API access to metadata if your intentions are good and you've been vetted by ISO and co.
Malik, thank you so much for the comments. I completely agree about the 'writing on the back of the photos' and it should be the topic of a post! I have a long, on-going archival project working with several generations of photography from a family OF professional journalists. Any of those little tidbits of data written on the slides or the negative sleeves are priceless. It just makes me sad for the future digital archivists and anthropologists.
Actually, your ideas about access control to metadata are excellent and we should explore those further. Right now, with current ImageSnippets techniques, we write the metadata in several places - in the html file and also in a triple store.
The triple store is the place where the data could be stored and accessed through a bit in the image that is protected, but of course this part of the idea is similar to current techniques being tried by several groups (the C2PA and an existing Blockchain solutions).
But their solutions are predominantly tied to authenticity and provenance - which I don't dispute as being necessary; but they don't necessarily solve the problem of reuse of metadata across many platforms and also, setting up a third location for data storage is good (we do it) but we do it in conjunction with having the data in the file itself (and a self-referential link back to the html file) as well as the triple-store.
What always worries me about having only 1 method of trust to refer back to can become corrupted in many ways (not necessarily technically corrupted) but politically, etc. It basically puts the data back into the hands of a central controller.
I've always preferred the notion that data can travel freely with an image where the triple-store data can be used more for the management of the resource. In this way, the principles of FAIR can be maintained alongside copyright assertions.
It doesn't solve ALL problems with authenticity and provenance, but it also doesn't try to do that. It also doesn't solve ALL problems with location/stalking/doxxing --- but it could be great to have a hidden link to location such that it is preserved but not available in the shared images, this is where something like Solid Pods/Data Access could help with access control over discrete metadata elements.
A long and thought-provoking read. Here are a few I had while reading:
I love the paradigm of virtually "flipping" a photograph to read its extensive metadata on ImageSnippets because it reminds me so much of our old family photo albums. Those low-resolution black-and-white, two-photos-a-year-per-family-member rarities had handwritten metadata on the back. Sometimes, it'd be date and time, sometimes geolocation, sometimes PII, and sometimes highly personal blobs.
---
As far as malicious pics "metanalysis" at scale is concerned, one of the mechanisms of protection I was thinking about is the equivalent of spam protection, which is also the basis for blockchain. In this case, a bit of computational power is required to get access to metadata. This computational expense will be unnoticeable for normal use but will be prohibitive at scale.
---
Coming from an engineering background and dealing with data (and metadata) daily, I can't help but notice a similarity with data protection in the corporate world. Almost every piece of data can be access-controlled through IAM (Identity and Access Management). The data is always there and is never lost, but accessing it is not a free-for-all.
Therefore, dissociating metadata from the data and handling access to both separately could be a way to eat the cake and have it, too.
I can't stalk you as an individual Instagram user, but ImageSnippets can be granted API access to metadata if your intentions are good and you've been vetted by ISO and co.
Am I too naïve?
Malik, thank you so much for the comments. I completely agree about the 'writing on the back of the photos' and it should be the topic of a post! I have a long, on-going archival project working with several generations of photography from a family OF professional journalists. Any of those little tidbits of data written on the slides or the negative sleeves are priceless. It just makes me sad for the future digital archivists and anthropologists.
Actually, your ideas about access control to metadata are excellent and we should explore those further. Right now, with current ImageSnippets techniques, we write the metadata in several places - in the html file and also in a triple store.
The triple store is the place where the data could be stored and accessed through a bit in the image that is protected, but of course this part of the idea is similar to current techniques being tried by several groups (the C2PA and an existing Blockchain solutions).
But their solutions are predominantly tied to authenticity and provenance - which I don't dispute as being necessary; but they don't necessarily solve the problem of reuse of metadata across many platforms and also, setting up a third location for data storage is good (we do it) but we do it in conjunction with having the data in the file itself (and a self-referential link back to the html file) as well as the triple-store.
What always worries me about having only 1 method of trust to refer back to can become corrupted in many ways (not necessarily technically corrupted) but politically, etc. It basically puts the data back into the hands of a central controller.
I've always preferred the notion that data can travel freely with an image where the triple-store data can be used more for the management of the resource. In this way, the principles of FAIR can be maintained alongside copyright assertions.
It doesn't solve ALL problems with authenticity and provenance, but it also doesn't try to do that. It also doesn't solve ALL problems with location/stalking/doxxing --- but it could be great to have a hidden link to location such that it is preserved but not available in the shared images, this is where something like Solid Pods/Data Access could help with access control over discrete metadata elements.