Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #9658 > unrolled thread

Automatic downloading of non-free software by stuff in main

Back to article view | Back to linux.debian.project

Contents

  Automatic downloading of non-free software by stuff in main Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-11-30 15:00 +0100
    Re: Automatic downloading of non-free software by stuff in main Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-12-01 15:00 +0100
      Re: Automatic downloading of non-free software by stuff in main Andrey Rahmatullin <wrar@debian.org> - 2017-12-01 16:30 +0100
        Re: Automatic downloading of non-free software by stuff in main Enrico Zini <enrico@enricozini.org> - 2017-12-01 16:40 +0100
          Re: Automatic downloading of non-free software by stuff in main Andrey Rahmatullin <wrar@debian.org> - 2017-12-01 17:20 +0100
            Re: Automatic downloading of non-free software by stuff in main Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-12-01 17:30 +0100
          Re: Automatic downloading of non-free software by stuff in main Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-12-01 17:20 +0100
        Re: Automatic downloading of non-free software by stuff in main "G. Branden Robinson" <g.branden.robinson@gmail.com> - 2017-12-01 19:10 +0100
      Re: Automatic downloading of non-free software by stuff in main Adam Borowski <kilobyte@angband.pl> - 2017-12-01 18:20 +0100
        Re: Automatic downloading of non-free software by stuff in main Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-12-01 18:30 +0100
        Re: Automatic downloading of non-free software by stuff in main "G. Branden Robinson" <g.branden.robinson@gmail.com> - 2017-12-01 19:10 +0100
          Re: Automatic downloading of non-free software by stuff in main Adam Borowski <kilobyte@angband.pl> - 2017-12-01 20:10 +0100
          Re: Automatic downloading of non-free software by stuff in main Tollef Fog Heen <tfheen@err.no> - 2017-12-03 12:10 +0100
    Re: Automatic downloading of non-free software by stuff in main "Dr. Bas Wijnen" <wijnen@debian.org> - 2017-12-03 09:00 +0100
    Re: Automatic downloading of non-free software by stuff in main Diane Trout <diane@ghic.org> - 2017-12-05 21:50 +0100
      Re: Automatic downloading of non-free software by stuff in main Andrey Rahmatullin <wrar@debian.org> - 2017-12-06 05:10 +0100
        Re: Automatic downloading of non-free software by stuff in main Ben Hutchings <ben@decadent.org.uk> - 2017-12-06 07:50 +0100
          Re: Automatic downloading of non-free software by stuff in main Henrique de Moraes Holschuh <hmh@debian.org> - 2017-12-07 00:40 +0100
            Re: Automatic downloading of non-free software by stuff in main Ben Hutchings <ben@decadent.org.uk> - 2017-12-07 01:10 +0100
              Re: Automatic downloading of non-free software by stuff in main Michael Stone <mstone@debian.org> - 2017-12-07 01:20 +0100
                Re: Automatic downloading of non-free software by stuff in main Ben Hutchings <ben@decadent.org.uk> - 2017-12-07 02:40 +0100
                  Re: Automatic downloading of non-free software by stuff in main Adam Borowski <kilobyte@angband.pl> - 2017-12-07 03:30 +0100
                    Re: Automatic downloading of non-free software by stuff in main Mike Hommey <mh@glandium.org> - 2017-12-07 04:20 +0100
                      Re: Automatic downloading of non-free software by stuff in main Andrey Rahmatullin <wrar@debian.org> - 2017-12-07 07:10 +0100
                      Re: Automatic downloading of non-free software by stuff in main Diane Trout <diane@ghic.org> - 2017-12-07 07:20 +0100
                    Re: Automatic downloading of non-free software by stuff in main Andrey Rahmatullin <wrar@debian.org> - 2017-12-07 14:00 +0100
                      Re: Automatic downloading of non-free software by stuff in main Holger Levsen <holger@layer-acht.org> - 2017-12-07 14:10 +0100
                        Re: Automatic downloading of non-free software by stuff in main Paul Wise <pabs@debian.org> - 2017-12-07 14:20 +0100
                        Re: Automatic downloading of non-free software by stuff in main "Paul R. Tagliamonte" <paultag@gmail.com> - 2017-12-07 14:40 +0100
                          Re: Automatic downloading of non-free software by stuff in main Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-12-07 15:00 +0100
                            Re: Automatic downloading of non-free software by stuff in main Holger Levsen <holger@layer-acht.org> - 2017-12-07 15:00 +0100
                              Re: Automatic downloading of non-free software by stuff in main Lars Wirzenius <liw@liw.fi> - 2017-12-07 15:50 +0100
                            Re: Automatic downloading of non-free software by stuff in main "Paul R. Tagliamonte" <paultag@gmail.com> - 2017-12-07 15:20 +0100
                              Re: Automatic downloading of non-free software by stuff in main Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-12-07 17:10 +0100
                                technical terms (Re: Automatic downloading of non-free software by  stuff in main) Holger Levsen <holger@layer-acht.org> - 2017-12-07 18:00 +0100
                                  technical terms (Re: Automatic downloading of non-free software by  stuff in main) Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-12-07 18:30 +0100
                                Re: Automatic downloading of non-free software by stuff in main Jonas Smedegaard <dr@jones.dk> - 2017-12-07 18:30 +0100
                                Re: Automatic downloading of non-free software by stuff in main "Paul R. Tagliamonte" <paultag@gmail.com> - 2017-12-07 18:40 +0100
                                  Re: Automatic downloading of non-free software by stuff in main Diane Trout <diane@ghic.org> - 2017-12-07 19:40 +0100
                                  Re: Automatic downloading of non-free software by stuff in main Adam Borowski <kilobyte@angband.pl> - 2017-12-07 22:10 +0100
                                    Re: Automatic downloading of non-free software by stuff in main Diane Trout <diane@ghic.org> - 2017-12-07 23:00 +0100
                                    Re: Automatic downloading of non-free software by stuff in main "Paul R. Tagliamonte" <paultag@gmail.com> - 2017-12-07 23:10 +0100
                          Re: Automatic downloading of non-free software by stuff in main gregor herrmann <gregoa@debian.org> - 2017-12-07 19:30 +0100
                            Re: Automatic downloading of non-free software by stuff in main Diane Trout <diane@ghic.org> - 2017-12-07 20:10 +0100
                              Re: Automatic downloading of non-free software by stuff in main Andrey Rahmatullin <wrar@debian.org> - 2017-12-07 20:30 +0100
                                Re: Automatic downloading of non-free software by stuff in main Diane Trout <diane@ghic.org> - 2017-12-07 21:10 +0100
                    Re: Automatic downloading of non-free software by stuff in main Holger Levsen <holger@layer-acht.org> - 2017-12-07 14:00 +0100
      Automatically marking downloaded files (was Re: Automatic downloading  of non-free software by stuff in main) Anthony DeRobertis <anthony@derobert.net> - 2017-12-06 06:30 +0100
        Re: Automatically marking downloaded files (was Re: Automatic downloading of non-free software by stuff in main) Stuart Prescott <stuart@debian.org> - 2017-12-07 02:40 +0100
          Re: Automatically marking downloaded files (was Re: Automatic downloading of non-free software by stuff in main) Ian Jackson <ijackson@chiark.greenend.org.uk> - 2017-12-07 15:00 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#9681

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2017-12-06 at 19:14 -0500, Michael Stone wrote:
> On Thu, Dec 07, 2017 at 12:09:22AM +0000, Ben Hutchings wrote:
> > That's only because it lives in mm/shmem.c, not under fs/.  It does
> > support xattrs.
> 
> Have you tried it?

