Wikipedia:Reference desk/Archives/Computing/2017 March 6

= March 6 =

XHR (Javascript): Absence of webpage necesses asyncasy?
Data items requested directly from the backend does require webpage bootstrapping...

In contrast, data items requested with XHRO as in AJAX (or AJAJ, to be more modern) are returned without bootstrapping of the webpage.

My question is this: Why excactly does the first way is synchronic and the second is asynchronic (by means of how the requested data items will return), I mean, why does the ABSENCE OF BOOTSTRAPPING necesses asyncasy?

78.48.189.23 (talk) 03:38, 6 March 2017 (UTC)
 * I take it "necesses asyncasy" means "requires asynchronicity", but what is "bootstrapping"? This Bootstrap? Asmrulz (talk) 02:14, 7 March 2017 (UTC)


 * Bootstrapping === Reloading of the webpage. Ben-Yeudith (talk) 04:00, 7 March 2017 (UTC)
 * In that case, the whole purpose of asynchronous requests is to fetch additional data without reloading of the page. Asmrulz (talk) 09:39, 7 March 2017 (UTC)
 * Asynchronous just means non-blocking, that is, the request returns immediately, and when the data is ready, a user-supplied callback function is called. And there can be any number of them running at a given time. They could've made background requests blocking, but that would be bad for the user. Asmrulz (talk) 09:39, 7 March 2017 (UTC)
 * Yes user:Asmrulz, but it seems to me, as a humble student, that you can load data synchronously as well, without bootstrapping, as it will just be loaded in an order, so I miss why is there a "necessity" for asyncasy if we pass the bootstrapping... Ben-Yeudith (talk) 11:46, 7 March 2017 (UTC)
 * are you the OP? dfq is asyncasy? about the only ghit for asyncasy is this page Asmrulz (talk) 13:35, 7 March 2017 (UTC)
 * Yes. BY "Ayncasy" I mean to getting the data asynchronously. Ben-Yeudith (talk) 15:13, 7 March 2017 (UTC)
 * oh, ok. Sorry. I just thought I sensed sarcasm. Anyway, there is no need, per se, and you can, if you must, send synchronous requests. One reason to use the blocking version is if you need to make sure the request completes before the user leaves the page or closes the browser. However, asynchronous requests are preferable, because they don't freeze the browser so much (the javascript engine apparently runs in the main UI thread and doesn't "come up for air" (i.e., let other code run) if it's inside XMLHttpRequest.send.) Plus, as I said, you can have many of them, because you don't have to wait for each one to complete before instantiating another one. Also see asynchronous I/O, it doesn't talk specifically of the web stuff, but the same principles apply. Note you don't need asynchronous I/O if the language (or the runtime environment in general) has threads. You just put a potentially time-consuming function in a separate thread and wait for it to finish. But there's no mechanism for this in Javascript and even if there were, asynchronous functions are still neater. Asmrulz (talk) 17:58, 7 March 2017 (UTC)
 * This answer helped me so much! I thank you very much Asmrulz! Ben-Yeudith (talk) 19:16, 7 March 2017 (UTC)

