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

I wish I had a dollar for every time I heard a manager complain, “The HR department included ‘must have college degree’ in the job req even though I don’t care” or “They asked for 5 years of experience in a technology that’s only been around for 3” or “I have no idea why they rejected this candidate without even contacting me.”

Still, in many cases you don’t have a choice. If you want to hire someone, you need to deal with HR, at least to a small degree – especially if you work in a big company.

So I’m writing a feature story for technology managers, collecting real-world advice from people who learned their lessons the hard way. Here’s the questions I’d like you to answer:

• Tell me about a frustration you had with the HR department (in regard to hiring). That is, tell me a personal story of HR-gone-wrong. Because we all love schadenfreude, and that gives me an emotional example with which to begin.
• Let’s say you have a new opening in your department. In what ways do you involve HR? (That could be anything from, “give them general guidelines and let them choose the best candidates for me to interview” to “I do the search myself, and use HR only for on-boarding.”) What makes you choose that path? How much choice do you have in the matter?
• What weaknesses have you discovered in your HR department’s ability to serve the needs of a tech-focused department?
• What have you done to cope with those weaknesses? Which of those efforts worked, and which failed?
• What do you wish you knew “n” years ago about dealing with your company’s HR department?
• So that I can give the reader some context: Let me know how to refer to you in the article (at least, “Esther, a software architect at a Midwest insurance company”), and give me some idea of your company size (because the processes appropriate for a 70-person company aren’t the same for one with 7,000 employees).

You don’t have to answer all those questions! I asked these to get the conversation going. Tell me as much or as little as you like.

Please don’t assume that I think HR always sucks. However, there isn’t as much to learn from “why HR is your friend.” The idea here is to help techie managers cope when HR doesn’t offer what you hoped for.

Docker recently made it so that it requires you to have an account on Docker Hub in order to download the Docker Desktop Installer. So, here's the links:

https://download.docker.com/win/stable/Docker%20for%20Windows%20Installer.exe

https://download.docker.com/mac/stable/Docker.dmg

In the rare chance you haven't heard of Flutter, here's the link: https://flutter.io

Flutter just officially left beta with v1.0 December 4, last year. The code is written in Dart, and deploys on Android, and iOS (and will run natively on the rumored Fuchsia OS).

So for those of you that have used Flutter or are currently using Flutter.

• What are you working on?
• Why'd you choose Flutter?
• What do you like about Flutter?
• And what do you dislike about Flutter?

I'll start:

I'm working on a niche art app. I myself do not do that type of art, but knowing people that do, I wanted to create a tool to fill in the lackluckster market for Chromebooks and Android.
I chose Flutter because:

• I wanted to try something new, and what newer than something that was (at the time) in beta?
• Custom Views in Android are a hassle.
• I will be able to release on both Android and iOS (semi-)natively without having to code it twice.

Here's what I like about Flutter:

• Layouts are really simple.
  (though you can easily let it get clustered if you don't think too much about it.)
• Design isn't an afterthought.
  Animations are built in (and simple), themes aren't hard-coded, and Material Components get more attention here. (Still waiting for Shapes on Android)
• It's fast by design.
  Flutter uses its own custom rendering engine (Skia). I've never experienced any stutter with the built-in components, and when I caused lag (with heavy I/O) Flutter/Dart had tools in place for me to narrow down exactly what was causing it.

What I don't like about Flutter:

• It has poor mouse/trackpad support.
  Right clicks, not a thing. I can workaround this with a double-click/long-click, but for a desktop OS, this isn't optimal. Scrolling, that's panning, this should be differentiated. There's a difference between using a scrollwheel and moving finger around on the screen. According to Flutter there is not. There's also currently no support for mouse hovers which I have needed very much.
  There is a pull-request for adding support for all of these, but the developer hasn't done anything since code review.
• Keyboard support, while there, is lackluster.
  Ctrl, Shift, Alt. These have to be gotten with the meta code. There's no built-in function for checking those. Text fields don't support the tab key to navigate. And text formatting (bold, italic, etc.) isn't possible with text fields without the use of a library (or making it yourself).

I was trying to think of a third dislike, but I can't. My complaints are on missing APIs for Chromebooks. That's it. I really like Flutter, I plan on using it more, and if they won't add support for mouse/keyboard, maybe I'll have to contribute.

I'd love to hear what your thoughts about it is.