Ah, damnit.  It supports *some* xattrs (like the security namespace),
but apparently not *user* xattrs.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein

[toc] | [prev] | [next] | [standalone]

#9682

On Thu, Dec 07, 2017 at 01:33:41AM +0000, Ben Hutchings wrote:
> On Wed, 2017-12-06 at 19:14 -0500, Michael Stone wrote:
> > On Thu, Dec 07, 2017 at 12:09:22AM +0000, Ben Hutchings wrote:
> > > That's only because it lives in mm/shmem.c, not under fs/.  It does
> > > support xattrs.
> > 
> > Have you tried it?
> 
> Ah, damnit.  It supports *some* xattrs (like the security namespace),
> but apparently not *user* xattrs.

Good.  While xattrs have some uses, this is a hidden privacy hole most users
aren't aware of (although /tmp/ is the filesystem least likely to be used
forensically against you).

Looks like the only filesystems that allow disabling it via a mount option
(nouser_xattr) are ext* and reiserfs, some more can do it via recompiling
the kernel although this kills all xattrs, not just the user: namespace;
most of these config options say "If unsure, say N." (other than CIFS, which
is also the filesystem where your files are most likely to be readable by
others) -- but they're all enabled in Debian kernels.

[~]$ task add "patch btrfs for mount -o nouser_xattr"


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 14:13 < icenowy[m]> are they hot enough? ;-)
⣾⠁⢰⠒⠀⣿⡁ 14:17 < icenowy[m]> I think now in Europe it should be winter? Let
⢿⡄⠘⠷⠚⠋⠀                     the BPi warm you ;-)
⠈⠳⣄⠀⠀⠀⠀ 14:17 <@KotCzarny> yeah, i have a pc to warm me ;)

