darkhelmet

The tech behind SMR is intriguing to me, but I really don't want it anywhere near data that I consider important.

A lot of folks don't realize that SMR drives have a lot more in common with SSD firmware with its emulated virtual block layer and wear leveling than a traditional HDD. Having the same kind of virtual block layer is where the problems come from.

With SSDs, virtual blocks stored in pages that are about to be erased have to be relocated elsewhere. SMR drives have to do the same sort of thing but with sequential recording for the overlapping tracks. All the same nightmares exist including garbage collection/reclaimation, de-fragmentation, managing TRIM (or parsing NTFS data structures), etc etc. With SMR, handling the worst case scenarios are made more difficult by seek latency - something that isn't as much of an issue for SSD storage.

All of this tends to invalidate cherished assumptions that unix/linux file systems make about HDD storage. And that's ignoring the issues about the devices reaching timeout thresholds - again, the kinds of things that Windows is OK with but really hurts linux/unix systems.

Ever noticed that Epic does a ``good deed'' right about when they get a bad PR hit?

Call me cynical, but I'm sure that Epic would really like for everybody to talk about something else than the quarter of a billion dollar penalty they just got from the FTC for exploiting children etc.

The very same Epic that would really, really like to be able to bypass any kind of app store safeguards and review processes, no matter how flawed and self-serving those processes might be.

Yep, it does seem like it's time for a few warm fuzzy PR events to get people's attention diverted.

/cynic mode off

Likewise. I've always insisted on building from in-house copies of external dependencies for precisely this kind of scenario. It astonishes me the number of people who didn't get why. Having things like docker rate-limiting/shutdowns, regular supply chain attacks, etc has been helping though.

Slightly related: actually knowing for sure that you've got a handle on all of the external dependencies is sometimes harder than it should be. Building in an environment with no outbound network access turns up all sorts of terrible things - far more often than it should. The kind that worry me are supposedly self-contained packages that internally do a bunch of "curl | sudo bash" type processing in their pre/post-install scripts. Those are good to know about before it is too late.

Think about it from the point of view of a manufacturer/distributor. Speculating a little:

Suppose you decided to carry them and they cost more, both from a material perspective and a reduced repeat customer perspective. Cheap competitors in stores won't just go away and they'll be on shelves next to them. Brand recognition and/or loyalty will only go so far and way too many people will prefer the cheaper cost. So the manufacturer/distributor have to provide both or risk losing sales. Now there's an extra sku in the mix and I'd wager that even with brand recognition the cheaper ones will outsell the Dubai ones, which makes the distribution overheads even more unpalatable. And so on.

I'm sure they've done their research and it doesn't add up from a business sense. It works in Dubai because the regulations eliminate part of the race to zero.

Even selling them directly online is problematic because of distributor territory, exclusivity etc. If the manufacturer competes with its distributor network (that they rely on) then that doesn't end well either.

I doubt it's any sort of conspiracy by 'big led' to keep you from buying them, but is more to do with mundane and unfortunate things like above.

I still want them though.

Don't underestimate the value of checking all the security compliance check boxes. It solves what really matters - protecting executives from prosecution and/or being dragged in front of Congress to testify. <sarcasm off>

Seriously though, so long as cybersecurity insurance and "industry best practices checkbox management" is easier and/or cheaper than actual meaningful security measures, it will never be solved.

Worse, when a meaningful security measure that could actually make a difference collides with something in a best practices document, you know who will lose.

I'm not cynical at this point, no...

Tip: You can bulk export your google authenticator app secrets for a disaster recovery like this. I had not seen this functionality before but I'm glad it existed when setting up a new phone yesterday. I remember the old high friction way of having to deregister and reregister for each account.

Howto:

  ... menu in top right -> export accounts
  make sure all are selected, select export
  It will generate a series of dense QR codes.
  Screenshot / photograph / add to backup phone, save and print for your document safe, whatever.

Of course, this doesn't help if you're already in a loss situation. But recovery this way is SO much easier than typing in a backup code. Recovery is as quick as having the app scan each of the QR codes in sequence. For me it was just 3 dense QR codes.

I was a little surprised that it was this easy to extract all the secrets. I'm going to have to think even more carefully about what TOTP secrets go in there now.

