Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Backups

40 views
Skip to first unread message

Jeff Layman

unread,
Nov 2, 2023, 4:23:22 PM11/2/23
to
Any views about backing up an Android phone? When I used Windows, I
regularly backed that up with Acronis or EaseUS Todo to an external
drive. Now I'm using Linux, I backup data ("Backups") to external USB
sticks and OS (Timeshift - not strictly a backup) to the internal HD.
Backing up to an external drive has always been very straightforward,
but Android seems less accommodating.

I should say that I have very little need to backup my phone, as I don't
use it for anything important. If I take any photos I want to keep, I'll
copy them to my laptop within a day. I also never use Cloud storage.

My Xiaomi phone has a built-in backup app, but of course that seems to
require a Xiaomi account with backup to Xiaomi cloud storage. However, a
little more digging into "Settings" reveals it can store in The Cloud,
or locally - either as "Mobile Device - Back up and restore items on
this device", or "Computer - Back up and restore it". However, the
"Mobile Device" backup says "This feature allows you to backup and
restore items using your mobile device and computer. This feature needs
to connect to the internet and requires the following mandatory
permissions to work:" There follows a list with accessing contacts and
call history for backing up, and editing contacts and call history to
restore, accessing storage for backing up files, and saving items to
storage for restoring items (what these items are it doesn't specify.
Are they files?). Finally it needs to access messages to back them up
(but there's nothing about restoring them). Why does it have to do this
through the internet, though? I have to agree to this before progressing
to the next info page, but haven't done so, so don't know exactly how
the computer is involved.

Looking at other backup apps on Play Store or F-Droid shows how confused
the picture is. Some backup specifics like apps, contacts, SMS/MMS
messages, or photos, while others do several. Some state they can't
backup data as root access is required. Some say they can backup to an
internal card, and only then copy from that card to an external store.

Why is backing up in Android apparently so complicated? Why can't I do
as simply as I would with Windows or Linux via USB (or Wi-Fi)? And I
haven't even looked at the issue of whether or not it is straightforward
to restore from a backup.

--

Jeff

Ed Cryer

unread,
Nov 2, 2023, 5:07:28 PM11/2/23
to
All phone companies I've used offer their own backup services; Google,
Huwaei, Samsung. You find them usually pre-installed on your phone.

I have a feeling, however, that you're a Windows-conditioned-man, and
are used to independent imaging and cloning software.
If so, I'm on your side. But I don't know where to get it.

Ed

Wally J

unread,
Nov 2, 2023, 5:29:22 PM11/2/23
to
Jeff Layman <Je...@invalid.invalid> wrote

> Any views about backing up an Android phone?

It's a perennial topic which comes up frequently on this newsgroup.
While backup is trivial, you should plan ahead for a proper backup.

For example, the Android phone and Windows are the same file system.

Every Android phone in your house is mounted to every Windows PC.
<https://i.postimg.cc/QtbR1GY0/webdav13.jpg>

Over the WI-Fi Lan. So if you're at home - it's the same file system.
<https://i.postimg.cc/hjkVFyqJ/scrcpy07.jpg>

Plus the apps can be installed from Windows simply by sliding them.
<https://i.postimg.cc/wvsbcNBz/scrcpy05.jpg>

And they can be deleted from Windows simply by running adb commands.
<https://i.postimg.cc/3xz7Qtrn/adb06.jpg>

All this stuff has been covered in gory detail on this newsgroup.

Suffice to summarize Android & Windows are exactly the same files.
You can act on Windows files from Android & vice versa all you want.

Meaning backup up Android is no different than backing up Windows.
They're the same files on both systems, in fact. And the same GUI.
<https://i.postimg.cc/k5gv0yw8/vysor34.jpg>

> When I used Windows, I
> regularly backed that up with Acronis or EaseUS Todo to an external
> drive. Now I'm using Linux, I backup data ("Backups") to external USB
> sticks and OS (Timeshift - not strictly a backup) to the internal HD.
> Backing up to an external drive has always been very straightforward,
> but Android seems less accommodating.

Google makes it pretty easy to back up & restore any Android phone.
So does Samsung.
Not sure about the other OEMs.

It requires an account though.

> I should say that I have very little need to backup my phone, as I don't
> use it for anything important. If I take any photos I want to keep, I'll
> copy them to my laptop within a day. I also never use Cloud storage.

Everyone organizes their kitchen utensils differently but everyone
organizes them. Organizing Android is no different than your kitchen.

It looks complex but it's the same in every kitchen where forks go with the
forks & spoons, the pots with the pots & pans, the dishes with the bowls
and saucers, etc. It's not any different with Android.

Most people have the camera set to store the images/videos on the external
sdcard (and if they don't have one, they usually have huge internal storage
because, basically, the only phones without the sd slot are the very high
end phones where people are supposed to pay more for internal storage and
also pay more for the cloud storage to compensate for the loss of the
sdcard slot). IMHO.

> My Xiaomi phone has a built-in backup app, but of course that seems to
> require a Xiaomi account with backup to Xiaomi cloud storage.

Most of the apps will require an account. The canonical backup app is
"titanium backup", but it has requirements to (e.g., root access).

> However, a
> little more digging into "Settings" reveals it can store in The Cloud,
> or locally - either as "Mobile Device - Back up and restore items on
> this device", or "Computer - Back up and restore it". However, the
> "Mobile Device" backup says "This feature allows you to backup and
> restore items using your mobile device and computer. This feature needs
> to connect to the internet and requires the following mandatory
> permissions to work:" There follows a list with accessing contacts and
> call history for backing up, and editing contacts and call history to
> restore, accessing storage for backing up files, and saving items to
> storage for restoring items (what these items are it doesn't specify.
> Are they files?). Finally it needs to access messages to back them up
> (but there's nothing about restoring them). Why does it have to do this
> through the internet, though? I have to agree to this before progressing
> to the next info page, but haven't done so, so don't know exactly how
> the computer is involved.

What seems to be happening, at least for me, as I usually get my phones for
free or low cost, is that the expansion cards are vastly bigger than my
internal storage.

When I had 16GB Androids, I had 32GB expansion cards.
When I had 32GB Androids, I had 64GB expansion cards.
When I had 64GB Androids, I had 128GB expansion cards.

The expansion card can hold more than the internal storage of the phone so
everything I wanted to make a copy of would be saved to the expansion card.

> Looking at other backup apps on Play Store or F-Droid shows how confused
> the picture is. Some backup specifics like apps, contacts, SMS/MMS
> messages, or photos, while others do several. Some state they can't
> backup data as root access is required. Some say they can backup to an
> internal card, and only then copy from that card to an external store.

Again, we've covered in gory detail all the SMS/MMS backup solutions.
There are many.

> Why is backing up in Android apparently so complicated?

It's not. It's no more complicated than your kitchen is.

> Why can't I do
> as simply as I would with Windows or Linux via USB (or Wi-Fi)? And I
> haven't even looked at the issue of whether or not it is straightforward
> to restore from a backup.

I do on Windows exactly what I do on Android and it works fine for me.
But I'm organized.

For example, I use the Nova free app launcher which saves the organization
of the homescreen folders and apps, and it backs them up to a file.

That way I can just reload that file into any other phone and all the app
icons in all the app folders in all the same positions is installed.

For my photos I keep them on the (always twice-the-size) external sd card.
Same with all my maps.
And videos.

For my other files, I keep a folder called "0000" on the internal sdcard.
And I keep a folder called "0001" on the external sdcard.

And I put everything I care about there.
That way, those are the only two folders I have to care about copying.

As for the apps, they're automatically backed up to a Windows drive letter
the instant they're installed (as the APK is simply not deleted).

All this would take me a while to re-explain but EVERY SINGLE THING I've
explained above we've covered on this newsgroup already in gory detail.

Wally J

unread,
Nov 2, 2023, 5:50:07 PM11/2/23
to
Ed Cryer <e...@somewhere.in.the.uk> wrote

> I have a feeling, however, that you're a Windows-conditioned-man, and
> are used to independent imaging and cloning software.
> If so, I'm on your side. But I don't know where to get it.

We've discussed backup solutions (e.g., Titanium backup & SMS/MMS backups)
umpteen times on this newsgroup so I have nothing new to offer other than a
summary that backup is so trivial that it happens automatically every day.

For example, all your Android phones are already mounted over your Wi-Fi
LAN as a drive letter on Windows - so why not use Windows backup tools?
<https://i.postimg.cc/BvJdKWzt/webdav06.jpg> Both sdcards mounted

The entire Android phone is simply a set of files on the Windows filesys.

Why can't you copy your entire Android user storage over to Windows?
(Actually, you'd likely copy it to a 5TB drive hanging off Windows).

Like this:
<https://i.postimg.cc/zD9P15FX/sdcard11.jpg> OsmAnd~ Windows confirmation
<https://i.postimg.cc/ZK4pNMTx/sdcard12.jpg> OsmAnd~ Android confirmation

Hence...

What's to stop you from simply _copying_ the entire Android phone to
Windows (even if you're not rooted - as most files are read access)?

Even all your APKs are saved to a Windows drive letter upon installation.
<https://i.postimg.cc/c4PrjSwx/aurora19.jpg> Save all APKs upon install
(Actually, to be clear, they're "not deleted", but that's the same thing.)
<https://i.postimg.cc/V6tyDpNd/aurora17.jpg> Don't delete APKs postinstall

The point is you can _copy_ Android to Windows even if you don't mount it.
<https://i.postimg.cc/BvJdKWzt/webdav06.jpg> Both sdcards mounted

For example, let's take the trivial example of copying the HOSTS file
from Android over to Windows (as just the simplest of examples).

On Windows, you run this command - and the HOSTS file is backed up.
C:\> adb pull /system/etc/hosts .\hosts.txt
That should copy the hosts file over even if you're unrooted.

Anyway, all this has been covered umpteen times on this newsgroup.
In gory detail.

My main point is that Android _is_ Windows.
The files are the same.

A "copy" of Android to Windows is trivial.

And vice versa (although you wouldn't usually copy Windows to Android
except for when you install your APK from your Windows file system).
<https://i.postimg.cc/wvsbcNBz/scrcpy05.jpg> Drag APK from Windows



Jörg Lorenz

unread,
Nov 3, 2023, 1:34:25 AM11/3/23
to
Am 02.11.23 um 21:23 schrieb Jeff Layman:
> I also never use Cloud storage.

In this case you are missing the most comfortable and most reliable way
to backup your Android on the go with Google.

--
Gutta cavat lapidem (Ovid)

Jörg Lorenz

unread,
Nov 3, 2023, 1:38:14 AM11/3/23
to
Am 02.11.23 um 21:23 schrieb Jeff Layman:
Very very complicated. Drop your old habits and use Google Cloud.

Jeff Layman

unread,
Nov 3, 2023, 4:27:18 AM11/3/23
to
Nope. Google has enough of my private info without me making it simple
for them. Do you really believe that Google doesn't scan all the info
you store on their Cloud servers? From a very recent article at
<https://www.comparitech.com/blog/information-security/google-drive-secure/#Google_Drive_privacy_issues>:

"Google has, over the years, perfected the art of surveillance
capitalism—where your data is mined and sold to advertisers, which is
then used to manipulate or influence your buying behavior."

You might also find it interesting to read the section "Relinquishing
control".

--

Jeff

Jörg Lorenz

unread,
Nov 3, 2023, 5:13:10 AM11/3/23
to
Am 03.11.23 um 09:27 schrieb Jeff Layman:
Why in the first place did you buy an Android smartphone? Google has
your data anyway.

> "Google has, over the years, perfected the art of surveillance
> capitalism—where your data is mined and sold to advertisers, which is
> then used to manipulate or influence your buying behavior."
>
> You might also find it interesting to read the section "Relinquishing
> control".

No. I use my Pixel sometimes but the really important things are done on
a different OS.

You are obviously lacking a coherent strategy. Conspiracy theories
really don't help at all.

Theo

unread,
Nov 3, 2023, 9:31:38 AM11/3/23
to
Jeff Layman <Je...@invalid.invalid> wrote:

> Looking at other backup apps on Play Store or F-Droid shows how confused
> the picture is. Some backup specifics like apps, contacts, SMS/MMS
> messages, or photos, while others do several. Some state they can't
> backup data as root access is required. Some say they can backup to an
> internal card, and only then copy from that card to an external store.
>
> Why is backing up in Android apparently so complicated? Why can't I do
> as simply as I would with Windows or Linux via USB (or Wi-Fi)? And I
> haven't even looked at the issue of whether or not it is straightforward
> to restore from a backup.

The problem is that, on Windows, you can get access to all your user
files in C:\Users\username so you can backup all the user state. On
Android there are security protections in place so one app can't access
another app's files. On Windows, if you have admin rights, you can
access every file. On Android you need root for that, which is
something the system is designed to not let you have, for the same
security reasons.

So if you don't have root, you have to rely on whatever backup
mechanisms the system lets you have. That might be:

1 Individual apps 'export my data options'
2 Grabbing whatever parts of the filesystem a backup app is allowed to
access
3 adb backup (unreliable)
4 Cloud backups

For #2, Syncthing is a handy tool for syncing (parts of) the phone
storage to another machine. But it doesn't get you data which is held
by apps (eg in a database) rather than stored on your filesystem.

Theo

Adrian

unread,
Nov 3, 2023, 10:30:16 AM11/3/23
to
In message <YIy*n2...@news.chiark.greenend.org.uk>, Theo
<theom...@chiark.greenend.org.uk> writes
>The problem is that, on Windows, you can get access to all your user
>files in C:\Users\username so you can backup all the user state. On
>Android there are security protections in place so one app can't access
>another app's files. On Windows, if you have admin rights, you can
>access every file. On Android you need root for that, which is
>something the system is designed to not let you have, for the same
>security reasons.
>

Am I missing something here ? If I plug my Android phone (or tablet)
into my PC using a USB lead, I can download data from it. That is
generally how I copy off photos that I want to use elsewhere. So if I
can do that for photos, what is to stop me downloading the rest of the
data on the device onto a PC, or in other words, backing it up ?

Adrian
--
To Reply :
replace "bulleid" with "adrian" - all mail to bulleid is rejected
Sorry for the rigmarole, If I want spam, I'll go to the shops
Every time someone says "I don't believe in trolls", another one dies.

Andy Burns

unread,
Nov 3, 2023, 10:38:29 AM11/3/23
to
Adrian wrote:

> If I plug my Android phone (or tablet) into my PC using a USB lead, I
> can download data from it.  That is generally how I copy off photos that
> I want to use elsewhere.  So if I can do that for photos, what is to
> stop me downloading the rest of the data on the device onto a PC

Because what you see on the PC when connected by USB are only the
folders that the phone chooses to let you see, rather than the entire
file structure.

AJL

unread,
Nov 3, 2023, 12:01:29 PM11/3/23
to
On 11/3/2023 1:27 AM, Jeff Layman wrote:

> Do you really believe that Google doesn't scan all the info you store
> on their Cloud servers?

I think it's a philosophical question. If a HUMAN reads my stuff it
would bother me. If my stuff is bits and bytes in a SERVER somewhere,
not so much.

If you're bothered by the bits and bytes server scenario then you better
cancel all your credit cards, never use any doctors, don't drive, don't
work, don't pay taxes, in other words don't have a life. Because your
life is on dozens of servers that you have no control over whether you
use Google or not...

> <https://www.comparitech.com/blog/information-security/google-drive-secure/#Google_Drive_privacy_issues>:

Interesting article. I liked this quote:

"For most computer users, Google Drive is more reliable, automatically
backed up, relatively safe from ransomware, and almost certainly more
secure from theft. In general, the benefits largely outweigh the risks."

> "Google has, over the years, perfected the art of surveillance
> capitalism—where your data is mined and sold to advertisers, which
> is then used to manipulate or influence your buying behavior."

They're pretty sneaky here. I've used Google Drive for years and have
yet to be able to tie any advertising to it. Where are the ads??

> You might also find it interesting to read the section
> "Relinquishing control".

Scary. Kinda like the legal mumbo-jumbo I gotta sign for a lot of
services (like the doctor). Does anybody read all those pages of
legalese before they sign...



Frank Slootweg

unread,
Nov 3, 2023, 12:38:33 PM11/3/23
to
That is true, but the USB/MTP connection to a Windows system lets you
see *more* than is available to an app on the phone.

For example with this connection, on Windows I can descend into
\Internal Storage\Android\data\net.osmand.plus\files and see all my
(.obf) OsmAnd+ maps.

If I do the same on my phone with its (Samsung) 'My Files' app (or a
similar app [1]), as soon as I try to descend into ...\data, the app
says

"Due to Android restrictions, the contents of this folder can only be
shown on a computer."

Note the nice hint to the computer! :-)

So with a USB/MTP connection to a Windows system, you can 'backup'
*more* of the Android filesystem, but it is rather cumbersome to use,
because you can only use this connection in (Windows) File Explorer and
only do *manual* copy-paste type operations. It's not a Windows drive -
it has no drive letter -, so you can not use it with other utilities,
not with 'DOS' (hence not with a .bat script), etc..

We Dutch call it (translated by Google Translate) "the law for the
preservation of misery"! :-) c.q. :-(

[1] For example the 'FX' app says '/!\ Access was denied.'.

Frank Slootweg

unread,
Nov 3, 2023, 12:44:02 PM11/3/23
to
Theo <theom...@chiark.greenend.org.uk> wrote:
[...]

> So if you don't have root, you have to rely on whatever backup
> mechanisms the system lets you have. That might be:
>
[...]
> 3 adb backup (unreliable)
[...]

Why is adb backup unreliable?

I was thinking of using 'adb pull' commands in a .bat script.

AFAIK, 'adb pull' can see as much/little of the Android filesystem as
a USB/MTP connection can (see my response to Andy).

Andy Burns

unread,
Nov 3, 2023, 1:34:04 PM11/3/23
to
Frank Slootweg wrote:

> So with a USB/MTP connection to a Windows system, you can 'backup'
> more of the Android filesystem, but it is rather cumbersome to use,
> because you can only use this connection in (Windows) File Explorer and
> only domanual copy-paste type operations. It's not a Windows drive -
> it has no drive letter -, so you can not use it with other utilities,
> not with 'DOS' (hence not with a .bat script), etc..

You can access the file explorer via the shell.application object within
powershell (or vbscript/javascript if that's more your thing) and the
phone shows up with a type of ssfDRIVES

<https://blog.daiyanyingyu.uk/2018/03/20/powershell-mtp>

Andy Burns

unread,
Nov 3, 2023, 1:36:31 PM11/3/23
to
Jeff Layman wrote:

> Any views about backing up an Android phone?

Way back, when I used to run custom firmware on my Nexus1, titanium
backup was the thing, but it required root.

Theo

unread,
Nov 3, 2023, 5:42:48 PM11/3/23
to
adb backup != adb pull

'adb backup' is supposed to back up your .apks and their associated data,
ie enough to restore the app onto a second device and have it configured
as it was on the first device. It often fails - I don't know exactly
why, but it seems like Google doesn't support it any more.

'adb pull' is just a file copy, so doesn't get apps or app data (but can
get files stored by apps, which is different from app data).

Theo

Dave Royal

unread,
Nov 3, 2023, 6:53:23 PM11/3/23
to
I think I read that adb backup now works only on apps that have granted
backup permission. I don't know which Android API version changed that.
Permissions seem to change in every API.

I think it's correct that if you can adb pull from a directory then you
should be able to access it with MTP. MTP works reliably with this Samsung
tablet (with Linux) but my previous Pixel C was very temperamental. I have
scripts that pull stuff onto Linux - Windows should work too.

ISTR when I had rooted devices that an app's private data - for example
Firefox's profile - as opposed to data accessible by other apps - for
example downloads - was in /data/data/<app-id> - or something like that. I
don't think you can adb pull that, but I'm not sure. Maybe it depends on
the app's permissions (in its manifest).

--
(Remove numerics from email address)

Carlos E. R.

unread,
Nov 3, 2023, 9:52:04 PM11/3/23
to
On 2023-11-03 15:25, Adrian wrote:
> In message <YIy*n2...@news.chiark.greenend.org.uk>, Theo
> <theom...@chiark.greenend.org.uk> writes
>> The problem is that, on Windows, you can get access to all your user
>> files in C:\Users\username so you can backup all the user state.  On
>> Android there are security protections in place so one app can't access
>> another app's files.  On Windows, if you have admin rights, you can
>> access every file.  On Android you need root for that, which is
>> something the system is designed to not let you have, for the same
>> security reasons.
>>
>
> Am I missing something here ?  If I plug my Android phone (or tablet)
> into my PC using a USB lead, I can download data from it.  That is
> generally how I copy off photos that I want to use elsewhere.  So if I
> can do that for photos, what is to stop me downloading the rest of the
> data on the device onto a PC, or in other words, backing it up ?

Because it doesn't work.

One example I suffered some days ago.

My WhatsApp app stopped working,it would not even start after an update
while I was sleeping.

After a day, I decided to uninstall and reinstall it again, without
deleting any data.

On installation, the app ignored the messages database on the phone, and
insisting on downloading the backup from Google Drive. But it was half a
week old, so I lost some messages.

What would be a file backup be on my computer? None. WhatsApp would
ignore it, refuse to use it. So it is no use...

It did reuse the photo and media files storage, that was not lost.

(then I reconfigured WhatsApp to do daily backup. No idea why it was
set to weekly).


Some apps will accept data backups restored into the phone, but other
apps will not. And you can not restore the apps themselves as files from
the computer. There is no way to simply copy everything and restore
everything as you would do a computer, except if the phone provides a
rescue mode option from boot to do it (offline backup/restore)

--
Cheers,
Carlos E.R.

Jeff Layman

unread,
Nov 4, 2023, 4:46:18 AM11/4/23
to
On 03/11/2023 09:13, Jörg Lorenz wrote:
> Am 03.11.23 um 09:27 schrieb Jeff Layman:
>> On 03/11/2023 05:38, Jörg Lorenz wrote:
>>> Very very complicated. Drop your old habits and use Google Cloud.
>>
>> Nope. Google has enough of my private info without me making it simple
>> for them. Do you really believe that Google doesn't scan all the info
>> you store on their Cloud servers? From a very recent article at
>> <https://www.comparitech.com/blog/information-security/google-drive-secure/#Google_Drive_privacy_issues>:
>
> Why in the first place did you buy an Android smartphone? Google has
> your data anyway.

Sadly, you're probably right. I suppose I should be looking at a
Pinephone or something similar.

It never ceases to amaze me when I look at what my phone's doing that
it's sending data to someone even when I thought I'd turned it all off.
I never use Chrome, yet I see it's sending a few kB a day over wi-fi
(which I have switched off!).

>> "Google has, over the years, perfected the art of surveillance
>> capitalism—where your data is mined and sold to advertisers, which is
>> then used to manipulate or influence your buying behavior."
>>
>> You might also find it interesting to read the section "Relinquishing
>> control".
>
> No. I use my Pixel sometimes but the really important things are done on
> a different OS.

Well, we have something in common.

> You are obviously lacking a coherent strategy. Conspiracy theories
> really don't help at all.

The first sentence might be correct in relation to Android usage,
although not using it for anything important is a sensible strategy. I
doubt, however, that it's a theory any more as to what Google is doing
with personal data.

--

Jeff

Jörg Lorenz

unread,
Nov 4, 2023, 5:01:33 AM11/4/23
to
On 04.11.23 09:46, Jeff Layman wrote:
> The first sentence might be correct in relation to Android usage,
> although not using it for anything important is a sensible strategy. I
> doubt, however, that it's a theory any more as to what Google is doing
> with personal data.

Perhaps you are right. It worries me to see how most users are naive.
Look at the neighbouring thread "RCS chat".

Jeff Layman

unread,
Nov 4, 2023, 6:44:30 AM11/4/23
to
Interesting thread. I've just read through it all (because most of my
messaging is to iPhone users I didn't follow it for long when it first
appeared).

I do wonder about End-to-End Encryption when the encrypted message goes
through Google. They could simply be the man-in-the-middle who is able
to read the message because they set up the encryption. It might also
answer another question raised as to "what's in RCS for Google?". Well,
if they are able to read those encrypted messages it's another source of
data for them to sell that others can't read and make use of.

Or does that sound too much like another conspiracy theory? ;-)

--

Jeff

Jörg Lorenz

unread,
Nov 4, 2023, 6:53:31 AM11/4/23
to
Am 04.11.23 um 11:44 schrieb Jeff Layman:
> I do wonder about End-to-End Encryption when the encrypted message goes
> through Google. They could simply be the man-in-the-middle who is able
> to read the message because they set up the encryption. It might also
> answer another question raised as to "what's in RCS for Google?".

Bingo! The world does not need Google as man-in-the-middle.

Jörg Lorenz

unread,
Nov 4, 2023, 6:54:35 AM11/4/23
to
Am 04.11.23 um 11:44 schrieb Jeff Layman:
> Or does that sound too much like another conspiracy theory? 😉

No, this is the naked truth!

Frank Slootweg

unread,
Nov 4, 2023, 7:05:51 AM11/4/23
to
Theo <theom...@chiark.greenend.org.uk> wrote:
> Frank Slootweg <th...@ddress.is.invalid> wrote:
> > Theo <theom...@chiark.greenend.org.uk> wrote:
> > [...]
> >
> > > So if you don't have root, you have to rely on whatever backup
> > > mechanisms the system lets you have. That might be:
> > >
> > [...]
> > > 3 adb backup (unreliable)
> > [...]
> >
> > Why is adb backup unreliable?
> >
> > I was thinking of using 'adb pull' commands in a .bat script.
> >
> > AFAIK, 'adb pull' can see as much/little of the Android filesystem as
> > a USB/MTP connection can (see my response to Andy).
>
> adb backup != adb pull
>
> 'adb backup' is supposed to back up your .apks and their associated data,
> ie enough to restore the app onto a second device and have it configured
> as it was on the first device. It often fails - I don't know exactly
> why, but it seems like Google doesn't support it any more.

Ah, i see! Thanks! I interpreted it as making (a sort of) backup with
adb, but you meant it literally, the 'adb backup' command.

As to backing up and restoring APKs, yes I use other means for that,
currently 'App Backup & Restore'. And yes, restoring an app with its
associated data can be a challenge. (See also Carlos' post on restoring
his WhatsApp app and data.)

> 'adb pull' is just a file copy, so doesn't get apps or app data (but can
> get files stored by apps, which is different from app data).

