Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

2018-02-22 Thread Narcis Garcia
The key word is: REPOSITORIES.
Scripts should be downloaded as software packages, and those packages
should come from a trusted repository. Each one of those scripts should
be registered accompanied with metadata: Name+Version, md5/hash, license
and features (same as F-Droid + APK).

If a web developer publishes with scripts, those scripts should include
at least Name+Version and md5/hash. First time IceCat visits that
website, it should download script from trusted repository (NOT SAME
WEBSITE). Next times, if not cached, IceCat could get user-approved
script from same website verifying recorded md5/hash matches.

If a web developer wanted a script be publicly trusted, he/she should
upload it to a repository (same as F-Droid process). There can be more
or less strict repositories on the net, same as user can trust more or
less repositories.
New script versions should have to be uploaded too.


El 23/02/18 a les 06:14, Julie Marchant ha escrit:
> On 2018年02月22日 21:50, bill-auger wrote:
>> so its not really accurate to say that libreJS is inherently ineffective
>> - it is just not widely adopted enough to realize its potential - if it
>> becomes significantly popular enough for people to start gaming and
>> cheating it then surely it would also become more robust over time as
>> there would be more effort put into its development and maintenance
>> (e.g. a volunteer team of license checking monkeys)
> 
> I think this is wishful thinking. What could you possibly do, maintain a
> giant list of websites that are mislabeling their proprietary scripts as
> libre?
> 
> And ultimately, that's not the real problem. The real problem is that
> LibreJS solves nothing. It's blocking some scripts, but not all. As I
> argued here:
> 
> https://onpon4.github.io/articles/kill-js.html
> 
> *Even if* these websites were serving 100% libre JavaScript, it is
> still, from a practical standpoint, impossible for the user to
> reasonably exercise freedom 1. You can't make any Web browser that
> currently exists run modified JavaScript code (unless you manage to
> convert it to user script code, which is a different syntax), and while
> you can audit the script, the server is able to change to another script
> without notice.
> 
> The problem here is that JavaScript, as it is used on Web pages, is,
> *fundamentally*, incompatible with software freedom.
> 
> That's why I have proposed that the only way any of that JavaScript code
> can *ever* be acceptable is with a fundamental rehaul of the way our
> browsers handle JavaScript code, and such a rehaul would take a whole
> lot of work. So I really think it would be easier to just fight against
> JavaScript *entirely*.
> 
> Create a browser that shows the merits of a scriptless Web. Advertise it
> as non-exploitable, because if it doesn't run scripts from random
> untrusted sources, it is. Show people that this world, where just
> navigating to the wrong Web page can potentially screw up your entire
> system, is a world we don't have to live in. Show them that Web pages
> don't have to take centuries to load. Show them that we don't have to
> deal with annoying pop-up messages and bizarre, unexpected behavior when
> clicking on a link.
> 
> And what's more, show them that we don't have to live in a world where
> not updating your Web browser every week leaves you vulnerable.
> 
> I truly believe we can change the Web in this way. Many websites are
> already there. But we need to actually be working toward it, as a group,
> with a good browser backing this up. Exactly *what* JavaScript code is
> being executed is merely a distraction. Let's band together and solve
> the real problem, right here and now.
> 
> Some time ago, I offered a bounty to anyone who would write a certain
> extension. I think it was $50? I don't remember for sure. But I am still
> offering that bounty, so either $50, or if it was larger, what I said
> back then. The extension I am offering a bounty for is one that does the
> following:
> 
> 1. Blocks *all* JavaScript code, regardless of what it does.
> 2. Adds a "danger button" which allows all JavaScript code to execute
> for the current page,* for a very short period of time (e.g. 5 minutes),
> and then reloads the page.
> 3. (Optional, +$10) Adds a "super danger button" which allows all
> JavaScript code to execute for any page on the current domain for the
> remainder of the session. A second click on this button would revert this.
> 4. (Optional, +$15) Offers LibreJS's complaint feature, with the default
> suggested complaint requesting the webmaster to remove all JavaScript
> dependencies from their website.
> 
> * Note that this would be based on what the current page's source is,
> not where the JavaScript files themselves come from, so this is
> completely different from what NoScript does. For example, if
> foo.com/example.html uses scripts from its own domain but also scripts
> from bar.com and baz.net, *all* of these scripts would execute normally
> 

Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

2018-02-22 Thread Julie Marchant
On 2018年02月22日 21:50, bill-auger wrote:
> so its not really accurate to say that libreJS is inherently ineffective
> - it is just not widely adopted enough to realize its potential - if it
> becomes significantly popular enough for people to start gaming and
> cheating it then surely it would also become more robust over time as
> there would be more effort put into its development and maintenance
> (e.g. a volunteer team of license checking monkeys)

I think this is wishful thinking. What could you possibly do, maintain a
giant list of websites that are mislabeling their proprietary scripts as
libre?

And ultimately, that's not the real problem. The real problem is that
LibreJS solves nothing. It's blocking some scripts, but not all. As I
argued here:

https://onpon4.github.io/articles/kill-js.html

*Even if* these websites were serving 100% libre JavaScript, it is
still, from a practical standpoint, impossible for the user to
reasonably exercise freedom 1. You can't make any Web browser that
currently exists run modified JavaScript code (unless you manage to
convert it to user script code, which is a different syntax), and while
you can audit the script, the server is able to change to another script
without notice.

The problem here is that JavaScript, as it is used on Web pages, is,
*fundamentally*, incompatible with software freedom.

That's why I have proposed that the only way any of that JavaScript code
can *ever* be acceptable is with a fundamental rehaul of the way our
browsers handle JavaScript code, and such a rehaul would take a whole
lot of work. So I really think it would be easier to just fight against
JavaScript *entirely*.

Create a browser that shows the merits of a scriptless Web. Advertise it
as non-exploitable, because if it doesn't run scripts from random
untrusted sources, it is. Show people that this world, where just
navigating to the wrong Web page can potentially screw up your entire
system, is a world we don't have to live in. Show them that Web pages
don't have to take centuries to load. Show them that we don't have to
deal with annoying pop-up messages and bizarre, unexpected behavior when
clicking on a link.

And what's more, show them that we don't have to live in a world where
not updating your Web browser every week leaves you vulnerable.

I truly believe we can change the Web in this way. Many websites are
already there. But we need to actually be working toward it, as a group,
with a good browser backing this up. Exactly *what* JavaScript code is
being executed is merely a distraction. Let's band together and solve
the real problem, right here and now.

Some time ago, I offered a bounty to anyone who would write a certain
extension. I think it was $50? I don't remember for sure. But I am still
offering that bounty, so either $50, or if it was larger, what I said
back then. The extension I am offering a bounty for is one that does the
following:

1. Blocks *all* JavaScript code, regardless of what it does.
2. Adds a "danger button" which allows all JavaScript code to execute
for the current page,* for a very short period of time (e.g. 5 minutes),
and then reloads the page.
3. (Optional, +$10) Adds a "super danger button" which allows all
JavaScript code to execute for any page on the current domain for the
remainder of the session. A second click on this button would revert this.
4. (Optional, +$15) Offers LibreJS's complaint feature, with the default
suggested complaint requesting the webmaster to remove all JavaScript
dependencies from their website.

* Note that this would be based on what the current page's source is,
not where the JavaScript files themselves come from, so this is
completely different from what NoScript does. For example, if
foo.com/example.html uses scripts from its own domain but also scripts
from bar.com and baz.net, *all* of these scripts would execute normally
with the "danger button", but *only* if the user is on foo.com/example.html.

I think such an extension would serve the purpose of killing JavaScript
very well because it would be a browser people would actually use (it is
not terribly inconvenient; all websites are still usable), but it would
cause no JavaScript to be the default. Users would be lured into the
extension by the fact that it keeps your browser secure, and they would
be won over by the fact that most pages work *better* without pressing
the "danger button". Watching a lot of YouTube videos? Applying for a
job? Shopping at Ebay? No worries; press the "Super Danger Button" and
be on your way.

With both optional features, that would be $75 for anyone willing to
write this.

-- 
Julie Marchant
https://onpon4.github.io



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

2018-02-22 Thread bill-auger
On 02/22/2018 12:59 PM, Ivan Zaigralin wrote:
> in order to placate LibreJS:
> 

i.e. "aint nobody here but us chickens"


i think it is safe to say that any web dev today who cares enough to
"placate LibreJS" is almost certainly not intending any deception -
LibreJS is very effective in blocking un-licensed "non-trivial" scripts
- if the majority of free javascripts were annotated properly then
LibreJS would block fewer scripts

web devs are not going to take any interest in LibreJS until *after* a
significant percentage of their site visitor start using it and either
the users complain or the web master see the page hits if the scripts
plummet - unfortunately *then* there would be the opposite problem:
namely the incentive to mis-represent the licensing

so its not really accurate to say that libreJS is inherently ineffective
- it is just not widely adopted enough to realize its potential - if it
becomes significantly popular enough for people to start gaming and
cheating it then surely it would also become more robust over time as
there would be more effort put into its development and maintenance
(e.g. a volunteer team of license checking monkeys)



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

2018-02-22 Thread bill-auger
On 02/22/2018 02:56 PM, David Hedlund wrote:
> On 2018-02-22 09:22, Ivan Zaigralin wrote:
>> GPL-licensed code is not necessarily free. An obfuscated source is
>> unmaintainable regardless of the license, so two freedoms are taken
>> away: the freedom to study, and the freedom to run modified versions.
>> LibreJS is unable to detect obfuscated code.
>
> Thank you. This is a bug, can you please file a bug report to
> https://savannah.gnu.org/bugs/?group=librejs ?


david - ivan was not reporting any bug that could be fixed - he was
saying that it is impossible for libreJS to determine if a script is
obfuscated or the original source - if the only available version of the
script is obfuscated then the GPL does not apply because all
requirements are not satisfiable - for this reason, any yet unseen
obfuscated script should be considered non-free regardless of it's
reported license

the only way libreJS can accurately deem a script to be free is either
if it is an original non-obfuscated source that matches identically to a
previously cataloged copy that has a verified license or an it is an
obfuscated script that matches identically to a previously cataloged
copy of an obfuscated script which has been previously verified to have
been produced from the original source that has a verified license -
beyond that, i think the halting problem would need to be solved first

just as you do for the FSD, this would require a human to verify the
reported license of each and every yet un-cataloged script then either
shipping with libreJS checksums for all known scripts on earth as a
white-list or having every script that every user downloads sent to a
central server for verification which would be as much of a privacy
concern as the script itself - also it should be clear from that any
such catalog would be incomplete at best, especially at the rate the web
changes




signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] Alsa IceCat

2018-02-22 Thread Damien Zammit

I got JACK support for IceCat merged into Fedora.
Jack support is already in Firefox, just add --enable-jack at compile 
time to the mozconfig.


This might be better than using ALSA since ALSA will block the sound 
card for other audio apps.


Damien

On 23/02/18 08:00, Gary wrote:

On Feb 22, 2018, at 3:28 AM, al3xu5 wrote:

I have explicity enabled alsa support and disabled pulseaudio

Perhaps I should switch to alsa as pulseaudio is the one that I always have 
trouble with...
--
http://gnuzilla.gnu.org



--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] Alsa IceCat

2018-02-22 Thread Gary
On Feb 22, 2018, at 3:28 AM, al3xu5 wrote:
> 
> I have explicity enabled alsa support and disabled pulseaudio

Perhaps I should switch to alsa as pulseaudio is the one that I always have 
trouble with...
--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

2018-02-22 Thread David Hedlund



On 2018-02-22 09:22, Ivan Zaigralin wrote:

On Thursday, February 22, 2018 01:04:30 bill-auger wrote:

this is confusing - what exactly is a
"drive-by-download" and how are they inherently "non-free no matter what
license is attached to them"?

also, how could LibreJS "incorrectly mark an obfuscated piece of
GPL-licensed code as free" - GPL-licensed code IS free

GPL-licensed code is not necessarily free. An obfuscated source is
unmaintainable regardless of the license, so two freedoms are taken away: the
freedom to study, and the freedom to run modified versions. LibreJS is unable
to detect obfuscated code.


Thank you. This is a bug, can you please file a bug report to 
https://savannah.gnu.org/bugs/?group=librejs ?


Please report all your bugs to that page.



What I mean by drive-by-downloading, here we get philosophical. How free is
the code which is only meant to be executed once? No one audits > 99% of this
code, and it's all in constant flux. I would even argue, there's no hope it
can ever be audited. There are already (I am sure) websites that generate
brand-new code for every visit, making this assertion literal. How do you
audit all that code? With an automated tool? An algorithm can't even solve a
halting problem, let alone audit itself out of a paper bag.

Now put yourself in the shoes of an average web user. Average here is the key
word. Their freedoms to understand and modify the JavaScript code have all but
completely eroded. In a traditional software distribution market they can hire
experts to explain and fix the software for them. This is utterly unaffordable
if every click generates new software.