[toc] | [prev] | [next] | [standalone]

#9683

On Thu, Dec 07, 2017 at 03:27:42AM +0100, Adam Borowski wrote:
> On Thu, Dec 07, 2017 at 01:33:41AM +0000, Ben Hutchings wrote:
> > On Wed, 2017-12-06 at 19:14 -0500, Michael Stone wrote:
> > > On Thu, Dec 07, 2017 at 12:09:22AM +0000, Ben Hutchings wrote:
> > > > That's only because it lives in mm/shmem.c, not under fs/.  It does
> > > > support xattrs.
> > > 
> > > Have you tried it?
> > 
> > Ah, damnit.  It supports *some* xattrs (like the security namespace),
> > but apparently not *user* xattrs.
> 
> Good.  While xattrs have some uses, this is a hidden privacy hole most users
> aren't aware of (although /tmp/ is the filesystem least likely to be used
> forensically against you).

Which makes the XDG thing borderline, since the only indicator that a file
has been downloaded they propose is the full url, not a boolean.

Mike

[toc] | [prev] | [next] | [standalone]

#9684

[Multipart message — attachments visible in raw view] — view raw

On Thu, Dec 07, 2017 at 11:53:50AM +0900, Mike Hommey wrote:
> > Good.  While xattrs have some uses, this is a hidden privacy hole most users
> > aren't aware of (although /tmp/ is the filesystem least likely to be used
> > forensically against you).
> 
> Which makes the XDG thing borderline, since the only indicator that a file
> has been downloaded they propose is the full url, not a boolean.
Yup. Like OS X and unlike Windows.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#9685

> Which makes the XDG thing borderline, since the only indicator that a
> file
> has been downloaded they propose is the full url, not a boolean.

But having the URL is useful.

I would love to know where some terribly named file was downloaded
from. (This is at least a fairly common problem in science)

This would also be helpful for after the fact scans if an intrusion
detection system discovered a site is hostile

Shouldn't the url xattr be hidden if you're using an encrypted file
system?

What about just making it more obvious that a file has extended
attributes? One of the problems with location data in images is many
people didn't even know it was being captured.

Could there be an color or flag for ls? and could nautilus & dolphin
have some indicator?

Diane

[toc] | [prev] | [next] | [standalone]

#9687

[Multipart message — attachments visible in raw view] — view raw

On Thu, Dec 07, 2017 at 12:50:06PM +0000, Holger Levsen wrote:
> > > Ah, damnit.  It supports *some* xattrs (like the security namespace),
> > > but apparently not *user* xattrs.
> > Good.  While xattrs have some uses, this is a hidden privacy hole most users
> > aren't aware of 
> 
> could you be so kind to explain that hidden hole? that would maybe help
> with more people being aware…
When you download a file, its original location is saved and can be
retrieved.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#9689

[Multipart message — attachments visible in raw view] — view raw

