When to FileVault a New Mac

[Wade Garrett]

Got a new Mac coming to replace my current one which has FileVault
turned on.

Better/easier to FileVault the new machine before or after transferring
data to it via Migration Assistant?

--
If you don't want to do something, one excuse is as good as another
- Yiddish proverb

[nospam]

In article <sp258j$9go$1...@dont-email.me>, Wade Garrett <Wa...@cooler.net>
wrote:

> Better/easier to FileVault the new machine before or after transferring
> data to it via Migration Assistant?

before will be much quicker since there's less to encrypt.

[Alan Browne]

On 2021-12-11 09:04, TimS wrote:

> Why filevault it in the first place?

Why _not_ filevault? It has a negligible effect on speed and means you
can dispose of the drive at end of life with no action other than
destroying the key.


--
"...there are many humorous things in this world; among them the white
man's notion that he is less savage than the other savages."
-Samuel Clemens

[Alan Browne]

On 2021-12-11 07:23, Wade Garrett wrote:
> Got a new Mac coming to replace my current one which has FileVault
> turned on.
>
> Better/easier to FileVault the new machine before or after transferring
> data to it via Migration Assistant?

Just as easy before or after.
Better before as all stuff being on-boarded will be encrypted as it's
loaded.

I'd prefer the OS maintain a unique key for every file and when the file
is deleted (from the trash), destroy the key. Impossible to recover.
(akin to what iOS does).

[Lewis]

In message <sp258j$9go$1...@dont-email.me> Wade Garrett <Wa...@cooler.net> wrote:
> Got a new Mac coming to replace my current one which has FileVault
> turned on.

> Better/easier to FileVault the new machine before or after transferring
> data to it via Migration Assistant?

With a new mac it makes no difference at all; the FileVault process is
basically instantaneous.

--
First we must assume a spherical cow.

[Lewis]

In message <Qu3tJ.45437$xe2....@fx16.iad> Alan Browne <bitb...@blackhole.com> wrote:
> On 2021-12-11 09:04, TimS wrote:
>> On 11 Dec 2021 at 13:41:19 GMT, nospam <nos...@nospam.invalid> wrote:
>>
>>> In article <sp258j$9go$1...@dont-email.me>, Wade Garrett <Wa...@cooler.net>
>>> wrote:
>>>
>>>> Better/easier to FileVault the new machine before or after transferring
>>>> data to it via Migration Assistant?
>>>
>>> before will be much quicker since there's less to encrypt.
>>
>> Why filevault it in the first place?

> Why _not_ filevault? It has a negligible effect on speed

Zero effect on speed with any T2 machine or M1 machine.

> and means you can dispose of the drive at end of life with no action
> other than destroying the key.

One of many advantages.



--
"Are you pondering what I'm pondering?"
"Well, I think so, Brain, but it's a miracle that this one grew
back."

[Alan Browne]

On 2021-12-11 12:13, Lewis wrote:
> In message <Qu3tJ.45437$xe2....@fx16.iad> Alan Browne <bitb...@blackhole.com> wrote:
>> On 2021-12-11 09:04, TimS wrote:
>>> On 11 Dec 2021 at 13:41:19 GMT, nospam <nos...@nospam.invalid> wrote:
>>>
>>>> In article <sp258j$9go$1...@dont-email.me>, Wade Garrett <Wa...@cooler.net>
>>>> wrote:
>>>>
>>>>> Better/easier to FileVault the new machine before or after transferring
>>>>> data to it via Migration Assistant?
>>>>
>>>> before will be much quicker since there's less to encrypt.
>>>
>>> Why filevault it in the first place?
>
>> Why _not_ filevault? It has a negligible effect on speed
>
> Zero effect on speed with any T2 machine or M1 machine.

I'll test that next week with an external SSD.

[Lewis]

In message <fF5tJ.23213$Pl1....@fx23.iad> Alan Browne <bitb...@blackhole.com> wrote:
> On 2021-12-11 12:13, Lewis wrote:
>> In message <Qu3tJ.45437$xe2....@fx16.iad> Alan Browne <bitb...@blackhole.com> wrote:
>>> On 2021-12-11 09:04, TimS wrote:
>>>> On 11 Dec 2021 at 13:41:19 GMT, nospam <nos...@nospam.invalid> wrote:
>>>>
>>>>> In article <sp258j$9go$1...@dont-email.me>, Wade Garrett <Wa...@cooler.net>
>>>>> wrote:
>>>>>
>>>>>> Better/easier to FileVault the new machine before or after transferring
>>>>>> data to it via Migration Assistant?
>>>>>
>>>>> before will be much quicker since there's less to encrypt.
>>>>
>>>> Why filevault it in the first place?
>>
>>> Why _not_ filevault? It has a negligible effect on speed
>>
>> Zero effect on speed with any T2 machine or M1 machine.

> I'll test that next week with an external SSD.

Enabling file vault on external drives will still be slow. The instant
process on the T2 and M1 machines applies to the internal boot drive.

--
I WILL NOT DO THE DIRTY BIRD Bart chalkboard Ep. AABF08

[Alan Browne]

If that's the case then it's pretty much un-testable for speed even if I
start up that system with FV off:

"If FileVault isn’t enabled on a Mac with the T2 chip during the initial
Setup Assistant process, the volume is still encrypted, but the volume
key is protected only by the hardware UID in the Secure Enclave. If
FileVault is enabled later — a process that is immediate since the data
was already encrypted — an anti-replay mechanism prevents the old key
(based on hardware UID only) from being used to decrypt the volume. The
volume is then protected by a combination of the user password with the
hardware UID as previously described."

https://www.apple.com/mideast/mac/docs/Apple_T2_Security_Chip_Overview.pdf

I'll still do an external volume test - should still outpace the i7 iMac
on difference.
(https://groups.google.com/g/comp.sys.mac.system/c/1qSo1J4UqcM/m/RHonW9sjDQAJ
- about 11% slower to an encrypted external volume per my measurements
in 2016).

[Wade Garrett]

On 12/11/21 9:04 AM, TimS wrote:
> On 11 Dec 2021 at 13:41:19 GMT, nospam <nos...@nospam.invalid> wrote:
>

> Why filevault it in the first place?
>

S.E.C.U.R.I.T.Y.

[Lewis]

Yes, I didn't recall the exact details because I just turn FileVault on
for all my machines.

> I'll still do an external volume test - should still outpace the i7 iMac
> on difference.

I would think so, I think the FileVault encryption is handled by the
neural engine.

--
Satan oscillate my metallic sonatas

[Your Name]

