# Potential privacy issue with Canon cameras and copyright info setting



## Canon Rumors Guy (Nov 16, 2020)

> As just about everyone knows, you can enter your custom copyright info in your Canon ILC and it will appear in the EXIF data. If you use the delete copyright information in the camera menu, apparently the deleted information is still actually in the camera, minus one character.
> The problem:
> Now, you are also privacy-conscious and delete these before selling a camera to a used equipment dealer. You use the camera’s Delete copyright information menu item, thinking that it will remove everything. Unfortunately, this isn’t the case. Besides not touching owner and IPTC fields at all, it only replaces the very first character of the author name and copyright fields with a zero, leaving your previously set copyright information in the camera.
> Laszlo at DIRE Studio has found the “bug”. Full disclosure… this issue is being used to sell his ShutterCount app, but you can also correct this...



Continue reading...


----------



## Roy Hunte (Nov 16, 2020)

No prob .


----------



## AdamBotond (Nov 16, 2020)

I have a second-hand Canon EOS 1-DX with the same issue. I couldn't figure out how to remove the previous owner from the copyright information until now. I will give it a try.


----------



## magarity (Nov 16, 2020)

I guess the real question is, if I leave my name as copyright and the new owner doesn't change it, do I own all the new pictures? Somehow I doubt that will hold up.


----------



## Robert Marxreiter (Nov 16, 2020)

magarity said:


> I guess the real question is, if I leave my name as copyright and the new owner doesn't change it, do I own all the new pictures? Somehow I doubt that will hold up.



No, the data is not written into the pictures, it's just in the internal memory of the camera.


----------



## bbasiaga (Nov 16, 2020)

Robert Marxreiter said:


> No, the data is not written into the pictures, it's just in the internal memory of the camera.


It is included in the exif data of the picture. So new owner's images would show as belonging to you if you looked at the metadata. Probably would not hold up in court, but still. 

_Brian


----------



## Robert Marxreiter (Nov 16, 2020)

bbasiaga said:


> It is included in the exif data of the picture. So new owner's images would show as belonging to you if you looked at the metadata. Probably would not hold up in court, but still.
> 
> _Brian


That is false, I just checked it.
deleted copyright info is not written to the files.
Regards,
Robert

EDIT: Oops sorry, I misunderstood. You meant the case that you deliberately do not delete the copyright info and hope that the future owner does not notice/ care. That would of course be written to the files. Along with the camera and camera serial number which ha can proove belongs to him. So that would surely not hold up in court.
Regards,
Robert


----------



## definedphotography (Nov 16, 2020)

Its just like files on a PC. When you delete them it just sets a bit to say this disk can be overwritten, but the data is still there.

Best thing to do is delete your info, put in random characters and then reset the camera to "delete" it.


----------



## Robert Marxreiter (Nov 16, 2020)

definedphotography said:


> Its just like files on a PC. When you delete them it just sets a bit to say this disk can be overwritten, but the data is still there.
> 
> Best thing to do is delete your info, put in random characters and then reset the camera to "delete" it.



blank spaces are perfectly sufficient, there is no need to randomise.

Regards,
Robert


----------



## definedphotography (Nov 16, 2020)

blank spaces could also be considered random


----------



## Robert Marxreiter (Nov 16, 2020)

definedphotography said:


> blank spaces could also be considered random



You are right in that 255 successive blank spaces can not categorically be declared nonrandom but at the same time can not sanely be attributed to chance.


----------



## lexptr (Nov 16, 2020)

Haha! It looks like they somehow write literal zero instead of numeric. In programming (e.g. in C and C++) it is a common way to quickly "erase" text by placing numeric zero as the first character. Because zero marks the end of text. If you mistakenly use literal zero - it will just appear as you've replaced the first character by zero character. Nice. I will have some lulz tomorrow with co-workers


----------



## SteveC (Nov 16, 2020)

lexptr said:


> Haha! It looks like they somehow write literal zero instead of numeric. In programming (e.g. in C and C++) it is a common way to quickly "erase" text by placing numeric zero as the first character. Because zero marks the end of text. If you mistakenly use literal zero - it will just appear as you've replaced the first character by zero character. Nice. I will have some lulz tomorrow with co-workers



MS Dos/Windows used to put a tilde (~) at the front of the name listed in the directory, overwriting the first letter of the name, just like we're seeing here. So "My Dog.jpg" becomes "~y Dog.jpg". That entry doesn't just give the name, but also gives a location on the the disk where the actual file resides. They do something else to make that space available again--they typically do something to put that space at the "back of the queue" for reassignment, so that it won't actually be overwritten for a while, until the machine has nothing less recent to overwrite.

