But it is what it is, not much we can individually do about the law.
But we can choose our hosting platforms and there seems to be variation in how hosting platforms handle DMCA takedown requests they receive.
Some, like Heroku, still give notice and have AFAIK a 24 hour cure period and document a counter-claim process. At least that was my fairly positive Heroku experience a couple years ago when a bad-actor competitor filed a provably fraudulent DMCA takedown on Friday night. (We presume they hoped we would not see any notifications until Monday by which time the cure/respond period would have elapsed and our site would have been taken down.)
But others including Render - based on a few posts in their community forum - apparently will take sites down without notice in response to a DMCA takedown request. (Easier/cheaper for the host, no doubt.)
Our year-long saga of suing a competitor (even with a very positive outcome) was still fresh in my mind when I was recently investigating hosting alternatives. So I'm possibly more attuned to this business risk than others. (Render is unfortunately out of consideration at this time for that reason.)
So I'm curious if anyone else explicitly considers DMCA handling policy when choosing a hosting platform, and if so, where did you land?
Turns out iDrive is blocking certain IPs used by my VPN (Mullvad)... no message, just a timeout. I switched to a different VPN location and it worked fine.
It seems to me that even if a bad actor has caused an IP address to get blocked, the right response would be some type of message (as opposed to a timeout).
Oops.
It would be 80% fails (406 status code in our logs) for an hour or two, then OK for an hour or two, then 100% fail again.
Sendgrid status page said no issues.
Sendgrid support said they could not see the rejects but they'd look into it.
We simply switched our traffic to our "other" ESP (Socketlabs, excellent IMO with far superior support) until we had time to dig into what was going on in Sendgridland..
On a hunch we tested what happened if our Heroku app used a static IP to send API requests to Sendgrid... and it worked 100% of the time. If we turn off the static IP it goes right back to high failures. Went back and forth a couple of times today with the same result.
IMO Sendgrid is pointlessly filtering IPs for apps that A) are using a secure APIKEY to submit API requests, and B) running on a cloud platform where they have no inherent control over shared IPs.
But, since Sendgrid appears to filter IPs, and doesn't seem to document the need for static IPs, and does NOT surface 406 errors in any Sendgrid dashboard where you OR their chat support can see them, I hope this info will someone else from chasing down the error. (And perhaps considering a ESP with much better support.)
That crucial consideration is: the health of un-vaccinated people around me. If there are people around me who will not be eligible for a vaccine for months, THEY seem to be better protected - from me - if I choose either of the two higher-efficacy vaccines (within a "reasonably short" incremental timeframe).
Based on the data we have so far it looks like I am about 5x more likely to get infected after J&J compared to Pfizer/Moderna, based on J&J's lower efficacy of about 75% vs 95%.
Even though J&J would protect ME from serious complications, if I get J&J and then get infected I am contagious, and therefore I am a risk to still-unvaccinated people around to me who still have normal risk for serious/fatal complication.
So if I can expect to have Moderna or Pfizer available within a "reasonably short" time frame, I'll wait for one of those higher-efficacy vaccines in order to better ALSO protect the unvaccinated people around me.
But the hard part is deciding what is a "reasonably short" timeframe? There is obviously a non-zero incremental risk from waiting, so that short-term risk (to me and mine) needs to be balanced against the longer-term risk (to others) from my rushing to accept a less efficacious vaccine sooner.
Using the current daily covid infection rate divided by the population as a rough, quick, back-of-envelope guesstimate for "incremental daily risk of infection" on the order of 0.015%.
Pretty big assumptions. But unless my reasoning is way off, I'll be willing to wait an extra 10-14 days for Pfizer/Moderna (vs J&J) with the goal of lower net risk to the unvaccinated people around me.
My test: use Carbon Copy Cloner v5.1.22 to clone an internal SSD with 690GB of data. “Find & replace corrupted files” is OFF*.
Source: Macbook Pro 16″, Catalina 10.15.7
Destination: 13" 2020 Intel MBP, Catalina 10.15.7, in Target Disk Mode, using a 40G Thunderbolt 3 cable.
Result: Direct-connect two MBP using a high-speed Thunderbolt-3 cable was 5.9 GB/minute, about half as fast as backing up via USB 3 to an SSD in an external drive dock (12 GB/minute).
Keep in mind that two “trips” are required if the goal is to move the data to a new Mac via an external SSD (first from source -> external SSD, then from external SSD -> target)… so when you add the time it also takes to restore the external SSD to the target Mac (which I did not measure), the net time difference between the two approaches is less.
For my purpose, simply cloning Mac#1 to Mac #2, the direct-connect using Target Disk Mode was simpler and adequately-fast. YMMV.
Might the Solarwinds hack conclusively disprove any such assertions (that the US government, if entrusted with encryption backdoors, is capable securing access to those backdoors)?
And how broad are the implications to the average American of such "keys" being stolen and widely disseminated?