[1] <https://play.google.com/store/apps/details?id=mobi.infolife.appbackup>

Frank Slootweg

unread,
Nov 4, 2023, 7:39:52 AM11/4/23
to
Carlos E. R. <robin_...@es.invalid> wrote:
> On 2023-11-03 15:25, Adrian wrote:
[...]
> > Am I missing something here ?  If I plug my Android phone (or tablet)
> > into my PC using a USB lead, I can download data from it.  That is
> > generally how I copy off photos that I want to use elsewhere.  So if I
> > can do that for photos, what is to stop me downloading the rest of the
> > data on the device onto a PC, or in other words, backing it up ?
>
> Because it doesn't work.
>
> One example I suffered some days ago.
>
> My WhatsApp app stopped working,it would not even start after an update
> while I was sleeping.
>
> After a day, I decided to uninstall and reinstall it again, without
> deleting any data.

AFAIK, uninstalling *does* delete data, at least in recent Android
versions (where \Android\data is not accessible by other apps).

That's the whole point: As \Android\data is not accessible by other
apps, it must be deleted by an uninstall, because if it's not
deleted at uninstall, it can't be deleted later, because another app
can't get to it. Catch-22!

Correct me if I'm wrong. (I don't want to uninstall any of my apps,
just to test this.)

> On installation, the app ignored the messages database on the phone, and
> insisting on downloading the backup from Google Drive. But it was half a
> week old, so I lost some messages.
>
> What would be a file backup be on my computer? None. WhatsApp would
> ignore it, refuse to use it. So it is no use...

As I mentioned earlier, you *can* backup and restore \Android\data
with a USB/MTP connection (or with 'adb pull'/'adb push').

AFAIK, if you use that, you can get it to work. You'd probably have to
test if you should install WhatsApp before or after restoring
\Android\data.

> It did reuse the photo and media files storage, that was not lost.

Yes, that lives in \Android\media\com.whatsapp and *is* normally
accessible by other apps (and is *not* deleted at uninstall).

> (then I reconfigured WhatsApp to do daily backup. No idea why it was
> set to weekly).
>
> Some apps will accept data backups restored into the phone, but other
> apps will not. And you can not restore the apps themselves as files from
> the computer. There is no way to simply copy everything and restore
> everything as you would do a computer, except if the phone provides a
> rescue mode option from boot to do it (offline backup/restore)

Yes, true. The bottom line is that backup is very hard and restore is
even harder.

Some (most? all?) brands also have their own backup/restore utilities,
which can often do more than regular backup apps/methods can do.

For example Samsung has 'Smart Switch', which - other than the name
implies - can not only help with switch from an old phone to a new one,
but can also backup/restore to/from a 'computer' (Windows and Mac?).

But for your WhatsApp case, that's of little use, because WhatsApp
needs/makes frequent backup, which is normally done to Google Drive.

Carlos E. R.

unread,
Nov 4, 2023, 9:43:19 AM11/4/23
to
Yes.

--
Cheers,
Carlos E.R.

Jörg Lorenz

unread,
Nov 4, 2023, 11:13:25 AM11/4/23
to
Am 04.11.23 um 14:43 schrieb Carlos E. R.:
Not at all indeed.

Wally J

unread,
Nov 4, 2023, 2:24:37 PM11/4/23
to
Theo <theom...@chiark.greenend.org.uk> wrote

> adb backup != adb pull
>
> 'adb backup' is supposed to back up your .apks and their associated data,
> ie enough to restore the app onto a second device and have it configured
> as it was on the first device. It often fails - I don't know exactly
> why, but it seems like Google doesn't support it any more.
>
> 'adb pull' is just a file copy, so doesn't get apps or app data (but can
> get files stored by apps, which is different from app data).

Hi Theo,


Speaking of why it "often fails", I always suspected that failures
were maybe probably perhaps due to Android not storing the original
APK but instead, maybe perhaps Android stored a hardware-specific APK?

I don't know. Do you?

Is the apk that is always stored on Android, a _full_ original APK?
Or is that stored APK stripped to the essentials for your hardware?

Let's run a test. Shall we?

You probably are aware that there never was an app installed on Android
that did not always have its APK saved on Android (even for pre-installed
system apps), which is exactly why those myriad "Apk extractors" can work.
<https://play.google.com/store/search?q=apk%20extractor&c=apps>

But...

I always wondered if the apk that you install is exactly the same as the
apk that is always saved - as what's saved could be hardware specific.

That is, Android could choose to save an APK with only the specific needs
of your specific hardware, such as for my specific Samsung Galaxy A32-5G.

So I ran a test of that just now, arbitrarily choosing OSMAnd to test.
This was all done from Windows (using scrcpy mirrored display of Android).

*Tutorial: Real world testing installing & backing up Android APKs*
*100% from Windows (Mac or Linux) over adb on USB*
<https://groups.google.com/g/comp.mobile.android/c/GcP5Y3p817U>

Interesting comparative results.

I had actually expected the base apk to be smaller than the original APK
because I had assumed a hardware-specific base APK was saved on Android.