And now back to drive-by-downloading, which is important because it is perhaps
the source of the problem. All of this is happening, as we all know very well,
because average users are willing to run software from any source, as long as
it doesn't make their computer explode right away. They don't even understand
the basic difference between downloading data versus downloading and executing
an arbitrary algorithm. When a blog, or a news site, or a government website
won't load because you didn't let it run an arbitrary algorithm on your
computer, that's crazy, just crazy. And the norm. These users who leave all
JavaScript on, they already buried 2 of their freedoms, and the boilerplate
license on the disposable code can't change that. They need to be told to
boycott sites which require JS to function, and to demand legislation which
would require something like HTML+CSS web fronts from commercial and
government entities. It is not at all helpful, in my opinion, to differentiate
between varieties of JavaScript sources, because none of them should be
downloaded in the first place. Most importantly, web masters who want a free
web should stop using JavaScript, and they should be transitioning right now,
and not stop until there's nothing left for LibreJS to mark as free. All
desired JavaScript functionality can be trivially recreated via a combination
of free browser plugins and calls to free and standard libraries. The drive-
by-download culture, on the other hand, will plunge us deeper into the sea of
disposable software.


--
http://gnuzilla.gnu.org


--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] Why IceCat discontinued official macOS and Windows releases

2018-02-22 Thread Gary
Looks good now -- thanks!

On Thu, Feb 22, 2018 at 7:45 AM, The Canadian Bacon 
wrote:

> Just confirmed myself now seems WordPress bumped a table in my plugin and
> readjusted things. It should work properly now.
>
> On Feb 22, 2018 8:59 AM, "David Hedlund"  wrote:
>
>> I can confirm that the "Download Source" (https://casualgamer.ca/index.
>> php/download/55/) link found at https://casualgamer.ca/index.p
>> hp/unofficial-icecat-builds/ is still broken.
>>
>> On 2018-02-22 12:59, The Canadian Bacon wrote:
>>
>> Perhaps your cache needs to be cleared because I'm able to access the
>> files via the page link from my laptop, phone, Desktop and soon I'll be
>> able to verify from a work PC. I'll let you know what's up if there's an
>> issue, but as far as I can tell, issue seems to be isolated to your end.
>>
>> On Feb 22, 2018 3:19 AM, "Gary"  wrote:
>>
>>> the link is from your icecat page linked from your front page...
>>>
>>> On Feb 22, 2018, at 12:05 AM, The Canadian Bacon 
>>> wrote:
>>>
>>> You're using an old link.
>>> https://casualgamer.ca/index.php/unofficial-icecat-builds/
>>>
>>> On Feb 22, 2018 12:09 AM, "Gary"  wrote:
>>>
 I don't think this is true for the macOS build but the Windows binaries
 can be cross-compiled under Linux. The only downside I see to that is that
 it's not signed nor is there an installer generated. So it sounds more like
 this is just a decision based on time vs GNU philosophy.

 Also, to the person that's hosting the unofficial binaries; it looks
 like your link to the source is broken: https://casualgamer.ca/index.p
 hp/download/55/ leads to a "Download does not exist" page.

 -Gary



 On Tue, Feb 20, 2018 at 10:21 AM, David Hedlund 
 wrote:

> People wonder why Rubén Rodríguez discontinued Windows and macOS
> releases for IceCat after version 38.8.0. I asked him to clarify this on
> https://www.gnu.org/software/gnuzilla/ which he updated immediately:
>
> "Note that building binary packages for Windows and macOS
> currently requires non-free software, so we no longer distribute binary
> releases for those platforms."
>
>
> Unofficial download links for macOS and Windows are listed in
> https://directory.fsf.org/wiki/IceCat#tab=Details
>
>
> --
> http://gnuzilla.gnu.org
>


 --
 http://gnuzilla.gnu.org


>>> --
>>> http://gnuzilla.gnu.org
>>>
>>>
>>
>> --http://gnuzilla.gnu.org
>>
>>
>>
>> --
>> http://gnuzilla.gnu.org
>>
>>
> --
> http://gnuzilla.gnu.org
>
>
--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

2018-02-22 Thread Ivan Zaigralin
I am not sure about the details, but this page explains what the web masters 
are expected to do, annotation-wise, in order to placate LibreJS:

https://www.gnu.org/software/librejs/free-your-javascript.html

I would not call this strategy crazy, but ineffective, yes. What's crazy is 
the common user behavior of allowing their computers to download and execute 
the code from literally dozens of independent sources, none of it audited ever 
by anyone, every time they reload a web page. To add insult to injury, 99% of 
these web pages would be fully functional and much faster if they were 
implemented in flat HTML+CSS.

On Thursday, February 22, 2018 18:50:30 Narcis Garcia wrote:
> It seems a crazy strategy.
> If GNU distributions used this kind of analysis instead of trusting
> software from subscribed repositories, all our computers could be a
> jungle (either with scripts and compiled files).
> 
> How does LibreJS check an script's license?
> 
> El 22/02/18 a les 18:43, Ivan Zaigralin ha escrit:
> > From what I can pick up, LibreJS tries to detect and whitelist "trivial"
> > code first, meaning, the code which an algorithm can recognize as
> > data-like and harmless. For all other code, it checks the license. I
> > don't have details on how these things are done, but both can clearly be
> > programmed in a variety of ways.
> > 
> > On Thursday, February 22, 2018 10:57:28 Narcis Garcia wrote:
> >> I was asking about the CURRENT principle for LibreJS, not for "good" or
> >> "bad" of theoretically prossibilities.
> >> 
> >> El 22/02/18 a les 09:35, Ivan Zaigralin ha escrit:
> >>> On Thursday, February 22, 2018 08:43:38 Narcis Garcia wrote:
>  Which is the principle for LibreJS to approve JavaScript functions
>  and/or files?
>  A license mention?
> >>> 
> >>> Can be regarded as necessary, but not sufficient.
> >>> 
>  A signature?
> >>> 
> >>> Useful for creating a trust model between users and web parties, but
> >>> this
> >>> is already implemented by https+noscript, and it solves a different
> >>> problem, not directly freedom-related.
> >>> 
>  A well-known functions comparison? A code analysis? It replaces
>  funcions?
> >>> 
> >>> A code analysis is pointless. Detecting obfuscated code, in particular,
> >>> is
> >>> an intractable problem. If you could define "obfuscated" formally,
> >>> chances are, there would be a formal proof that the detection is
> >>> unsolvable by a TM. But generally speaking, a good way to obfuscate is
> >>> by
> >>> writing a virtual assembly interpreter, and then feeding it "binaries"
> >>> which appear to be perfectly cromulent, poetic even, JavaScript sources.
> >>> And obfuscated code cannot be considered free.
> >>> 
> >>> None of this is purely academic. Dynamic, obfuscated JavaScript bitcash
> >>> miners are all the rage right now. This is where we are today.
> >>> 
> >>> 
> >>> 
> >>> --
> >>> http://gnuzilla.gnu.org
> >> 
> >> --
> >> http://gnuzilla.gnu.org
> >> 
> >> 
> >> --
> >> http://gnuzilla.gnu.org
> 
> --
> http://gnuzilla.gnu.org