It seems to be increasingly widespread and is not just the Music/iTunes ecosystem.

For example, the Home app and HomeKit situation is also unreliable. People's devices suddenly disappear from their Home app on bigger installations. You have to delete the entire thing and start over and go and find all the barcodes again. There's a well known workaround for setting up Home Assistant, moving all your devices to its control and having it export to your HomeKit. People hate doing this but it's been one of the reliable ways of stopping this from happening in larger setups.

Also in the HomeKit area, synchronization of voice recognition for personal requests in a multi-person house is extremely fragile. It works for many people, but sometimes it just doesn't. It is supposed to be transparent and automatic - if you teach your phone to recognize your voice, then all the HomePods in your house are supposed to as well. Except sometimes they just don't sync and you have to reset the homepods to factory defaults and reintroduce them just to get them to sync the voice recognition. Or worse, your phone won't let you turn on voice recognition for you in homekit even though your phone is doing recognition successfully.

Or even more maddening, the home app says you're signed in with a different apple ID on your phone and home app, but it's the exact same ID.

And that's assuming you can even join the home on your phone. My wife's phone is nearly impossible to invite to our "Home". The invites never arrive if using the appleID. Sometimes it'll work if the invite is done by phone number, but again, no invite message. Sometimes firing up the Home app on her phone will announce that there is a pending invite but it often takes 5-10 tries over a few days to get this far.

When searching on the support forums, it is easy to find other people who have had these exact same problems for years.

Or the AirTag situation. I put an airtag on a remote control that keeps getting lost in the room. But only one person in the house can locate it with the UWB direction finding system. I don't want to have to put two or three airtags on the same remote just because Apple won't let us share tags between family members. This is just silly.

Sadly, I find myself agreeing with the article. Apple has drifted from "it just works" to being surprised if it actually works.

Unfortunately, this issue lowers the bar for exploiting a months-old vulnerability.

The older ongoing problem is that any person can create a new Experian account with a new email address, and answer a few credit-related quiz to take over somebody's credit file. When doing this Experian will helpfully even offer to unlock the credit file and you can reset security questions etc. All without the consent of the victim. All the "security" systems are bypassed.

This new vulnerability means you need even less information to take over somebody's credit/identity. You can get the answers to their quiz directly from Experian's own systems. That makes it a bigger deal.

I remember trying to download an archive of my email a few years ago. Hah, that was fun. I had a number of tries but each time the archive it gave me had between 20% to 50% of the total email messages.

It's been unreliable for years.

How? The same as you would if the farmer providing retail-ready carrots didn't exist.

In California's case the grid generation capacity was made up of nuclear (fixed base load), natural gas for dynamic load, and solar/other renewables (wind, hydro etc), and import/export.

If you look at the grid operator stats on https://www.caiso.com/TodaysOutlook/Pages/supply.html#sectio... - I find it interesting to compare days like May 10th (where solar + base load lead to exporting) vs something like Sept 1st (where solar + gas + imports was barely enough) vs today (Dec 16th, where sun is limited and we rely on natural gas + imports to fill the gap).

PG&E probably loses money on days like May 1st where a large portion of their power is acquired at retail, but makes a killing on the other two example days by selling wholesale generated/imported power at our jacked up rates.

IMHO They want to make a killing on the plentiful springtime solar surplus too. Now that they've got everything they asked for don't expect that this will reduce rates for non-solar customers - it'll go to investors.

I still think a tune-up of NEM2.0 would have been better. Other places seem to get by just fine with an 80%-90% buy-back rate vs NEM2.0's 100%.

To extend the metaphor a little, the farmer would be bringing in carrots in a ready-to-sell condition and putting them directly in the Safeway stores on the retail shelves.

That's a little different than forcing Safeway to pick them up at the wholesale distribution warehouse (at full retail price) and truck them around themselves and stack the stores themselves.

In the PG&E case, the residential rooftop solar power is delivered directly into the retail last-mile networks just like the carrots on the Safeway shelves metaphor.

However, the NEM2.0 model is still needed a tuneup. Last-mile networks still need maintenance. Suppose each neighborhood reached self sufficiency, somebody has to pay for the grid maintenance and run the whole thing.