On 2021-12-11 12:23:45 +0000, Wade Garrett said:
>
> Got a new Mac coming to replace my current one which has FileVault turned on.
>
> Better/easier to FileVault the new machine before or after transferring
> data to it via Migration Assistant?

Migration Assistant is always best used when you are going through the
initial computer setting up process. Trying to do it afterwards can
cause issues with user ID conflicts.

[Lewis]

The question has nothing to do with Migration Assistant.

--
(on emojis) Remember when they added Groucho and no Harpo?

[Alan Browne]

Likewise, haven't really read up on it since FV changed to FV2. More
interested now as I'm planning the house conversion to Mx processors.
Work Macs will stay intel for quite a while (no urgent needs and some
legacy issues).

MBA allegedly arrives this week.

Can't wait for a "higher end" iMac (M1 Max perhaps - though the Pro is
probably more than enough for my needs). By spring maybe. I'd even
consider a Mini with high end Mx.

>> I'll still do an external volume test - should still outpace the i7 iMac
>> on difference.
>
> I would think so, I think the FileVault encryption is handled by the
> neural engine.

I wouldn't think so - AES is not all that complex to implement. Neural
engines are more for 'fuzzy stuff' (graphics, audio, etc.).

The M1 has the T2 functionality including the AES "inline" function for
system storage. But I wonder if it has a separate AES engine that can
be used generally (by any process) via the encryption libraries.

IAC, AES is not a very expensive function even in s/w. A requirement of
AES from the start). Below.

[1] https://www.oryx-embedded.com/doc/aes_8c_source.html

[Ant]

Ditto. It's also good to test the drive out before dumping your datas
into it.
--
Incoming major (<2") winter rain storm 2 do more preparations 4 da warm nest & colony! Also, 2 many free weekend games again! :(
Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
/\___/\ Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org.
/ /\ /\ \ Please nuke ANT if replying by e-mail.
| |o o| |
\ _ /
( )

[Lewis]

In message <nZOdnchZ77sSkCr8...@earthlink.com> Ant <a...@zimage.comANT> wrote:
> nospam <nos...@nospam.invalid> wrote:
>> In article <sp258j$9go$1...@dont-email.me>, Wade Garrett <Wa...@cooler.net>
>> wrote:

>> > Better/easier to FileVault the new machine before or after transferring
>> > data to it via Migration Assistant?

>> before will be much quicker since there's less to encrypt.

Still not correct.

> Ditto.

Nope.

> It's also good to test the drive out before dumping your datas into
> it.

If you have backups *you DO have backups?) then this is quite literally
a waste of time, and largely meaningless with modern drives that will
often simply report their internal status and not actually write
multiple terabytes of 0s to the drive.


--
Cecil is made of blood and unfinished leather

[Alan Browne]

On 2021-12-11 07:23, Wade Garrett wrote:

> Got a new Mac coming to replace my current one which has FileVault
> turned on.
>
> Better/easier to FileVault the new machine before or after transferring
> data to it via Migration Assistant?

Another reason to do it while migrating is an issue called Data
Remanence. When an unencrypted file is encrypted it is not re-written
in place on SSD drives but written somewhere else and then the original
is deleted. But when it's deleted it is not erased (destroyed). So
until something overwrites those sectors (blocks on an SSD), the
information is recoverable.

Those blocks will get clobbered at some point, to be sure. This is not
acceptable for very secure requirements.

I've been searching through Apple docs and so far have found no mention
of this issue, so either it is handled and not mentioned, or it depends
on the blocks eventually being over-written. Apple are pretty
transparent with how they handle security and this I've yet to find.

Hope for the best. Plan for the worst. Encrypt on migration. Or fill
the rest of the drive with gibberish files and erase them after conversion.

Better: encrypt on migration.

