Slashdot Mirror

>> https://addons.mozilla.org/en-...

Looks like you'll be needing to fend of some lawyers too... "Contribute to me to download all these free songs!" is one spin.

Except it *doesn't* make sense. The .org domain is pretty much made for a logical or business organization, just like Organization for Transformative Works, The National Organization for Women, The Mozilla Corporation/Organization, etc

Now if they wanted to cover both bases, having trump.com and trump.org might make sense.

No. The person you replied to is correct. Telemetry is not on at all by default in release versions of Firefox. However it is on by default on pre-release versions (this is when it will tell you that they are collecting some data). For more info see this article: https://wiki.mozilla.org/Telem...

This is false. Release versions of Firefox do not enable telemetry. See https://wiki.mozilla.org/Telem... for more info.

What you're looking for exists as an add-on for the Firefox browser:

RequestPolicy

Install https://addons.mozilla.org/en-... on Firefox (not Palemoon) and use the following user-agent if you wanted Palemoon to browse the site;
"Mozilla/5.0 (X11; Linux x86_64; rv:2.1) Gecko/20100101 Goanna/20160814 PaleMoon/26.4.0"

You can use https://addons.mozilla.org/en-... in Firefox

Any links as to what Chrome collects?

No, because there is no law which requires a company to publish an honest privacy policy. And even if there was, there is no way in hell Google will ever allow any regulatory body to pry around their data centres and entire database and archives to ensure that they are indeed not spying or doing nasty things with data, like selling to insurance companies, government bodies, highest bidder, etc.

And even if there was such a thing as a regulatory body to monitor Google, Google will simply pay them enough to shut up, like they bribe the US Government and the EU.

The only honest privacy policy (as it appears to me) comes from the likes of EFF, DuckDuckGo, Mozilla, ProtonMail, and Wire, of the few that I've read.

Google on the other hand is very deceptive and vague in their privacy policy, especially data retention... if there is such a thing as privacy and Google!

The only reason to stay on Firefox is that it's addons are better. Whatever your need, there's an addon for that.

https://addons.mozilla.org/en-...

I have run version 0.14.2014051101 from the "old Versions" Directory of the Add-on (Before the "Drop support for Firefox 30 and older versions" of the Add-on )

https://addons.mozilla.org/en-...

You aren't supposed to download the _newest_ version from oldversion.com

You are supposed to download an _old_ version.

Also, http://releases.mozilla.org/pub/{phoenix,firebird,firefox}/ has them down all the way to 0.1 if that floats your boat.

Sure can. Read about it.

