Wikipedia:Reference desk/Archives/Computing/2017 August 16
Computing desk | ||
---|---|---|
< August 15 | << Jul | August | Sep >> | August 17 > |
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. |
August 16
[edit]HTTPS vs fake-news impersonators
[edit]How much can HTTPS help against an adversary who's created a business entity with a confusingly similar name to a reputable media outlet, can obtain a certificate of its own, and is using e.g. DNS poisoning or typosquatting to deliver fake news? NeonMerlin 00:05, 16 August 2017 (UTC)
- If you're talking about impersonation, then HTTPS won't help at all. This is a social engineering problem, more than a technical one. Andy Dingley (talk) 00:17, 16 August 2017 (UTC)
- An attack based on DNS poisoning would still work even with the correct hostname, though, and most typosquatting isn't really social engineering, since it relies on a keyboard error made while the user is trying to visit the legitimate website (although it could be part of a larger attack, such as a phishing campaign with an embedded URL). As for HTTPS, it depends on how easy it is to get certificates that most web browsers will accept with their default security settings: I believe most browsers block self-signed certificates by default, and require the user to click-through, which would prevent many (not all) typosquatting, and some DNS-based attacks (although most people just keep clicking until they get to the site). I know of at least one authority that grants free certificates, but I'm not sure if you can just get a steady supply of them, which would be necessary if you wanted to stay online for any length of time. OldTimeNESter (talk) 03:29, 16 August 2017 (UTC)
- This is one of the reasons for Extended Validation Certificates. -- zzuuzz (talk) 03:43, 16 August 2017 (UTC)
Digital images, born-digital vs. scanned prints
[edit]![](http://upload.wikimedia.org/wikipedia/commons/thumb/4/40/1979-08-13-Williamsburg-104.jpg/300px-1979-08-13-Williamsburg-104.jpg)
Images like this one (from 1979) are easily recognisable as scans of print photos, partly because of the colors and their edges. I've never seen a born-digital image with colors of this kind, aside from photos that someone's processed afterward, and the edges (e.g. between the leaves and the sky) are very different from a born-digital image. Why are scans of print photos so different? Is it typically the result of something in the scanning process? I've never seen colors or edges like this in the print photos I took when a child, but I'm not sure if that's because camera technology changed between 1979 and 1999, or (again) if it's because of the scanning, so comparing this to unscanned 1990s prints is apples and oranges. Nyttend (talk) 00:49, 16 August 2017 (UTC)
- Couple possible causes come to mind, each probably contributes to the overall problem to some extent. The first is the color gamut. i think prints generally have significantly smaller color gamuts than photographic films and digital cameras. The second is fading of dyes in older photographs. Dyes of different colors fade at different rates, causing color shifts. The third is color management problems in the original printing and the later scanning processes. Given that more conversion steps are involved before an image turns from film to a print to a digital scan, it seems reasonable to expect more error to be in the resulting image. --98.115.172.183 (talk) 04:30, 16 August 2017 (UTC)
- The image has 1224x831 = 1,017,144 pixels which would occupy
30.53.05 MB of "true color" data. However the JPEG file employs Lossy compression to 1.39 MB that inevitably introduces degradations that cannot be reversed, particularly on edge details. The flatbed scanner could probably give a better image without the compression. The color quality of the grass is similar to that in the famous Zapruder film which was made on Kodachrome. Blooteuth (talk) 22:52, 18 August 2017 (UTC)- That's an incorrect explanation. The problems with the picture are not caused by lossy compression. --98.115.172.183 (talk) 02:51, 19 August 2017 (UTC)
- My information in no way contradicts your post, User 98.115.172.183. It cannot be denied that lossy data compression causes some degradation. The metadata for the image says it has been handled in Photoshops Elements that makes possible some correcting of color shift though we can't know whether that has been attempted. Blooteuth (talk) 03:43, 19 August 2017 (UTC)
- The size of an uncompressed image of the same dimensions is not a good estimate for how much space is required for a compressed version of a given image with good visual quality. The compressibility of an image depends on the complexity of the image and the compression algorithm. If you start with a clean image, take this one [1] for an example, and shrink it down to ≈ 1.0 megapixel, you'll find that you'll need a lot less than 1.3 MB for a very good JPEG compressed file. The picture the OP referred to, despite having a nominal size of ≈ 1 megapixel, doesn't seem to have 1 megapixel's worth of details. It also looks like it's been sharpened artificially. While the scanning process and post-processing may have degraded the picture further, I like to think that the original print wasn't of very good quality to being with. --98.115.172.183 (talk) 05:15, 19 August 2017 (UTC)
- My information in no way contradicts your post, User 98.115.172.183. It cannot be denied that lossy data compression causes some degradation. The metadata for the image says it has been handled in Photoshops Elements that makes possible some correcting of color shift though we can't know whether that has been attempted. Blooteuth (talk) 03:43, 19 August 2017 (UTC)
- That's an incorrect explanation. The problems with the picture are not caused by lossy compression. --98.115.172.183 (talk) 02:51, 19 August 2017 (UTC)
- The image has 1224x831 = 1,017,144 pixels which would occupy
PHP MySQL source code
[edit]I am developing a web application that is to be deployed on intranet where by users will be able to make requisition for two type of items by logging in with phpmysql i wrapped it in Quadodo login system.But my requirement is that change/reset password should not be by mailing but if a user forgets the admin will be notified and the admin will reset the pw to welcome and then with welcome password the user will reset to pw of his choice.I also want the system to be secure and restrict single simultaneous session per user.How should i modify the user table and php code specially password changing script which appears to be nonfunctional and disable any mail functionality.Unfortunately the Quadodo does not appear to be enterprise grade/production quality.Web reviews are saying that the code repeatedly senselessly uses sha1() and md5().Should I use bcrypt and password salting what will be the database schema like the one seen in culttt.com or p2p.wrox.com.Where can I find such source code php/mysqli/pdo source code in github or any book /site.Your advice is highly solicited.103.24.110.197 (talk) 09:22, 16 August 2017 (UTC)