Web Browser
- Login o registrati per inviare commenti
Like I wrote to heyjoe:
Distributing the lists is not the hard part. Creating them is. It involves crawling the Web and processing every page (Google does so in parallel virtual machines): https://www.usenix.org/legacy/events/hotbots07/tech/full_papers/provos/provos.pdf
You cannot just redistribute Google's data:
Unless expressly permitted by the content owner or by applicable law, you will not, and will not permit your end users or others acting on your behalf to, do the following with content returned from the APIs:
- Scrape, build databases, or otherwise create permanent copies of such content, or keep cached copies longer than permitted by the cache header;
I am a member!
> BTW I am looking for a way to search/browse Youtube without JS. Any ideas?
Recent versions of GNOME Videos can search and play YouTube videos, as
well as Vimeo and perhaps a few other sites.
mps-youtube also searches YouTube, but it won't play videos on my
machine. Its UI is also not a shiny GUI app like Videos is, so
recommending Windows users to go from using the site to using the
terminal is kind of embarrassing.
I am a member!
> My main concern is not to run JavaScript.
Mine, too.
> Do you know if Gnome Videos use JS
> internally?
It does not use YouTube's JS or youtube-dl.
>
> FWIW the other day I read that youtube-dl *does* use JS... which makes me
> hesitant to use it. Do you know any alternative to it which doesn't?
AVideo, but it needs to be updated.
https://notabug.org/GPast/avideo/src/master
--
Caleb Herbert
OpenPGP public key: http://bluehome.net/csh/pubkey
> I installed totem. However... some YouTube videos don't play.
That is expected behavior. Unfortunately, some YouTube videos cannot be downloaded without JavaScript, so any program that avoids JavaScript won't be able to play all videos.
heyjoe said:I suppose the best thing we can do is have separate computers for everything: One for watching YouTube, one for running JavaScript, one for personal things, one for work etc.
I got a new gprl license , try to find 5 legs for my linseed, it will drive you nuts always during a mental digestion. it is good to have 5 computers, it could cause personality processing disorder.The vaccination to this habit is a simply one, come back to your designated place and galaxy and stop finding excuses.
I am a member!
> Is Gnome Videos the same as totem? I can't find any package with name close
> to videos or gnome videos on my openSUSE but I have totem.
Yes, but it's been redesigned so much that GNOME Videos really doesn't
resemble the classic GNOME video player Totem anymore.
--
Caleb Herbert
OpenPGP public key: http://bluehome.net/csh/pubkey
I saw a lot of word-confusion in this thread.
Software freedom and privacy are conceptually different issues and should be treated as such.
However, software freedom is a condition for privacy. you can't really be sure to have privacy without software freedom.
If you feel that a piece of free software is not giving you enough privacy (which is obviously the case) then you can alter the source code and remove the critical parts.
Or you can pay somebody who will do the job for you.
Free software gives you no guarantee that a program will be 100% secure, bug free and exactly what you need for a specific task.
It simply can't do that.
I am a member!
On Thu, 2018-01-11 at 01:15 +0100, name at domain wrote:
> The answer given by the Chromium dev surely is not to my taste. Yet it is
> more acceptable considering that even currently Chromium's test shows it to
> be a privacy respecting browser. Or can you show a test which demonstrate
> that Chromium leaks data to Google? Or any other freedom related issue?
> Please do share, I am interested.
Are these words sincere, or are they meant to provoke others? Everybody
knows about all the struggles Chromium forks like Iridium had to go thru
to get Chromium to stop going full botnet! RMS even discussed Iridium
when they tried to liberate Electron, and it was difficult then too.
I am a member!
> but there is nothing wrong with them claiming that their Debian-derived distro PureOS is libre because it is,
I see they've recommended Etcher, an Electron app. They didn't respond
to me on IRC when I said Electron was a possible FSDG issue, since
Fedora and FSDG distros (specifically Parabola) have removed it for
this reason.
I am a member!
You throw the baby out with the bathwater, which irritates me very much.
On Tue, 2018-01-09 at 19:47 +0100, name at domain wrote:
> Could you please explain what freedom issues (apart from the one mentioned by
> me) there are? I have always thought Chromium is FLOSS.
If you're concerned about privacy issues in Mozilla, then how could you
ever consider Chromium? Chromium's privacy issues are even more
difficult to remove, and people are still trying to figure it out.
> But I am not a programmer. And it seems no programmer has taken care to
> remove them, yet the vendors claim it is free software respecting privacy and
> people believe that.
If someone's not doing it fast enough, pay them to go faster.
> Perhaps I need to find an command line tool or
> get rid of RSS totally...
What. On. Earth.
You are making no sense.
You take no initiative to use the rights you hold so dear. You just sit
back and take anything the developer gives you, as if the software were
proprietary.
Just because all the clients in the world are garbage is absolutely no
justification for refusing to ever use the protocol. That's insanity.
Just wait for a better client, whether one that someone else makes or
one you pay someone to make.
--
Caleb Herbert
OpenPGP public key: http://bluehome.net/csh/pubkey
To find out the possible issues with Chromium, I recommend you all to
contribute to [1] and the discussion around it in [2]. If there is no
review as to whether some software is free/libre or not, then we can
only assume the worst case which Stallman and others keep showing in
their talks: that it's non-free software. And the community here
shouldn't recommend non-free software.
I myself so far only contributed with a simple run of licensecheck [3]
but as I explained in the reference, we need to clean that result (the
reference talks about an attachment, but you must download it using the
torrent Info hash in [1] instead, or run licensecheck against your own
copy of Chromium's source code --- following the steps I gave in [1] or
in [3]).
Finally, the practice of using shorter license notices such as "licensed
under SomeLicense" even if the "SomeLicense" itself already defines what
the notice should be makes things more confusing (as I noted in [3]).
About RSS (and generall news feed/reading: I don't like the RSS
specification too, I prefer Atom feeds, specially if the makers of the
feed post the complete article in the item). ;) Currently I'm
experimenting with some famous news readers for Emacs: Newsticker
(built-in), org-feed (built-in), elfeed (external). I'm also
contributing to Newsticker and org-feed by testing them and sending
detailed bug reports. I can't do that with elfeed because of GitHub
issues well described in gnu.org.
[1] https://directory.fsf.org/wiki/Talk:Chromium.
[2]
http://lists.gnu.org/archive/html/directory-discuss/2017-11/msg00001.html.
[3]
http://lists.gnu.org/archive/html/directory-discuss/2017-11/msg00014.html.
2018-01-09T19:47:02+0100 name at domain wrote:
> Could you please explain what freedom issues (apart from the one
> mentioned by me) there are? I have always thought Chromium is FLOSS.
>
>
> But I am not a programmer. And it seems no programmer has taken care
> to remove them, yet the vendors claim it is free software respecting
> privacy and people believe that. My test proves that it is not. And
> that the vendor not only doesn't care but would rather argue with
> proven and close the ticket.
>
>
> Yes - IceCat, Waterfox. IceCat also does background communication on
> startup. Waterfox shows the same behavior as Firefox.
>
>
> Using uMatrix's background log I noticed that Tor Browser also sends
> behind the scenes packets. I don't know if they go through the Tor
> network but in any case - they are sent, without prior (or any)
> consent. Some of them were to Mozilla's servers. I haven't tested
> further or in more detail.
>
>
> Thanks. I also just found QuiteRSS which has built in browser in which
> JS can be disabled. But to my mind the very fact that the RSS reader
> has support for JS makes me stay away from it. Perhaps I need to find
> an command line tool or get rid of RSS totally...
>
--
- https://libreplanet.org/wiki/User:Adfeno
- Palestrante e consultor sobre /software/ livre (não confundir com
gratis).
- "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar
instantaneamente comigo no endereço abaixo.
- Contato: https://libreplanet.org/wiki/User:Adfeno#vCard
- Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft
Office, MP3, MP4, WMA, WMV.
- Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU
GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF
(apenas sem DRM), PNG, TXT, WEBM.
I am a translator!
>Also looking at most recent issues of Spectre and Meltdown - personally I have blocked all JS in chromium. Firefox doesn't even have such setting.
Well done, welcome to the club. Firefox does have the option to block all javascript, of course. In about:config type javascript
javascript.enabled false
Just a friendly reminder about Chromiummo...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786909
In Trisquel 8, Abrowser is default browser and works nice (apart from some branding issues).
Also, as others have mentioned, the "Web" package is nice.
There is another browser called Brave. It is a chromium/blink derivative, it has adblockers and says that it enhances user privacy but when I go to their extensions page(only limited extensions web) it contains proprietary extensions like 1-pass...
I would be interested to see your results with a command line browser linke lynxs or elinks.
> New browser tested with tcpdump: Konqueror
Please beware of KDE family!
I was a KDE user for maybe 10 years until I saw this:
(Well, I had already had it with bloatware. Now I'm on LXQt)
I am running the following command in a cron job:
06 * * * * /usr/bin/akonadictl stop 2>&1
My firewall logs show that every time this command is executed, the PC running the cron job attempts to contact 198.105.254.114 using SPT=56445 DPT=512
Why does the running of “akonadictl stop” via cron initiate outgoing traffic to a remote site?
---------------
As a side note, your thunderbird test also showed covert chatter in background. Browsers can give the weak excuse of "service integration" talk. Then what business can a mail/news client possibly have with "Amazon, Linode, Comodo, Akamai and other hosts etc."?
Do you see a characteristic pattern here?
This is one of the reasons why I prefer refraining from large suites backed by large organizations (apart from bloatware associated problems).
I have several concerns, in terms of privacy and security, about large suits:
1) The software is big and complex, so
1a - it is relatively easier to smuggle in a piece of malware, and
1b - it is relatively more difficult to audit the code.
(1a and 1b are both true separately on their own, and they also make use of, and augment the effect of, one another - i.e. there's a good synergy between them)
2) The organization is big and complex, so
2a - it is a larger and easier target for infiltration, and
2b - it is relatively more difficult to audit them.
(same remarks go here)
Simple programs produced by small teams present far less such risks.
> Also without any network application started I don't
> see any packets in tcpdump. So it doesn't look like
> KDE itself is breaking into user privacy.
If I were to write a spyware, I would be very careful not to push the user hard towards this or that direction. I would lay my web in the features and hope that most users will use them. IOW, I wouldn't chase after the users, but just collect the ones who stick to my web of "features".
Therefore, it is clever of a spyware author not to try to connect remote sites when there's no obvious reason/excuse for it. So, KDE's not sending TCP packets when all the net apps are down, doesn't impress me. I'm not implying that KDE contains spyware - I'm just saying that it's not a decisive parameter for me.
OTOH,
1) KDE was (still is?) being financed by EC.
2) Akonadi + nepomuk couple, depending on how you use it, lays a perfect foundation (technically) to build sophisticated spyware on. See the main article in my link (they are explaining it in terms of "power feature", but please also evaluate it in terms of "spying power"). Again, I'm not drawing any conclusions, but simply pointing out a powerful feature that can be quite misused in wrong hands.
2) Akonadi attempts (at least did in the past) to connect remote sites at shutdown.
These were enough for me to migrate from KDE to LXQt.
Yikes. I avoid saving passwords in my browser as well.
Of course. Enabling JS is still unsafe, but the particular issue you link to relies on having the passwords stored in the browser. Even without JS enabled, another application could exploit Spectre to access your browser, so it is still wise to avoid storing passwords in your browser. I agree though the JS is the most likely way someone would exploit Spectre.
> I store them in Gnome Keyring.
I store them in my head. :)
> Nothing can save us from Spectre except a new CPU.
Yep, and the new CPUs are sure to require a non-free BIOS. Spectre is very bad news for freedom and privacy.
> Recently I started doing something which is probably silly: if I have to
> enable JS for short in a particular website, I close all other programs and
> all other browser tabs. The idea is to have less info in the memory which
> could be broken into. However this may be a really silly overkill because
> certain data remains cached in memory even after the program is closed +
> that doesn't mean other processes are not running. So maybe I am just
> paranoid. It was so nice in single-tasking 16-bit times :)
I think you're wise to do this. As you say, it's not foolproof, but since there is no solution for Spectre right now the best we can do is limit the number and magnitude of opportunities to exploit it.
Nice!
On 01/20, name at domain wrote:
> New browser tested:
>
> PaleMoon
>
> Results:
>
> With default ("factory") settings the browser starts with some
> PaleMoon's page which obviously results in packets exchange.
>
> After tightening of privacy settings (similar to previous browsers)
> the result is:
>
> + No background chattering on startup
> + No background chattering on opening preferences
> + Opening https://fsf.org/robots.txt or https://fsf.org
> communicates only with fsf.org
>
> The browser also supports uBO and uMatrix (though - only older
> versions, not the new ones which are WebExtensions)
>
> It seems to me I may have finally found a FOSS browser which
> respects privacy too.
>
> Please test it and share your results.
> All this makes me think that such brute force cleanup in
> about:config may be possible for other Firefox clones.
Very interesting. Thanks for the time your putting into this. If we can determine exactly which changes were the one that fixed the problem, I think asking for those values to be the default in privacy-minded FF derivatives like Icecat and Abrowser would be a reasonable feature request. It might be worth requesting the same of Mozilla, since that would benefit all downstream forks, but I wouldn't count on them caring...
> However as I
> haven't read what each setting does, it may have some other
> (probably negative) effects. Perhaps we should read about all that
> and come up with settings which are both private and don't affect
> functionality (if that is possible).
I agree that we'd be better off determining the minimum set of values that need to be zeroed to prevent background chatter will be better than zeroing all of them, but what you've found is a great starting point. A binary-search-like approach of zeroing groups of values containing URLs might help identify the culprit(s). Another thought I had is to compare the about:config for Icecat and Tor Browser and see if changing some of Icecat's values to match that of Tor Browser can reduce background chatter.
I'm in the middle of a busy couple of weeks, but I'll try to start hepling you on some of this soon.
> Or maybe we could ask them
> which about:config settings we need to clean/disable in order to
> stop the chatter.
That might work. Rather than calling it a bug report or feature request, it could be framed as a simple support request. You wouldn't be asking them to change anything about their software, just to explain how it works so that you can configure it to meet your needs. That information might then be useful to FF forks, or individual users, who may prefer for that configuration to be part of their default.
That response is promising. Although the fact that Mozilla has a guide for preventing automatic connections indicates that it they do not consider it a problem for automatic connections being the default, he at least acknowledges that background chattering after following that guide is a bug in the documentation. Whether or not they can justify automatic connections, it doesn't take an ethical argument to criticize incomplete documentation. Hopefully they will fix it. If it comes down to the tedious task of testing different combinations of zeroed values I'm happy to help, but it will be much easier of Mozilla can just do their job. :)
> Stop saying that but do something :)
I know... I'll have a busy next couple of days but I should get to it soon. I just need some time to sit down and figure out how tcpdump works and what I'm doing wrong.
> Meanwhile
> lots of talks about community control and ideologies :P
When a community is based around a common cause it can get... passionate about certain issues. This isn't the first time that a thread has spun out of control, but in general I find this forum to be a very positive place when we stay on topic and nobody brings up systemd.
> They edited the bug and
> turned it into a documentation issue instead of looking at the actual
> request to provide an easy (default) setting ensuring real privacy.
I agree that an interface requiring this much work to achieve a theoretically possible configuration is a software bug. However, having a documentation page called "How to stop Firefox from making automatic connections" that doesn't stop Firefox from making automatic connections is also a documentation issue. They should fix both of these things, but fixing the second one is better than nothing as working documentation would help achieve a privacy-respecting configuration FF derivatives may be more willing to accept as a default. I doubt they will listen to you on the first issue, but now that they've at least acknowledged the documentation issue it may be productive to push them to at least fix that.
I will work with tcpdump tonight. Once I know what I'm doing, what's the the most helpful thing to start with? Replicating your tests? Focusing on vanilla FF so I can contribute to the documentation bug report? Focusing on Abrowser since you weren't able to test that one?
> "Work offline" sends packets on closing of the browser. It is not
> offline at all. So Mozilla can talk nonsense to infinity - this is
I agree that this is an actual bug. Unfortunately it seems that Mozilla will not acknowledge this.
> So Mozilla can talk nonsense to infinity - this is
> not a documentation bug.
True, but there is a separate documentation bug (a documentation page contains a procedure that does not work) which they have acknowledged. Maybe their just deflecting to it because they would rather fix the documentation than acknowledge the software bug, but at least they've acknowledged there is *a* problem. Fixing the documentation would not make Firefox a privacy-respecting browser, but it would not be useless either. Your recent comments in the Mozilla threads are correct, and it is frustrating to be correct and ignored, but I think that letting the software bug go temporarily and pushing them on the documentation bug may get the better results.
> 1) show Mozilla that it is not just a single user who sees their
> mischief.
I figured out how to run tcpdump last night. I see a bunch of connections to the University WiFi I'm using, which get mixed in with the connections that begin when I open a browser. Once I find a way to suppress these so that the output of interest is readable I'll corroborate your statements in the Mozilla bug reports.
Mason I am afraid there is a much more serious issue here than a bug or documentation error.
Mozilla is foot-dragging to correct a grave fault - grave as in it blatantly trespasses users' privacy, and what is more, does this being one of main representatives of "open, secure, peer-reviewed RYF" FLOSS suit.
The main problem here, is *not* that Firefox has so and so flaws here and there. The problem is that, Mozilla is NOT behaving. This is an attitude problem, is grave, and prone to grave consequences.
If this apathy of Mozilla for such a serious issue gets its way to FOSS circles, it will not be a very good PR for both Mozilla and the whole FOSS community as well.
With such an attitude Mozilla is effectively sabotaging both itself and the FOSS community.
Something has to be done, by Mozilla, before it is too late. Because once peoples' trust in Mozilla (indirectly FOSS) is harmed, there is no easy/short way to mend it again.
I already question (and don't trust) large suits maintained by large organizations, but I would like to keep this to myself. I hope this distrust of mine won't become a mainstream attitude. And Mozilla is just pumping the fire.
> The main problem here, is *not* that Firefox has so and so flaws
> here and there. The problem is that, Mozilla is NOT behaving. This
> is an attitude problem, is grave, and prone to grave consequences.
I agree. Even if Mozilla were to fix these specific issues I would not use their browser. My interest is in information that may help more freedom- and privacy-friendly Firefox forks.
> Something has to be done, by Mozilla, before it is too late.
> Because once peoples' trust in Mozilla (indirectly FOSS) is harmed,
> there is no easy/short way to mend it again.
Yes, it is a problem that Mozilla has managed to brand itself as "the privacy-respecting" browser. I have seen some positive effects; friends of mine began to take my talk of privacy more seriously after trying Quantum and being exposed to Mozilla's privacy-friendly language. However, it has many disadvantages. Mozilla should not be able to define what is and is not necessary to have privacy. I often have to explain to people why switching from Chrome to Firefox is not enough to protect their privacy. Another problem, as you point out, is that when people learn that Mozilla does not live up to the privacy-respecting image they've created for themselves it creates mistrust. This mistrust is not in itself a bad thing, as Mozilla does not deserve to be fully trusted, but like the Ubuntu spyware issue it reflects poorly on the free software movement in general. A few weeks ago there was the issue of an add-on that was installed by default until Firefox users opt-out (although the add-on was not enabled by default). This was bad, but in some threads I saw people saying that they were switching to Chrome. Chromium is one thing, but I don't think I have to explain why using Chrome is a terrible decision privacy-wise, and if Mozilla's problems are making Chrome look good that's a problem.
While I guess I can see how in Mozilla's mind the automatic connections are not a bug, the documentation bug is undeniable. A documentation page contains information that is simply inaccurate and incomplete. I believe that they closed this bug prematurely just because you pissed them off. I finally managed to partially replicate some of your results, which I have shared along with a request to reopen the bug.
I posted as soon as I had some results to show because I did not want to delay any longer, but I am still struggling to fully replicate your results. Would you mind clarifying some things for me?
My procudure was to reboot, start tcpdump, open Firefox (having started with a fresh download of Firefox 58 and followed the steps on the documentation page in question), close Firefox, and stop tcpdump. Your tcpdump command as specified in the bug report was
# tcpdump -i eth1 ip src host pc and dst host not router and dst host not pc -ltq
Since I am using WiFi and not Ethernet I changed it to
# tcpdump -i wlan2 ip src host pc and dst host not router and dst host not pc -ltq
which gave me "tcpdump: unknown host 'router'", so I removed 'and dst host not router'
# tcpdump -i wlan2 ip src host pc and dst host not pc -ltq
This gave no errors or warnings, but it also did not show any connections. I had to remove the boolean expressions:
# tcpdump -i wlan2 -ltq
To get any output, which showed connections to cloudfront.net. After removing the arguments '-ltq'
# tcpdump -i wlan2
and examining the output I was able to find some additional urls among the full output, which I listed in my comment requesting that the report be reopened.
So while I can verify that Firefox makes some automatic connections, your results seem a little different from mine, and I'd like to figure out how to replicate more of your results so that I can make a stronger argument in the Mozilla thread.
Some differences between my procedure and yours are that I am using Trisquel 8 instead of OpenSUSE and i3 instead of Plasma, but I do not see a particular reason why this should make a difference. It is more likely that I am doing something wrong because I am not as proficient with tcpdump as you are. It is also possible that I am confusing this specific test with some of the other situations you have tested and that I need to try more situations that simply opening and closing the browser (robots.txt etc.) I have not tried these yet because I am very pressed for time at the moment and believe that showing automatic connections on startup and closing should be enough to justify reopening the bug report, but I can try them if you think it will significantly strengthen our case.
> - "Work offline" does not work offline (sends packets on exiting).
> - The documentation is wrong
> - There is no easy way to get privacy (can be considered a feature request)
You are right on all three points. It would be great to fix all three. This is the strategy I suggest:
(1) Start with the documentation issue. I think we have the best change of persuading them on this point, and if they fix it we will know a little more about how Firefox works, which will inform what we do next.
(2) If (1) was successful, the documentation now explains how to avoid all sending of packets, including in offline mode. This simplifies our next bug report (I'll create it) because we will know what about:config settings need to be changed and can simply request that "Work offline" change those settings. Although the documentation is incomplete, one thing it does well is giving each config change its own section so that you can understand what each one does, so hopefully we can figure out which setting changes are required. If (1) was unsuccessful we will have to request that Mozilla research a fix, but it should still be pretty easy to argue that this is a legitimate bug.
(3) A feature request to make privacy configuration will be more difficult, since Mozilla has a different idea of what constitutes 'privacy', but if (1) and (2) are successful then there is hope for (3). We can request, one at a time, that actions in the documentation that rely on changing values in about:config be replaced with easily accessible settings in "Privacy and Security" like some of these actions already are.
> - They refuse to give even the difficult way to get what the documentation
> promises (can be considered deliberately hiding)
Yes, but if we accuse them of that they will get mad and blow us off. Taking it one improvement at a time will be more subtle.
> Through closing of the ticket they deny community feedback, however
> accurate, objective and detailed it may be.
I'm not ready to give up. I hope my playing 'good cop' will help, but you may be right and they'll continue to ignore the issue. That would suck, but at least we would know that trying to reason with Mozilla is not effective, which will save time in the future.
> They are really telling us "No, you should not trust your eyes, you should
> trust what we say.
Exactly. This is huge problem, and Mozilla isn't even the worst offender. Those with power expand it by convincing people that they are too weak, selfish, and stupid to govern themselves. We can't let them break us.
> They also talk about "anonymized telemetry data". I don't know if you have
> looked at that data but when I started investigating that for the first time
> it I did. It looks like an actual fingerprint of the system. I can see
> strings showing disk capacity, CPU parameters, even the model of the video
> card. Add an IP address to all that and send it to Amazon and Akamai and you
> will know how "private" and "anonymized" all this is.
Even without the IP address I bet the other information is enough to uniquely identifying when combined with basic information about browing habits.
> Re. tcpdump: I learned everything from the man page. Explained:
It's generous of you to spend the time explaining to save me some reading. I'll try to repay the favor by using the time it saves me to support your efforts.
> I think the distro shouldn't matter, neither the desktop environment as long
> as there are no any other network programs adding parasite packets during
> the test.
Agreed. I think it's possible that the different version of Firefox is the issue (I'll try again with 57 to check) but most likely that it's
> because we are on different
> networks, your FF may be connecting to different CDN hosts, so that would
> explain if you see different subdomain part.
in which case it doesn't really matter which or how many automatic connections there are. The fact that there are any after following the documentation is enough to prove that there is a problem.
> This is the strategy I suggest:
Mason and heyjoe, I very much appreciate your efforts, but I would like to put forth a fundamental question: Is this privacy flop inadvertent or is it deliberate?
In the former case, your efforts are well placed and worth it. In the latter case, you would be talking to a wall - actually worse than that, you would be talking to diplomats with an alternative agenda. That is, you can steer them - with much effort - into correction of all the 3 points. But would it matter at all, to figth them in lower levels when they have a high level policy of giving user privacies away to 3rd parties? They would need a watchdog team closely scrutinizing them at all times. They would need to be fought against every time they falter. It would be an endless, futile contention in the end.
For it to be a solution, high level policy must be changed, and this is an issue beyond bug reports.
Even if FOSS community makes it a case and force Mozilla to change their policies (as in the Ubuntu case) what good would it be when management is the same? E.g. would you trust Ubuntu anymore just because they have corrected their minor policies under community pressure? Management being the same, have they changed their higher policies? (I doubt it)
Think about it: Mozilla did decide to collect user specifics and forward this info to 3rd parties, didn't they? This decision cannot be haphazard or inadvertent. It is a sober, deliberate decision. Not a bug. And you will be trying to fight against that decision through bug reports.
You might be wasting your time and energy.
I think the effort should be concentrated on top management of Mozilla (how? I don't know). I doubt they can be forced to change their minds (which really matters), so even targeting top management might not pay off the invested time and effort, but I can't see any other way in the direction of a possible permanent solution.
One can't fight against a top level policy through bug reports. But may be FSF can do something about this. So the best route of action, I believe, is escalating this to FSF's attention.
> Is this privacy flop
> inadvertent or is it deliberate?
It's hard to say. The data sent does provide some benefit that I think could be desirable for many users, but as heyjoe has said users should be aware of it and have an easy way to disable it. Maybe Mozilla intends for the automatic connections to be benign, believes that so few users would want to disable them that it is not worth the trouble of an option to disable them in Preferences, and has some broken documentation that is at least partially related to changes in Firefox (I should try again with ESR). Maybe Mozilla is malicious and the benefits of these automatic connections are simply a cover for their real goals. Maybe Mozilla consists of some well-meaning people who believe they are doing the former and some malicious individuals who are exploting their labor to use it against Firefox users.
> That is, you can steer them - with much effort - into
> correction of all the 3 points. But would it matter at all, to
> figth them in lower levels when they have a high level policy of
> giving user privacies away to 3rd parties?
At minimum it would benefit the Icecat and Abrowser developers, as they would not have to choose between fixing this issue themselves or spending that time doing other useful work. This is especially true with Abrowser. Anything that saves Ruben time will help him to wrap up Trisquel 8 sooner.
If all three points are fixed and many users disable some of these connections, Mozilla may find that they were wrong to assume that not many users would prefer to do so (assuming that this is their real reason, which it may not be), which could inform their policy more broadly.
> would you trust Ubuntu anymore just
> because they have corrected their minor policies under community
> pressure?
Nope, but I'm glad they did for several reasons. One is that no one can defend Ubuntu's actions now that they've implicitly acknowledged that they were wrong by stopping them. Another is that the fewer antifeatures Ruben has to remove from Ubuntu to ensure that Trisquel is privacy-respecting the more time he can spend on other work.
> Think about it: Mozilla did decide to collect user specifics and
> forward this info to 3rd parties, didn't they? This decision cannot
> be haphazard or inadvertent. It is a sober, deliberate decision.
> Not a bug. And you will be trying to fight against that decision
> through bug reports.
You might be right, but I'm uncertain. Mozilla may be selling data for extra profit, but I don't believe it is integral to their business model, so there is at least a chance of them deciding that it is not worth the risk to their reputation. In contrast, I wouldn't even consider bothering to press Google or Facebook on this, because selling data is their business model and they would go out of business if they stopped, and because unlike Mozilla they don't rely on having the appearance of being privacy-friendly for marketing. Quite the opposite, they try to make their users disregard the value of privacy itself.
> You might be wasting your time and energy.
This very well may be true.. Part of the reason I want to start with the documentation bug is to get a sense of how productive additional efforts will be. I think that going that far has some potential reward and negligible risk.
> But
> may be FSF can do something about this. So the best route of
> action, I believe, is escalating this to FSF's attention.
Yes. The kind of high-level policy change that we really need will require a lot of people paying attention to the issue, something we can't achieve but that the FSF could. This creates another potential benefit to these bug reports that will occur if we *fail*. Right now some people might look at the bug report and conclude that Mozilla's response is reasonable. While heyjoe is right in the substance of what he was saying, the conversation started out a little rocky which may distract people from the validity of the points he made. If we give up now and leave it there then we have not made the issue look as serious as it should. However, if we continue to push until Mozilla runs out of excuses, it will be much more obvious that there is a real problem here. This would incentivize the FSF to make this a priority and give them more ammunition should they decide to act.
> This creates another potential benefit to
> these bug reports that will occur if we *fail*.
Hmm never looked at it from this angle. Yes it may be a smart move and effective. Also heyjoe said that RMS will look at the bug report, so FSF is kind of in the process already.
OTOH, there's a subtle difference in our approaches to this strategy: I gather that you want to find out whether there is deliberacy in this bundle, and if there is, you want to make it stick out like a sore thumb. Meanwhile I am sure that there is deliberacy (how can such a decision be not deliberate?) and support this strategy only for the second ("sore thumb") part.
My only concern with this strategy is that, Mozilla may get prudent (but not get "right" at the high level) and cover this up by complying with all your 3 requests, which masks their higher level main approach. OTOH, now that they are caught pants down, it might be better not to give them the chance to cover this blunder up. Because this wouldn't cure the disease but just postpone it only to recur later - and the next recurrence may be graver, and may not be caught by the community (actually this one is not caught by the community either, if it wasn't for heyjoe's efforts this privacy issue would probably pass unnoticed - a big thanks to heyjoe for this).
So I do support your strategy but I'm not quite sure. I'm kind of close to the fence.
I am a translator!
>so that people stop using their products
Nobody cares, unfortunately, amigo Joe el Guitarra
>They will keep doing worse things and become stronger and more arrogant in that.
Sure, the fact that nobody cares means their gooble's greens are not threatened. People will continue using it no matter what antifeature gets added and without even thinking about it. And gooble will throw more money at them.
**give it to them costless and promote it fine and they will buy every single time**
But may I ask, what't the alternative? Use Tor Browser exclusively? Lynx, Mosaic? Wget? Curl?
I am a translator!
>Encrypted smoke signals.
How 'bout dem piggggins?
I am a translator!
>network.allow-experiments;true
The incredibly idiotic feature is disabled though.
experiments.enabled is set to false
Pretty sure that one is the one that controls the entire thingy.
I basically agreed with this when you wrote it. Since then the situation has progressed and I'm reevaluating a few points. You may turn out to have been right on all points anyway, but I'm going to see how things play out before I make a conclusion.
Your other post about Tor Browser is interesting. I have thought about changing all or FF52 or Icecat's about:config to match that of Tor Browser and seeing what happens. If Tor Browser relies on anonymity to solve certain Firefox problems then this will be an incomplete solution, but the Tor developers have probably investigated Firefox more thoroughly than anyone.
I think the effort should be concentrated on top management of Mozilla (how? I don't know).
As a developer yold heyjoe in his first bug report:
Bugzilla is not the place to discuss these topics; the governance mailing list might be the right place for it:
https://lists.mozilla.org/listinfo/governance
https://bugzilla.mozilla.org/show_bug.cgi?id=1424781#c14
I am a translator!
>Yes, it is a problem that Mozilla has managed to brand itself as "the privacy-respecting" browser.
Yes, and Purism promoted itself as the 'first high-end laptop in the world that ships with a fully free operating system'
As long as people are goofy, the opportunists will grow like fungus. It's marketing, the snake charmer.
We need more education and awareness, unfortunately very few seem to care
I am a translator!
Joe le Chitarra mate, just letting you know that Netsurfy is clean as snow, no 'chattering' no nada.
cheers
I am a translator!
Maybe if you paste the output here someone will be able to help you with the issue you are encountering during build time.
I am a translator!
Nope, last version dates 20 Oct 2017.
NetSurf 3.7 features
General
Web standards: HTML 4.01 and CSS 2.1
Image formats including: PNG, GIF, JPEG, SVG, and BMP
HTTPS for secure online transactions
Unicode text
Web page thumbnailing
Local history trees
Global history
Hotlist manager (bookmarks)
Cookie manager
URL completion
Text selection
Scale view
Search-as-you-type text search highlighting
Save pages complete with images
Fast, lightweight layout and rendering engine
------------------------------------------
Disable javascript and firejail it. Make the cookie file and the history files read-only. If I had to make an educated guess I'd say it's more secure than Bloatafox. Just a guess though.
> Netsurfy is clean as snow
Also fast and lightweight.
Unfortunately netsurf is missing in debian testing (buster) for now. It's included in stable and sid, so I assume this exclusion from testing is temporary. Will try it as soon as it appears in buster repos.
I don't read the whole topic but this post was enough to remind me why I use abrowser until today.
However, for some weeks some pages are progressively stopping the 56.0 version used in the abrowser.
Youtube was the first to show notification, followed by Facebook (both allow STILL use).
Soundcloud and Mixcloud no longer allow access, but now, the design of github begins to present problems (and show "Please note that GitHub no longer supports old versions of Firefox.")
Sorry for the bad English, but would anyone know when the next abrowser update will be?
I use Midori as an alternative but depending on the restrictions of the site, it does not go in.
I imagine all this restriction has to do with DRM but I really was not bothering me until I had issues with github.
Regards.
As an alternative to Firefox I suggest the Waterfox browser at www.waterfoxproject.org.
What are your opinion about Waterfox?
I noticed that IceCat is pretty faster than Abrowser on my computer. Why is that?
I don't no, but clarified my doubt.
IceCat 52.3 is more current than abrowser 56 ^^ (besides being faster)
- Login o registrati per inviare commenti