On Thu, Dec 07, 2017 at 05:58:31PM +0500, Andrey Rahmatullin wrote:
> On Thu, Dec 07, 2017 at 12:50:06PM +0000, Holger Levsen wrote:
> > > > Ah, damnit.  It supports *some* xattrs (like the security namespace),
> > > > but apparently not *user* xattrs.
> > > Good.  While xattrs have some uses, this is a hidden privacy hole most users
> > > aren't aware of 
> > 
> > could you be so kind to explain that hidden hole? that would maybe help
> > with more people being aware…
> When you download a file, its original location is saved and can be
> retrieved.

ah, so it's a privacy hole in certain tools, but not in xattr.

how about filing bugs for those issues then?


-- 
cheers,
	Holger

[toc] | [prev] | [next] | [standalone]

#9690

On Thu, Dec 7, 2017 at 9:09 PM, Holger Levsen wrote:

> ah, so it's a privacy hole in certain tools, but not in xattr.

Is it any more of a privacy hole than ~/.bash_history?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#9692

[Multipart message — attachments visible in raw view] — view raw

I hilariously discovered this last night as well (playing with IMA), and
removing the creation of that attr would be a huge step back.

Restricting the execution of files one downloads or disabling macros on
word documents you download and open would be a huge security win.

These attributes are destroyed by merely coping the file, and are on the
filesystem, not the file. It's not like sending a file via email leaks
where I downloaded it from.

For most users, this attribute, if we start actually using it, would
massively protect, not hurt their security.

Paul



On Dec 7, 2017 8:09 AM, "Holger Levsen" <holger@layer-acht.org> wrote:

> On Thu, Dec 07, 2017 at 05:58:31PM +0500, Andrey Rahmatullin wrote:
> > On Thu, Dec 07, 2017 at 12:50:06PM +0000, Holger Levsen wrote:
> > > > > Ah, damnit.  It supports *some* xattrs (like the security
> namespace),
> > > > > but apparently not *user* xattrs.
> > > > Good.  While xattrs have some uses, this is a hidden privacy hole
> most users
> > > > aren't aware of
> > >
> > > could you be so kind to explain that hidden hole? that would maybe help
> > > with more people being aware…
> > When you download a file, its original location is saved and can be
> > retrieved.
>
> ah, so it's a privacy hole in certain tools, but not in xattr.
>
> how about filing bugs for those issues then?
>
>
> --
> cheers,
>         Holger
>

[toc] | [prev] | [next] | [standalone]

#9693

Paul R. Tagliamonte writes ("Re: Automatic downloading of non-free software by stuff in main"):
> I hilariously discovered this last night as well (playing with IMA), and
> removing the creation of that attr would be a huge step back.
> 
> Restricting the execution of files one downloads or disabling macros on word
> documents you download and open would be a huge security win.
> 
> These attributes are destroyed by merely coping the file, and are on
> the filesystem, not the file. It's not like sending a file via email
> leaks where I downloaded it from.

So if I use a browser in porn mode to download a file, and when I
close the browser the browser's record of the url where I got it is
deleted, but the url is saved in a hidden thing attached to the file.
Surely that is undesirable ?

And that's what happens if the browser implements this feature.  If
the browser doesn't implement it (or suppresses it for porn mode
downloads), then I am vulnerable to the obvious clickbait attacks.

Furthermore, this "file is dangerous" attribute ought to be copied
much more.  There are surely situations where that it is not copied
into copies of the file is a problem.

And, files can be dangerous if they came from emails, or file transfer
clients, as well as if they came from web pages.  Some of these
sources might not have sensible URLs (and saving a dummy URL seems
wrong).

Finally, if a user thinks it useful to know where a file came from - I
can definitely see that this might be good (although personally I
think it should be disabled by default) - they might well want to do
that _and_ also mark the file as trusted for execution.  That way if
they hear that the file is out of date they don't have to trust a
general search engine and re-navigate to the same url.

And, the privacy concerns mean that browser authors will properly
resist implementing it or enabling it by default.

It seems to me therefore that this XDG url saving attribute is not the
right shape to be reused as a boolean "file was downloaded from the
internet and might be dangerous" flag.

Ian.

[toc] | [prev] | [next] | [standalone]

#9694

[Multipart message — attachments visible in raw view] — view raw

On Thu, Dec 07, 2017 at 01:52:07PM +0000, Ian Jackson wrote:
> Furthermore, this "file is dangerous" attribute ought to be copied
> much more.

