What common specific Linux apps are known to access the clipboard upon mere invocation & without your permission?

Arlen Holder

unread,

Mar 17, 2020, 10:59:26 PM3/17/20

to

What common specific Linux apps are known to access the clipboard upon mere
invocation & without your permission?

On the Apple newsgroups, it was posted this week by Ant that many iOS apps
habitually access the private information on the iOS clipboard, sans any
user request whatsoever, to which the Apple users repeatedly and endlessly
claimed that Linux apps do this exact thing all the time.
o Famous iOS apps are snooping on the Pasteboard - Learn Worthy, by Ant
<https://groups.google.com/forum/#!topic/misc.phone.mobile.iphone/XXaeEvEB79Y>

What apps do you know of on Linux that access the clipboard every time you
invoke those apps without you wanting those apps to have that private data?
--
Usenet is so much more valuable, and pleasant, when adults share ideas.

David W. Hodgins

unread,

Mar 18, 2020, 12:21:02 AM3/18/20

to

On Tue, 17 Mar 2020 22:59:25 -0400, Arlen Holder <arlen.geo...@is.invalid> wrote:

> What apps do you know of on Linux that access the clipboard every time you
> invoke those apps without you wanting those apps to have that private data?

None of the distribution supplied applications, and as all of them have the source
code available, it's easy to verify, with the exception a few things like video card
drivers.

There may be applications from other sources that do, but like the few distribution
supplied binary only files they can be checked using tools such as strace.

I have no need of applications from any source other then the distribution
I use. In my case that's Mageia 7 currently.

Regards, Dave Hodgins

--
Change dwho...@nomail.afraid.org to davidw...@teksavvy.com for
email replies.

unread,

Mar 18, 2020, 4:31:50 AM3/18/20

to

Any application has read/write access to the primary, secondary, and clipboard data.

Anytime you are going to log into a site with a browser, it is highly
recommend to close browser, then launch it again.

Personally, I have separate Linux user accounts for bank, surfing,
creditcard, email,....

That way any single account crack can not expose the other accounts.

All the web browser accounts check to see if a web browser is running and abort
with a message to close it.

All those accounts use xclip to clear the primary, secondary, and clipboard
buffers upon exit.

Your other options are to use a virtual OS manager like VirtualBox for
each site or a multi-boot setup, one boot for each.

Carlos E.R.

unread,

Mar 18, 2020, 8:04:07 AM3/18/20

to

On 18/03/2020 05.59, David W. Hodgins wrote:
> On Wed, 18 Mar 2020 00:39:19 -0400, Arlen Holder
> <arlen.geo...@is.invalid> wrote:
>
>> The fact everyone _can_ rob a bank is meaningless in terms of what
>> this question asks, given the facts in the original thread show an
>> exact list of iOS apps that are _currently_ (today!) reading the
>> clipboard EVERY time they're invoked - even though the user has
>> never explicitly told them to. The question here is whether there
>> is a known list of specific apps.
>
> If you're really concerned, switch to https://www.qubes-os.org/ which
> sets up virtual machines, giving even more control over what various
> applications can access.

Virtual machines can also access, depending on setup, the clipboard of
the host, and the other way round.

The concept of clipboard, both in Linux and Windows, do not include
making the clipboard available to only a chosen application. I can see
applications noticing that there is something in the clipboard and
listing it in case the user wants to paste it.

Possibly a clipboard manager can limit who can read it, but till now I
was not aware of a problem.

Now I see why keepass deletes the clipboard after some seconds.

At least in Linux an application doing something nefarious with the
clipboard contents would be noticed.

And no, I'm not aware of a list.

--
Cheers, Carlos.

fr31...@gmail.com

unread,

Mar 18, 2020, 9:10:44 AM3/18/20

to

On Tuesday, March 17, 2020 at 10:59:26 PM UTC-4, Arlen Holder wrote:

>
> What apps do you know of on Linux that access the clipboard every time you
> invoke those apps without you wanting those apps to have that private data?
>

The pre-established, standard types of "clipboards," or selections, in
X Window are not private. They can be accessed by any program. Thus your
concern is misplaced.

However, any program can establish arbitrary types of selections that can
indeed be "private" in the sense that their access would be restricted only
to other software that understood such types.

Arlen Holder

unread,

Mar 18, 2020, 12:41:15 PM3/18/20

to

On Wed, 18 Mar 2020 13:00:07 +0100, Carlos E.R. wrote:

> Now I see why keepass deletes the clipboard after some seconds.
>
> At least in Linux an application doing something nefarious with the
> clipboard contents would be noticed.
>
> And no, I'm not aware of a list.

Hi Carlos,

I think, in addition to "keepass", that "veracrypt" might also clear the
clipboard (but I'm not wholly sure) but I do recall, offhand, that
"veracrypt" has an option to clear or cache the passphrase in RAM, under
your control, based on, I think, a given time, as I recall.

Something similar to ensure clipboards are emptied might be useful perhaps?

Like you were, I too was not at all aware this was happening without the
users' knowledge or consent until I too had read the thread posted by Ant
that provided a cite which listed scores of tested iOS apps that had no
business doing what they were doing (in my opinion and clearly in the
opinion of the cited expose's authors).

o Famous iOS apps are snooping on the Pasteboard (March 14th, 2020)
<https://learnworthy.net/famous-ios-apps-are-snooping-on-the-pasteboard>

Clearly, _any_ Linux apps that read my private data without my knowledge or
permission would be on my list of apps to potentially avoid.

We just need to figure out what that specific list of apps is.
--
Usenet helps all of us improve our technical skills by sharing with others.

Arlen Holder

unread,

Mar 18, 2020, 12:52:48 PM3/18/20

to

On Wed, 18 Mar 2020 03:31:44 -0500, Bit Twister wrote:

> All those accounts use xclip to clear the primary, secondary, and clipboard
> buffers upon exit.

Thank you for this useful advice to prevent nefarious apps from being able
to find anything when they do read the clipboard without users' permission.

> Any application has read/write access to the primary, secondary, and clipboard data.

We all knew that _before_ the thread was opened, just like all of us can
potentially hit little old ladies with a baseball bat whenever we see them.

:)

The facts are that the cited article exposed something I was wholly unaware
of prior, which is that scores of well-known (admittedly iOS only) apps
were actually _caught_ effectively clubbing old ladies ... just because
they can.

Clearly the authors of that cite claim (and I agree a priori) that none of
those apps had any business doing what they were doing, just because they
can.

It's the difference between smacking old ladies because you can, and not
hitting those little old ladies simply because it's the wrong thing to do.

*The question is which Linux apps are _known_ to be reading clipboards*
*clearly _without_ users' knowledge or consent, simply upon invocation.*

--
Usenet allows purposefully helpful adults to share solutions with others.

Arlen Holder

unread,

Mar 18, 2020, 1:02:21 PM3/18/20

to

On Wed, 18 Mar 2020 06:10:40 -0700 (PDT), fr31...@gmail.com wrote:

> The pre-established, standard types of "clipboards," or selections, in
> X Window are not private. They can be accessed by any program. Thus your
> concern is misplaced.

Hi fr314159,

I don't think there's a single person on this Linux ng who didn't know that
programs "can" read the clipboard, even _before_ this thread was authored.

This thread is asking for a named list of badly behaved Linux programs.
o These would clearly be Linux programs to avoid.

To your point, just because we _can_ rummage through people's garbage to
obtain their bank statements, doesn't mean that reputable people actually
_do_ that without any need to have done so (and without users' consent).

The cite clearly states the opinion that the scores of listed (admittedly
only iOS) apps that have been _caught_ rummaging through your garbage for
personal information is the wrong thing for those iOS apps to do.

I concur, and I claim that those apps would likely be apps to be avoided.

Similarly, the goal here is to list any known Linux programs that have no
business rummaging through your garbage, without your knowledge or consent,
who are known to be doing so, merely upon invocation of the Linux program.

What Linux programs are known to access the clipboard merely upon
invocation (which have no need to do so) that we know of?

fr31...@gmail.com

unread,

Mar 18, 2020, 3:51:08 PM3/18/20

to

On Wednesday, March 18, 2020 at 1:02:21 PM UTC-4, Arlen Holder wrote:

>
> What Linux programs are known to access the clipboard merely upon
> invocation (which have no need to do so) that we know of?
>

Selections in X (i.e. clipboards) are neither independent nor permanent
entities. They are essentially properties of a client window and will
vanish when the client program (or at least the window) exits.

So if by "garbage" you mean something that is left over from
previous activity then there is none.

But an invoked program can immediately, and repeatedly, ask for
the current owners of the standard, built-in selections, called PRIMARY
and CLIPBOARD, and then request a conversion for the contents. Such
activity would be easy to detect by monitoring the calls to the
appropriate X routines.

Carlos E.R.

unread,

Mar 18, 2020, 5:48:07 PM3/18/20

to

On 18/03/2020 17.52, Arlen Holder wrote:
> *The question is which Linux apps are _known_ to be reading clipboards*

> *clearly_without_ users' knowledge or consent, simply upon invocation.*

Again, all applications can do that and none has to tell you or ask
permission. It is a feature of the desktop paradigm.

--
Cheers, Carlos.

Carlos E.R.

unread,

Mar 18, 2020, 5:48:07 PM3/18/20

to

On 18/03/2020 17.41, Arlen Holder wrote:
> On Wed, 18 Mar 2020 13:00:07 +0100, Carlos E.R. wrote:
>
>> Now I see why keepass deletes the clipboard after some seconds.
>>
>> At least in Linux an application doing something nefarious with the
>> clipboard contents would be noticed.
>>
>> And no, I'm not aware of a list.
>
> Hi Carlos,
>
> I think, in addition to "keepass", that "veracrypt" might also clear the
> clipboard (but I'm not wholly sure) but I do recall, offhand, that
> "veracrypt" has an option to clear or cache the passphrase in RAM, under
> your control, based on, I think, a given time, as I recall.
>
> Something similar to ensure clipboards are emptied might be useful perhaps?
>
> Like you were, I too was not at all aware this was happening without the
> users' knowledge or consent until I too had read the thread posted by Ant
> that provided a cite which listed scores of tested iOS apps that had no
> business doing what they were doing (in my opinion and clearly in the
> opinion of the cited expose's authors).
>
> o Famous iOS apps are snooping on the Pasteboard (March 14th, 2020)
> <https://learnworthy.net/famous-ios-apps-are-snooping-on-the-pasteboard>
>
> Clearly, _any_ Linux apps that read my private data without my knowledge or
> permission would be on my list of apps to potentially avoid.

ALL Linux desktop tools can potentially read the clipboard and none will
tell you they do, as this is a desktop feature and nobody has considered
this might be dangerous.

>
> We just need to figure out what that specific list of apps is.
>

ALL.

The only thing you should consider in Linux is if there is any
application that does read the clipboard with nefarious purpose. I doubt
that any distribution distributes any such application knowingly - they
are all opensource and can be easily inspected.

Of course, the administrator of a machine can create his own snooping
application on you.

--
Cheers, Carlos.

DecadentLinux...@decadence.org

unread,

Mar 18, 2020, 7:09:55 PM3/18/20

to

"Carlos E.R." <robin_...@es.invalid> wrote in
news:fhhakg-...@Telcontar.valinor:

It is clear that Mr. Holder needs to hold a session with himself
in which he reads a book on Linux... slowly... carefully.

Buffer, buffer, who's got the buffer?

Or...

Clipboard, clipboard,
Second generation,
No easy way to be free...
No easy way to be free...
It's a hard, hard world...

R.Wieser

unread,

Mar 19, 2020, 3:43:36 AM3/19/20

to

Carlos,

>> *The question is which Linux apps are _known_ to be reading clipboards*
>> *clearly_without_ users' knowledge or consent, simply upon invocation.*
>
> Again, all applications can do that and none has to tell you or ask
> permission. It is a feature of the desktop paradigm.

You are not telling him what he wants to hear (and thats the only thing he
will listen to). Be prepeared to be classified as "worthless" and "never
helpfull" or worse.

And you might have noticed that he doesn't seem to want to put any work in
it himself, but expects you and others to do all the work and than present
the results on a silver platter. Which is an MO that permeates thru most
all of his requests.

FYI, he's posted the same question in Win10 and XP too. With pretty-much
the same answers and results.

On a positive note, he seem to have learned to keep Windows and Linux apart,
and not expect answers that "just work" on both. Maybe there is still hope
for him. :-)

Regards,
Rudy Wieser

Dan Purgert

unread,

Mar 19, 2020, 6:15:20 AM3/19/20

to

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

R.Wieser wrote:
> Carlos,
>
>>> *The question is which Linux apps are _known_ to be reading clipboards*
>>> *clearly_without_ users' knowledge or consent, simply upon invocation.*
>>
>> Again, all applications can do that and none has to tell you or ask
>> permission. It is a feature of the desktop paradigm.
>
> You are not telling him what he wants to hear (and thats the only
> thing he will listen to). Be prepeared to be classified as
> "worthless" and "never helpfull" or worse.

Carlos is already part of our merry band of misfits :)

>
> And you might have noticed that he doesn't seem to want to put any
> work in it himself, but expects you and others to do all the work and
> than present the results on a silver platter. Which is an MO that
> permeates thru most all of his requests.

Quite so. Don't forget that he then tries to take all the credit for
it.
>
> [...] Maybe there is still hope for him. :-)

That'll change soon enough.

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl5zRjUACgkQjhHd8xJ5
ooExyAgAqNzaxoUoozb3+lpD6zhW1AAyuMntwWpoysU9Pwvpx+f1SDdJ4QbXOULW
kveMW+8rDwPtQnaRZuXpMqQleqpC04l2k0k+rXk2v6U9T0AhcLTcGxsw+cViPu2M
pxGcuSEe3ccRq3+rosHV8hN5xMvZUi5jMbG6LPK40rC4zR7DZW4Jm/eZC8vLxuk5
sjsDZIYnffnZLmnemkmee+Z4+4YJ4gAhJegyiJXKH93SpBHJL1bDB9aIlyDqLv50
zRt9XyaOwZEbabkGQ3Yu8Q2J7ld3EK0rGxWKejxTxI+umsPo38mbdFZojpJSL/8l
2ptAq2cQL9DiQH88YBrhIdge5+cUIA==
=HjUV
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281

Carlos E.R.

unread,

Mar 19, 2020, 6:44:07 AM3/19/20

to

On 19/03/2020 11.15, Dan Purgert wrote:
> R.Wieser wrote:
>> Carlos,
>
>>>> *The question is which Linux apps are _known_ to be reading clipboards*
>>>> *clearly_without_ users' knowledge or consent, simply upon invocation.*
>>>
>>> Again, all applications can do that and none has to tell you or ask
>>> permission. It is a feature of the desktop paradigm.
>
>> You are not telling him what he wants to hear (and thats the only
>> thing he will listen to). Be prepeared to be classified as
>> "worthless" and "never helpfull" or worse.
>
> Carlos is already part of our merry band of misfits :)