Time delay after failed login
What do you call the time delay after a failed login? It's what websites and other things require to make a brute-force attack take a long time to be successful. 208.95.51.38 (talk) 17:35, 6 March 2017 (UTC)
 * To the best of my knowledge, there's no official or industry standard name for the practice. Google doesn't seem to contradict me on this, though an editor with a specialty in security might be able to provide an answer. ᛗᛁᛟᛚᚾᛁᚱPants   Tell me all about it.  17:50, 6 March 2017 (UTC)


 * I think the technical term would be a "backoff algorithm," as in the exponential backoff algorithm or the randomized backoff algorithm. Applications of this technique - enforcement of a delay before permitting a retry - exist in the context of software security, but also exist in network theory and communications theory at large.  For example, if you study ethernet in great technical detail, you will learn about Carrier sense multiple access with collision detection.  A well-informed student will read a few case-studies about voluntary- and mandatory- enforcement of delayed retries: there is a tradeoff between best-case, worst-case, and median-case performance.  The very same analysis can apply to these delays: whether they are emplaced to prevent accidental- or intentional (malicious) retry attempts; or, whether the retry applies to a very-low-level communication protocol like ethernet or a very-high-level software protocol like application-layer authentication.
 * To provide a little bit more concrete example of the tradeoffs: a system that enforces very strict back-off delays after failed attempts may be very robust against a brute force attack but is pathologically susceptible to a denial of service attack.
 * Nimur (talk) 18:12, 6 March 2017 (UTC)
 * That is why I don't volunteer for doing any security-related coding tasks at work. I set up a log-in that (among other things, including an IP blacklisting function) enforced a 5 second delay as part of a school exercise, and found that a single machine with a slightly clever IP spoofing set-up could effectively lock my site up indefinitely. I thought I was being clever, but it turned out to be just another reminder that Dunning-Kruger make no exceptions. ᛗᛁᛟᛚᚾᛁᚱPants   Tell me all about it.  18:59, 6 March 2017 (UTC)


 * All implementations that I've worked with base the delay on the user account, not the client. You try to login as "alice" and fail, it gets a 1 second delay attached to that account regardless of who tries to use it. Fail again and it is 2 seconds, then 4, then 8, then 16, then 32... Once a successful login happens, the delay goes back to zero. Therefore, a distributed attempt will only be useful if the server is highly threaded and you can get multiple login attempts with the same delay value. 209.149.113.5 (talk) 13:23, 7 March 2017 (UTC)
 * The anecdote I related was a school project. I thought it would be clever to stop a computer from trying the same password (such as password123) with multiple accounts. Again, the punchline is that I made the system highly vulnerable to a DDOS by being clever. The moral of the story was that when it comes to IT security, you shouldn't try to be clever unless you know what you're doing to begin with. ᛗᛁᛟᛚᚾᛁᚱPants   Tell me all about it.  15:27, 7 March 2017 (UTC)


 * Because timeouts are used extensively in software development, using the word "timeout" to indicate a time in which a person cannot login seems reasonable. On the programming and database side, I often see it labeled as a timeout variable or a timeout column in the database. I remember it because when I see "timeout", I think of giving a child a timeout and mentally see the computer telling the hacker: You need a timeout. 209.149.113.5 (talk) 20:53, 6 March 2017 (UTC)


 * I went digging into the source code for a few common modules related to "logging in on the command-line": login, implemented in GNU glibc-2.25 and Apple's BSD layer. I couldn't find any delays or delay enforcement logic!
 * But I did find pam_fail_delay in libpam for Linux, (and libpam-32.1, an open-source fork distributed with macOS). If you aren't familiar, PAM is the standard that you're probably using every time you authenticate to a Linux or Unix system or even if you build your own open-source Unix system from Apple-distributed source code.  This is the software library that does the real hard work of authentication; login itself just plumbs the sessions together.
 * Surely, if you go digging through the application-layer source code for other common use-cases like the login through your favorite SSH server, you'll find similar separation of concerns.
 * So if we want to get really technical, for many of the POSIX-ish systems you find in the real world, there's no delay after a failed login. There's a delay after a failed authentication.  The distinction is subtle but important - you might be using a computer system where authentication never involves typing on a teletype!
 * Nimur (talk) 01:49, 7 March 2017 (UTC)

Cellular automata maze generation
As we all know, among the 262144 possible Life-like cellular automaton rules, quite a few produce mazes. Among these, two are particularly well known, and are even named: Maze (B3/S12345) and Mazectric (B3/S1234). These are mentioned every time you talk about CA mazes. (See, for instance, Maze_generation_algorithm, and . There are also a few named variants of these, like "Electrified maze" and "Maze with mice".) My question is why these two were originally chosen as examples of maze-generating rules.

What really makes my wonder is the fact that there are -- in my opinion -- better examples of maze-generating Life-like rules, like B2/S123 [in fact, probably every one of these: B2(7)(8)/S(0)123(5)(6)(7)(8)]. As I discuss on my website, both Maze and Mazectric produce extremely disconnected mazes, if you interpret the live cells as the walls. If you interpret the dead cells as the walls, Maze gets a bit better, while Mazectric doesn't improve. Still, even the "improved" Maze is highly disconnected. On the other hand, B2/S123 and her friends produce one huge connected component and only a small number of tiny other components.

Does anyone know the history behind these CAs? In addition, what was the original interpretation of the living/dead cells? Walls or corridors? --Andreas Rejbrand (talk) 20:21, 6 March 2017 (UTC)

