I would assume the launch of the Switch successor is why they are clamping down. It's likely very similar architecturally to the Switch. Nobody knows how long it would take to hack it, someone could be silently sitting on an exploit that they've been saving to see if it'll work on the successor. In the event it's hacked quickly and there are still actively developed Switch emulators, it wouldn't be a stretch to believe support would quickly be added to those emulators for the successor.
Consider a scenario where you have a log file and in the log file is an IP address (172.217.5.14). You are not sure whose IP address it is. So you run the following commands:
# dig -x 172.217.5.14 +short
lga15s49-in-f14.1e100.net.
ord38s19-in-f14.1e100.net.
# dig lga15s49-in-f14.1e100.net. +short
172.217.5.14
# dig lga15s49-in-f14.1e100.net. +short
172.217.5.14
The first command (dig -x) checks the PTR record for the IP address 172.217.5.14. It returns two PTR records: lga15s49-in-f14.1e100.net. and ord38s19-in-f14.1e100.net.[0]. Those are subdomains of 1e100.net, which we know Google owns. However, you can set a PTR to pretty much whatever you want, so we now take an additional step as well. We run the dig command again to check the A records for the domains. This returns the same IP address we started with, which is good. Since Google controls the DNS for 1e100.net we can be reasonably sure that it is in fact a Google server. This is called Forward-confirmed reverse DNS (FCrDNS) and is one tool you can use to determine the ownership of an IP address. For example, it is frequently used as a weight in email spam filters. Although, because of the intricacies of email, in that case it is usually not used for identification and instead used as a general purpose check to determine whether a mail server is rogue or not, since spam servers very often do not have proper FCrDNS.
There are other tools to determine who owns an IP address, like whois, but in some instances one will garner useful information and the other will not. So it's nice to have both at your disposal.
[0] As a side note: the trailing . in those PTR records returned by dig is not a typo. All domains actually end in a dot, it's just usually implied.
> Those are subdomains of 1e100.net, which we know Google owns
Sorry but to the average user, the domain name 1e100.net doesn't ring a bell at all at this point. They would still have to look up the IP in ARIN/RIPE/etc to see that the IP range is effecively owned by a company called Google.
Do you really need a hostname at all? Wouldn't be the ARIN/RIPE/etc entry be sufficient to know who "owns" said IP address?
See, I probably would have reached for whois before dig. Partially because reverse DNS seems less likely to be populated with useful info, in my limited experience.
rDNS can be populated with a great deal of useful information, if you are trying to diagnose an asymmetric routing issue between two internet service providers. Particularly if both of them have had the forethought to give reasonable, understandable, hierarchical names to their globally distributed POPs. Other things like "ae" that show up in a traceroute can be indications of an 802.3ad aggregated link, which juniper calls an Aggregated Ethernet. Same as interface abbreviations for Cisco and juniper you will find like "hu", "te", "xe", etc.
One example: say you have a $200/mo dedicated server customer, as an ISP, you're giving them a /29 of public IP space. That /29 exists as a vlan subinterface of one of your juniper routers and is trunked across the datacenter through various switches to the server. Let's say it's vlan 2659. Somewhere in the public rDNS for the default gateway IP of that /29, you would have the string "vl2659”.
Visual changes are an easy feather-in-the-cap for both front-end developers and for management. A design overhaul is immediately obvious to everyone. It's something you can show off. It's something you can add eye-candy to. Changes like that are more glamorous than performance improvements. People that are trying to justify their position love to attach their name to those types of things.
There are already a plethora of fly-by-night Javascript frameworks. Outside of hobby projects, I'd wager that most people prefer not to use frameworks that lack an established track record. For a business, the cost of switching frameworks after the fact is simply too great. Unless the framework has a sizable userbase and has been around for a few years, I wouldn't use it in any serious projects. To get a large enough userbase that people will feel comfortable using it in serious projects, you're going to need them to use your framework in those hobby projects. However, those projects are the least likely to have a budget, and the most likely to utilize free resources. This is why I do not think a commercial framework can succeed.
Not a whole lot. The fastest CPUs will net you less than 100 MH/s [0]. The fastest single-card GPU configurations will net you around 1,000 MH/s [0]. The current total hash rate is around 5,000,000,000,000 MH/s [1]. WannaCry affected around 300,000 PCs [2]. So if every WannaCry miner was operating off CPU and getting 100 MH/s, it would only be 30,000,000 MH/s. Or 0.0006% of the current total hash rate. If they all had high-end GPUs getting them 1,000 MH/s then that would bring it up to 300,000,000 MH/s. Or 0.006% of the current total hash rate. So WannaCry wouldn't even be a drop in the bucket. If you're wondering how the hash rate is so high, it's because mining has switched to using ASICs, the fastest of which run around 14,000,000 MH/s [3].
You could try an all-in-one solution like iRedMail[0] or Mail-in-a-Box[1]. Those supposedly do most of the leg work for you and set up a commonly used stack (Postfix, Dovecot, SpamAssassin, Roundcube, etc). I've never used either of them since I just install everything piecemeal, but I imagine there is an ease of use tradeoff compared to setting the same stack up yourself. In other words, it'll be easier to set up initially, but the downside is that you wont learn the ins and outs of the individual components. So if something breaks or you need to make an adjustment you're going to have a more difficult time at that point.
That said, there are some things you should be aware of when running a mail server:
1. You need to make sure that the IP address and domain name that SMTP is bound to is not on a blacklist[2]. You also need to consider the trustworthiness of your host because you could very well get caught in the cross-fire if one of their other customers gets them range banned. Certain cloud providers that make it very easy to change IP will more than likely have all of their addresses on some blacklist or another.
2. You also need to make sure you have matching forward (A record) and reverse (PTR record) DNS records for that IP address. This is called Forward-confirmed reverse DNS, aka FCrDNS. Many mail servers will reject email from servers that do not have or have mismatching records for FCrDNS.
3. You must set up SPF and DKIM. Many mail servers will either reject mail from servers without these, or at least weight heavily against it.
4. You probably want to make sure TLS is set up properly, otherwise your mail is going to travel the internet in plaintext.
5. The IP address you're sending from is going to start off with no reputation. The volume, type of mail, and how many people mark your mail as spam is going to decide whether other mail servers start filtering you or not. You may have no problems here. If you're unlucky, you will need to try to reach out to whichever major mail provider is filtering your mail. Many of them have a ticketing system for this, but you'll be at the mercy of whomever is working that ticket. There are also various whitelists that might be worth trying your server on. They're usually very selective and will probably reject your request.
6. You really, really need to make sure you've got your policies set up correctly because you do not want to accidentally set up an open relay[3] that will be used to spam other people.
7. Greylisting is a very, very effective means of spam filtering. The downside is that mail from new servers wont be delivered instantaneously and will instead be delivered whenever their mail server tries to deliver it again. Other than that, most spam is malformed in some way so some basic DNS checks will filter a ton of it. There are also free RBL and DNSBL lists that will pick up the slack.
To be honest, if he was that disoriented it sounds like your dad should have been calling 911 and not Uber. I have no idea how you could expect anything short of an ambulance with trained medical personnel to provide the requisite support that a mentally incapacitated cancer patient may require.
It might be better to ask what you had expected the outcome in this scenario to be?
Consider the three most common authentication factors:
* Something you know
* Something you have
* Something you are
A conventional password-based login implements "something you know" (i.e. your password). A password-less login implements "something you have" (e.g. email access). That doesn't make it more secure, it's just substituting one authentication factor for another. One could argue that it's more convenient but that's subjective since people that use password lockers might actually find it less convenient.
An argument against password-less logins might be that they should be implementing multi-factor authentication in the first place. Password-less login is by nature not at least two-factor authentication. Even if you have two-factor authentication enabled for your email, it will still just be "something you have" because someone that gains access to your PC or phone will probably have access to your email as well. The easiest second factor to add into the mix is "something you know" (e.g. a password) and now you're back to conventional two-factor authentication practices.
I disagree. I think Microsoft's current driver policies are unreasonable. Most end-users don't want to run their PC in testing mode, and will look for an easier way around it. This has a negative effect on free and open-source software. For example, there is software out there that allows you to use Playstation 3 controllers with your PC. In the past, there were pretty much two software solutions for Windows. One driver was unsigned, and the other was signed. Many people used the latter because it was much easier to get working. The problem is that it also installed alongside Chinese malware. Driver signing didn't save anyone there. If anything, it made the issue worse.
It doesn't cost $1000 even today, and as EV Code Signing certificates become more popular the price will fall.
A non-Code Signing EV certificate is "only" $100-200 right now from tons of vendors. All we need is for them to flag it for Code Signing which is "free."
Until you convince those CAs to start signing for code, they still cost $400+. And remember, that's per year. The driver will continue to function after that year, but they will either need to cough up another $400 the next year, or cease development. Even at $100-200 per year that's still an unreasonable cost for hobby projects.
Open source software of any complexity costs far more than that to develop, assuming you assign non-zero value to opportunity cost. Your time is valuable!
So your complaint as far as I can understand it is - both solutions are imperfect. Well, great ! I do think you're conflating 'reasonable' with 'perfect'.
Actually, my complaint is that if you go through the effort of manually disabling driver verification checks at boot time, Microsoft should respect your decision and allow you to persist that decision for that driver, even if you reboot and turn verification back on. They don't, and instead give you an all or nothing approach, with the nothing approach being a hassle and leaving a permanent watermark in the bottom right corner of your display.
> Microsoft should respect your decision and allow you to persist that decision for that driver, even if you reboot and turn verification back on.
If you have a whitelist, then malware authors would ship a primary driver that is signed and "clean". This clean driver just changes the whitelist so other malware can be executed without signature checks. I would suggest you first model the threat, model your response and analyze the different approaches.