:-))

>
>
>> And you might have noticed that he doesn't seem to want to put any
>> work in it himself, but expects you and others to do all the work and
>> than present the results on a silver platter. Which is an MO that
>> permeates thru most all of his requests.

I saw the post on W10 group, yes.

>
> Quite so. Don't forget that he then tries to take all the credit for
> it.
>
>> [...] Maybe there is still hope for him. :-)
>
> That'll change soon enough.

{chuckle}

--
Cheers, Carlos.

R.Wieser

unread,

Mar 19, 2020, 7:55:09 AM3/19/20

to

Dan,

> Carlos is already part of our merry band of misfits :)

I seemed to have that notion too, but I was not sure looking at the
reasonable tone of his reply. Than again, I tried to do the same in my own
reply to this subject (in XP) ...

> Quite so. Don't forget that he then tries to take all the
> credit for it.

:-) I didn't want to make it a full-blown rant, just a warning for the
unweary.

For the few of those results he posted here I noticed that his "tutorials"
where 1) everything but that 2) sometimes downright dangerous to ones
computer health, so I'm not so sure I would want to be named as a
contributor ...

You know, the critique he got here for those "tutorials" (with us being able
to look back to what was actually said and contributed) might well be why he
chose /not/ to post them here anymore.

>> [...] Maybe there is still hope for him. :-)
>
> That'll change soon enough.

Possibly. But lets try to keep the positive possibilities in sight.
Besides, what (I think) he learned directly benefits himself, and thats
always a good motivator.

Regards,
Rudy Wieser

DecadentLinux...@decadence.org

unread,

Mar 19, 2020, 8:05:18 AM3/19/20

to

"R.Wieser" <add...@not.available> wrote in
news:r4vmir$ofp$1...@gioia.aioe.org:

> Possibly. But lets try to keep the positive possibilities in
> sight. Besides, what (I think) he learned directly benefits
> himself, and thats always a good motivator.
>
> Regards,
> Rudy Wieser

Cary Grant voice inflection...

(shakes head...)
"Rudy, Rudy, Rudy..."

Most won't get that...

"I'm not a Brewster, I'm the son of a seacook!" --Mortimer Brewster

Or that.

Arlen Holder

unread,

Mar 19, 2020, 10:24:38 AM3/19/20

to

On Wed, 18 Mar 2020 22:45:25 +0100, Carlos E.R. wrote:

> ALL Linux desktop tools can potentially read the clipboard and none will
> tell you they do, as this is a desktop feature and nobody has considered
> this might be dangerous.

Hi Carlos,

We're trying to get something adult done here; not play your silly games.
o Por que constantemente demuestras ser dueno del cerebro de un nino, Carlos?

Specifically we're trying to get a list of Linux programs here (like that
which were reported for iOS) which have been caught reading the clipboard
without users' explicit consent, and all you can do is claim that you're
repeatedly shocked that programs "can" read the clipboard, Carlos?

Seriously?
o Please stop posting if all you wish to do is waste our time, Carlos.

Just stop it.

Did you even _read_ a single other post to this thread?
o No?

Are you actually that immune to the obvious, Carlos?
o You didn't read even _one_ post other than yours to this thread?

Why not?
o Why do you _consistently_ prove to ignore the facts in this thread?

Stop it.
o Everyone _knows_ that we all have the capacity to steal our computers
from the electronics store. Everyone.

They knew this _before_ you were born, Carlos.
o And they still know it now.

So stop repeating that people "can" steal computers from the stores.
o Just stop it.

Just because we can steal computers every day, doesn't mean we do.
o Any program that does, is a program to be listed to be avoided.

Period.

This is a problem that needs to be addressed as an adult.
o We'll get nowhere, as adults, by playing your childish games, Carlos.

You already know from the Android newsgroups you're on that
*Android has limitations on reading the clipboard*, Carlos:
"Unless your app is the default input method editor (IME)
or is the app that currently has focus, your app cannot
access clipboard data on Android 10 or higher."
<https://developer.android.com/about/versions/10/privacy/changes#clipboard-data>

Google is at least doing "something" to prevent bad actors from reading the
clipboard without the knowledge or consent or expectation of the user.

And, for iOS, researchers tested apps to find which were bad players.

All we ask here is whether we know of any named Linux programs that are
also bad actors like those.

What's so hard about that topic that you fail to understand, Carlos?
o Or do you just wish to incessantly play your silly Dan Purgert games?

Grow up, Carlos.
o Stop playing your silly Cybe(r) Wizard, Lucifer, et al. worthless games.

Please just stop telling us what everyone but you seems to have known since
they were weaned off their mothers' milk.

Just stop it.
o It _subtracts_ value for you to repeat what everyone always knew.

That's _not_ the topic Carlos.
o If you want that to be the topic, go start a thread on _that_ topic.

You just _waste_ our time telling us stuff that you're didn't know but
everyone else clearly knew the moment they started using computers.

Please stop posting to this thread if all you wish to do is waste our time.
o Por que constantemente demuestras ser dueno del cerebro de un nino, Carlos?
--
To spare the adults on this ng further indignity, this is my _last_
response to Carlos until and unless he learns how to read the subject
line of the thread and stops telling us what he doesn't know but that we
knew likely since before he was born.

Arlen Holder

unread,

Mar 19, 2020, 10:50:45 AM3/19/20

to

Oh my God.

I'm frustrated by the responses because I _care_ about getting an answer.
o An _adult_ answer.

An answer which, if Paul doesn't know, probably _nobody_ here knows.
o Least of all me.

And yet, for a thread that should have only one or maybe two responses, the
permanent Usenet record will amply show the worthless pieces of shit came
out in droves to infest this thread with their always childish silly games.

Hence, this thread will _never_ be able to arrive at the _adult_ answer
asked. The worthless pieces of shit won't allow that.

They _hate_ that they, themselves, utterly lack any added value.
o So they incessantly shit on the threads that attempt to add value.

All these proven worthless pieces of shit "can" do, is play their games:
o *Carlos* E.R. (he's shocked that programs "can" read the clipboard!)
o *DecadentLinuxUserNumeroUno* (incessantly played his silly games)
o *Rudy Wieser* (has never in his entire life _not_ subtracted value)
o *Dan Purgert* (has never authored a thread of value in the history of Usenet)
et al. (since more worthless pieces of shit will surely follow).

Just because these proven worthless people 'can' shit on a thread...
o Doesn't mean they should.

And yet, they do.

The specific worthless pieces of shit listed above _love_ this thread
because they lack any possible input of value, and nobody else who actually
_can_ add value knows the answer to the question (as that would take a lot
of knowledge).

Hence, what happened is this thread drew out the worthless pieces of shit.
o I'm done playing their silly always-childish games.

Not a single one of the listed worthless pieces of shit has _ever_ in the
entire history of Usenet, ever authored a thread of value to this ng.

Not even one.

For the permanent Usenet record... and yet, these worthless pieces of shit
have completely infested this thread to the point that it's impossible to
get an _adult_ answer to the question - even as that adult answer is
important.

None of these worthless pieces of shit comprehend this simple statement:
o Just because a program "can" read the clipboard doesn't mean it should.

All anyone has said (and the worthless pieces of shit above repeat ad
infinitum) is what Paul said in the very first response when he didn't
comprehend the question, which is what _everyone_ has known since the early
days of computers (and which isn't even the topic of this thread).

The topic of this thread is the bad players to be listed.
o It's OK for nobody to know the answer to this _adult_ question.

But why do these worthless pieces of shit incessantly have to prove not
only that they have absolutely zero clue about the answer to this adult
question, but that they insist on posting what amounts to worthless
repetition of what Paul clearly stated in the first response?

Clearly a list of programs that have no business reading the clipboard
without the users' consent or expectation, 'can' read the clipboard; but
prudence dictates that many programs will simply because they don't need
that information to function.

And yet, the facts show "some" programs do it anyway:
o Notice the given iOS cite contains an actual list of the bad players.

And yet, the fact show "some" operating systems limit it in some way:
o Notice on Android, Google implemented clipboard-privacy restrictions.

All this thread asked was the _adult_ question that, apparently, only the
worthless pieces of shit are posting their silly games to, which I refuse
to play along with them any further.

We will not be able to get the _adult_ answer until the worthless pieces of
shit find some other thread for them to infest for their silly childish
games.
--
Only 2 kinds of people are on Usenet: Those adding value & those who can't.
Those who have never added any value can't comprehend those that try to.

David W. Hodgins

unread,

Mar 19, 2020, 11:32:39 AM3/19/20

to

On Thu, 19 Mar 2020 10:50:44 -0400, Arlen Holder <arlen.geo...@is.invalid> wrote:

> Oh my God.
>
> I'm frustrated by the responses because I _care_ about getting an answer.
> o An _adult_ answer.
>
> An answer which, if Paul doesn't know, probably _nobody_ here knows.
> o Least of all me.

You've been given the answer, but just don't like it. There are none, and
if there were they would be easy to detect as the source code is available.

Android and IOS are not Linux. Linux is not controlled by a profit driven
corporation, so it doesn't suffer from the need to exploit it's users.

Dan Purgert

unread,

Mar 19, 2020, 1:01:55 PM3/19/20

to

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

R.Wieser wrote:

> Dan,
>
>> Carlos is already part of our merry band of misfits :)
>
> I seemed to have that notion too, but I was not sure looking at the
> reasonable tone of his reply. Than again, I tried to do the same in
> my own reply to this subject (in XP) ...

Yeah, Carlos is better than many in keeping an even keel (especially me)

>
>> Quite so. Don't forget that he then tries to take all the
>> credit for it.
>
>:-) I didn't want to make it a full-blown rant, just a warning for the
> unweary.
>
> For the few of those results he posted here I noticed that his
> "tutorials" where 1) everything but that 2) sometimes downright
> dangerous to ones computer health, so I'm not so sure I would want to
> be named as a contributor ...

Indeed.

>
> You know, the critique he got here for those "tutorials" (with us
> being able to look back to what was actually said and contributed)
> might well be why he chose /not/ to post them here anymore.

Well, that and Cybe R. Wizard (IIRC) always asking him to prove that
he's actually written 10k of them.

>
>>> [...] Maybe there is still hope for him. :-)
>>
>> That'll change soon enough.
>
> Possibly. But lets try to keep the positive possibilities in sight.

People will learn how killfiles work, out of necessity of the current
"you're trapped here" situation caused by the pandemic? :)

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl5zpX8ACgkQjhHd8xJ5
ooFNhwgAjpSvtF0MhzESIrEh5KbwlpMCxjH3GrCjytAyDVPoasDp4G62urPJQeRY
V1OipHmLqoSVJx8wNdrwiBZcyHnFSH8cuH6lmuAZIrIK090TGHXiS2TgCMR62/Kh
w4s8tR9fqxC2U+q7yywJYwqwGQjEtVrQcG78TzWfw/tA5M7MfZWIv+xjb+bEg51V
wnj/1YbG79SbtusBSLtRkzEt+VJZbWS8BdQOnI3ZG9iFcMIUrf5d/EVqDEKTGCnx
mHATcamL7t1x+AwOaZW0us8oqXWxxXWxaIZev/QDosbVXac0oheyHvO1lRzdh+sw
rtXcF3JvDUEhoOaCWBrMB5xmSl+xyQ==
=5tvK

unread,

Mar 19, 2020, 2:13:37 PM3/19/20

to

Arlen Holder <arlen.geo...@is.invalid> wrote in news:r500s3$uvp
$1...@news.mixmin.net:

> I'm frustrated by the...

85 lines of total horseshit you just posted.

Go AWAY, little girl.

R.Wieser

unread,

Mar 19, 2020, 3:27:02 PM3/19/20

to

Dan,

> Well, that and Cybe R. Wizard (IIRC) always asking him to prove
> that he's actually written 10k of them.

I thought that his choice to dump his "potluck picknick" stews into google
groups was more driven by the longevity of whats posted there. You know,
the same longevity by which we sometimes enjoy google groupers posting
replies to a decade or more old messages.

As for those 10k tutorials ? That /is/ what he claimed ... And even when
we slash that claim by a factor of 10 and assume one tutorial every week of
the year (which is not even resonable if we consider the time needed for
research and, not to forget, testing) than he would still have needed 19
years for it. And pardon me, but he certainly doesn't sound as he has
already outgrown his teenage years. :-)

> People will learn how killfiles work, out of necessity of the current
> "you're trapped here" situation caused by the pandemic? :)

:-) He's been a resident in my "killfile" for quite some time now
(actually, just hidden, so that any-and-all replies to them also get
hidden). Though I regulary take a peek at those "killfiled" messages to
see if someone should get parole. And now I concluded that our esteemed OPs
question was sensible, though a bit misinformed/misguided. So, I took a bit
of a chance. But nope, he hasn't changed much. :-)

Regards,
Rudy Wieser

Carlos E.R.

unread,

Mar 19, 2020, 4:32:07 PM3/19/20

to

On 19/03/2020 15.24, Arlen Holder wrote:
> On Wed, 18 Mar 2020 22:45:25 +0100, Carlos E.R. wrote:
>
>> ALL Linux desktop tools can potentially read the clipboard and none will
>> tell you they do, as this is a desktop feature and nobody has considered
>> this might be dangerous.
>
> Hi Carlos,
>
> We're trying to get something adult done here; not play your silly games.
> o Por que constantemente demuestras ser dueno del cerebro de un nino, Carlos?

Now you are being stupid as usual, when you do not like the answer we
give you, and you go into a tantrum as a child.

Not reading any of your tantrum.

--
Cheers, Carlos.

Arlen Holder

unread,

Mar 19, 2020, 6:51:53 PM3/19/20

to

On Thu, 19 Mar 2020 18:13:34 +0000 (UTC),
DecadentLinux...@decadence.org wrote:

> 85 lines of total horseshit you just posted.

unread,

Mar 19, 2020, 7:31:59 PM3/19/20

to

Arlen Holder <arlen.geo...@is.invalid> wrote in news:r50tps$m9e
$1...@news.mixmin.net:

> I'm not afraid of facts.