signature.asc
Description: This is a digitally signed message part.
--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

2018-02-22 Thread Loic Duros
It looks for license metadata in the following forms: 
https://www.gnu.org/software/librejs/free-your-javascript.html 



> On Feb 22, 2018, at 12:50 PM, Narcis Garcia  wrote:
> 
> It seems a crazy strategy.
> If GNU distributions used this kind of analysis instead of trusting
> software from subscribed repositories, all our computers could be a
> jungle (either with scripts and compiled files).
> 
> How does LibreJS check an script's license?
> 
> 
> El 22/02/18 a les 18:43, Ivan Zaigralin ha escrit:
>> From what I can pick up, LibreJS tries to detect and whitelist "trivial" 
>> code 
>> first, meaning, the code which an algorithm can recognize as data-like and 
>> harmless. For all other code, it checks the license. I don't have details on 
>> how these things are done, but both can clearly be programmed in a variety 
>> of  
>> ways.
>> 
>> On Thursday, February 22, 2018 10:57:28 Narcis Garcia wrote:
>>> I was asking about the CURRENT principle for LibreJS, not for "good" or
>>> "bad" of theoretically prossibilities.
>>> 
>>> El 22/02/18 a les 09:35, Ivan Zaigralin ha escrit:
 On Thursday, February 22, 2018 08:43:38 Narcis Garcia wrote:
> Which is the principle for LibreJS to approve JavaScript functions
> and/or files?
> A license mention?
 
 Can be regarded as necessary, but not sufficient.
 
> A signature?
 
 Useful for creating a trust model between users and web parties, but this
 is already implemented by https+noscript, and it solves a different
 problem, not directly freedom-related.
 
> A well-known functions comparison? A code analysis? It replaces funcions?
 
 A code analysis is pointless. Detecting obfuscated code, in particular, is
 an intractable problem. If you could define "obfuscated" formally,
 chances are, there would be a formal proof that the detection is
 unsolvable by a TM. But generally speaking, a good way to obfuscate is by
 writing a virtual assembly interpreter, and then feeding it "binaries"
 which appear to be perfectly cromulent, poetic even, JavaScript sources.
 And obfuscated code cannot be considered free.
 
 None of this is purely academic. Dynamic, obfuscated JavaScript bitcash
 miners are all the rage right now. This is where we are today.
 
 
 
 --
 http://gnuzilla.gnu.org
>>> 
>>> --
>>> http://gnuzilla.gnu.org
>>> 
>>> 
>>> --
>>> http://gnuzilla.gnu.org
> 
> --
> http://gnuzilla.gnu.org
> 

--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

2018-02-22 Thread Narcis Garcia
It seems a crazy strategy.
If GNU distributions used this kind of analysis instead of trusting
software from subscribed repositories, all our computers could be a
jungle (either with scripts and compiled files).

How does LibreJS check an script's license?


El 22/02/18 a les 18:43, Ivan Zaigralin ha escrit:
> From what I can pick up, LibreJS tries to detect and whitelist "trivial" code 
> first, meaning, the code which an algorithm can recognize as data-like and 
> harmless. For all other code, it checks the license. I don't have details on 
> how these things are done, but both can clearly be programmed in a variety of 
>  
> ways.
> 
> On Thursday, February 22, 2018 10:57:28 Narcis Garcia wrote:
>> I was asking about the CURRENT principle for LibreJS, not for "good" or
>> "bad" of theoretically prossibilities.
>>
>> El 22/02/18 a les 09:35, Ivan Zaigralin ha escrit:
>>> On Thursday, February 22, 2018 08:43:38 Narcis Garcia wrote:
 Which is the principle for LibreJS to approve JavaScript functions
 and/or files?
 A license mention?
>>>
>>> Can be regarded as necessary, but not sufficient.
>>>
 A signature?
>>>
>>> Useful for creating a trust model between users and web parties, but this
>>> is already implemented by https+noscript, and it solves a different
>>> problem, not directly freedom-related.
>>>
 A well-known functions comparison? A code analysis? It replaces funcions?
>>>
>>> A code analysis is pointless. Detecting obfuscated code, in particular, is
>>> an intractable problem. If you could define "obfuscated" formally,
>>> chances are, there would be a formal proof that the detection is
>>> unsolvable by a TM. But generally speaking, a good way to obfuscate is by
>>> writing a virtual assembly interpreter, and then feeding it "binaries"
>>> which appear to be perfectly cromulent, poetic even, JavaScript sources.
>>> And obfuscated code cannot be considered free.
>>>
>>> None of this is purely academic. Dynamic, obfuscated JavaScript bitcash
>>> miners are all the rage right now. This is where we are today.
>>>
>>>
>>>
>>> --
>>> http://gnuzilla.gnu.org
>>
>> --
>> http://gnuzilla.gnu.org
>>
>>
>> --
>> http://gnuzilla.gnu.org

--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

2018-02-22 Thread Ivan Zaigralin
From what I can pick up, LibreJS tries to detect and whitelist "trivial" code 
first, meaning, the code which an algorithm can recognize as data-like and 
harmless. For all other code, it checks the license. I don't have details on 
how these things are done, but both can clearly be programmed in a variety of  
ways.

On Thursday, February 22, 2018 10:57:28 Narcis Garcia wrote:
> I was asking about the CURRENT principle for LibreJS, not for "good" or
> "bad" of theoretically prossibilities.
> 
> El 22/02/18 a les 09:35, Ivan Zaigralin ha escrit:
> > On Thursday, February 22, 2018 08:43:38 Narcis Garcia wrote:
> >> Which is the principle for LibreJS to approve JavaScript functions
> >> and/or files?
> >> A license mention?
> > 
> > Can be regarded as necessary, but not sufficient.
> > 
> >> A signature?
> > 
> > Useful for creating a trust model between users and web parties, but this
> > is already implemented by https+noscript, and it solves a different
> > problem, not directly freedom-related.
> > 
> >> A well-known functions comparison? A code analysis? It replaces funcions?
> > 
> > A code analysis is pointless. Detecting obfuscated code, in particular, is
> > an intractable problem. If you could define "obfuscated" formally,
> > chances are, there would be a formal proof that the detection is
> > unsolvable by a TM. But generally speaking, a good way to obfuscate is by
> > writing a virtual assembly interpreter, and then feeding it "binaries"
> > which appear to be perfectly cromulent, poetic even, JavaScript sources.
> > And obfuscated code cannot be considered free.
> > 
> > None of this is purely academic. Dynamic, obfuscated JavaScript bitcash
> > miners are all the rage right now. This is where we are today.
> > 
> > 
> > 
> > --
> > http://gnuzilla.gnu.org
> 
> --
> http://gnuzilla.gnu.org