(Ironically on spinning disk storage, write over in place is very
feasible; whereas on SSD it would be a desirable exception to wear
leveling strategies, but the logic of the storage device won't permit it).

[nospam]

In article <5JOtJ.122411$SW5....@fx45.iad>, Alan Browne

<bitb...@blackhole.com> wrote:

> Another reason to do it while migrating is an issue called Data
> Remanence. When an unencrypted file is encrypted it is not re-written
> in place on SSD drives but written somewhere else and then the original
> is deleted. But when it's deleted it is not erased (destroyed). So
> until something overwrites those sectors (blocks on an SSD), the
> information is recoverable.

only with substantial effort and expense.

> Those blocks will get clobbered at some point, to be sure. This is not
> acceptable for very secure requirements.
>
> I've been searching through Apple docs and so far have found no mention
> of this issue, so either it is handled and not mentioned, or it depends
> on the blocks eventually being over-written. Apple are pretty
> transparent with how they handle security and this I've yet to find.

that's a function of the ssd, not anything apple does.

it's also not possible to directly access the spare blocks, other than
via a forensic lab, i.e., substantial effort and expense.

> Hope for the best. Plan for the worst. Encrypt on migration. Or fill
> the rest of the drive with gibberish files and erase them after conversion.

filling the drive is unnecessary wear on an ssd and unless you're a
high profile target, overkill.

> Better: encrypt on migration.

yep.

> (Ironically on spinning disk storage, write over in place is very
> feasible; whereas on SSD it would be a desirable exception to wear
> leveling strategies, but the logic of the storage device won't permit it).

hard drives remap bad blocks and their contents remain.

whether it's still readable depends on how bad the block actually is.

[Alan Browne]

On 2021-12-13 17:17, nospam wrote:
> In article <5JOtJ.122411$SW5....@fx45.iad>, Alan Browne
> <bitb...@blackhole.com> wrote:
>
>> Another reason to do it while migrating is an issue called Data
>> Remanence. When an unencrypted file is encrypted it is not re-written
>> in place on SSD drives but written somewhere else and then the original
>> is deleted. But when it's deleted it is not erased (destroyed). So
>> until something overwrites those sectors (blocks on an SSD), the
>> information is recoverable.
>
> only with substantial effort and expense.
>
>> Those blocks will get clobbered at some point, to be sure. This is not
>> acceptable for very secure requirements.
>>
>> I've been searching through Apple docs and so far have found no mention
>> of this issue, so either it is handled and not mentioned, or it depends
>> on the blocks eventually being over-written. Apple are pretty
>> transparent with how they handle security and this I've yet to find.
>
> that's a function of the ssd, not anything apple does.

Apple are mute on the issue.

>
> it's also not possible to directly access the spare blocks, other than
> via a forensic lab, i.e., substantial effort and expense.

Due to TRIM perhaps, yes.

>> Hope for the best. Plan for the worst. Encrypt on migration. Or fill
>> the rest of the drive with gibberish files and erase them after conversion.
>
> filling the drive is unnecessary wear on an ssd and unless you're a
> high profile target, overkill.

1 overwrite. The method is for the paranoid and won't affect the long
term by any serious amount.

>> Better: encrypt on migration.
>
> yep.
>
>> (Ironically on spinning disk storage, write over in place is very
>> feasible; whereas on SSD it would be a desirable exception to wear
>> leveling strategies, but the logic of the storage device won't permit it).
>
> hard drives remap bad blocks and their contents remain.

Hardly relevant as bad blocks don't come into being very often ...

[STALKING_TARGET_69]

He is a jerk; advocates have kf'd his flooding. What he really can not make
is a bot that keeps switching names, then flood posts have a shot at being
one quarter as idiotic as he is. When will Ixchel support the allegation
he's made multiple times about me being a Ryan Sullivan sock? The guy is
as loved as a wet dog at a parlor social -- and with good reason. It's his
problem but he does not care. Obviously he would rather blame Ryan Sullivan
than face reality. The bulk of the regulars in this group do customizations
either as a pastime or as a career, so I have doubts anyone here thinks
of automation to be "black magic".

What is your evidence?

--
One Smart Penny!!
https://swisscows.com/web?query=%22narcissistic%20bigot%22
Automate Google Groups https://groups.google.com/forum/#!search/Petruzzellis$20or$20Carroll
https://www.perkinscoie.com/en/professionals/michael-glaser.html
Steve 'Narcissistic Bigot' Carroll

[nospam]

In article <35QtJ.55547$Gco3....@fx01.iad>, Alan Browne

<bitb...@blackhole.com> wrote:

> >> Those blocks will get clobbered at some point, to be sure. This is not
> >> acceptable for very secure requirements.
> >>
> >> I've been searching through Apple docs and so far have found no mention
> >> of this issue, so either it is handled and not mentioned, or it depends
> >> on the blocks eventually being over-written. Apple are pretty
> >> transparent with how they handle security and this I've yet to find.
> >
> > that's a function of the ssd, not anything apple does.
>
> Apple are mute on the issue.

there's nothing for apple to say. it's how ssds work.

> > it's also not possible to directly access the spare blocks, other than
> > via a forensic lab, i.e., substantial effort and expense.
>
> Due to TRIM perhaps, yes.

not just that.

directly accessing raw blocks requires bypassing the controller
firmware, which is not something end users are able to do.

a data recovery lab, such as drivesavers, can do that, and it isn't
going to be particularly cheap.

> >> Hope for the best. Plan for the worst. Encrypt on migration. Or fill
> >> the rest of the drive with gibberish files and erase them after conversion.
> >
> > filling the drive is unnecessary wear on an ssd and unless you're a
> > high profile target, overkill.
>
> 1 overwrite. The method is for the paranoid and won't affect the long
> term by any serious amount.

it's 1 more than is needed and doesn't actually help.

unless you're a high profile target, nobody is going to bother trying
to recover your ssd since it's not worth the effort.

if someone was able to access some of the spare blocks, they'd only get
fragments of files. the chances that there's something of interest in a
random block of a random file is statistically quite low.

> >> (Ironically on spinning disk storage, write over in place is very
> >> feasible; whereas on SSD it would be a desirable exception to wear
> >> leveling strategies, but the logic of the storage device won't permit it).
> >
> > hard drives remap bad blocks and their contents remain.
>
> Hardly relevant as bad blocks don't come into being very often ...

nor do those who want to forensically examine hard drives...

the point is that unencrypted data can also exist on a hard drive.

[Lewis]

In message <5JOtJ.122411$SW5....@fx45.iad> Alan Browne <bitb...@blackhole.com> wrote:
> On 2021-12-11 07:23, Wade Garrett wrote:
>> Got a new Mac coming to replace my current one which has FileVault
>> turned on.
>>
>> Better/easier to FileVault the new machine before or after transferring
>> data to it via Migration Assistant?

> Another reason to do it while migrating is an issue called Data
> Remanence. When an unencrypted file is encrypted

This is not an issue on new Macs, the data is ALWAYS encrypted, it is
just a matter of if the key to the encryption is private or not.

--
Silence is golden, duct tape is silver.

[Lewis]

In message <131220211717401043%nos...@nospam.invalid> nospam <nos...@nospam.invalid> wrote:
> In article <5JOtJ.122411$SW5....@fx45.iad>, Alan Browne
> <bitb...@blackhole.com> wrote:

>> Another reason to do it while migrating is an issue called Data
>> Remanence. When an unencrypted file is encrypted it is not re-written
>> in place on SSD drives but written somewhere else and then the original
>> is deleted. But when it's deleted it is not erased (destroyed). So
>> until something overwrites those sectors (blocks on an SSD), the
>> information is recoverable.

> only with substantial effort and expense.

It also really is not. The idea you can reassemble a file by gathering
random cells on an SSD is pretty much the definition of impossible.

>> Better: encrypt on migration.

> yep.

Not on a recent Mac, it makes absolutely no difference.

--
The brain is an amazing organ, it works every second of every day
from before we're even born right up until the instant we fall in
love.

[Alan Browne]

On 2021-12-13 21:36, Lewis wrote:
> In message <131220211717401043%nos...@nospam.invalid> nospam <nos...@nospam.invalid> wrote:
>> In article <5JOtJ.122411$SW5....@fx45.iad>, Alan Browne
>> <bitb...@blackhole.com> wrote:
>
>>> Another reason to do it while migrating is an issue called Data
>>> Remanence. When an unencrypted file is encrypted it is not re-written
>>> in place on SSD drives but written somewhere else and then the original
>>> is deleted. But when it's deleted it is not erased (destroyed). So
>>> until something overwrites those sectors (blocks on an SSD), the
>>> information is recoverable.
>
>> only with substantial effort and expense.
>
> It also really is not. The idea you can reassemble a file by gathering
> random cells on an SSD is pretty much the definition of impossible.
>
>>> Better: encrypt on migration.
>
>> yep.
>
> Not on a recent Mac, it makes absolutely no difference.

For a "drive recovery" (Drive removed from computer) that is correct.

But, if your laptop is stolen[1] and booted into Recovery Mode and
Target Disk Mode is used on the attack-Mac, then it would be as
transparent as a window without Filevault requiring the password...

https://blog.kolide.com/modern-macs-still-need-filevault-d5e2f55c083b
... skip about 1/4 of the way down.

[Doc O'Leary]

For your reference, records indicate that

OK, but be honest with yourself about your threat profile. Apple’s tools
are fine if you only thoughtlessly play in the Apple ecosystem. Once you
start using other technology, interoperable solutions are more useful.

It has never made sense for me to use Migration Assistant. Any data that
is important to me is not exclusively on my Mac (nor do I have just one
Mac). I have backups, and I’m better served by testing them with the new
machine than just importing all the cruft that built up on my old machine.

Likewise, FileVault only serves to protect the Mac, not the data. I
always use it on laptops, due to their risk of being lost “in the wild”.
But otherwise, data security is bigger than the Mac, and if you don’t
have a process in place that respects that, you’re quite likely to have
your security compromised by some other lower-hanging fruit.

--
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly

[Alan Browne]

On 2021-12-15 11:23, Doc O'Leary wrote:
> For your reference, records indicate that
> Wade Garrett <Wa...@cooler.net> wrote:
>
>> On 12/11/21 9:04 AM, TimS wrote:
>>>
>>> Why filevault it in the first place?
>>>
>>
>> S.E.C.U.R.I.T.Y.
>
> OK, but be honest with yourself about your threat profile. Apple’s tools
> are fine if you only thoughtlessly play in the Apple ecosystem. Once you
> start using other technology, interoperable solutions are more useful.
>
> It has never made sense for me to use Migration Assistant. Any data that
> is important to me is not exclusively on my Mac (nor do I have just one
> Mac). I have backups, and I’m better served by testing them with the new
> machine than just importing all the cruft that built up on my old machine.

Yesterday spent some time pruning and re-organizing data on my SO's
laptop in anticipation of a new Mac. Haven't decided for or against MA
for this yet. Probably won't.

> Likewise, FileVault only serves to protect the Mac, not the data. I
> always use it on laptops, due to their risk of being lost “in the wild”.
> But otherwise, data security is bigger than the Mac, and if you don’t
> have a process in place that respects that, you’re quite likely to have
> your security compromised by some other lower-hanging fruit.

While less vulnerable to theft than a traveling laptop, home (or office)
theft is always possible. See my prior post for how that data can be
accessed.

The performance cost of Filevault on a T2/Mx Mac is negligible and only
carries the cost of a safe place for the password.

--
Beginning in the 1970's, all birds in North America were replaced by
drones made to look and act like birds. By 2004, no real birds are to
be found. They are all drones. They all belong to the government.
They spy on everyone. All of the time. Birds are not real.

[Lewis]

In message <nz7uJ.45660$xe2....@fx16.iad> Alan Browne <bitb...@blackhole.com> wrote:
> On 2021-12-13 21:36, Lewis wrote:
>> In message <131220211717401043%nos...@nospam.invalid> nospam <nos...@nospam.invalid> wrote:
>>> In article <5JOtJ.122411$SW5....@fx45.iad>, Alan Browne
>>> <bitb...@blackhole.com> wrote:
>>
>>>> Another reason to do it while migrating is an issue called Data
>>>> Remanence. When an unencrypted file is encrypted it is not re-written
>>>> in place on SSD drives but written somewhere else and then the original
>>>> is deleted. But when it's deleted it is not erased (destroyed). So
>>>> until something overwrites those sectors (blocks on an SSD), the
>>>> information is recoverable.
>>
>>> only with substantial effort and expense.
>>
>> It also really is not. The idea you can reassemble a file by gathering
>> random cells on an SSD is pretty much the definition of impossible.
>>
>>>> Better: encrypt on migration.
>>
>>> yep.
>>
>> Not on a recent Mac, it makes absolutely no difference.

> For a "drive recovery" (Drive removed from computer) that is correct.

> But, if your laptop is stolen[1] and booted into Recovery Mode and
> Target Disk Mode is used on the attack-Mac, then it would be as
> transparent as a window without Filevault requiring the password...

Which has noting to do with the time it takes to encrypt (none) or the
so-called "data remembrance" bullshit above that you wrongly
interjected into this conversation without knowing what you are talking
about.

There is NO REASON to not encrypt your drive on a modern Mac, it
literally costs noting at all, do difference in speed, no impact on the
data safety, nothing at all. It does not matter if you do it before or
after adding all your data to the drive, because it still takes no time
at al to encrypt because the data on the drive is already encrypted. If
you leave FileVault off, then your data is openly accessible, even
though it is encrypted. This would be an exceedingly foolish thing to
do, but it is possible to be that foolish.

--
"If you want to get rich from writing, write the sort of thing that's
read by persons who move their lips when they're reading to
themselves." - Don Marquis

[Lewis]

In message <spd4qp$g7n$1...@dont-email.me> Doc O'Leary <drol...@2017usenet1.subsume.com> wrote:
> For your reference, records indicate that
> Wade Garrett <Wa...@cooler.net> wrote:

>> On 12/11/21 9:04 AM, TimS wrote:
>> >
>> > Why filevault it in the first place?
>> >
>>
>> S.E.C.U.R.I.T.Y.

> OK, but be honest with yourself about your threat profile. Apple’s tools
> are fine if you only thoughtlessly play in the Apple ecosystem. Once you
> start using other technology, interoperable solutions are more useful.

there's a meaningless paragraph.

> It has never made sense for me to use Migration Assistant.

That seems like a PEBKAC problem to me, but you be you.

> Any data that is important to me is not exclusively on my Mac (nor do
> I have just one Mac). I have backups, and I’m better served by
> testing them with the new machine than just importing all the cruft
> that built up on my old machine.

Ah, the legendary 'cruft' bullshit. Spoken like a Windows user.

When I migrated my data to this new MBA I ended up with an exact copy of
what was on my other computer at the time, INCLUDING all the shell tools
I had installed, scripts I had written, preferences and nearly all
settings. It was then the task of a few minutes to delete things I did
not need to have on the laptop.

And yes, Migration Assistant is a perfectly good way to test your backups
since the simplest way to migrate is to boot off your time machine
volume and migrate from it.

> Likewise, FileVault only serves to protect the Mac, not the data.

What the fuck are you talking about? It protects *EVERYTHING* on the
computer.

The only drive I have that is not encrypted is a Drobo I use for media
backups, and it is not encrypted only because it cannot be.

> always use it on laptops, due to their risk of being lost “in the wild”.
> But otherwise, data security is bigger than the Mac, and if you don’t
> have a process in place that respects that, you’re quite likely to have
> your security compromised by some other lower-hanging fruit.

A lesser computer's inability to protect your data has nothing
whatsoever to do with macOS or FileVault.

--
gentlemen in England now a-bed Shall think themselves accursed the
were not here,

[Lewis]

In message <OYouJ.64137$zF3....@fx03.iad> Alan Browne <bitb...@blackhole.com> wrote:
> The performance cost of Filevault on a T2/Mx Mac is negligible

You keep repeating this mistake. It is *zero* performance cost.

> and only carries the cost of a safe place for the password.

And you can use your account password as the key. I=Of course, have a
decent password on *ALL* accounts, but only a fool would not do that
anyway.

--
The Disc, being flat, has no real horizon. Any adventurous sailors
who get funny ideas from staring at eggs and oranges for too long
and set out for the antipodes soon learned that the reason why
distant ships sometimes looked as though they were disappearing
over the edge of the world was that they were disappearing over
the edge of the world. --The Light Fantastic

[Alan Browne]

On 2021-12-15 15:29, Lewis wrote:
> In message <nz7uJ.45660$xe2....@fx16.iad> Alan Browne <bitb...@blackhole.com> wrote:
>> On 2021-12-13 21:36, Lewis wrote:
>>> In message <131220211717401043%nos...@nospam.invalid> nospam <nos...@nospam.invalid> wrote:
>>>> In article <5JOtJ.122411$SW5....@fx45.iad>, Alan Browne
>>>> <bitb...@blackhole.com> wrote:
>>>
>>>>> Another reason to do it while migrating is an issue called Data
>>>>> Remanence. When an unencrypted file is encrypted it is not re-written
>>>>> in place on SSD drives but written somewhere else and then the original
>>>>> is deleted. But when it's deleted it is not erased (destroyed). So
>>>>> until something overwrites those sectors (blocks on an SSD), the
>>>>> information is recoverable.
>>>
>>>> only with substantial effort and expense.
>>>
>>> It also really is not. The idea you can reassemble a file by gathering
>>> random cells on an SSD is pretty much the definition of impossible.
>>>
>>>>> Better: encrypt on migration.
>>>
>>>> yep.
>>>

>>> Not on a recent Mac, it makes absolutely no difference. [AAA] <---

>
>> For a "drive recovery" (Drive removed from computer) that is correct.
>
>> But, if your laptop is stolen[1] and booted into Recovery Mode and
>> Target Disk Mode is used on the attack-Mac, then it would be as
>> transparent as a window without Filevault requiring the password...
>
> Which has noting to do with the time it takes to encrypt (none) or the
> so-called "data remembrance" bullshit above that you wrongly
> interjected into this conversation without knowing what you are talking
> about.

It is an issue with spinning mass. I had forgotten all the lovely
things that SSD/TRIM do. Big deal. Sorted out. Move on. That's what
newsgroups are about.

> There is NO REASON to not encrypt your drive on a modern Mac, it

Above: I said "Better: encrypt on migration."
Nospam said "yep"
YOU said "Not on a recent Mac, it makes no difference" [AAA] above.

> literally costs noting at all, do difference in speed, no impact on the
> data safety, nothing at all. It does not matter if you do it before or

<S>

Why, when I first replied to the fellow I said: "Filevault on and
Encrypt on migration. Negligible performance hit.".

You really need to cool yer jets before you hit the keyboard.

[Alan Browne]

On 2021-12-15 15:40, Lewis wrote:
> In message <OYouJ.64137$zF3....@fx03.iad> Alan Browne <bitb...@blackhole.com> wrote:
>> The performance cost of Filevault on a T2/Mx Mac is negligible
>
> You keep repeating this mistake. It is *zero* performance cost.

Look up "negligible" and stop with the trifling answers.

>
>> and only carries the cost of a safe place for the password.
>
> And you can use your account password as the key. I=Of course, have a
> decent password on *ALL* accounts, but only a fool would not do that
> anyway.

I'm sure you're the only person in the world with decent passwords. /s

[Lewis]

But you keep repeating the same BS.

>> There is NO REASON to not encrypt your drive on a modern Mac, it

> Above: I said "Better: encrypt on migration."
> Nospam said "yep"

But it matters not one tiny bit when you do it. Before or after is
meaningless.

> Why, when I first replied to the fellow I said: "Filevault on and
> Encrypt on migration. Negligible performance hit.".

Which is the mistake you keep repeating over and over. There is NO
performance hit. None. At all. Zero. Zilch. Nada. Nil.

> You really need to cool yer jets before you hit the keyboard.

You really need to stop repeating the same misinformation.

--
Like the moment when the brakes lock/And you slide towards the big
truck/You stretch the frozen moments with your fear

[Lewis]

In message <MAsuJ.122613$aF1.1...@fx98.iad> Alan Browne <bitb...@blackhole.com> wrote:
> On 2021-12-15 15:40, Lewis wrote:
>> In message <OYouJ.64137$zF3....@fx03.iad> Alan Browne <bitb...@blackhole.com> wrote:
>>> The performance cost of Filevault on a T2/Mx Mac is negligible
>>
>> You keep repeating this mistake. It is *zero* performance cost.

> Look up "negligible" and stop with the trifling answers.

I know perfectly well what it mans, and it is not applicable here.
Negligible means there is a difference that *in your opinion) doesn’t
matter, That is not the case, as there is NO difference.

Stop repeating the same error over and over, you are misleading people
and you are completely 100% wrong.


--
if you ever get that chimp off your back, if you ever find the thing
you lack, ah but you know you're only having a laugh. Oh, oh here
we go again -- until the end.

[Alan Browne]

On 2021-12-15 22:48, Lewis wrote:
> In message <MAsuJ.122613$aF1.1...@fx98.iad> Alan Browne <bitb...@blackhole.com> wrote:
>> On 2021-12-15 15:40, Lewis wrote:
>>> In message <OYouJ.64137$zF3....@fx03.iad> Alan Browne <bitb...@blackhole.com> wrote:
>>>> The performance cost of Filevault on a T2/Mx Mac is negligible
>>>
>>> You keep repeating this mistake. It is *zero* performance cost.
>
>> Look up "negligible" and stop with the trifling answers.
>
> I know perfectly well what it mans, and it is not applicable here.
> Negligible means there is a difference that *in your opinion) doesn’t
> matter, That is not the case, as there is NO difference.
>
> Stop repeating the same error over and over, you are misleading people
> and you are completely 100% wrong.

No inline conversion can be 0 time. Very fast though.

But negligible.

Trifle on though.

[Lewis]

In message <aAJuJ.155127$831.1...@fx40.iad> Alan Browne <bitb...@blackhole.com> wrote:
> On 2021-12-15 22:48, Lewis wrote:
>> In message <MAsuJ.122613$aF1.1...@fx98.iad> Alan Browne <bitb...@blackhole.com> wrote:
>>> On 2021-12-15 15:40, Lewis wrote:
>>>> In message <OYouJ.64137$zF3....@fx03.iad> Alan Browne <bitb...@blackhole.com> wrote:
>>>>> The performance cost of Filevault on a T2/Mx Mac is negligible
>>>>
>>>> You keep repeating this mistake. It is *zero* performance cost.
>>
>>> Look up "negligible" and stop with the trifling answers.
>>
>> I know perfectly well what it mans, and it is not applicable here.
>> Negligible means there is a difference that *in your opinion) doesn’t
>> matter, That is not the case, as there is NO difference.
>>
>> Stop repeating the same error over and over, you are misleading people
>> and you are completely 100% wrong.

> No inline conversion can be 0 time. Very fast though.

There is no "inline conversion". Stop making up things. If you do not
understand what is happening, you can look it up instead of opining
nonsense.

--
Vernon: Now this is the thought that wakes me up in the middle of the
night. That when I get older, these kids are going to take care
of me
Carl: I wouldn't count on it.

[Alan Browne]

On 2021-12-16 16:58, Lewis wrote:
> In message <aAJuJ.155127$831.1...@fx40.iad> Alan Browne <bitb...@blackhole.com> wrote:
>> On 2021-12-15 22:48, Lewis wrote:
>>> In message <MAsuJ.122613$aF1.1...@fx98.iad> Alan Browne <bitb...@blackhole.com> wrote:
>>>> On 2021-12-15 15:40, Lewis wrote:
>>>>> In message <OYouJ.64137$zF3....@fx03.iad> Alan Browne <bitb...@blackhole.com> wrote:
>>>>>> The performance cost of Filevault on a T2/Mx Mac is negligible
>>>>>
>>>>> You keep repeating this mistake. It is *zero* performance cost.
>>>
>>>> Look up "negligible" and stop with the trifling answers.
>>>
>>> I know perfectly well what it mans, and it is not applicable here.
>>> Negligible means there is a difference that *in your opinion) doesn’t
>>> matter, That is not the case, as there is NO difference.
>>>
>>> Stop repeating the same error over and over, you are misleading people
>>> and you are completely 100% wrong.
>
>> No inline conversion can be 0 time. Very fast though.
>
> There is no "inline conversion". Stop making up things. If you do not
> understand what is happening, you can look it up instead of opining
> nonsense.

Oh dear Lewis, you need to stop flinging stones.

Yes, I am in error for the case of a T2 or Mx processor, there would be
no difference whether FileVaulted or not. When I was writing I wasn't
accounting for the default encryption being on whether Filevault
encryption was on or not.

But of course it is inline conversion as it happens directly between the
CPU and the storage device: CPU ----> T2 ----> Storage.

(Or CPU <---- T2 <---- Storage for read).

(Where T2 can be replaced by the same functionality within the M1).

[Doc O'Leary]

For your reference, records indicate that

Lewis <g.k...@kreme.dont-email.me> wrote:

> In message <spd4qp$g7n$1...@dont-email.me> Doc O'Leary <drol...@2017usenet1.subsume.com> wrote:
>
> > OK, but be honest with yourself about your threat profile. Apple’s tools
> > are fine if you only thoughtlessly play in the Apple ecosystem. Once you
> > start using other technology, interoperable solutions are more useful.
>
> there's a meaningless paragraph.

Sorry to hear about your lack of technical know-how.

> > It has never made sense for me to use Migration Assistant.
>
> That seems like a PEBKAC problem to me, but you be you.

Sorry to hear you have difficulty with perspective-taking.

> > Any data that is important to me is not exclusively on my Mac (nor do
> > I have just one Mac). I have backups, and I’m better served by
> > testing them with the new machine than just importing all the cruft
> > that built up on my old machine.
>
> Ah, the legendary 'cruft' bullshit. Spoken like a Windows user.

Are you just here to troll, or what? I’ve been using Macs since the 80s.
All sorts of software comes and goes over decades of use, and I don’t need
things like preference files, caches, and all sorts of other stuff hanging
around for no reason. I much prefer to curate my systems, and for me that
means being able to start from scratch on a new setup without having to
rely on proprietary tools to carry everything forward. Again, sorry you
have trouble understanding things like that.

> When I migrated my data to this new MBA I ended up with an exact copy of
> what was on my other computer at the time, INCLUDING all the shell tools
> I had installed, scripts I had written, preferences and nearly all
> settings. It was then the task of a few minutes to delete things I did
> not need to have on the laptop.

As I stated, I don’t just have a singular “other” Mac. I need to actively
sync my work on a number of computers, including non-Apple hardware, not
just simply migrate/copy everything from old to new.

> And yes, Migration Assistant is a perfectly good way to test your backups
> since the simplest way to migrate is to boot off your time machine
> volume and migrate from it.

Again, Apple-only solutions like Time Machine don’t work for those of us
who *do* indeed need to venture outside the walled garden.

> > Likewise, FileVault only serves to protect the Mac, not the data.
>
> What the fuck are you talking about? It protects *EVERYTHING* on the
> computer.

Your words make me doubt that I can explain anything in a simple enough
manner for you to understand. Encryption simply is not the beginning
and end of data security. If someone has told you otherwise, you’re
working off of bad information.

> A lesser computer's inability to protect your data has nothing
> whatsoever to do with macOS or FileVault.

Very bad information indeed.

[Lewis]

In message <K4PuJ.40982$bo.2...@fx18.iad> Alan Browne <bitb...@blackhole.com> wrote:
> On 2021-12-16 16:58, Lewis wrote:
>> In message <aAJuJ.155127$831.1...@fx40.iad> Alan Browne <bitb...@blackhole.com> wrote:
>>> On 2021-12-15 22:48, Lewis wrote:
>>>> In message <MAsuJ.122613$aF1.1...@fx98.iad> Alan Browne <bitb...@blackhole.com> wrote:
>>>>> On 2021-12-15 15:40, Lewis wrote:
>>>>>> In message <OYouJ.64137$zF3....@fx03.iad> Alan Browne <bitb...@blackhole.com> wrote:
>>>>>>> The performance cost of Filevault on a T2/Mx Mac is negligible
>>>>>>
>>>>>> You keep repeating this mistake. It is *zero* performance cost.
>>>>
>>>>> Look up "negligible" and stop with the trifling answers.
>>>>
>>>> I know perfectly well what it mans, and it is not applicable here.
>>>> Negligible means there is a difference that *in your opinion) doesn’t
>>>> matter, That is not the case, as there is NO difference.
>>>>
>>>> Stop repeating the same error over and over, you are misleading people
>>>> and you are completely 100% wrong.
>>
>>> No inline conversion can be 0 time. Very fast though.
>>
>> There is no "inline conversion". Stop making up things. If you do not
>> understand what is happening, you can look it up instead of opining
>> nonsense.

> Oh dear Lewis, you need to stop flinging stones.

> Yes, I am in error for the case of a T2 or Mx processor

Not just once, but over and over and over again.

> But of course it is inline conversion as it happens directly between the
> CPU and the storage device: CPU ----> T2 ----> Storage.

No, because that is how data is ALWAYS routed on modern macs, so there is no
"difference".

--
Girl wins her man after showing off her legs and not talking
(The Little Mermaid)

[Lewis]

In message <spgpbl$qmq$1...@dont-email.me> Doc O'Leary <drol...@2017usenet1.subsume.com> wrote:
> For your reference, records indicate that
> Lewis <g.k...@kreme.dont-email.me> wrote:

>> In message <spd4qp$g7n$1...@dont-email.me> Doc O'Leary <drol...@2017usenet1.subsume.com> wrote:
>>
>> > OK, but be honest with yourself about your threat profile. Apple’s tools
>> > are fine if you only thoughtlessly play in the Apple ecosystem. Once you
>> > start using other technology, interoperable solutions are more useful.
>>
>> there's a meaningless paragraph.

> Sorry to hear about your lack of technical know-how.

You spout meaningless buzzword bingo nonsense it doesn't make it
"technical".

>> > It has never made sense for me to use Migration Assistant.
>>
>> That seems like a PEBKAC problem to me, but you be you.

> Sorry to hear you have difficulty with perspective-taking.

>> > Any data that is important to me is not exclusively on my Mac (nor do
>> > I have just one Mac). I have backups, and I’m better served by
>> > testing them with the new machine than just importing all the cruft
>> > that built up on my old machine.
>>
>> Ah, the legendary 'cruft' bullshit. Spoken like a Windows user.

> Are you just here to troll, or what? I’ve been using Macs since the 80s.

And you seem to think it is still the 80s. And big whoop, I bet most
everyone here has been using macs since the 80s.

> All sorts of software comes and goes over decades of use, and I don’t need
> things like preference files, caches

So, you have no fucking clue what migration assisstant does. Good to
know.

, and all sorts of other stuff hanging
> around for no reason. I much prefer to curate my systems, and for me that
> means being able to start from scratch on a new setup without having to
> rely on proprietary tools to carry everything forward. Again, sorry you
> have trouble understanding things like that.

As I said, that is a PEBKAC issue, you want to do dumb things slowly to
get your feels, that is up to you.

>> And yes, Migration Assistant is a perfectly good way to test your backups
>> since the simplest way to migrate is to boot off your time machine
>> volume and migrate from it.

> Again, Apple-only solutions like Time Machine don’t work for those of us
> who *do* indeed need to venture outside the walled garden.

Utter bullshit. I manage a group of FreeBSD servers and that does not
stop me at all from using my mac and my Mac's software.

>> > Likewise, FileVault only serves to protect the Mac, not the data.
>>
>> What the fuck are you talking about? It protects *EVERYTHING* on the
>> computer.

> Your words make me doubt that I can explain anything in a simple enough

Your words are idiocy. FileVault absolutely does protect the data. Your
inability articulate coherent thoughts is a you problem.

> manner for you to understand. Encryption simply is not the beginning
> and end of data security.

No one claimed it was.

>> A lesser computer's inability to protect your data has nothing
>> whatsoever to do with macOS or FileVault.

> Very bad information indeed.

Why don't you try actually forming complete thoughts instead of vague
nonsense that makes you feel like you know what you are talking about,
even a little bit.



--
<https://en.wikipedia.org/wiki/Posting_style#Top-posting>

[Alan Browne]

On 2021-12-17 00:32, Lewis wrote:
> In message <K4PuJ.40982$bo.2...@fx18.iad> Alan Browne <bitb...@blackhole.com> wrote:
>> On 2021-12-16 16:58, Lewis wrote:
>>> In message <aAJuJ.155127$831.1...@fx40.iad> Alan Browne <bitb...@blackhole.com> wrote:
>>>> On 2021-12-15 22:48, Lewis wrote:
>>>>> In message <MAsuJ.122613$aF1.1...@fx98.iad> Alan Browne <bitb...@blackhole.com> wrote:
>>>>>> On 2021-12-15 15:40, Lewis wrote:
>>>>>>> In message <OYouJ.64137$zF3....@fx03.iad> Alan Browne <bitb...@blackhole.com> wrote:
>>>>>>>> The performance cost of Filevault on a T2/Mx Mac is negligible
>>>>>>>
>>>>>>> You keep repeating this mistake. It is *zero* performance cost.
>>>>>
>>>>>> Look up "negligible" and stop with the trifling answers.
>>>>>
>>>>> I know perfectly well what it mans, and it is not applicable here.
>>>>> Negligible means there is a difference that *in your opinion) doesn’t
>>>>> matter, That is not the case, as there is NO difference.
>>>>>
>>>>> Stop repeating the same error over and over, you are misleading people
>>>>> and you are completely 100% wrong.
>>>
>>>> No inline conversion can be 0 time. Very fast though.
>>>
>>> There is no "inline conversion". Stop making up things. If you do not
>>> understand what is happening, you can look it up instead of opining
>>> nonsense.
>
>> Oh dear Lewis, you need to stop flinging stones.
>
>> Yes, I am in error for the case of a T2 or Mx processor
>
> Not just once, but over and over and over again.