Obviously you are because "the clipboard" has been a basic paradigm
in graphical operating system 'desktops' for DECADES!

YOU LOSE... AGAIN!

DecadentLinux...@decadence.org

unread,

Mar 19, 2020, 7:34:11 PM3/19/20

to

Arlen Holder <arlen.geo...@is.invalid> wrote in
news:r50tps$m9e$1...@news.mixmin.net:

> And yet, these worthless pieces of shit can't stand that they,
> themselves, are easily proven to be utterly incapable of authoring
> a thread of adult on-topic technical value, in their entire lives.
>

You were told by several respondents exactly what the clipboard
paradigm is about. You need to excise your mental block.

If you had a lobotomy, you should sue your doctor. If you haven't
had one, you should get one, becasue it will have to be an improvement
over what you spew currently.

Arlen Holder

unread,

Mar 19, 2020, 7:38:09 PM3/19/20

to

On Thu, 19 Mar 2020 21:30:28 +0100, Carlos E.R. wrote:

> Now you are being stupid as usual, when you do not like the answer we
> give you, and you go into a tantrum as a child.

Hi Carlos,

*What _answer_ did "we" give exactly*?

Hint: This is _not_ an answer even if it's "telling the truth":
Q: What cars are still made in the USA?
A: Cars cause accidents.

Now let me ask _you_ a question, Carlos.

Q: Why is it that on the iOS ng, we have a list of rogue apps,
and, even better, on the Android newsgroup, we found out that
Google recently implemented privacy procedures to prevent rogue apps
from accessing the clipboard - and yet - on this Linux newsgroup
- all we get is the answer to a question that was never asked?
--
It's OK if nobody has the knowledge of a given list of the rogue apps.

RonB

unread,

Mar 19, 2020, 7:40:00 PM3/19/20

to

When you graduate from 7th grade I'll consider removing you from my
killfile. Until then... Adios.

--
The fabulous Latitude D430, running
Linux Mint Mate 19.3 on 2GBs of RAM

Not on iOS do they expect it.
o On iOS, it's considered a bug by all companies caught to date.

Why is it a bug on iOS but not a bug on Linux?

> Because that is simply the purpose of the clipboard, to
> provide data to be shared among apps.

I don't think you understand the problem set if that's what you think.

Remember, Linked-In said it was a bug that they will immediately fix.

Remember, Reddit said it was a bug that they will immediately fix.

Remember, TikTok said it was a bug which they will immediately fix.

Why is it a bug on iOS but the same behavior is not a bug on Linux?

> They certainly do not expect apps to access the clipboard and then send that
> data around, without the users consent or even the user knowing about it

BTW, nobody really thinks they're telling the truth (reddit, tiktok,
LinkedIn, et al.); they just got caught so they have to claim it's a bug.

I admit, openly, I can't yet understand the point of view of Linux users.
o Why is this creepy behavior on iOS _clearly_ a bug by all accounts...

*... but on Linux, the _same_ creepy behavior is not a bug?*

Makes no sense.
--
Usenet is most useful when adult post with purposefully helpful intent.

Arlen Holder

unread,

Jul 5, 2020, 7:02:55 PM7/5/20

to

On Sun, 05 Jul 2020 18:21:38 -0400, nospam wrote:

>> So I'm not sure _why_ the Android, Linux, and Windows groups seem to think
>> this is normal behavior to read the clipboard upon every keystroke (or
>> invocation of the app).
>

> ignorance.
>
> how do you think a clipboard manager app works, which runs in the
> background?
>
> a clipboard manager probably isn't doing anything sleazy (at least the
> reputable ones) with what's on the clipboard, but that doesn't mean a
> different app couldn't do something nefarious.

Hi nospam,

It could be ignorance on the part of the Android, Windows, & Linux users,
as when I first broached the subject, en masse, the trolls came out, and
even some of the regulars seemed to think it's perfectly normal for an app
that has absolutely zero need for the clipboard, to be reading it.

I can see how it's a tad more dangerous, perhaps, on iOS simply because of
the integration with the Mac clipboard (but such integration may be on
Windows, Linux, and Android for all I know).

What I do know is that when an app is called out for this behavior on iOS,
they turn it off and apologize, claiming it's a bug (as you're well aware).

Seems to me Android, Windows, and Linux need the _same_ kind of enhanced
privacy that this new iOS 14 popup message provides.... but, as we both
noted, the Android, Linux, and Windows users appear to be either ignorant,
or, perhaps, they know something we don't know.

I just don't get it why _all_ five platforms shouldn't have this creepy
behavior pointed out, if it's occurring on all five platforms.

Arlen Holder

unread,

Jul 5, 2020, 7:12:48 PM7/5/20

to

On 05 Jul 2020 22:25:37 GMT, Stéphane CARPENTIER wrote:

> The purpose of a clipboard is to exchange information between
> applications. So by design it's normal they are able to access it.

Hi Stephane,

Thanks for trying to answer the question, because I'm genuinely confused
why it's a bug on iOS by all accounts (nobody on the planet has yet to
claim it's _not_ a bug, even the companies caught doing it, even as nobody
is fooled that they wrote the code on purpose)... but ... on Linux... it's
not a bug.

Why is it not a bug on Linux when it's clearly (by all accounts) a bug when
it happens on iOS?

Nobody (not even the companies caught doing it!) can defend this behavior
when it happens on iOS.

What's different about Linux?

> That
> being said, if an application is using its privilege to send the
> information on Internet it's not a but of the OS but a real issue with
> the application.

The problem is that the user puts "sensitive data" (e.g., account numbers,
passwords, people's names, whatever) in their clipboard, and, while we can
blame the users, EVERY company caught doing this, so far, on iOS, has
admitted guilt (they claimed it was a bug but the code was written on
purpose), and has vowed to remove the app's creepy behavior.

> If you are really concerned with this behavior, you can use qubes OS. By
> design it wont let that happens without your agreement.

I should be clear that I'm not at all concerned about the behavior, nor am
I confused about what it is.

What worries me is that if it's clearly aberrant behavior on iOS (by every
account where I stress nobody on this planet is claiming it's not aberrant
behavior when it happens on iOS) ... isn't aberrant behavior on Linux.

That's what concerns me.

Why is it clearly (and always!) aberrant behavior on iOS... but not Linux?
o ... makes no sense to me.

Arlen Holder

unread,

Jul 5, 2020, 7:29:52 PM7/5/20

to

> So I'm not at all really sure why only iOS makes the news for this kind of
> clearly creepy app behavior... and not, oh, say, Android, or, Windows.

Hi Ant,

It's not just the Windows & Android folks who think it's normal behavior.
o Even the Linux folks seem to think this is perfectly normal behavior.

Windows: <https://groups.google.com/forum/#!topic/microsoft.public.windowsxp.general/wDbAqMr-0oY>
Android: <https://groups.google.com/forum/#!topic/comp.mobile.android/hdNb3BeYm44>
Linux: <https://groups.google.com/forum/#!topic/alt.os.linux/VmByXYAaJts>

So what is confusing to me is why, on iOS, this reading of the clipboard
(by apps that have absolutely no business whatsoever reading the clipboard)
is _always_ considered aberrant behavior by all accounts we can find
(including the companies caught doing it!)...

But on Windows, Linux, and on Android, they think it's perfectly normal.
o Makes no sense.

I agree with nospam, for example, that when the companies who are caught
doing it "claim" it's a bug, they're just making excuses 'cuz you have to
explicitly code this stuff... it doesn't happen by accident.

But at least on iOS, when those companies are caught, they _all_ (so far)
agreed that it's the wrong thing to do, and they all said they'd remove it
(e.g., Reddit, Linked-In, & TikTok, although TikTok was caught long ago so
they are especially egregious offenders).
o Linked-In: <https://groups.google.com/forum/#!topic/misc.phone.mobile.iphone/2VZ5a3QsvBc>
o Reddit: <https://groups.google.com/forum/#!topic/misc.phone.mobile.iphone/-gvgKjTALvI>
o TikTok: <https://groups.google.com/forum/#!topic/misc.phone.mobile.iphone/dRKgQG8jGo8>
o Others: <https://groups.google.com/forum/#!topic/misc.phone.mobile.iphone/IHVirXnbJF0>

Why is it always a bug (by all accounts) when it happens on iOS, but not on
the other four common consumer OS platforms?

Arlen Holder

unread,

Jul 5, 2020, 7:39:40 PM7/5/20

to

On Sun, 5 Jul 2020 21:50:37 -0000 (UTC), Lewis wrote:

> This is a much more complicated issue than these abndwagon jumpers would
> indicate.
>
> For example, if I copy a link from a page to an RSS feed and then I open
> my podcast app, it will get that URL off the clipboard so that I can
> easily subscribe to the podcast.
>
> When I copy a phone number and then open Hiya, it offers immediately to
> search its database for that phone number.
>
> These are both desirable features.
>
> The issue is when an app (or more likely a framework plugin that the
> "developer" dropped in without even looking at the code) is constantly
> polling the clipboard to monitor everything the user is doing.
>
> When I launch the Safeway app there is no reason I can think of for it
> to be polling the clipboard, and yet it does. It's not doing anything
> for me with that clipboard like offering to search for "Fritos" if
> that's on my clipboard, it's just phoning home with whatever is on the
> clipboard.
>
> Or I have to assume it is phone home because it is grabbing the
> clipboard and I have no way to know it is not phoning that home.
>
> So, I put "Hey Siri remind me to stop going to Safeway because they are
> spying on my clipboard" and open the app a few dozen times.
>
> But since nothing like credit card numbers or passwords are ever on the
> clipboard (never) it's more of an annoyance than anything else.
>
> People who manage their passwords by keeping a notes document and
> copy/pasting their logins and passwords... well, they have a problem,
> but it is a self-inflicted problem.

Lewis has a good point that the "bug" can be accidental if the companies
caught doing it (e.g., Reddit, Linked-In, TikTok, et al.) simply blindly
linked in code that they never even understood...

Although that alone, should be a scary thought for reasons that are
obvious, but unrelated to this query...

My query is simply why it's _clearly_ always considered a bug when, on iOS,
apps that have absolutely zero need to be constantly reading your
clipboard, are constantly reading your clipboard...

... ... and yet ... ...

On all the other common consumer platforms that I asked the question of...
o It's _not_ considered a bug?

Makes no sense.

If it's clearly a bug on iOS for an app that has absolutely no business
reading the clipboard to be constantly monitoring everything you cut into
the clipboard... (which even the companies caught doing it admitted)...

Then why isn't it a bug on the other common consumer platforms?
--
If it's clearly a bug when an iOS app does it, how can it _not_ be a bug
when the Linux, Android, and/or Windows equivalent app does it?

Arlen Holder

unread,

Jul 5, 2020, 7:47:45 PM7/5/20

to

On Sun, 5 Jul 2020 16:38:20 -0700, 123456789 wrote:

>> some of the regulars seemed to think it's perfectly normal for an
>> app that has absolutely zero need for the clipboard, to be reading
>> it.
>

> I see there are a number of Android Clipboard Cleaner apps available. I
> just tried one and it seemed to work OK. So I suppose one could leave his
> clipboard squeaky clean after use if wanted. The question that came to
> my mind is what might the cleaner apps be doing with the dirty laundry...

I'm sure there are tons of workarounds to prevent Android apps that have
absolutely no business reading our clipboards to be constantly obtaining
data from our clipboards...

But what I don't get (yet) is why the Android users who posted (so far)
seem to think it's perfectly normal for an app that has absolutely no
business to be reading our clipboards, to be reading our clipboards.

Only if/when we agree it's aberrant behavior, can we begin to discuss the
workarounds, IMHO.

Although, some workarounds that come to mind, including the one above...
o Auto clear the clipboard every few seconds (or on demand, or on paste)
o Pop up a configurable warning when an app requests clipboard access
o Set a permission, per app, to access the clipboard (if that's possible)
etc.

What bothers me most so far in this thread is people think it's normal.

If it's clearly a bug when an iOS app does it, how can it _not_ be a bug
when the Linux, Android, and/or Windows equivalent app does it?

David W. Hodgins

unread,

Jul 5, 2020, 8:38:17 PM7/5/20

to

On Sun, 05 Jul 2020 19:02:53 -0400, Arlen Holder <arlen...@newmachine.com> wrote:
> I admit, openly, I can't yet understand the point of view of Linux users.
> o Why is this creepy behavior on iOS _clearly_ a bug by all accounts...
> *... but on Linux, the _same_ creepy behavior is not a bug?*

Here you've gone from asking if it happens on linux, to asking why it's not
considered a bug. Please show your evidence that it is happening on any linux
distribution published software. Otherwise, stop trolling.

J.O. Aho

unread,

Jul 6, 2020, 2:12:00 AM7/6/20

to

On 06/07/2020 01.12, Arlen Holder wrote:

> On 05 Jul 2020 22:25:37 GMT, St�phane CARPENTIER wrote:
>
>> The purpose of a clipboard is to exchange information between
>> applications. So by design it's normal they are able to access it.
>
> Hi Stephane,
>
> Thanks for trying to answer the question, because I'm genuinely confused
> why it's a bug on iOS by all accounts (nobody on the planet has yet to
> claim it's _not_ a bug, even the companies caught doing it, even as nobody
> is fooled that they wrote the code on purpose)... but ... on Linux... it's
> not a bug.
>
> Why is it not a bug on Linux when it's clearly (by all accounts) a bug when
> it happens on iOS?

First of all, it's not a bug, it's a design decision the application
makers has done, they want to know what people copies to the clipboard,
it's a way of spying on your users.

> Nobody (not even the companies caught doing it!) can defend this behavior
> when it happens on iOS.
>
> What's different about Linux?

Those applications you listed do not have Linux native version, so they
aren't targeting Linux. This far there haven't been any application for
Linux that are known to send the clipboard data to a remote server, if
you are in doubt use only open source application and check the source
code and problem solved.

Is it possible to do so, yes, it's possible no matter the OS in
question, the clipboard (as mentioned by so many others) is public for
all application that the user is running. If the clipboard wasn't
public, then you would have trouble to copy and past text between
applications.

> Why is it clearly (and always!) aberrant behavior on iOS... but not Linux?
> o ... makes no sense to me.

If you look at the question in your subject, people has in the whole
original thread and this new one been telling you that there ain't
special permission to access the clipboard, a creepy application no
matter which OS could snoop on your clipboard and send it to a remote
server and this far no Linux application has been caught to do this.

--

//Aho

Stéphane CARPENTIER

unread,