The file recovery software that came with the Microshaft operating system (and maybe still does) would check to ensure that none of the actual file got overwritten, then ask you to tell it what that first letter originally was before they replaced it with ~. Once you supply that letter, the directory entry became visible again, and the actual data (stored in some other part of the disk than where the directory entries were) would then be marked as in use again.

(I think modern (Post Windows 95) systems actually do something different. They move the file's directory listing to the "recycle bin" and there it sits until you empty the bin. Even then, perhaps, all it does is put the tilde in and it works like I'm describing. I just don't know.)

All bets are off, of course, if you "erase" a bunch of files and then defragment your hard drive. When you do that, data actually gets physically moved from one location to another rather than just de-listed, and anything marked as presently not in use is up for grabs. So the data that you "erased" will more than likely really get overwritten. Similarly, a low level format will trash the entire structure.

A lot of this is not true for SSDs, by the way. There's no motivation to "defragment" them because an SSD is truly random access. If you read sector 0 then read sector 1,000,000,000, it's just as fast as reading sector 0 then sector 1, unlike with a hard drive that has to re-position the read head in the first case but not the second.

An analogy (which will date me); imagine you record lots of music onto cassettes. But when you're tired of the mix on a cassette, you don't actually erase the cassette; rather you just take the label off and throw the cassette in a bin of "blank" cassettes you can record different music onto. If you actually put it at the bottom of the bin when you do that, you're operating like a Microshaft system's hard drive. It's possible for you to find that cassette and put the label back onto it if you change your mind, but wait long enough and you'll eventually get down to the bottom of the bin and re-use the cassette, and THEN it's gone for good.


----------



## Bdbtoys (Nov 16, 2020)

Robert Marxreiter said:


> You are right in that 255 successive blank spaces can not categorically be declared nonrandom but at the same time can not sanely be attributed to chance.



However, one could say that picking the 'space' character (although, repeating it) was chosen by random.


----------



## Robert Marxreiter (Nov 17, 2020)

Bdbtoys said:


> However, one could say that picking the 'space' character (although, repeating it) was chosen by random.


By choosing random characters, the choice would appear less arbitrary, I agree.


----------



## Robert Marxreiter (Nov 17, 2020)

SteveC said:


> Lenses:
> Full Frame: [...] the 100mm (non-L) f/2.8 macro (you can have it from my cold, dead hands).



So... I can have it?

Do you ship to Germany?


----------



## Fischer (Nov 17, 2020)

It can be many things. "Privacy", I think not...


----------



## Kiton (Nov 17, 2020)

I would think when you sell the camera you could just go in an change the copyright data to something like I JUST SOLD THIS CAMERA, that will over ride the old data and more than likely motivate the new owner to change it and add their own.


----------



## SteveC (Nov 17, 2020)

Robert Marxreiter said:


> So... I can have it?
> 
> Do you ship to Germany?



You'll have to talk to the executor of my estate about that one. 

[Hmmm....have I just given someone a reason to murder me?  ]


----------



## mdcmdcmdc (Nov 17, 2020)

Setting the first character to zero disables the string? What did they write the software with, Pascal??!!


----------



## YuengLinger (Nov 17, 2020)

Very useful info. Thanks!


----------



## zim (Nov 17, 2020)

mdcmdcmdc said:


> Setting the first character to zero disables the string? What did they write the software with, Pascal??!!


Oye don't diz the Pascal! Bloody millennials


----------



## peters (Nov 17, 2020)

I would see this as a feature. In case the camera gets stole this MAY improve your chances to prove ownership, if you are lucky.


----------



## mdcmdcmdc (Nov 17, 2020)

zim said:


> Oye don't diz the Pascal! Bloody millennials


Gen X thank you very much. And I learned Pascal in college on an original 128K Apple Macintosh!


----------



## Bishop80 (Nov 17, 2020)

mdcmdcmdc said:


> Setting the first character to zero disables the string? What did they write the software with, Pascal??!!
> 
> 
> zim said:
> ...



If it weren't for C, we'd all be programming in BASI and OBOL


----------



## zim (Nov 17, 2020)

mdcmdcmdc said:


> Gen X thank you very much. And I learned Pascal in college on an original 128K Apple Macintosh!


To kind, to kind , I use to teach Cobal, in fairness I was the same age as some of the students


----------



## privatebydesign (Nov 18, 2020)

I sold a 1DX II that had all my copyright and contact info in it to another pro photographer. He didn’t normally enter his info in the camera just in post. One of his clients is a University sports team and in their contract they have to deliver the RAW files and the University has copyright of any images shot of their team members or on their property. He got in a ton of shit because he delivered RAW files with copyright info that was incorrect.

I know it isn’t directly related to the thread but close enough to mention it.


----------



## SteveC (Nov 18, 2020)

mdcmdcmdc said:


> Gen X thank you very much. And I learned Pascal in college on an original 128K Apple Macintosh!



OK, but pascal doesn't null terminate its strings...at least not the original pascal. the strings are indexed [1] to [255] and location [0] is actually the length of the string, so no termination needed. Maybe later versions of Pascal do something different, but this was Pascal as of 1983.

C and C++ do null terminate their strings, writing an ascii zero in the first position would give you an empty string.


----------



## mdcmdcmdc (Nov 18, 2020)

SteveC said:


> OK, but pascal doesn't null terminate its strings...at least not the original pascal. the strings are indexed [1] to [255] and location [0] is actually the length of the string, so no termination needed. Maybe later versions of Pascal do something different, but this was Pascal as of 1983.
> 
> C and C++ do null terminate their strings, writing an ascii zero in the first position would give you an empty string.



Yes that was the joke. When they set the first byte, the length byte, to zero, the string has zero length so it is ignored.


----------



## Antono Refa (Nov 18, 2020)

I don't see the privacy issue here. If the camera is sold 2nd hand or stolen, and someone finds out the [previous] owner's name. So? People aren't secretive about their camera model.


----------



## SteveC (Nov 18, 2020)

mdcmdcmdc said:


> Yes that was the joke. When they set the first byte, the length byte, to zero, the string has zero length so it is ignored.



Oh THAT first byte. OK, gotcha!!!  (I was thinking of the first byte of the string proper, i.e., string[1].)

(Amusing, though how it ends up working the same way for Pascal and C for two totally different reasons!)


----------



## mdcmdcmdc (Nov 18, 2020)

SteveC said:


> Oh THAT first byte. OK, gotcha!!!  (I was thinking of the first byte of the string proper, i.e., string[1].)
> 
> (Amusing, though how it ends up working the same way for Pascal and C for two totally different reasons!)



That is pretty funny. My mind immediately went to the Pascal length byte, but you’re right, putting the C null terminator there would have the same effect.

They probably actually wrote it in C++. To delete the strings, they called std::string::clear(), and their compiler implemented it that way. 

Cheers!


----------



## SteveC (Nov 18, 2020)

mdcmdcmdc said:


> That is pretty funny. My mind immediately went to the Pascal length byte, but you’re right, putting the C null terminator there would have the same effect.
> 
> They probably actually wrote it in C++. To delete the strings, they called std::string::clear(), and their compiler implemented it that way.
> 
> Cheers!



Hmm...std::string supposedly works differently from the old school char * string, and as far as I know isn't null terminated. But on second thought, I should try some experiments, because I know that std::string's .c_str( ) function call does return a null-terminated string, so maybe, in fact, it does use a null terminator and all the class buys you is automagic resizing and concatenation operators. (If I can set some std::string's first character to zero and still have it return a length greater than zero when I call length( ), it's doing something different, regardless of whether c_str() returns an "empty" char * string [which I would expect it to do].) Such experiments should look at the actual address returned by c_str( ) as well as its referent....


----------



## Robert Marxreiter (Nov 19, 2020)

Antono Refa said:


> I don't see the privacy issue here. If the camera is sold 2nd hand or stolen, and someone finds out the [previous] owner's name. So? People aren't secretive about their camera model.


Well that might be true for Canon cameras, but imagine someone found out you once had an affair with a Nikon camera, that could thoroughly taint your reputation.


----------



## mdcmdcmdc (Nov 20, 2020)

Robert Marxreiter said:


> Well that might be true for Canon cameras, but imagine someone found out you once had an affair with a Nikon camera, that could thoroughly taint your reputation.


When I was in between my last film SLR (EOS 100) and my first DSLR (EOS 20D), I had a brief fling with an Olympus C-5050. She was a hot little number with some great specs in those days (wink, wink)! And hoo-wee what a lens! But it didn't last long. She didn't have the fastest autofocus in the camera bag, if you know what I mean.


----------



## deleteme (Nov 20, 2020)

Robert Marxreiter said:


> You are right in that 255 successive blank spaces can not categorically be declared nonrandom but at the same time can not sanely be attributed to chance.


Of course those who buy lottery tickets will fight you.


----------



## Robert Marxreiter (Nov 23, 2020)

Normalnorm said:


> Of course those who buy lottery tickets will fight you.


Find me one who'll pick "1-1-1-1-1-1+1" and you have a point


----------

