Google "safebrowsing"

[Supernova]

As far as I know, Pale Moon still use this. At least the 2 checkboxs in options for that are still there
To summarize how it works : you regularly update a list of site from google, and if you run into one of them, the browser connect to google servers to know if it is still on their blacklist, and if yes it displays things to explain that the site you tried to go on is not safe etc.

I disabled it, but it's not why I do this post.
Today I ran into this : https://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec
According to this, a google authorization is needed to use that. I searched a little bit and ran here : https://developers.google.com/safe-browsing/
There, it's not clear, but it is explained in its developer guide that an API key is required from google. Remembering geolocation issue, I guess that Pale Moon do not have that key.

I'm not sure what Pale Moon actually do, but the current situation have something wrong.

[Moonchild]

Thanks for raising a red flag there.

Looks like it's time to remove the safebrowsing API from Pale Moon builds.

According to https://developers.google.com/safe-browsing/ :

• APIv1 has been discontinued.
• APIv2 and Lookup API are experimental

so.. there's no production-stable implementation of it at the moment{a}:

We provide two types of experimental APIs for using the Safe Browsing service:

• Safe Browsing API v2
• Safe Browsing Lookup API

Note that the Safe Browsing API v1 has been discontinued.

...and APIv2, like other Google on-line services, now needs an API key which is volume-based on number of lookups, similar to the Geolocation API{b}.
I.e.: The service is no longer free to use, and I cannot bear the costs for continued use of the service with an API key.

{a} and {b} are both good reasons by themselves to stop using it, but combined you'd even have to wonder if Mozilla should continue paying for something experimental

[access2godzilla]

Okay, I understand why you're removing safe browsing from Pale Moon ... but is this the correct move?

Personally, I have no use for that feature since I run a tight ship and if/when I download malware, it is a deliberate act; but a large section of users still fall for these things.

Have you looked into the pricing for these APIs?

[Moonchild]

Yes, I believe it is the correct move.
A few reasons:

1. It's experimental in its current state on the provider side. It apparently has been experimental for quite a while and that state has not changed, nor is there any indication it will change. I do not want Pale Moon to rely on experimental services.
2. It provides little protection that normal aware browsing would already surpass. What does it take for a website to be listed and with what turnaround? (no data available on that) Do phishing/malware sites actually stay on the same domain for any length of time? (no, they don't)
3. There are alternatives that probably do a better job, if you feel you need the extra protection from a reputation check on every site visit.
4. Page load speed: there is a noticeable delay when initially requesting pages, especially over wireless, as the lookup is performed. This is probably related to the experimental status of the service.
5. Of course there is the inherent privacy issue dealing with sending (even partial) addresses to any service provider for every site visited - keeping in mind Google's recent track record, a different alternative might be better.
6. API key costs: There is no indication specifically for this service. Comparing it with other related APIs it will be out of my budget range, though. On top, why should I have to pay for a now-experimental service that used to be free of charge when it was not experimental?

In short: I don't see why I should keep a non-production-grade service in the browser that will cost me money, doesn't seem to be providing usable results, gives users a false sense of security (and compromises their privacy), and harms performance.

[dinosaur]

I don't see why I should keep a non-production-grade service in the browser that will cost me money, doesn't seem to be providing usable results, gives users a false sense of security (and compromises their privacy), and harms performance.

Excellent !... I was already compiling my own builds of PM with safe-browsing disabled anyway...

[dinosaur]

Note that you should also disable the "url clasifier" feature (ac_add_options --disable-url-classifier), which is associated with safe browsing.

And since Mozilla devels didn't do their job properly and cleanly, here is a patch I'm using to get rid of the safe browsing settings and preferences (check boxes in the security tab), when building without safe-browsing enabled (but the patch still entitles you to build a safe-browsing enabled PM if such is your wish).

palemoon-24.6.2-no_safe_browsing_build.patch.gz

(2.37 KiB) Downloaded 61 times

[Moonchild]

Thanks dinosaur, but source edits have already been made to that effect (also, your patch wouldn't apply cleanly, and the firefox.js addition of the URL fixes is undesired).
I do see one thing that would be beneficial which is not loading the js in browser.js that I missed, so thanks.

If you want to submit patches in the future, please consider a pull request on the git repo instead, which prevents manual patching and manual edits.

[dinosaur]

Thanks dinosaur, but source edits have already been made to that effect (also, your patch wouldn't apply cleanly, and the firefox.js addition of the URL fixes is undesired).

It is there so that you can still build PM with safebrowsing support if you (or others) so wish: it's simply a move from the "branding" prefs to the main prefs, but it's enclosed between #ifdef MOZ_SAFE_BROWSING/#endif, so these prefs won't get included in a non-safe-browsing build (the reason why I simply didn't add the #ifdef to the branding prefs is that these are probably not ran through cpp, and the #ifdef won't work there, I think).

I do see one thing that would be beneficial which is not loading the js in browser.js that I missed, so thanks.

If you want to submit patches in the future, please consider a pull request on the git repo instead, which prevents manual patching and manual edits.

The patch applies cleanly to the source coming from the PM v24.6.2 7-zipped sources as distributed on your website. And I don't see any link to a git repo either there... It's rather hard to provide patches to a source tree you can't access !

[Moonchild]

And I don't see any link to a git repo either there... It's rather hard to provide patches to a source tree you can't access !

Hmm, good point - I'll add a link to the git repo on that page. I didn't think of updating it after creating the repo not too long ago.

For reference, the git repo can be found on Github at https://github.com/MoonchildProductions/Pale-Moon

[dinosaur]

And I don't see any link to a git repo either there... It's rather hard to provide patches to a source tree you can't access !

Hmm, good point - I'll add a link to the git repo on that page. I didn't think of updating it after creating the repo not too long ago.

For reference, the git repo can be found on Github at https://github.com/MoonchildProductions/Pale-Moon

Thanks !

[Moonchild]

By the way, there is no configure option --disable-url-classifier. there only is an --enable for that to explicitly enable it.
When not building safe browsing, the url classifier is not implicity enabled, so no further configure options are needed.

[dinosaur]

By the way, there is no configure option --disable-url-classifier. there only is an --enable for that to explicitly enable it.
When not building safe browsing, the url classifier is not implicity enabled, so no further configure options are needed.

Well, --disable-url-classifier is accepted, even if it's the default anyway (that's just how the "configure" scripts work: both "--enable-*" and "--disable-*, as well as both "--with-*" and "--without-*' are always accepted, even if either of the two (enable/with or disable/without) may be made the default by the configure.in script writer).

But since the instructions to build PM (for Linux) so far specified "ac_add_options --enable-url-classifier", the latter will definitely have to be either removed or replaced with "ac_add_options --disable-url-classifier"... Thus my remark.

[Moonchild]

It will only check for the non-default setting, so --disable-url-classifier would do the same thing as --ihate-that-url-classifier, meaning, it will do absolutely nothing to the configure process.
Configure should accept anything your throw at it (as long as it's not an invalid thing for a recognized setting), but whether it will have an effect is a different story.

If the build instructions for Linux state explicitly to use --enable-url-classifier, then it should be removed. You'd only need that setting if you want the classifier while not building safebrowsing.

EDIT: removed the erroneous entries from the Linux build instructions.