Jul 6, 2020, 6:50:56 AM7/6/20

to

Le 05-07-2020, Arlen Holder <arlen...@newmachine.com> a écrit :

> On 05 Jul 2020 22:25:37 GMT, Stéphane CARPENTIER wrote:
>
>> The purpose of a clipboard is to exchange information between
>> applications. So by design it's normal they are able to access it.
>

> Thanks for trying to answer the question, because I'm genuinely
> confused why it's a bug on iOS by all accounts (nobody on the planet
> has yet to claim it's _not_ a bug, even the companies caught doing it,
> even as nobody is fooled that they wrote the code on purpose)... but
> ... on Linux... it's not a bug.

First of all, it's not a bug. A bug is an unexpected behavior. The
clipboard content isn't sent unexpectedly by an application : it's
nonsense. It's a malicious application who does it.

The OS, anyone except qubes OS, is designed to let applications be able
to read the clipboard. But it doesn't mean the application has to do
everything it can with it.

> Why is it not a bug on Linux when it's clearly (by all accounts) a bug
> when it happens on iOS?

Because they don't know what a bug is ? A bug is not something done on
purpose.

> Nobody (not even the companies caught doing it!) can defend this behavior
> when it happens on iOS.
>
> What's different about Linux?

On iOS the users pay to don't have to understand how things are going ?

Nobody here defend the behavior. They say the application, not the OS is
to blame, it's not the same.

>> That being said, if an application is using its privilege to send the
>> information on Internet it's not a but of the OS but a real issue
>> with the application.
>
> The problem is that the user puts "sensitive data" (e.g., account
> numbers, passwords, people's names, whatever) in their clipboard, and,
> while we can blame the users, EVERY company caught doing this, so far,
> on iOS, has admitted guilt (they claimed it was a bug but the code was
> written on purpose), and has vowed to remove the app's creepy
> behavior.

If you have sensitive data, you don't use skype for example. If you use
skype, you don't blame your OS for letting sensitives datas to escape, you
blame your poor choices. Here it's the same. If you use any application
without concern on what they do, you don't blame the OS, you blame the
application.

> What worries me is that if it's clearly aberrant behavior on iOS (by every
> account where I stress nobody on this planet is claiming it's not aberrant
> behavior when it happens on iOS) ... isn't aberrant behavior on Linux.

Maybe on Linux users know what they are doing, so they are not as
surprised as on iOS.

It is an aberrant behavior on Linux. But it's the application which has
this behavior, not the OS.

Stéphane CARPENTIER

unread,

Jul 6, 2020, 7:03:48 AM7/6/20

to

Le 06-07-2020, J.O. Aho <us...@example.net> a écrit :
>
> First of all, it's not a bug, it's a design decision the application
> makers has done, they want to know what people copies to the clipboard,
> it's a way of spying on your users.

Yes, for once : it's not a bug, it's a feature is really appropriate.

> Is it possible to do so, yes, it's possible no matter the OS in
> question,

Not exactly. In fact qubes OS is designed to avoid this.

> the clipboard (as mentioned by so many others) is public for
> all application that the user is running. If the clipboard wasn't
> public, then you would have trouble to copy and past text between
> applications.

Exactly, on qubes OS, the clipboard is more difficult to use. It's the
choice made to avoid people having to face this behavior. Everything
comes at a price.

> a creepy application no matter which OS could snoop on your clipboard
> and send it to a remote server and this far no Linux application has
> been caught to do this.

Really, qubes OS is the exception. If you let the application getting
access to your clipboard, the application would have issue to exporting
the information.

Except for this, I fully agree.

Peter Köhlmann

unread,

Jul 6, 2020, 7:28:15 AM7/6/20

to

Arlen Holder wrote:

> On Mon, 06 Jul 2020 00:32:07 +0200, Peter K�hlmann wrote:
>
>> You got it completely wrong.
>
> Hi Peter,
>
> Either you don't understand what's going on, or I don't understand it.
> o It has to be one or the other.
>
> If I have it "completely wrong", can you explain why, when they do it on
> iOS, it's _always_ considered a bug, but, according to you, when the same
> creepy behavior of an app that isn't even running in the foreground is
> copying all your clipboard contents (on both your desktop & your iOS
> device!) is always a bug?

The big difference is: There is NO known linux app which does this. None. If
you are too stupid to understand that, you have no business asking those
extremely stupid questions here.
And when apps on iOS do this "creepy thing", ask apple why their app-
scanning is failing this miserably. Don't ask linux users

Soviet_Mario

unread,

Jul 6, 2020, 7:35:15 AM7/6/20

to

Il Mon, 06 Jul 2020 10:50:55 +0000, Stéphane CARPENTIER ha scritto:

CUT

>
> If you have sensitive data, you don't use skype for example. If you use
> skype, you don't blame your OS for letting sensitives datas to escape,
> you blame your poor choices. Here it's the same. If you use any
> application without concern on what they do, you don't blame the OS, you
> blame the application.

As I was compelled to use skype for video lessons and I'll be compelled to
use GSuite conferencing too, what precautions should I use to curtail
this tendency to send away data ? What data we are speaking ? Clipboard ?
Files (located where) ? Other ?

>
> Maybe on Linux users know what they are doing, so they are not as
> surprised as on iOS.
>
> It is an aberrant behavior on Linux. But it's the application which has
> this behavior, not the OS.

Is it there a way to add some restraint to spyware (skype, GSuite and
other) when one is obliged to use them by others ?
I'd be eager to limit damages !

--
la firma la setto dopo

Arlen Holder

unread,

Jul 6, 2020, 11:29:17 AM7/6/20

to

On Mon, 6 Jul 2020 08:11:56 +0200, J.O. Aho wrote:

> First of all, it's not a bug, it's a design decision the application
> makers has done, they want to know what people copies to the clipboard,
> it's a way of spying on your users.

Hi J.O. Aho,

I'm glad you posted, as usual, as an adult would post (thank God).

If you read the cites, you'll note that _everyone_ but the app makers
themselves, agrees with you; however, if you read the cites, it's patently
clear that the app makers themselves, at the highest levels in fact, said
very very very (very) clearly, "It's a bug".

Hence, we can move on since we both, as adults, understand what is going
on, where it's like when Putin says that the PMC isn't under his control,
you just have to take it in stride.
o It's not a bug until they're caught (it's a "design decision"); yet...
o the instant they're caught doing it, they "claim" it was a bug.

As with Putin & Wagner, it's "plausible deniability". :)

>> Nobody (not even the companies caught doing it!) can defend this behavior
>> when it happens on iOS.
>>
>> What's different about Linux?
>
> Those applications you listed do not have Linux native version, so they
> aren't targeting Linux.

There were over fifty apps listed, where I'll agree with you that most (if
not all) would be most often found as a "mobile app", e.g., "ABC News".

However, there's nothing stopping a malicious app from being malicious,
where I saw Peter's post claiming that there are no malicious Linux apps.

What's interesting, and an enigma perhaps, is that the iOS users, by all
accounts, applaud the new features of letting users know when it happens,
where I was also told today in an Android 10 thread that Android 10 has
this capability of letting users know when malicious apps are accessing the
clipboard...
o *Those on Android 10... is it worth upgrading from 9 to 10?*
*What are the pitfalls you've experienced & the benefits?*
<https://groups.google.com/forum/#!topic/comp.mobile.android/X65cMyzAn-g>

