cmcaine

OK, but you absolutely wouldn't let a self-driving car out without ernest human supervision or really rigorous testing would you?

Cars aren't killing people. Car drivers are killing people, usually because they are careless.

Compare the language used when pedestrians are killed by cyclists.

I use mpv on my laptop to get more out of the battery and to stop the fan annoying me.

No. Check the latest updates in the github thread.

1. We will release an update that we think is compatible with the AMO reviewers' demands. 2. You can just read the readme for the project on github for a non AMO but easy way to install it.

Another fun thing to note is that because they have delisted the addon users may also struggle to work out what is going on, which really goes against the whole "let's update this critical security preference" thing.

If they had left us listed but only with older versions we could have at least left a message in the addon description telling people about the issue and how to manually revert the preference for people who care. And obviously we would have done so if asked.

To my knowledge, no. They said they were working on it ages ago when they introduced the commands API for webextensions, but I don't think it is high on their priority queue.

Hello, I am one of the founding contributors to Tridactyl.

I think the three comments from this one[1] down summarise the overall issue well.

[1]: https://github.com/tridactyl/tridactyl/issues/1800#issuecomm...

After appealing the first reviewer's decision, we appealed to the amo-admins who basically said "we agree with reviewer 1 and will reject affected versions of the addon".

Apparently they have decided that all of our addon versions ever are affected (which is not really true) and have delisted the entire addon.

Further, they have asked us to also remove another opt-in feature that disables some CSP protections so that Tridactyl can insert its own UI into e.g. raw.githubusercontent.com. This is required because webextension content can still be blocked by a site's CSP setting, supposedly this is fixed in Firefox 69, but our testing is inconclusive and the new Firefox ESR is 68 anyway.

Our intention is to make tridactyl compatible with the AMO reviewers' requests for the sake of our users, but we're all very busy and none of us really wants to make these (in our opinion) overly invasive and unnecessary changes.

Our understanding is that users who have already installed Tridactyl will continue to have it installed and that new users will not be able to install it or find it on the AMO (where it has been removed with no explanatory text), but they can follow instructions on our github repo to install it fairly easily.

We believe that the AMO reviewers' choices do not serve the community and that a more suitable response would be to ask us to display prominent warnings over these features for our users and ask for their re-informed consent for their continued use.

We also note that loads of other extensions (including Mozilla-recommended addons) talk about the very same config settings that we have been delisted for on their AMO pages![2]

[2]: https://www.google.com/search?q=site:addons.mozilla.org+exte...

Just deleting the features and undoing the changes for all users (as Mozilla has asked us to do) means that Mozilla is forcing our users to adopt a risk model and level of risk aversion that I think is not actually appropriate for the majority of our users. If we want to trade a little security for functionality we should be able to do that.

You can have multiple versions of a program installed in linux. Most package managers won't help you very much with that, but it's about as easy as windows if the programs are interpreted or statically linked or compile easily with your system libraries.

NixOS and distri are notable package managers that do make installing different versions of packages pretty easy.

You can index rows in DataFrames in the same way you index rows in matrices:

julia> df = DataFrame(x = 1:10, y=2:11)

julia> df[1,:] DataFrameRow │ Row │ x │ y │ │ │ Int64 │ Int64 │ ├─────┼───────┼───────┤ │ 1 │ 1 │ 2 │

julia> m = rand(10, 2);

julia> m[3,:] 2-element Array{Float64,1}: 0.013457628869001814 0.2632480919750453

As for static typing/static analysis, that's something that can be built inside Julia (and several projects have done so). Personally, I would not want Julia to insist on static typing and much power comes from not overspecifying types.

The devs in the thread are those with [member] in their name. Which might just be me and bovine3dom.

None of the dev team believe that Mozilla are acting unconscionably. We believe roughly what I put in the post above.

E: and sure, it is a quote, but the immediate context matters.

This is a misrepresentation of our argument.

The very next sentences are:

"I am happy to be corrected on this. If you have any specific explanations you would like me to provide to our users, I would be happy to pass them on."

We also supported Mozilla's choice to move away from the XUL API.

I and most of the other core contributors are in favour of of capabilities-based security with explicit permission granting, not just in Firefox, but in general.

We believe that it should also be possible for users to have their software do what they want it to do. Part of that is letting people make their own decisions about what level of risk they are willing to accept.

We are reasonable people. We have been told in non-specific terms that something is unsafe that we think is useful and reasonably safe. So we have asked Mozilla (several times) to explain how it is unsafe so that we can update our beliefs if necessary.

We are asking because we know from experience that Mozilla employees generally have a lower tolerance for risk than us (the developers of tridactyl) or many of our users. Fundamentally, that is OK, but here Mozilla is asking us to do a bunch of work and change our code in ways we don't really want to do so that it more closely matches their risk tolerance than ours.

They can choose to manage their ecosystem how they like, but we in the ecosystem rightly also get a small say.

So we are asking them to say why and trying to negotiate a compromise that will be acceptable to all of us.

I am one of the developers of Tridactyl.