no, it ought to be the default. all files should be considered harmful,
unless tagged otherwise.

> It seems to me therefore that this XDG url saving attribute is not the
> right shape to be reused as a boolean "file was downloaded from the
> internet and might be dangerous" flag.

if the semantics were inverted, maybe.


-- 
cheers,
	Holger

[toc] | [prev] | [next] | [standalone]

#9697

On Thu, Dec 07, 2017 at 01:59:16PM +0000, Holger Levsen wrote:
> On Thu, Dec 07, 2017 at 01:52:07PM +0000, Ian Jackson wrote:
> > Furthermore, this "file is dangerous" attribute ought to be copied
> > much more.
> 
> no, it ought to be the default. all files should be considered harmful,
> unless tagged otherwise.

All files _should_ be considered potentially harmful. Even if tagged
safe. A previously-safe file might become harmful because it happens
to trigger a newly found security bug. Possibly a newly found security
bug that did not exist when the file was tagged safe.

In my opinion, tagging files safe or harmful is not a winning
strategy. I don't think it gives enough benefit to be worth it, and it
doesn't seem to me it actually protects our users very much. An xattrs
tag, in particular, gets lost so very easily, and having it applied
inconsistently means there's a lot of ways in which any protection
based on such a tag gets accidentally or intentionally circumvented.
If we have a "this is safe" tag, instead of "this may be harmful",
then that's also going to get lost often, leading to users getting
annoyed by unintended security warnings all the time.

Obviously it's possible to handle this by treating it as a by every
time a file is copied without its xattr flag. But even from limited
experience, that's going to be a very large number of bugs. If my
security depends on all programs individually doing all the right
things, I won't be feeling very secure.

I don't have a good solution, but I suspect something like QubesOS may
be the way forward. In other worse, isolate all processes into
containers (or virtual machines) of some sort and arrange it so that
this doesn't become too cumbersome to the user. (Disclaimer: I haven't
had time to actually try QubesOS myself, yet.)

The advantage of that approach is that the security gets centralised
into fewer system components. It's less important that, say, Firefox
is secure, if it can't be exploited to do bad things, if the container
stops Firefox from deleting or modifying local files, or making
unexpected network connections, or using too much RAM or CPU or other
local resources. (I'm describing an ideal here, not the state of
current technology.)

-- 
I want to build worthwhile things that might last. --joeyh

[toc] | [prev] | [next] | [standalone]

#9696

[Multipart message — attachments visible in raw view] — view raw

On Dec 7, 2017 8:52 AM, "Ian Jackson" <ijackson@chiark.greenend.org.uk>
wrote:

Paul R. Tagliamonte writes ("Re: Automatic downloading of non-free software
by stuff in main"):
> I hilariously discovered this last night as well (playing with IMA), and
> removing the creation of that attr would be a huge step back.
>
> Restricting the execution of files one downloads or disabling macros on
word
> documents you download and open would be a huge security win.
>
> These attributes are destroyed by merely coping the file, and are on
> the filesystem, not the file. It's not like sending a file via email
> leaks where I downloaded it from.

So if I use a browser in porn mode to download a file, and when I
close the browser the browser's record of the url where I got it is
deleted, but the url is saved in a hidden thing attached to the file.
Surely that is undesirable ?

And that's what happens if the browser implements this feature.  If
the browser doesn't implement it (or suppresses it for porn mode
downloads), then I am vulnerable to the obvious clickbait attacks.

Furthermore, this "file is dangerous" attribute ought to be copied
much more.  There are surely situations where that it is not copied
into copies of the file is a problem.

And, files can be dangerous if they came from emails, or file transfer
clients, as well as if they came from web pages.  Some of these
sources might not have sensible URLs (and saving a dummy URL seems
wrong).

Finally, if a user thinks it useful to know where a file came from - I
can definitely see that this might be good (although personally I
think it should be disabled by default) - they might well want to do
that _and_ also mark the file as trusted for execution.  That way if
they hear that the file is out of date they don't have to trust a
general search engine and re-navigate to the same url.

And, the privacy concerns mean that browser authors will properly
resist implementing it or enabling it by default.