I have yet to test the new Android 10 capability to let users know whenever
malicious apps access the keyboard (presumably you can fine tune it so that
you're not notified to death), where the need on Linux, you seem to be
saying, is less.

Peter said essentially the same thing when he said there are no malicious
apps of that type on Linux.

If that's true, then that's the answer to the question, perhaps.

> This far there haven't been any application for
> Linux that are known to send the clipboard data to a remote server, if
> you are in doubt use only open source application and check the source
> code and problem solved.

I'm not skilled enough to check the source code, and, if we are actually
relistic, anyone who tells someone that, after hearing the question, isn't
really being honest, IMHO, since even trained researchers, with extensive
coding experience and training in coding flaws, miss such things.

It's common on Usenet for people to tell others to read the code and
understand every single line of that code, even as there may thousands to
millions of lines of code in that code - but it's a worthless suggestion
IMHO.

No "normal person" is capable of finding such bugs simply by "reading the
code" so I tend to have the hairs on my back stick up when someone appears
to be serious when suggesting that.

Even Linked-IN, Reddit, and TikTok "claimed" they didn't know it was there,
and, certainly the "heartthrob" bug and many others in known open source
code that you _expect_ trained people to look at, had holes that those
trained people didn't see.

So please do not suggest what is, in essence, impossible, since you know it
to be impossible given I'm not even close to a trained security
professional (I'm just a normal casual Linux user).

> Is it possible to do so, yes, it's possible no matter the OS in
> question, the clipboard (as mentioned by so many others) is public for
> all application that the user is running. If the clipboard wasn't
> public, then you would have trouble to copy and past text between
> applications.

Yes but.

The question was _never_ whether the clipboard was public. Never.

The question was what apps are "known" to access it when they didn't need
to.

On iOS, there are now, as of this date, over 50 apps "known" to be doing
this.

On Android, the fact Google (apparently) implemented the same kind of
checks in Android 10 that Apple introduced in iOS 14 indicates that Google
is aware of the problem.

If the answer on Linux is no Linux app would even think of doing it, then
that's the answer, I guess (as Peter suggested).

>> Why is it clearly (and always!) aberrant behavior on iOS... but not Linux?
>> o ... makes no sense to me.
>
> If you look at the question in your subject, people has in the whole
> original thread and this new one been telling you that there ain't
> special permission to access the clipboard, a creepy application no
> matter which OS could snoop on your clipboard and send it to a remote
> server and this far no Linux application has been caught to do this.

In summary, I repeat nobody has to tell anyone, least of all me, that any
app "can" do it, since that was known well before the thread was opened.

What you are telling me, is, in effect:
o No coder of any Linux app is _known_ to do this.

The only thing left is whether there is an existing mechanism, like there
is clearly in iOS 14 and like there has been stated there is now in Android
10, for a user to crosscheck that there is no known Linux malware that does
this (where that cross check now exists on iOS & reputedly also on Android)
--
And no, it's not a good suggestion to tell every Linux user on the planet
to read all the code of all the apps on their linux box to find out whether
any app is doing this. It's just not a reasonable suggestion.

Arlen Holder

unread,

Jul 6, 2020, 12:42:16 PM7/6/20

to

On 06 Jul 2020 11:03:48 GMT, Stéphane CARPENTIER wrote:

> Le 06-07-2020, J.O. Aho <us...@example.net> a écrit :
>>
>> First of all, it's not a bug, it's a design decision the application
>> makers has done, they want to know what people copies to the clipboard,
>> it's a way of spying on your users.
>
> Yes, for once : it's not a bug, it's a feature is really appropriate.

Hi Stephane,

We all agree, a priori, it's not a bug except when the app maker is caught
doing it, and then, and only then, they "claim" it was a bug; but that's
just their excuse (which all adults understand, without further discussion
- just as we understand the inane excuses of our grandkids when caught
snatching cookies from the cookie jar or not doing their chores at home).

o *LinkedIn says iOS clipboard snooping after every key press is a bug*
<https://www.zdnet.com/article/linkedin-says-ios-clipboard-snooping-after-every-key-press-is-a-bug-will-fix/>

"A LinkedIn spokesperson told ZDNet yesterday that a bug in the company's
iOS app was responsible for a seemingly privacy-intrusive behavior
spotted by one of its users on Thursday."

The point is that, once caught, they _all_ say they'll fix it soon.
o *Reddit says it's fixing code in its iOS app that copied clipboard contents*
<https://www.theverge.com/2020/7/4/21313214/reddit-code-clipboard-privacy-copy-ios>

"Reddit says it's releasing a fix for a piece of code that copied
contents from users' clipboards. 'We tracked this down to a codepath in
the post composer that checks for URLs in the pasteboard and then
suggests a post title based on the text contents of the URL,' a Reddit
spokesperson wrote in an email to The Verge..."

"'We removed this code and are releasing the fix on July 14th'."

Same with Linked-In:

"LinkedIn said Friday it would stop the practice, explaining its app
was doing so to perform an equality check between what a user is typing
and what's in their clipboard... The company didn't explain why the
practice was in place to begin with..."
<https://www.theverge.com/2020/7/4/21313214/reddit-code-clipboard-privacy-copy-ios>

>> Is it possible to do so, yes, it's possible no matter the OS in
>> question,
>
> Not exactly. In fact qubes OS is designed to avoid this.

Exactly the point of the iOS and Andriod operating system tweaks, which at
least _notify_ the user whenever an app accesses the clipboard (which, I
think is configurable so we're not notified to death).

Why not Linux?

You pretty much answered that _some_ Linux variants do have this
protection.

Thank you for that useful information Stephan, which I appreciate, and,
more importantly, which adds on-topic value to the thread topic.

>> the clipboard (as mentioned by so many others) is public for
>> all application that the user is running. If the clipboard wasn't
>> public, then you would have trouble to copy and past text between
>> applications.
>
> Exactly, on qubes OS, the clipboard is more difficult to use. It's the
> choice made to avoid people having to face this behavior. Everything
> comes at a price.

Agreed.

It would be nice for "basic" Linux (e.g., ubuntu) to have this option, just
as iOS 14 and now, Android 10, have this option.

Note I haven't tested either, as the iOS 14 is well publicized, but I'm on
iOS 13.5 at the moment, and I only found out about the Android 10 (which I
moved to this week on my $100 Moto G7 which came with Android 9) from this
thread earlier today...

o *Those on Android 10... is it worth upgrading from 9 to 10?*
*What are the pitfalls you've experienced & the benefits?*
<https://groups.google.com/forum/#!topic/comp.mobile.android/X65cMyzAn-g>

>> a creepy application no matter which OS could snoop on your clipboard
>> and send it to a remote server and this far no Linux application has
>> been caught to do this.
>
> Really, qubes OS is the exception. If you let the application getting
> access to your clipboard, the application would have issue to exporting
> the information.
>
> Except for this, I fully agree.

You seem, so far, to be the only one who posted who actually understands
the situation, for which I thank you Stephane, as it's a pleasure to not
have to explain that everyone knows, everyone knew, everyone always knew,
that any app could access the clipboard just like anyone could rob a bank.

It's only a problem when a malicious app does it when you don't know it.

That's why it's a welcome operating system change that you speak of in
qubes OS, and which is also, in some ways, in iOS 14 and (reputedly) in
Android 10.

I looked at the documentation, briefly, for Qubes to see what they say:
o <https://www.qubes-os.org/>

I haven't seen the word "clipboard" or "pasteboard" yet at the top level:
o <https://www.qubes-os.org/doc/>

But "clipboard" does show up at lower levels (which I need to read further)
o <https://www.qubes-os.org/doc/copy-paste/>
"On Copy/Paste Security
The scheme is secure because it doesn't allow other VMs to steal the
content of the clipboard."

That's not the same thing (as VMs are different beasts), but it's a start.
--
Usenet is wonderful when everyone pitches in helpfully with knowledge.

Arlen Holder

unread,

Jul 6, 2020, 2:02:39 PM7/6/20

to

On Mon, 6 Jul 2020 11:35:14 -0000 (UTC), Soviet_Mario wrote:

> What data we are speaking ? Clipboard ?
> Files (located where) ? Other ?

In the cases that prompted this thread and it's update, it's the clipboard.
o Here are some of the various "excuses" app developers attempted this week

o *LinkedIn says iOS clipboard snooping after every key press is a bug*
<https://www.zdnet.com/article/linkedin-says-ios-clipboard-snooping-after-every-key-press-is-a-bug-will-fix/>
"A LinkedIn spokesperson told ZDNet yesterday that a bug in the company's
iOS app was responsible for a seemingly privacy-intrusive behavior
spotted by one of its users on Thursday."

"LinkedIn said Friday it would stop the practice, explaining its app
was doing so to perform an equality check between what a user is typing
and what's in their clipboard... The company didn't explain why the
practice was in place to begin with..."
<https://www.theverge.com/2020/7/4/21313214/reddit-code-clipboard-privacy-copy-ios>

o *Reddit says it's fixing code in its iOS app that copied clipboard contents*
<https://www.theverge.com/2020/7/4/21313214/reddit-code-clipboard-privacy-copy-ios>
"Reddit says it's releasing a fix for a piece of code that copied
contents from users' clipboards. 'We tracked this down to a codepath in
the post composer that checks for URLs in the pasteboard and then
suggests a post title based on the text contents of the URL,' a Reddit
spokesperson wrote in an email to The Verge..."
"'We removed this code and are releasing the fix on July 14th'."

o *TikTok says it will stop accessing clipboard content on iOS devices*
<https://www.theverge.com/2020/6/26/21304228/tiktok-security-ios-clipboard-access-ios14-beta-feature>
"A TikTok spokesperson said in a statement emailed to The Verge on Friday
that it had submitted an update to the App Store to remove the feature,
which it described as an anti-spam measure. The feature was never
introduced to Android devices, according to the company"

J.O. Aho

unread,

Jul 6, 2020, 4:30:58 PM7/6/20

to

On 06/07/2020 13.03, Stéphane CARPENTIER wrote:
> Le 06-07-2020, J.O. Aho <us...@example.net> a écrit :
>>
>> First of all, it's not a bug, it's a design decision the application
>> makers has done, they want to know what people copies to the clipboard,
>> it's a way of spying on your users.
>
> Yes, for once : it's not a bug, it's a feature is really appropriate.
>
>> Is it possible to do so, yes, it's possible no matter the OS in
>> question,
>
> Not exactly. In fact qubes OS is designed to avoid this.

QubeOS runs things in Xen containers and do not enable normal clipboard
sharing between host/guest, it's like running Virtualbox and disable the
sharing of clipboards, between host and guest. This do not prevent the
application to access the local clipboard/clipboard manager and get data
from there.

>> the clipboard (as mentioned by so many others) is public for
>> all application that the user is running. If the clipboard wasn't
>> public, then you would have trouble to copy and past text between
>> applications.
>
> Exactly, on qubes OS, the clipboard is more difficult to use. It's the
> choice made to avoid people having to face this behavior. Everything
> comes at a price.

You need to use a special clipboard application to copy the data between
different instances, in a similar manner you would have to do if you
haven't enabled clipboard sharing in Virtualbox, you need to use an
alternative.

>> a creepy application no matter which OS could snoop on your clipboard
>> and send it to a remote server and this far no Linux application has
>> been caught to do this.
>
> Really, qubes OS is the exception.

No, it's not, the application will still be able to access the local
environments clipboard.

> If you let the application getting
> access to your clipboard, the application would have issue to exporting
> the information.

Not fully true, you have to have restricted the network access for the
container, otherwise the application has access to internet. Say you
have a chat program like IRC and it's snooping the clipboard, it could
send the clipboard data to the connected server and you would still be
leaking the data in the IRC's local clipboard.

--

//Aho

Carlos E.R.

unread,

Jul 6, 2020, 5:00:08 PM7/6/20

to

On 06/07/2020 01.12, Arlen Holder wrote:

> On 05 Jul 2020 22:25:37 GMT, Stéphane CARPENTIER wrote:
>
>> The purpose of a clipboard is to exchange information between
>> applications. So by design it's normal they are able to access it.
>
> Hi Stephane,
>
> Thanks for trying to answer the question, because I'm genuinely confused
> why it's a bug on iOS by all accounts (nobody on the planet has yet to
> claim it's _not_ a bug, even the companies caught doing it, even as nobody
> is fooled that they wrote the code on purpose)... but ... on Linux... it's
> not a bug.
>
> Why is it not a bug on Linux when it's clearly (by all accounts) a bug when
> it happens on iOS?
>
> Nobody (not even the companies caught doing it!) can defend this behavior
> when it happens on iOS.
>
> What's different about Linux?

Please forget iOS, and as as you are writing in a Linux group, tell us
what app has been found to do this. Not Android, iOS, Windows apps. Just
Linux apps.

--
Cheers, Carlos.

Carlos E.R.

unread,

Jul 6, 2020, 5:00:08 PM7/6/20

to

For files, apparmor, for instance.

--
Cheers, Carlos.

Stéphane CARPENTIER

unread,

Jul 6, 2020, 5:10:43 PM7/6/20

to

Le 06-07-2020, Soviet_Mario <Sovie...@CCCP.MIR> a écrit :
> Il Mon, 06 Jul 2020 10:50:55 +0000, Stéphane CARPENTIER ha scritto:
>
> CUT
>>
>> If you have sensitive data, you don't use skype for example. If you use
>> skype, you don't blame your OS for letting sensitives datas to escape,
>> you blame your poor choices. Here it's the same. If you use any
>> application without concern on what they do, you don't blame the OS, you
>> blame the application.
>
> As I was compelled to use skype for video lessons and I'll be compelled to
> use GSuite conferencing too, what precautions should I use to curtail
> this tendency to send away data ? What data we are speaking ? Clipboard ?
> Files (located where) ? Other ?

First, there is two skype. The historical one and skype for entreprises.
For the former, there is no way to avoid it. You don't know what it
does, it's working, but it uses your computer to do nobody knows what.
It's not only my vision of skype.

I don't know if there is an English translation available, I can't find
it. A study has been done to try to know what skype was doing. It was
done by Frédéric DESCLAUX and the title is "castle in the skype". I'm
aware only of a French version, i's very technical and at the end he
wasn't able to go to the end of the study.

If you are interested, you can look here, maybe you can understand some
parts with very few words :
<https://www.yumpu.com/fr/document/read/26566254/castle-in-the-skype-sstic>
I really have no better explanation. Maybe you look for yourself you'll
have different results and be able to find the English version.

For the skype for entreprises, I have no clue. I heard it's safer. But
really, for the former one, if you grant it access, you don't control
anything.

>> Maybe on Linux users know what they are doing, so they are not as
>> surprised as on iOS.
>>
>> It is an aberrant behavior on Linux. But it's the application which has
>> this behavior, not the OS.
>
> Is it there a way to add some restraint to spyware (skype, GSuite and
> other) when one is obliged to use them by others ?
> I'd be eager to limit damages !

The only way I'm aware of is qubes OS. The principle is to have a lot of
VM and run everything either in its own VM or in its own group of VM.
Like that, if you have a malware which take control of it's own VM, it
isn't able to take control of anything else.

You can do the same without qubes OS, but for it you need to take care
of everything :
<https://www.qubes-os.org/>

J.O. Aho

unread,

Jul 6, 2020, 5:10:56 PM7/6/20

to

On 06/07/2020 17.29, Arlen Holder wrote:
> On Mon, 6 Jul 2020 08:11:56 +0200, J.O. Aho wrote:
>
>> First of all, it's not a bug, it's a design decision the application
>> makers has done, they want to know what people copies to the clipboard,
>> it's a way of spying on your users.
>
> Hi J.O. Aho,
>
> I'm glad you posted, as usual, as an adult would post (thank God).
>
> If you read the cites, you'll note that _everyone_ but the app makers
> themselves, agrees with you; however, if you read the cites, it's patently
> clear that the app makers themselves, at the highest levels in fact, said
> very very very (very) clearly, "It's a bug".

That is human, even a kid says it's a mistake that they took a cookie
before dinner if they were caught. Of course they will blame it's a bug
or forgotten test code.

> However, there's nothing stopping a malicious app from being malicious,
> where I saw Peter's post claiming that there are no malicious Linux apps.

The number of malicious application in the distributions repositories
tend to be zero (I know that is a quite bold statement, but the distro
maintainers do a quite good job of keeping malicious programs away, but
sure they could fail in that too), the problem arises when you start to
download things outside the normal repositories, it's not Linux fault,
it's your own.

The golden rule is use what your distro provides, if you still miss
something, compile it yourself after downloading it from the authors
source code repository.

> What's interesting, and an enigma perhaps, is that the iOS users, by all
> accounts, applaud the new features of letting users know when it happens,
> where I was also told today in an Android 10 thread that Android 10 has
> this capability of letting users know when malicious apps are accessing the
> clipboard...

> I have yet to test the new Android 10 capability to let users know whenever
> malicious apps access the keyboard (presumably you can fine tune it so that
> you're not notified to death), where the need on Linux, you seem to be
> saying, is less.

Linux traditionally uses a request model, the application that needs
something from a clipboard has to ask the application who owns the
clipboard entry, the owner then sends. Sure you could write a confirm
mechanism to it, just rewrite part of the xlib, but people who uses
clipboard managers would be quite annoyed by it.

Of all OS:es, Linux may have the most ancient and most complicated to
use in code, which may give Linux even less interest to snoop the
clipboard, simpler to use keylogger.

>> This far there haven't been any application for
>> Linux that are known to send the clipboard data to a remote server, if
>> you are in doubt use only open source application and check the source
>> code and problem solved.
>
> I'm not skilled enough to check the source code, and, if we are actually
> relistic, anyone who tells someone that, after hearing the question, isn't
> really being honest, IMHO, since even trained researchers, with extensive
> coding experience and training in coding flaws, miss such things.

If you are scared to use application and don't have the time to write
them yourself, you need to know coding so much that you can make simple
review and look for if someone uses a clipboard framework of uses xlib
to access the clipboard.

Most people do trust the distro maintainers or else they would have
picked another distro. In the same way you trusted teachers to teach you
the right things at school, you have to decide whom to trust for your
software unless you are prepared to review and compile everything yourself.

> It's common on Usenet for people to tell others to read the code and
> understand every single line of that code, even as there may thousands to
> millions of lines of code in that code - but it's a worthless suggestion
> IMHO.

Yes, it's common to tell people to look at the code for people tend to
think that there are hidden code that makes something bad without any
real reason. Sure there are some people who would be able to read the
code and understand everything, but if you don't trust the maintainers
then you have only one option, read the code.

> No "normal person" is capable of finding such bugs simply by "reading the
> code" so I tend to have the hairs on my back stick up when someone appears
> to be serious when suggesting that.

This ain't a bug you are looking for, you are looking for two
functionalities (in this case), read clipboard and transmit the data.
This already limits which functions/libraries you would need to find in
the code.

> Even Linked-IN, Reddit, and TikTok "claimed" they didn't know it was there,
> and, certainly the "heartthrob" bug and many others in known open source
> code that you _expect_ trained people to look at, had holes that those
> trained people didn't see.

When data been sent to them, you know it's a feature, the bug was that
they failed to hide the traffic.

unread,

Jul 6, 2020, 6:59:01 PM7/6/20

to

Le 06-07-2020, Arlen Holder <arlen...@newmachine.com> a écrit :
>

> However, there's nothing stopping a malicious app from being malicious,
> where I saw Peter's post claiming that there are no malicious Linux apps.

The fact is, in Linux, the applications are mostly open-source. It means
anyone can read the code. It doesn't stop someone tu put malicious code,
but it needs to be really carefully done if you ask the package
maintainers to deploy it.

For example, the Sony rootkit didn't run on Linux :
<https://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootkit_scandal>

> No "normal person" is capable of finding such bugs simply by "reading the
> code" so I tend to have the hairs on my back stick up when someone appears
> to be serious when suggesting that.

There are some tools to help you doing it. Nobody is reading every
single line of code deployed on his computer. But there is a lot of
people who are checking some part of the code. Not always because they
are suspicious, it's more often to improve it.

> Even Linked-IN, Reddit, and TikTok "claimed" they didn't know it was there,

If you tell me a secret and I told you back : "My bad, I thought I
suppressed your email. But I realised I was filming myself reading it
and I put the video on youtube and sent the link to everyone I know. But
I'm really sorry, I didn't do it on purpose." Would you believe me ?
Here it's the same. I don't care what they claim.

> On iOS, there are now, as of this date, over 50 apps "known" to be doing
> this.

Why are you only concerned by the clipboard ? Do you know which
application is using you mic or your camera ?

Soviet_Mario

unread,

Jul 6, 2020, 7:13:45 PM7/6/20

to

so nothing about skype / GSuite ?

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

unread,

Jul 6, 2020, 8:02:39 PM7/6/20

to

On 2020-07-06, Arlen Holder <arlen...@newmachine.com> wrote:
> On Mon, 6 Jul 2020 11:35:14 -0000 (UTC), Soviet_Mario wrote:

> In the cases that prompted this thread and it's update, it's the clipboard.
> o Here are some of the various "excuses" app developers attempted this week
>

> "A LinkedIn spokesperson told ZDNet yesterday that a bug in the company's
> iOS app was responsible for a seemingly privacy-intrusive behavior
> spotted by one of its users on Thursday."
>
> "LinkedIn said Friday it would stop the practice, explaining its app
> was doing so to perform an equality check between what a user is typing
> and what's in their clipboard.

> "Reddit says it's releasing a fix for a piece of code that copied
> contents from users' clipboards. 'We tracked this down to a codepath in
> the post composer that checks for URLs in the pasteboard and then
> suggests a post title based on the text contents of the URL,'

> "A TikTok spokesperson said in a statement emailed to The Verge on Friday
> that it had submitted an update to the App Store to remove the feature,
> which it described as an anti-spam measure.

Interesting; it seems that some of the developers may have been snooping the
clipboard to detect pastes.

That seems plausible, if misguided: there are surely better ways to
detect pastes..

--
Jasen.

Aragorn

unread,

Jul 6, 2020, 8:54:33 PM7/6/20

to

On 06.07.2020 at 19:30, David W. Hodgins scribbled:

> On Mon, 06 Jul 2020 19:19:12 -0400, Soviet_Mario
> <Sovie...@cccp.mir> wrote:
>
> > yes the virtual machine approach was my first one even when
> > I knew little about this specific topic.
> > On the other PC I'll keep on using this. Maybe here I'll try
> > to learn apparmor .... (I won't give up using Debian, I'm
> > too accustomed to it)
>
> You may also want to change the umask from 022 to 077 so that newly
> created files are only readable by that user.
> https://www.thegeekstuff.com/2010/04/unix-file-and-directory-permissions/
>
> In Mageia, the default umask value is set in /etc/profile.

That would not be the right place to change it, unless you know some
bash scripting, because the root user's umask should remain at 022.

For those who don't know enough about scripting, it is better to set the
umask in ~/.bashrc and/or ~/.bash_profile — provided that one uses Bash
as one's login shell, of course. In zsh, it's ~/.zprofile.

For those who'd want to do it via /etc/profile, something like this
below will work — it's what I did on my Manjaro system.

if [ ${UID} -lt 1000 ]
then
umask 022
else
umask 077
fi

The above is under the assumptions that normal user accounts start at
UID 1000. In some distributions — e.g. PCLinuxOS — they may start at
500, or maybe at yet another number.

Of course, one would best have the permissions on /root — i.e. the root
account's home directory — be 700.

# chmod 700 /root

--
With respect,
= Aragorn =

David W. Hodgins

unread,

Jul 6, 2020, 9:35:46 PM7/6/20

to

On Mon, 06 Jul 2020 20:54:31 -0400, Aragorn <thor...@telenet.be> wrote:

> On 06.07.2020 at 19:30, David W. Hodgins scribbled:
>
>> On Mon, 06 Jul 2020 19:19:12 -0400, Soviet_Mario
>> <Sovie...@cccp.mir> wrote:
>>
>> > yes the virtual machine approach was my first one even when
>> > I knew little about this specific topic.
>> > On the other PC I'll keep on using this. Maybe here I'll try
>> > to learn apparmor .... (I won't give up using Debian, I'm
>> > too accustomed to it)
>>
>> You may also want to change the umask from 022 to 077 so that newly
>> created files are only readable by that user.
>> https://www.thegeekstuff.com/2010/04/unix-file-and-directory-permissions/
>>
>> In Mageia, the default umask value is set in /etc/profile.
>
> That would not be the right place to change it, unless you know some
> bash scripting, because the root user's umask should remain at 022.
>
> For those who don't know enough about scripting, it is better to set the
> umask in ~/.bashrc and/or ~/.bash_profile — provided that one uses Bash
> as one's login shell, of course. In zsh, it's ~/.zprofile.

Good Point. I agree. In Mageia, checking /etc/bashrc, which is sourced for all
users, it does override the default set in /etc/profile. It's also overridden
in several other scripts in /etc, so it wouldn't be as simple as changing it

Carlos E.R.

unread,

Jul 6, 2020, 10:32:07 PM7/6/20

to

Unless your distribution has taken the work to also distribute the
profiles for it, it does nothing. You have to create the profiles or
download from somewhere, and it is hard work. For one app or to, it is easy.

--
Cheers, Carlos.

Arlen Holder

unread,

Jul 7, 2020, 12:02:00 AM7/7/20

to

On 06 Jul 2020 21:55:50 GMT, Stephane CARPENTIER wrote:

> Yes, but no. With android and I'd say the same for iOS, the application
> is requesting its requirements at the installation process. And once
> granted it doesn't request anything any more and you don't know what is
> done. Except when you have wifi, data and everything off by default and
> the application is requesting you to put it on.

Hi Stephane,

Yes but no. :)

Here's the "Yes"...
"Explanation: Any applications that declare the permission
android.permission.READ_CLIPBOARD in their AndroidManifest.xml file
is automatically granted this permission when it is installed,
meaning they can read the Android clipboard.

Although many devices have access to a permission management control
system in Settings, READ_CLIPBOARD is not something users can restrict
from apps (unless you're a user of certain custom ROMs such as
LineageOS.)"
<https://www.xda-developers.com/stop-apps-reading-android-clipboard/>

Here's the "but no"...
"However, there's actually a hidden way of restricting the permission
apps use to read your clipboard... We used the hidden appops command
line interface, which lets us restrict more permissions than is shown
in Settings."
<https://www.xda-developers.com/stop-apps-reading-android-clipboard/>

It's a pleasure to discuss things with you because, with you, we can move
forward from what we all knew before this thread existed, instead of doing
what most people are doing, which is rehashing what everyone already knows.

While you seem to be the only one so far who has posted (that I've
responded to anyway) that seems to have _any_ grasp of the issue, as far as
I can recall, Android (up until Android 10 anyway), doesn't have, AFAIK, a
specific permission set for clipboard access (someone correct me if I'm
wrong as all I ever care about, are the facts).

Just like with clipboard protection, iOS & Android are ahead of Linux and
Windows, it seems, at least by default, as we move ahead on privacy (e.g.,
Android now transmits only randomized MAC addresses, by default).
o *Privacy changes in Android 10*
<https://developer.android.com/about/versions/10/privacy/changes>
<https://tr2.cbsistatic.com/hub/i/2019/06/04/d390bc2c-33a3-4def-8d19-1d2c49ef2b8d/macb.jpg>

That kind of privacy, by default, isn't yet on Linux (AFAIK), as, well,
Lord knows how many threads I've authored on Mac randomization in the past.

It seems the mobile devices are ahead of Linux, on these defaults.

In Android 10, for example, there are now new clipboard permissions:
o *Read Clipboard Permissions on Android 10*
<https://joaoapps.com/AutoApps/Help/Info/com.joaomgcd.join/android_10_read_logs.html>
"To read your clipboard on Android 10, Join needs to be granted
permission to read system logs and draw over other apps on your device"

o *No more stealing passwords*
"The Android Q 10 build includes new permission called
READ_CLIPBOARD_IN_BACKGROUND. As the name suggests, the new permission
will hamper random background apps from accessing the clipboard content.
Above all, apps would be asked to get a signature from the OEM.
<https://fossbytes.com/best-android-10-features/>

>> Why not Linux?
>
> There is ways to restrict usages to application in Linux. But the
> purpose of the clipboard isn't to be restricted but to help sharing
> information between applications.

Well, on Android, as shown below, there _are_ ways to restrict apps from
reading the clipboard, which is good news as Android is ahead of the game.

o *How to Stop Apps from Reading the Android Clipboard to Protect your Privacy*
<https://www.xda-developers.com/stop-apps-reading-android-clipboard/>
(You set the clipboard permissions from your Mac, Linux, or Windows
computer over USB using the freeware adb commands.)
$ /home/user/downloads/adb devices
$ adb shell
$ cmd appops query-op --user 0 READ_CLIPBOARD allow
$ cmd appops set <package> READ_CLIPBOARD ignore
"If you don┤ see an error message, then the command worked!
Repeat the above step for any other apps you want to stop reading
your clipboard."

"The first command we did, query-ops, pulls a list of applications
installed that have been granted the Android clipboard read permission.
Using that list, we can then decide which apps we want to stop from
reading your clipboard. If you decide to restrict the permission from
every user/third-party app installed on your device, then you can even
start to safely copy and paste your passwords without having to worry
that another app might listen in and steal your passwords!"
<https://www.xda-developers.com/stop-apps-reading-android-clipboard/>

>> You pretty much answered that _some_ Linux variants do have this
>> protection.
>
> Qubes OS is not a Linux variant. It's an hypervisor with a lot of
> Virtual machines running on it. The VM can be Linux or Windows. But for
> the privacy, it's a lot more heavier to handle, the people don't want it
> without reason.

Ah, thanks for clarifying what Qubes OS is, as this is my first exposure.

What I like about iOS and Android's philosophy on clipboard privacy is that
you _can_ turn off clipboard access, on a case by case basis, with the
latest iOS 14, and, apparently, with multiple Android versions (where it's
simply easier to do now, in Android 10, reputedly).

>> It would be nice for "basic" Linux (e.g., ubuntu) to have this option,
>> just as iOS 14 and now, Android 10, have this option.
>
> It's not an option in Linux. The design is different. And I trust a
> little bit the applications I'm putting in because they aren't very
> popular and around from a long time. They are all open source, so a
> malware could be found more easily.

Agreed.

Overall, open source helps the user because we can presume "somebody" who
knows what they're doing has "inspected" the code. (Let's hope.)

I do get my hairs on end when people, like they did in this thread, suggest
"everyone" (even those who don't code!) still read the code, in order to
assess what the code is doing to the clipboard... but that's just crazy
(which is why I state that of all who posted, only you seem to understand
the problem set sufficiently to provide useful advice).

> I would be very surprised to find that Android iOS have the same level of
> security than qubes OS.

Let's be clear that nobody said that, and nobody implied that, and nobody
thinks that, and nobody should infer that anyone said that.

What Android (and iOS) has, that Linux doesn't seem to have, is control
over whether or not an app has access to the clipboard, and, in the case of
iOS, notification when it does access the clipboard.

Does Linux have that yet?
o If not, perhaps it should. :)

> The purpose is not to protect against the clipboard, but against
> everything. From the viruses, to the webcam. The clipboard is only a way
> to extract information. They wouldn't do so much work only for the
> clipboard.

Agreed.
o Later, not now, but later, I'll run a search for the obvious, which is:
"What is the difference between Tails and Qubes OS"
(although that alone might get me on some TLA's radar as an activist!) :)

However, the point of this thread is _only_ about the clipboard.
o Specifically Linux protection akin to what we now see on Android & iOS.

> The
> purpose is to let your application access to an isolated clipboard, like
> that, whatever your application do with your clipboard is of no
> consequence for your privacy.

Thank you for that explanation where, again, you seem to be the only one,
so far, who posted, who understands the problem set sufficiently to advise
others.

In summary, I think, this thread, has suggested multiple related factors:
1. On both iOS and on Android, the user is now notified when an app
secretly accesses the clipboard.
2. All apps caught that we know of to date, have instantly apologized and
said they will immediately remove their creepy snooping behavior
3. All app developers have "claimed" it was a bug, but we all on this ng
aren't that easily bamboozled by their excuses; sufficient that they remove
the clipboard snooping when caught.
4. On Linux (e.g., Ubuntu) native, the user apparently will have no way of
knowing how many apps perform this act when they don't need to do it.
5. As nospam has said, it's "ignorance" driving users (like Peter) who
claimed, without a shred of data apparently, that no apps on Linux are
malicious.
6. The fact that many (most? all?) Linux apps are open source helps greatly
though, where we can "assume" that "someone" who knows how to read code,
has checked the code to see if the apps maliciously read the clipboard.

In summary, most people feel it's only a problem on iOS and Android, and
not, necessarily, on Linux, where, if that's indeed the case, the good news
is that clearly both iOS and Android are doing something about the problem.
--
Working in unison on Usenet in polite discussion we can all learn together.

Arlen Holder

unread,

Jul 7, 2020, 1:01:56 AM7/7/20

to

On 06 Jul 2020 22:59:00 GMT, Stéphane CARPENTIER wrote:

> Why are you only concerned by the clipboard ?

Hi Stephane,

You seem to be able to handle technical detail, so it's a pleasure to
discuss this problem set with you.

That's especially true given you're the only one who seems to _understand_
the problem set (perhaps along with J.O. Aho with his most recent response
to the same post you're responding to above)... hence what you ask of me is
important.

The simple answer is inherent in the opening post:
o TikTok got caught doing it; so I wondered what Linux programs do it.

The more complex answer in inherent in the timeline of new details:
o Apple iOS implemented popup notifications when it happens again

Where, that caught TikTok (again), along with Reddit, Linked-In, et al.
o So that's why the thread was UPDATED with further new details this week

In addition, after getting a shit ton of bogus answers on this (and other)
OS threads from people who _still_ don't seem to comprehend what you
understood from the very start... I dug into what Android does & did,
where, since at least Android 6, we've had control of app clipboard
permissions obtained as easily as simply installing an app, e.g.,

o *Private Clipboard helps mimic Android 10's clipboard privacy on older Android devices*
<https://www.xda-developers.com/private-clipboard-mimic-android-10-privacy/>
"In Android versions prior to Android 10, every single app could read the
contents of your clipboard. And this was accomplished without needing to
grant any runtime permission to any app..."

"Android Q/Android 10 would finally block background clip reading.
But if you are on an older release of Android, you can mimic the
same functionality with this Private Clipboard app."
<https://forum.xda-developers.com/android/apps-games/app-private-clipboard-t3964055>
<https://labs.xda-developers.com/store/app/net.easyjoin.privateclipboard>

Note that you can do the same thing, apparently, as private clipboard does,
simply by connecting your Android device to Linux, Mac, Windows, over adb
on USB, and then you can issue commands to *control* what apps have
clipboard access (as described in gory detail in a prior post to you
minutes ago).

In summary, for clipboard access, the two operating systems doing something
about it are clearly iOS and Android, where what iOS is doing is
essentially two things (AFAICT):
1. Notifying the user whenever an app maliciously reads the clipboard, and,
2. Allowing the user to _control_ whether they want that app to have it.

On Android, it seems the "notification" isn't there yet (is it?); but it
seems the ability to allow the user control over the setting was always
there (within some range of "always", e.g., Android 6+), and, it's
apparently more easily accessible to the normal user in Android 10.
o *Clipboard not accessible from background app with Android 10 SDK upgrade*
<https://stackoverflow.com/questions/58727690/clipboard-not-accessible-from-background-app-with-android-10-sdk-upgrade>

It seems both Linux & Windows, so far, don't have/need/want it yet.

> Do you know which
> application is using you mic or your camera ?

Yes, of course.
o At least for Android I think I have full & complete knowledge.

Particularly since I turn _off_ mic & camera permissions for all apps that
request it, and only turn it back on, ad hoc, if/when I need it.

In fact, I turned off _all_ possible permissions, and fully documented it:
o *My experiment turning all Android app permissions off*
<https://groups.google.com/forum/#!topic/comp.mobile.android/FKjvRYbqgIw>
--
Every thread should add to the value of our permanent Usenet archive.

Stéphane CARPENTIER

unread,

Jul 7, 2020, 6:40:41 AM7/7/20

to

Le 06-07-2020, J.O. Aho <us...@example.net> a écrit :

The issue with skype is on purpose. You don't know where it needs to send
information to work correctly and where it sends information you don't
want to be sent.

Stéphane CARPENTIER

unread,

Jul 7, 2020, 7:37:04 AM7/7/20

to

Le 07-07-2020, Arlen Holder <arlen...@newmachine.com> a écrit :
> On 06 Jul 2020 21:55:50 GMT, Stephane CARPENTIER wrote:
>
> That kind of privacy, by default, isn't yet on Linux (AFAIK), as,
> well, Lord knows how many threads I've authored on Mac randomization
> in the past.

The MAC address randomisation is only useful when you move without VPN.

> It seems the mobile devices are ahead of Linux, on these defaults.

Because it's pointless on desktop, and pointless on laptop if you use
your phone as a wifi source. So, Linux can put it in place easily, but
there is no real need by default outside mobile devices.

>
> In Android 10, for example, there are now new clipboard permissions:
> o *Read Clipboard Permissions on Android 10*
><https://joaoapps.com/AutoApps/Help/Info/com.joaomgcd.join/android_10_read_logs.html>
> "To read your clipboard on Android 10, Join needs to be granted
> permission to read system logs and draw over other apps on your device"

Do you really believe it's an improvement to be required to read the log
to be able to access the clipboard ?

OK, I'm French and maybe I don't know what a clipboard is. It's possible
we don't speak of the same thing. For me, the clipboard is the thing used
to copy/paste information between applications.

If I'm wrong, I'd like an explanation.

If I'm right, I really don't understand what concerned you so much with
the clipboard. It's not a keylogger. If you tell me that Android and iOS
don't manage a real clipboard but are using the central logs for the
purpose, there is a real concern. But they are not far in advance of
Linux, they are garbage which needs fast improvement.

> o *No more stealing passwords*
> "The Android Q 10 build includes new permission called
> READ_CLIPBOARD_IN_BACKGROUND. As the name suggests, the new
> permission will hamper random background apps from accessing the
> clipboard content. Above all, apps would be asked to get a
> signature from the OEM.
><https://fossbytes.com/best-android-10-features/>

Why do you put your password on you clipboard ? There is better ways
than that. Either you know your password or you put it in a serious
password manager. Putting your password in your clipboard is bad.

> Well, on Android, as shown below, there _are_ ways to restrict apps from
> reading the clipboard, which is good news as Android is ahead of the game.

From what I see it's more far behind. And for the restriction, it's as I
said. You don't grant it the right at each need, which would be very
difficult.

> What I like about iOS and Android's philosophy on clipboard privacy is
> that you _can_ turn off clipboard access, on a case by case basis,
> with the latest iOS 14, and, apparently, with multiple Android
> versions (where it's simply easier to do now, in Android 10,
> reputedly).

I don't know how Android and iOS are managing their clipboards, but
unless I have not the same definition, only what you copy must be
available in it. If the clipboard grant to access to anything else, it's
bad, and I understand your concern. But in this case, their philosophy
is garbage and they lack far behind Linux.

> I do get my hairs on end when people, like they did in this thread, suggest
> "everyone" (even those who don't code!) still read the code, in order to
> assess what the code is doing to the clipboard... but that's just crazy
> (which is why I state that of all who posted, only you seem to understand
> the problem set sufficiently to provide useful advice).

The important thing is anyone who wants to can. You don't have to rely
on someone you don't trust. You can trust who you want and if you trust
nobody you can check by yourself. Even if you trust someone, you can
check by yourself. On Linux, you have the developer who do what he want,
and then you have the package maintainers. So, you have people who knows
their jobs to take care of it.

> Does Linux have that yet?
> o If not, perhaps it should. :)

There is no reason to limit something insensitive.

> However, the point of this thread is _only_ about the clipboard.
> o Specifically Linux protection akin to what we now see on Android & iOS.

Yes, but you seam overtly concerned about it. For me, in the clipboard,
you put only information you choose. If have put a keylogger, you have
every information you type on your keyboard for example. If you cant do
anything better, it's good for a spy to access your clipboard, but it
should be his last ressort.

> In summary, most people feel it's only a problem on iOS and Android, and
> not, necessarily, on Linux,

If I know what a clipboard is, I agree with them.

> where, if that's indeed the case, the good news is that clearly both
> iOS and Android are doing something about the problem.

If their clipboards aren't limited to the copy information, I'd say,
they really should improve faster.

Stéphane CARPENTIER

unread,

Jul 7, 2020, 7:46:54 AM7/7/20

to

Le 06-07-2020, David W. Hodgins <dwho...@nomail.afraid.org> a écrit :
> On Mon, 06 Jul 2020 07:03:48 -0400, Stéphane CARPENTIER
> <s...@fiat-linux.fr> wrote:
>
>> Really, qubes OS is the exception. If you let the application getting
>> access to your clipboard, the application would have issue to
>> exporting the information. Except for this, I fully agree.
>
> Not really that different. All qubes os does is separate applications
> into different virtual machines based on how the user configures it.
>
> Two applications running in the same virtual machine still have access
> to the same clipboard.

Yes, if the user put everything in the same VM, he has no more security
than with any other OS. But qubes OS helps him to get different
applications in different VM.

> With any os, the user must learn how to keep their data reasonably secure,
> based on their threat level.

Yes, there is no way to stop a user to send sensitive information
because he doesn't understand what he's doing. The purpose of qubes OS
is to help the user not to replace his brain.

> The more secure a system is, the harder it is to use properly.

Yes, it's what I said, nobody is using qubes OS without purpose. And
nobody would want to limit the access to the clipboard which purpose is
to help application sharing information.

> That's why the very insecure microsoft software is still so common.

The first time I heard a Windows review saying at least the security has
improved, a few time after, everybody said to deactivate the security to
be able to use it.

Carlos E.R.

unread,

Jul 7, 2020, 7:52:08 AM7/7/20

to

On 07/07/2020 13.37, Stéphane CARPENTIER wrote:
> Le 07-07-2020, Arlen Holder <arlen...@newmachine.com> a écrit :

>> o *No more stealing passwords*
>> "The Android Q 10 build includes new permission called
>> READ_CLIPBOARD_IN_BACKGROUND. As the name suggests, the new
>> permission will hamper random background apps from accessing the
>> clipboard content. Above all, apps would be asked to get a
>> signature from the OEM.
>> <https://fossbytes.com/best-android-10-features/>
>
> Why do you put your password on you clipboard ? There is better ways
> than that. Either you know your password or you put it in a serious
> password manager. Putting your password in your clipboard is bad.

Password managers, like KeepPass in Linux, do it. You hit a key on the
manager, password goes to clipboard, you go to the application and paste
it. By default the password is automatically deleted after a few seconds.

But, we still do not know of any Linux application that steals data from
the clipboard.

--
Cheers, Carlos.

J.O. Aho

unread,

Jul 7, 2020, 7:58:51 AM7/7/20

to

Limiting it access to the system will keep it more in the dark about
your system and less capable to affect your system too.

--

//Aho

Arlen Holder

unread,

Jul 7, 2020, 1:28:12 PM7/7/20

to

On 07 Jul 2020 11:37:03 GMT, Stéphane CARPENTIER wrote:

> The MAC address randomisation is only useful when you move without VPN.

Hi Stephane,

<warning: details follow, where I address all your stated concerns, I hope>

It's a pleasure discussing this with you since, unlike most who posted, you
can handle details (as can I). Most simply think the entire thread is no
more detailed than the Subject line (which is why they repeatedly and
endlessly told us what everyone knew since the dawn of computers, for
example - which simply wasted more than half this thread on their lack of
ability to comprehend what the thread topic was actually about).

Agreed on VPN...

You maybe don't remember how many threads Marek Novotny and I had which
created scripts (almost exclusively by Marek, where I tested them for the
team) improving the geolocated randomization of six thousand VPN servers in
the past on this newsgroup.

If you want, I can dig up a few representative a.o.l threads where we
tested to death killswitches, VPN geolocation scripts, & VPN randomization
years ago, where my point is that randomization of everything is useful,
e.g., I even randomize my (Windows) system timezone, as shown in this post:
o Script to randomize the system timezone to help foil fingerprinting
<https://groups.google.com/d/msg/alt.msdos.batch/0EE2VwfKwYc/fjh7tvLpAAAJ>

>> It seems the mobile devices are ahead of Linux, on these defaults.
>
> Because it's pointless on desktop, and pointless on laptop if you use
> your phone as a wifi source. So, Linux can put it in place easily, but
> there is no real need by default outside mobile devices.

I don't disagree now that I know more about what the mobile devices are
doing, where, you may note I'm all over the Android & iOS newsgroups on how
to improve privacy (e.g., I've virtually eliminated Google-anything on my
Android devices, without needing to be rooted).

You can have full functionality on Android _without_ Google if you just
take some risks of deleting, disabling, and blocking Google's background
and system processes.

I have so many threads on this topic that pointing to just one would be
insufficient, but here's just one to give you the idea of the scope:
o *Does anyone know how the PHONE ties to CONTACTS tiies to SMS on Android 9 Pie?*
<https://groups.google.com/forum/#!topic/comp.mobile.android/EvXtsP9radE>

In that case, for example, I eliminate the default sqlite contacts db,.
which, I realize, almost nobody on the planet does, but they also don't
know what I know, which is that Google uploads that specific file without
you knowing it (most people can't fathom that concept, which is why they
don't do the things I do to get around that privacy hole in Android).

> Do you really believe it's an improvement to be required to read the log
> to be able to access the clipboard ?

No. No. No. :)

Nobody said that, nobody implied that, and nobody should infer that.

All I was saying was that Android, since Android 6, has had the capability
to deny read permission on an app-by-app basis, but it was a bitch (as you
noted).

What _is_ an improvement though, is that in iOS 14 and in Android 10
(reputedly), the user has app-by-app control that is _easy_ so that the
_user_ decides which apps have clipboard read permission.

I couldn't get it to work on Android 10 when I tried yesterday, but I
didn't try for more than a minute or two as I was in the middle of
researching it.

Luckily, on iOS 14 (currently in beta), the user is _notified_ whenever an
app accesses their clipboard, which is a boon to detection of which apps do
it (since some clearly have no business accessing the clipboard at all,
even less so constantly).

> OK, I'm French and maybe I don't know what a clipboard is. It's possible
> we don't speak of the same thing. For me, the clipboard is the thing used
> to copy/paste information between applications.
>
> If I'm wrong, I'd like an explanation.

I think on Apple they call it a "pasteboard" & "clipboard" concurrently:

o *Apple Suddenly Confirms Hidden Problem Impacting All iPhone, iPad Users*
<https://www.forbes.com/sites/zakdoffman/2020/06/23/apple-ios14-release-iphone-11-pro-update-ipad-upgrade-security>
"Apple should include a privacy setting, app by app, enabling or
disabling access to the _clipboard_. And, at the very least, it should
flash a notification on screen when an app does access the _clipboard_,
to prevent apps from exploiting the _pasteboard_, the researchers said
back in February, Apple must act!"

On Android, they mostly just call it a "clipboard", I think:
o *Limited access to clipboard data*
<https://developer.android.com/about/versions/10/privacy/changes>
"Unless your app is the default input method editor (IME) or is the app
that currently has focus, your app cannot access clipboard data on
Android 10 or higher."

It's important to realize the detail that it's the OPERATING SYTEM
developer who needs to act first, and only after the OS is fixed, can the
user have this privacy against malicious clipboard access.

It's also important to notice the detail that both Android & iOS developers
did act, and both implemented solutions in the operating system, which are
the kinds of things I was asking here, about Linux.

My key question was why is it desperately needed in mobile devices, but not
on desktop operating system, where the answer from most here is
(essentially) that there is simply no malicious code on the Linux operating
system - and there never will be malicious code on Linux ('cuz it's open
source). :)

[Yes, I know I'm taking it slightly out of context; but that's essentially
Peter's claim, for example.]

> If I'm right, I really don't understand what concerned you so much with
> the clipboard. It's not a keylogger. If you tell me that Android and iOS
> don't manage a real clipboard but are using the central logs for the
> purpose, there is a real concern. But they are not far in advance of
> Linux, they are garbage which needs fast improvement.

Thank you for asking as I think almost nobody on this thread understands
the problem set, where you clearly understood the most. Most think they
read the subject line and then they understand the problem set - but
EVERYTHING they post proves that they don't understand the issue.

So I thank you for saying that you're a bit confused, as we must be talking
about different things if you're confused about the danger, which I admit
must be my mistake that I didn't explain it well.

If you read why everyone is upset with Linked-In, Reddit, and TikTok, and
if you read the developers' statements that they will _remove_ the
clipboard reading, the problem is clearly stated in those references
(previously provided, but here's just one more to read to get the idea):
o *Apple iOS 14 Alerts Reveal Reddit App Is Reading User Clipboard Data*
<https://www.forbes.com/sites/daveywinder/2020/07/05/reddit-latest-to-get-caught-by-apple-ios-14-clipboard-data-copying-alerts-iphone-privacy/>

*The _simplest_ clarification I can give is that apps that have no*
*business in reading the clipboard, are constantly reading the clipboard.*

It's far worse than that, of course, but that's the gist of the problem
set.

The only reason Reddit, Linked-In, and TikTok (among others) are removing
the code is that they got caught.

The only reason they got caught (at least recently), was that iOS 14 beta
now tells the user whenever an app is reading their clipboard without their
knowledge, nor consent.

This thread was just to ask about this same problem set on Linux. :)

> Why do you put your password on you clipboard ? There is better ways
> than that. Either you know your password or you put it in a serious
> password manager. Putting your password in your clipboard is bad.

Hmmmmmmmm.... people do a lot of things that you and I might not do. On
Apple, for example, you can copy something on your Mac, which will show up
in the clipboard of your iPhone (apparently), which then the malicious apps
can vacuum up.

People cut and paste a _lot_ of things, where I think anyone who focuses
_just_ on passwords misses the point.

It's sort of like having a miscreant kid in the neighborhood who steals
people's packages left on their doorstep, one of which might be, oh, say,
electronics, and then asking why people allow electronics packages on their
doorstep.

The "password" part is just one kind of "package" that the miscreant
steals, where anyone who asks "why do people allow electronics packages to
be left on their doorstep" is missing the point, IMHO.

The point is that the miscreant is stealing the packages.

> From what I see it's more far behind. And for the restriction, it's as I
> said. You don't grant it the right at each need, which would be very
> difficult.

Usenet is a flat text-only communication so I think we agree for the most
part, where I think it goes this way in terms of sophistication:
1. iOS 14 beta seems to be best for notifying users & allowing control.
2. Android 10 seems to be ok for allowing control and inadequate for
notifying users.
3. Android 6 to 9 seems to be barely adequate for allowing control &
totally inadequate for notifying users
4. Linux/Windows seem to be stuck in the Stone Age in terms of notifying
users and allowing control.

The argument most posted, so far, for _why_ Linux doesn't do what the
latest iOS and Android do, is that Linux apps are never malicious, which,
if true, is good enough for me.

As the Spartans would say to "If Linux doesn't need it...", my reply is:
o If

> I don't know how Android and iOS are managing their clipboards, but
> unless I have not the same definition, only what you copy must be
> available in it. If the clipboard grant to access to anything else, it's
> bad, and I understand your concern. But in this case, their philosophy
> is garbage and they lack far behind Linux.

Again, I think we're just talking about different aspects of the clipboard.

Think about it in terms of a kid stealing packages left on people's
doorstep, who shouldn't be stealing those packages.

On Linux, in this thread, most people said there are no kids stealing those
packages, so you don't need anything to tell you that it's happening.

OK.

But on iOS, we _clearly_ know there _are_ kids stealing those packages
(e.g., Reddit, LinkedIn, TikTok, and about 50 others, to date).

And on Android, we clearly know that in Android 10, you have to explicitly
allow that kid to take that package off your doorstep.

Notice the problem is not that the package is on the doorstep (i.e., it's
not what you pasted into the clipboard or why you did it); the problem is
that the miscreant kid is stealing those packages off your doorstep, when
he has no right to do so.

These miscreant apps are reading your clipboard when they have no rational
reason to do so (and they _all_ admit it, although they try to explain it
away as a "bug").

The important point is that all apps caught to date stealing these packages
from your doorstep have instantly vowed to remove the miscreant code.

That tells you everything you need to know, right there. (IMHO)

> The important thing is anyone who wants to can.

Trust me Stephane, I _know_ all the platitudes on Open Source.

What irks me is when someone seriously suggests, in effect, _everyone_ who
cares about privacy must read all the open source code of all the open
source apps on their system.

It's just a ridiculous suggestion and as such, is patently unhelpful.

Most of the comments in this thread just wasted everyone's time, e.g., how
many freaking people claimed any app "can" read our clipboard? What the
heck did they think they were telling us? I can see someone mentioning it
once, but jesus christ, do you know how many times they said it?

45% of the posts in this thread were that kind of utter garbage, and 45% of
the posts from me were responding to that utter garbage.

It's utter garbage what was suggested (to read the source code).
o It just is.

Your point of view that people who know how to look for such things "can"
(and probably should and likely do) look at the source code is fine.

However, it's something we all knew decades ago, so it only needs to be
stated once and we can move on instead of rehashing it over and over and
over and over (and over) again.

> You don't have to rely
> on someone you don't trust. You can trust who you want and if you trust
> nobody you can check by yourself.

We do not need to rehash this.
o We all knew this decades ago.

It adds no value after the first time it's mentioned.
o Nobody disagrees.

It only has merit when/if someone claims _because_ it's open source, there
is no malicious (or accidental) code that reads the clipboard that doesn't
need to read the clipboard.

That's essentially what has been claimed by Peter, for example.
o Because it's open source, it's looked at, and no malicious code exists.

> Even if you trust someone, you can
> check by yourself. On Linux, you have the developer who do what he want,
> and then you have the package maintainers. So, you have people who knows
> their jobs to take care of it.

Understood. We do not need to rehash this over and over (and over) again.
o Because it's linux, if it's looked at, malicious code doesn't exist.

If

> Yes, but you seam overtly concerned about it.

Heh heh heh... I'm not in the _least_ worried about it.

Just like I'm not in the least worried that at the 2018 Battle of Khasham,
something like 200 or so of 500 Russian "soldiers" were massacred by we
Americans because they tried a simple "Banzai style" attack against 30
Americans who didn't need to fire a shot in response...

That simply happened.
o It doesn't worry me.

But I'm extremely _interested_ in _how_ that could possibly have happened,
where, Putin claimed that they were not Russian soldiers (despite lots of
now-childless Russian mothers & bereft Russian wives wailing in the weeks
afterward).

Notice it's the same type of "excuse" Putin is providing (i.e., Wagner is a
group of completely private mercenaries whom he has no control over) as
LinkedIn, Reddit, and TikTok provided (i.e., they claimed they were simply
bugs).

In both cases, adults know exactly what is going on.
o In both cases, I'm _interested_ in knowing what is going on.

But I'm not worried about it in either case.

It's the same with Macron & Putin in Libya just this week.
o I'm not at all worried that Libya is split into three factions, where
Macron supports one of the three, while Putin another, and Turkey yet the
third (greatly oversimplified).

Hence, what Macron claims about Putin is true, but what Macron claims about
what he's doing, is bullshit...

Just as what Putin claims about Macron is true, but what Putin claims about
what he's doing, is bullshit... (he's claiming the PMC did it, for example,
not him).

Notice I'm _interested_ but I'm not in the least concerned.
o All I want to know is what is really going on.

What is really going on isn't going to be resolved by platitudes.
o This thread is, unfortunately, 95% platitudes and 5% progress on
understanding the problems set.

> For me, in the clipboard,
> you put only information you choose. If have put a keylogger, you have
> every information you type on your keyboard for example. If you cant do
> anything better, it's good for a spy to access your clipboard, but it
> should be his last ressort.

That's not the problem.

The problem is akin to a miscreant kid in the neighborhood stealing
packages that people feel should be left alone on their doorstep.

If they were shipping enriched uranium, like that which was made at the
Natanz Nuclear Fuel Enrichment Facility that, just this weekend
mysteriously blew up (heh heh heh), they wouldn't be putting it on their
doorstep.

What we're talking about has nothing, per se, to do with passwords or
keyloggers at all. The Israelis are likely the "keylogger" here, who were
rather clever at planting a bomb _inside_ the super secure facility, and
they widely emailed journalists with well-prepared videos of their action
just moments (mere minutes) after it happened (at 2am Iranian time).

That's a keylogger you should be concerned about if you're an Iraqi bent on
nefarious nuclear hegemony.

All we're talking about here is simply that a miscreant kid in the
neighborhood is stealing, for no good reason, packages casually left on
people's doorsteps.

The point is that people have a right to have packages casually left on
their doorstep that they don't need to worry about a miscreant kid stealing
them.

So please understand that we're talking not about nuclear fuel (i.e.,
passwords) so much as ladies and men's underwear left on the doorstep,
where the point is that app developers have no business reading this
information when they have no business reading it.