This dispute is because Tridactyl used to provide a function that users could choose to run that would change two of Firefox's settings (the kind you find in about:config). Changing these settings allows addons to run on e.g. addons.mozilla.org and accounts.firefox.org where they otherwise cannot. The change we made is the same change that several blogs had already talked about and suggested.

Here is a relevant bugzilla thread that motivated the creation of the blacklist that we turned off, so you can see what Mozilla thinks: https://bugzilla.mozilla.org/show_bug.cgi?id=1415644

A mozilla employee informally asked us to remove this function for security reasons (and we did). Later, an AMO reviewer asked us to change users' Firefox config automatically to remove these settings. We would rather this were made an explicit choice for Tridactyl users and we're trying to negotiate a compromise with the reviewer.

This is the only plausible route to exploitation of this situation that I know of, assuming a user acting before we removed the fixamo command:

1. You manually install Tridactyl

2. You manually install our native messenger

3. You manually run a command called `fixamo` or you manually find and install our exemplar RC file that explicitly says at the top that you should read and customise it because it does things you might not like; and then you don't read or edit it

4. You also manually install a malicious addon

5. That malicious addon doesn't have permissions for <all_urls> (otherwise it can steal your banking credentials without tridactyl's help) but does have permission for accounts.firefox.org

6. That addon can then steal your firefox account credentials and use them to e.g. mess with your synced settings and e.g. download your passwords database (if you don't have a master password set).

My view is that you're pretty much fucked if you install a malicious addon with <all_urls> anyway (and many addons request that permission), so this slight extra capability you get if you successfully phish someone in this pool of <1000 people isn't a big deal.

---

Some people have opined that our documentation for the command was not explicit enough. My opinion is that it's good enough and about on par with other resources that talked about the same settings. It would be better if it was more explicit about the security risks, but we provided fairly complete information about what we were doing and a link to the source code.

This is the documentation we provided:

In the "Webextension caveats" section:

"To make Tridactyl work on addons.mozilla.org and some other Mozilla domains, you need to open about:config, run fixamo or add a new boolean privacy.resistFingerprinting.block_mozAddonManager with the value true, and remove the above domains from extensions.webextensions.restrictedDomains."

In the docstring for fixamo, partially displayed if you type fixamo in the commandline and also included in the help pages we encourage users to use with e.g. `:h fixamo`:

"Simply sets

"privacy.resistFingerprinting.block_mozAddonManager":true "extensions.webextensions.restrictedDomains":""

in about:config via user.js so that Tridactyl (and other extensions!) can be used on addons.mozilla.org and other sites."

You can find these messages in src/excmds.ts at commit 92e1b005c47995e3d24f61a7d4c3935df8437f1a

We also included a variant of the fixamo command in the exemplar .tridactylrc file (not used unless you have also installed the native messenger and also explicitly found, downloaded and installed the exemplar). This file includes this text at the top:

"Provided only as an example.

Do not install/run without reading through as you may be surprised by some of the settings."

And this text right above the fixamo line:

"Make Tridactyl work on more sites at the expense of some security"

This is the documentation we provided:

"To make Tridactyl work on addons.mozilla.org and some other Mozilla domains, you need to open about:config, run fixamo or add a new boolean privacy.resistFingerprinting.block_mozAddonManager with the value true, and remove the above domains from extensions.webextensions.restrictedDomains."

And

"Simply sets

"privacy.resistFingerprinting.block_mozAddonManager":true "extensions.webextensions.restrictedDomains":""

in about:config via user.js so that Tridactyl (and other extensions!) can be used on addons.mozilla.org and other sites."

You can find these messages in src/excmds.ts at commit 92e1b005c47995e3d24f61a7d4c3935df8437f1a

The only way this hurts you as a user is if all of the following occurs:

1. You manually install Tridactyl

2. You manually install our native messenger

3. You manually fun a command called `fixamo` or you manually find and install our exemplar RC file that explicitly says at the top that you should read it because it does things you might not like; and then you don't read or edit it

4. You also manually install a malicious addon

5. That malicious addon doesn't have permissions for <all_urls> (otherwise it can steal your banking credentials without tridactyl's help) but does have permission for accounts.firefox.org

