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

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 14

Spreadsheet help

My local animal shelter puts out collection boxes on store counters for people to put their loose change in. The staff member that oversees this project has a spreadsheet, which she has shared with me, where all the info is kept. That info includes the store's name and address. It also lists the date that the collection box was emptied and how much was collected on that date. She's been keeping the date each box was emptied and the amount that was in it in the same cell (I know that will have to change as keeping two data types in the same cell simply won't work). Not all the boxes are emptied on the same date since there are several volunteers (I'm one of them) who go out and pick up the cash, and not every volunteer collects on the same day. Also, some boxes are emptied twice a month during tourist season. I have one like that but other people might have more lucrative boxes which are emptied more often, I don't know.

What she'd like to be able to do is to be able to see which boxes are not bringing in very much money. She'd then make the decision to pull those boxes and put them in more lucrative places. The boxes are expensive, so just throwing more boxes at the problem isn't the best way to go at it.

I don't have a huge amount of experience with Excel but I'd like to help her clean this up a bit and make it easier to use. What I'd like to do is make it so that she can see a graph of each box's proceeds over time. For instance, if the box is continually brining in less than, for example, $10 per month, then the graph would make that clear without having to scan through a bunch of numbers.

So, does anyone have any tips on how I might achieve this? Thanks, Dismas|^(talk) 06:13, 14 October 2014 (UTC)

A graph for every box seems like too much info, to me. I'd think that once you separate the data into the proper columns, and ensure that money is recorded as money or at least a numeric field, and date is really recorded as a date, not character or some other format, then you could just find the daily average as the amount collected divided by the number of days between the current collection and the previous collection (the box installation date should be listed as the first collection date, with $0 collected). Report that in a new column.

You might also want a long term average, say by dividing the sum of all the money collected at that location by the total number of days since the box was first installed. At the bottom of the short term and long term daily averages, you could list the worst performing box in each category, in case you need to find one to move to a new location.

Note that when a box is moved, you should start a new row, not continue on the same row, as then you'd have combined long term average info for both locations. Fill in cells in the old row with the closing info on the old location, then enter a zero collection for the new location on the new row. The date should be entered twice, once for each row.

A graph would only be useful if you need to study trends, in detail, at each box, and it would require running a report to generate the graphs, while the method I proposed would be calculated automatically and added to the spreadsheet, as soon as you enter the data for each box. StuRat (talk) 17:49, 14 October 2014 (UTC)

@Dismas: I think what you want is essentially a cumulative distribution of money over time for each box. For each box, start a new column (or row, whatever) to hold the amount of money accumulated. Then just put in a formula that adds each withdrawn amount to a running total. So if box A withdrawals are in in column A, then column B should be something like B1=A1, B2=B1+A2, ... BN=B(N-1)+AN.

This is simple, but it only makes sense to compare cumulative totals when the last withdrawal is roughly the same date. To facilitate graphing, I'd change mm/dd/yy (or dd/mm/yyyy, etc) values to day of year values, so that they are easier to plot/manipulate (Excel can do this with built-in functions, as described here [1] [2]). If you have a new column of DOY dates, then you can just use a line plot of DOY vs cumulative box total to compare many boxes total returns over time, even if the withdrawals are at different times and frequencies.

One of these links might help you split the date/value column into two columns [3] [4]. Make sense? SemanticMantis (talk) 19:04, 14 October 2014 (UTC)

WinRoute Pro problem

I know this will be upsetting reading, but please bear in mind that we are using ancient hardware and software due to company frugality and a 'that's the way it was always done' philosophy.

We have WinRoute Pro version 4.1 running on a Windows 2000 server that collects emails from the sky and spits them out into Eudora on the appropriate workplace PC. The company has recently moved locations. For some reason, our current ISP (Demon) was unable to provide broadband on the new location's phone line. One Bill now supply our broadband and we retained Demon's services hosting our website and email which is now 'forwarded' (?).