The fact that miscreant kids were stealing the packages is the problem,
where now we know they're doing it (on iOS anyway), and their parents
immediately said they will have their miscreant kids stop it.

Same with the app developers (who are akin to the miscreant kid).

>
>> In summary, most people feel it's only a problem on iOS and Android, and
>> not, necessarily, on Linux,
>
> If I know what a clipboard is, I agree with them.

I understand your agreement, where my only reply is... "if".

>> where, if that's indeed the case, the good news is that clearly both
>> iOS and Android are doing something about the problem.
>
> If their clipboards aren't limited to the copy information, I'd say,
> they really should improve faster.

No. Their clipboards _are_ copy information.

The clipboard is analogous to the "doorstep" where packages are left.

It's good when people are aware that miscreant kids are stealing their
packages which are habitually casually left on their doorstep.

When the parents of the miscreant kids are publicly outed, as Reddit,
LinkedIn and TikTok were, those parents put a stop to it immediately.

My initial question was why wasn't this needed on Linux.
o The (simplified) answer was there are no miscreants coding on Linux.

I understand that point of view, where my key response is... "if".
--
It's a pleasure discussing a topic with someone who can understand it.

Arlen Holder

unread,

Jul 8, 2020, 10:09:59 AM7/8/20

to

On 06 Jul 2020 22:29:24 GMT, Stéphane CARPENTIER wrote:

> Yes. You are right, I changed a little bit the request of the PO without
> realising it. In fact, for me, the most important thing is not to stop
> an application accessing the clipboard but to stop an application
> accessing information not purposefully sent to it.

Along those lines of stopping those who don't need information about us
from accessing information about us, It seems, based on the experiences to
date on the comp.mobile.android Usenet ng, some Android 10 phones differ...
o Some have the Mac randomization for WiFi settings autoset to randomize
o Some need to have the default manually set to randomize
o And some, like mine, don't seem to have that setting at all

Here's what Google says about the HISTORY of Android MAC Randomization:
<https://source.android.com/devices/tech/connect/wifi-mac-randomization>
o Android 8.0 uses randomized MAC addresses when probing for new networks
(while not currently associated with a network)
o In Android 9, you can enable a developer option (disabled by default)
to cause the device to use a randomized MAC address when connecting
to a Wi-Fi network
o In Android 10, MAC randomization is enabled by default
(for client mode, SoftAp, and Wi-Fi Direct)

BTW, MAC randomization is just a single step in privacy, as this article
notes it's not a panacea that negates them tracking you by MAC address:
o *Coming to Android Q: MAC address randomization, new location data*
*permission popup, no more clipboard sniffing.*
<https://www.zdnet.com/article/android-q-to-get-a-ton-of-new-privacy-features/>
"Despite security researchers proving that they can still track devices
with randomized MAC addresses, supporting this feature will reduce the
efficiency of some data harvesting and user tracking operations."
o A study of MAC randomization in mobile devices & when it fails
<https://arxiv.org/pdf/1703.02874v1.pdf> (paper)
<https://arxiv.org/abs/1703.02874v1> (abstract)

