Tobu

A website I visit is using the new PageVisibility API to cover content with an annoying message if I switch away from their tab.

I don't think "good at executing bad code" applies for embedded CPUs. Of course, good code is still more the province of the compiler (with PGO for example).

I don't think it does, it's just a few bytes. There's a client with a different identifier for the major platforms (µTorrent on Mac, Linux, Android IIRC) but that doesn't include the OS version.

The code is still easy to find, but they threatened the main developer so he won't work on it anymore. I think they won this round.

The developer console can disable the cache so that you can edit websites live, is that what you're seeing?

Also, I wonder if it's still slow if you restart with extensions disabled. There's a lot of hidden interactions in the current model.

Funny you should say that, Git's fast-import format was adopted by most DVCSes for easy transfer of commits from a foreign repository. Transparent-ish proxies do exist, like git-remote-hg. Those others have different models for history (Bazaar uses folder-type branches, Hg's branching is also different) but Git's internal model is a common subset.

But Git was not a first mover. That simple model was pioneered by Monotone. Git won because Linus' use case required high performance. DVCS flows from that (no waiting on the network), as does the index, and it just made for a huge difference in user experience.

I think I would introduce the new APIs through Jetpack (which has a formal separation between the extension proper and the APIs it uses, but ships the implementation for both). Once an extension uses only stabilised APIs (APIs taken from chromium could stabilise first, assuming there aren't too many abstraction leaks), label it as Forward-Compatible on AMO (similar to restartless addons). Help the top extensions port, and start breaking internal APIs more aggressively. Maybe start measuring the latency introduced by cross-process wrappers (assuming the extension that uses them can be determined at runtime), and warn about extensions that use them. The perception that Firefox is slow largely comes from that kind of compatibility hack, and people would probably make an informed choice to speed up their browser.

Such a fluffy article.

Here is what he's publishing: http://arxiv.org/find/cs/1/au:+Hinton_G/0/1/0/all/0/1

This seems to be a good introduction to the topic: http://arxiv.org/pdf/1310.4546v1.pdf

This is about paragraph vectors: http://arxiv.org/abs/1507.07998 http://arxiv.org/abs/1405.4053

Yup, it's basically a spider. The Anticontainer plug-in enhances it to fetch images that are a few steps away from the original page. Looks like it just needs unrestricted XHR, which greasemonkey and every other chrome extension already require. Maybe off-screen rendering, which could look like this: https://www.chromium.org/developers/design-documents/extensi...

OSes are getting hardened with a per-app security model (instead of per-account which you describe). Hardening Firefox so that it won't compromise itself through XPI (which are opaque to the OS) is part of a defense in depth strategy. Security policies can prevent applications from scribbling over each other's memories as a general rule, whereas attaching security labels to profile directories requires targeted policies that are much more fragile and full of false positives.

Feature parity is a meaningless term. Extensions currently have access to the entirety of Firefox internals. That huge internal surface couldn't be stabilised without stopping development entirely.

XPCOM has support for stable, versioned APIs, but no one cared about using that subset since the rest was also available; it stagnated and the supposedly unstable APIs ended up bearing the compatibility burden. Now there will only be a supported subset, and the trickier stuff will require getting a patch accepted instead of monkey-patching and letting the user cope with the breakage. Your coping skills are above average, I've submitted patches too, it's still yak shaving and not a very productive use of time. Working out APIs is a hard problem, it should be handled as part of the development phase instead of being completely disconnected.

Chrome did a similar change which led to a pretty spectacular drop: http://blog.chromium.org/2015/05/continuing-to-protect-chrom...

They'll probably be less broken, with a proper API: https://wiki.mozilla.org/WebExtensions#Additional_APIs

That kind of keyboard permission could be used for keyloggers though, it's not something every extension should get.

Tab Mix Plus is explicitly mentioned as something they'll support: https://wiki.mozilla.org/WebExtensions#Additional_APIs

They're using the WebExtension model of isolated extensions with permissions. They're not going to limit themselves to any competitor's API, they'll build a superset by consulting with the developers of popular extensions. Tab Mix Plus being the 15th most popular extension, it's pretty certain they'll be consulted on the new APIs.

Quoting from the announcement:

> A major challenge we face is that many Firefox add-ons cannot possibly be built using either WebExtensions or the SDK as they currently exist. Over the coming year, we will seek feedback from the development community, and will continue to develop and extend the WebExtension API to support as much of the functionality needed by the most popular Firefox extensions as possible.

Great news. With the current system, firefox's stability, upgrade compatibility and performance were entirely dependent on every author of every extension I use being sufficiently careful. It meant a lot of periodic purges, housekeeping, and reduced trust. I'm sure the overhead helped users move to chrome, despite Firefox's vanilla install being lighter. Reducing the API surface was a necessity.

Also, it takes a lot of effort to cope with the churn in internal APIs, and I had to get rid of promising extensions like Pentadactyl because they broke too often. With a smaller, stable API, that problem doesn't exist. I don't believe that the current tradeoff of power vs responsibility was working out in the majority of cases, and I've seen enough evidence in the form of lagging addons and neglected ports.

Hopefully enough has been altered that they can't be identified too easily. That said, it looks like they can, maybe should find better elsewhere.

xhtml worked like that, html5 has moved towards specifying the quirks that are used to deal with poor conformance. That said, if you look at a webdev console, things that cause poor performance (à la document.write) tend to be noted.

The novel part here is transducers and the funken package built on top of them, right? What are they used for, in your applications? The documentation is really terse and could use a few examples.

The next release (in six weeks) will also disable RC4 fallback, except for a few sites which are on a whitelist for one release after that.

The cross-compilation stuff is already addressed in the article. The jhybrid demo is a calculator and doesn't do storage.

> a magistrate judge with authority in any district where activities related to a crime may have occurred

Weasely enough that the warrant-seeker could pick a pet court wherever they have computers. There's a judge who made Marshall, East Texas the place to find software patents infringed with maximum damages. A similar venue would pop up.

Just don't enable any filter lists. A while back you had to add them manually; now I think it's a matter of unchecking them in the first-run dialog.

ABP also makes it easy to create very specific rules: only block a particular resource when accessed from the current domain.

This doesn't work with the push to HTTPS. Either you use proxy connect, and Privoxy is no better than /etc/hosts blocking. Or you'd rely on the proxy's poorer and slower implementation of TLS. Certificate verification will suffer (no certificate pinning, no certificate blacklist, no OCSP stapling, no way to verify incomplete chains), no SPDY, no sunsetting of bad ciphers or bad protocols.

Not really. I have some integrists (Catholics) in my family, and they took the trouble to forward e-mails explaining that they didn't really like Charlie Hebdo, because it wasn't respectful towards any religion. In fact, they don't think much of press freedom:

«freedom of expression and freedom of the press don't extend to insulting, showing contempt, blaspheming, trampling, mocking the faith or values of co-citizens». The justification: «insult is violence».

Possibly they are afraid of being mocked. Realizing that people didn't have to take (the idea of) god seriously was transformative for me.

Their email forward about Charlie Hebdo described a cartoon of pope benedict xvi «taking position on pedophilia» (sodomizing children), here's the drawing: http://culturebox.francetvinfo.fr/tendances/evenements/dessi... . The cartoon is not actually related to Charlie Hebdo, which goes to show they don't read it. That said, here's a drawing that's really be Charlie, lampooning the catholics for a hush-hush attitude to pedophilia: http://stripsjournal.canalblog.com/archives/2010/03/31/27376... . It's accurate: those well-to-do catholics I've talked to, including priests, reacted to the scandals strictly by being preoccupied with perception of the catholic church.

It's a worthwhile effort. If you just go with the first thing that goes through your head, you're probably repeating someone else's meme.

It's a shitty thing to equate islamic terrorists (Al-Qaeda, in this case) with Islam. Al Qaeda kills eight times more muslism than non-muslims: http://www.spiegel.de/international/world/surprising-study-o...

And Daeh is killing muslims and blowing up mosques: http://www.thedailybeast.com/articles/2014/10/07/isis-s-grue...

The idea that this is a clash of civilisations, rather than terrorists seeking to control co-religionists, is designed to drive both sides to their respective extremists.

That /robots.txt does tell the other bots to not crawl most of the site. These results are unlikely to stay.

Sorry, but any self-moderated forum is going to have content you don't like and lack content you like. That subreddit has the community's self-moderation, which scales, and moderators who don't. The moderators' aren't going to spend their day making judgment calls, they write clear rules[0] and let things take their course. “Must be peer-reviewed research” is pretty clear cut and the signal to noise is better than without it. Who cares if it's too strict; you have other subreddits.

[0] https://www.reddit.com/r/science/wiki/rules#wiki_submission_...

Seems like INRIA is starting to do some formal checking of OpenSSL. Here's their page: http://prosecco.gforge.inria.fr/

Here's another OpenSSL flaw that was found with Coq, a formal prover: http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Inject...