Our current problem is that WinRoute is now very confused and while it happily collects our email and spits it out at the right person, none of us are able to send any email, unless it is to another Demon address. We are temporarily getting around this by using webmail.

Too many people have tried to sort this out and everyone has received different advice and opinions from the helplines we have phoned. The last advice is that we need to change the port number from 25 to 587 as the mail is only able to be delivered to that in the Demon ip range. I've changed the relay SMTP server back to smtp.demon.co.uk and changed the SMTP port to 587 (no 465 was also suggested) but I am still getting the same message:

Mail server: WinRoute Pro 4.1 at xxxredactedxxx Error description: message could not be delivered, server replied: 503 This mail server requires authentication when attempting to send to a non-local e-mail address. Please check your mail client settings or contact your administrator to verify that the domain or address is defined for this server.

What have I missed out or not done?

Many grateful thanks in advance for any hints you might be able to share. 89.243.208.99 (talk) 14:01, 14 October 2014 (UTC)

It sounds like smtp.demon.co.uk (that name is mentioned in the delivery failure message, right?) notices that you're connecting not from a Demon IP address, so it demands authentication. You might be able to get Demon to add a rule to recognize your IP block with One Bill (especially if that IP range is small/static). Otherwise, you might be able to teach WinRoute a username/password or similar to use with Demon's SMTP server, but there might not even be such (the message might really mean "we don't allow mail from your IP without special permission that it is impossible to have"). Why not use One Bill's SMTP server for outgoing mail, though? It doesn't matter if it's different from the server you use for incoming… --Tardis (talk) 01:50, 17 October 2014 (UTC)

Why does Snapchat even have an API in the first place?

I'm reading about the how thousands of private photos have been compromised by malicious third-party apps using Snapchat's API.[5] The main point of Snapchat is that it's supposed to protect the user's privacy. What I don't get is why Snapchat has an API to begin with. Having an API seems like a really, really bad idea. Why not have a close system like Skype? AFAIK, it's not possible to create a third-party Skype app. A Quest For Knowledge (talk) 14:05, 14 October 2014 (UTC)