If you noticed at the bottom of the doc it mentions Ryan Sleevi (also see https://wiki.mozilla.org/CA:Po...)
So at least in some fashion Google is involved as well

Pale Moon is not on their whitelist. When will this user-agent sniffing/whitelist bullshit ever end?!

It's probably because Pale Moon doesn't implement Media Source Extensions. Check what YouTube thinks your browser supports and if media source extensions aren't available you won't get any 1080p content. The easy fix to get 1080p content on YouTube is to switch to Firefox, which is like a more up to date version of Pale Moon.

The Vaani wiki states: "No longer an approved project" (right side of https://wiki.mozilla.org/Vaani), unfortunately.

Not yet mentioned yet is http://lucida.ai/ -- it's the successor to Sirius, and where all the ongoing development is focused.

Major options that are mentioned elsewhere in the thread:
https://mycroft.ai/ (One of the most advanced,can actually be used in a pretty useful manner now, but sends snippets to Google for voice recognition--they intend to change that eventually, and they don't have a full-time open mic. Plus they aggregate audio across users so it's less identifiable as from a single source).
https://wiki.mozilla.org/Vaani (from the Mozilla project; supposed to enter beta this month according to that page)

The Mozilla project Vaani is intended to fill exactly this niche. https://wiki.mozilla.org/Vaani

Yes, it does. You can enable it by right-clicking on the toolbar and ticking the "Menu Bar" option. To make the menu bar a fixture rather than appearing only when you press alt. When the menu bar is enabled in this way you can still toggle its visibility by pressing F10.

Personally I find the menu bar occupying a whole row on its own to be a waste of space, so I install the Personal Titlebar extension, which allows me to use the "Customise" screen to add a page title next to the menu.

Here's what my browser looks like at the moment.

Nope. They keep on pushing that back for ... some reason.

The new API landed in Firefox 48 (I guess, the 48.0 release notes just say that it's "considered stable" which I think means "released to the general public").

The old API is still going to be going away, but it's really hard for me to guess when - on the original road map it was already gone, but given how long the new extension API took, they haven't hit that yet. If you want to try and decode the Firefox Roadmap and figure out when the old extension API is being removed, go for it. Best guess is Firefox 51, when Electrolysis is enabled for "people using extensions" since the stated reason for removing the old API is that it doesn't work with Electrolysis.

But who knows. In the original road map, yes, the old API would be gone by now. As far as I know it isn't, yet. Although if you have extensions you care about, I'd check to make sure they still work before upgrading. Firefox isn't exactly known for not breaking extensions with new releases.

Nope. They keep on pushing that back for ... some reason.

The new API landed in Firefox 48 (I guess, the 48.0 release notes just say that it's "considered stable" which I think means "released to the general public").

The old API is still going to be going away, but it's really hard for me to guess when - on the original road map it was already gone, but given how long the new extension API took, they haven't hit that yet. If you want to try and decode the Firefox Roadmap and figure out when the old extension API is being removed, go for it. Best guess is Firefox 51, when Electrolysis is enabled for "people using extensions" since the stated reason for removing the old API is that it doesn't work with Electrolysis.

But who knows. In the original road map, yes, the old API would be gone by now. As far as I know it isn't, yet. Although if you have extensions you care about, I'd check to make sure they still work before upgrading. Firefox isn't exactly known for not breaking extensions with new releases.

While it probably would be challenging to hack a CA or trick one into issuing the necessary certificate for addons.mozilla.org

That depends on the CA, some are more easy to trick than others...

Not for Mozilla. They have important bugs, that are a decade in their BTS. Such big projects have a hard time to fix everything, especially when they set the priority on moving forward to new features.

https://bugzilla.mozilla.org/s...
> By the way, if you appreciate irony, note that Zvi Har'El, who analyzed this bug 9 years ago (see above), is my father. He unfortunately died 8 years ago, and today I ran into the same bug. My daughter already reached the age that she started to use Firefox too, so soon she'll probably run into this bug too, and this will have become a 3-generation bug...

Perhaps it is asking Google's Safe Browsing service about each URL that it is opening. I have a feeling that, if you turned off that feature, the 1000+ browser tabs will open more quickly upon restart.

I agree that the web is pretty much a huge mess, but I just want to address one thing:

- JavaScript. Single threaded and garbage collected.

I think Web Workers allow you to write multi-threaded JavaScript--with, of course, limitations (e.g., no shared memory).

I thought Mozilla was going to remove NPAPI plugin functionality. As is Chrome if they did not do it already. Adobe regularly does interesting things like this. Releasing "new" software just when an API is going to get deprecated. (Carbon anyone?).

Unless you're of the opinion "digital restrictions management should not exist, and therefore rentals and subscriptions should not exist", how is CDM "not much of an improvement" over Flash Player? The CDM is a much smaller piece of code with a much smaller scope than the entirety of Flash Player. It also runs in a sandbox that can only do a few things, such as receive encrypted data from the browser and send decrypted and decoded video to the operating system.

I use RequestPolicy for Firefox which can be configured to deny all cross-domain requests until explicitly allowed to. A determined tracker may still put the tracking code server side on the third party host, but this will never become the norm because the tracker will be exposing themselves to fake requests.

They might be legit, but they use StartCom for certs

https://www.techdirt.com/artic...
https://bugzilla.mozilla.org/s...

https://en.wikipedia.org/wiki/...
https://groups.google.com/foru...

It works fine for me: mobile Firefox on Nexus 7 2013, desktop Firefox on two different PCs running Windows 7. It's been over a year since I set it up, but I think I followed these instructions.

Disclaimer: I've got a design diploma (with accolades).

The letter-logo is just fine. They should just iterate their branding a little.

Here are my quick points for the website (German layout version) alone (a new style-tile incorporating these would also be a neat base for a brand overhaul) ... The current englisch version looks boooooring btw. - it's an example of a bad iteration. Just current trendy stuff quickly ripped and remixed without a clear concept, once again half finished. ... Why don't these people just iterate an ok design to make it perfect? Why always a complete overhaul? This is non-sense.

My list:
- Letter Logo off to the side a bit, more breathing room (hero image/video backdrop maybe?)
- Letter Logo bolder (is there an extrabold version of the font? They should move to that.)
- less clutter on the screen
- limit the palette and have it follow color theory (looks like an unfinished MS Metro rippoff - not nice)
- one radius for rounded corners and not 5 or so that I'm seeing.
- Justify left, better images, perhaps some hippster hero images (yes I know, we have enough of those already, but well done they *do* work ... get an expert on this)
- 2 to 3 font sizes, not the 6 or 7 I'm seeing (bad layout design!! Together with the various radi on rounded corners the layout is a mess - a little tweaking alone would be a huge improvement)
- Flowtext font thinner.
- Flowtext fontsize smaller
- Double your whitespace. No, really, double your whitespace.
- layout backdrop coloring is so 2010 - should get a redo, limit colorset or remove it all-together and stick to base-color-palette
- We'res the Firefox Ad or the Moz equivalent? ... Mozilla needs a presentation video of its own. Hero size, professionally done. People want Moooovieezzz! nowadays.
- Nice to have: They should check with some world class webdesigners and see if they can remove or limit the "bootstrappiness" of the entire layout. People are bored of that. Perhaps limiting the use of Icons would already help a bit. Fontawesome and Co. make sense, but they're often overused and out of place. Like postmodern architecture with no sense or meaning... Maybe more to the polymer icons - those are hip, classic and work well with fresh minimalistic designs.

My 2 designer cents.

Disclaimer: I've got a design diploma (with accolades).

The letter-logo is just fine. They should just iterate their branding a little.

Here are my quick points for the website (German layout version) alone (a new style-tile incorporating these would also be a neat base for a brand overhaul) ... The current englisch version looks boooooring btw. - it's an example of a bad iteration. Just current trendy stuff quickly ripped and remixed without a clear concept, once again half finished. ... Why don't these people just iterate an ok design to make it perfect? Why always a complete overhaul? This is non-sense.

My list:
- Letter Logo off to the side a bit, more breathing room (hero image/video backdrop maybe?)
- Letter Logo bolder (is there an extrabold version of the font? They should move to that.)
- less clutter on the screen
- limit the palette and have it follow color theory (looks like an unfinished MS Metro rippoff - not nice)
- one radius for rounded corners and not 5 or so that I'm seeing.
- Justify left, better images, perhaps some hippster hero images (yes I know, we have enough of those already, but well done they *do* work ... get an expert on this)
- 2 to 3 font sizes, not the 6 or 7 I'm seeing (bad layout design!! Together with the various radi on rounded corners the layout is a mess - a little tweaking alone would be a huge improvement)
- Flowtext font thinner.
- Flowtext fontsize smaller
- Double your whitespace. No, really, double your whitespace.
- layout backdrop coloring is so 2010 - should get a redo, limit colorset or remove it all-together and stick to base-color-palette
- We'res the Firefox Ad or the Moz equivalent? ... Mozilla needs a presentation video of its own. Hero size, professionally done. People want Moooovieezzz! nowadays.
- Nice to have: They should check with some world class webdesigners and see if they can remove or limit the "bootstrappiness" of the entire layout. People are bored of that. Perhaps limiting the use of Icons would already help a bit. Fontawesome and Co. make sense, but they're often overused and out of place. Like postmodern architecture with no sense or meaning... Maybe more to the polymer icons - those are hip, classic and work well with fresh minimalistic designs.

My 2 designer cents.

These designs are all completely dreadful.
https://blog.mozilla.org/opend...

...This apparently makes it a native browser feature where you can capture directly to a file with no intermediate steps. However I've been using the FireShot plugin for years and it works fine; I don't see why this needs to be built directly into the browser.

GP here. I just use the native Snipping Tool in Win 7 and up. When I need to use a Mac, the OS has supported native screenshots for years. Even back in the XP glory days I used a third-party OS program which saved directly to disk.

If a program can snip anything from the OS-level, why do we need it at the browser level? Can you elaborate on the day-to-day use that you get out of a browser-specific screenshotting plugin?

With printscreen you eventually have to run some other program (MSPAINT, Photoshop, whatever) and paste in the clipboard contents. This apparently makes it a native browser feature where you can capture directly to a file with no intermediate steps. However I've been using the FireShot plugin for years and it works fine; I don't see why this needs to be built directly into the browser.

Currently the plan is to make non flash npapi plugins disabled by default on firefox 52, and by firefox 53 support will be removed entirely. So better change to pdf.js, or open the pdf files that pdf.js has problems with externally.

Source: https://bugzilla.mozilla.org/s...

By "the spec", are you referring broadly to the W3C's EME spec or more narrowly to the spec of how Firefox implements EME?

"the attack surface of plug-ins" oh fuck off. If processes can't be assigned fine-grained permissions then your operating system is shit.

Unfortunately, people have allowed themselves to become locked into incumbent operating systems that are, as you put it, "shit". But given the presence of "sandbox" in the titles of bugs listed at Media/EME, it appears Firefox is at least trying to limit the permissions of the CDM.

Well asm.js is about 50% more than native [1], maybe slower on browsers that don't have asm.js optimisations (the analogon for PNaCl would result in it not working at all). So yes, its 20% difference, but its not considerably far away, unless you say that PNaCl is far away from native speeds.

Javascript is not designed to model a processor architecture

No it isn't. But asm.js is. The only thing it doesn't have that "normal" assembly has is gotos, its done via manual loops instead.

It uses LLVM bitcode which means it can be translated into native instructions and cached.

Its the same for asm.js, it gets translated into native instructions as well. At least on browsers that care about asm.js.

[1]: https://hacks.mozilla.org/2013...

PDF.js is not really a safe option though since it has had countless vulnerabilities.Stop recommending shit you know nothing about.

https://blog.mozilla.org/secur...

https://www.mozilla.org/en-US/...

https://www.mozilla.org/en-US/...

https://www.mozilla.org/en-US/...

etc..

PDF.js is not really a safe option though since it has had countless vulnerabilities.Stop recommending shit you know nothing about.

https://blog.mozilla.org/secur...

https://www.mozilla.org/en-US/...

https://www.mozilla.org/en-US/...

https://www.mozilla.org/en-US/...

etc..

PDF.js is not really a safe option though since it has had countless vulnerabilities.Stop recommending shit you know nothing about.

https://blog.mozilla.org/secur...

https://www.mozilla.org/en-US/...

https://www.mozilla.org/en-US/...

https://www.mozilla.org/en-US/...

etc..

PDF.js is not really a safe option though since it has had countless vulnerabilities.Stop recommending shit you know nothing about.

https://blog.mozilla.org/secur...

https://www.mozilla.org/en-US/...

https://www.mozilla.org/en-US/...

https://www.mozilla.org/en-US/...

etc..

js+html+canvas API is a perfect way to encode vector animations, with similar compression ratios (assuming transport compression) as flash.

I agree that Canvas or SVG would be the ideal solution going forward. Have you tried any non-Adobe tools for authoring such animations that you're willing to recommend? I don't want to rely on Adobe Animate because it's available only for rental.

For legacy content, there is shumway.

If Shumway could replace Flash Player the way pdf.js replaced the Adobe Reader plug-in, that would be great. But as far as I can tell, Mozilla canceled Shumway. There hasn't been a status report in over a year, and the graph of contributions to Git appears to have flatlined over the past 11 months.

[Appliances on a home network with a web-based administration interface] are not servers and don't need to serve https

The article "Deprecating Non-Secure HTTP" by Richard Barnes begins: "Today we are announcing our intent to phase out non-secure HTTP." Not only Firefox but also Chrome has announced plans to deprecate HTTP. This includes making new web APIs, such as Service Worker, available only to a "secure context". The list of such APIs includes Service Worker, Geolocation, Notification, Fullscreen, Pointer Lock, and Media Stream (camera and microphone).

A secure context is available only if all documents holding references to objects in that context come from a "potentially trustworthy origin", as defined in the W3C's "Secure Contexts" spec. As of right now, web browsers are treating only the 127/8 netblock (that is, localhost) and origins using the https or wss scheme as potentially trustworthy origins. The spec allows a web browser to allow the user to mark other origins as potentially trustworthy, but the present draft doesn't suggest how the web browser might expose this functionality to the user.

as you'll connect on a trusted network - your own, and your own only. Wired or encrypted WiFi.

A web browser cannot tell the difference between my encrypted Wi-Fi network at home and the encrypted Wi-Fi network of the coin laundry near me. For this reason, the RFC 1918 private netblocks 10/8, 172.16/12, and 192.168/16 are by default not treated as potentially trustworthy without the https scheme, unlike 127/8.

"Hey I've got a great idea! If we do this little thing our product will be even better!"
They do some little thing no one asked for, to half a billion installed browsers.
That thing in no way affects their bottom line.
But somewhere else, the bottom drops out of something else and something precious is broken.
Please don't do this.

So Wayback is going to be the error page for every damned malformed or mis-typed link? That is abuse and attack.

I can see Wayback hit like a gigaton of bricks as people who have no deep interest in the content they're trying to access say "gee, what's this? All these changes! What did it look like in 2009?" And often the last crawl is NOT the one with real content. There is no substitute for knowing what you're doing and what you are looking for. There is no way to dumb down the process. And what about those [stupid] pre-load and crawler plugins? Will they hit Wayback too?

And more site owners will drop in that magic blip into robots.txt that will shut Wayback access for good, even the pages in the database that are there ready to serve. It's bad enough that domain squatters often block Wayback.

And even the constant stream of reflected robots.txt lookups will hit Wayback like a malevolent attack. Do you [Mozilla] even know how Wayback works?

Add-ons like Resurrect Pages are the way to go. Only folks with a real and deep interest will go further. And THAT level of traffic is what Wayback can support.

If you don't want services automatically crawling your pages, configure your robots.txt appropriately. http://archive.org/about/faqs.php#2, http://lmgtfy.com/?q=prevent%20google%20from%20caching%20my%20site, etc. This feature (which has been around in the form of the Resurrect Pages addon for at least 10 years) simply gives users an easy way to access a backup copy of a page when it isn't found live.

https://addons.mozilla.org/en-US/firefox/addon/resurrect-pages/

Not sure why it's never been very popular. It's one of the most useful add-ons I have. Unlike the proposed add-on in TFA which only uses the Wayback Machine, Resurrect Pages lets you pick from four possible sources (Google cache in full and text-only mode for those annoying pages which won't show the text until all the nonexistent pics finish loading first, Wayback Machine, WebCite, archive.is) for a cached version of the page. There used to be more, but I guess some of those archiving projects died.

I guess most people are like me. I don't want an old, out of date page. If the site isn't there I most likely have no interest in it at all anymore. I certainly can't trust anything it says since it's been demonstrated an not valuable enough to keep around. There are a handful of times I've used the various archive sites out there, mainly to see how a site has evolved over time. Occasionally I'll check out what an expired domain used to host when deciding if I want to buy it. That's about it.

"WebExtensions" are just glorified Greasemonkey scripts -- with a much larger API than GM scripts have available, but you're still playing around in a sandbox. These are mostly interesting for extending how a given website works, hence my comparison to GM.

With WebExtensions, you're not playing in a sandbox, you're playing with abstractions. Exposing internal XPCOM objects to extensions offered no abstraction - extensions were messing directly with browser internals, which was severely hampering our ability to improve fundamentals of the Gecko engine. We want to be able to make significant changes to Gecko without constantly worrying about breaking extensions. An abstraction layer is the way to do that.

"Extensions" have access to the browser chrome, and can thus add or change any functionality in the browser. This is the bit that is euphemistically (and wrongly) described as "deprecation of XUL and XPCOM" (even though XUL and XPCOM aren't actually a requirement for this type of extension...).

You're right, XUL and XPCOM are not required for that type of extension. WebExtension APIs are going to allow for modification of browser chrome. Mozilla is working with extension developers to make sure that the functionality that they require will be exposed to them in a way that is future-proof. We fully intend to allow for extensions such as tree-style tabs and Vimperator.

If you have useful ideas for new extension APIs, I encourage you to offer suggestions instead of FUD.

WebExtensions overview
WebExtensions roadmap
WebExtensions experiments

"WebExtensions" are just glorified Greasemonkey scripts -- with a much larger API than GM scripts have available, but you're still playing around in a sandbox. These are mostly interesting for extending how a given website works, hence my comparison to GM.

With WebExtensions, you're not playing in a sandbox, you're playing with abstractions. Exposing internal XPCOM objects to extensions offered no abstraction - extensions were messing directly with browser internals, which was severely hampering our ability to improve fundamentals of the Gecko engine. We want to be able to make significant changes to Gecko without constantly worrying about breaking extensions. An abstraction layer is the way to do that.

"Extensions" have access to the browser chrome, and can thus add or change any functionality in the browser. This is the bit that is euphemistically (and wrongly) described as "deprecation of XUL and XPCOM" (even though XUL and XPCOM aren't actually a requirement for this type of extension...).

You're right, XUL and XPCOM are not required for that type of extension. WebExtension APIs are going to allow for modification of browser chrome. Mozilla is working with extension developers to make sure that the functionality that they require will be exposed to them in a way that is future-proof. We fully intend to allow for extensions such as tree-style tabs and Vimperator.

If you have useful ideas for new extension APIs, I encourage you to offer suggestions instead of FUD.

WebExtensions overview
WebExtensions roadmap
WebExtensions experiments

"WebExtensions" are just glorified Greasemonkey scripts -- with a much larger API than GM scripts have available, but you're still playing around in a sandbox. These are mostly interesting for extending how a given website works, hence my comparison to GM.

With WebExtensions, you're not playing in a sandbox, you're playing with abstractions. Exposing internal XPCOM objects to extensions offered no abstraction - extensions were messing directly with browser internals, which was severely hampering our ability to improve fundamentals of the Gecko engine. We want to be able to make significant changes to Gecko without constantly worrying about breaking extensions. An abstraction layer is the way to do that.

"Extensions" have access to the browser chrome, and can thus add or change any functionality in the browser. This is the bit that is euphemistically (and wrongly) described as "deprecation of XUL and XPCOM" (even though XUL and XPCOM aren't actually a requirement for this type of extension...).

You're right, XUL and XPCOM are not required for that type of extension. WebExtension APIs are going to allow for modification of browser chrome. Mozilla is working with extension developers to make sure that the functionality that they require will be exposed to them in a way that is future-proof. We fully intend to allow for extensions such as tree-style tabs and Vimperator.

If you have useful ideas for new extension APIs, I encourage you to offer suggestions instead of FUD.

WebExtensions overview
WebExtensions roadmap
WebExtensions experiments