But in this single test (notice we're not using the new APEX files!),
what was (always automatically) saved on Android as the base.apk
turned out to be exactly the same as what was downloaded and installed.
--
The whole point of Usenet is to find people who know more than you do.
And to contribute to the overall tribal knowledge value of the newsgroup.
It's a domino effect where each of us helps the next person in the lineup.

Wally J

unread,
Nov 4, 2023, 9:29:08 PM11/4/23
to
Jeff Layman <Je...@invalid.invalid> wrote

>> Why in the first place did you buy an Android smartphone? Google has
>> your data anyway.
>
> Sadly, you're probably right.

If you think Joerg is right, then that's a sad assessment on your part.

Apple forces you to constantly log into its mothership tracking servers.
Google can't.

Think about that before you assess that one may be safer than the other.

Wally J

unread,
Nov 4, 2023, 9:30:43 PM11/4/23
to
Jeff Layman <Je...@invalid.invalid> wrote

> I do wonder about End-to-End Encryption when the encrypted message goes
> through Google.

Have you looked at PulseSMS' end-to-end encryption instead of Google's?

*Pulse SMS* (Phone/Tablet/Web)
free, adfree, reqgsf, 4.7star,78.5K reviews,1M+Downloads
<https://home.pulsesms.app/overview/>
<https://play.google.com/store/apps/details?id=xyz.klinker.messenger>

Theo

unread,
Nov 5, 2023, 9:24:21 AM11/5/23
to
Jeff Layman <Je...@invalid.invalid> wrote:
> I do wonder about End-to-End Encryption when the encrypted message goes
> through Google. They could simply be the man-in-the-middle who is able
> to read the message because they set up the encryption. It might also
> answer another question raised as to "what's in RCS for Google?". Well,
> if they are able to read those encrypted messages it's another source of
> data for them to sell that others can't read and make use of.
>
> Or does that sound too much like another conspiracy theory? ;-)

Yes. E2EE means that Google in the middle can't intercept. That's what
E2EE means - if they can, it's not E2EE.

However what's in RCS for Google is a competitor to iMessage. Especially in
the US, Android suffers from 'green bubbles syndrome', where people buy
iPhones because they get better messaging with their iPhone owning mates via
iMessage, and Android owners have to fall back to SMS which is very much a
second class citizen. RCS is Google's (umpteenth) attempt on an iMessage
rival.

(In the US iMessage has a big chunk of market share, in other countries this
isn't really a thing - everyone uses WhatsApp or Telegram or whatever so the
blue bubbles/green bubbles difference doesn't matter).

If RCS succeeds, it address a key deficiency of Android compared with iOS
and helps them sell more Android phones.

Google is pushing the narrative that RCS is 'open' and iMessage is 'closed',
but, with carriers throwing in the towel and using Google's server, it
sounds like it's not a million miles different from iMessage.

Google are doing this big US ad campaign to 'convince' Apple to add RCS
support to iOS - they know Apple won't, but it just gets Google publicity
for RCS.

Theo

Larry Wolff

unread,
Nov 5, 2023, 10:44:37 AM11/5/23
to
Have you read this?
https://www.reuters.com/article/us-apple-fbi-icloud-exclusive-idUSKBN1ZK1CT

It says Apple holds onto your encryption key to read your iMessages while
on iCloud and to give all your iMessages on iCloud to anyone they want to?

Jeff Layman

unread,
Nov 5, 2023, 10:57:39 AM11/5/23
to
On 05/11/2023 14:24, Theo wrote:
> Jeff Layman <Je...@invalid.invalid> wrote:
>> I do wonder about End-to-End Encryption when the encrypted message goes
>> through Google. They could simply be the man-in-the-middle who is able
>> to read the message because they set up the encryption. It might also
>> answer another question raised as to "what's in RCS for Google?". Well,
>> if they are able to read those encrypted messages it's another source of
>> data for them to sell that others can't read and make use of.
>>
>> Or does that sound too much like another conspiracy theory? ;-)
>
> Yes. E2EE means that Google in the middle can't intercept. That's what
> E2EE means - if they can, it's not E2EE.

I guess my use of man-in-the-middle was somewhat misleading as it has a
specific meaning. Perhaps "backdoor" would have been a better choice.

<https://en.wikipedia.org/wiki/End-to-end_encryption#Backdoors>

My point is that Google provide Android. It doesn't matter how open
source it is as nobody outside Google (and I would think many inside it)
can know what umpteen million lines of code do. I was referring mainly
to Google's own backup to their Cloud servers. It may also be the case
that other manufacturers using their modified Android OS can do the same
thing. It may be unlikely, but how would anyone outside the company know
if there was a software backdoor in Android? Backdoors aren't unknown in
hardware, either. This is from over 10 years ago:
<http://www.cl.cam.ac.uk/~sps32/Silicon_scan_draft.pdf>

Perhaps not relevant so much to Google, but what about Huawei or Xiaomi?

> However what's in RCS for Google is a competitor to iMessage. Especially in
> the US, Android suffers from 'green bubbles syndrome', where people buy
> iPhones because they get better messaging with their iPhone owning mates via
> iMessage, and Android owners have to fall back to SMS which is very much a
> second class citizen. RCS is Google's (umpteenth) attempt on an iMessage
> rival.
>
> (In the US iMessage has a big chunk of market share, in other countries this
> isn't really a thing - everyone uses WhatsApp or Telegram or whatever so the
> blue bubbles/green bubbles difference doesn't matter).
>
> If RCS succeeds, it address a key deficiency of Android compared with iOS
> and helps them sell more Android phones.
>
> Google is pushing the narrative that RCS is 'open' and iMessage is 'closed',
> but, with carriers throwing in the towel and using Google's server, it
> sounds like it's not a million miles different from iMessage.
>
> Google are doing this big US ad campaign to 'convince' Apple to add RCS
> support to iOS - they know Apple won't, but it just gets Google publicity
> for RCS.

I assume that if Google gets their success with RCS that would mean more
data available for analysis by them, and more ads for us.

--

Jeff

Jeff Layman

unread,
Nov 5, 2023, 11:03:37 AM11/5/23
to
I think you're misinterpreting what I'm saying here. I never said that
Android was better or worse than Apple regarding privacy. Apple are very
closed-source when it comes to their OS, and Google are much more open.
But that doesn't mean we /know/ what Google are doing, as some of their
code is proprietary. And, as I pointed out in my reply to Theo, can
anyone know what all the millions of line of /open/ code in Android are for?

FWIW, I wouldn't trust either to not mine data.

--

Jeff

Jörg Lorenz

unread,
Nov 5, 2023, 12:25:27 PM11/5/23
to
On 05.11.23 16:44, Larry Wolff wrote:
> Have you read this?
> https://www.reuters.com/article/us-apple-fbi-icloud-exclusive-idUSKBN1ZK1CT
>
> It says Apple holds onto your encryption key to read your iMessages while
> on iCloud and to give all your iMessages on iCloud to anyone they want to?

*ROTFLSTC*

Very very old news and in the meantime Apple allows E2E-encryption.
You are trying to spread FUD and a lot of nonsense.

Carlos E. R.

unread,
Nov 5, 2023, 7:53:52 PM11/5/23
to
No, no big company with a modicum of sense would do that. Just
collecting data, massively, to analyze and target publicity? That would
get known, many people need to be in the know to make use of that lot of
data. Too risky. Thus, not likely.

Now, a backdoor so that authorities can capture a few conversations with
a warrant? Maybe. Or so that a spy agency captures data from a limited
number of targets? Perhaps.

By the way, this is normally done by placing a trojan at one of the targets.

--
Cheers,
Carlos E.R.

Carlos E. R.

unread,
Nov 5, 2023, 7:54:38 PM11/5/23
to
I can buy this analysis :-)

--
Cheers,
Carlos E.R.

Java Jive

unread,
Nov 6, 2023, 6:25:37 AM11/6/23
to
On 06/11/2023 00:53, Carlos E. R. wrote:
>
> No, no big company with a modicum of sense would do that. Just
> collecting data, massively, to analyze and target publicity? That would
> get known, many people need to be in the know to make use of that lot of
> data. Too risky. Thus, not likely.

Except Google are already known to be doing this - by their own
admission they already scan all emails on gmail, etc. I don't knowingly
use cloud services, and therefore haven't read any of the T&C of any
cloud service, but I wouldn't be at all surprised to find somewhere in
there some phrase such as:

"I agree that <Google|whoever> scans my data for malware and the purpose
of improving their services to me."

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

Frank Slootweg

unread,
Nov 6, 2023, 9:43:12 AM11/6/23
to
Java Jive <ja...@evij.com.invalid> wrote:
> On 06/11/2023 00:53, Carlos E. R. wrote:
> >
> > No, no big company with a modicum of sense would do that. Just
> > collecting data, massively, to analyze and target publicity? That would
> > get known, many people need to be in the know to make use of that lot of
> > data. Too risky. Thus, not likely.
>
> Except Google are already known to be doing this - by their own
> admission they already scan all emails on gmail, etc. I don't knowingly
> use cloud services, and therefore haven't read any of the T&C of any
> cloud service, but I wouldn't be at all surprised to find somewhere in
> there some phrase such as:
>
> "I agree that <Google|whoever> scans my data for malware and the purpose
> of improving their services to me."

The - snipped - issue was:

<JL>
I assume that if Google gets their success with RCS that would mean
more data available for analysis by them, and more ads for us.
</JL>

So yes, they do *data analysis* of your Gmail e-mail, but AFAICT both
Jeff's and Carlos' point is *ads* and in over 15 years of having (a)
Gmail account(s), I still have to get the very first ad in or triggered
by Gmail!