IMHO, buyback at a discount makes sense, but NEM3.0 seems like a Christmas gift to PG&E. They get ToU, capacity fees, wholesale rates, and minimum usage fees. They asked for the sky and got it all.

First, there was X10. There was appetite for something better. There were several candidate replacements, including:

* UPB - Universal Powerline Bus (powerline)

* Insteon (powerline + wireless)

* Z-Wave (wireless)

* Zigbee (wireless)

Of these, Zigbee seems to be in the best position these days.

Z-Wave is/was a closed system - you had to get compatibility testing/certification in order to sell products using the tech. It's fairly lightweight, reliable, and well respected by users.

Yes, this is one of the concerns. In theory a browser addon should take a while for the bad guys to update and publish, but are the existing addons downloading and using server-provided JS? One would hope not, but that's hardly a safe assumption these days. I know Mozilla takes a pretty hard stance against this sort of thing, but it's not all caught in review. And then there's the electron style apps - those should be static too, right? right?? Also not a safe assumption. And yes, there is a pure-web UI where the code is downloaded from their servers.

Anyway - it's not a good position to be in.

I miss Insteon. I know it's kinda-sorta-maybe-alive again but we'll see.

Insteon was simple and mostly just worked. Even my wife saw the benefit of the thing.

Companies like Google rely heavily on AI and automation and keep humans out of the loop to the extent possible. Once the models detect these sort of photos, they won't be stopping. If they don't add a permanent exception then the AI would flag it on the next pass and repeat the process. Google certainly won't be retraining the models to learn to exclude "but not photos for doctors". Having humans going through and flagging accounts (or photos) for exceptions will ruin the economies of scale.

This can't keep going on like this. To somebody like Google, an account might just be a profit source, but to the affected people it can be their lives or livelihood.

The issue of right of redress really needs to be forced, legislatively.

Perhaps her account credentials were compromised? Somebody could have used the web API to run a spam/abuse campaign.

There's also https://fraidyc.at/ which provides a browser extension. It's an easy way to do exactly what the OP was doing and for more than just twitter.

I've been using ZFS since circa 2008, but it's a tradeoff.

If I want no-worries and I don't want to be surprised by data loss, I use ZFS. If I want speed with data I can afford to lose, I use something else (ufs, ext4, xfs, the right FS for the job).

ZFS's integrity checking won't do a dang thing for you if you're not paying attention, don't have monitoring, or don't even run its checks. Yes, I over-provision. Yes, I'll make the reliability vs performance tradeoffs (when it makes sense, usually reliability over performance by default though).

The great thing about having options is exactly that. For me, ZFS is the right choice in most cases. For other people it's not. Being able to make an informed choice and not being forced either way is a good thing.

Zealotry/religion has no place in matters like this when there are clear tradeoffs in all the alternatives.

At Yahoo, there was a tool that did in-place OS upgrades for FreeBSD, but you're right - in most cases, people installed whatever was current of the day and then relied on yinst to make it work. ybsdupgrade did work and was mostly a non-event. I don't recall whether we had it work across major version upgrades though.

You are correct. This is widely copy/pasted bad advice and does the exact opposite of what the comment says.

It is not an idle timeout logout at all. Instead, it causes sshd to periodically send probes to the client. This has a couple of effects, most notably keeping tcp sessions "active" and frequently exchanging packets (this can be useful to keep connections through statefull firewalls alive if you are genuinely idle), and to rapidly detect and disconnect a client that has actually gone away.

I think the origin of this incorrect description is the CIS documents. They have the exact same gross mistake in them.

I think the ClientAlive probes are useful and should be on, but it's definitely not an "idle logout" as claimed.

It amazes me how much time has passed since then. I would have to go and look up the history and events to remember what order things happened.

However, with my FreeBSD hat on, it should be pointed out that we had this wonderful fellow called Cameron Grant. He is largely responsible for FreeBSD's post-OSS audio system. FreeBSD could have gone several ways for audio at the time, but he made it work, and it worked well. It had virtual channels with in-kernel mixing with very low latency - with full API compatibility. Tragically, Cameron's time was cut short.

Over time, other people got involved and picked it up. The subsystem gradually progressed from the user perspective of being simple and Just Working, to something that is rather powerful today.