signature.asc
Description: This is a digitally signed message part.
--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] Why IceCat discontinued official macOS and Windows releases

2018-02-22 Thread The Canadian Bacon
Just confirmed myself now seems WordPress bumped a table in my plugin and
readjusted things. It should work properly now.

On Feb 22, 2018 8:59 AM, "David Hedlund"  wrote:

> I can confirm that the "Download Source" (https://casualgamer.ca/index.
> php/download/55/) link found at https://casualgamer.ca/index.
> php/unofficial-icecat-builds/ is still broken.
>
> On 2018-02-22 12:59, The Canadian Bacon wrote:
>
> Perhaps your cache needs to be cleared because I'm able to access the
> files via the page link from my laptop, phone, Desktop and soon I'll be
> able to verify from a work PC. I'll let you know what's up if there's an
> issue, but as far as I can tell, issue seems to be isolated to your end.
>
> On Feb 22, 2018 3:19 AM, "Gary"  wrote:
>
>> the link is from your icecat page linked from your front page...
>>
>> On Feb 22, 2018, at 12:05 AM, The Canadian Bacon 
>> wrote:
>>
>> You're using an old link.
>> https://casualgamer.ca/index.php/unofficial-icecat-builds/
>>
>> On Feb 22, 2018 12:09 AM, "Gary"  wrote:
>>
>>> I don't think this is true for the macOS build but the Windows binaries
>>> can be cross-compiled under Linux. The only downside I see to that is that
>>> it's not signed nor is there an installer generated. So it sounds more like
>>> this is just a decision based on time vs GNU philosophy.
>>>
>>> Also, to the person that's hosting the unofficial binaries; it looks
>>> like your link to the source is broken: https://casualgamer.ca/index.p
>>> hp/download/55/ leads to a "Download does not exist" page.
>>>
>>> -Gary
>>>
>>>
>>>
>>> On Tue, Feb 20, 2018 at 10:21 AM, David Hedlund 
>>> wrote:
>>>
 People wonder why Rubén Rodríguez discontinued Windows and macOS
 releases for IceCat after version 38.8.0. I asked him to clarify this on
 https://www.gnu.org/software/gnuzilla/ which he updated immediately:

 "Note that building binary packages for Windows and macOS currently
 requires non-free software, so we no longer distribute binary releases for
 those platforms."


 Unofficial download links for macOS and Windows are listed in
 https://directory.fsf.org/wiki/IceCat#tab=Details


 --
 http://gnuzilla.gnu.org

>>>
>>>
>>> --
>>> http://gnuzilla.gnu.org
>>>
>>>
>> --
>> http://gnuzilla.gnu.org
>>
>>
>
> --http://gnuzilla.gnu.org
>
>
>
> --
> http://gnuzilla.gnu.org
>
>
--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] Why IceCat discontinued official macOS and Windows releases

2018-02-22 Thread David Hedlund
I can confirm that the "Download Source" 
(https://casualgamer.ca/index.php/download/55/) link found at 
https://casualgamer.ca/index.php/unofficial-icecat-builds/ is still broken.



On 2018-02-22 12:59, The Canadian Bacon wrote:
Perhaps your cache needs to be cleared because I'm able to access the 
files via the page link from my laptop, phone, Desktop and soon I'll 
be able to verify from a work PC. I'll let you know what's up if 
there's an issue, but as far as I can tell, issue seems to be isolated 
to your end.


On Feb 22, 2018 3:19 AM, "Gary" > wrote:


the link is from your icecat page linked from your front page...

On Feb 22, 2018, at 12:05 AM, The Canadian Bacon
> wrote:


You're using an old link.
https://casualgamer.ca/index.php/unofficial-icecat-builds/


On Feb 22, 2018 12:09 AM, "Gary" > wrote:

I don't think this is true for the macOS build but the
Windows binaries can be cross-compiled under Linux. The only
downside I see to that is that it's not signed nor is there
an installer generated. So it sounds more like this is just a
decision based on time vs GNU philosophy.

Also, to the person that's hosting the unofficial binaries;
it looks like your link to the source is broken:
https://casualgamer.ca/index.php/download/55/
 leads to a
"Download does not exist" page.

-Gary



On Tue, Feb 20, 2018 at 10:21 AM, David Hedlund
> wrote:

People wonder why Rubén Rodríguez discontinued Windows
and macOS releases for IceCat after version 38.8.0. I
asked him to clarify this on
https://www.gnu.org/software/gnuzilla/
 which he updated
immediately:

    "Note that building binary packages for Windows and
macOS currently requires non-free software, so we no
longer distribute binary releases for those platforms."


Unofficial download links for macOS and Windows are
listed in
https://directory.fsf.org/wiki/IceCat#tab=Details



--
http://gnuzilla.gnu.org



--
http://gnuzilla.gnu.org



--
http://gnuzilla.gnu.org



--
http://gnuzilla.gnu.org


--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] bug-gnuzilla Digest, Vol 137, Issue 13

2018-02-22 Thread Habs


Hello all

On Thu, 22 Feb 2018, bug-gnuzilla-requ...@gnu.org wrote:


Send bug-gnuzilla mailing list submissions to
bug-gnuzilla@gnu.org

Today's Topics:

  1. Re: GNU LibreJS won't be removed from GNU IceCat (Ivan Zaigralin)
  7. Re: GNU LibreJS won't be removed from GNU IceCat (Julie Marchant)




Even with those well-made points, I would add that 'users' have to be 
bothered in the first place to want change.  I doubt the majority of 
every-day users are aware enough, or are that bothered about it.


Whilst not about browsing per se, I recall a conversation I was having in 
some free time, where very briefly with a bit of reasoning I mentioned 
about not being interested in using skype, facebook messenger, whatsapp 
etc and using other communication options; to which I got a reply, 
someting like "why can't you just be normal and use what everyone else 
does... I'm not bothered, as long as I can do what I want and it 
works..especially on my smart phone".


If 'normal users' become more informed and are really bothered to demand 
change, then perhaps things move [more] quickly.


Regards
Habs

