They are referring to hiding individual tabs, not hiding the horizontal tab bar.
The legacy extension they are referring to is Tab Groups [0]. It allowed you to separate the tabs of a single session into groups. Selecting the active group would hide the other tabs.
Still, it seems that the current API couldn't really support that use-case if tabs with active audio or video can't be hidden. At least there will be some random tabs hanging around that don't belong to your group.
But the main use-case for this API seems to be organizing things - and it's strange that I would want certain tabs not take part in my organisation scheme.
If I had virtual desktop support, but certain windows are nevertheless shown on all desktops, that would feel broken, too.
Of course notifying users of audio/video recording is important, but this could be done with a separate notification - with options to stop recording or activate and un-hide the tab.
I don't know if this is the case, but the API ought to also let you kill any active video or audio streams playing in a tab. Then you'd be able to go ahead with hiding them.
If this is not possible or planned, it feels kind of broken in my view.
Could you be more specific? I don't believe this is a known issue. If you're experiencing this behavior, you may want to report it: https://github.com/philc/vimium/issues
Personally, I'm running Firefox 55.0.3 with `vimium-ff` 1.6.0 (current build on addons.mozilla.org), and the `t` keybinding opens new tabs just like `Ctrl-t`. Command repetition also works (eg, `5t`).
I also find that briefly paraphrasing the abstract helps me understand my own expectations of the paper. Even if the paraphrase is wrong, it's still a good primer for switching into active engagement instead of passive absorption. Also, when you finish the paper you can review and correct your initial impressions; sort of like tutoring yourself (which personally I find helpful from both perspectives, tutor and tutee).
Regarding importance, it provides an efficient alternative to RSA.
[edit: this paragraph, based on my old notes on the subject, seems to be incorrect, see sdevlin's comment below]
More specifically, because of the RSA dependency on prime numbers, the RSA effective key space is very sparse (which is why going from 2048-bit RSA to 4096-bit RSA only increases the effective key space by ~16%). With elliptic curves, the key space is very dense, which reduces the key size for an "equivalent" encryption strength. Elliptic curve solutions also tend to be more computationally efficient, both in terms of key generation as well as encryption operations; this performance delta increases rapidly as "equivalent" key sizes grow.
Regarding "trending":
-- They're under active fundamental research, which is fun (RSA is well established, whereas new EC proposals are still under active debate)
-- They've been the subject of some drama, which is also "fun" (conspiracy theories related to several EC proposals/recommendations, debates regarding a primary EC researcher, etc)
> More specifically, because of the RSA dependency on prime numbers, the RSA effective key space is very sparse (which is why going from 2048-bit RSA to 4096-bit RSA only increases the effective key space by ~16%). With elliptic curves, the key space is very dense, which reduces the key size for an "equivalent" encryption strength.
This isn't correct.
The reason RSA (and classic DH) keys are gigantic is because index calculus techniques yield efficient attacks on systems based on finite fields. We need big keys to make them impractical.
EC systems are not susceptible to these attacks because the points on a curve comprise only a group and not a field. Counterintuitively (to me, at least!), they're safer because they have less structure.
On the question of whether it's intuitive or not: NP-complete problems tend to have fairly little structure. A problem like boolean satisfiability has basically no structure: all you have is a soup of clauses. The "tricky" problems that have solutions in P get their solutions from clever exploitation of structure.
At least, that's how it becomes more intuitive to me.
The structure of a problem specifies it; an unstructured problem is less well-specified, and that makes it intuitively more difficult to approach.
E.g. summation of a column of decimal numbers is a highly structured problem that's very easy to solve. Parsing the speech of yelling drunkards is not so structured, and much harder to solve.
Very informative, thanks for the detailed response. To be clear, was my statement incorrect in terms of the "16%" quotation (from [0], which I now realize I misquoted in my private notes), or in the claim that the RSA key space density is low due to the dependency on prime numbers?
My private notes include a claim (original source uncited, sadly) that because the prime density from 1..n decreases (approximately) as `1/ln(n)`, then the corresponding effective key space density for RSA decreases at a related rate, which was what led to the corresponding reduction in the "equivalent" key size. If my notes on this are complete bunk I'd love to hear it. (Even a simple 'yes' would suffice and I'll revisit the subject.) Ta!
It's true that the space of valid RSA keys is sparse relative to size, but this isn't why we need big keys. As a counterexample, classic DH keys are also big (or they can be), even though the space of valid keys is dense.
We need big keys (or rather big fields) due to index calculus. This is a family of algorithms used to factor integers and compute discrete logarithms in finite fields. The fact that index calculus is (thus far) inapplicable to elliptic curve groups is the primary motivation for ECC.
The legacy extension they are referring to is Tab Groups [0]. It allowed you to separate the tabs of a single session into groups. Selecting the active group would hide the other tabs.
[0] https://addons.mozilla.org/en-US/firefox/addon/tab-groups-pa...