I claim if you can read this attribute, you can observe the rest of those
actions passively.

Even putting a dummy value for incognito mode (a fake uri with a random
hash) would be fine, but I'm pretty OK with the current model. It makes my
time better spent doing forensics after I'm worried.

"Sticky" xattrs would be cool too, but alas, with imperfect primitives we
have an imperfect system.


It seems to me therefore that this XDG url saving attribute is not the
right shape to be reused as a boolean "file was downloaded from the
internet and might be dangerous" flag.

Ian.

[toc] | [prev] | [next] | [standalone]

#9698

Paul R. Tagliamonte writes ("Re: Automatic downloading of non-free software by stuff in main"):
> I claim if you can read this attribute, you can observe the rest of those
> actions passively. 

So the secret police who have seized my computer, or my spouse who
suspects me of looking at the "wrong" sort of websites (but doesn't
want to risk installing spyware), or my employer who has suspended me
because they to fire me unjustifiably and is now searching my
computer, can easily get into their time machine and go back and make
the computer tell them what I did last week ?

No.

(Your logic would argue that browser porn mode is basically
pointless.)

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

[toc] | [prev] | [next] | [standalone]

#9699 — technical terms (Re: Automatic downloading of non-free software by stuff in main)

[Multipart message — attachments visible in raw view] — view raw

On Thu, Dec 07, 2017 at 04:06:43PM +0000, Ian Jackson wrote:
> (Your logic would argue that browser porn mode is basically
> pointless.)
 
I didnt get what you ment originally, but after the 3rd mail using these
words I realized you ment "privacy mode".

I dont understand why you are using demeaning words for "privacy mode".
Are you suggesting privacy=porn? I dont think so, so please use the
proper words.

Thanks.


-- 
cheers,
	Holger

[toc] | [prev] | [next] | [standalone]

#9701 — technical terms (Re: Automatic downloading of non-free software by stuff in main)

Holger Levsen writes ("technical terms (Re: Automatic downloading of non-free software by stuff in main)"):
> On Thu, Dec 07, 2017 at 04:06:43PM +0000, Ian Jackson wrote:
> > (Your logic would argue that browser porn mode is basically
> > pointless.)
>  
> I didnt get what you ment originally, but after the 3rd mail using these
> words I realized you ment "privacy mode".
> 
> I dont understand why you are using demeaning words for "privacy mode".
> Are you suggesting privacy=porn? I dont think so, so please use the
> proper words.

If you think "porn mode" is demeaning, I'm happy to call it "privacy
mode" instead.  I don't think "porn mode" is demeaning; it's just what
my real-life social calls it.

Ian.
(who does a lot of hir browsing in privacy mode.)

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

[toc] | [prev] | [next] | [standalone]

#9700

[Multipart message — attachments visible in raw view] — view raw

Quoting Ian Jackson (2017-12-07 17:06:43)
> Paul R. Tagliamonte writes ("Re: Automatic downloading of non-free software by stuff in main"):
>> I claim if you can read this attribute, you can observe the rest of 
>> those actions passively.
>
> So the secret police who have seized my computer, or my spouse who 
> suspects me of looking at the "wrong" sort of websites (but doesn't 
> want to risk installing spyware), or my employer who has suspended me 
> because they to fire me unjustifiably and is now searching my 
> computer, can easily get into their time machine and go back and make 
> the computer tell them what I did last week ?
> 
> No.
> 
> (Your logic would argue that browser porn mode is basically 
> pointless.)

Your "porn mode" browser plugin would tell your browser to pass a 
redacted URL to the filesystem.  Your enemies would then know only that 
you redacted something.

If you want to hide that as well, you will need to replace your 
"porn-mode" browser plugin with a "porn-and-stealth-mode plugin which 
instead of simple redaction spews Facebook URLs instead.

(and you need also need to buy a faster laptop to keep up with the 
CPU-hungry reasoning engine used to pick Facebook URLs adequately 
non-random yet not themselves revealing - whatever that means...)

If you want to save power and money, then go deep into the config 
options for your pron-mode plugin and enable "I trust everything on the 
Internet and want to treat all downloaded files as local when in porn 
mode".


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#9702

