Re: Privacy guarantees

2021-09-12 Thread Jeroen Dekkers
On Sat, 11 Sep 2021 08:18:16 +0200,
Paul Wise wrote:
> 
> On Fri, Sep 10, 2021 at 2:44 PM Felix Lechner wrote:
> 
> > Would this esteemed group please advise if the topic is in some form
> > suitable for a General Resolution?
> 
> I'm not sure a GR is the appropriate mechanism to fix privacy issues
> in Debian, instead I would encourage interested folks to form a group
> focused on detecting, fixing and mitigating these issues. See the work
> of the Reproducible Builds folks for an example how such a group can
> move Free Software forward on a particular issue.

The discussion in the lintain bug is about whether these issues need
to be fixed at all (and thus what the lintain severity should be).
Creating a group focused solely on fixing the issues won't resolve
that discussion. My guess is that there is a majority in the project
that thinks these issues are worth fixing and my personal expectation
was actually also that Debian does this, but there actually isn't any
policy saying this!

I think we should actually work on creating such a policy and as far
as I can see a GR would then be an appropriate mechanism to make it
official. Although my time is limited, I'd like to help with this.

So I'd like to see a group with a broader focus. It would not only
work on detecting, fixing and mitigating issues, but also on creating
a policy. And we could also work on things like recommendations on how
to do opt-in for data sharing in the software we ship.

Shall we create a debian-privacy list for this?


Kind regards,

Jeroen Dekkers



Re: Privacy guarantees

2021-09-12 Thread Bastian Blank
On Sat, Sep 11, 2021 at 06:18:16AM +, Paul Wise wrote:
> On Fri, Sep 10, 2021 at 2:44 PM Felix Lechner wrote:
> > A fellow developer and I have reached an impasse over the appropriate
> > level of privacy guarantees in Debian. [1]
> I think that lintian privacy tags currently represent several sets of bugs:

> The browsers shipping in Debian place no barriers between local files
> on disk, sites on the local network and sites on the Internet. So if
> someone reads some local documentation they didn't get from Debian
> using a browser from Debian, they could have a privacy violation.

Could you please describe what the policy violation is you see?
Especially as you generalize.

And yes, the browsers place barriers between local files and network.
E.g. chromium enforces a referrer policy of
"strict-origin-when-cross-origin" on file://.

Bastian

-- 
If I can have honesty, it's easier to overlook mistakes.
-- Kirk, "Space Seed", stardate 3141.9



Re: Privacy guarantees

2021-09-11 Thread Stefano Rivera
Hi Paul (2021.09.11_06:18:16_+)
> The web applications available in Debian may suggest visitors request
> resources not available on the same web service. Since most web
> browsers don't block third-party requests by default, those visitors,
> who are only indirectly Debian users, could have a privacy violation.
> The same applies when Debian documentation is copied to a website.

Browsers have a mechanism to do this, Content-Security-Policy:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

That can be implemented by injecting  tags into HTML, or serving
them through a web server (dhelp/dwww) that can provide CSP http
headers.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272



Re: Privacy guarantees

2021-09-11 Thread Paul Wise
On Fri, Sep 10, 2021 at 2:44 PM Felix Lechner wrote:

> A fellow developer and I have reached an impasse over the appropriate
> level of privacy guarantees in Debian. [1]

I think that lintian privacy tags currently represent several sets of bugs:

The browsers shipping in Debian place no barriers between local files
on disk, sites on the local network and sites on the Internet. So if
someone reads some local documentation they didn't get from Debian
using a browser from Debian, they could have a privacy violation.

The documentation available in Debian may suggest readers request
resources not available as local files on disk. Even if we fix the
browsers available in Debian, users may read Debian documentation using
browsers not available in Debian, they could have a privacy violation.

The web applications available in Debian may suggest visitors request
resources not available on the same web service. Since most web
browsers don't block third-party requests by default, those visitors,
who are only indirectly Debian users, could have a privacy violation.
The same applies when Debian documentation is copied to a website.

> Would this esteemed group please advise if the topic is in some form
> suitable for a General Resolution?

I'm not sure a GR is the appropriate mechanism to fix privacy issues
in Debian, instead I would encourage interested folks to form a group
focused on detecting, fixing and mitigating these issues. See the work
of the Reproducible Builds folks for an example how such a group can
move Free Software forward on a particular issue.

https://wiki.debian.org/PrivacyIssues
https://reproducible-builds.org/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: Privacy guarantees