As I said before, if Google is scanning my emails and allegedly acting
on that scanning, they are doing a very poor job, because after the
fact, I still get *in-browser* (*not* in email/Gmail) ads for products
which I already purchased and for which the order/receipt/invoice/etc.
are in that same Gmail mailbox! Can you say "stupid"!? (Yes, people have
explained why this is so, but that doesn't mean that the end result
isn't still stupid.)

Jörg Lorenz

unread,
Nov 6, 2023, 11:18:29 AM11/6/23
to
Am 05.11.23 um 16:57 schrieb Jeff Layman:
> I guess my use of man-in-the-middle was somewhat misleading as it has a
> specific meaning. Perhaps "backdoor" would have been a better choice.

No. Google would be the man-in-the-middle.

Jörg Lorenz

unread,
Nov 6, 2023, 11:19:56 AM11/6/23
to
Am 06.11.23 um 01:53 schrieb Carlos E. R.:
Total nonsense! My God are you naïve! They do already such things.

Jörg Lorenz

unread,
Nov 6, 2023, 11:21:33 AM11/6/23
to
Am 06.11.23 um 01:54 schrieb Carlos E. R.:
Nowhere near an analysis! *ROTFLSTC*
RCS is already dead.

Carlos E. R.

unread,
Nov 6, 2023, 12:28:37 PM11/6/23
to
Yeah, Amazon does that, it is stupid.

--
Cheers,
Carlos E.R.

Carlos E. R.

unread,
Nov 6, 2023, 12:29:40 PM11/6/23
to
On 2023-11-06 12:25, Java Jive wrote:
> On 06/11/2023 00:53, Carlos E. R. wrote:
>>
>> No, no big company with a modicum of sense would do that. Just
>> collecting data, massively, to analyze and target publicity? That
>> would get known, many people need to be in the know to make use of
>> that lot of data. Too risky. Thus, not likely.
>
> Except Google are already known to be doing this  -  by their own
> admission they already scan all emails on gmail, etc.

Which are not encrypted. Much less E2EE.

And we are talking RCS, not email. Different technology.

> I don't knowingly
> use cloud services, and therefore haven't read any of the T&C of any
> cloud service, but I wouldn't be at all surprised to find somewhere in
> there some phrase such as:
>
> "I agree that <Google|whoever> scans my data for malware and the purpose
> of improving their services to me."


Why would I be surprised? The first time I asked Google to have one
gmail address, which at the time was by invitation, I read the
conditions. And they clearly said that email could be read by machines,
not humans, for the purpose of publicity targeting and improving
services. Only if using webmail, possibly.

--
Cheers,
Carlos E.R.

Java Jive

unread,
Nov 6, 2023, 12:30:50 PM11/6/23
to
On 06/11/2023 14:43, Frank Slootweg wrote:
>
> Java Jive <ja...@evij.com.invalid> wrote:
>>
>> On 06/11/2023 00:53, Carlos E. R. wrote:
>>>
>>> No, no big company with a modicum of sense would do that. Just
>>> collecting data, massively, to analyze and target publicity? That would
>>> get known, many people need to be in the know to make use of that lot of
>>> data. Too risky. Thus, not likely.
>>
>> Except Google are already known to be doing this - by their own
>> admission they already scan all emails on gmail, etc. I don't knowingly
>> use cloud services, and therefore haven't read any of the T&C of any
>> cloud service, but I wouldn't be at all surprised to find somewhere in
>> there some phrase such as:
>>
>> "I agree that <Google|whoever> scans my data for malware and the purpose
>> of improving their services to me."
>
> The - snipped - issue was:
>
> <JL>
> I assume that if Google gets their success with RCS that would mean
> more data available for analysis by them, and more ads for us.
> </JL>

Well, that's not quite correct anyway, what he should have said was:
"more targeted ads for us".

> So yes, they do *data analysis* of your Gmail e-mail, but AFAICT both
> Jeff's and Carlos' point is *ads* and in over 15 years of having (a)
> Gmail account(s), I still have to get the very first ad in or triggered
> by Gmail!

The paragraph above suggests that you misunderstand what is really
happening, but that below suggests that you do not. To clarify, the
data they get from scanning your personal data such as emails is used in
other places - over 2 million other places, at very least all those
sites using Google's ad services - to match the advertisements shown
to you with your interests as judged by scanning your personal data.

> As I said before, if Google is scanning my emails and allegedly acting
> on that scanning, they are doing a very poor job, because after the
> fact, I still get *in-browser* (*not* in email/Gmail) ads for products
> which I already purchased and for which the order/receipt/invoice/etc.
> are in that same Gmail mailbox! Can you say "stupid"!? (Yes, people have
> explained why this is so, but that doesn't mean that the end result
> isn't still stupid.)

As we see daily from the amount of obviously fake news that infests
social media, Artificial so-called Intelligence can only do so much.

Carlos E. R.

unread,
Nov 6, 2023, 12:33:53 PM11/6/23
to
Yeah, we know your manias.

--
Cheers,
Carlos E.R.

Java Jive

unread,
Nov 6, 2023, 12:35:25 PM11/6/23
to
On 06/11/2023 17:29, Carlos E. R. wrote:
>
> On 2023-11-06 12:25, Java Jive wrote:
>>
>> On 06/11/2023 00:53, Carlos E. R. wrote:
>>>
>>> No, no big company with a modicum of sense would do that. Just
>>> collecting data, massively, to analyze and target publicity? That
>>> would get known, many people need to be in the know to make use of
>>> that lot of data. Too risky. Thus, not likely.
>>
>> Except Google are already known to be doing this  -  by their own
>> admission they already scan all emails on gmail, etc.
>
> Which are not encrypted. Much less E2EE.

Irrelevant, the principle is exactly the same: they scan your supposedly
private data.

> And we are talking RCS, not email. Different technology.

Again irrelevant, it's all big data to Google, and grist for their mill.

>> I don't knowingly use cloud services, and therefore haven't read any
>> of the T&C of any cloud service, but I wouldn't be at all surprised to
>> find somewhere in there some phrase such as:
>>
>> "I agree that <Google|whoever> scans my data for malware and the
>> purpose of improving their services to me."
>
> Why would I be surprised? The first time I asked Google to have one
> gmail address, which at the time was by invitation, I read the
> conditions. And they clearly said that email could be read by machines,
> not humans, for the purpose of publicity targeting and improving
> services. Only if using webmail, possibly.

Which contradicts your earlier claim still quoted above.

Carlos E. R.

unread,
Nov 6, 2023, 12:44:01 PM11/6/23
to
On 2023-11-06 18:35, Java Jive wrote:
> On 06/11/2023 17:29, Carlos E. R. wrote:
>>
>> On 2023-11-06 12:25, Java Jive wrote:
>>>
>>> On 06/11/2023 00:53, Carlos E. R. wrote:
>>>>
>>>> No, no big company with a modicum of sense would do that. Just
>>>> collecting data, massively, to analyze and target publicity? That
>>>> would get known, many people need to be in the know to make use of
>>>> that lot of data. Too risky. Thus, not likely.
>>>
>>> Except Google are already known to be doing this  -  by their own
>>> admission they already scan all emails on gmail, etc.
>>
>> Which are not encrypted. Much less E2EE.
>
> Irrelevant, the principle is exactly the same: they scan your supposedly
> private data.

No, they can not scan E2EE communications.

>
>> And we are talking RCS, not email. Different technology.
>
> Again irrelevant, it's all big data to Google, and grist for their mill.

No, there are differences.

>
>>> I don't knowingly use cloud services, and therefore haven't read any
>>> of the T&C of any cloud service, but I wouldn't be at all surprised
>>> to find somewhere in there some phrase such as:
>>>
>>> "I agree that <Google|whoever> scans my data for malware and the
>>> purpose of improving their services to me."
>>
>> Why would I be surprised? The first time I asked Google to have one
>> gmail address, which at the time was by invitation, I read the
>> conditions. And they clearly said that email could be read by
>> machines, not humans, for the purpose of publicity targeting and
>> improving services. Only if using webmail, possibly.
>
> Which contradicts your earlier claim still quoted above.

Not at all, it doesn't. Learn to read.


--
Cheers,
Carlos E.R.

Jörg Lorenz

unread,
Nov 6, 2023, 1:06:56 PM11/6/23
to
You are not able to develop a critical attitude towards services you
like as a fanboy.

Google as man-in-the-middle? Never ever.
Google tries for years now but without any success. *LOL*

Carlos E. R.

unread,
Nov 6, 2023, 1:13:09 PM11/6/23
to
Your opinion is noted and discarded.

--
Cheers,
Carlos E.R.

Ed Cryer

unread,
Nov 6, 2023, 1:49:51 PM11/6/23
to
Carlos is toying with you.
Google's abusive behaviour is patent, obvious and wide-open to anybody
with half a brain.
Don't humour him. He needs a head-blow.

Ed

Java Jive

unread,
Nov 6, 2023, 2:57:23 PM11/6/23
to
On 06/11/2023 17:43, Carlos E. R. wrote:
>
> On 2023-11-06 18:35, Java Jive wrote:
>>
>> On 06/11/2023 17:29, Carlos E. R. wrote:
>>>
>>> On 2023-11-06 12:25, Java Jive wrote:
>>>>
>>>> On 06/11/2023 00:53, Carlos E. R. wrote:
>>>>>
>>>>> No, no big company with a modicum of sense would do that. Just
>>>>> collecting data, massively, to analyze and target publicity? That
>>>>> would get known, many people need to be in the know to make use of
>>>>> that lot of data. Too risky. Thus, not likely.
>>>>
>>>> Except Google are already known to be doing this  -  by their own
>>>> admission they already scan all emails on gmail, etc.
>>>
>>> Which are not encrypted. Much less E2EE.
>>
>> Irrelevant, the principle is exactly the same: they scan your
>> supposedly private data.
>
> No, they can not scan E2EE communications.

Neither can you, so it has to be decrypted for you to read, and, if you
can read it, so can they.

>>> And we are talking RCS, not email. Different technology.
>>
>> Again irrelevant, it's all big data to Google, and grist for their mill.
>
> No, there are differences.

Not any that are material to the point. As below, learn to read.

>>>> I don't knowingly use cloud services, and therefore haven't read any
>>>> of the T&C of any cloud service, but I wouldn't be at all surprised
>>>> to find somewhere in there some phrase such as:
>>>>
>>>> "I agree that <Google|whoever> scans my data for malware and the
>>>> purpose of improving their services to me."
>>>
>>> Why would I be surprised? The first time I asked Google to have one
>>> gmail address, which at the time was by invitation, I read the
>>> conditions. And they clearly said that email could be read by
>>> machines, not humans, for the purpose of publicity targeting and
>>> improving services. Only if using webmail, possibly.
>>
>> Which contradicts your earlier claim still quoted above.
>
> Not at all, it doesn't. Learn to read.

Start with Shoshana Zuboff's book.

Carlos E. R.

unread,
Nov 6, 2023, 3:38:56 PM11/6/23
to
On 2023-11-06 20:57, Java Jive wrote:
> On 06/11/2023 17:43, Carlos E. R. wrote:
>>
>> On 2023-11-06 18:35, Java Jive wrote:
>>>
>>> On 06/11/2023 17:29, Carlos E. R. wrote:
>>>>
>>>> On 2023-11-06 12:25, Java Jive wrote:
>>>>>
>>>>> On 06/11/2023 00:53, Carlos E. R. wrote:
>>>>>>
>>>>>> No, no big company with a modicum of sense would do that. Just
>>>>>> collecting data, massively, to analyze and target publicity? That
>>>>>> would get known, many people need to be in the know to make use of
>>>>>> that lot of data. Too risky. Thus, not likely.
>>>>>
>>>>> Except Google are already known to be doing this  -  by their own
>>>>> admission they already scan all emails on gmail, etc.
>>>>
>>>> Which are not encrypted. Much less E2EE.
>>>
>>> Irrelevant, the principle is exactly the same: they scan your
>>> supposedly private data.
>>
>> No, they can not scan E2EE communications.
>
> Neither can you, so it has to be decrypted for you to read, and, if you
> can read it, so can they.

WOSH! :-D

(ignoring the resti)

--
Cheers,
Carlos E.R.

Java Jive

unread,
Nov 6, 2023, 4:08:38 PM11/6/23
to
So you have no reply. End of argument.

Jörg Lorenz

unread,
Nov 6, 2023, 4:14:11 PM11/6/23
to
On 06.11.23 22:08, Java Jive wrote:
> On 06/11/2023 20:38, Carlos E. R. wrote:
>> WOSH!  :-D
>>
>> (ignoring the resti)
>
> So you have no reply. End of argument.

Not only in this subthread. Do not waste your time.

Frank Slootweg

unread,
Nov 7, 2023, 10:15:33 AM11/7/23
to
No, my point (below) is that in my actual experience, Google does
*not* "match the advertisements shown to you with your interests as
judged by scanning your personal [email] data".

It matches ads with my *browsing activity* (Duh!), but it does *not*
match ads based on its scanning of my Gmail. That's the stupid bit.

> > As I said before, if Google is scanning my emails and allegedly acting
> > on that scanning, they are doing a very poor job, because after the
> > fact, I still get *in-browser* (*not* in email/Gmail) ads for products
> > which I already purchased and for which the order/receipt/invoice/etc.
> > are in that same Gmail mailbox! Can you say "stupid"!? (Yes, people have
> > explained why this is so, but that doesn't mean that the end result
> > isn't still stupid.)
>
> As we see daily from the amount of obviously fake news that infests
> social media, Artificial so-called Intelligence can only do so much.

It's not just only doing so much, it's *failing totally*, that's
the/my point.

At other times when this came up, some have mentioned that this
failure might be caused by the EU's strict privacy laws (both Carlos and
I are in the EU), but nobody knows for sure.

Carlos E. R.

unread,
Nov 7, 2023, 3:25:02 PM11/7/23
to
They said when they started life that they would scan mail on webmail,
not on pop3/imap/smtp.


On the other hand, they clearly scan mail looking for criteria. They
separate invoices to a folder (on wemail at least). Or for travel
tickets. This is a feature you can find useful or intrusive. It is
machine scanning, anyway. It is OFF by default on the EU.


>>> As I said before, if Google is scanning my emails and allegedly acting
>>> on that scanning, they are doing a very poor job, because after the
>>> fact, I still get *in-browser* (*not* in email/Gmail) ads for products
>>> which I already purchased and for which the order/receipt/invoice/etc.
>>> are in that same Gmail mailbox! Can you say "stupid"!? (Yes, people have
>>> explained why this is so, but that doesn't mean that the end result
>>> isn't still stupid.)
>>
>> As we see daily from the amount of obviously fake news that infests
>> social media, Artificial so-called Intelligence can only do so much.
>
> It's not just only doing so much, it's *failing totally*, that's
> the/my point.
>
> At other times when this came up, some have mentioned that this
> failure might be caused by the EU's strict privacy laws (both Carlos and
> I are in the EU), but nobody knows for sure.

--
Cheers,
Carlos E.R.

Carlos E. R.

unread,
Nov 7, 2023, 3:26:15 PM11/7/23
to
On 2023-11-06 22:08, Java Jive wrote:
> On 06/11/2023 20:38, Carlos E. R. wrote:
>>
>> On 2023-11-06 20:57, Java Jive wrote:
>>>
>>> On 06/11/2023 17:43, Carlos E. R. wrote:
>>>>
>>>> No, they can not scan E2EE communications.
>>>
>>> Neither can you, so it has to be decrypted for you to read, and, if
>>> you can read it, so can they.
>>
>> WOSH!  :-D
>>
>> (ignoring the resti)
>
> So you have no reply.  End of argument.

Oh, I did reply. You are not ilustrate enough to understand.

--
Cheers,
Carlos E.R.

Jörg Lorenz

unread,
Nov 7, 2023, 3:35:50 PM11/7/23
to
Am 07.11.23 um 21:26 schrieb Carlos E. R.:
You do not understand the absolute basics of communication: You want to
be read and understood so you have to deliver accordingly.

That is where you too often fail miserably.

Java Jive

unread,
Nov 7, 2023, 3:49:34 PM11/7/23
to
LOL! You are not 'ilustrate' enough comment about others!

Frank Slootweg

unread,
Nov 8, 2023, 9:53:19 AM11/8/23
to
Java Jive <ja...@evij.com.invalid> wrote:
> On 07/11/2023 20:26, Carlos E. R. wrote:
> >
> > On 2023-11-06 22:08, Java Jive wrote:
> >>
> >> So you have no reply.  End of argument.
> >
> > Oh, I did reply. You are not ilustrate enough to understand.
>
> LOL! You are not 'ilustrate' enough comment about others!

And how's your Spanish? His English is very good, so if he happens to
make a spelling error, just move on.

Anyway, before criticizing others, first learn the difference between
end-to-end-encryption and no encryption. That Joerg is siding with you,
should be a red flag, a *big* one!

Carlos E. R.

unread,
Nov 8, 2023, 10:12:33 AM11/8/23
to
On 2023-11-08 15:53, Frank Slootweg wrote:
> Java Jive <ja...@evij.com.invalid> wrote:
>> On 07/11/2023 20:26, Carlos E. R. wrote:
>>>
>>> On 2023-11-06 22:08, Java Jive wrote:
>>>>
>>>> So you have no reply.  End of argument.
>>>
>>> Oh, I did reply. You are not ilustrate enough to understand.
>>
>> LOL! You are not 'ilustrate' enough comment about others!
>
> And how's your Spanish? His English is very good, so if he happens to
> make a spelling error, just move on.

Thank you.

My speller says 'ilustrate' is correct.

The problem is that Thunderbird has two languages active, and checks the
same word against two dictionaries (or more). Previously Thunderbird
deactivated automatically the current language when you clicked on the
other, allowing only one at a time.

A missing feature in Thunderbird is automatically selecting the spelling
language based in criteria, like the folder. The speller is a pain for
multilingual people, not smart.

>
> Anyway, before criticizing others, first learn the difference between
> end-to-end-encryption and no encryption. That Joerg is siding with you,
> should be a red flag, a *big* one!

Indeed.


--
Cheers,
Carlos E.R.

Frank Slootweg

unread,
Nov 8, 2023, 11:33:23 AM11/8/23
to
Carlos E. R. <robin_...@es.invalid> wrote:
> On 2023-11-08 15:53, Frank Slootweg wrote:
> > Java Jive <ja...@evij.com.invalid> wrote:
> >> On 07/11/2023 20:26, Carlos E. R. wrote:
> >>>
> >>> On 2023-11-06 22:08, Java Jive wrote:
> >>>>
> >>>> So you have no reply.  End of argument.
> >>>
> >>> Oh, I did reply. You are not ilustrate enough to understand.
> >>
> >> LOL! You are not 'ilustrate' enough comment about others!
> >
> > And how's your Spanish? His English is very good, so if he happens to
> > make a spelling error, just move on.
>
> Thank you.
>
> My speller says 'ilustrate' is correct.

It probably should be 'illustrate', with double-l, but I doubt that's
what you meant. You probably meant 'literate', the opposite of
'illiterate'. Or 'illustrious'?

> The problem is that Thunderbird has two languages active, and checks the
> same word against two dictionaries (or more). Previously Thunderbird
> deactivated automatically the current language when you clicked on the
> other, allowing only one at a time.
>
> A missing feature in Thunderbird is automatically selecting the spelling
> language based in criteria, like the folder. The speller is a pain for
> multilingual people, not smart.

As I mentioned in a recent discussion (with AJL?), I do not use a
spellchecker in my newsreader or e-mail agent, but use Google Translate
when I think it's called for.

The problem with built-in spellcheckers is that they only check the
spelling, not if the word(s) actually mean what you think they mean.

Carlos E. R.

unread,
Nov 8, 2023, 1:54:21 PM11/8/23
to
On 2023-11-08 17:33, Frank Slootweg wrote:
> Carlos E. R. <robin_...@es.invalid> wrote:
>> On 2023-11-08 15:53, Frank Slootweg wrote:
>>> Java Jive <ja...@evij.com.invalid> wrote:
>>>> On 07/11/2023 20:26, Carlos E. R. wrote:
>>>>>
>>>>> On 2023-11-06 22:08, Java Jive wrote:
>>>>>>
>>>>>> So you have no reply.  End of argument.
>>>>>
>>>>> Oh, I did reply. You are not ilustrate enough to understand.
>>>>
>>>> LOL! You are not 'ilustrate' enough comment about others!
>>>
>>> And how's your Spanish? His English is very good, so if he happens to
>>> make a spelling error, just move on.
>>
>> Thank you.
>>
>> My speller says 'ilustrate' is correct.
>
> It probably should be 'illustrate', with double-l, but I doubt that's
> what you meant. You probably meant 'literate', the opposite of
> 'illiterate'. Or 'illustrious'?

illustrated, being an illustrated person. Maybe the expression did not
caught in English. It relates to people from the illustration epoch
(Spanish and French), which wikipedia says it is "Age of Enlightenment"
in English.

What language teachers call "a false friend". A word in the second
language almost identical to another in the first language, with a
totally different meaning.

:-)

...

--
Cheers,
Carlos E.R.

Kenan ÇOT

unread,
Nov 8, 2023, 2:18:11 PM11/8/23
to
8 Kasım 2023 Çarşamba tarihinde saat 21:54:21 UTC+3 itibarıyla Carlos E. R. şunları yazdı:
https://www.teknofeed.com/clash-of-clans-12-seviye-koy-duzeni/

Java Jive

unread,
Nov 9, 2023, 5:17:24 AM11/9/23
to
On 08/11/2023 14:53, Frank Slootweg wrote:
>
> Java Jive <ja...@evij.com.invalid> wrote:
>>
>> On 07/11/2023 20:26, Carlos E. R. wrote:
>>>
>>> Oh, I did reply. You are not ilustrate enough to understand.
>>
>> LOL! You are not 'ilustrate' enough comment about others!
>
> And how's your Spanish? His English is very good, so if he happens to
> make a spelling error, just move on.

My Spanish is almost non-existent, but then I'm not trying to converse
in it. Anyway, the whole point is that it's not only a spelling error,
it's entirely the wrong choice of word, so wrong that I'm not sure
actually what he intended to say - if anything, that's a malapropism.

> Anyway, before criticizing others, first learn the difference between
> end-to-end-encryption and no encryption. That Joerg is siding with you,
> should be a red flag, a *big* one!

No-one has answered my basic point that, if Google run the OS, and
Carlos can read the message, so can Google, and, given Google's track
record, most probably they will.

Carlos E. R.

unread,
Nov 9, 2023, 6:02:50 AM11/9/23
to
Yes, we did.

Google can not read the messages, that's the whole point of E2EE.

--
Cheers,
Carlos E.R.

Java Jive

unread,
Nov 9, 2023, 7:45:44 AM11/9/23
to
No, you didn't ...

> Google can not read the messages, that's the whole point of E2EE.

... because Google is running the OS that is decrypting it for you.

Frank Slootweg

unread,
Nov 9, 2023, 8:17:32 AM11/9/23
to
Java Jive <ja...@evij.com.invalid> wrote:
> On 09/11/2023 11:02, Carlos E. R. wrote:
> > On 2023-11-09 11:17, Java Jive wrote:
> >> On 08/11/2023 14:53, Frank Slootweg wrote:
> >>>
> >>> Java Jive <ja...@evij.com.invalid> wrote:
> >>>>
> >>>> On 07/11/2023 20:26, Carlos E. R. wrote:
> >>>>>
> >>>>> Oh, I did reply. You are not ilustrate enough to understand.
[...]
> >>>    Anyway, before criticizing others, first learn the difference between
> >>> end-to-end-encryption and no encryption. That Joerg is siding with you,
> >>> should be a red flag, a *big* one!
> >>
> >> No-one has answered my basic point that, if Google run the OS, and
> >> Carlos can read the message, so can Google,

No they can't. See below.

> >> and, given Google's track
> >> record, most probably they will.

You're still misunderstanding/misrepresenting "Google's track record".
Footstamping doesn't make a credible argument.

> > Yes, we did.
>
> No, you didn't ...
>
> > Google can not read the messages, that's the whole point of E2EE.
>
> ... because Google is running the OS that is decrypting it for you.

Nope, the OS is not doing the decrypting.

But your -invalid - point seems to be that someone - i.e. also Google
- could have a backdoor somewhere.

Yes, that's theoretically possible, but in practice it's extremely
unlikely, because that would get them in big, big trouble.

But even if you accept that premise, it also holds for any other
company which provides end-to-end-encryption, so you haven't any real
argument whatsoever.

So let's turn this around: What *proof* do *you* have that some other
company can *not* read your end-to-en-encrypted messages?

Java Jive

unread,
Nov 9, 2023, 9:05:11 AM11/9/23
to
On 09/11/2023 13:17, Frank Slootweg wrote:
> Java Jive <ja...@evij.com.invalid> wrote:
>> On 09/11/2023 11:02, Carlos E. R. wrote:
>>> On 2023-11-09 11:17, Java Jive wrote:
>>>> On 08/11/2023 14:53, Frank Slootweg wrote:
>>>>>
>>>>> Java Jive <ja...@evij.com.invalid> wrote:
>>>>>>
>>>>>> On 07/11/2023 20:26, Carlos E. R. wrote:
>>>>>>>
>>>>>>> Oh, I did reply. You are not ilustrate enough to understand.
> [...]
>>>>>    Anyway, before criticizing others, first learn the difference between
>>>>> end-to-end-encryption and no encryption. That Joerg is siding with you,
>>>>> should be a red flag, a *big* one!
>>>>
>>>> No-one has answered my basic point that, if Google run the OS, and
>>>> Carlos can read the message, so can Google,
>
> No they can't. See below.
>
>>>> and, given Google's track
>>>> record, most probably they will.
>
> You're still misunderstanding/misrepresenting "Google's track record".
> Footstamping doesn't make a credible argument.

Track record is all anyone has to judge a company. I can only suggest
that you read Shoshana Zuboff's book "The Age Of Surveillance
Capitalism" which goes into detail on their track record.

>>> Yes, we did.
>>
>> No, you didn't ...
>>
>>> Google can not read the messages, that's the whole point of E2EE.
>>
>> ... because Google is running the OS that is decrypting it for you.
>
> Nope, the OS is not doing the decrypting.
>
> But your -invalid - point seems to be that someone - i.e. also Google
> - could have a backdoor somewhere.
>
> Yes, that's theoretically possible, but in practice it's extremely
> unlikely, because that would get them in big, big trouble.

No back-doors are needed when the front is wide-open. The results of
decryption are fed back through the OS to be given to the user.

> But even if you accept that premise, it also holds for any other
> company which provides end-to-end-encryption, so you haven't any real
> argument whatsoever.
>
> So let's turn this around: What *proof* do *you* have that some other
> company can *not* read your end-to-en-encrypted messages?

This argument is exactly about Google, so why try to omit them from the
argument? The point of principle is that *any* company, *including*
Google, that provides an OS can read the results of a decryption after
it has taken place within that OS, so all the general public have to go
on in deciding whether to trust such a company is track-record, and
Google's does not encourage such trust.

Carlos E. R.

unread,
Nov 9, 2023, 9:22:15 AM11/9/23
to
Irrelevant.

--
Cheers,
Carlos E.R.

Frank Slootweg

unread,
Nov 9, 2023, 10:22:26 AM11/9/23
to
Java Jive <ja...@evij.com.invalid> wrote:
> On 09/11/2023 13:17, Frank Slootweg wrote:
> > Java Jive <ja...@evij.com.invalid> wrote:
> >> On 09/11/2023 11:02, Carlos E. R. wrote:
> >>> On 2023-11-09 11:17, Java Jive wrote:
> >>>> On 08/11/2023 14:53, Frank Slootweg wrote:
> >>>>>
> >>>>> Java Jive <ja...@evij.com.invalid> wrote:
> >>>>>>
> >>>>>> On 07/11/2023 20:26, Carlos E. R. wrote:
> >>>>>>>
> >>>>>>> Oh, I did reply. You are not ilustrate enough to understand.
> > [...]
> >>>>>    Anyway, before criticizing others, first learn the difference between
> >>>>> end-to-end-encryption and no encryption. That Joerg is siding with you,
> >>>>> should be a red flag, a *big* one!
> >>>>
> >>>> No-one has answered my basic point that, if Google run the OS, and
> >>>> Carlos can read the message, so can Google,
> >
> > No they can't. See below.
> >
> >>>> and, given Google's track
> >>>> record, most probably they will.
> >
> > You're still misunderstanding/misrepresenting "Google's track record".
> > Footstamping doesn't make a credible argument.
>
> Track record is all anyone has to judge a company. I can only suggest
> that you read Shoshana Zuboff's book "The Age Of Surveillance
> Capitalism" which goes into detail on their track record.

Irrelevant. You misrepresent what Google is doing with Gmail and you
misunderstand how E2EE works / does not work.

> >>> Yes, we did.
> >>
> >> No, you didn't ...
> >>
> >>> Google can not read the messages, that's the whole point of E2EE.
> >>
> >> ... because Google is running the OS that is decrypting it for you.
> >
> > Nope, the OS is not doing the decrypting.
> >
> > But your -invalid - point seems to be that someone - i.e. also Google
> > - could have a backdoor somewhere.
> >
> > Yes, that's theoretically possible, but in practice it's extremely
> > unlikely, because that would get them in big, big trouble.
>
> No back-doors are needed when the front is wide-open. The results of
> decryption are fed back through the OS to be given to the user.

Nope. That's not how E2EE works. The OS does not see the decrypted
data (unless there's a backdoor).

Example: WhatsApp and other IM platforms.

> > But even if you accept that premise, it also holds for any other
> > company which provides end-to-end-encryption, so you haven't any real
> > argument whatsoever.
> >
> > So let's turn this around: What *proof* do *you* have that some other
> > company can *not* read your end-to-en-encrypted messages?
>
> This argument is exactly about Google, so why try to omit them from the
> argument?

I don't omit them, you single them out.

> The point of principle is that *any* company, *including*
> Google, that provides an OS can read the results of a decryption after
> it has taken place within that OS,

But that's your false premise, the decryption does *not* "take place
within that OS".

> so all the general public have to go
> on in deciding whether to trust such a company is track-record, and
> Google's does not encourage such trust.

Well, on *this* (note emphasis) aspect (RCS E2EE), I trust Google more
than some Usenet poster who 'compares' totally different subject
matters.

I'm done.

'End-to-end encryption'
<https://en.wikipedia.org/wiki/End-to-end_encryption>

Java Jive

unread,
Nov 9, 2023, 12:09:13 PM11/9/23
to
The book is totally relevant, long sections of it details the evidence
of Google's snooping.

>>>>> Yes, we did.
>>>>
>>>> No, you didn't ...
>>>>
>>>>> Google can not read the messages, that's the whole point of E2EE.
>>>>
>>>> ... because Google is running the OS that is decrypting it for you.
>>>
>>> Nope, the OS is not doing the decrypting.
>>>
>>> But your -invalid - point seems to be that someone - i.e. also Google
>>> - could have a backdoor somewhere.
>>>
>>> Yes, that's theoretically possible, but in practice it's extremely
>>> unlikely, because that would get them in big, big trouble.
>>
>> No back-doors are needed when the front is wide-open. The results of
>> decryption are fed back through the OS to be given to the user.
>
> Nope. That's not how E2EE works. The OS does not see the decrypted
> data (unless there's a backdoor).

So, for example, the encryption has its own routines to display a
message on the screen of the device? No, of course not, OS routines do it.

> Example: WhatsApp and other IM platforms.
>
>>> But even if you accept that premise, it also holds for any other
>>> company which provides end-to-end-encryption, so you haven't any real
>>> argument whatsoever.
>>>
>>> So let's turn this around: What *proof* do *you* have that some other
>>> company can *not* read your end-to-en-encrypted messages?
>>
>> This argument is exactly about Google, so why try to omit them from the
>> argument?
>
> I don't omit them, you single them out.

On account of their known record of monetising what should be customers'
private data.

>> The point of principle is that *any* company, *including*
>> Google, that provides an OS can read the results of a decryption after
>> it has taken place within that OS,
>
> But that's your false premise, the decryption does *not* "take place
> within that OS".

Well, that's trying to bend what I'm saying to suit your own argument,
but doesn't make it any less true. How exactly do you want me to say
it? The OS controls the memory space within the device; it controls the
time sharing between applications; in response to user input it launches
the programs that use the encryption; finally and most importantly, OS
routines output the decrypted data on the screen or whereever. I think
it's reasonable to describe that process as I did above.

>> so all the general public have to go
>> on in deciding whether to trust such a company is track-record, and
>> Google's does not encourage such trust.
>
> Well, on *this* (note emphasis) aspect (RCS E2EE), I trust Google more
> than some Usenet poster

Fine, but, from the sound of it, you would still be very well advised to
read Shoshana Zuboff's book to understand what is really going on with
Google and other like companies.

> who 'compares' totally different subject
> matters.

Eh? Let me remind how this whole subthread began, which was as follows:

On 05/11/2023 15:57, Jeff Layman wrote:
>
> I assume that if Google gets their success with RCS that would mean
> more data available for analysis by them, and more ads for us.

[Note: I've already pointed out that he should have said "more targetted
ads for us."]

To which Carlos replied:

On 06/11/2023 00:53, Carlos E. R. wrote:
>
> No, no big company with a modicum of sense would do that. Just
> collecting data, massively, to analyze and target publicity? That
> would get known, many people need to be in the know to make use of
> that lot of data. Too risky. Thus, not likely.

But Google are already known to do just that, viz: "Just collecting
data, massively, to analyze and target publicity", so I replied:

On 06/11/2023 11:25, Java Jive wrote:
>
> Except Google are already known to be doing this - by their own
> admission they already scan all emails on gmail, etc. I don't
> knowingly use cloud services, and therefore haven't read any of the
> T&C of any cloud service, but I wouldn't be at all surprised to find
> somewhere in there some phrase such as:
>
> "I agree that <Google|whoever> scans my data for malware and the
> purpose of improving their services to me."

So ISTM that I've been entirely consistent in what I've said.

Java Jive

unread,
Nov 9, 2023, 12:11:27 PM11/9/23
to
Sigh! How do you think it gets from the app using encryption onto the
screen so that you can read it?

Frank Slootweg

unread,
Nov 9, 2023, 2:04:32 PM11/9/23
to
Java Jive <ja...@evij.com.invalid> wrote:
> On 09/11/2023 15:22, Frank Slootweg wrote:
> > Java Jive <ja...@evij.com.invalid> wrote:
> >> On 09/11/2023 13:17, Frank Slootweg wrote:
> >>> Java Jive <ja...@evij.com.invalid> wrote:
> >>>> On 09/11/2023 11:02, Carlos E. R. wrote:
> >>>>> On 2023-11-09 11:17, Java Jive wrote:
> >>>>>> On 08/11/2023 14:53, Frank Slootweg wrote:
> >>>>>>>
> >>>>>>> Java Jive <ja...@evij.com.invalid> wrote:
> >>>>>>>>
> >>>>>>>> On 07/11/2023 20:26, Carlos E. R. wrote:
> >>>>>>>>>
> >>>>>>>>> Oh, I did reply. You are not ilustrate enough to understand.
> >>> [...]
> >>>>>>> Anyway, before criticizing others, first learn the
> >>>>>>> difference between end-to-end-encryption and no encryption.
> >>>>>>> That Joerg is siding with you, should be a red flag, a *big*
> >>>>>>> one!
> >>>>>>
> >>>>>> No-one has answered my basic point that, if Google run the OS, and
> >>>>>> Carlos can read the message, so can Google,
> >>>
> >>> No they can't. See below.
> >>>
> >>>>>> record, most probably they will.
> >>>
> >>> You're still misunderstanding/misrepresenting "Google's track record".
> >>> Footstamping doesn't make a credible argument.
> >>
> >> Track record is all anyone has to judge a company. I can only suggest
> >> that you read Shoshana Zuboff's book "The Age Of Surveillance
> >> Capitalism" which goes into detail on their track record.
> >
> > Irrelevant. You misrepresent what Google is doing with Gmail and you
> > misunderstand how E2EE works / does not work.
>
> The book is totally relevant, long sections of it details the evidence
> of Google's snooping.

So you keep saying, but your definition of "snooping" seems to be a
rather strange one. Case in point: Google is *not* "snooping" Gmail.
What they do - i.e. scanning - is in their T&Cs. Don't like it, don't
use it. *And*, as I said, but you 'conveniently' ignored, that evil
"snooping" of my Gmail hasn't resulted in a single ad in over 15 years.
Bad Google, bad, bad Google!

> >>>>> Yes, we did.
> >>>>
> >>>> No, you didn't ...
> >>>>
> >>>>> Google can not read the messages, that's the whole point of E2EE.
> >>>>
> >>>> ... because Google is running the OS that is decrypting it for you.
> >>>
> >>> Nope, the OS is not doing the decrypting.
> >>>
> >>> But your -invalid - point seems to be that someone - i.e. also Google
> >>> - could have a backdoor somewhere.
> >>>
> >>> Yes, that's theoretically possible, but in practice it's extremely
> >>> unlikely, because that would get them in big, big trouble.
> >>
> >> No back-doors are needed when the front is wide-open. The results of
> >> decryption are fed back through the OS to be given to the user.
> >
> > Nope. That's not how E2EE works. The OS does not see the decrypted
> > data (unless there's a backdoor).
>
> So, for example, the encryption has its own routines to display a
> message on the screen of the device? No, of course not, OS routines do it.

Sigh! If you're implying that Google is intercepting user data which
is written to the screen (or coming from the keyboard), then that's a
backdoor, which 1) we've said would get them in big, big trouble and 2)
I had specifically excluded.

> > Example: WhatsApp and other IM platforms.

Hmm!? No comment? Strange!

> >>> But even if you accept that premise, it also holds for any other
> >>> company which provides end-to-end-encryption, so you haven't any real
> >>> argument whatsoever.
> >>>
> >>> So let's turn this around: What *proof* do *you* have that some other
> >>> company can *not* read your end-to-en-encrypted messages?
> >>
> >> This argument is exactly about Google, so why try to omit them from the
> >> argument?
> >
> > I don't omit them, you single them out.
>
> On account of their known record of monetising what should be customers'
> private data.

As do many others, so it's not a reason to single them out, but you
still did and do.

Face it, you just have an agenda. Don't insult us trying to hide it
behind (non-)technical claptrap.

BTW, I assume you don't actually own or use any Android devices,
Google services, etc..

> >> The point of principle is that *any* company, *including*
> >> Google, that provides an OS can read the results of a decryption after
> >> it has taken place within that OS,
> >
> > But that's your false premise, the decryption does *not* "take place
> > within that OS".
>
> Well, that's trying to bend what I'm saying to suit your own argument,
> but doesn't make it any less true. How exactly do you want me to say
> it? The OS controls the memory space within the device; it controls the
> time sharing between applications; in response to user input it launches
> the programs that use the encryption; finally and most importantly, OS
> routines output the decrypted data on the screen or whereever. I think
> it's reasonable to describe that process as I did above.

See above.

> >> so all the general public have to go
> >> on in deciding whether to trust such a company is track-record, and
> >> Google's does not encourage such trust.
> >
> > Well, on *this* (note emphasis) aspect (RCS E2EE), I trust Google more
> > than some Usenet poster
>
> Fine, but, from the sound of it, you would still be very well advised to
> read Shoshana Zuboff's book to understand what is really going on with
> Google and other like companies.

Ah, at least now you include "other like companies", so it's just a
general concern and not really relevant to Google's RCS E2EE. Check.

> > who 'compares' totally different subject
> > matters.
>
> Eh? Let me remind how this whole subthread began, which was as follows:
[lots deleted]
> So ISTM that I've been entirely consistent in what I've said.

Yes, you've been consistent. Consistently biased and consistently
wrong.

EOD.

Carlos E. R.

unread,
Nov 9, 2023, 2:44:52 PM11/9/23
to
None on E2EE streams.

>
>>>>>> Yes, we did.
>>>>>
>>>>> No, you didn't ...
>>>>>
>>>>>> Google can not read the messages, that's the whole point of E2EE.
>>>>>
>>>>> ... because Google is running the OS that is decrypting it for you.
>>>>
>>>>     Nope, the OS is not doing the decrypting.
>>>>     But your -invalid - point seems to be that someone - i.e. also
>>>> Google
>>>> - could have a backdoor somewhere.
>>>>
>>>>     Yes, that's theoretically possible, but in practice it's extremely
>>>> unlikely, because that would get them in big, big trouble.
>>>
>>> No back-doors are needed when the front is wide-open.  The results of
>>> decryption are fed back through the OS to be given to the user.
>>
>>    Nope. That's not how E2EE works. The OS does not see the decrypted
>> data (unless there's a backdoor).
>
> So, for example, the encryption has its own routines to display a
> message on the screen of the device?  No, of course not, OS routines do it.

That would be known eventually, and the culprit would get smeared in big
shit and court suits.

It is simply not done.

>
>>    Example: WhatsApp and other IM platforms.
>>
>>>>     But even if you accept that premise, it also holds for any other
>>>> company which provides end-to-end-encryption, so you haven't any real
>>>> argument whatsoever.
>>>>
>>>>     So let's turn this around: What *proof* do *you* have that some
>>>> other
>>>> company can *not* read your end-to-en-encrypted messages?
>>>
>>> This argument is exactly about Google, so why try to omit them from the
>>> argument?
>>
>>    I don't omit them, you single them out.
>
> On account of their known record of monetising what should be customers'
> private data.

I'm sure that it is mentioned in their terms and conditions, and that
data is not E2EE.


>
>>>            The point of principle is that *any* company, *including*
>>> Google, that provides an OS can read the results of a decryption after
>>> it has taken place within that OS,
>>
>>    But that's your false premise, the decryption does *not* "take place
>> within that OS".
>
> Well, that's trying to bend what I'm saying to suit your own argument,
> but doesn't make it any less true.  How exactly do you want me to say
> it?  The OS controls the memory space within the device; it controls the
> time sharing between applications; in response to user input it launches
> the programs that use the encryption; finally and most importantly, OS
> routines output the decrypted data on the screen or whereever.  I think
> it's reasonable to describe that process as I did above.

No, it isn't.

>
>>>                      so all the general public have to go
>>> on in deciding whether to trust such a company is track-record, and
>>> Google's does not encourage such trust.
>>
>>    Well, on *this* (note emphasis) aspect (RCS E2EE), I trust Google more
>> than some Usenet poster
>
> Fine, but, from the sound of it, you would still be very well advised to
> read Shoshana Zuboff's book to understand what is really going on with
> Google and other like companies.
>
>> who 'compares' totally different subject
>> matters.
>
> Eh?  Let me remind how this whole subthread began, which was as follows:
>
> On 05/11/2023 15:57, Jeff Layman wrote:
> >
> > I assume that if Google gets their success with RCS that would mean
> > more data available for analysis by them, and more ads for us.
>
> [Note: I've already pointed out that he should have said "more targetted
> ads for us."]
>
> To which Carlos replied:
>
> On 06/11/2023 00:53, Carlos E. R. wrote:
> >
> > No, no big company with a modicum of sense would do that. Just
> > collecting data, massively, to analyze and target publicity? That
> > would get known, many people need to be in the know to make use of
> > that lot of data. Too risky. Thus, not likely.
>
> But Google are already known to do just that, viz: "Just collecting
> data, massively, to analyze and target publicity", so I replied:

No, they are not known to do just that with E2EE streams.

>
> On 06/11/2023 11:25, Java Jive wrote:
> >
> > Except Google are already known to be doing this  -  by their own
> > admission they already scan all emails on gmail, etc.  I don't
> > knowingly use cloud services, and therefore haven't read any of the
> > T&C of any cloud service, but I wouldn't be at all surprised to find
> > somewhere in there some phrase such as:
> >
> > "I agree that <Google|whoever> scans my data for malware and the
> > purpose of improving their services to me."
>
> So ISTM that I've been entirely consistent in what I've said.

Consistently paranoid without justification.

--
Cheers,
Carlos E.R.

Java Jive

unread,
Nov 9, 2023, 3:44:43 PM11/9/23
to
Whether or not it's in their T&C, which almost no-one reads anyway -
see the definition of the 'uncontract' in Shoshana Zuboff's book -
scanning email is a form of snooping, because it is concerning
themselves with private things that shouldn't be their concern.

>>>>>>> Yes, we did.
>>>>>>
>>>>>> No, you didn't ...
>>>>>>
>>>>>>> Google can not read the messages, that's the whole point of E2EE.
>>>>>>
>>>>>> ... because Google is running the OS that is decrypting it for you.
>>>>>
>>>>> Nope, the OS is not doing the decrypting.
>>>>>
>>>>> But your -invalid - point seems to be that someone - i.e. also Google
>>>>> - could have a backdoor somewhere.
>>>>>
>>>>> Yes, that's theoretically possible, but in practice it's extremely
>>>>> unlikely, because that would get them in big, big trouble.
>>>>
>>>> No back-doors are needed when the front is wide-open. The results of
>>>> decryption are fed back through the OS to be given to the user.
>>>
>>> Nope. That's not how E2EE works. The OS does not see the decrypted
>>> data (unless there's a backdoor).
>>
>> So, for example, the encryption has its own routines to display a
>> message on the screen of the device? No, of course not, OS routines do it.
>
> Sigh! If you're implying that Google is intercepting user data which
> is written to the screen (or coming from the keyboard), then that's a
> backdoor, which 1) we've said would get them in big, big trouble and 2)
> I had specifically excluded.

Sigh! You're trying to play with words again - most people would
think of a backdoor as means of seeing into the encryption system
itself. Are you really trying to claim that a screen-reader for a blind
person is a back-door?

>>> Example: WhatsApp and other IM platforms.
>
> Hmm!? No comment? Strange!

They both have to write to the screen or other output device, so they
are covered by what I had already written.

>>>>> But even if you accept that premise, it also holds for any other
>>>>> company which provides end-to-end-encryption, so you haven't any real
>>>>> argument whatsoever.
>>>>>
>>>>> So let's turn this around: What *proof* do *you* have that some other
>>>>> company can *not* read your end-to-en-encrypted messages?
>>>>
>>>> This argument is exactly about Google, so why try to omit them from the
>>>> argument?
>>>
>>> I don't omit them, you single them out.
>>
>> On account of their known record of monetising what should be customers'
>> private data.
>
> As do many others, so it's not a reason to single them out, but you
> still did and do.

On the contrary, I specifically wrote, as is still quoted below: "*any*
company, *including* Google"

> Face it, you just have an agenda. Don't insult us trying to hide it
> behind (non-)technical claptrap.

My so-called 'agenda' was only ever to correct what Carlos wrote.

> BTW, I assume you don't actually own or use any Android devices,
> Google services, etc..

On the contrary I do, I just accept that it's relatively insecure -
apart from anything else, it might be lost or stolen - and thus don't
use it for purposes where security is important.

>>>> The point of principle is that *any* company, *including*
>>>> Google, that provides an OS can read the results of a decryption after
>>>> it has taken place within that OS,
>>>
>>> But that's your false premise, the decryption does *not* "take place
>>> within that OS".
>>
>> Well, that's trying to bend what I'm saying to suit your own argument,
>> but doesn't make it any less true. How exactly do you want me to say
>> it? The OS controls the memory space within the device; it controls the
>> time sharing between applications; in response to user input it launches
>> the programs that use the encryption; finally and most importantly, OS
>> routines output the decrypted data on the screen or whereever. I think
>> it's reasonable to describe that process as I did above.
>
> See above.

There is nothing above that is relevant to my point.

>>>> so all the general public have to go
>>>> on in deciding whether to trust such a company is track-record, and
>>>> Google's does not encourage such trust.
>>>
>>> Well, on *this* (note emphasis) aspect (RCS E2EE), I trust Google more
>>> than some Usenet poster
>>
>> Fine, but, from the sound of it, you would still be very well advised to
>> read Shoshana Zuboff's book to understand what is really going on with
>> Google and other like companies.
>
> Ah, at least now you include "other like companies", so it's just a
> general concern and not really relevant to Google's RCS E2EE. Check.

I've never said anything different.

>>> who 'compares' totally different subject
>>> matters.
>>
>> Eh? Let me remind how this whole subthread began, which was as follows:
> [lots deleted]
>> So ISTM that I've been entirely consistent in what I've said.
>
> Yes, you've been consistent. Consistently biased and consistently
> wrong.

On the contrary, you haven't yet been able to substantiate Carlos'
original claim that ...

On 06/11/2023 00:53, Carlos E. R. wrote:
>
> No, no big company with a modicum of sense would do that. Just
> collecting data, massively, to analyze and target publicity?

... whereas I've been able to give a concrete counter-example.

> EOD.

So you keep saying, but then keep replying, so rightly no-one takes any
notice of your attempt to make it look as though you've won an argument
when you haven't.

Carlos E. R.

unread,
Nov 9, 2023, 3:49:27 PM11/9/23
to
I read them.

> see the definition of the 'uncontract' in Shoshana Zuboff's book  -
> scanning email is a form of snooping, because it is concerning
> themselves with private things that shouldn't be their concern.

IT IS THEIR CONCERN. They said in their T&C they were going to do it.
You accepted this, and you clicked "I have read the T&C.
No, you haven't.

>>    EOD.
>
> So you keep saying, but then keep replying, so rightly no-one takes any
> notice of your attempt to make it look as though you've won an argument
> when you haven't.

Yours is simply ridiculous.

--
Cheers,
Carlos E.R.

Java Jive

unread,
Nov 9, 2023, 4:17:33 PM11/9/23
to
I think you're probably right that it's somewhere in their T&C, but
that's partly the point, few people actually bother to read them, so
it's an 'uncontract' that gives them legal coverage to snoop on people
with many or most of their customers probably being completely unaware
that it is happening.

>>>>            The point of principle is that *any* company, *including*
>>>> Google, that provides an OS can read the results of a decryption after
>>>> it has taken place within that OS,
>>>
>>>    But that's your false premise, the decryption does *not* "take place
>>> within that OS".
>>
>> Well, that's trying to bend what I'm saying to suit your own argument,
>> but doesn't make it any less true.  How exactly do you want me to say
>> it?  The OS controls the memory space within the device; it controls
>> the time sharing between applications; in response to user input it
>> launches the programs that use the encryption; finally and most
>> importantly, OS routines output the decrypted data on the screen or
>> whereever.  I think it's reasonable to describe that process as I did
>> above.
>
> No, it isn't.

The words used don't alter the principle of what I'm saying, which is
that E2EE only works between the two endpoints, it's what happens
outside of that that is the potential problem.
Not *known* to be happening with E2EE streams doesn't mean that in fact
it isn't happening, because, if it was, presumably the intention would
be to ensure that it wasn't widely known; I have never tried to claim
that it was happening or was not, merely I'm pointing out that in
principle it *could* happen, and that your faith in Google or any
similar company is misplaced, and, even worse, that the reason you gave
for your faith is actually false, as I have shown below ...

>> On 06/11/2023 11:25, Java Jive wrote:
>>  >
>>  > Except Google are already known to be doing this  -  by their own
>>  > admission they already scan all emails on gmail, etc.  I don't
>>  > knowingly use cloud services, and therefore haven't read any of the
>>  > T&C of any cloud service, but I wouldn't be at all surprised to find
>>  > somewhere in there some phrase such as:
>>  >
>>  > "I agree that <Google|whoever> scans my data for malware and the
>>  > purpose of improving their services to me."
>>
>> So ISTM that I've been entirely consistent in what I've said.
>
> Consistently paranoid without justification.

I'm not paranoid at all, just pointing that you are mistaken in your
assertion that "No, no big company with a modicum of sense would do
that. Just collecting data, massively, to analyze and target publicity?"
because that is *exactly* how Google make 80% of their revenue:

https://www.statista.com/statistics/266249/advertising-revenue-of-google/

Java Jive

unread,
Nov 9, 2023, 4:35:06 PM11/9/23
to
On 09/11/2023 20:49, Carlos E. R. wrote:
>
> On 2023-11-09 21:44, Java Jive wrote:
>>
>> On 09/11/2023 19:04, Frank Slootweg wrote:
>>>
>>> Java Jive <ja...@evij.com.invalid> wrote:
>>>>
>>>> The book is totally relevant, long sections of it details the evidence
>>>> of Google's snooping.
>>>
>>>    So you keep saying, but your definition of "snooping" seems to be a
>>> rather strange one. Case in point: Google is *not* "snooping" Gmail.
>>> What they do - i.e. scanning - is in their T&Cs. Don't like it, don't
>>> use it. *And*, as I said, but you 'conveniently' ignored, that evil
>>> "snooping" of my Gmail hasn't resulted in a single ad in over 15 years.
>>> Bad Google, bad, bad Google!
>>
>> Whether or not it's in their T&C, which almost no-one reads anyway  -
>
> I read them.

Fine, but most people don't.

>> see the definition of the 'uncontract' in Shoshana Zuboff's book  -
>> scanning email is a form of snooping, because it is concerning
>> themselves with private things that shouldn't be their concern.
>
> IT IS THEIR CONCERN. They said in their T&C they were going to do it.
> You accepted this, and you clicked "I have read the T&C.

Your emails should be private and not anyone else's concern.

>> On the contrary, you haven't yet been able to substantiate Carlos'
>> original claim that ...
>>
>> On 06/11/2023 00:53, Carlos E. R. wrote:
>>  >
>>  > No, no big company with a modicum of sense would do that. Just
>>  > collecting data, massively, to analyze and target publicity?
>>
>> ... whereas I've been able to give a concrete counter-example.
>
> No, you haven't.

See other post, 80% of Google's income comes from targeted advertising
using big data, exactly opposite to what you wrote above.

>>>    EOD.
>>
>> So you keep saying, but then keep replying, so rightly no-one takes
>> any notice of your attempt to make it look as though you've won an
>> argument when you haven't.
>
> Yours is simply ridiculous.

However ridiculous or not it is, it has to be less ridiculous than
yours, because it is supported by the publicly known facts about Google,
Ad Sense, and the income they derive from the latter, as linked
elsewhere in the thread.

Carlos E. R.

unread,
Nov 9, 2023, 4:38:43 PM11/9/23
to
NO.

What I say is that it can not massively happen. If there is a hole like
that they can not use it on everybody, because it would get known
eventually and there would be hell to pay. Someone would murder them.

Obviously there are spy tools, but they target just a few individuals,
and secretively.

It is impossible to have a backdoor and use it to scan all the messages,
to scan everybody. Simply too dangerous for them.


>
>>> On 06/11/2023 11:25, Java Jive wrote:
>>>  >
>>>  > Except Google are already known to be doing this  -  by their own
>>>  > admission they already scan all emails on gmail, etc.  I don't
>>>  > knowingly use cloud services, and therefore haven't read any of the
>>>  > T&C of any cloud service, but I wouldn't be at all surprised to find
>>>  > somewhere in there some phrase such as:
>>>  >
>>>  > "I agree that <Google|whoever> scans my data for malware and the
>>>  > purpose of improving their services to me."
>>>
>>> So ISTM that I've been entirely consistent in what I've said.
>>
>> Consistently paranoid without justification.
>
> I'm not paranoid at all, just pointing that you are mistaken in your
> assertion that "No, no big company with a modicum of sense would do
> that. Just collecting data, massively, to analyze and target publicity?"
> because that is *exactly* how Google make 80% of their revenue:

Ad it is in their T&C, and doesn't apply to E2EE streams.

>
> https://www.statista.com/statistics/266249/advertising-revenue-of-google/
>

--
Cheers,
Carlos E.R.

Carlos E. R.

unread,
Nov 9, 2023, 5:21:07 PM11/9/23
to
On 2023-11-09 22:35, Java Jive wrote:
> On 09/11/2023 20:49, Carlos E. R. wrote:
>>
>> On 2023-11-09 21:44, Java Jive wrote:
>>>
>>> On 09/11/2023 19:04, Frank Slootweg wrote:
>>>>
>>>> Java Jive <ja...@evij.com.invalid> wrote:
>>>>>
>>>>> The book is totally relevant, long sections of it details the evidence
>>>>> of Google's snooping.
>>>>
>>>>    So you keep saying, but your definition of "snooping" seems to be a
>>>> rather strange one. Case in point: Google is *not* "snooping" Gmail.
>>>> What they do - i.e. scanning - is in their T&Cs. Don't like it, don't
>>>> use it. *And*, as I said, but you 'conveniently' ignored, that evil
>>>> "snooping" of my Gmail hasn't resulted in a single ad in over 15 years.
>>>> Bad Google, bad, bad Google!
>>>
>>> Whether or not it's in their T&C, which almost no-one reads anyway  -
>>
>> I read them.
>
> Fine, but most people don't.

Those can not complain.

>>> see the definition of the 'uncontract' in Shoshana Zuboff's book  -
>>> scanning email is a form of snooping, because it is concerning
>>> themselves with private things that shouldn't be their concern.
>>
>> IT IS THEIR CONCERN. They said in their T&C they were going to do it.
>> You accepted this, and you clicked "I have read the T&C.
>
> Your emails should be private and not anyone else's concern.

Well, it is not so. It is in the T&C. It is not a matter of opinion, it
is the law.


>>> On the contrary, you haven't yet been able to substantiate Carlos'
>>> original claim that ...
>>>
>>> On 06/11/2023 00:53, Carlos E. R. wrote:
>>>  >
>>>  > No, no big company with a modicum of sense would do that. Just
>>>  > collecting data, massively, to analyze and target publicity?
>>>
>>> ... whereas I've been able to give a concrete counter-example.
>>
>> No, you haven't.
>
> See other post, 80% of Google's income comes from targeted advertising
> using big data, exactly opposite to what you wrote above.

I have, and you are simply wrong.

>
>>>>    EOD.
>>>
>>> So you keep saying, but then keep replying, so rightly no-one takes
>>> any notice of your attempt to make it look as though you've won an
>>> argument when you haven't.
>>
>> Yours is simply ridiculous.
>
> However ridiculous or not it is, it has to be less ridiculous than
> yours, because it is supported by the publicly known facts about Google,
> Ad Sense, and the income they derive from the latter, as linked
> elsewhere in the thread.
>

LOL.

I'll just write you off as paranoic, and EOD.


--
Cheers,
Carlos E.R.

Java Jive

unread,
Nov 9, 2023, 6:41:04 PM11/9/23
to
It's no good just denying it, what you wrote is still quoted above, and
the facts that disprove it are still linked, with further additions, below.

> What I say is that it can not massively happen. If there is a hole like
> that they can not use it on everybody, because it would get known
> eventually and there would be hell to pay. Someone would murder them.
>
> Obviously there are spy tools, but they target just a few individuals,
> and secretively.

That may have been what you meant, but it's not what you wrote. We are
not psychic, and can only argue with what you actually wrote.

> It is impossible to have a backdoor and use it to scan all the messages,
> to scan everybody. Simply too dangerous for them.

How many times do I have to point out that it doesn't have to be a
backdoor, when the front door is wide open. For example, most devices
can support accessibility functionality such as screen-readers.

Like I said, the foundations of your faith are false.

>> I'm not paranoid at all, just pointing that you are mistaken in your
>> assertion that "No, no big company with a modicum of sense would do
>> that. Just collecting data, massively, to analyze and target
>> publicity?" because that is *exactly* how Google make 80% of their
>> revenue:
>
> Ad it is in their T&C, and doesn't apply to E2EE streams.

Firstly, if, as you claim, you had read the T&C of GMail and therefore
knew that scanning was in their T&C, why did you write the falsehood
requoted above that began this subthread? However, see new information
below ...

Secondly, to find out what else may be going on, at very least you'd
have to examine the T&C of Android itself, not just the E2EE encryption
software or of any app that uses it, but, preferably also, you'd have to
examine all the Android code.

>> https://www.statista.com/statistics/266249/advertising-revenue-of-google/

I was trying to find out what percentage of GMail users were actually
aware that their mails were scanned, and found these instead:

Google will stop scanning content of personal emails
https://www.theguardian.com/technology/2017/jun/26/google-will-stop-scanning-content-of-personal-emails

"Although G Suite customers, who pay Google for business use of a
portfolio of web apps including Gmail, Google Docs, Calendar and
Contacts, have never had their messages scanned for use in advertising,
many potential customers were nonetheless put off the product by the
mistaken impression that they were, Greene told Bloomberg. “What we’re
going to do is make it unambiguous,” she said."

... so, basically, we have business users to thank for forcing Google
partially to clean up GMail for personal users, and, according to the
same article, their cloud platforms as well.

And ...

Google promised not to scan Gmail for targeted ads—but for how long?
https://arstechnica.com/tech-policy/2017/09/google-promised-not-to-scan-gmail-for-targeted-ads-but-for-how-long/

"On July 23, Google promised with great fanfare that it would stop
scanning consumers' Gmail messages to serve targeted, contextually aware
ads. The announcement—which put Gmail in line with competing services
and Google's paid e-mail for government, business, and education
sectors—was published widely, from tech blogs to the mainstream media.
"Free consumer Gmail users," Google said, "can remain confident that
Google will keep privacy and security paramount as we continue to innovate."

However, court documents suggest that this could be temporary. A month
after Google's announcement, the company quietly agreed to settle a
class-action lawsuit alleging that the targeted-advertising scanning was
illegal wiretapping. That deal, in which a federal judge gave
"preliminarily approval" (PDF link) to on Thursday, binds Google for
just three years."

... and ...

How private is your Gmail, and should you switch?
https://www.theguardian.com/technology/2021/may/09/how-private-is-your-gmail-and-should-you-switch

"Although Google stopped scanning email content to tailor ads in 2017,
last year the company started showing shopping ads in Gmail. And it
still scans emails to facilitate so-called smart features such as the
ability to add holiday bookings or deliveries straight to your calendar,
or to autocomplete suggestions.

Every way you interact with your Gmail account can be monitored, such as
the dates and times you email at, who you are talking to, and topics you
choose to email about, says Rowenna Fielding, founder of privacy
consultancy Miss IG Geek.

How Google uses your data

Much of the information collected by Gmail and shared with advertisers
is metadata – data about data. But if you carry cookies from other
Google services, your activity can be correlated or “fingerprinted” from
associated products such as Google Maps and YouTube. “Gmail becomes a
window into your entire online life because of how wide and deep their
surveillance architecture goes,” Fielding says. “Practically everything
you do online will feed back to Google.”

Google claims none of the data collected from scanning emails for
purchase information, delivery tracking numbers and flight bookings is
used for advertising, but as Andy Yen, founder and CEO of secure email
service ProtonMail says: “It remains a fact that Google keeps a record
of these events and logs them regardless.”"

The above article is worth reading in its entirety.

But even worse ...

Google Still Lets Third-Party Devs Scan Your Email
https://www.tomshardware.com/news/google-lets-developers-scan-email,37829.html

"How else is a third-party app made specifically for Gmail supposed to
function? People use these products because they want to be able to
handle their inboxes better, extract information from the far-too-many
emails they receive each day, or do something else that Gmail doesn't.
Being upset that Google lets developers access this data is like someone
in a high-rise being mad at their doorman for letting UPS into the building.

There is one key difference: the WSJ reported in July that some of these
developers were having their employees read some emails themselves so
they could train AI. Developers can also share information with outside
companies, meaning information gleaned via email scanning could be used
to inform advertisements, for example. A lot of Gmail users probably
didn't realize the contents of their emails could be used in that way."

Etc, etc. Expert opinion seems united on the point that, while other
firms aren't very much better, GMail are consistently the worst
offenders for personal data collection, aka snooping.

Sadly, I wasn't able to discover what percentage of GMail users were or
are aware of their emails being scanned. Whether by Google or others
barely seems relevant to me, my point being that it shouldn't be
happening at all. However, legally it might make a difference, because
the user signs Google's T&C, but not those of others business entities.

Java Jive

unread,
Nov 9, 2023, 7:06:58 PM11/9/23
to
On 09/11/2023 22:21, Carlos E. R. wrote:
> On 2023-11-09 22:35, Java Jive wrote:
>> On 09/11/2023 20:49, Carlos E. R. wrote:
>>>
>>> On 2023-11-09 21:44, Java Jive wrote:
>>>>
>>>> On 09/11/2023 19:04, Frank Slootweg wrote:
>>>>>
>>>>> Java Jive <ja...@evij.com.invalid> wrote:
>>>>>>
>>>>>> The book is totally relevant, long sections of it details the
>>>>>> evidence
>>>>>> of Google's snooping.
>>>>>
>>>>>    So you keep saying, but your definition of "snooping" seems to be a
>>>>> rather strange one. Case in point: Google is *not* "snooping" Gmail.
>>>>> What they do - i.e. scanning - is in their T&Cs. Don't like it, don't
>>>>> use it. *And*, as I said, but you 'conveniently' ignored, that evil
>>>>> "snooping" of my Gmail hasn't resulted in a single ad in over 15
>>>>> years.
>>>>> Bad Google, bad, bad Google!
>>>>
>>>> Whether or not it's in their T&C, which almost no-one reads anyway  -
>>>
>>> I read them.
>>
>> Fine, but most people don't.
>
> Those can not complain.

That doesn't alter the fact that probably most people are not aware of
the implications of using GMail, see my other post.

>>>> see the definition of the 'uncontract' in Shoshana Zuboff's book  -
>>>> scanning email is a form of snooping, because it is concerning
>>>> themselves with private things that shouldn't be their concern.
>>>
>>> IT IS THEIR CONCERN. They said in their T&C they were going to do it.
>>> You accepted this, and you clicked "I have read the T&C.
>>
>> Your emails should be private and not anyone else's concern.
>
> Well, it is not so. It is in the T&C. It is not a matter of opinion, it
> is the law.

Legal right is not the same as ethical right.

>>>> On the contrary, you haven't yet been able to substantiate Carlos'
>>>> original claim that ...
>>>>
>>>> On 06/11/2023 00:53, Carlos E. R. wrote:
>>>>  >
>>>>  > No, no big company with a modicum of sense would do that. Just
>>>>  > collecting data, massively, to analyze and target publicity?
>>>>
>>>> ... whereas I've been able to give a concrete counter-example.
>>>
>>> No, you haven't.
>>
>> See other post, 80% of Google's income comes from targeted advertising
>> using big data, exactly opposite to what you wrote above.
>
> I have, and you are simply wrong.

You can jump up and down screaming "YOU'RE WRONG!" like a spoilt child
all you like, it doesn't alter one jot that the facts I've linked
disprove what you claimed.

> LOL.
>
> I'll just write you off as paranoic, and EOD.

LOL! I'll just write you off as naive, and a bad loser.

Frank Slootweg

unread,
Nov 10, 2023, 8:51:09 AM11/10/23
to
Java Jive <ja...@evij.com.invalid> wrote:
> On 09/11/2023 19:04, Frank Slootweg wrote:
> > Java Jive <ja...@evij.com.invalid> wrote:
> >> On 09/11/2023 15:22, Frank Slootweg wrote:
> >>> Java Jive <ja...@evij.com.invalid> wrote:
> >>>> On 09/11/2023 13:17, Frank Slootweg wrote:
> >>>>> Java Jive <ja...@evij.com.invalid> wrote:
> >>>>>> On 09/11/2023 11:02, Carlos E. R. wrote:
> >>>>>>> On 2023-11-09 11:17, Java Jive wrote:
> >>>>>>>> On 08/11/2023 14:53, Frank Slootweg wrote:
> >>>>>>>>>
> >>>>>>>>> Java Jive <ja...@evij.com.invalid> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On 07/11/2023 20:26, Carlos E. R. wrote:

[Gmail scanning hoopla deleted. There's just no point.]

> >>>>>>> Yes, we did.
> >>>>>>
> >>>>>> No, you didn't ...
> >>>>>>
> >>>>>>> Google can not read the messages, that's the whole point of E2EE.
> >>>>>>
> >>>>>> ... because Google is running the OS that is decrypting it for you.
> >>>>>
> >>>>> Nope, the OS is not doing the decrypting.
> >>>>>
> >>>>> But your -invalid - point seems to be that someone - i.e. also Google
> >>>>> - could have a backdoor somewhere.
> >>>>>
> >>>>> Yes, that's theoretically possible, but in practice it's extremely
> >>>>> unlikely, because that would get them in big, big trouble.
> >>>>
> >>>> No back-doors are needed when the front is wide-open. The results of
> >>>> decryption are fed back through the OS to be given to the user.
> >>>
> >>> Nope. That's not how E2EE works. The OS does not see the decrypted
> >>> data (unless there's a backdoor).
> >>
> >> So, for example, the encryption has its own routines to display a
> >> message on the screen of the device? No, of course not, OS routines do it.
> >
> > Sigh! If you're implying that Google is intercepting user data which
> > is written to the screen (or coming from the keyboard), then that's a
> > backdoor, which 1) we've said would get them in big, big trouble and 2)
> > I had specifically excluded.
>
> Sigh! You're trying to play with words again - most people would
> think of a backdoor as means of seeing into the encryption system
> itself. Are you really trying to claim that a screen-reader for a blind
> person is a back-door?

Nice try, but no cigar.

Nope, it's anything *but* playing with words. The example you describe
is *Google* deceitfully intercepting the user's (screen/keyboard) data
without their knowledge or approval. *That* *is* a backdoor.

The screen-reader for a blind person example is intentional behaviour
with the user's approval.

Two totally different and incomparable situations.

[...]

> > BTW, I assume you don't actually own or use any Android devices,
> > Google services, etc..
>
> On the contrary I do, I just accept that it's relatively insecure -
> apart from anything else, it might be lost or stolen - and thus don't
> use it for purposes where security is important.

A case of sarchasm.

[...]

> > EOD.
>
> So you keep saying, but then keep replying, so rightly no-one takes any
> notice of your attempt to make it look as though you've won an argument
> when you haven't.

Sigh! I keep replying because you keep coming up with more and even
more weird stuff and I don't want to give anyone the impression that you
might actually have a valid argument.

And no, I haven't 'won' an argument, because there *is* no argument,
just your opinion(s).

But if you like this better:

AFAIC, EOD.

Carlos E. R.

unread,
Nov 10, 2023, 9:07:00 AM11/10/23
to
No, they are not. It is just your paranoia, and it is EOD for me. Bye.

Not even reading the rest.

--
Cheers,
Carlos E.R.

Carlos E. R.

unread,
Nov 10, 2023, 9:08:26 AM11/10/23
to
I didn't lose. You did. There are people reading that they know, they
just left the discussion earlier.

Bye. EOD.

--
Cheers,
Carlos E.R.

Java Jive

unread,
Nov 10, 2023, 9:40:07 AM11/10/23
to
On 10/11/2023 13:51, Frank Slootweg wrote:
>
> Java Jive <ja...@evij.com.invalid> wrote:
>>
>> On 09/11/2023 19:04, Frank Slootweg wrote:
>>>
>>> Java Jive <ja...@evij.com.invalid> wrote:
>>>>
>>>> So, for example, the encryption has its own routines to display a
>>>> message on the screen of the device? No, of course not, OS routines do it.
>>>
>>> Sigh! If you're implying that Google is intercepting user data which
>>> is written to the screen (or coming from the keyboard), then that's a
>>> backdoor, which 1) we've said would get them in big, big trouble and 2)
>>> I had specifically excluded.
>>
>> Sigh! You're trying to play with words again - most people would
>> think of a backdoor as means of seeing into the encryption system
>> itself. Are you really trying to claim that a screen-reader for a blind
>> person is a back-door?
>
> Nice try, but no cigar.
>
> Nope, it's anything *but* playing with words. The example you describe
> is *Google* deceitfully intercepting the user's (screen/keyboard) data
> without their knowledge or approval. *That* *is* a backdoor.

This seems to support both of us ...

https://en.wikipedia.org/wiki/Backdoor_(computing)

... for while the description in the first paragraph supports your
meaning, all the subsequent examples support mine, so we'll just have to
agree to differ on that.

> The screen-reader for a blind person example is intentional behaviour
> with the user's approval.
>
> Two totally different and incomparable situations.

My point was and is that the software needed for such an attack is
likely already there on the device as part of the OS, no-one has to
install it, only to use it, and as such is not what in my experience is
commonly thought of as a backdoor.

>>> BTW, I assume you don't actually own or use any Android devices,
>>> Google services, etc..
>>
>> On the contrary I do, I just accept that it's relatively insecure -
>> apart from anything else, it might be lost or stolen - and thus don't
>> use it for purposes where security is important.
>
> A case of sarchasm.

A case of of misspelling of allegedly the lowest form of wit.

>> So you keep saying, but then keep replying, so rightly no-one takes any
>> notice of your attempt to make it look as though you've won an argument
>> when you haven't.
>
> Sigh! I keep replying because you keep coming up with more and even
> more weird stuff and I don't want to give anyone the impression that you
> might actually have a valid argument.
>
> And no, I haven't 'won' an argument, because there *is* no argument,
> just your opinion(s).
>
> But if you like this better:
>
> AFAIC, EOD.

Yet you replied again.

Java Jive

unread,
Nov 10, 2023, 9:44:27 AM11/10/23
to
To clarify, like it or not, your statement that "no big company with a
modicum of sense would do that. Just collecting data, massively, to
analyze and target publicity?" has been proven to be false; it's exactly
how Google makes 80% of its revenue.

Java Jive

unread,
Nov 10, 2023, 9:45:29 AM11/10/23
to
To clarify, like it or not, your statement that "no big company with a
modicum of sense would do that. Just collecting data, massively, to
analyze and target publicity?" has been proven to be false; it's exactly
how Google makes 80% of its revenue.

Frank Slootweg

unread,
Nov 10, 2023, 1:55:34 PM11/10/23
to
Java Jive <ja...@evij.com.invalid> wrote:
> On 10/11/2023 13:51, Frank Slootweg wrote:
[...]

> My point was and is that the software needed for such an attack is
> likely already there on the device as part of the OS, no-one has to
> install it, only to use it, and as such is not what in my experience is
> commonly thought of as a backdoor.

That's exactly what a backdoor is, something which is already there.

From your Wikipedia reference: "A backdoor may take the form of a
hidden part of a program". In this case, the alledged "program" is some
part of the OS.

The disagreement is that you say the backdoor is "likely", while
Carlos and I say it's bloody unlikely, because of the exterme
repercussions it would have for Google.

> >>> BTW, I assume you don't actually own or use any Android devices,
> >>> Google services, etc..
> >>
> >> On the contrary I do, I just accept that it's relatively insecure -
> >> apart from anything else, it might be lost or stolen - and thus don't
> >> use it for purposes where security is important.
> >
> > A case of sarchasm.
>
> A case of of misspelling of allegedly the lowest form of wit.

It's not a misspelling. Look it up. (Hint: 'define: <term>' in Google.
Might as well give them a few dollars worth of your data.)

As to "the lowest form": Can't do the time, ...

> >> So you keep saying, but then keep replying, so rightly no-one takes any
> >> notice of your attempt to make it look as though you've won an argument
> >> when you haven't.
> >
> > Sigh! I keep replying because you keep coming up with more and even
> > more weird stuff and I don't want to give anyone the impression that you
> > might actually have a valid argument.
> >
> > And no, I haven't 'won' an argument, because there *is* no argument,
> > just your opinion(s).
> >
> > But if you like this better:
> >
> > AFAIC, EOD.
>
> Yet you replied again.

Exactly *which* part(s) of "because..." and "AFAIC" didn't you
understand!?

Frank Slootweg

unread,
Nov 10, 2023, 1:55:35 PM11/10/23
to
Java Jive <ja...@evij.com.invalid> wrote:
> On 10/11/2023 14:08, Carlos E. R. wrote:
> >
> > On 2023-11-10 01:06, Java Jive wrote:
> >>
> >> LOL!  I'll just write you off as naive, and a bad loser.
> >
> > I didn't lose. You did. There are people reading that they know, they
> > just left the discussion earlier.
> >
> > Bye. EOD.
>
> To clarify, like it or not, your statement that "no big company with a
> modicum of sense would do that. Just collecting data, massively, to
> analyze and target publicity?" has been proven to be false; it's exactly
> how Google makes 80% of its revenue.

You keep harping on that, but your 'argument' is invalid, because
Carlos' remark [1] was in the context of Google's RCS, i.e. E2EE. That
you 'conveniently' snipped [2] the context from your response [3],
doesn't change the context.

Carlos and I have repeatedly reconfirmed that the context was and is
E2EE.

*In the context of E2EE*, your babbling about Gmail "snooping" and
Google's revenues from ads, is totally irrelevant and just shows your
agenda.

Give it a rest! You're not fooling anybody, except yourself.

I hope you enjoy the egg and pie.

[1] Message-ID: <kqqrot...@mid.individual.net>

[2] Snipped part *directly* above Carlos' text:

<JL>
I assume that if Google gets their success with RCS that would mean more
data available for analysis by them, and more ads for us.
</JL>

See the "RCS" bit you pretend/wish wasn't there!?

[3] Message-ID: <uiaiff$esio$1...@dont-email.me>

Carlos E. R.

unread,
Nov 10, 2023, 2:10:50 PM11/10/23
to
Agree to all.

--
Cheers,
Carlos E.R.

Java Jive

unread,
Nov 10, 2023, 4:26:04 PM11/10/23
to
Your original quote in its *entirety* read ...

On 06/11/2023 00:53, Carlos E. R. wrote:
>
> No, no big company with a modicum of sense would do that. Just
> collecting data, massively, to analyze and target publicity? That
> would get known, many people need to be in the know to make use of
> that lot of data. Too risky. Thus, not likely.
>
> Now, a backdoor so that authorities can capture a few conversations
> with a warrant? Maybe. Or so that a spy agency captures data from a
> limited number of targets? Perhaps.
>
> By the way, this is normally done by placing a trojan at one of the
> targets.

... and thus contained no such reservation that you are *only*
discussing E2EE. I am happy to accept that you may have *meant* that
context, but it's not what you actually *said*, and I'm not the only one
here who isn't psychic, because both Jörg Lorenz and Ed Cryer seem to
have read your original quote the same way as I did. And, it seems,
despite everything that Frank Slootweg has posted since, so did he,
because his first reply to me when I first pointed out your error
contained zilch mention of E2EE either ...

On 06/11/2023 14:43, Frank Slootweg wrote:
>
> The - snipped - issue was:
>
> <JL>
> I assume that if Google gets their success with RCS that would mean
> more data available for analysis by them, and more ads for us.
> </JL>
>
> So yes, they do*data analysis* of your Gmail e-mail, but AFAICT
> both Jeff's and Carlos' point is *ads* and in over 15 years of having
> (a) Gmail account(s), I still have to get the very first ad in or
> triggered by Gmail!
>
> As I said before, if Google is scanning my emails and allegedly
> acting on that scanning, they are doing a very poor job, because after
> the fact, I still get*in-browser* (*not* in email/Gmail) ads for
> products which I already purchased and for which the order/receipt
>/invoice/etc. are in that same Gmail mailbox! Can you say "stupid"!?
> (Yes, people have explained why this is so, but that doesn't mean that
> the end result isn't still stupid.)

So both of you are moving the goalposts to explain away your (Carlos')
original error. I accept that instead of allowing myself to be
inveigled into following the moving goalposts I should have replied
along the lines above sooner, and for that, I apologise, but you have
yet to apologise for your error.

Carlos E. R.

unread,
Nov 10, 2023, 5:09:52 PM11/10/23
to
Wrong. You have omitted parts of the context:


+++---------------------------
> On 2023-11-05 16:57, Jeff Layman wrote:
>> On 05/11/2023 14:24, Theo wrote:
>>> Jeff Layman <Je...@invalid.invalid> wrote:
>>>> I do wonder about End-to-End Encryption when the encrypted message goes
>>>> through Google. They could simply be the man-in-the-middle who is able
>>>> to read the message because they set up the encryption. It might also
>>>> answer another question raised as to "what's in RCS for Google?". Well,
>>>> if they are able to read those encrypted messages it's another source of
>>>> data for them to sell that others can't read and make use of.
>>>>
>>>> Or does that sound too much like another conspiracy theory? 😉
>>>
>>> Yes. E2EE means that Google in the middle can't intercept. That's what
>>> E2EE means - if they can, it's not E2EE.

...

>>> Google are doing this big US ad campaign to 'convince' Apple to add RCS
>>> support to iOS - they know Apple won't, but it just gets Google publicity
>>> for RCS.
>>
>> I assume that if Google gets their success with RCS that would mean more data available for analysis by them, and more ads for us.
>
> No, no big company with a modicum of sense would do that. Just collecting data, massively, to analyze and target publicity? That would get known, many people need to be in the know to make use of that lot of data. Too risky. Thus, not likely.

...

---------------------------++-

The context I quoted in my post included E2EE and RCS, with RCS being in
the previous paragraph directly above mine.

And if it was not clear we were talking of those, we repeatedly insisted
we were talking of E2EE and RCS several times later (an acronym, E2EE,
that is new to me, I normally prefer long words, so it may not occur in
my writings about it. I say this in case you grep for E2EE only).

Every post is part of a thread, a conversation, and you have to look at
more posts than one for context. And in my post I left enough material
of the ongoing conversation, so that everybody could know what we were
talking about.

And what I wrote in that post doesn't make sense unless read in the
context of RCS and E2EE.

You are intentionally perverting what we said.


--
Cheers,
Carlos E.R.

Java Jive

unread,
Nov 10, 2023, 5:20:40 PM11/10/23
to
On 10/11/2023 18:55, Frank Slootweg wrote:
>
> Java Jive <ja...@evij.com.invalid> wrote:
>>
>> On 10/11/2023 13:51, Frank Slootweg wrote:
> [...]
>
>> My point was and is that the software needed for such an attack is
>> likely already there on the device as part of the OS, no-one has to
>> install it, only to use it, and as such is not what in my experience is
>> commonly thought of as a backdoor.
>
> That's exactly what a backdoor is, something which is already there.
>
> From your Wikipedia reference: "A backdoor may take the form of a
> hidden part of a program". In this case, the alledged "program" is some
> part of the OS.

Yes, but, as I pointed out, all the examples they gave tended to support
my stricter meaning of the phrase rather than yours, so we'll have to
agree to differ on mere nomenclature.

> The disagreement is that you say the backdoor is "likely", while
> Carlos and I say it's bloody unlikely, because of the exterme
> repercussions it would have for Google.

I have never used the word "likely" until this very sentence, only you
and Carlos have, but I did say ...

On 09/11/2023 10:17, Java Jive wrote:
>
> No-one has answered my basic point that, if Google run the OS, and
> Carlos can read the message, so can Google, and, given Google's track
> record, most probably they will

... which, having now done the research outlined in a recent reply that
Carlos apparently didn't bother to read, I would now accept is probably
overstated, because they do seem to have made some attempts to clean up
their act. Nevertheless, as that research indicated, their record for
snooping is not good, is still pretty much the worst known of all such
companies, and there is still plenty of legal wiggle-room for them to
regress, so I still think, even accepting his originally unstated
context of E2EE, that his faith is misplaced.

>>>>> BTW, I assume you don't actually own or use any Android devices,
>>>>> Google services, etc..
>>>>
>>>> On the contrary I do, I just accept that it's relatively insecure -
>>>> apart from anything else, it might be lost or stolen - and thus don't
>>>> use it for purposes where security is important.
>>>
>>> A case of sarchasm.
>>
>> A case of of misspelling of allegedly the lowest form of wit.
>
> It's not a misspelling. Look it up. (Hint: 'define: <term>' in Google.
> Might as well give them a few dollars worth of your data.)

So to be sure I just did exactly as ordered, and found, as of course I
have known for 65 or more years, there is no 'h' in 'sarcasm'. Only
when I clicked on "Search instead for define: sarchasm" did I find the
obscure coined word, which suggests that the term is of sufficient
obscurity that its use might have been better avoided, particularly as
any joke that has to be explained falls flat.

By the way, something else I didn't need to know, it's also the name of
a punk band, thus obscuring his intended meaning still further.

>> Yet you replied again.
>
> Exactly *which* part(s) of "because..." and "AFAIC" didn't you
> understand!?

The fact that you both keep saying 'EOD' but then keep replying.

Java Jive

unread,
Nov 10, 2023, 6:00:04 PM11/10/23
to
> ....
>
>>>> Google are doing this big US ad campaign to 'convince' Apple to add RCS
>>>> support to iOS - they know Apple won't, but it just gets Google
>>>> publicity
>>>> for RCS.
>>>
>>> I assume that if Google gets their success with RCS that would mean
>>> more data available for analysis by them, and more ads for us.
>>
>> No, no big company with a modicum of sense would do that. Just
>> collecting data, massively, to analyze and target publicity? That
>> would get known, many people need to be in the know to make use of
>> that lot of data. Too risky. Thus, not likely.
>
> ....
>
> ---------------------------++-
>
> The context I quoted in my post included E2EE and RCS, with RCS being in
> the previous paragraph directly above mine.
>
> And if it was not clear we were talking of those, we repeatedly insisted
> we were talking of E2EE and RCS several times later (an acronym, E2EE,
> that is new to me, I normally prefer long words, so it may not occur in
> my writings about it. I say this in case you grep for E2EE only).

I have apologised for allowing myself to follow the moving goalposts, I
note that you have not apologised for making the original misleading claim.

> Every post is part of a thread, a conversation, and you have to look at
> more posts than one for context. And in my post I left enough material
> of the ongoing conversation, so that everybody could know what we were
> talking about.
>
> And what I wrote in that post doesn't make sense unless read in the
> context of RCS and E2EE.
Which is the problem, you stated *explicitly* an absolutist but false
claim in "no big company with a modicum of sense would do that. Just
collecting data, massively, to analyze and target publicity?" but did
not state equally *explicitly* the context that you wished to apply to it.

> You are intentionally perverting what we said.

No, I'm going by how I - and seemingly most or all others that have
replied in this subthread, even initially Frank Slootweg judging by his
first reply to me - initially read your original claim.

Carlos E. R.

unread,
Nov 10, 2023, 6:20:07 PM11/10/23
to
WRONG. You have to apologize to me for manipulation of quotes and
perverting what I said.


--
Cheers,
Carlos E.R.

Java Jive

unread,
Nov 11, 2023, 7:55:50 AM11/11/23
to
Bollocks to that, I merely quoted facts in reply to the false claim that
you yourself wrote.

And unlike you hypocrites, when I say EOD, I mean it.

Subthread ignored.
It is loading more messages.
0 new messages