Precisely this. And I realize it's not the same around the world, but recurring payments get really bad in large parts of the world.

If you, the customer, want to cancel a recurring payment and you're using ApplePay, it's one button and done.

If you're using 3rd party billing from $randomcompany, it usually works by you, the customer, trying to find who to call and spending a substantial portion of your time being badgered by customer retention people. They're set up to make it as difficult as possible because they know that they can make people give in if the effort is too high.

This is a huge part of the reason why companies want the second option - they want to own the customer, and for you to have to get permission from them to stop belonging to them.

It is easily blocked with ublock origin. Custom rule:

  ! 8/7/2020 https://medium.com
  medium.com###credential_picker_container

A slightly less drastic option than quitting is to go into a passive, readonly mode and keep a safe distance.

I use https://fraidyc.at/ Seriously, it's a thing. You can still follow public social media streams that you're interested in. It does RSS, Twitter, as well as the usual social media suspects. It's fast and perfect for avoiding getting suckered into a fight over nothing important.

If you really have to, you can fire up the real thing but this is a good way to get some of your time back.

It's not even the first IPv8. There was an IPv8 doing the rounds in the late 1990's for a while. I had some trouble finding references, but I think this is the sanitized version: https://tools.ietf.org/html/draft-terrell-ip-spec-ipv7-ipv8-... I have fond memories of reading about how stargates, galaxy routers etc, etc were going to solve all our problems. The IPv8 in the link is a far more pedestrian read.

Technically, you can on an iPhone too, just not for free and not anywhere near as conveniently. There were various tools in circulation while there were no decent Jailbreaks. One that springs to mind was iReSign - according to its github page it's for re-signing app bundles with enterprise keys, but that's not what it was used for back then. People captured the .ipa files and signed them with developer keys and all sorts of unfortunate things happened after that.

TL;DR: "sideloading" for iOS = Free: no. Convenient: no. Possible: yes. Out of reach of most people: absolutely yes.

That's the one.

In traditional BSD kernels, there is a portable layer and a machine dependent layer. The cpu MD layer for context switching was called cpu_switch(), usually written in assembler. It saved the current state and switched to another. When you regained control of the cpu, you returned from cpu_switch(). There was always somewhere to switch to.

When we added multiple threads per process (part of the KSE effort back in the day), a new low level construct was added - cpu_throw(). You switched somewhere else and threw away your context, didn't put the old thread in the run queue, and never returned. We used this for quickly disposing of threads.

This was all fine, thread implementations, process/thread schedulers, etc came and went.

Somewhere along the way, somebody reused the NetBSD MD/asm layer for one of the powerpc architectures. Of course, NetBSD didn't have cpu_throw(). It was #defined to cpu_switch() because it was close enough and worked.

Until somebody tried to use threading on this powerpc architecture. The fake cpu_throw() didn't prevent a return and the system got far enough to reach the upper machine independent layers and hit the panic.

This caused some amusement. Particularly as somebody had previously suggested that the panic was unnecessary as it cannot happen but I wanted to keep it anyway.

I added panic("I'm a teapot!"); to the FreeBSD kernel, many many years ago (sys/kern/kern_thread.c). It was for an impossible, cannot-happen scenario.

Much to my astonishment/amusement, it did.

I have memories of this sort of thing going on back in the early 2000s with DirecTV access cards. One of the methods was to glitch the access card processor during bootup by pulsing and otherwise messing with the power. IIRC, it could be put into a test or debug mode if it was timed right.

On one hand I'd expect most systems that take security seriously would defend against this, but on the other hand the pitiful state of mass market and consumer hardware would indicate that very low expectations would be appropriate.

We had a situation like this at work. My username was very common and got locked on our ssh proxies like clockwork with just the routine background internet scanning. I couldn't get any traction with getting this fixed. We had hardware 2FA (physical tokens), so brute forcing was effectively moot.

Then, strangely, various senior folks found their accounts getting locked 1-2 times a day, including the founder. That autolock policy died in a week, and they started looking for 2FA failures instead, as they should have.

I had considered "accidentally" setting up a ssh loop to do this but never quite got around to it. I assume somebody else did. I doubt that an infusion of sanity happened by accident.