Thanks for pointing me to Epiphany. I tried it many years ago and was not convinced, but now it seems to be very good. Even my bank accepts it! :~)
Proprietary Software? Not even once!
Pyra without decent web browser?
Thanks for pointing me to Epiphany. I tried it many years ago and was not convinced, but now it seems to be very good. Even my bank accepts it! :~)
Proprietary Software? Not even once!
S
sulu
Guest
If we dismiss Firefox for having a questionable future on armhf, Chromium for not being trustworthy and anything Webkit-based to be a security risk then the only remaining full-featured browser in Debian seems to be Qupzilla, as canseco pointed out.
Epiphany is based on Webkit and can therefore not be assumed to be secure in Debian.
Just like SneHebNor, I don't consider a proprietary browser to be a viable option.
Besides, I really wouldn't want to use a browser that is not maintained by Debian in a reasonable way, because I neither want nor can do that on my own and I don't believe this community is up to the huge task of properly maintaining a web browser with all its security implications.
btw:
I've opened a discussion about #787527 in the unofficial German Debianforum [1] and so far we've come to the conclusion that the bug report is still valid.
[1] https://debianforum.de/forum/viewtopic.php?f=29&t=164083
levi
Still fresh, damnit!
FWIW, while Netsurf may not count as 'full-featured' having limited JS support and occasional CSS rendering troubles, does count as 'decent' in my book. That's written in a sensible language, namely C++ IIRC, and doesn't depend on any third party rendering libraries and so on.
S
sulu
Guest
I have to take that statement about Qupzilla back, because when I wrote that I forgot, that except for Firefox and Chromium, NO browser in Debian gets ANY security updates. [1]
[1] https://www.debian.org/releases/stable/armhf/release-notes/ch-information.en.html#browser-security
(It's the same advisory for all supported releases and architectures btw.)
Silent-Hunter
Hardcore Member
- Joined
- May 29, 2010
- Messages
- 3,485
Widevine won't work on the Pyra anyway though, unless there's a armhf version of it. Native client won't likely work either.
[doublepost=1486570869,1486570056][/doublepost]Oh hey they fixed it. It says they added a content management setting you can turn on and off that enables or disables Widevine.
[doublepost=1486570869,1486570056][/doublepost]Oh hey they fixed it. It says they added a content management setting you can turn on and off that enables or disables Widevine.
levi
Still fresh, damnit!
I didn't realise the DMCA stopped white hat hackers testing these plugins, but let them attack Adobe Flash.
Silent-Hunter
Hardcore Member
- Joined
- May 29, 2010
- Messages
- 3,485
Yeah unfortunately the DMCA has extra special protections for DRM software, it's illegal for anyone to crack it for any reason.
Christoph.Krn
Advanced Member
Well, up to this point I would have guessed that this kind of data collection is only in Chrome, but not in Chromium, at least not enabled by default on Debian, considering the story around the creation of Iceweasel back then.
I would argue that, at least for software in the Debian repositories that is seeing any significant amount of use from the userbase, such an intimate kind of data collection is generally not expected to happen out of the blue, but expected to go along with explicit-ish information (for example, in the documentation) to enable users to make an informed decision on whether or not to willingly accept this kind data handling. This kind of documentation is necessary in order to be in harmony with the spirit of free software, because without this knowledge, users wouldn't be able to have control over their computers, the software that they're running, and the data that this software will be processing. What is at the core of the free software spirit, if not to have a greater understanding of what happens with and to data?
As it stands today, I would argue, the data collection behavior of Chromium may be surprising to many Debian users, and in any case is so intimate that it should not take place under any unsuspecting user's radar, who might otherwise not agree with the practice. Obviously, once this intimate user data gets transmitted to a third party's server, there will be no turning back. To assure that all of the the intentions of free software will be met going into a future of Big Data and Internet of Things, there needs to be be a warning system which, at an appropriate moment, provides informational notes about any package's intimate data collection practices, providing an overview over their extent and briefly touching potential ramifications, to ensures that users are able to make informed decisions /before/ data that could be considered intimate irreversibly gets transmitted to other partys' servers.
Additionally, It should be considered to work against having intimate data collection behavior be the default for widely-used software packages that touch wide areas of everyday life. Though, really, informing users when and where they have to stop trusting their software is more important.
Anyone, feel free to iterate on the above...
S
sulu
Guest
The Iceweasel story was only about Firefox' artwork to be considered proprietary. [1] It had nothing to do with Firefox not respecting user's privacy.
Basically it's the same thing with Palemoon now, but Palemoon is just not big enough for Debian to jump through any hoops for it.
While that behavior of Chromium is certainly against the spirit of FLOSS, as RMS had in mind over 30 years ago, it is not against the legal formalization of that spirit in terms of FLOSS licenses.
From a formal POV FLOSS really only cares about licenses, and so does Debian with its DFSG. That leaves loopholes to undermine FLOSS by things like software patents (if applicable) and obscuring FLOSS-licensed code in a way that it formally still is FLOSS but is unmaintainable by 3rd parties in reality. The latter is what #787527 is all about. It's the attempt to find a loophole in a loophole to formally prove, that Chromium in its current shape is not DSFG compliant.
That loophole problem is not solely a problem of FLOSS though. Whenever you try to formalize the spirit of an idea into a legal construct, there will be loopholes. And there will be people looking for how to use these loopholes to their advantage. In fact, FLOSS itself uses such a loophole. It turns copyright against itself (creating copyleft) by allowing the copyright holder in a legally safe way to waive any rights that are usually associated with copyright or, depending on the license, even giving him the power to make others waive these rights.
Now, especially Google has become a master of using these loopholes in FLOSS to its advantage. They are geniuses in PR and have found out, that FLOSS can be a selling point, especially for people who blindly trust labels instead of digging deep to find out what's behind the label they trust.
Google releases most of its code under FLOSS licenses. So they get the label. But they mangle code, have at least in the past delayed the release of code (not sure if they still do that) and as an entity are not truly interested in the spirit of FLOSS (otherwise they wouldn't be the data kraken they are).
[1] https://en.wikipedia.org/wiki/Mozilla_software_rebranded_by_Debian
Christoph.Krn
Advanced Member
@sulu Sure, I know about all of these things (never talked about FLOSS specifically). But do you agree with the general thinking that I've lined out? That the question of whether or not a software transmits masses of intimate data of yours to a third party is not less important than the question of whether or not a software is proprietary? That it's an ever more important aspect going into the future, and that formally "regulating" data collection is a difficult topic, but not so important, because the better way is to make sure that users will have the necessary knowledge to make informed decisions about it?
Debian's development is based on ideas from a past where this aspect hasn't been a common concern, of course it would be difficult to put into the legal construct as an afterthought. But I would assume that there are many FLOSS developers who would agree that extensive data collection /is/ a problem these days, and potentially getting bigger and bigger. I could imagine some FLOSS developers agreeing with the idea of an automatic "intimate data collection" informational note system (whatever shape and form that may have). Do you happen to ever have seen such a system being proposed/discussed anywhere before?
Debian's development is based on ideas from a past where this aspect hasn't been a common concern, of course it would be difficult to put into the legal construct as an afterthought. But I would assume that there are many FLOSS developers who would agree that extensive data collection /is/ a problem these days, and potentially getting bigger and bigger. I could imagine some FLOSS developers agreeing with the idea of an automatic "intimate data collection" informational note system (whatever shape and form that may have). Do you happen to ever have seen such a system being proposed/discussed anywhere before?
S
sulu
Guest
I totally agree.
But from a formal POV, Debian (and FLOSS in general) is powerless against these threats, because FLOSS is not about privacy. It's about software licenses. You can only try to shoehorn privacy into it by finding loopholes that turn a privacy concern into a technical or license concern, or you can add further requirements beyond pure FLOSS.
Debian even has such additional requirements, represented by the DSC, but the DSC says nothing about privacy. In fact, it could be argued, that in terms of privacy, even Google had(!) a marginally clearer formal POV, coined by their former motto: "Don't be evil." And we know how that turned out.
The only thing in Debian that currently protects us from privacy violation is the good will of its maintainers. While I generally believe those to be trustworthy, there is no formally correct way to protect us from the occasional black sheep. To change that situation nothing short of a rework of the principles of the DSC would be necessary. This is nothing we, as ordinary users, can fix by filing bug reports against individual packages.
levi
Still fresh, damnit!
Maybe it's time for a GPLv4? Just as the Tivo was (as I remember) the straw that broke the camel's back wrt GPLv2, and gave us GPLv3, this could be the spark that gives us GPLv4. As you hint at, this could be tricky to encode in legal language - after all a simple web browser could be validly described as a privacy risk due to cookies, and specifically how advertisers use them.
comradekingu
Glowing ember
S
sulu
Guest
I'm not sure I'd like that. I don't even fully understand GPLv3 and I'm pretty sure GPLv4 wouldn't be any easier to understand if it includes a whole new topic.
The first two are not in Debian and the latter is not maintained. Are you volunteering and qualified to maintain a highly used and highly security-sensitive application for the whole Pyra community, which due to its demographic probably has a lot of people who would totally depend on you making the right calls?
Don't get me wrong, I'm certain that someone here could provide packages and regular updates for the community. ptitSeb comes to mind and I could probably do it myself if I actually followed upstream's development.
But I know that I m not qualified to judge the impacts of CVE's in an armhf and/or Pyra specific context. And I doubt that someone else here has these qualifications. So the result of such packages would be no better than a Rust-enabled Firefox with a Rust team that doesn't actually care for clean builds on armhf. It would work, but it wouldn't be trustworthy.
Last edited by a moderator:
We have our own Pyra Debian repositories.
If these browsers have a git and compile without any issues, it might be possible setting up an automatic build.
If these browsers have a git and compile without any issues, it might be possible setting up an automatic build.
S
sulu
Guest
But that's just the point. If you compile them automatically whenever there is an upstream change, then you will tend to not look closely at the build logs or at upstream's advices.* So any non-fatal problems will probably go unnoticed for a long time.
If these problems are also architecture-specific, then chances are, that upstream won't notice either because they probably don't test on armhf in the first place.
I know I'm being pedantic here, but I think I am for a reason. The web browser is probably the most critical user space program. It is likely the most-used single application, it sees a lot of private data from its user and due to being inherently and constantly connected to the internet it presents a huge attack vector.
So one should exercise special caution when dealing with this type of program. In my opinion that includes not trusting in automatic build processes without constant qualified human supervision.
*) I'm a software maintainer in my company, so I know how these things tend to go. After all, people are lazy.
Ziz
Advanced Member
- Joined
- Jan 15, 2006
- Messages
- 3,583
QT 5.7.1 is only 2 months old.
I guess the debian maintainers focus on fixing bugs for the next stable release.