--- Sent using Alpine/Pine MUA ---

--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] Why IceCat discontinued official macOS and Windows releases

2018-02-22 Thread The Canadian Bacon
Perhaps your cache needs to be cleared because I'm able to access the files
via the page link from my laptop, phone, Desktop and soon I'll be able to
verify from a work PC. I'll let you know what's up if there's an issue, but
as far as I can tell, issue seems to be isolated to your end.

On Feb 22, 2018 3:19 AM, "Gary"  wrote:

> the link is from your icecat page linked from your front page...
>
> On Feb 22, 2018, at 12:05 AM, The Canadian Bacon 
> wrote:
>
> You're using an old link.
> https://casualgamer.ca/index.php/unofficial-icecat-builds/
>
> On Feb 22, 2018 12:09 AM, "Gary"  wrote:
>
>> I don't think this is true for the macOS build but the Windows binaries
>> can be cross-compiled under Linux. The only downside I see to that is that
>> it's not signed nor is there an installer generated. So it sounds more like
>> this is just a decision based on time vs GNU philosophy.
>>
>> Also, to the person that's hosting the unofficial binaries; it looks like
>> your link to the source is broken: https://casualgamer.ca/index.p
>> hp/download/55/ leads to a "Download does not exist" page.
>>
>> -Gary
>>
>>
>>
>> On Tue, Feb 20, 2018 at 10:21 AM, David Hedlund 
>> wrote:
>>
>>> People wonder why Rubén Rodríguez discontinued Windows and macOS
>>> releases for IceCat after version 38.8.0. I asked him to clarify this on
>>> https://www.gnu.org/software/gnuzilla/ which he updated immediately:
>>>
>>> "Note that building binary packages for Windows and macOS currently
>>> requires non-free software, so we no longer distribute binary releases for
>>> those platforms."
>>>
>>>
>>> Unofficial download links for macOS and Windows are listed in
>>> https://directory.fsf.org/wiki/IceCat#tab=Details
>>>
>>>
>>> --
>>> http://gnuzilla.gnu.org
>>>
>>
>>
>> --
>> http://gnuzilla.gnu.org
>>
>>
> --
> http://gnuzilla.gnu.org
>
>
--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] Icecat fonts option

2018-02-22 Thread al3xu5 / dotcommon
Il giorno giovedì 22/02/2018 01:31:25 +0100
David Hedlund  ha scritto:

> https://quitter.se/ looks good in IceCat 52.3.0 by default.
> 
> 
> On 2016-06-05 01:07, Alejandro Hernández wrote:
> > Hi,
> >
> > Icons form GNUsocial on quitter.se are not correctly shown, on icecat 
> > web browser. (see captura.png)
> >
> > And if I check the option shown on captura2.png, they are right 
> > displayed. But by doing this, maybe there will be sites that show non 
> > free fonts, right?
> >
> > Thanks,

Hi

I propose/suggest IceCat should use by default exactly the same local fonts and
the same fonts' related preferences used by TorBrowser.

Regards




-- 
al3xu5 / dotcommon
Say NO to copyright, patents, trademarks and any industrial design restrictions.

--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] Alsa IceCat

2018-02-22 Thread al3xu5 / dotcommon
Il giorno mercoledì 21/02/2018 15:43:40 +0100
Brian Durant  ha scritto:

> I just installed IceCat on a new computer with a vanilla Devuan minimum 
> i3wm install. IceCat works fine, except that no sound is available. I am 
> using Alsa for sound at this point. Please advise as to how to get 
> IceCat to work with Alsa. I have confirmed that my sound card works, so 
> I know that the problem doesn't lie there.


Hi

Alsa sound works fine to me with Gnuzilla IceCat 52.3.0 I have built on a
updated Devuan GNU+Linux Jessie 1.0 amd64 machine using the procedure I have
detailed here:

https://libreplanet.org/wiki/Group:IceCat/Compile_and_package/build_52.3.0_on_devuan_(debian)_jessie_1.0

As you can see looking inside the configuration parameters here:

https://libreplanet.org/wiki/Group:IceCat/Compile_and_package/build_52.3.0_on_devuan_(debian)_jessie_1.0#Set_the_configuration_parameters_.28file:_src.2Fmozconfig.29

I have explicity enabled alsa support and disabled pulseaudio.

Regards


-- 
al3xu5 / dotcommon
Say NO to copyright, patents, trademarks and any industrial design restrictions.

--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] Alsa IceCat

2018-02-22 Thread Brian Durant

On 2018-02-22 10:58, Narcis Garcia wrote:

Before installing Icecat, I tested same sound source with M.Firefox.


El 22/02/18 a les 09:00, Narcis Garcia ha escrit:

I've tried to reproduce the problem in a
devuan_jessie_1.0.0_amd64_desktop-live session with this installation
procedure*:*

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys
B4EFB9F38D8AEBF1

RepoFile=/etc/apt/sources.list.d/temporary-icecat.list

echo "deb http://es.archive.trisquel.info/trisquel belenos-updates main"
| sudo tee $RepoFile

sudo apt-get update

sudo apt-get install icecat

sudo rm $RepoFile

Had to disable LibreJS to allow opening /jamendo.com/radios/ and *sound
works* for any radio there.


El 21/02/18 a les 15:43, Brian Durant ha escrit:

I just installed IceCat on a new computer with a vanilla Devuan
minimum i3wm install. IceCat works fine, except that no sound is
available. I am using Alsa for sound at this point. Please advise as
to how to get IceCat to work with Alsa. I have confirmed that my sound
card works, so I know that the problem doesn't lie there.

I am using the stand alone IceCat version 52.3.0 (64-bit), downloaded 
from a GNU repository. I have since I posted last, found a number of 
posts regarding Alsa support being taken out of Firefox (and I assume 
IceCat???). Here is what I did to get Alsa to work:


I added this line to my /etc/apt/sources.list:
deb http://auto.mirror.devuan.org/devuan experimental main

then ran

apt-get update
apt-get -t experimental install apulse

Remember to comment out the repository and run apt-get update again 
after the fact.


As I am running i3wm as my only window manager, I just added "apulse" in 
front of what I already have in my config file, so it now looks like this:

bindsym $mod+b exec apulse ~/bin/icecat/icecat

Everything works fine so far...

--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

