Re: proposal for more options in gnu/services/networking.scm for blocklist

[Nils Gillmann]

address@hidden (Ludovic Courtès) writes:

> Nils Gillmann <address@hidden> skribis:
>
>> address@hidden (Ludovic Courtès) writes:
>>
>>> Nils Gillmann <address@hidden> skribis:
>>>
>>>> A first version for google I just came up with starts like the attached
>>>> code.
>>>>
>>>> What do you think?
>>>
>>> I would use it!  (Although I use Tor + Privoxy for most of my web
>>> browsing, so I would also need the black list there.)

Appending to what I've written further down below, do you still want me
to push the google ads related servers as an patch and proceed with the
rest like what I've written below?

>>>
>>> The only downside I see it having to maintain it.  Do you know if anyone
>>> maintains a list of these hosts somewhere?  If yes, we should put the
>>> URL as a comment and have a somewhat streamlined process to update the
>>> list.
>>
>> There are many lists out there which are not limited to google.
>> The downside I see with this is external authorities and the trust you
>> have to put into them, plus unnecessary downloads.
>> If it should be moved into a file, I would put it into the Guix system
>> source. (-> maybe mirrors of those listed below?)
>> I could try and see if I can find a blacklist which is not very long and
>> does not need extensive checking.
>
> OK.
>
>>> If there’s no publicly-maintained list of hosts, I think we won’t go
>>> beyond Google, because that would easily become unmaintained, and people
>>> would be disappointed to get an incomplete/outdated host list.
>>>
>>> What do people think?
>>
>> Ublock Origin uses the following sources:
>> https://easylist.adblockplus.org/en/policy#easylist
>> http://pgl.yoyo.org/adservers/policy.php
>> http://www.malwaredomainlist.com
>> http://www.malwaredomains.com
>> https://github.com/gorhil/uBlock/tree/master/assets/ublock
>>
>> Pro: Other people and collections of people maintain these lists. less
>> work for us
>> Pro: widely accepted and maintained
>>
>> Con: see section above (other authorities, traffic)
>
> Yeah.  OTOH I don’t see us (Guix) claim maintenance of such lists.
>
> Another option would be for you to publish such lists, signed and
> versioned, on a hosting site you have access to?  The advantage would be
> less churn in Guix proper, and the responsibility would be moved to you
> (or the collective that maintains the list) rather than Guix.  We could
> refer to it in the manual.
>
> WDYT?
>
> Thanks,
> Ludo’.

Interesting idea, although I have an issue with signing commits.
I did not dive much into the topic itself, but if you have more
knowledge about it and could say that signed commits can not be abused
in my name to let's say pretend a fork with malicious intentions end up
being signed in my name, I'm open for it. What's you experience on
signed commits?

I am on savannah, gna (not sure), and notabug, so either one of those
would work, where I have not much experience with savannah myself but
more with notabug.

If I find reasonable policy and standards of what should, could, would
be included and what will definitely not be included,
and will find people who are interested in keeping it up to date,
it's an doable project which can be linked to in Guix but not promoted
as official Guix related.

I try to make it happen this year, can't tell when exactly but I'll talk
about it with other people and see if they have ideas and criterias in
addition to mine.
It shouldn't be main priority to anyone as maintaining such lists can
take time.
If I come to the conclusion that it is doable without being the 40th
invention of the wheel, I'll start this.

-- 
ng/ni*
vcard: http://krosos.sdf.org