As the newcomer to the, very entrenched, block, I think the memristor has a lot of momentum to overcome. In a EE undergrad (2007, so it has been a bit) we spent plenty of time understanding resistors, capacitors, and inductors. We looked at example circuits and uses, we learned the math and theory... We developed intuition around them.
Memristors were the missing fourth, and "imagine what you could do with that!" My imagination did not extend very far. Everything was being built with those other three and the non-linear components.
It'll take a while to overcome that momentum.
I feel like IPv6 has a similar barrier. I'm mostly an infosec nerd and I've been through a lot of training and education. Never once seen IPv6 treated beyond, "it has more bytes, firewall it off".
Came here to see if anyone'd mention Tiddlywiki. Had a coworker who swears by it, and I'm consider using it myself. The category of "personal wiki" software seems to overlap heavily with note-taking apps:
Programming a computer is a way of thinking. It in some ways involves the same thinking as determining how to break down a mechanical manufacturing process, or parts of team management (sport or industry), or legal arguments, or considering how biology works.
Basic logic is part of this, as is process decomposition, as is just learning a new way of communicating and many other things.
Learning new ways of thinking makes us flexible individuals. It fosters creativity. These are skills we all need in society, but the modern economy especially.
This is actually, I think, a compelling argument (aimed at adults who are deciding what children will do, less so the children themselves) for almost any subject.
The video game lure is good for some, but for others it's too complicated. But making flash-style animations using Scratch is also attractive (and easier). You can also make algorithmically-generated 3D models for 3D printing using programs like turtleSpaces. And there's also algorithmic music. So games aren't the only option.
Unfortunately just like putting "democratic" in your country name - if you have to put "freedom" in your name it's a good sign you are going for anything but.
But this only works if all views of the images employ your client... If I download an image (screenshot if necessary), modify it, and host it myself, how does the system work then?
And, unless all users trust only things viewed securely, and distrust things viewed nonsecurely (out of your client), then misinformation and fake photos can still propagate, right? (Or, how does the system handle this?)
In this scenario, it would almost certainly have to be that manufacturers would have to build cameras that cryptographically sign the images and videos. The cameras would have to be able to have that ability, install of the manufacturers doing the signing.
And then what would the Blockchain provide in this case? A chain of cryptographically signed certificates back to a manufacturer is basically the same system we use on the web today TLS certs. No Blockchain required.
And a major problem with that system is making sure the camera only signs genuine images. A nation state actor, or even a large political operation, is going to have an incentive to bypass the protections on that camera - perhaps just driving what the CCD is telling the rest of the camera - so they can produce signed fakes.
That's if they can't just get the private key off the camera, perhaps through a side channel attack - which can be pretty tough to pull off but is very tough to really defend against. Get a private key, game is over for the fraudster.
The way I thought that the blockchain would be employed is to use it to track transformations of the image. Post-processing, adding captions, and what not. This would provide an audit trail of changes to the original source image.
If, in fact, we can’t reliably sign the source image as authentic, then the rest of the system falls apart. It seems like this is the crux of the problem.
That seems to be a DRM problem. Let's say that you want the camera to track all modifications of the picture. Then, analogous to DRM, there's nothing stopping the forger from just replacing the CCD array on the camera with a wire connected to a computer running GIMP.
To patch the "digital hole", it would be necessary to make the camera tamperproof, or force GIMP to run under a trusted enclave that won't do transformations without a live internet connection, or create an untamperable watermark system to place the transform metadata in the picture itself.
These are all attempted solutions to the DRM problem. And since DRM doesn't work, nor would this, I don't think.
> And then what would the Blockchain provide in this case?
The main thing a blockchain provides is a cryptographically secured logbook of history. It doesn't guarantee you that the entries in the logbook are true, but it gets a lot harder to fake history when you can't go back to change your story. You have to fake it right when you claim it happened and hope that nobody else records anything in the logbook that conflicts with your story.
I can see how then a journalist source could use this to help prove their integrity. And I like that as a solution for that...
But - I don't really see that as the issue today. Those outlets that are interested in lying don't have to participate in this Blockchain chain of proof system. The malicious entities like political groups cited in the article definitely don't have to participate. It's still really on the viewer/spreader of the fake images/misinformation to verify the images, and to only rely on verifiable images. But I think a system like that would leave out most of the population who simply don't care.
Perhaps my worry about leaving out that chunk of population means this problem is unsolvable - and therefore my point is unfair. But I do think we need some solutions that are practical for widespread acceptance and use. If I can't imagine my parents (who are tech literate) would participate, and can't imagine some of my non-nerd friends wanting to participate, I don't think it solves the problems I'd like systems like this to solve.
I don’t think most people need to adopt this on their cameras for it to work. My perspective here is that journalistic sources that want to be trusted could employ this system. Along with signing the media and the blockchain, a system would need to be built to simply show the change log and history of a photo from the source. These journalism websites could just link out to it to demonstrate their veracity.
Once that’s adopted by the NYTs, WSJs, BBCs of the world, I’m hoping there would be critical mass to pressure more and more journalistic sources to adopt this standard. Eventually, any credible journalism would be on this technology and any outlet that doesn’t use this would be viewed with a grain of salt.
I agree though that a number of developments would have to happen to make this a reality. I would think that a partnership between NYT and Apple or Nikon could kickstart it though.
The problem with using certificates is any media signed by a party (by nature) traces directly back to that source/certificate. With a certificate-based approach I can imagine something like Shodan meets Google Image Search being used to make it easier to source media for the purposes of enhancing training for an ML model. Needless to say I have serious concerns about this approach.
This is why our approach only embeds a random unique identifier in the asset and requires a client to extract the media identifier to verify integrity, provenance, etc.
There are also two problems at play here - are we trying to verify this media as being as close to the source photons as possible, or are we trying to verify this is what the creator intended to be attributable to them and released for consumption? The reality is everyone from Kim Kardashian to the Associated Press performs some kind of post-sensor procession (anything from cropping, white balance, etc to HEAVY facetunning, who knows what).
Ok - I like this for some use cases. To restate my understanding so you can tell me I'm wrong if I am:
I think that it's still the user's job to make sure that they are skeptical of the provenance of any photos that claim to be from, say, the NY Times, that are not viewed in the NYT's viewer (if they were using your system). And then, they should still trust the image only as far as they trust the NYT. But if they're viewing the image the "right" way they can generally believe it's what the NYT intended to put out.
And perhaps, over time, user behavior would adapt to fit that method of media usage, and it would be commonplace.
I am skeptical that that "over time" will come to pass. And I think that users will not be apply appropriate skepticism or verification to images that fit their presuppositions. And I think malicious players (like some mentioned in the article) will attempt to build and propagate user behavior that goes around this system (sharing media on platforms that don't use the client, for instance).
And I guess making that broad set of problems harder or impossible is really what I'd like to solve. I can see how your startup makes good behavior possible, and I guess that's a good first step and good business case.
It's probably best for me to provide an example. We create three URLs for each media asset. For [1], [2], and [3] you can click our icon in the top right corner:
- A link to the asset itself (just the JPEG or whatever with embedded ID) [0]
- A link to a preview with twitter card, facebook open graph, etc support suitable for sharing (and re-sharing) on social media [1]
- A link to an iframe embed for use wherever else [2]
For an asset where the user has configured the metadata to be hidden our verification API doesn't return anything other than the checksum to validate against [3].
Users can update the returned metadata at any time or hiding of the extended metadata and it's updated dynamically and instantly - everywhere. So this way producers and consumers of content don't need to have a dedicated consumption implementation (but it could certainly be branded or white labeled to the content producer). Currently the client is just our javascript but we're working on mobile and browser extensions that can run anywhere against the raw asset link provided in [0].
"Once it works properly, you won't need to spend anything at all on marketing... people will flock to it in droves."
I agree.
However this really remains to be seen. If Waymo got everything working as right as they could it might still fail. This is a culture shift you're talking about, and even when past tech has required less to shift some has failed.
Memristors were the missing fourth, and "imagine what you could do with that!" My imagination did not extend very far. Everything was being built with those other three and the non-linear components.
It'll take a while to overcome that momentum.
I feel like IPv6 has a similar barrier. I'm mostly an infosec nerd and I've been through a lot of training and education. Never once seen IPv6 treated beyond, "it has more bytes, firewall it off".