As far as I can tell, Snapchat doesn't have a public API, so it's like Skype in that regard. Various people have been reverse engineering the internal API that the various official Snapchat clients use to talk to their server, and then using that information to write their own Snapchat clients (which do stuff the official ones don't). Doing that is contrary to their terms of service, and they've apparently been trying to block these other apps, by technical and legal means. -- Finlay McWalterᚠTalk 14:18, 14 October 2014 (UTC)

hmm, I'm not sure they've actually C&D-ed anyone, and there's certainly lots of documentation of the private API and various projects on sites like Github which use it. -- Finlay McWalterᚠTalk 14:27, 14 October 2014 (UTC)

Google did remove a large swathe of unofficial Snapchat apps, which worked by the means I've described above, back in January - presumably at Snapchat's request. As most Android devices allow sideloading apps even without rooting the device, some of those apps remained available as APK files after that. -- Finlay McWalterᚠTalk 15:25, 14 October 2014 (UTC)

It's a fundamental problem - whenever you have an online service, part of the code lives in the client's computer and part off on the server someplace. Those two parts generally need to interact - and for that to happen, there must be some kind of API. Worse still, the client-side part is available to any user of the service to examine and reverse-engineer...especially if you're using a web/browser-based system where the client is running JavaScript...and it's really tough for the server-side code to know when it's being activated by the intended client software or some reverse-engineered malware. SteveBaker (talk) 16:26, 14 October 2014 (UTC)

Difficult, but also not impossible to improve the security. Theoretically some of the software token techniques described by Security_token#Password_types could be used to assess the authenticity of the client. I doubt snapchat can afford to distribute physical tokens or dongles with their business model, but I don't think there's any theoretical barrier to establishing client identity/authenticity on the server side... right? SemanticMantis (talk) 17:07, 14 October 2014 (UTC)

Anything the client can do to authenticate itself can be spoofed. Even a dongle wouldn't change that, since the dongle can't know whether a legitimate client is using it except by some sort of authentication protocol which could also be spoofed. -- BenRG (talk) 20:15, 14 October 2014 (UTC)

The signed message produced by the dongle could, instead of simply saying "this client (tells me it) is OK", actually be the request that the dongle had vetted. --Tardis (talk) 13:25, 15 October 2014 (UTC)

Do you mean that in the same sense as "any encryption can be in principle broken"? Maybe I should ask a new question, because while I grant the concept in principle, my understanding is that related encryption/authentication schemes could be deployed so as to make spoofing roughly as difficult as breaking modern encryption schemes (i.e. possible, but highly unlikely unless the breaker has huge amounts of time, money and expertise). SemanticMantis (talk) 16:39, 15 October 2014 (UTC)

The only ways I can see for this to work are:

• The dongle has its own display screen, and it decrypts, displays, and erases the image entirely within the dongle.
• The app contains an authentication secret, and the OS and the hardware it runs on use ubiquitous encryption to prevent anyone ever seeing any of the app's code to extract the secret.
• The OS doesn't allow apps to send arbitrary data to the server; for example, each app has some sort of unique ID and other apps can't transmit that ID.

All of these are very difficult to implement, and none of them can be done by an Android app acting alone.

Normally the purpose of a dongle is to prevent anyone who lacks the dongle from authenticating. Here, the adversary has the dongle, and has the Snapchat account password, and is in fact the intended recipient of the image. There's nothing the client can do to prove to the server that it will delete the image after displaying it.

The best you can do is obfuscate the client code and hope that no one will bother to spend the additional time it would take to extract the secret. Even then you can bypass the obfuscation by running the app in an emulated environment and scraping the images from the emulated screen. -- BenRG (talk) 05:01, 16 October 2014 (UTC)

• Q:What I don't get is why Snapchat has an API to begin with. A: Microsoft insist on third parties having micrsoft's closed sourced API (interfaces) to protect microsoft's manopily. Then microsoft can (and do) claim payments from security companies that can only retroactively try to fix microsoft's security sort commings. That is why it is often quoted that Windows is defective by design. Nuff said? ! ! !--Aspro (talk) 19:19, 14 October 2014 (UTC)

for the claim Microsoft insists on third parties having Microsoft's close source APIs. If you interact with Windows or any other Microsoft OS, you do have to use Microsoft's APIs (although the level can vary greantly, you can use open source APIs which interact with Windows in a low level manner many don't recommend or find produces poor results if you want), just as you would any other OS, like for example with Apple's largely closed source APIs (although they lower level APIs tend to be open source). Of course as others had already pointed out, this has little to do with why Snapchat is vunerable. In fact, while security by obscurity is generally a bad idea, in this particular case there is actually a minor advantage to a closed source operating system in that if you OS doesn't provide a means to monitor the apps network and other activity, you could easily customise your open source OS to provide such functionality. That said, it's a very minor advantage. E.g. for network activity all you need to do is monitor outside the device. And you could always hack whatever functionality in to the OS if really needed. It's also a moot point since Android (and Windows) intentionally allows that level of debugging functionality to the end user on certain devices if they want it. Actually the design of most OSes probably means the functionality is there or can be added, just perhaps disabled, not only without a means to enable it but intentionally made difficult to even try (iOS and I think Windows Phone and some Android devices). In any case, Snapchat doesn't even have an official Windows Phone client [6] do I don't get the relevance of your random rant. Nil Einne (talk) 07:15, 15 October 2014 (UTC)

Need a citation ah! Here is a good WP type reliable ref: “it is well established that a monopolist generally has no duty to cooperate with its competitors.” [7] So, Novell (as is now on legal record) could not get access to the updated microsoft's API's. Try and develop ones own API's in the dark leads to all sorts of problems. Your quote: In any case, Snapchat doesn't even have an official Windows Phone client... Now you know why! Now microsoft wants to promote its own version of Snapchat (just as it wanted to premote Word over Novells Wordperfect. Et cetera, et cetraa. Snapchat is under attack by forces that want it to look bad so that they can more easily capture (by good means or foul) Snapchat's market segment. One does not have to have a diploma or degree in Kindergarden dynamics to see this.So most of your other comments are now moot.--Aspro (talk) 16:20, 16 October 2014 (UTC)

Finally: Google is your Friend, but you don't seem to understand![8]. This is the result of 20 seconds of googling....See: Microsoft builds Snapchat-like WindUp for Windows Phone. Why should microsoft allow Snapchat access to authentic microsoft API's, that other developers can then use to dilute microsoft's monopoly? A leopard cannot change its spots! So I stand by what I say. Snapchat is boxed into using their own unofficial API by the actions of a big monopolist bully. Meaning that, other independent developers are liable to introduce security weaknesses if they misuse Snapchats guidelines. Is that Snapchat's fault, when they are being forced to work in the dark? Over to you that where born knowing everything but understanding nothing!--Aspro (talk) 18:04, 16 October 2014 (UTC)

Little to do with original question, so collapsing Nil Einne (talk) 05:20, 17 October 2014 (UTC)

Frankly I have little idea what you're referring to. What unofficial API is Snapchat forced to use? And for that matter, what on earth does this have to do with the question? The whole point of the question was why Snapchat would use a public API for their client-server interactions. The answer to this question is they don't, but security through obscurity doesn't generally work very well. In this particular case, since the client is on a device the user basically has complete control over (and the user also has control over part of the network*), there's nothing that Snapchat can do to stop people working out what their private API is doing and making unofficial apps which interact with their servers. (Edit2: Although many people unrelated to Microsoft have said that SnapChat's API and server/database and client design is particularly poor.) In any case since they don't interact with the Microsoft world official at all, it clear has nothing to do with Microsoft, but all to do with Android and iOS who they do interact with. (Edit3: As to independent developers, well AFAIK and supported by what others have said earlier, with the caveats I mentioned later, Snapchat doesn't even allow them. Actually one suggestion is that SnapChat should have a public API and allow third party applications to official interact with them provided they follow the necessary published guidelines and provide their own token so can be recognised as third party clients [9]. And some of the "flaws" of third party applications are intentionally, i.e. people are just doing stuff Snapchat doesn't want. Others appear to relate the way third party clients are trying to get around either the limitations of Snapchat's API since they're doing stuff Snapchat doesn't want. As mentioned, I don't really understand how Microsoft APIs came in to this. Whatever flaws in Snapchat's server-client API is surely their own, unless they were dumb enough to try and copy someone else's like Microsoft for something which is supposed to be their own internal API completely unrelated to Microsoft even if they were running on anything Microsoft related, which AFAIK they aren't neither client or server side anyway.) As to your other points, well the APIs for Windows Phone are easily available to developers whatever historic problems Microsoft may have in this regard. The could be limitations in these APIs, but frankly the primary reason why Snapchat is not building a Windows Phone client is fairly obvious to anyone paying one iota of attention to the state of the mobile market. Microsoft has only a miniscule portion of the mobile space, undoubtedly even more so among the teen & young adult who are Snapchat's primary client based. Microsoft is continually begging and offering all sort of incentive for developers to develop stuff for Windows Phone (and the Modern UI in Windows), the main reason why everyone says they're not doing so is not because of any limitations in the Windows Phone API but because of the small market share. It could be these developers are secretly scared of someone who they're generally laughing at and not afraid to make fun of and criticise. But probably not, and they mean what they say when they say they don't think it's worth developing for Windows Phone. (The older ones in particular may also have a dislike for Microsoft or their tactics, but the nature of the mobile space is such that many of them were probably still in high school when Microsoft was making a patent deal with Novell, let alone earlier problems between them. And so most don't really give a damn about anything (if they are even aware) except perhaps that Microsoft just isn't seen as 'cool'.) I was aware of the Microsoft Research's Snapchat alternative having encountered mention of it in my earlier searches, I didn't mention it as it's not particularly relevant. Snapchat developers and owners probably didn't even lose a day sleep to it, compared to all the much more serious threats including from competitors they feel are a genuine risk, not Microsoft but others like Facebook, probably Twitter, maybe even Google, Yahoo/Tumblr and Apple (who's wide market share does make them a concern, despite the fact their apps will surely only be for one set of devices). And actually showing my age here, those new popular messaging services I can't recall offhand (ah WhatsApp, that's one). Actually speaking of Microsoft, it's very likely Snapchat is if anything more concerned about unofficial clients on Windows Phone that interact with their services, I'm not sure whether Microsoft is as proactive as Google, the lack of an official alternative probably gives them a reason to be less so. Of course, they have been trying to convince Snapchat to build a Windows Phone app [10], so it could be a sign of good faith to remove stuff Snapchat consider harmful. And the nature of such disputes is complicated anyway, the history of IM and elsewhere has shown it's not clear if there's really anything legally preventing such apps particularly when there aren't patents involved. However, most of the stores generally have robust enough policies (and a willingness to change them), that whoever is control (Apple, Google, Microsoft, Blackbery, Samsung, Amazon, Nokia etc) can basically remove apps or other content when they feel it's needed, without much fear of legal repercussions (PR may be a different matter). Then again, I'm not even sure what Snapchat's official stance is, do they consider all unofficial apps unacceptable, or do they turn a blind eye to those which try and open Snapchat's norms, at least on platforms they don't support? While there are undoubtedly competitors using every opportunity to make Snapchat look bad, it's likely Microsoft would be willing to even can their Research project with guarantees not to resurrect it, if Snapchat promises to make an official client. (And frankly Microsoft Research is fairly well known for making extremely interesting stuff that almost no one ever uses until someone else makes a different or better version.) Edit: And if Snapchat really was going to be concerned about Microsoft, it would be about Skype Qik (which at least is part of an established platform albeit one not invented or popularised by Microsoft), not WindUp. Of course, you've still provided zero references for your initial claim that the vulnerability of Snapchat's API had anything to do with Microsoft APIs. P.S. Microsoft is not a monopolist in the mobile space, not even close... P.P.S. (*)I should mention I recognise now my statement above was a little wrong. While having control over the network is useful, if a person doesn't have sufficient control over the client to be able to control it, it could be of limited use if the client is well made. As people mentioned earlier, encryption should make network sniffing useless (provided the key exchange and encryption is implemented well). Still since people do normally gain sufficient control over their devices, this doesn't matter. And as mentioned, Android which intentionally (many would say and good on them) gives the user this control. (Even with iOS devices, there's strong enough incentive generally that any of Apple's attempts to prevent the user getting this level of control is usually defeated, eventually.) And thinking a bit more, while not using OS provided stuff like certificates and SSL may have advantages if implemented well, also runs a strong risk you'll screw up your implementation and it won't be very strong yet if you do use such, even iOS may provide the level needed to be able to monitor unencrypted communication. P.P.P.S. If anything, the most common modern complain about Microsoft when it comes to APIs, at least on the Windows if not Windows Phone side, is they have too many of them since they maintain many legacy ones, and are also frequently introducing new ones. Nil Einne (talk) 03:45, 17 October 2014 (UTC)

iOS 3rd party app interactive notifications

Maybe I'm missing a trick, but I can't see to find any options in my iPhone settings for interactive notifications. The reason I'm asking is because I can reply to iMessage and SMS from the lock screen using the interactive notifications, but none of the third party apps I use let me, and I'm not seeing where I can activate the functionality. I googled it, but all the guides say, I can activate/deactivate interactive notifications 'from Settings' but doesn't specify where.

I am aware that some of the apps may not yet have this functionality added, so if you know whether Facebook, Line, WhatsApp and WeChat allow this yet, please let me know. I'm thinking Facebook does because I saw some article about being able to reply to wall comments etc somewhere.36.225.87.98 (talk) 14:58, 14 October 2014 (UTC)

They're probably not "notifications", but "widgets" (small mini-views of an app, intended for use on screens like the home screen). As far as I can tell (I'm not so up on IOS things as Android), IOS8 added the ability to add widgets to the lock screen. This may help you do that yourself. It seems that IOS7 didn't support 3rd party widgets on the lock screen, unless one rooted the phone with Cydia or the like. -- Finlay McWalterᚠTalk 16:20, 14 October 2014 (UTC)

No, it's definitely notifications. When I get an SMS since the update to iOS 8, I can reply from the lock screen by sliding left and typing. Apparently this should work with Facebook and Line... but it doesn't. Like I said, all the guides say the ability to do this can be toggled 'from Settings' without saying where specifically. I'm not sure if those apps have been updated to allow this function.36.225.82.45 (talk) 16:10, 15 October 2014 (UTC)

Word menu disappeared

I'm not sure I have the terminology right here, but Microsoft Office 2010 programs (including Word) have at the top menu labels (File, Home, Insert, Design, etc.) with sub-menus where you can click to do such things as center text and make it bold. I clicked a button that made the sub-menus go away, and I don't know how to reverse that action. Can anybody help? Thanks. --Halcatalyst (talk) 21:10, 14 October 2014 (UTC)

P.S. The icon was in the far upper right hand corner, and I was just curious what it was for. I hate it when I go somewhere and can't find my way back. --Halcatalyst (talk) 21:49, 14 October 2014 (UTC)

If you still have the help question mark icon, you can click that and type in the keywords you want, then bring up a link to change the setting. StuRat (talk) 23:27, 14 October 2014 (UTC)

Thanks, this suggestion led me to the solution. The state I was in is called Read View. It's designed to allow more space when you just want to read the document. The other options are Print Layout, Web Layout, Outline and Draft. If you're in Read Mode, you hit View and then choose Edit Document to see the writing tools and menus again. --Halcatalyst (talk) 00:02, 15 October 2014 (UTC)

You're quite welcome. I'll mark this Q resolved. StuRat (talk) 01:28, 15 October 2014 (UTC)

Resolved

Installing 1333MHz RAM into a 1066MHz machine

My older computer takes 1066MHz DDR3 RAM SO-DIMMs . However, I'm having trouble finding that speed in retail stores in the 8GB density I want. What risks (if any) is there of installing 1600MHz or or 1333MHz DDR3 SO-DIMMs? I'm assuming the faster RAM will merely run at the maximum 1066MHz that my motherboard accepts? --76.95.37.3 (talk) 22:04, 14 October 2014 (UTC)

Yup. And even slower too, because it gets bottlenecked. Stick with 1066 if you can find it. I have no idea what computer you have, but probably something like this. KonveyorBelt 22:14, 15 October 2014 (UTC)

Can you provide any evidence to support "even slower too, because it gets bottlenecked"? I'm pretty sure that's false.

Faster RAM will most likely work. Higher-capacity DIMMs may or may not work. You should check what your motherboard, or prebuilt machine, supports. If it does work, I really doubt it will be slower than slower-rated RAM. -- BenRG (talk) 22:28, 15 October 2014 (UTC)

I just bought some PNY DDR3 PC3-12800 RAM and on the packaging it says "compatible with 1600MHz, 1333MHz, and 1066MHz". So I guess that answers that! Thanks for your help! --Navstar (talk) 18:30, 17 October 2014 (UTC)