December 2

TrueCrypt#Identifying_TrueCrypt_volumes TrueCrypt volumes can't be identified, but some of those claim are not cited.--58.251.146.130 (talk) 06:45, 2 December 2013 (UTC)[reply]

There's no way to distinguish the contents of a TrueCrypt container file from random bits unless you have a decryption key. The best source I can find for this is a footnote in the official documentation ("These parameters are kept secret [...] primarily to make TrueCrypt volumes unidentifiable (indistinguishable from random data) [...]", on page 135 of TrueCrypt User Guide.pdf). They're likely to be "identifiable" in other ways, though. -- BenRG (talk) 08:28, 2 December 2013 (UTC)[reply]

In jurisdictions with a key disclosure law, where the authorities can force someone to provide them access to encrypted data, the presence of a large file containing highly random data is likely to be taken as prima facie evidence that it is an encrypted container of some sort (particularly if the person in question has TrueCrypt installed). A large random file is evidently not a program, media file, or user document, all of which are non-random and readily identifiable. An unfortunate corollary of this is that if one really did have a large file of random data, one might be faced with the vexing task of proving the negative, as there's no way to show that random data isn't a TruecCrypt volume. -- Finlay McWalterჷTalk 11:45, 2 December 2013 (UTC)[reply]

In fact a properly set-up TrueCrypt volume can be completely undetectable and plausibly deniable. In short, by encrypting volumes within volumes you can make data appear to represent blank space on one encrypted volume when in fact it is part of another encrypted volume that, without the proper password, cannot be detected or proved to exist. —Noiratsi (talk) 20:30, 2 December 2013 (UTC)[reply]

What will they do if I just can't or don't decrypt the information? Will they assume me as guilty, or hyptonize me or put me on a Polygraph?--58.251.146.130 (talk) 01:36, 3 December 2013 (UTC)[reply]

That largely depends on your country, see

Rubber-hose cryptanalysis for a discussion of key extraction methods. —Noiratsi (talk) 08:20, 4 December 2013 (UTC)[reply

]

Kitutal (talk) 15:27, 2 December 2013 (UTC)[reply]

Which FTP program do you use? /project is often treated as a folder called project. My FTP program can display folders at the target site and has an option to create a new folder when right clicking in an existing folder. PrimeHunter (talk) 15:43, 2 December 2013 (UTC)[reply]

Currently using FileZilla, is that ok? Kitutal (talk) 16:16, 2 December 2013 (UTC)[reply]

I also use FileZilla. Don't you have the described right-click option when you view files on the target server? I don't know whether it can depend on the server. PrimeHunter (talk) 16:31, 2 December 2013 (UTC)[reply]

I'll have another look, see if I can make it work. The other thing is whether it would be possible to download a sample wordpress template for me to use, or would I have to write that all myself? Kitutal (talk) 17:39, 2 December 2013 (UTC)[reply]

I don't know the answer - but I have to say that if you're doing any kind of serious web development work, FTP is a horrible way to go. You should try to find out whether you can have a "shell account" on the machine that hosts the site so that you can easily log into it to maintain it. Failing that, consider using something like rsync or (my personal favorite) Unison that let you set up the files on your local computer and "sync" them with the files on the server so that whatever arrangement you set up on your local machine gets transferred to the server whenever you decide to do so. This is also good because it allows you to more easily maintain a proper backup of the file system on the server for easy restoration in case of problems. If your service provider doesn't allow you to do such things - then I strongly recommend switching to one who does. SteveBaker (talk) 17:40, 2 December 2013 (UTC)[reply]