On Thu, Dec 7, 2017 at 11:06 AM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> Paul R. Tagliamonte writes ("Re: Automatic downloading of non-free software by stuff in main"):
>> I claim if you can read this attribute, you can observe the rest of those
>> actions passively.
>
> So the secret police who have seized my computer, or my spouse who
> suspects me of looking at the "wrong" sort of websites (but doesn't
> want to risk installing spyware), or my employer who has suspended me
> because they to fire me unjustifiably and is now searching my
> computer, can easily get into their time machine and go back and make
> the computer tell them what I did last week ?
>
> No.

If the Secret Police has seized your computer, has physical access to
your machine and the decryption passphrase for your system, I don't
think there's any website that you visited that would be more
incriminating than the rest of the drive.

> (Your logic would argue that browser porn mode is basically
> pointless.)

In a word of network taps, and a world where if I had a program
running on your computer without you knowing, yes, it is actually
literally useless. All it does it avoid storing data into your profile
or sending data the browser has about you, kinda. Not even that well,
just mostly well enough. It's not a security or privacy measure.

It does not make you safe. It doesn't avoid a network tap. Your
browser will still send an SNI before you handshake, and the Server's
Certificate, and your Client Certificate before the handshake is done.

The URL where you got a file is not nearly as privacy violating as the
file itself to the secret police. If you can read the attr, you can
read the file.


The pros vastly outweighs the speculitive cons on this, it's literally
just a tag that's stored on the filesystem. If you can read the tag,
you can read the file. If you store porn that's readable by others,
it's not a shock that you go to porn websites. If you have an
overthrow the government file, it's not really that big of a deal
where you got it from. Chances are they'd be more interested in the
file.

>
> Ian.
>
> --
> Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.
>
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.



-- 
:wq

[toc] | [prev] | [next] | [standalone]

#9704

[Multipart message — attachments visible in raw view] — view raw

> The pros vastly outweighs the speculitive cons on this, it's
> literally
> just a tag that's stored on the filesystem. If you can read the tag,
> you can read the file. If you store porn that's readable by others,
> it's not a shock that you go to porn websites. If you have an
> overthrow the government file, it's not really that big of a deal
> where you got it from. Chances are they'd be more interested in the
> file.

I agree.

If the contents of the file are taboo, you need to protect the file.

One obvious thing is a browser in incognito mode shouldn't be saving
real data for the attribute. Though then I'd like to be able to disable
incognito mode when in a managed computing environment.

(Users accounts are regularly compromised, and so I have to assume some
fraction of my users' accounts are actually controlled by hostile
entities)

Diane

[toc] | [prev] | [next] | [standalone]

#9708

On Thu, Dec 07, 2017 at 12:17:10PM -0500, Paul R. Tagliamonte wrote:
> If the Secret Police has seized your computer, has physical access to
> your machine and the decryption passphrase for your system, I don't
> think there's any website that you visited that would be more
> incriminating than the rest of the drive.

Some of us do take steps to be aware of potentially sensitive data on our
disks.  While for anything really dangerous you'd have an in-memory livecd,
that's quite a hassle for everyday use, thus most of us don't go into
paranoia and at most know how to wipe histories.

This can be somewhat tricky as you have quasi-logs stored around, such as
~/.cache/thumbnails (timestamped!), but at least these are files that are
reasonable for an average person to find.

Smuggling this data in xattrs on the other hand?  Even for those of us who
mess with filesystem development and who are aware of caps (xattr -l
/bin/ping) and thus rsync -X, it's surprising news.  And usual tools shipped
by current Debian don't mark the presence of such hidden data, nor do we
install any xattrs aware tool by default.  Now take an average somewhat
technical user... no way to find this.


But, I see you're dismissing possible harm as "theoretical".  While I don't
have real-life examples of bad xattrs yet, here's two related cases that
happened to me, personally -- without bad consequences as both were on a
desktop that doesn't leave my home, but it's obvious what would happen if
the data was read by a bad guy, especially likely on an USB stick, laptop or
phone that you travel past a border with.

* upgrading to gnupg2 left a copy of my private key in ~/.gnupg/secring.gpg,
  despite me explicitly deleting it, and asking gpg to --list-secret-keys
  doesn't reveal that this "backup just in case you might want to downgrade"
  is still on the disk.