6. That addon can then steal your firefox account credentials and use them to e.g. mess with your synced settings and e.g. download your passwords database (if you don't have a master password set).

My view is that you're pretty much fucked if you install a malicious addon with <all_urls> anyway (and many addons request that permission), so this slight extra capability you get if you successfully phish someone in this pool of <1000 people isn't a big deal.

Only extensions that have a native messenger can do this (which requires users to accept a scary sounding permission and install a separate application on their computer)

The arguments made by tridactyl developers to Mozilla are published in the linked thread. There is no need to speculate.

We don't complain about walled gardens.

In our defence

1. that's a perfectly sensible comment to suggest that you should probably look it up on your own if you care about security.

2. The command did document exactly what it did in the same manner (or more detail) as the blogs we got it from.

3. We invited Mozilla to provide text for us to comment it with and they didn't give us any.

Edit: And as bovine3dom says, this was done in response to an informal request by someone reasonably friendly to the project.

> it involves modifying user.js without explicitly saying so, but that's literally exactly what they did already.

We have never modified firefox settings without a user explicitly opting in.

All the documentation for the `fixamo` function named the two firefox settings (as viewable in about:config) that `fixamo` would change.

`fixamo` was an opt-in feature that users were only going to find by reading our help files or asking us on our support channel.

Disclaimer: I am one of the authors of tridactyl.

Disclaimer: I am one of the authors of Tridactyl.

We did actually set another firefox setting that means that webextensions cannot access the privileged JS environment on AMO (to my knowledge).

We have invited Mozilla several times to provide some text for us to share with our users explaining what the issue is and they have demurred.

I think for 99% of users, if a webextension can run on all pages (which many do) it can hurt them a lot more by stealing credentials (which is quite easy) than by installing other addons (which is hard).

Sure, we could have included some more warnings but 1. we did document clearly what we were doing if anyone wanted to check up (we were just automating the advice given in several blogs); 2. I think I talked to some mozillian's about it at the time, and they were unconcerned, but maybe not, could have been a similar other issue; 3. last time I looked there was no good explanation of why this is actually dangerous anywhere.

For reference, the exact messages provided to users were:

"To make Tridactyl work on addons.mozilla.org and some other Mozilla domains, you need to open about:config, run fixamo or add a new boolean privacy.resistFingerprinting.block_mozAddonManager with the value true, and remove the above domains from extensions.webextensions.restrictedDomains."

And

"Simply sets

"privacy.resistFingerprinting.block_mozAddonManager":true "extensions.webextensions.restrictedDomains":""

in about:config via user.js so that Tridactyl (and other extensions!) can be used on addons.mozilla.org and other sites."

---

You can find these messages in src/excmds.ts at commit 92e1b005c47995e3d24f61a7d4c3935df8437f1a

To save other people fact checking this:

This quote is from https://nsarchive2.gwu.edu/NSAEBB/NSAEBB130/

The primary source is Fred Kaplan's "Wizards..." book.

Good search is a huge engineering challenge and nowhere-near solved. Google's continued dominance is what makes their ad space valuable.

If I were google, I would keep investing in improving search, and that would obviously include hiring machine learning and AI experts.

This is hardly a full lifecycle assessment.

The assertion is true only for cyclists eating a mad diet and only if:

1. Motorists really do eat less food than cyclists, controlling for other factors.

2. You only count transit-energy emissions (not construction or recycling or road maintenance or healthcare etc).

To my knowledge, there is no evidence that active travel modes are associated with greater calorie consumption. There is plenty of evidence that all kinds of important externalities are worse for any kind of car-travel versus cycling.

You can perhaps make an argument based on average lifespan that motoring is better for the environment because it costs more life years per km, but advocating for shorter lives in the name of carbon emissions is not going to be popular (and if so, there are less polluting ways to do it).

Escape will always exit fullscreen in browsers, which is a SAK that is well publicised.

We aren't trained to press escape before entering passwords, though.

I have never seen a SAK-before-login notice on any linux machine. Only one institutional setting, I suppose.

> Criminal charges

Heh, I don't think so. Teachers don't like to send their pupils to court for silly things. They'd just get told why not to do it again and probably get some detention and stuff.

At a uni, the consequences might be more severe.

Python lambdas cannot contain statements, only expressions. Typical python contains a lot of statements, so that's a bit annoying.

You can define inner functions and so on, and most of the times that I want to use lambdas it's just because I've been stuck in a language without *-comprehensions for too long.

+ works fine on complex numbers.

I'm not super familiar with the loop macro, but it lets you do both things similar to a python comprehension and to a python for loop. I don't think it does anything you can't do in python.

Because we'll only be 3/5ths as good :)

Or maybe because we're only trying.

https://riot.im/app/#/room/#tridactyl:matrix.org/$1507907809...

The zotero main program is now a standalone thing, but there's a webextension that lets you add things to your library. Looking into it, it seems you can get a rudimentary experience with a bookmarklet/jseval:

https://www.zotero.org/downloadbookmarklet

I'm glad that Greasemonkey support is coming, though. Will the GM scripts run in the same JS scope as page scripts?

Webkit forks also render text slightly worse for HiDPI screens and don't seem to support CSS `hyphens: auto`. Which is annoying because I really like justified text.

When I last tried, the adblocker wasn't as good as ublock. If I were to switch now, I would miss easy access to my passwords, referrer control, zotero, and RES (a bit, a userscript would do).

Some of the adblock issue is possibly an engine problem (there's some pre-script hooks that Webkit-forks don't support).

Thanks for mentioning us, Florian.

We're aiming to get Tridactyl to feature-equality with Vimium and Saka-Key by the end of this weekend. (We are runnable now, but it's not a fantastic UX)

We hope to match or exceed the current WebExtension state of the art (cVim) by the FF57 release date (Mid November).

Our longer-term roadmap depends on how responsive Mozilla are to our feature requests. They've suggested that our two most important API extensions could be merged in FF58 (Jan 2018? I forget), but we'll have to see.

If you don't want to run other WebExtensions or Firefox, Qutebrowser offers a really good solution :)