Think FileZilla is a good way to go. The only disadvantage I found, was that there was very little documentation, that could find, at the time, to tell me how to make it sing and dance (but it worked). I did some of the things that your asking about (and I'm no expert) but now can't remember clearly enough to help. Hopefully some editors here can provides links to the sources that can help you. So stick with it. Thanks, for reminding me about FileZilla. Now that winter's coming on and the nights are drawing in, I think I'll rent another virtual server and have some fun. I've been thinking of creating a family 'virtual private network', where we can just let each other know what were up to (– save for perhaps the teenagers that what to keep that sort of thing under the bedcovers). The emails on it, will also automatically have higher priority, because it is family business and so can't be over looked or get spam filtered... --Aspro (talk) 22:24, 2 December 2013 (UTC)[reply]

When one converts JPG to PNG, does any damage/generation loss/etc result from the process of MIME format conversion? Someone uploaded File:Pbalson 20060527 IMG 3701.JPG to Commons as File:Pbalson 20060527 IMG 3701.png (see the "author" line; the Commons image is definitely taken from here, not vice versa), and I'm wondering if we might want to upload the original JPG to Commons. Nyttend (talk) 23:12, 2 December 2013 (UTC)[reply]

The JPG is 628 KB and the PNG is 3.46 MB. That seems reason to prefer the JPG whether or not the PNG lost something. commons:Special:Contributions/Spriggy.mcgee shows this and the similar conversion of File:Pbalson 20060527 IMG 3702.JPG to commons:File:Pbalson 20060527 IMG 3702.png were the only edits of the user who created the account 7 minutes earlier. I have no idea why the user converted the images but it probably wasn't for a good reason. I say transwiki the JPG's but with meaningful names, and consider nominating the PNG's for deletion. PrimeHunter (talk) 23:33, 2 December 2013 (UTC)[reply]

No information is lost in converting from JPG to PNG, except possibly

EXIF metadata that is not part of the visible image. So file size is really the only issue. Looie496 (talk) 23:49, 2 December 2013 (UTC)[reply

]

commons:Help:JPEG#JPEG versus other formats says: However, if the original file is in JPEG, it makes no sense to convert it to PNG: converting a lossy compression into a "lossless" format doesn't buy you anything since the "loss" already occurred in the original, and doing so will only increase the file size. PrimeHunter (talk) 00:22, 3 December 2013 (UTC)[reply]

PNG is a lossless file format. When you create a PNG from a JPG, every single pixel that you saw in the JPG file will be there in the PNG, perfect in every regard. However, the reverse is most definitely NOT the case. When a PNG (or any other file format for that matter) is converted into JPG, the "lossy" compression scheme that's behind the JPG file format throws away information that is deemed relatively unimportant to human perception. That's how it manages to compress the file to take up less space/bandwidth. JPG compression is usually fairly good - but it does rely on some assumptions about the viewer that may not be true. For example, it assumes that the image will be presented at a screen resolution of around 50 to 100 pixels per inch, at a reasonable brightness, and is viewed square-on to the eye in the center of the person's field of view. When those viewing conditions are violated, (or if you set the compression level too high) then you'll see artifacts due to the fact that JPG threw away some information that actually matters. This often takes the form of ghostly outlines around objects with sharp color transitions, and in the form of weird colored pixels showing up when you zoom into the image.

So if you're seeing artifacts in a PNG image that was *ever* at some time in the past a JPG image - then the odds are good that the artifacts were introduced in the original conversion in to JPG, not in the subsequent conversion into PNG.

Sadly, you can't "repair" an image that's been stored as a JPG because (fundamentally) some information was thrown away and cannot ever be recovered without going back to a version of the image that has never been converted to JPG.

SteveBaker (talk) 00:43, 3 December 2013 (UTC)[reply]

Thanks to everyone for the advice. I've uploaded the JPGs to Commons, deleted the local images under criterion F8 (identical image on Commons), and filed deletion requests for the PNGs. Nyttend (talk) 03:06, 3 December 2013 (UTC)[reply]

I agree - that's the right thing to do. The person who uploaded those files probably heard that PNG is a higher quality file format than JPG - which is undoubtedly true. However, if all you have is a JPG, converting it to PNG is just a waste of disk space because the damage has already been done and all you're doing is preserving the exact same ugly artifacts in a more expensive way! But if there is some more original file (like a ".RAW" file taken from the camera or a higher resolution JPG or something) then there is definitely great benefit to making a PNG from that source and replacing the existing JPG file with it. SteveBaker (talk) 03:21, 3 December 2013 (UTC)[reply]