One of the people in an IRC channel I frequent pointed out a site I've been building uses CDNs that are IPv4 only. I never realized this, I just assumed every major provider had deployed IPv6. Oh, how very wrong I was. A quick check of some major (to me) sites shows a shocking lack of IPv6, including:

• Bootstrap (stackpath.bootstrapcdn.com)
• Discord
• FontAwesome (use.fontawesome.com)
• GitHub/GitHub pages
• GitLab/GitLab pages (self-hosted supports IPv6, but officially hosted GitLab only supports IPv4 due to Azure limitations)
• jQuery, IF you use code.jquery.com (some tutorials use ajax.googleapis.com, which does have IPv6, but an unfortunate amount use code.jquery.com, including the getting started page for Bootstrap)
• Parts of Amazon/AWS (Amazon is IPv4 only, some of AWS is IPv4 only, including S3)
• Reddit
• Stack Overflow/Exchange/etc
• Twitter

An honorable mention goes to Angular's websites because the websites themselves are IPv4 only but the libraries are hosted on ajax.googleapis.com, which is IPv6 accessible. I checked npm, PyPI, RubyGems, and Tildes, and they all support IPv6.

I can understand why companies like Amazon have partial support (upgrading can be a PITA if you're a cloud service provider with uptime requirements), but then you have services like Discord (launched in 2015 with no obligation to maintain service) that only support IPv4. At the very least, I'd expect CDNs referenced by thousands (if not millions) of webpages to be on IPv6 by now.

Am I missing something? CDNs are pretty static, it's just a matter of choosing one that supports IPv6, you don't even need to update your application if you just change the DNS entries.

There seems to be a trend lately of people switching over to BSD operating systems. Having read some blog posts on the matter and now given the recent system-d controversy, I'm genuinely curious to give FreeBSD or OpenBSD a go as my main OS.

For those who have switched over to BSD, what are some problems you've encountered and/or what are some things you miss?

I just received a mail from my own e-mail address, hosted on Gandi on my own domain name. It said that the sender has hacked me, used malware, keyloggers and RDP to get my passwords and copy all my files to his own computer, and took videos of me while watching adult content using my webcam (I never noticed the light turning on for it). Claims they've been doing this for a few months. Gives a bitcoin address and wants $1000 (a sum I can't and won't give, don't even have a fraction of it) in 48 hrs, or else will share the videos with my contacts. It said something about a pixel the message included.

I viewed the message from K-9 mail on android (which didn't tell anything about pixels or whatnot), and when I went back on my computer to check the headers and stuff, the message was deleted.

Now, is this some sort of phishing or or have I really been pwned? I feel like it's just phishing, but the message deleting itself kinda gave me shills of fear. I promptly changed my password for the mail account.

Today I configured an onion service and it was like 10 minutes job, very easy and I now have my hidden service up and running. Have you configured an onion service, if so then for what?

Simple Steps

• Install nginx (or any other web server), tor

• Configure nginx

• Add few lines in torrc

• Done!

I don't know what is the correct word in English, but I'll be one of those guys who will teach a "class" consisting on answering questions and guiding them through the exercises.

The content is very basic algorithms in C, so things like functions, pointers, and structs are off the scope. Here is the repo I made with the solutions for last semester. I'm starting in the second semester, so I have everything fresh in my memory.

I welcome anything you can give but I'm not necessarily seeking technical advice since the teachers have that covered. What I'd really like to know is what you consider to be some good examples, attitudes, and approaches for this particular position. Thanks.

Recently, Ian Lance Taylor, one of the most productive contributors to Go and, IIRC, the original author of gccgo, has written a very interesting comment on his view of the language:

(…) Go intentionally has a weak type system, and there are many restrictions that can be expressed in other languages but cannot be expressed in Go. Go in general encourages programming by writing code rather than programming by writing types. (…)

I found this distinction, writing code vs. writing types, very insightful. In my experience, in a language like Rust or (modern fancy) C++ the programmer is constantly forced to think about types, while when I program in Go or C, I almost never think about them. Types are, in fact, almost always obvious. It is also interesting that languages like Haskell and Idris explicitly expect the programmer to program with types.

What do you think?

I was a bit worried about the future of Google Voice with the demise of Hangouts, but I got an email from GSuite about classic Hangouts today, which linked to this support page. Coming to Hangouts Chat are:

• Enhanced video calling experience

• Google Voice integration

I included the video calling line because I thought it was a bit odd for Chat to have that - I thought that's what Hangouts Meet was for (though it certainly wouldn't be the first case of Google making a redundant product). In any case, if Chat is going to have video calling, it's not much of a stretch to assume it'll also have voice calling for Google Voice, in addition to SMS/MMS.

Self-post instead of a link post because I want to highlight just 2 bullet points in the support page that wouldn't be obvious if I just linked the page. I wasn't sure if this should go in ~tech or ~comp, but ~comp seems to have more non-link discussion than ~tech.

Edit: Somewhat related, I found a news article about the Google Voice 5.7 update. They've created some interesting Google Calendar integrations, which makes sense since Voice will be available in GSuite this March.

Preface

Software security is one of those subjects that often gets overlooked, both in academia and in professional projects, unless you're specifically working with some existing security-related element (e.g. you're taking a course on security basics, or updating your password hashing algorithm). As a result, we frequently see stories of rather catastrophic data leaks from otherwise reputable businesses, leaks which should have been entirely preventable with even the most basic of safeguards in place.

With that in mind, I thought I would switch things up and discuss something security-related this time.

Background