2018-02-22 Thread Julie Marchant
On 2018年02月22日 03:22, Ivan Zaigralin wrote:
> What I mean by drive-by-downloading, here we get philosophical. How free is 
> the code which is only meant to be executed once? No one audits > 99% of this 
> code, and it's all in constant flux. I would even argue, there's no hope it 
> can ever be audited. There are already (I am sure) websites that generate 
> brand-new code for every visit, making this assertion literal. How do you 
> audit all that code? With an automated tool? An algorithm can't even solve a 
> halting problem, let alone audit itself out of a paper bag.
> 
> Now put yourself in the shoes of an average web user. Average here is the key 
> word. Their freedoms to understand and modify the JavaScript code have all 
> but 
> completely eroded. In a traditional software distribution market they can 
> hire 
> experts to explain and fix the software for them. This is utterly 
> unaffordable 
> if every click generates new software.
> 
> And now back to drive-by-downloading, which is important because it is 
> perhaps 
> the source of the problem. All of this is happening, as we all know very 
> well, 
> because average users are willing to run software from any source, as long as 
> it doesn't make their computer explode right away. They don't even understand 
> the basic difference between downloading data versus downloading and 
> executing 
> an arbitrary algorithm. When a blog, or a news site, or a government website 
> won't load because you didn't let it run an arbitrary algorithm on your 
> computer, that's crazy, just crazy. And the norm. These users who leave all 
> JavaScript on, they already buried 2 of their freedoms, and the boilerplate 
> license on the disposable code can't change that. They need to be told to 
> boycott sites which require JS to function, and to demand legislation which 
> would require something like HTML+CSS web fronts from commercial and 
> government entities. It is not at all helpful, in my opinion, to 
> differentiate 
> between varieties of JavaScript sources, because none of them should be 
> downloaded in the first place. Most importantly, web masters who want a free 
> web should stop using JavaScript, and they should be transitioning right now, 
> and not stop until there's nothing left for LibreJS to mark as free. All 
> desired JavaScript functionality can be trivially recreated via a combination 
> of free browser plugins and calls to free and standard libraries. The drive-
> by-download culture, on the other hand, will plunge us deeper into the sea of 
> disposable software.

I agree with this 100%. I've written about it here; I suggest for anyone
who hasn't already to give it a read:

https://onpon4.github.io/articles/kill-js.html

-- 
Julie Marchant
https://onpon4.github.io



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

2018-02-22 Thread bill-auger
ok thats sorta what i thought you meant - i couldnt have said it more
verbosely myself - i do quite agree that the web is a hopeless cause for
FOSS - as you say, the only real solution is stop running foreign
scripts completely - though allowing white-listed client-side JS
libraries is an interesting idea

i will add this though, as you mention the average user's complacency -
such as:

On 02/22/2018 03:22 AM, Ivan Zaigralin wrote:
> average users are willing to run software from any source
> They don't even understand the basic difference between
> downloading data versus executing an arbitrary algorithm

i think even that statement is over-stating the user's understanding -
the average user does not even consider the web to be software - it is
nothing more significant than a magazine or TV show - most people do not
care what software is running in their television or even know that
their television is running software - take next into account that the
casual PC user is migrating to smart-phones which, just as a television
or a home-bot appliance, the owner does not see as a computer -
websites, "apps", tweeting, and of course shopping, those are all just
"stuff that my phone does" when i push the pretty buttons - just as the
TV goes on when i press the red button on the remote - as long as that
works why should the user care about it's software - they are not
computing with that device; they are merely entertaining themselves with it

to put this into context: the underlying impetus of the 4 freedoms is
that user should control their own computing - frankly, i dont consider
tweeting and shopping to be "computing" in any meaningful sense; and
understandably so, neither does the casual user - aside from privacy
concerns, it is an increasingly less convincing argument to make to the
casual user that software freedom is something they should be concerned
about



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] Alsa IceCat

2018-02-22 Thread Narcis Garcia
Before installing Icecat, I tested same sound source with M.Firefox.


El 22/02/18 a les 09:00, Narcis Garcia ha escrit:
> I've tried to reproduce the problem in a
> devuan_jessie_1.0.0_amd64_desktop-live session with this installation
> procedure*:*
> 
> sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys
> B4EFB9F38D8AEBF1
> 
> RepoFile=/etc/apt/sources.list.d/temporary-icecat.list
> 
> echo "deb http://es.archive.trisquel.info/trisquel belenos-updates main"
> | sudo tee $RepoFile
> 
> sudo apt-get update
> 
> sudo apt-get install icecat
> 
> sudo rm $RepoFile
> 
> Had to disable LibreJS to allow opening /jamendo.com/radios/ and *sound
> works* for any radio there.
> 
> 
> El 21/02/18 a les 15:43, Brian Durant ha escrit:
>> I just installed IceCat on a new computer with a vanilla Devuan
>> minimum i3wm install. IceCat works fine, except that no sound is
>> available. I am using Alsa for sound at this point. Please advise as
>> to how to get IceCat to work with Alsa. I have confirmed that my sound
>> card works, so I know that the problem doesn't lie there.
>>
>>
>> -- 
>> http://gnuzilla.gnu.org
> 

--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

2018-02-22 Thread Narcis Garcia
I was asking about the CURRENT principle for LibreJS, not for "good" or
"bad" of theoretically prossibilities.


El 22/02/18 a les 09:35, Ivan Zaigralin ha escrit:
> On Thursday, February 22, 2018 08:43:38 Narcis Garcia wrote:
>> Which is the principle for LibreJS to approve JavaScript functions
>> and/or files?
>> A license mention?
> 
> Can be regarded as necessary, but not sufficient.
> 
>> A signature?
> 
> Useful for creating a trust model between users and web parties, but this is 
> already implemented by https+noscript, and it solves a different problem, not 
> directly freedom-related.
> 
>> A well-known functions comparison? A code analysis? It replaces funcions?
> 
> A code analysis is pointless. Detecting obfuscated code, in particular, is an 
> intractable problem. If you could define "obfuscated" formally, chances are, 
> there would be a formal proof that the detection is unsolvable by a TM. But 
> generally speaking, a good way to obfuscate is by writing a virtual assembly 
> interpreter, and then feeding it "binaries" which appear to be perfectly 
> cromulent, poetic even, JavaScript sources. And obfuscated code cannot be 
> considered free.
> 
> None of this is purely academic. Dynamic, obfuscated JavaScript bitcash 
> miners 
> are all the rage right now. This is where we are today.
> 
> 
> 
> --
> http://gnuzilla.gnu.org
> 

--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

2018-02-22 Thread Ivan Zaigralin
On Thursday, February 22, 2018 01:04:30 bill-auger wrote:
> this is confusing - what exactly is a
> "drive-by-download" and how are they inherently "non-free no matter what
> license is attached to them"?
> 
> also, how could LibreJS "incorrectly mark an obfuscated piece of
> GPL-licensed code as free" - GPL-licensed code IS free

