Wikipedia:Reference desk/Archives/Computing/2014 October 19

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

October 19

Getting the "right" IP (geolocationally wise) without a VPN service

How can I pass as a US user (for services like hulu.com and netflix.com and some youtube videos) without a paid VPN service (nor an open proxy). Is Tor or some DNS thing an option to this? And if a paid VPN is the best option, will any website know that I am accessing them through a VPN?

Tor bounces your connections all around, continuously changing your IP, so that's out. DNS "tricks" are mostly for clients, not servers. A VPN or other proxy server can make your IP address on the Internet appear to be the same as that servers. Some proxy services also forward along your real address, some do not. VPN providers almost never forward your true address. Proxy/VPN providers typically get blacklisted on large media services, so even though your geo-location would be right, they could still deny your access. — xaosflux ^Talk 05:06, 20 October 2014 (UTC)

Actually you can specify that you want your exitnode to be in a specific geographical location with Tor. See [1] [2]. However I wouldn't recommend Tor because 1) It probably doesn't provide the bandwidth for streaming services to give a satisfactory experiences 2) The Tor exit nodes are published and can easily be blocked. Note that many commercial and free services designed for bypassing such geoblocks rely on the fact that frequently the geolocking happens only on the front end and the CDN serving the content doesn't actually attempt to geolock. This both reduces the bandwidth the service needs, and also tends to result in better performance for you. Nil Einne (talk) 12:32, 20 October 2014 (UTC)

Getting rid of Delta Search in Firefox

My browser, Firefox, got infected with that annoying Delta Search thing. What's the easiest way to get rid of it? I searched the Archives because I assumed this question had been asked before but I could only get info for Chrome, not Firefox. Thanks. Contact Basemetal here 02:00, 19 October 2014 (UTC)

PS: Btw is it possible that I infected my browser while updating Java? Is it possible that to make a few cents Oracle bundles this with the Java update? Seems hard to believe and yet I have a faint recollection that as I was typing next, next, next w/o paying attention to what was actually checked that I was "agreeing" to there was a line with "Delta search" among the options that were pre-checked. Plus that's the only thing I installed yesterday. Contact Basemetal here 02:00, 19 October 2014 (UTC)

Supposedly, this looks like their instructions for removing it. No clue personally whether this'd just lead you further down their rabbit-hole. http://info.delta-search.com/uninstall/firefox There's also a Firefox support thread on the topic, you could try the various suggestions they have: https://support.mozilla.org/en-US/questions/969882 75.140.88.172 (talk) 02:13, 19 October 2014 (UTC)

Oracle bundles the Ask.com toolbar with their Java updates. I can't find evidence that they bundle Delta Search. Did you download your Java update directly from java.com or oracle.com? If you downloaded it from a third-party site, it might have been wrapped with a third-party malware installer. (Download.com does that. Don't use download.com.) If you got a popup saying that you should update Java and followed its instructions, it was probably a fraudulent ad that had nothing to do with your real Java installation. -- BenRG (talk) 03:41, 19 October 2014 (UTC)

You might do well to dump Java at the same time.--Shantavira|^{feed me} 08:08, 19 October 2014 (UTC)

I'm considering it. But how would removing Java cripple my browser? No applet will work anymore, right? Is there a way to disable the browser's use of Java w/o actually deleting Java? (In a security setting for example?) And is there then a way to reenable it on a case by case basis, that is when I think (possibly incorrectly of course) it is safe to taking the risk to run one or the other applet? Contact Basemetal here 14:39, 22 October 2014 (UTC)

Thanks for your help. Regarding Java another question: The Java that we're talking about is the Java virtual machine, correct? Does it mean that if I get myself a Java compiler I can actually write code that will compile to bytecode that will run on that engine? Contact Basemetal here 14:39, 22 October 2014 (UTC)

Silent data corruption of video files

I've had an incident affecting my collection of photographs and videos that worries me, and that I hope someone here is able to help me understand. I had five videos (.3gp format) recorded on an HTC phone (HTC Incredible S S710e) bought January 2012. The videos were recorded May 2012. I recently discovered they were corrupt. Jpegs in the same directory appeared to be ok. Two other videos recorded with the same phone a couple of months later, which were stored in a different directory, were ok. Below (collapsed) is a summary of the troubleshooting I've done so far.