Although we need to look at the _date_ on that paper, which is 2017:
o *MAC randomization: A massive failure that leaves iPhones, Android mobes open to tracking*
<https://www.theregister.com/2017/03/10/mac_address_randomization/>
"US Naval Academy researchers report that they were able to track
100 per cent of devices using randomization, regardless of manufacturer,
by exploiting a previously unknown flaw in the way existing wireless
chipsets handle low-level control frames."

"The researchers found that the overwhelming majority of Android devices
are not implementing the available randomization capabilities built into
the Android OS"
--
Well then, those of us on Android 8, to Android 10, let's implement it to
make it harder to be tracked by our unique MAC addresses.

Arlen Holder

unread,

Jul 11, 2020, 9:05:42 PM7/11/20

to

Update (based on threads posted today)...

This thread was posted by someone today of what we've discussed prior:
o *TikTok and 32 other iOS apps still snoop your sensitive clipboard data*
<https://groups.google.com/forum/#!topic/comp.mobile.android/6YRFPNiRTo0>

My global response, which ties the operating systems together, is below.

On Sat, 11 Jul 2020 21:57:29 -0000 (UTC), CrawdaddinCrawdad wrote:

> On background, a spokesperson said that TikTok
> for Android never implemented the anti-spam feature.

This has been reported & discussed in detail on each of these newsgroups.
o Interestingly, the same topic was considered different by each newsgroup!

iOS:
o *Even more iOS apps caught snooping clipboard contents ...*
<https://groups.google.com/forum/#!topic/misc.phone.mobile.iphone/IHVirXnbJF0>

Android:
o *What common specific Android apps are known to access the clipboard upon mere invocation & without your permission?*
<https://groups.google.com/forum/#!topic/comp.mobile.android/hdNb3BeYm44>

Windows:
o *Do any Windows freeware apps habitually access the private contents of the clipboard upon mere invocation of the app?*
<https://groups.google.com/forum/#!topic/alt.comp.freeware/AI5SiPSGyaE>

Linux:
o *What common specific Linux apps are known to access the clipboard upon mere invocation & without your permission?*
<https://groups.google.com/forum/#!topic/alt.os.linux/VmByXYAaJts>

For some reasons, it's only considered a big problem, on iOS.
o I'm not quite sure why, but you can read the threads for the detail.

Similar iOS Discussions:
o *Reddit caught red handed by iOS 14 copying the clipboard contents on iOS devices*
<https://groups.google.com/forum/#!topic/misc.phone.mobile.iphone/-gvgKjTALvI>

o *iOS 14: TikTok seems to have been caught abusing the clipboard in a quite extraordinary way.*
<https://groups.google.com/forum/#!topic/misc.phone.mobile.iphone/dRKgQG8jGo8>

o *iOS 14 - Linked-In app caught reading the user's clipboard in background (including from other sources)*
<https://groups.google.com/forum/#!topic/misc.phone.mobile.iphone/2VZ5a3QsvBc>

For whatever reason, the Android folks aren't as worried, where Android has
had the ability, since Android 6, to view & remove clipboard access on an
app-by-app basis:
o *Freeware "App Inspector" by Ubqsoft [free, no ads, GSF independent] lists installed apps & their "secret" permissions [apparently]*
<https://groups.google.com/forum/#!topic/comp.mobile.android/3MEPsDCDCSs>

And, where, in Android 10, you can set that clipboard access more easily:
o *Those on Android 10... is it worth upgrading from 9 to 10? What are the pitfalls you've experienced & the benefits?*
<https://groups.google.com/forum/#!topic/comp.mobile.android/X65cMyzAn-g>

In summary, note that each operating systems apparently handles this
clipboard access privacy/security hole quite differently:

A. iOS 14 tells you when it's happening & allows you to block it.
B. Android 6+ can block it; but doesn't tell you when it's happening.
C. Windows, as far as I can tell, has no protections or notification.
D. Linux is completely different - they claim no apps are malicious.

Go figure.
o If you don't believe (or understand) my summary, click on the threads.
--
Each operating system group considers the same problem differently.

bad sector

unread,

> If I may hazard a summary of why most people on a.o.l don't see this
> as an issue but the iOS users clearly see it not only as an issue, but
> as a privacy hole, and worse, as a potential criminal offense (we'll
> see how that court case makes it though the legal system in
> California) - I guess the reason Linux users don't see it as a problem
> is they _trust_ their distros to check for this particular "bug"
> (which is what every company caught to date has characterized it as).

They trust their distros and they have ways to control it, too. There is
a lot of tools available to look at what your distro is doing. A long
time ago, I saw Firefox sending information I don't remember where. I
disabled this functionality.