2021-09-10 Thread Thomas Goirand
On 9/10/21 4:43 PM, Felix Lechner wrote:
> Hi,
> 
> A fellow developer and I have reached an impasse over the appropriate
> level of privacy guarantees in Debian. [1] Would this esteemed group
> please advise if the topic is in some form suitable for a General
> Resolution?
> 
> The aggrieved party is likely to appeal my forthcoming lack of action
> to the Technical Committee. [2] While the Technical Committee is more
> or less Debian's Supreme Court, it seems unfair to burden that select
> group of ours with matters of broad social significance. The Policy
> Team was similarly reluctant. They have not acted on the matter in
> nearly eight years. [3]
> 
> The maintainer of a well-known web browser took a stance in the
> middle. [4] My own position was outlined here. [5]
> 
> In the spirit of seeking common ground, I would like to offer to the
> aggrieved party that we co-sponsor a General Resolution together. Is
> that appropriate? Thank you!
> 
> Kind regards
> Felix Lechner

Hi,

I've skimmed through the first bug report that you've linked to, and
failed to understand. Is this about privacy breaches in docs, for
example, when linking to a remote image and such in a local doc? If so,
I don't see the problem of removing them... These are very annoying, and
it doesn't take much effort from the maintainer perspective. I am very
happy that Lintian considers this as a big problem that needs to be
fixed, as I would hate myself to browse a local doc and having my web
browser access remote content when I don't expect it.

I don't think a GR is appropriate here, at least not before discussing
this with other DDs (maybe in debian-devel) for long enough. I also
believe that this isn't a topic that deserves so much of our DD time.

Cheers,

Thomas Goirand (zigo)



Re: Privacy guarantees

2021-09-10 Thread Ulrike Uhlig

Hi!

On 10.09.21 19:10, Russ Allbery wrote:

Felix Lechner  writes:


The Policy Team was similarly reluctant. They have not acted on the
matter in nearly eight years. [3]



In the interim, one path forward would be for someone who cares strongly
about this area to write up a good guide for maintainers who have no
expertise here and not a lot of time but a willingness to do something
(this may already exist in the wiki), and then put that guide into the
Developer's Reference (perhaps a "Best practices around privacy" section).
That gets the information about what to do into our technical
documentation and creates an on-ramp for elevating it to Policy advice and
then possibly a Policy recommendation as the tools improve.


I love this idea.

I believe it would have a much greater impact on the long term to raise 
awareness among maintainers.