Since you didn't clarify before, you can't complain over it. Lighten up.

>
>> But of course it is inline conversion as it happens directly between the
>> CPU and the storage device: CPU ----> T2 ----> Storage.
>
> No, because that is how data is ALWAYS routed on modern macs, so there is no
> "difference".

Exactly: inline.

[Alan Browne]

On 2021-12-17 00:32, Lewis wrote:

Forgot to add: The T2 appeared in 2017. So there are an awful lot of
modern macs that predate that and are still in use. Oodles.

(The T1 did not provide storage encryption).

[Wade Garrett]

On 12/11/21 7:23 AM, Wade Garrett wrote:
> Got a new Mac coming to replace my current one which has FileVault
> turned on.
>
> Better/easier to FileVault the new machine before or after transferring
> data to it via Migration Assistant?
>

OP here.

So I FileVaulted the new Mac during setup. Decided to manually copy over
selected data later rather than use Migration Assistant. No problems,
went quick, working fine.

OK...resume name calling and character assassination ;-)

--
The real reason Santa is so jolly is because he knows where all the
naughty girls live

[Doc O'Leary]

For your reference, records indicate that
Lewis <g.k...@kreme.dont-email.me> wrote:

> In message <spgpbl$qmq$1...@dont-email.me> Doc O'Leary <drol...@2017usenet1.subsume.com> wrote:
> > For your reference, records indicate that
> > Lewis <g.k...@kreme.dont-email.me> wrote:
>
> >> In message <spd4qp$g7n$1...@dont-email.me> Doc O'Leary <drol...@2017usenet1.subsume.com> wrote:
> >>
> >> > OK, but be honest with yourself about your threat profile. Apple’s tools
> >> > are fine if you only thoughtlessly play in the Apple ecosystem. Once you
> >> > start using other technology, interoperable solutions are more useful.
> >>
> >> there's a meaningless paragraph.
>
> > Sorry to hear about your lack of technical know-how.
>
> You spout meaningless buzzword bingo nonsense it doesn't make it
> "technical".

What buzzwords am I using? I am speaking to general concepts in modern
computing. Again, I’m sorry if such things come across to you as
nonsense. For your own sake, instead of attacking, seek clarity.

> So, you have no fucking clue what migration assisstant does. Good to
> know.

It’s quite possible Apple has massively revamped it since I last used it,
but the onus is on them (or you as their profane proxy) to explain the
changes. You shed no light on how it could possibly cover my use case.

> > Again, Apple-only solutions like Time Machine don’t work for those of us
> > who *do* indeed need to venture outside the walled garden.
>
> Utter bullshit. I manage a group of FreeBSD servers and that does not
> stop me at all from using my mac and my Mac's software.

Well, then, instead of cursing left and right, how about you enlighten us
all on how you do things? How did you get Time Machine to back up your
FreeBSD machines? How do you use Migration Assistant to keep your
various working accounts in sync?

Yes, I use Apple’s software on Apple’s hardware when it makes sense. But
Apple has been going out of their way to make things less useful the
instant you introduce non-Apple solutions into the mix. That’s precisely
why I said FileVault protects the Mac, but not necessarily the *data*,
because the decrypted files may be shared (or sometimes stolen) any number
of ways that obviate any security FileVault provides.

> >> What the fuck are you talking about? It protects *EVERYTHING* on the
> >> computer.
>
> > Your words make me doubt that I can explain anything in a simple enough
>
> Your words are idiocy. FileVault absolutely does protect the data. Your
> inability articulate coherent thoughts is a you problem.

See above. You’re making a fool of yourself.

> > manner for you to understand. Encryption simply is not the beginning
> > and end of data security.
>
> No one claimed it was.

You certainly seem to be doing that. See above.

> Why don't you try actually forming complete thoughts instead of vague
> nonsense that makes you feel like you know what you are talking about,
> even a little bit.

Such hostility is both tragic and unnecessary. Have you been affected
severely by the pandemic, or is there some other hardship in your life
that has left you thinking that lashing out at strangers is the best way
to move through the world? Regardless, I am not your enemy. Change
your tone and we can have a productive discussion. Otherwise, I’m
warming up my killfile.

[Lewis]

In message <spl98i$ggv$1...@dont-email.me> Doc O'Leary <drol...@2017usenet1.subsume.com> wrote:
> For your reference, records indicate that
> Lewis <g.k...@kreme.dont-email.me> wrote:

>> In message <spgpbl$qmq$1...@dont-email.me> Doc O'Leary <drol...@2017usenet1.subsume.com> wrote:
>> > For your reference, records indicate that
>> > Lewis <g.k...@kreme.dont-email.me> wrote:
>>
>> >> In message <spd4qp$g7n$1...@dont-email.me> Doc O'Leary <drol...@2017usenet1.subsume.com> wrote:
>> >>
>> >> > OK, but be honest with yourself about your threat profile. Apple’s tools
>> >> > are fine if you only thoughtlessly play in the Apple ecosystem. Once you
>> >> > start using other technology, interoperable solutions are more useful.
>> >>
>> >> there's a meaningless paragraph.
>>
>> > Sorry to hear about your lack of technical know-how.
>>
>> You spout meaningless buzzword bingo nonsense it doesn't make it
>> "technical".

> What buzzwords am I using?

I'm sorry, I mistook you for being literate.

--
“Yes yes, you’re a little mangey”

[Doc O'Leary]

For your reference, records indicate that
Lewis <g.k...@kreme.dont-email.me> wrote:

> I'm sorry, I mistook you for being literate.

I’ve given you every opportunity to act more civil, and you have refused.
So trolling all the way into my killfile it is. Wait, is this you:

g.k...@gmail.com

? I guess you’ve demonstrated your inability to act like an adult to me
in the past. Just the 35th entry, too, so you’ve intentionally been a
jerk for quite a while, haven’t you? That’s sad for you; I hope you find
the help you need. Not sure when you nym-shifted (BTW, Usenet hasn’t be
a ripe target for spammers in 5+ years), but your new one is now resting
comfortably next to the old one.

Shame on me for feeding the troll, though. I apologize to the group for
thinking “Lewis” was worth engaging with.

[Lewis]

In message <spofcf$mgf$1...@dont-email.me> Doc O'Leary <drol...@2017usenet1.subsume.com> wrote:
> For your reference, records indicate that
> Lewis <g.k...@kreme.dont-email.me> wrote:

>> I'm sorry, I mistook you for being literate.

> I’ve given you every opportunity to act more civil, and you have refused.

But you have succeeded in acting like an idiot spouting nonsense.

> So trolling all the way into my killfile it is. Wait, is this you:

> g.k...@gmail.com

Well, you can at least pattern match, even if you cannot seem to read.

Announcing you are killfiling someone is the true mark of the desperate
troll. It's the equivalent of the 5 year screeching "Oh yeah! Well I'm
not talking to you ever again."

Boo hoo. I's so crushed, princess. I sure will miss your inane replies
devoid of content or meaning.

--
I don't believe there's a power in the 'verse can stop Kaylee from
bein' cheerful. Sometimes you just wanna duct-tape her mouth and
dump her in the hold for a month.

[Dustin Kook]

Several of us reported him years ago. As expected, it did not a thing
to thwart the imbecile. Onion Knight's behavior is totally thoroughly
disingenuous. There is no dispute that as soon as any pardoned 'plonkee'
does one thing to offend the poor daisy's feelings that they'll be reblocked.
Did he think that was clever? Gee, imagine Onion Knight trying to pin
his rubbish on others, no one has ever seen that before ¯\_(ツ)_/¯.

Not long ago I did work on and showed some JavaScript for the front
end which is the only thing you can do when trying to avoid Onion Knight's
immature crap while reading with Google Groups. You're like a bowling
pin in a needle-stack. We all see you there and wonder how you can be
so stupid. And you're so stupid you keep repeating it.


--
One Smart Penny
https://www.walmart.com/browse/books/family-kids-books/cary-fagan/3920_582053_585918/YnJhbmQ6Q2FyeSBGYWdhbgieie
<https://groups.google.com/g/comp.sys.mac.apps/c/VMCw29DnV84>
Narcissistic Bigot Steve Carroll