GPL-licensed code is not necessarily free. An obfuscated source is 
unmaintainable regardless of the license, so two freedoms are taken away: the 
freedom to study, and the freedom to run modified versions. LibreJS is unable 
to detect obfuscated code.

What I mean by drive-by-downloading, here we get philosophical. How free is 
the code which is only meant to be executed once? No one audits > 99% of this 
code, and it's all in constant flux. I would even argue, there's no hope it 
can ever be audited. There are already (I am sure) websites that generate 
brand-new code for every visit, making this assertion literal. How do you 
audit all that code? With an automated tool? An algorithm can't even solve a 
halting problem, let alone audit itself out of a paper bag.

Now put yourself in the shoes of an average web user. Average here is the key 
word. Their freedoms to understand and modify the JavaScript code have all but 
completely eroded. In a traditional software distribution market they can hire 
experts to explain and fix the software for them. This is utterly unaffordable 
if every click generates new software.

And now back to drive-by-downloading, which is important because it is perhaps 
the source of the problem. All of this is happening, as we all know very well, 
because average users are willing to run software from any source, as long as 
it doesn't make their computer explode right away. They don't even understand 
the basic difference between downloading data versus downloading and executing 
an arbitrary algorithm. When a blog, or a news site, or a government website 
won't load because you didn't let it run an arbitrary algorithm on your 
computer, that's crazy, just crazy. And the norm. These users who leave all 
JavaScript on, they already buried 2 of their freedoms, and the boilerplate 
license on the disposable code can't change that. They need to be told to 
boycott sites which require JS to function, and to demand legislation which 
would require something like HTML+CSS web fronts from commercial and 
government entities. It is not at all helpful, in my opinion, to differentiate 
between varieties of JavaScript sources, because none of them should be 
downloaded in the first place. Most importantly, web masters who want a free 
web should stop using JavaScript, and they should be transitioning right now, 
and not stop until there's nothing left for LibreJS to mark as free. All 
desired JavaScript functionality can be trivially recreated via a combination 
of free browser plugins and calls to free and standard libraries. The drive-
by-download culture, on the other hand, will plunge us deeper into the sea of 
disposable software.

signature.asc
Description: This is a digitally signed message part.
--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] Why IceCat discontinued official macOS and Windows releases

2018-02-22 Thread Gary
the link is from your icecat page linked from your front page...

> On Feb 22, 2018, at 12:05 AM, The Canadian Bacon  wrote:
> 
> You're using an old link.
> https://casualgamer.ca/index.php/unofficial-icecat-builds/ 
> 
>> On Feb 22, 2018 12:09 AM, "Gary"  wrote:
>> I don't think this is true for the macOS build but the Windows binaries can 
>> be cross-compiled under Linux. The only downside I see to that is that it's 
>> not signed nor is there an installer generated. So it sounds more like this 
>> is just a decision based on time vs GNU philosophy.
>> 
>> Also, to the person that's hosting the unofficial binaries; it looks like 
>> your link to the source is broken: 
>> https://casualgamer.ca/index.php/download/55/ leads to a "Download does not 
>> exist" page.
>> 
>> -Gary
>> 
>> 
>> 
>>> On Tue, Feb 20, 2018 at 10:21 AM, David Hedlund  wrote:
>>> People wonder why Rubén Rodríguez discontinued Windows and macOS releases 
>>> for IceCat after version 38.8.0. I asked him to clarify this on 
>>> https://www.gnu.org/software/gnuzilla/ which he updated immediately:
>>> 
>>> "Note that building binary packages for Windows and macOS currently 
>>> requires non-free software, so we no longer distribute binary releases for 
>>> those platforms."
>>> 
>>> 
>>> Unofficial download links for macOS and Windows are listed in 
>>> https://directory.fsf.org/wiki/IceCat#tab=Details
>>> 
>>> 
>>> --
>>> http://gnuzilla.gnu.org
>> 
>> 
>> --
>> http://gnuzilla.gnu.org
>> 
--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] Why IceCat discontinued official macOS and Windows releases

2018-02-22 Thread The Canadian Bacon
You're using an old link.
https://casualgamer.ca/index.php/unofficial-icecat-builds/

On Feb 22, 2018 12:09 AM, "Gary"  wrote:

> I don't think this is true for the macOS build but the Windows binaries
> can be cross-compiled under Linux. The only downside I see to that is that
> it's not signed nor is there an installer generated. So it sounds more like
> this is just a decision based on time vs GNU philosophy.
>
> Also, to the person that's hosting the unofficial binaries; it looks like
> your link to the source is broken: https://casualgamer.ca/index.
> php/download/55/ leads to a "Download does not exist" page.
>
> -Gary
>
>
>
> On Tue, Feb 20, 2018 at 10:21 AM, David Hedlund 
> wrote:
>
>> People wonder why Rubén Rodríguez discontinued Windows and macOS releases
>> for IceCat after version 38.8.0. I asked him to clarify this on
>> https://www.gnu.org/software/gnuzilla/ which he updated immediately:
>>
>> "Note that building binary packages for Windows and macOS currently
>> requires non-free software, so we no longer distribute binary releases for
>> those platforms."
>>
>>
>> Unofficial download links for macOS and Windows are listed in
>> https://directory.fsf.org/wiki/IceCat#tab=Details
>>
>>
>> --
>> http://gnuzilla.gnu.org
>>
>
>
> --
> http://gnuzilla.gnu.org
>
>
--
http://gnuzilla.gnu.org


Re: [Bug-gnuzilla] Alsa IceCat

2018-02-22 Thread Narcis Garcia
I've tried to reproduce the problem in a
devuan_jessie_1.0.0_amd64_desktop-live session with this installation
procedure*:*

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys
B4EFB9F38D8AEBF1

RepoFile=/etc/apt/sources.list.d/temporary-icecat.list

echo "deb http://es.archive.trisquel.info/trisquel belenos-updates main"
| sudo tee $RepoFile

sudo apt-get update

sudo apt-get install icecat

sudo rm $RepoFile

Had to disable LibreJS to allow opening /jamendo.com/radios/ and *sound
works* for any radio there.


El 21/02/18 a les 15:43, Brian Durant ha escrit:
> I just installed IceCat on a new computer with a vanilla Devuan
> minimum i3wm install. IceCat works fine, except that no sound is
> available. I am using Alsa for sound at this point. Please advise as
> to how to get IceCat to work with Alsa. I have confirmed that my sound
> card works, so I know that the problem doesn't lie there.
>
>
> -- 
> http://gnuzilla.gnu.org

--
http://gnuzilla.gnu.org