It's commonplace for complex software systems to avoid unnecessarily large expenses, especially in terms of technical debt and the capital involved in the initial development costs of building entire systems for e.g. geolocation or financial transactions. Instead of reinventing the wheel and effectively building a parallel business, we instead integrate with existing third-party systems, typically by using an API.

The problem, however, is that sometimes these third-party systems process requests over a long period of time, potentially on the order of minutes, hours, days, or even longer. If, for example, you have users who want to purchase something using your online platform, then it's not a particularly good idea to having potentially thousands of open connections to that third-party system all sitting there waiting multiple business days for funds to clear. That would just be stupid. So, how do we handle this in a way that isn't incredibly stupid?

There are two commonly accepted methods to avoid having to wait around:

1. We can periodically contact the third-party system and ask for the current status of a request, or
2. We can give the third-party system a way to contact us and let us know when they're finished with a request.

Both of these methods work, but obviously there will be a potentially significant delay in #1 between when a request finishes and when we know that it has finished (with a maximum delay of the wait time between status updates), whereas in #2 that delay is practically non-existent. Using #1 is also incredibly inefficient due to the number of wasted status update requests, whereas #2 allows us to avoid that kind of waste. Clearly #2 seems like the ideal option.

Method #2 is what we call a webhook.

May I see your ID?

The problem with webhooks is that when you're implementing one, it's far too easy to forget that you need to restrict access to it. After all, that third-party system isn't a user, right? They're not a human. They can't just give us a username and password like we want them to. They don't understand the specific requirements for our individual, custom-designed system.

But what happens if some malicious actor figures out what the webhook endpoint is? Let's say that all we do is log webhook requests somewhere in a non-capped file or database table/collection. Barring all other possible attack vectors, we suddenly find ourselves susceptible to that malicious actor sending us thousands, possibly millions of fraudulent data payloads in a small amount of time thanks to a botnet, and now our server's I/O utilization is spiking and the entire system is grinding to a halt--we're experiencing a DDoS!

We don't want just anyone to be able to talk to our webhook. We want to make sure that anyone who does is verified and trusted. But since we can't require a username and password, since we can't guarantee that the third-party system will even know how to make use of them, what can we do?

The answer is to use some form of token-based authentication--we generate a unique token, kind of like an ID card, and we attach it to our webhook endpoint (e.g. https://example.com/my_webhook/{unique_token}). We can then check that token for validity every time someone touches our webhook, ensuring that only someone we trust can get in.

Class is in Session

Just as there are two commonly accepted models for how to handle receiving updates from third-party systems, there are also two common models for how to assign a webhook to those systems:

1. Hard-coding the webhook in your account settings, or
2. Passing a webhook as part of request payload.

Model #1 is, in my experience, the most common of the two. In this model, our authentication token is typically directly linked to some user or user-like object in our system. This token is intended to be persisted and reused indefinitely, only scrapped in the event of a breach or a termination of integration with the service that uses it. Unfortunately, if the token is present within the URL, it's possible for your token to be viewed in plaintext in your logs.

In model #2, it's perfectly feasible to mirror the behavior of model #1 by simply passing the same webhook endpoint with the same token in every new request; however, there is a far better solution. We can, instead, generate a brand new token for each new request to the third-party system, and each new token can be associated with the request itself on our own system. Rather than only validating the token itself, we then validate that the token and the request it's supposed to be associated with are both valid. This ensures that even in the event of a breach, a leaked authentication token's extent of damage is limited only to the domain of the request it's associated with! In addition, we can automatically expire these tokens after receiving a certain number of requests, ensuring that a DDoS using a single valid token and request payload isn't possible. As with model #1, however, we still run into problems of token exposure if the token is present in the URL.

Model #2 treats each individual authentication token not as a session for an entire third-party system, but as a session for a single request on that system. These per-request session tokens require greater effort to implement, but are inherently safer due to the increased granularity of our authentication and our flexibility in allowing ourselves to expire the tokens at will.

Final Thoughts

Security is hard. Even with per-request session tokens, webhooks still aren't as secure as we might like them to be. Some systems allow us to define tokens that will be inserted into the request payload, but more often than not you'll find that only a webhook URL is possible to specify. Ideally we would stuff those tokens right into the POST request payload for all of our third-party systems so they would never be so easily exposed in plaintext in log files, but legacy systems tend to be slow to catch up and newer systems often don't have developers with the security background to consider it.

Still, as far as securing webhooks goes, having some sort of cryptographically secure authentication token is far better than leaving the door wide open for any script kiddie having a bad day to waltz right in and set the whole place on fire. If you're integrating with any third-party system, your job isn't to make it impossible for them to get their hands on a key, but to make it really difficult and to make sure you don't leave any gasoline lying around in case they do.

I was using Antergos for like 15 days and I really loved it! Not Antergos but Arch, I like how simple everything is in arch. Before installing antergos I tried to install arch on vm but failed. so i installed antergos with i3wm. somewhere i wanted to install vanilla arch.

Initially I was referring to the wiki with elinks and doing it carefully but failed. my setup was going to be arch + grub + luks, for some reason grub didn't show up while booting. i also encountered other error which made grub-mkconfig to hang. later i decided to drop luks so arch + grub, but again same error.

i've used debian family distros for a long time and grub was the most used bootloader so i wanted to install that. next i looked for a guide online and followed another guide which had same commands as arch wiki. again that failed.

after some more searching i found archfi, so basically it is a script that will ask me questions and install everything. again that grub thing failed so i went with systemd for the second time with this script. & voila!

later i used archdi to setup lightdm-gtk-greeter and installed i3wm.

i didn't install it myself but i am happy with my arch and probably someday would do it myself.

btw, i use arch