There is a wiki page that references different privacy issues with 
Debian packages [https://wiki.debian.org/PrivacyIssues] and that could 
equally add some data and starting points for a "Best practices".


Another thing that I dit not see addressed in that matter is that fact 
that privacy issues should also be fixed upstream ("we will give back to 
the community", Debian Social Contract) - and with priority.


Take care,
Ulrike



Re: Privacy guarantees

2021-09-10 Thread Russ Allbery
Felix Lechner  writes:

> The Policy Team was similarly reluctant. They have not acted on the
> matter in nearly eight years. [3]

(The below is somewhat off the topic of the Lintian bug, which I know was
the original prompt for this message, and is more about the broader issue.
I'm not expressing an opinion on the merits of the Lintian tag, although I
think reaching more of a consensus about the broader issue would help
inform a decisions about the tag, such as its severity.)

I'm not sure Policy is the appropriate place to talk about this in its
current state.  Policy would be appropriate if there is a consensus in
Debian to ask all maintainers to modify upstream documentation that we
install to remove external images or external JavaScript.

There's some tricky nuance to that statement, so let me try to expand that
carefully.

I think there is a consensus that we would all be very happy if upstream
documentation did not contain such links that could be abused as trackers.
My belief from the previous discussions is that there are a few people who
don't think this matters much, a few people who feel strongly about this
and are investing work into improving the situation, and a lot of people
who are uncomfortable with the existence of such things but are also not
very focused on it.  If all such links went away without work by the
maintainers, I think nearly everyone would be happy.

However, that's not precisely the question at hand.  The question is
whether we are asking maintainers to take action to remove such things
from installed files.  I think the implicit assumption here (and certainly
the assumption that I would make) is that most (not all) upstreams would
not be willing to take such patches, and some upstreams would be annoyed
by and opposed to such a change (often not, to be clear, because they are
intending to use trackers as trackers, although I'm sure there is some of
that, but because things we consider trackers they believe are serving
some other purpose, such as linking to a donation site).  Therefore, for
most packages, this would mean carrying Debian-local modifications and
some risk of upstream conflict.

That's a higher bar, since every modification of that type increases the
maintenance load for maintainers and doesn't scale particularly well.
It's that practical concern -- the additional work burden that we would be
asking maintainers to carry -- that I think is the root of the reluctance
that you're seeing and the lack of willingness to push forward with a
mandate or strong recommendation.  In other words, I think this is a
trade-off question: the project has a certain capacity for work that we
ask maintainers to do, and if we ask them to spend time on one thing, this
will often mean they won't have time to spend on something else.  Does
removing trackers rise to that level of request?  This, I think, is less
clear.

One approach is to reduce the burden.  If there were a highly reliable
tool that could be automatically run over installed files that would
remove all the abusable links with no negative effects on the quality of
the documentation when viewed locally and preserving clear and effective
paths for upstream maintainers to solicit donations to support their work,
I think it would be easy to arrive at a consensus that every package
should run that tool.  My understanding is that people are working on
developing such a tool but it doesn't exist in quite that reliable form
yet.

In the interim, one path forward would be for someone who cares strongly
about this area to write up a good guide for maintainers who have no
expertise here and not a lot of time but a willingness to do something
(this may already exist in the wiki), and then put that guide into the
Developer's Reference (perhaps a "Best practices around privacy" section).
That gets the information about what to do into our technical
documentation and creates an on-ramp for elevating it to Policy advice and
then possibly a Policy recommendation as the tools improve.

-- 
Russ Allbery (r...@debian.org)  



Re: Privacy guarantees

2021-09-10 Thread Pierre-Elliott Bécue

Felix Lechner  writes:

> Hi,
>
> A fellow developer and I have reached an impasse over the appropriate
> level of privacy guarantees in Debian. [1] Would this esteemed group
> please advise if the topic is in some form suitable for a General
> Resolution?
>
> The aggrieved party is likely to appeal my forthcoming lack of action
> to the Technical Committee. [2] While the Technical Committee is more
> or less Debian's Supreme Court, it seems unfair to burden that select
> group of ours with matters of broad social significance. The Policy
> Team was similarly reluctant. They have not acted on the matter in
> nearly eight years. [3]
>
> The maintainer of a well-known web browser took a stance in the
> middle. [4] My own position was outlined here. [5]
>
> In the spirit of seeking common ground, I would like to offer to the
> aggrieved party that we co-sponsor a General Resolution together. Is
> that appropriate? Thank you!
>
> Kind regards
> Felix Lechner
>
> [1] https://bugs.debian.org/743694
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743694#44
> [3] https://bugs.debian.org/726998
> [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765503#5
> [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743694#24

A GR sounds quite big, but if that's what you want, please go for it.

I personally agree with your opinion as stated on the bug report post
24, and therefore I consider the current situation as good as it is.

With best regards,

--
PEB


signature.asc
Description: PGP signature


Re: Privacy guarantees

2021-09-10 Thread Sylvestre Ledru

Le 10/09/2021 à 16:43, Felix Lechner a écrit :

Hi,

A fellow developer and I have reached an impasse over the appropriate
level of privacy guarantees in Debian. [1] Would this esteemed group
please advise if the topic is in some form suitable for a General
Resolution?

The aggrieved party is likely to appeal my forthcoming lack of action
to the Technical Committee. [2] While the Technical Committee is more
or less Debian's Supreme Court, it seems unfair to burden that select
group of ours with matters of broad social significance. The Policy
Team was similarly reluctant. They have not acted on the matter in
nearly eight years. [3]

The maintainer of a well-known web browser took a stance in the
middle. [4] My own position was outlined here. [5]

Heu, sorry but I think you are jumping on the gun here.

1. I am not maintaining Firefox in Debian. Mike Hommey is the maintainer.

2. This was my personal opinion in 2014. While I still agree with myself,
you can see that I didn't do anything in that bug for 7 years.
Showing how much I care about this issue ;)

Regards,
Sylvestre



Privacy guarantees

2021-09-10 Thread Felix Lechner
Hi,

A fellow developer and I have reached an impasse over the appropriate
level of privacy guarantees in Debian. [1] Would this esteemed group
please advise if the topic is in some form suitable for a General
Resolution?

The aggrieved party is likely to appeal my forthcoming lack of action
to the Technical Committee. [2] While the Technical Committee is more
or less Debian's Supreme Court, it seems unfair to burden that select
group of ours with matters of broad social significance. The Policy
Team was similarly reluctant. They have not acted on the matter in
nearly eight years. [3]

The maintainer of a well-known web browser took a stance in the
middle. [4] My own position was outlined here. [5]

In the spirit of seeking common ground, I would like to offer to the
aggrieved party that we co-sponsor a General Resolution together. Is
that appropriate? Thank you!

Kind regards
Felix Lechner

[1] https://bugs.debian.org/743694
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743694#44
[3] https://bugs.debian.org/726998
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765503#5
[5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743694#24