pardner

As discussed in quite a few HN threads, I agree with what seems to be the consensus that DMCA is a mess, ripe for bad actors. And, as discussed often, recourse against bad actors who file purposefully fraudulent takedowns is hard to attain due to the wording of 512(f) which at a superficial glance allows for damages but which requires proving in court not only that the infringement claim is false, but that the claimant knew it was false. (Not "should have known", not "reasonably would have known", but "actually knew-in-their-hearts knew".)

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?

Backup failed and attempts to reach the website timed out. Everything else worked fine, even Google worked without popping up a captcha.

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).

Anyone else get the email today from HBOMax@mail.hbomax.com (mail headers match), with subject "Integration Test Email #1", and message "This template is used by integration tests only"

Oops.

The past few days we started seeing a high (but intermittent) percentage of failed email sends using Sendgrid.

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.)

It seems to me that the official recommendation "the best vaccine is the one they offer you first" ignores one crucial consideration that might make a better decision for some individuals to be "skip the J&J if I can get Pfizer/Moderna by waiting a 'reasonably short' time".

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.

TL;DR Formerly unusably-slow for backups a few years ago, the built-in Target Disk Mode in Macs has actually improved in latter-day Intel models (using a Thunderbolt 3 cable), now nearly 1/2 as fast as an external USB-C drive dock.

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.

Each attempt by the US government to weaken encryption with backdoors seems to teeter upon a pivotal assertion that the government can be trusted with such "keys". Forever. The Lawful Access to Encrypted Data Act introduced by Senators Graham, Blackburn, and Cotton, for example.

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?

When designing a internal CRM we incorporated a few extra features such always displaying link addresses (mailto and url), which works so well at making the majority of phfishing emails so obvious I just cringe every time I use IOS Mail.

Which got me to wondering if IOS Mail's refusal to add a setting to display the sender's email address right in the inbox might actually be a leading cause of successful phfishing attacks... If you can see right in your inbox that "xyz.abc@def.jp" is claiming to be "Rackspace Support" and was the sender of "Important notice regarding your Rackspace account" there is NO need to open or interact with the obviously fake email... wipe left and be done with it.

But Apple (and other clients) continues to not only hide that important info by default, but does not provide an option to display it in the inbox. (Even Apple's Mac Mail client development team has made some ill-informed decisions in this regard.)

Of course, an IOS user CAN see the sender's email... after they OPEN the email, TAP the sender name, then TAP it again. For every message. Explain THAT to your grandparents.

I suspect the extra steps mean it only gets used by more sophisticated users who sniff something pfishy about the email itself. Not the people who need it most.

It seems to me that any responsible email client provider ought to recognize the importance of the sending email address as a first line of defense against the simpler attacks such as the example above.

IMO a 2nd line of defense email clients ought to add is link-expanders too. For example in our system if the link label includes "homedepot.com" but the actual url is not a homedepot.com url we expand it to look something like "NOTICE: see more at www.homedepot.com LINKS TO xyz.abc@def.jp" right in the email and remove the active link.

Link expansion makes pretty marketing emails look not-so-pretty.

It also makes the most common bad-guy emails we see stick out like a sore thumb.

On Oct 23 My MBP 16" died while being used, and showed no signs of life, 9 months into the Applecare warranty period.

Apple confirmed receipt on Oct 29.

Since then the repair status page has said "Our technicians are inspecting your product to diagnose the issue"

Chat support and phone support say they can obtain no additional info about the repair status (such as "have they evenopend the case yet?")

Nor would Apple support give ANY indication of expected turnaround time, although Apple certainly knows what their backlog and repair throughput.

Given glopbal circumstances Apple's complete absence of transparency is more irritating than the delay. (For example if it is "months" some users like startup CTOs might actually opt to buy a new laptop then resell the old one once it finally comes back.)

Has anyone else recently submitted a MBP for repair under AppleCare, and if so what sort of turnaround time did you experience?