* a sysadmin whom I have helped before asked me for help interpreting mail
  headers and some advice wrt something that happened at his company (I
  never had any relation with that company).  Instead of sending a tarball,
  he copied the mails to a temporary IMAP account, to which I connected with
  Thunderbird.  I've viewed a couple of the mails and promptly deleted the
  account.  Yet Thunderbird not only downloads the entirety of data for
  offline use (this is kind of known), but also leaves data for deleted
  accounts on the disk, without any indication it's there (unless you dig
  into the profile's directory by hand).  I found out these files are there
  only many years later.  The mails included stuff that's illegal to
  distribute, and would clearly land the guy in jail, and possibly me as
  well.  Semi-accidentally distributing them was a lapse of judgement on his
  part, but per the Dissident Test, I would really appreciate if software
  did not put its user in danger after the human error is noticed and
  (seemingly) rectified.

> > (Your logic would argue that browser porn mode is basically
> > pointless.)
> 
> In a word of network taps, and a world where if I had a program
> running on your computer without you knowing, yes, it is actually
> literally useless.

You probably noticed all the outrage against backdoors in Intel ME and AMD
PSP.  You might also want an operating system with open auditable code.

> All it does it avoid storing data into your profile
> or sending data the browser has about you, kinda. Not even that well,
> just mostly well enough. It's not a security or privacy measure.

I don't even use the "incognito mode", it's indeed nearly useless.  It
doesn't even block third-party trackers, block most means of fingerpriting,
etc.  You're much better off with a hand-crafted browser profile.  Then,
there's Tor, which is no magic bullet, but is a pretty powerful tool.

> It does not make you safe. It doesn't avoid a network tap. Your
> browser will still send an SNI before you handshake, and the Server's
> Certificate, and your Client Certificate before the handshake is done.

No need to even bother eavesdropping on SNI, browsers and most programs send
a DNS query even for a domain you accessed a minute ago.  Usually, this goes
only over your ISP and the network path to an authoritative nameserver in
the vicinity of the target server, but in some configurations it gets send
to world's second most nosy company (with an enormous infrastructure for
cross-matching such data!); despite that resolver being supposed to be
anycasted, on at least one occassion I noticed it going to the US (the
world's most nosy government (geoip-ing the AS doesn't work but you can look
at traceroute).  Even worse, if you use systemd-resolvd, any transient
failure will silently use 8.8.8.8 for queries (#761658, wontfixed closed). 
Gee, guess how this goes if you're working for a company or country that the
US finds "interesting".
 
> The URL where you got a file is not nearly as privacy violating as the
> file itself to the secret police. If you can read the attr, you can
> read the file.

In #883746 I pointed out an image that's harmless on its own, but can be
used for nasty purposes when a personal identifier is accessible.

Or, what if the URL contains login details?  Or the referer points to a
secret forum?

> The pros vastly outweighs the speculitive cons on this

I might be inattentive, but I did not notice a single pro mentioned on
this thread.  The only part, Windows-like "you downloaded this file from the
Internet, it may be bad" popup, can be done with a boolean, and is still a
dubious idea.

>,it's literally
> just a tag that's stored on the filesystem. If you can read the tag,
> you can read the file. If you store porn that's readable by others,
> it's not a shock that you go to porn websites. If you have an
> overthrow the government file, it's not really that big of a deal
> where you got it from. Chances are they'd be more interested in the
> file.

I guess you haven't read news about leaks happening once in a short while? 
It seems as if in most cases the govt is interested mostly not in what was
leaked, but in who leaked it, so they can make an example of the
whistleblower.

And, in recent cases that data came on USB sticks, which, unless formatted
with FAT, preserve xattrs.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 14:13 < icenowy[m]> are they hot enough? ;-)
⣾⠁⢰⠒⠀⣿⡁ 14:17 < icenowy[m]> I think now in Europe it should be winter? Let
⢿⡄⠘⠷⠚⠋⠀                     the BPi warm you ;-)
⠈⠳⣄⠀⠀⠀⠀ 14:17 <@KotCzarny> yeah, i have a pc to warm me ;)

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.project

csiph-web