Wikipedia:Reference desk/Archives/Computing/2018 March 30

= March 30 =

Can you hack in to idle wireless
If i have a pc or a mac in this case, and its wireless is on but not attached to anything, can someone break into it through the wireless? Assume no firewall is active, im thinking theoretically. — Preceding unsigned comment added by 2600:1003:b116:ca40:64d1:acc0:3ee7:8273 (talk) 30 March 2018
 * If your wifi is on it's not generally 'idle'. Even if it's not connected to anything, being 'on' most likely mean it's actively looking for access points. After all, that's how it can connect to access points in the first place. So with bugs, yes this process can be vulnerable to being compromised. E.g. Broadpwn [//www.wired.com/story/broadpwn-wi-fi-vulnerability-ios-android/] [//blog.exodusintel.com/2017/07/26/broadpwn/]. Even if it wasn't actively participating i.e. was just listening to stuff it received, this would generally mean there was some interpretation of what it was receiving so this could also be vulnerable although the more complex the process, the larger the attack surface is likely to be. Nil Einne (talk) 06:43, 1 April 2018 (UTC)
 * P.S. Also 'not attached to anything' is unclear. Mostly OSes have abandoned automatically connecting to unknown public wifi hotspots although it can still be an option. But even if it's not connecting to unknown hotspots, it's easily possible either someone could spoof one of the known ones (i.e. Evil twin (wireless networks)) or the real known one could compromise you. In other words, 'not attached' can be a fleeting thing if the OS is set-up to automatically connect to some known hotspot. (Spoofing a WPA2 protected hotspot is a lot harder since you need to know the PSK, and if you've obtained that there's a fair chance you'll either be compromising the AP or compromising the device while connected to the proper AP.) Nil Einne (talk) 17:11, 1 April 2018 (UTC)

Bizarre TV/monitor behaviour
We have a TV at the office that we use as a screen during meetings. It's a Vizio D65u-D2 4K TV and we all connect via an HDMI cable. It's been working fine for months, but over the last little while, people's laptop's have stopped being able to connect. Like, you unplug from a laptop where it's working fine, plug it into another laptop and the screen just stays blank. At first, everybody's laptops worked fine, then a few started experiencing this problem, and now several people have the same issue. We've reset the TV, tried different ports and different cables. We've all got Dell laptops of approximately the same vintage. I've tried Googling, but all I get is people with issues of Wifi connection (which works fine for us). Any pointers or suggestions? Matt Deres (talk) 21:52, 30 March 2018 (UTC)

Python Unicode Madness
I'm writing a small script that extracts two columns from a CSV file with UTF-8 text, formats them, and prints them back. I use Python 3.6.3 and the csv module. So far all is well. I get a reader, and iterating over it gives me a list of strings for each row. Now these strings can contain Unicode characters, but Python is content and thinks they are type class 'string'. But when I try to print them, I get "UnicodeEncodeError: 'ascii' codec can't encode character '\xfc' in position 35: ordinal not in range(128)". So I use str.encode("utf8") on them, and get objects of type class 'bytes'. Those I can print, but it is printed with the leading b and quote marks, and I can't e.g. use format on them. So I try to use bytes.decode, and I'm back where I started - and very unhappy. I finally gave up using nice string functions, and just opened the output file in binary and used file.write to write the raw byte strings. But there must be a better way! I thought that the CSV part would be hard, but not that I would spend 5 hours digging through stack exchange, Python tutorials, and the documentation to find out how to print Unicode strings - in particular since in Python 3 all strings are Unicode strings. I suspect my problem has something to do with the fact that the csv.reader returned the raw UTF8 bytes as a string. The decode turns should turn it into a unicode string, but it turns it into a byte stream...please explain what is going on and how I can escape this labyrinth! --Stephan Schulz (talk) 22:11, 30 March 2018 (UTC)
 * I found  It says csv.reader does not handle Unicode, but it gives an example wrapper "unicode_csv_reader" that allows for reading Unicode and also a UnicodeReader class.  RudolfRed (talk) 22:25, 30 March 2018 (UTC)
 * Thanks. That, unfortunately, applies to Python 2.7.4 - the Python 3 version here does no longer contain this discussion, and I think it does not translate - the problem is the Python 3 distinguishes strings and byte sequenced, while Python 2 used string for both (I think). --Stephan Schulz (talk) 22:45, 30 March 2018 (UTC)


 * Assuming your opening the files with utf8, it should work:


 * (language is grabbed out of the various ??.wikipedia homepages, apologies if it's inadvertently nsfw or something). -- Finlay McWalter··–·Talk 01:36, 31 March 2018 (UTC)


 * -- Finlay McWalter··–·Talk 02:01, 31 March 2018 (UTC)
 * Thanks - I think that is what I'm doing...here is the heart of my code:


 * ...originally without the encodes - if I then try to print the keys in printPaper, I get the error. --Stephan Schulz (talk) 07:09, 31 March 2018 (UTC)
 * It sounds like you had a version where resfp1 wasn't opened in binary mode. Can we see whatever was closest to working in that case?  --Tardis (talk) 21:21, 31 March 2018 (UTC)
 * What I've posted so far is the hack I hacked to hack around the issue. Below is a reconstruction of the original version:


 * ...and here are input:

#,Authors,Title,Decision,"Average total score","Total score","Overall evaluation","Reviewer's confidence" 3,"An Author",A Title,ACCEPT,0.7,"0,1,1","0,1,1","4,4,4" 4,Max Müller, Something about Logic,ACCEPT,1.3,"1,2,1","1,2,1","4,4,4"
 * ...and depressing result:

An Author : A Title Traceback (most recent call last): File "./accepted_hack2.py", line 13, in     printPaper(row[1],row[2]) File "./accepted_hack2.py", line 7, in printPaper print(authors, ": ", title) UnicodeEncodeError: 'ascii' codec can't encode character '\xfc' in position 5: ordinal not in range(128)
 * Thanks! --Stephan Schulz (talk) 20:53, 1 April 2018 (UTC)


 * Your code works fine for me (Python 3.6.3 on Linux). I have to wonder - what do you see if (at the command line) you say  - you should see (as I do)

foo.py:     Python script, ASCII text executable minimal.csv: UTF-8 Unicode text
 * -- Finlay McWalter··–·Talk 21:33, 1 April 2018 (UTC)
 * I do:

accepted_hack2.py:        Python script text executable, ASCII text minimal.csv:              UTF-8 Unicode text
 * Maybe I should have mentioned I'm on a Mac (though the error shows in both Mac Terminal and in xterm). I now suspect that Python thinks it need to print the output to an ASCII terminal, and hence to convert it to 7 bit ASCII (at least my terminals don't show Umlauts even if I  files). It might be a problem with the environment, not Python. --Stephan Schulz (talk) 08:46, 2 April 2018 (UTC)


 * https://stackoverflow.com/questions/918294/python-unicode-in-mac-os-x-terminal  -- Finlay McWalter··–·Talk 11:03, 2 April 2018 (UTC)


 * I don't have access to a Mac to verify, but on Linux if I run Python with  then   is indeed ascii, and so   generates the   error you get. -- Finlay McWalter··–·Talk 11:12, 2 April 2018 (UTC)
 * Thanks - that is at least a workaround! setenv PYTHONIOENCODING utf-8 makes it work (the characters look funny on the Terminal, but I wanted to redirect things to a file, anyways. I really do think this is broken behaviour - Python should always send the same bytestream to the terminal, and it's the terminal's job to interpret it. Separation of concerns and all that! --Stephan Schulz (talk) 18:49, 2 April 2018 (UTC)