Re: The Spirit of Free Software, or The Reality
Bas Wijnen writes: > The "problem" that nobody mentioned it may be caused by the fact that > nobody really considers those icons non-free, The copyright holder of those icons does not, AFAIK, grant restricted license for recipients to modify and redistribute the work. That makes those works non-free by my reading of the Social Contract. > and so having them on our users' machines isn't a problem. But then I > agree with Ian and Mike, we should just ship them in the package. Distributing them to Debian recipients makes the implicit promise that they are free by the DFSG, or that they should be removed from Debian if that's discovered to be untrue. So the above seems to argue either that search engine icons are sufficiently important that we can violate the Social Contract, or I've misunderstood. I'd like to know exactly where that misunderstanding is. -- \ “The surest way to corrupt a youth is to instruct him to hold | `\ in higher esteem those who think alike than those who think | _o__) differently.” —Friedrich Nietzsche, _The Dawn_, 1881 | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/857fq0vdyv@benfinney.id.au
Re: The Spirit of Free Software, or The Reality
On Wed, Jul 15, 2015 at 07:56:42PM +0100, Ian Jackson wrote: > Right. I find it disappointing to discover that in Debian we have > deliberately modified Iceweasl to make this problem worse, even if > only in a modest way. ... > And one thing we could easily do (well, easily from a technical point > of view, if we could agree to do it) would be to not download the > icons. AIUI downloading the icons was a change that was made in > Debian for DFSG reasons. I've seen Mike's mail, and agree that his solution is appropriate. I'd like to note my opinion on what seems to have happened here though (it may not actually be what happened, but this is a theoretical argument, so that is irrelevant): We found that some content was not DFSG free, and therefore we didn't want to distribute it in Debian. I don't see how anyone could think that "let the program download the non-free material at first boot" is an appropriate solution for anything in main. The point of software in main is that our users trust that we don't put non-free stuff on their machine. It really doesn't matter if that stuff comes from the archive or is auto-downloaded from somewhere else. I don't expect this to be controversial, but I wanted to mention it anyway, because nobody did so far, and if there is no consensus about this, I think we should have a discussion about it. The "problem" that nobody mentioned it may be caused by the fact that nobody really considers those icons non-free, and so having them on our users' machines isn't a problem. But then I agree with Ian and Mike, we should just ship them in the package. Thanks, Bas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150716051023.gq8...@fmf.nl
Bug#792539: ITP: python-mapnik -- Python interface to the mapnik library
Package: wnpp Severity: wishlist Owner: Bas Couwenberg * Package name: python-mapnik Version : 0.0~20150708-c005502 Upstream Author : Mapnik Developers * URL : https://github.com/mapnik/python-mapnik * License : LGPL-2.1+ Programming Lang: C++/Python Description : Python interface to the mapnik library Mapnik is an OpenSource C++ toolkit for developing GIS (Geographic Information Systems) applications. At the core is a C++ shared library providing algorithms/patterns for spatial data access and visualization. Essentially a collection of geographic objects (map, layer, datasource, feature, geometry), the library doesn't rely on "windowing systems" and is intended to work in multi-threaded environments This package contains the bindings for Python. It used to be built from the mapnik source, but has been split off into its own project since mapnik 3.0.0. The package will be maintained within the Debian GIS team. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150715222725.22472.26284.report...@osiris.linuxminded.xs4all.nl
Re: The Spirit of Free Software, or The Reality
On Wed, Jul 15, 2015 at 01:07:00PM +0100, Ian Jackson wrote: > > BTW, that's something that would need to be resolved once and for all by > > an SPI lawyer, because a) Mozilla's lawyers consider those icons kocher > > as MPL-licensed icons and b) that's a problem broader than just > > iceweasel, as it concerns any package with references to external > > services (and a recurring question on debian-legal). > > There isn't a legal problem, surely. I can't imagine that ebay or > whoever mind us copying their icon in this way. There is surely a > formal legal copyright licence from ebay which makes the icon > redistributable for this kind of purpose. As for trademarks, we are > using the icon to refer to the organisation in question, so we do not > even need permission (although there is almost certainly a formal > permission document). > > AFAICT no-one has suggested that redistributing unmodified copies of > these icons along with the corresponding search engine thingies in > Iceweasl is contrary to any laws, or contrary to the wishes of the > copyright or trademark owners. > > The problem is simply that the icons are non-DFSG-free. I'm not even convinced it's a non-DFSG-freeness problem. You know what? (IANAL opinion here) If upstream is telling me these files are MPL-kocher, I have no reason not to believe them. MPL is DFSG-free, right? Now, surely, you can't modify company logos without some legal boundaries, but those come from trademark laws. Guess what, the same freaking problem exists with the Debian DFSG-free logo! I, myself, find our DFSG-freeness pickiness going too far, and I'm sick of this icon thing. So, here's what I'm going to do: unless I hear non-IANAL objection until the next upstream release due on august 11 (and I'm BCCing the DPL in case he wants to have the SPI lawyer(s) look into this), I will remove the replacement of the bundled icons with urls. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150715221703.gd19...@glandium.org
Re: The Spirit of Free Software, or The Reality
On Wed, Jul 15, 2015 at 12:56:29PM +0100, Ian Jackson wrote:
> Nikolaus Rath writes ("Re: The Spirit of Free Software, or The Reality"):
> > On Jul 15 2015, Jakub Wilk wrote:
> > > So I made this experiment with Iceweasel. These are the requests it
> > > makes with a fresh profile, before you even type an URL:
> > >
> > > POST
> > > https://location.services.mozilla.com/v1/country?key=no-mozilla-api-key
> > > GET http://www.ebay.com/favicon.ico
> > > GET http://en.wikipedia.org/favicon.ico
> > > GET http://www.yahoo.com/favicon.ico
> > > GET http://www.google.com/favicon.ico
> > > GET http://www.amazon.com/favicon.ico
> ...
> > 1. Were you surprised by this? I was certainly not, this is about what I
> >would have guessed. If a program does what I expect it to do, I'm not
> >sure if me starting it is "violating my privacy".
>
> I was surprised that it would download the icons from the installed
> search providers. There is no need for it to do that. And that means
> that the mere presence of an unused but configured search provider,
> causes every user's iceweasel to notify the search provider whenever
> the user starts the browser.
Starts the browser for the first time ever.
Mike
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150715220617.gc19...@glandium.org
Re: The Spirit of Free Software, or The Reality
On Wed, Jul 15, 2015 at 02:18:08PM +0200, Bas Wijnen wrote: > On Wed, Jul 15, 2015 at 01:26:16PM +0900, Mike Hommey wrote: > > On Wed, Jul 15, 2015 at 03:51:42AM +0200, Bas Wijnen wrote: > > > On Wed, Jul 15, 2015 at 01:06:28AM +0200, Jakub Wilk wrote: > > > > POST > > > > https://safebrowsing.google.com/safebrowsing/downloads?client=Iceweasel&appver=38.1.0&pver=2.2&key=no-google-api-key > > > > + a few dozens of GET requests to https://safebrowsing.google.com/ > > > > > > > > So nothing serious here. It's just casually violating your privacy. > > > > > > I disagree that the safebrowsing part is not serious, especially > > > considering > > > that it continues to send a message there on every new page you visit. > > > Best > > > case the only thing that happens is that Google checks that you aren't > > > visiting > > > a dangerous site. But really? Does anyone believe that Google does not > > > store > > > this data to monitor browsing habits? > > > > FUD is easy. How about documenting yourself on how Safe browsing > > actually works? > > Please don't be so harsh. FUD is about trying to mislead people into thinking > untrue bad things about someone. I have no bad intentions, and I don't see > why > you would think that I do. Because you were misleading people into thinking untrue bad things about safe browsing. (snip) > As Jakub was saying: just starting it up without even visiting a site yet will > do a POST and a *few dozen* GET requests. Shouldn't it be waiting with its > checks until it actually knows what to check? What is it sending them at > browser startup? I'm not sure which version of the protocol iceweasel uses nowadays, but this is the protocol spec for v2.2: https://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec Using a POST is part of that. If you're interested in knowing exactly what's going over the wire, you can go enable the browser toolbox and watch all the network requests the browser does. https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox > So I wanted to make it stop; I can live without the safe browsing feature. I > couldn't find it anywhere in the regular preferences. Security > Block reported attach sites and Security > Block reported web forgeries Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150715220450.gb19...@glandium.org
Re: Re: The Spirit of Free Software, or The Reality
On Wed, Jul 15, 2015 at 03:50:18PM +, Christoph Riehl wrote: > > On Wed, Jul 15, 2015 at 03:51:42AM +0200, Bas Wijnen wrote: > > > On Wed, Jul 15, 2015 at 01:06:28AM +0200, Jakub Wilk wrote: > > > > POST > https://safebrowsing.google.com/safebrowsing/downloads?client=Iceweasel&appver=38.1.0&pver=2.2&key=no-google-api-key > > > > + a few dozens of GET requests to https://safebrowsing.google.com/ > > > > > > > > So nothing serious here. It's just casually violating your privacy. > > > > > > I disagree that the safebrowsing part is not serious, especially > considering > > > that it continues to send a message there on every new page you > visit. Best > > > case the only thing that happens is that Google checks that you > aren't visiting > > > a dangerous site. But really? Does anyone believe that Google > does not store > > > this data to monitor browsing habits? > > > > FUD is easy. How about documenting yourself on how Safe browsing > > actually works? Hint: urls are _never_ sent to Google. The worst thing > > that Google can know is that the _hash_ of /some/ url you went to, > has the > > first n bits matching the first n bits of the hash of one (or multiple) > > of the known malware of phishing urls. Nothing more. > > Yeah, it's not like google would have a giant scanning tool that > downloads the content, processes, parses, classifies every web page out > there. > Google will of course never ever generate and store in one of their > databases a hash of the url of each page they process. No, never ever > they will do that. > Also, google will never ever store your requests. They never store > anything for tra(ffi)cking. Let's say they do. So what? The only thing they can get from the first n bits of the hash is that you visited one of possibly hundreds of thousands of urls with the same hash first n bits that also matches the first n bits of the hash of some known malware. Wow, that's going to make tracking so much easier than, say, ads or analytics. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150715215357.ga19...@glandium.org
Bug#792534: ITP: pd-flext -- Flext C++ external layer for Pd (and similar)
Package: wnpp Severity: wishlist Owner: IOhannes m zmoelnig * Package name: pd-flext Version : 0.5.1 Upstream Author : Thomas Grill * URL : http://g.org/research/software/flext/ * License : GPL Programming Lang: C++ Description : Flext C++ external layer for Pd (and similar) Flext is a C++ layer for programming externals for Pure Data (Pd) as well as the proprietary Max/MSP. It provides an object oriented abstraction layer to writing Pd objects. pd-flext is a dependency of a number of pd-externals, that have not been packaged up until now because pd-flext has been removed from the archives in 2009. This is a second round for this nice API... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150715193953.7709.31172.report...@umlautq.umlaeute.mur.at
Re: The Spirit of Free Software, or The Reality
Ian Jackson writes ("Re: The Spirit of Free Software, or The Reality"):
> Right. I find it disappointing to discover that in Debian we have
> deliberately modified Iceweasl to make this problem worse, even if
^
Also, why do I keep doing that ?
e <= here are the ones I missed out so far with a few extra spare.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21926.45026.984216.363...@chiark.greenend.org.uk
Re: The Spirit of Free Software, or The Reality
Nikolaus Rath writes ("Re: The Spirit of Free Software, or The Reality"):
> On Jul 15 2015, Ian Jackson wrote:
> > If I use Iceweasl to visit the EFF's web pages, over TLS, I see no
> > reason why I should be exposed to any privacy violations (other than
> > any implied by decisons taken by the EFF).
>
> I agree with you. There is no reason, and it would be nice if Iceweasel
> would not violate your privacy if you do so.
Right. I find it disappointing to discover that in Debian we have
deliberately modified Iceweasl to make this problem worse, even if
only in a modest way.
> However, I am not at all surprised that Iceweasel is doing that. If I
> want privacy, I don't run Iceweasel but something like w3m. That's a lot
> more reliable than changing Iceweasel to not download some icons and
> disable safe browsing.
Well, that may be a realistic assessment. But others in this thread
have suggested possible ways to gain more assurance about the
behaviour of programs like Iceweasel. I think people who want to do
that deserver our moral and practical support.
And one thing we could easily do (well, easily from a technical point
of view, if we could agree to do it) would be to not download the
icons. AIUI downloading the icons was a change that was made in
Debian for DFSG reasons.
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21926.44266.664357.850...@chiark.greenend.org.uk
Re: The Spirit of Free Software, or The Reality
Nikolaus Rath writes ("Re: The Spirit of Free Software, or The Reality"):
> On Jul 15 2015, Bas Wijnen wrote:
> > As Jakub was saying: just starting it up without even visiting a
> > site yet will do a POST and a *few dozen* GET requests. Shouldn't
> > it be waiting with its checks until it actually knows what to
> > check? What is it sending them at browser startup?
>
> Why don't you check the code?
I think asking questions is a reasonable way to go about this. Having
been the maintainer of a similar package for a while, "checking the
code" is far from straightforward.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21926.39019.476429.927...@chiark.greenend.org.uk
ITP: r-cran-brglm -- GNU R package for bias reduction in binomial-response GLMs
Package: wnpp Owner: Balint Reczey Severity: wishlist * Package name: r-cran-brglm Version : 0.5-9 Upstream Author : Ioannis Kosmidis * URL : http://www.ucl.ac.uk/~ucakiko/index.html * License : GPL-2.0+ Programming Lang: R Description : GNU R package for bias reduction in binomial-response GLMs Fit generalized linear models with binomial responses using either an adjusted-score approach to bias reduction or maximum penalized likelihood where penalization is by Jeffreys invariant prior. These procedures return estimates with improved frequentist properties (bias, mean squared error) that are always finite even in cases where the maximum likelihood estimates are infinite (data separation). Fitting takes place by fitting generalized linear models on iteratively updated pseudo-data. The interface is essentially the same as 'glm'. More flexibility is provided by the fact that custom pseudo-data representations can be specified and used for model fitting. Functions are provided for the construction of confidence intervals for the reduced-bias estimates. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55a6987e.70...@balintreczey.hu
Re: Re: The Spirit of Free Software, or The Reality
> On Wed, Jul 15, 2015 at 03:51:42AM +0200, Bas Wijnen wrote: > > On Wed, Jul 15, 2015 at 01:06:28AM +0200, Jakub Wilk wrote: > > > POST https://safebrowsing.google.com/safebrowsing/downloads?client=Iceweasel&appver=38.1.0&pver=2.2&key=no-google-api-key > > > + a few dozens of GET requests to https://safebrowsing.google.com/ > > > > > > So nothing serious here. It's just casually violating your privacy. > > > > I disagree that the safebrowsing part is not serious, especially considering > > that it continues to send a message there on every new page you visit. Best > > case the only thing that happens is that Google checks that you aren't visiting > > a dangerous site. But really? Does anyone believe that Google does not store > > this data to monitor browsing habits? > > FUD is easy. How about documenting yourself on how Safe browsing > actually works? Hint: urls are _never_ sent to Google. The worst thing > that Google can know is that the _hash_ of /some/ url you went to, has the > first n bits matching the first n bits of the hash of one (or multiple) > of the known malware of phishing urls. Nothing more. Yeah, it's not like google would have a giant scanning tool that downloads the content, processes, parses, classifies every web page out there. Google will of course never ever generate and store in one of their databases a hash of the url of each page they process. No, never ever they will do that. Also, google will never ever store your requests. They never store anything for tra(ffi)cking. Gruss Christoph
Re: preparing for GCC 5, especially libstdc++6
On 07/03/2015 03:24 PM, Matthias Klose wrote: > On 07/02/2015 06:45 PM, Emilio Pozuelo Monfort wrote: >> On 01/07/15 14:39, Matthias Klose wrote: >>> On 06/26/2015 03:01 AM, Emilio Pozuelo Monfort wrote: On 25/06/15 17:44, Matthias Klose wrote: > On 06/25/2015 01:20 PM, Matthias Klose wrote: >> On 06/25/2015 11:23 AM, Emilio Pozuelo Monfort wrote: >>> - You suggest that some libraries may need to be renamed due to the ABI >>> breaks. >>> Do you have a list of affected libraries? >> >> No. Getting this list is a bit difficult. Candidates for these packages >> are the >> GCC 5 build failures due to mismatched symbols files. However there may >> be more >> packages which successfully build, but have additional symbols (this may >> be an >> empty set, because usually some symbol names should be just replaced by >> new ones). > > If symbol versioning is used in a library, you probably won't see this at > all, > until the package is built using GCC 5. I'll ask for another test rebuild > with a > diverted dpkg-gensymbols to look at the generated symbols files. Thanks Matthias. I'd be very interested in knowing more about what breaks. >>> >>> We have 361 C++ libraries which define at least one of these new symbols >>> [1]. >>> Note this list only includes the packages which succeed to build with GCC 5. >>> Another 70 packages might need the same action (the issues at [2] with >>> severity >>> important, which fail during the dpkg-gensymbols call). >>> >>> So my proposal would be to file bug reports for each of these packages, >>> asking >>> the maintainers for what to do with this library. Actions could be: >>> >>> - do nothing, if none of these symbols are part of the library ABI. That >>>would be a rebuild of the library and its reverse dependencies. >>> >>> - add breaks to all reverse dependencies on this library, and rebuild >>>the library and the reverse dependencies. >>> >>> - rename the library package and rebuild all reverse dependencies. >>> >>> The default action should be the most conservative action (the renaming of >>> the >>> library package). >> >> But let's not do transitions unnecessarily... we have hundreds of libraries >> there, so if we can avoid a bunch, then we should avoid them. So I'd say the >> default action should be to investigate if a transition is needed or not. I'm >> not advocating to blindly ignore the problem, fwiw, just want to try to make >> this a little manageable. > > agreed. So I think filing these issues as a task to check their libraries is > the > right thing to do, and asking to close the issue if the packages should just > be > rebuilt without a transition. > >> I see there are quite a few FTBFS bugs for the affected libraries, but since >> the >> plan is to do the switch to GCC 5 first, and the libstdc++6 transition later, >> there would be time in between to fix those bugs and prepare for the >> transition. >> Right? > > We could do the GCC 5 switch first, but then would have to deal with a second > round of uploads once we change the default ABI. I'd like to avoid that. > Note > that for the packages mentioned in the transition we have far more RC issues > which are unrelated to GCC 5. From my point the GCC 5 issues can be handled, > and I'm currently asking people to help with fixes. I'm unsure what to do > with > all the other RC issues, as these are popping up while other unrelated > packages > are uploaded to the archive. Maybe let auto removals do it's work? > >>> These bug reports could be used as transition bug reports as well, once GCC >>> 5 is >>> the default. Then these could be reassigned to release.debian.org once the >>> transitions start. >> >> Yeah, that or new bugs. As long as usertags / titles are set properly, I >> don't >> mind. :) > > Now filed as > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libstdc%2B%2B-cxx11;users=debian-...@lists.debian.org while fixing build failures, I set some of these issues to 'confirmed' where I found link errors while trying to build a package without first rebuilding all it's c++ dependencies. There are some ... plus there are some more, which I didn't find while inspecting the libraries. The ones I found were tagcoll, and exiv2 not showing up in my initial batch, but were tagcoll and exiv2 symbols from the template headers were included in another library libfoo, and then trying to build something depending on libfoo failed without rebuilding that libfoo. So what do we want to do about the default action (always rename, or keep the name)? Certainly some things will break if you don't rename, however you could rename the library later too once you see the actual breakage. Another way to reduce renamings would be to only rename the lowest library in a library stack (e.g. tagcall in tagcall/libept/wibble/..., glibmm in glibmm/gtkmm/pangomm/cairomm/...), because almost everyth
Re: The Spirit of Free Software, or The Reality
On Jul 15 2015, Bas Wijnen wrote: > As Jakub was saying: just starting it up without even visiting a site yet will > do a POST and a *few dozen* GET requests. Shouldn't it be waiting with its > checks until it actually knows what to check? What is it sending them at > browser startup? Why don't you check the code? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87oajdtqhn@thinkpad.rath.org
Re: The Spirit of Free Software, or The Reality
On Jul 15 2015, Ian Jackson wrote:
> Nikolaus Rath writes ("Re: The Spirit of Free Software, or The Reality"):
>> On Jul 15 2015, Jakub Wilk wrote:
>> > So I made this experiment with Iceweasel. These are the requests it
>> > makes with a fresh profile, before you even type an URL:
>> >
>> > POST
>> > https://location.services.mozilla.com/v1/country?key=no-mozilla-api-key
>> > GET http://www.ebay.com/favicon.ico
>> > GET http://en.wikipedia.org/favicon.ico
>> > GET http://www.yahoo.com/favicon.ico
>> > GET http://www.google.com/favicon.ico
>> > GET http://www.amazon.com/favicon.ico
> ...
>> 1. Were you surprised by this? I was certainly not, this is about what I
>>would have guessed. If a program does what I expect it to do, I'm not
>>sure if me starting it is "violating my privacy".
>
> I was surprised that it would download the icons from the installed
> search providers. There is no need for it to do that. And that means
> that the mere presence of an unused but configured search provider,
> causes every user's iceweasel to notify the search provider whenever
> the user starts the browser. This is not desirable.
I agree that it's not desirable. But there's a lot of stuff in a lot of
packages that's not desirable, I don't see this as an especially severe
problem.
>> 2. Would it be ok if Firefox did all this at the time you visited the
>>first webpage, rather than at the time of startup?
>
> I think that depends on what the first webpage is.
>
> If the first webpage is (say)
> https://en.wikipedia.org/wiki/Embarrassing_medical_problem
> https://act.eff.org/login
> https://search.debian.org/cgi-bin/omega?DB=en&P=vulnerability+scanner
> https://fetlife.com/home/v4
> then I don't see any reason why Ebay or Amazon would have to know even
> that I am running Iceweasel.
>
> To implement the unsafe sites protection, Google might need to know
> that I am running Iceweasel, but measures described elsewhere in this
> thread mean that its information about which actual URLs I am visiting
> is limited.
>
>>If not, then what about all the tracking pages that Firefox is going
>>to load because they're referenced in the page you asked for?
>>Shouldn't you be much more worried about those?
>
> It is obviously not practical for us to do very much about that, other
> than by promoting (a) privacy-enhancing client-side tools
> (b) privacy-respecting websites, where relevant and (c) political
> change.
Yes. I guess what I'm trying to say is that calling Iceweasel isn't the
same as calling "ls" or make. Having the latter programs do the above
would be severe. But in order to protect your privacy when browsing with
Iceweasel, you have to run it through tor anyway (and probably add all
sorts of other measures to prevent fingerprinting). So why worry about a
few extra requests?
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87r3o9tql1@thinkpad.rath.org
Re: GitHub “pull request ” is proprietary, incompatible with Git ‘req u est-pull ’
Antonio Terceiro writes ("Re: GitHub “pull request ” is proprietary,
incompatible with Git ‘req u est-pull ’"):
> But if there is server side support for anyone to push to some ref in
> the maintainer's repository without any authentication in a way that
> won't otherwise interefere with the maintainer's regular trees, the
> client side "should be easy".
Such server side support is fairly straightforward.
Would you like me to write you a proof-of-concept ?
> > > 3.3) git pull-request review $id
> > >
> > > This would probably be the hardest part, since we would need to devise
> > > a reasonable UI for the maintainer to comment on the contents of the
> > > patches. I would imagine that being able to record some review message
> > > against each hunk of the diffs would be a good beginning. Being able
> > > to add line-by-line comments, as gerrit allows, would be awesome.
> >
> > I think this is probably future work.
> >
> > One approach would be
> >
> > git review-push patchbomb-myself $id
> >
> > which would use git-format-patch and git-send-email in some fairly
> > automatic way. Then you could reply to the individual patch messages
> > by email.
>
> I guess the point is storing all of if it the repository itself,
AFAIAA we don't have a plausible gitish storage approach for patch
review comments and status. That's probably a research problem.
I look forward to other people's work in that area :-).
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21926.28016.284585.105...@chiark.greenend.org.uk
Re: GitHub “pull request ” is proprietary, incompatible with Git ‘requ est-pull ’
On Tue, Jul 14, 2015 at 05:06:31PM +0100, Ian Jackson wrote:
> Antonio Terceiro writes ("Re: GitHub “pull request ” is proprietary,
> incompatible with Git ‘requ est-pull ’"):
> > I have a few ideas about this. I have used gerrit before, and it
> > provides a really nice experience except for 2 little facts:
> >
> > - you have to use a web UI thingy to review patches (although that said
> > web UI does have a really nice keyboard-based navigation support)
> >
> > - the server side is quite heavyweight, so both running your own and
> > packaging it for Debian seems to be difficult.
>
> Right.
>
> > I would be very happy if something that works more or less like gerrit
> > but without the above issue existed. I would imagine something along
> > these lines:
> ...
> > on the submitter side
> ...
> > $ git pull-request submit $ORIGBRANCH $PATCHSET
>
> This syntax requires that the user have some special
> `git-pull-request' tool.
>
> An alternative would be:
>
> $ git push git://some/url HEAD:$ORIGBRANCH
>
> And the server side would do this:
>
> > This would create a specially named ref on the maintainer's
> > repository, and the maintainer should be notified somehow that such a
> > pull request exists. Notifications methods could be plugged, so that
> > you can choose to enable notification by email, IRC, or what have you.
> > Of course notifications by email is the obvious choice, given commits
> > come with email addresses.
Yes, `git pull-request` was a thought experiment, an imaginary tool.
But if there is server side support for anyone to push to some ref in
the maintainer's repository without any authentication in a way that
won't otherwise interefere with the maintainer's regular trees, the
client side "should be easy".
> > on the maitainer side
> > ---
> >
> ...
> > 3.1) git pull-request accept $id
> >
> > I imagine this could be as easy as a simple wrapper around `git
> > merge`. when the maintainer pushes the branch, it would be really
> > awesome if the server noticed which pull requests have been merged,
> > and notify the submitters of that.
>
> Notify by email, you mean ?
yes. maybe it could also be done client side, I don't know.
> > 3.3) git pull-request review $id
> >
> > This would probably be the hardest part, since we would need to devise
> > a reasonable UI for the maintainer to comment on the contents of the
> > patches. I would imagine that being able to record some review message
> > against each hunk of the diffs would be a good beginning. Being able
> > to add line-by-line comments, as gerrit allows, would be awesome.
>
> I think this is probably future work.
>
> One approach would be
>
> git review-push patchbomb-myself $id
>
> which would use git-format-patch and git-send-email in some fairly
> automatic way. Then you could reply to the individual patch messages
> by email.
I guess the point is storing all of if it the repository itself,
--
Antonio Terceiro
signature.asc
Description: Digital signature
Bug#792500: ITP: python-futurist -- useful additions to futures, from the future
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-futurist Version : 0.1.2 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/futurist * License : Apache-2.0 Language: Python Description : useful additions to futures, from the future Code from the future, delivered to you in the now. For example: * A futurist.GreenThreadPoolExecutor using eventlet green thread pools. It provides a standard executor API/interface and it also gathers execution statistics. * A futurist.ProcessPoolExecutor derivative that gathers execution statistics. * A futurist.SynchronousExecutor that doesn’t run concurrently. It has the same executor API/interface and it also gathers execution statistics. * A futurist.ThreadPoolExecutor derivative that gathers execution * statistics. * A futurist.periodics.PeriodicWorker that can use the previously * mentioned executors to run asynchronous work periodically in parallel or synchronously. * etc. note: This is a new dependency of python-taskflow, needed for OpenStack Liberty release due this October. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150715130422.12452.31848.report...@buzig2.mirantis.com
Re: The Spirit of Free Software, or The Reality
On 07/15/2015 at 08:18 AM, Bas Wijnen wrote: > As Jakub was saying: just starting it up without even visiting a site > yet will do a POST and a *few dozen* GET requests. Shouldn't it be > waiting with its checks until it actually knows what to check? What > is it sending them at browser startup? > > So I wanted to make it stop; I can live without the safe browsing > feature. I couldn't find it anywhere in the regular preferences. In > about:config I searched for it and there is an "enabled" flag, which > I turned off, but that didn't actually stop the traffic (is that a > bug, or does it disable something in a different way?) I've seen this (or something similar) discussed on Mozilla lists semi-recently. I believe there was a bug opened about it, but I don't recall the bug number or what the outcome (if any yet) may have been. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#792497: ITP: python-fasteners -- provides useful locks
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-fasteners Version : 0.12.0 Upstream Author : Joshua Harlow * URL : https://github.com/harlowja/fasteners * License : Apache-2.0 Programming Lang: Python Description : provides useful locks Fasterners is a python package that provides useful locks. It includes locking decorator (that acquires instance objects lock(s), acquires on method entry and releases on method exit), reader-writer locks, inter-process locks and generic lock helpers. This package is a new dependency for python-taskflow (ie: OpenStack stuff), and handles locks. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150715122602.4655.82290.report...@buzig2.mirantis.com
Re: The Spirit of Free Software, or The Reality
On Wed, Jul 15, 2015 at 12:16:36PM +0200, Marcus Rohrmoser wrote: > https://requestpolicycontinued.github.io/ comes to a rescue. Note that while requestpolicycontinued is capable to do everything original requestpolicy did, in its default mode it's just a poor ad blocker, strictly weaker than Adblock Plus. There is a switch to make it block third-party servers by default, but the documentation discourages that. I can't fathom why they would do such a thing as this throws away the whole concept, but as it stands, I wouldn't recommend requestpolicycontinued to unwary users. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150715121826.ga26...@angband.pl
Re: The Spirit of Free Software, or The Reality
On Wed, Jul 15, 2015 at 01:26:16PM +0900, Mike Hommey wrote: > On Wed, Jul 15, 2015 at 03:51:42AM +0200, Bas Wijnen wrote: > > On Wed, Jul 15, 2015 at 01:06:28AM +0200, Jakub Wilk wrote: > > > POST > > > https://safebrowsing.google.com/safebrowsing/downloads?client=Iceweasel&appver=38.1.0&pver=2.2&key=no-google-api-key > > > + a few dozens of GET requests to https://safebrowsing.google.com/ > > > > > > So nothing serious here. It's just casually violating your privacy. > > > > I disagree that the safebrowsing part is not serious, especially considering > > that it continues to send a message there on every new page you visit. Best > > case the only thing that happens is that Google checks that you aren't > > visiting > > a dangerous site. But really? Does anyone believe that Google does not > > store > > this data to monitor browsing habits? > > FUD is easy. How about documenting yourself on how Safe browsing > actually works? Please don't be so harsh. FUD is about trying to mislead people into thinking untrue bad things about someone. I have no bad intentions, and I don't see why you would think that I do. I have some experience with safe browsing, but indeed I have not looked up how it works. I do know that it continuously sends data to Google, and I have quite a bit of confidence in their capability and willingness to use that data for tracking. From your description it sounds like that is not trivial, but there are smart people at Google, and they have near infinite resources. > Hint: urls are _never_ sent to Google. The worst thing > that Google can know is that the _hash_ of /some/ url you went to, has the > first n bits matching the first n bits of the hash of one (or multiple) > of the known malware of phishing urls. Nothing more. That sounds good, and I believe you that is how it's supposed to work, but I can't quite match it with my observations. The first time I encountered safe browsing was when I was running wireshark for an unrelated reason. I saw lots of packets going to a remote server even though I wasn't doing anything on the network yet. So I checked which host it was, and it turned out to be Google. Given that every product they have seems to be targeting maximum gathering of personal information on people, I worry when my computer is sending a lot of data to them without me asking for it. I also note that it sent requests there all the time. I wasn't even doing anything with my browser, and I didn't have any sites open that would obviously keep contact with the server. I don't remember exactly what happened, but I do remember that it looked like Iceweasel was sending a lot of information about me to Google. As Jakub was saying: just starting it up without even visiting a site yet will do a POST and a *few dozen* GET requests. Shouldn't it be waiting with its checks until it actually knows what to check? What is it sending them at browser startup? So I wanted to make it stop; I can live without the safe browsing feature. I couldn't find it anywhere in the regular preferences. In about:config I searched for it and there is an "enabled" flag, which I turned off, but that didn't actually stop the traffic (is that a bug, or does it disable something in a different way?) Eventually I managed to stop it by replacing all the safebrowsing related urls with empty strings. I don't like that I need to do that much work to prevent my computer from contacting Google. I also don't think I am obligated to find out the technical details of the protocol before I'm allowed to complain about it. All that being said, I agree with Ben that the Iceweasel packaging in Debian is excellent, and I'm happy to know that this is the case. Thanks, Bas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150715121808.gp8...@fmf.nl
Re: git repositories for packages and signed pushes
Gerrit Pape writes ("Re: git repositories for packages and signed pushes"):
> On Sat, Jul 11, 2015 at 06:23:59PM +0100, Ian Jackson wrote:
> > The only significant problem is that the relevant versions of git are
> > currently only in experimental. Can we expect these (a) to be in sid
> > soon and (b) usefully stable backports to be available for (at least)
> > jessie ? (CCing git@p.d.o.)
>
> Hi, currently git maintenance got a bit slow, and we maintainers didn't
> do the backports in the past. You can NMU the experimental version into
> unstable if needed.
Right. Thanks. I might do that. I have some other stuff on my plate
first.
> I currently cannot do that as I'm in the process to get a new key into
> the keyring.
In the meantime I would be happy to sponsor uploads, if it would help.
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21926.19877.228679.903...@chiark.greenend.org.uk
Re: The Spirit of Free Software, or The Reality
Marc Haber writes ("Re: The Spirit of Free Software, or The Reality"):
> On Wed, 15 Jul 2015 14:56:28 +1000, Ben Finney
> wrote:
> >Whatever my position ends up being on that, I do have a firm position on
> >another aspect: I greatly appreciate that you're grappling with these
> >issues in Mozilla products, and working to keep Debian high-quality and
> >free.
>
> Amen. Packaging Mozilla software surely is hard work just for its
> obiquity, and the work is done just splendidly.
I should say that I agree with this and my previous message should not
be read as a criticism of Mike, who is indeed dealing with very tricky
problems.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21926.19736.832540.256...@chiark.greenend.org.uk
Re: The Spirit of Free Software, or The Reality
Mike Hommey writes ("Re: The Spirit of Free Software, or The Reality"):
> On Wed, Jul 15, 2015 at 01:06:28AM +0200, Jakub Wilk wrote:
> > GET http://www.ebay.com/favicon.ico
> > GET http://en.wikipedia.org/favicon.ico
> > GET http://www.yahoo.com/favicon.ico
> > GET http://www.google.com/favicon.ico
> > GET http://www.amazon.com/favicon.ico
> > GET http://www.yahoo.com/favicon.ico
> > GET http://www.yahoo.com/favicon.ico
> > GET https://en.wikipedia.org/favicon.ico
> > GET https://en.wikipedia.org/favicon.ico
> > GET https://www.yahoo.com/favicon.ico
> > GET https://en.wikipedia.org/favicon.ico
>
> FWIW, those are a consequence of removing supposedly non-free icons from
> the source package. But maybe you'd prefer no icons at all for the list
> of search engines.
Yes. Frankly I think it is astonishing that we have done this
deliberately. Do we really think we are enhancing our users' freedom
by doing this ?
Compared to distributing the icon in the package, the user does not
gain the ability to legally modify the icon. We are not avoiding
exposing us or our users to any legal risks.
Supposely this decision is made by us for ethical reasons (ie, to
uphold our values) but the actual effect is simply to diminish our
users' privacy,.
I would prefer the following things in this order:
1. Where distribution is permitted by an upstream, we make an
exception for non-free icons in this context. We already make
exceptions for the text of licences and I don't see this being a
problem in principle.
No reasonable downstream would want to take the trademarked icons
of a proprietary company, which happens to be bundled into our
package for privacy and convenience, and produce derivative icons.
Nor would anyone reasonable expect to be able to do that.
2. No non-DFSG-free icons for search engines. If no modifiable icon
is available, no icon.
> BTW, that's something that would need to be resolved once and for all by
> an SPI lawyer, because a) Mozilla's lawyers consider those icons kocher
> as MPL-licensed icons and b) that's a problem broader than just
> iceweasel, as it concerns any package with references to external
> services (and a recurring question on debian-legal).
There isn't a legal problem, surely. I can't imagine that ebay or
whoever mind us copying their icon in this way. There is surely a
formal legal copyright licence from ebay which makes the icon
redistributable for this kind of purpose. As for trademarks, we are
using the icon to refer to the organisation in question, so we do not
even need permission (although there is almost certainly a formal
permission document).
AFAICT no-one has suggested that redistributing unmodified copies of
these icons along with the corresponding search engine thingies in
Iceweasl is contrary to any laws, or contrary to the wishes of the
copyright or trademark owners.
The problem is simply that the icons are non-DFSG-free.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21926.19684.439953.87...@chiark.greenend.org.uk
Re: The Spirit of Free Software, or The Reality
On Wed, 15 Jul 2015 14:56:28 +1000, Ben Finney wrote: >Whatever my position ends up being on that, I do have a firm position on >another aspect: I greatly appreciate that you're grappling with these >issues in Mozilla products, and working to keep Debian high-quality and >free. > >Thank you, Mike. Amen. Packaging Mozilla software surely is hard work just for its obiquity, and the work is done just splendidly. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1zfklg-hl...@swivel.zugschlus.de
Re: dgit: all users of dgit << 0.30 please upgrade
Wouter Verhelst writes ("Re: dgit: all users of dgit << 0.30 please upgrade"):
> On Tue, Jul 14, 2015 at 06:00:32PM +0100, Ian Jackson wrote:
> > * I am going to move the git repositories. The old version of dgit
> >will stop working when I do.
>
> In that case, and seen as how -devel is not a must-read mailinglist,
> maybe this is more appropriate for -devel-announce?
Perhaps, but the preexisting dgit user community is fairly small.
Also, the failure modes are safe: they don't involve data loss or the
upload of corrupted packages.
I'm going to make an announcement on -devel-announce shortly with some
more stuff in, and I will mention this then.
But, thanks for your suggestion.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21926.14237.728236.829...@chiark.greenend.org.uk
Bug#792488: ITP: libtext-levenshtein-damerau-perl -- Edit distance calculator with Damerau Levenshtein algorithm
Package: wnpp Owner: Dominique Dumont Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libtext-levenshtein-damerau-perl Version : 0.41 Upstream Author : Nick Logan * URL : https://metacpan.org/release/Text-Levenshtein-Damerau * License : Artistic or GPL-1+ Programming Lang: Perl Description : Edit distance calculator with Damerau Levenshtein algorithm Text::Levenshtein::Damerau module returns the true Damerau Levenshtein edit distance of strings with adjacent transpositions. Useful for fuzzy matching, DNA variation metrics, and fraud detection. Defaults to using Pure Perl Text::Levenshtein::Damerau::PP, but has an XS addon Text::Levenshtein::Damerau::XS for massive speed imrovements. Works correctly with utf8 if backend supports it. -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3000763.DKPrHFeM9s@ylum
Re: The Spirit of Free Software, or The Reality
Dear Nikolaus, I have to disagree. > I'm not sure if that's really as serious as you make it sound. Let me > ask you this: > > 1. Were you surprised by this? Yes. > I was certainly not, this is about what I >would have guessed. Why? > If a program does what I expect it to do, I'm not >sure if me starting it is "violating my privacy“. If I didn’t tell it to access a webpage I wouldn’t expect it to. >Accessing various webpages is necessary for the functions that >Firefox provides. So complaining about this is a little like >complaining that my car needs fuel - unfortunate, but difficult to >avoid if I want to have a car. If you don't want the functions that >Firefox provides, don't use it. Indeed, staying in the car analogon (that usually fails): question is who’s in the driver’s seat. Who decides which directions to take - i.e. pages to access. It should be the user's decision. Not the visited website’s (which sadly too often is) but definitively not the browser’s own decision. Even less so in secrecy. And even less so prior ANY USER ACTION requesting so. > 2. Would it be ok if Firefox did all this at the time you visited the >first webpage, rather than at the time of startup? No. >If not, then what about all the tracking pages that Firefox is going >to load because they're referenced in the page you asked for? >Shouldn't you be much more worried about those? Thank you mentioning this - yes, acually I am not only worried but annoyed to a degree to take action: https://requestpolicycontinued.github.io/ comes to a rescue. Cheers, M -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cf383996-93cc-4f4f-9dbb-c5f95d3fe...@mro.name
Re: git repositories for packages and signed pushes
On Sat, Jul 11, 2015 at 06:23:59PM +0100, Ian Jackson wrote: > The only significant problem is that the relevant versions of git are > currently only in experimental. Can we expect these (a) to be in sid > soon and (b) usefully stable backports to be available for (at least) > jessie ? (CCing git@p.d.o.) Hi, currently git maintenance got a bit slow, and we maintainers didn't do the backports in the past. You can NMU the experimental version into unstable if needed. I currently cannot do that as I'm in the process to get a new key into the keyring. Regards, Gerrit. signature.asc Description: Digital signature
Re: dgit: all users of dgit << 0.30 please upgrade
On Tue, Jul 14, 2015 at 06:00:32PM +0100, Ian Jackson wrote: > * I am going to move the git repositories. The old version of dgit >will stop working when I do. In that case, and seen as how -devel is not a must-read mailinglist, maybe this is more appropriate for -devel-announce? -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150715074626.gb28...@grep.be
Re: The Spirit of Free Software, or The Reality
On Wed, Jul 15, 2015 at 02:34:41PM +0900, Mike Hommey wrote: > On Wed, Jul 15, 2015 at 01:09:47PM +0800, Paul Wise wrote: > > On Wed, Jul 15, 2015 at 12:26 PM, Mike Hommey wrote: > > > > > FUD is easy. How about documenting yourself on how Safe browsing > > > actually works? Hint: urls are _never_ sent to Google. The worst thing > > > that Google can know is that the _hash_ of /some/ url you went to, has the > > > first n bits matching the first n bits of the hash of one (or multiple) > > > of the known malware of phishing urls. Nothing more. > > > > Why doesn't it just download the full list and do checks client-side? > > The full list is huge, so it downloads a smaller list with hash > prefixes, then when it hits a match, it downloads a list of all the > hashes that start with that prefix. In other words, that's what it actually does, modulo some optimization so it doesn't have to download terabytes of data. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150715074242.ga28...@grep.be