How do spammers know when an address is active?
Over the past several years, I've moved between a few institutions, and used respective email addresses to varying degrees. Right now I have three academic email addresses, call them A, B, C. A is new, and I get sciencey spam there on a near daily basis (e.g. "Less bias for your RNA-seq experiments!"). Address C I've had for ~5 years. When it was new and actively used, I got plenty of spam, but now, I almost never use it, and almost never get spam. Account B is in the middle, both by usage and by spam. It certainly seems there is a pattern at play. My question is: how do spammers know that an account is active vs. inactive? I suspect I could be wrong, and I haven't kept careful usage stats, but over time this pattern seems to have become stronger. None of the addresses is posted in any especially prominent place, though all are technically available through institutional directories. I thought I understood the basics of how email worked, and that it ruled out easy ways to see if someone uses an account more or less regularly, but maybe not... Thanks for any insight, SemanticMantis (talk) 20:25, 6 March 2017 (UTC)


 * What you likely do not see is the levels of spam filters that email goes through before you receive it. For example, GMail does a lot of filtering. Most businesses do some filtering. Even programs, such as Thunderbird, do filtering. Over the years, the filters can change. So, address B may have become more heavily filtered over the years and it is just coincidental that you don't use it much. 209.149.113.5 (talk) 20:45, 6 March 2017 (UTC)
 * None of these are gmail. I do see at least two levels of filtering, I get "spam control:end user digest" messages from two of the three (B, C). Also I have my apple Mail app shows me the messages it has marked as spam (though of course some spam makes it through both). To clarify: email account C got a LOT of stuff caught in the filter when it was new/active, and now there isn't any even in the filter. I strongly suspect B, C use the same filtering. SemanticMantis (talk) 22:06, 6 March 2017 (UTC)


 * You may yourself give the information to spammers if you open the spam. There are techniques, known as Email tracking, that allow the sender to know when the message is displayed at the receiver's device – see e.g. Web beacon. --CiaPan (talk) 21:06, 6 March 2017 (UTC)
 * So that can indicate that my mail.app basically marked the message as "read"? I don't click on any web links anything. Also, the "unused" account is not used to receive or send "real" emails, but the spam that got through the filters was still being clicked on by me, enough to be marked as "read" and perhaps have a 1x1 gif loaded before I can delete. Anyway, this is the best lead yet, so thanks! SemanticMantis (talk) 22:11, 6 March 2017 (UTC)


 * That's correct – simply opening (displaying) a message is enough. If it's a multimedia message, for example it contains some images embedded, which are not actually included inside the message but rather referenced with an external URL pointing at some web server, then the owner of the referenced site will know when the image is fetched. If they prepare a unique URL for each message, then they know who (which recipient) has opened their message – that is, which recipient e-mail address is active. That's why most e-mail client programs allow blocking externally linked images. And it doesn't need to be a transparent 1-by-1 pixel GIF; it may as well be an image of some device they offer you or their logo or the message background, etc.
 * Similary the HTML content may refer external definitions, e.g. CSS files, which makes exactly the same possibility of mail tracking. That's why email clients offer rendering just a simple HTML or blocking HTML at all. --CiaPan (talk) 22:53, 6 March 2017 (UTC)
 * Thunderbird, at least, allows you block remote content, so even if the email has hidden gifs etc., you can safely read the rest of the message. It's a setting under Options -> Privacy -> Allow remote content.  CodeTalker (talk) 01:44, 7 March 2017 (UTC)


 * Yes, that was what I was about to say.--Aspro (talk) 21:09, 6 March 2017 (UTC)


 * I don't want to make anyone paranoid, but one of my fellow students worked in the IT department when I was in college, and he was offered money to put spyware on the email server that did nothing but track the creation of new email addresses and (from what I could tell when we played with it instead of installing it) the frequency with which they were used. He was told by the person who made him the offer that it was not malware, just an advertising tool. He refused, but I pretty much guarantee that there's a student out there somewhere who didn't. That being said, I consider that pretty unlikely to be your answer, as it's a lot of risk for not a lot of reward. Just figured I'd throw it out there. ᛗᛁᛟᛚᚾᛁᚱPants   Tell me all about it.  22:54, 6 March 2017 (UTC)


 * See Email address harvesting for some of the methods used to get emails. Old emails do tend to go out of use so addresses which have been more recently verified are used preferentially. Dmcq (talk) 23:49, 6 March 2017 (UTC)