Troubleshooting (details)

In my most recent backups, the files were corrupt, but I retrieved the intact files from a backup from June 2013, along with the jpegs that I had kept in the same directory. I've found that the sizes of the corrupt videos are larger than the originals: 05.05.2012 17:25 50 019 626 VIDEO0002.3gp 01.10.2014 14:54 50 019 849 VIDEO0002_corrupt.3gp Although there appears to be no problem with the jpegs, I've found that they too have increased in size: 05.05.2012 17:42 1 686 133 IMAG0237.jpg 01.10.2014 14:54 1 696 534 IMAG0237_modified.jpg Using exiftool, I've found some differences in the metadata, both of the jpegs and the videos: Videos: A tag called "Handler Type" in the original is missing (or rather, moved, see below) in the corrupt file. It has the value "Video track" in the original. The tag called "Handler Description" immediately follows in the original, and is untouched in the corrupt file (value: "VideoHandle"). Later in the corrupt file, the following section appears: Handler Type  : Metadata Encoding Time  : 2012:05:05 18:52:54Z Media Class Secondary ID  : Unknown Content Media Class Primary ID  : Video Finally, the movie data offset is different, 810040 vs 810263. When the movie data offset is taken into account, the size of the binary video+audio data sections are exactly equal (49209586 bytes) in the original and corrupted files in the example. So I isolated the tails of the files, to check if the binary video+audio data were equal. They weren't. It is conceivable that they would have been identical if I'd had a way of assembling separate and continuous audio and video streams. But when compared as 49209586 byte binary files, they were totally different. I restored the entire foto directory from the 2013 backup on a separate disk, and programmatically deleted all files that had identical md5 signatures to files in my current Photo/Video directory, and then examined the files that were left in the restored backup. I'm not through examining (it's a huge task), but I found one similar instance, in which .MOV files recorded on a Canon EOS 500 camera had been modified in the data section. The exiftool-readable stuff was identical. The modified .MOV files were playable, and I noticed no visible or audible differences between the original and modified file. See below regarding the accompanying *.THM files, which really are small JPEGS. JPEGS The tag "Interoperability Index: R98 - DCF basic file (sRGB)" present in the original is gone in the modified file. Later, there is a section "Padding: (Binary data 2060 bytes, use -b option to extract)" in the modified file, that is not present in the original. Thumbnail offsite and length are increased in the modified file. There is a section in the modified file: About : uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b Date Acquired: 2013:01:26 00:12:31 That is not present in the original. In the second observation mentioned above (modified but playable .MOV files from a Canon EOS 500), I had renamed the *.THM files to *.jpg. These had also been modified. The most conspicuous changes were that Exif byte order had been changed from Little-endian (Intel, II) to Big-endian (Motorola, MM), and that the block About  : uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b Date Acquired : 2013:01:21 23:46:36 had been introduced. Note that the uuid is identical to the one above, and that the date is different. It is puzzling that the dates are close in time, but nevertheless before the undamaged backup was taken. A web search for similar problems came up with two hits that resemble the problems I have experienced: http://feedback.photoshop.com/photoshop_family/topics/_3gp_corruption_error_in_lightroom_4_beta http://answers.microsoft.com/en-us/windows/forum/windows_7-pictures/windows-live-photo-gallery-corrupting-3gp-files/62c48718-4957-4566-b4f3-f1e93d933e2d

Working hypothesis: The troubleshooting clearly shows that this is not a case of random data corruption caused by faulty disks or cosmic rays, and I find it very unlikely that it is caused intentionally by malware. I probably at some point in time, have accessed the files with a program installed on my PC which silently modifies both their metadata and the way video and audio chunks are laid out in video files. My top suspect was XnView, which I use a lot. However, I've tried to reproduce the problem with XnView, but my currently installed version does not modify the files it accesses in its file explorer. Other candidates are Windows itself, with its image and video display functionality. I've tried accessing the files with the windows 7 image viewer and the windows Xp viewer (from a virtual machine), without being able to reproduce the problem. I suspect that the uuid referred to in the details of the troubleshooting, faf5bdd5-ba3d-11da-ad31-d33d75182f1b identifies the culprit. A web search for the uuid leads to various images, but does not appear to be strongly associated with reports of data corruption. I have not been able to identify the program associated with the uuid, a search at https://mikolajapp.appspot.com/uuid/ returns no results for {faf5bdd5-ba3d-11da-ad31-d33d75182f1b}. I have used regedit to search for the uuid in my Win 7 installation, and in the Xp virtual machine, with no hits. This does not exclude that it is a previous version of a currently installed program.

And that's where I am right now. The incident certainly feeds my paranoia. If I had known the reason, I would have been in a position to eliminate the problem.

Suggestions on how to proceed to reach an accurate diagnosis of the cause of the data corruption would be highly appreciated. I believe I have mentioned the possible suspects, but should add that I use Adobe Lightroom and Exiftool a lot, and previously used jhead and a Canon program for adjusting white balance etc of raw files.

In particular, it would be helpful if someone could find out what program the uuid faf5bdd5-ba3d-11da-ad31-d33d75182f1b is associated with.

Thank you in advance!

--NorwegianBlue ^talk 11:43, 19 October 2014 (UTC)

I was able to reproduce this by opening the properties of a JPEG image in Explorer, going to the Details tab, and altering information there (for example, adding a tag or a star rating). This adds EXIF data to the image itself, and the UUID faf5bdd5-ba3d-11da-ad31-d33d75182f1b appears in the data that it adds. -- BenRG (talk) 01:39, 20 October 2014 (UTC)

Thanks! I'll try tonight if the same procedure corrupts the videos. I often access the Details tab for checking things, but rarely modify the EXIF data from there. But your experiment shows that Windows itself is making the changes, probably via calls from other applications. This was very helpful! --NorwegianBlue ^talk 04:54, 20 October 2014 (UTC)

I can confirm that modifying the EXIF data of the video files from the Details tab indeed caused corruption of the .3gp video files, with very similar changes in the EXIF data to those I described in the details of the troubleshooting above. I then used ffmpeg and moved the data to an mp4 container:

 ffmpeg -i VIDEO.3gp -vcodec copy -acodec copy VIDEO.mp4

and again modified the EXIF data from the Details tab. This time, the file was still fully functional. All I need to do now, is to move the small number of .3gp files that I have to .mp4 containers, and the problem is solved. Thanks, BenRG, for giving me peace of mind! --NorwegianBlue ^talk 21:45, 20 October 2014 (UTC)

Resolved

Windows Server 2008 R2 with licence key from original

Would an unused valid licence key for Windows Server 2008 work to activate 2008 R2? I know I can try it and see, but I'd rather not spend my download quota and hours of setup time for nothing. Thanks! 213.205.251.78 (talk) 12:59, 19 October 2014 (UTC)

No; they are different operating systems and require different registration keys. --  Gadget850 ^talk 16:37, 19 October 2014 (UTC)

How are spammers actually paid?

My interest here is basically how the employees of spammers actually get compensated and have their performance measured, though data on the front-office end wouldn't be taken amiss.

Specifically, I was thinking of a thought (or perhaps literal) experiment: suppose for example you started a wiki that was poorly-watched and would have a hard time dealing with all the spam. But you post a notice that you've divided your site into two sections: articles /s/wiki (spam-enabled) that do not have nofollow set, where people will not monitor for spam, which are refreshed on a very slow and predictable schedule from your /d/wiki (spam-disabled) section, which has nofollow set, which is what the users actually edit and read. Now if the spammer gets paid for how many spam links he adds, and/or how long they last, and/or how they affect search rankings, then he should post to /s/ daily. But if the spammer is paid according to the number of actual hits received from his links, then he'll still post to /d/ where the readers are. Which would happen in practice? Wnt (talk) 18:34, 19 October 2014 (UTC)