Re: [Tails-dev] Update on Firefox extension
Giorgio Maone:
> On 31/08/2015 20:55, sajolida wrote:
>> Giorgio Maone:
>>
>>> The main roadblock was Mozilla finalizing its add-ons migration strategy
>>> to the Electrolysis (e10s) multi-process & sandboxing architecture.
>>> Without an ultimate public decision, which has been deemed "imminent"
>>> for all the past month (see
>>> https://labs.riseup.net/code/issues/8567#note-7 ), it was hard to even
>>> decide which of the 4 different technical approaches to develop Firefox
>>> add-ons was the best for this project:
>>>
>>> 1. XUL/XPCOM, like desktop NoScript;
>>> 2. restartless, like Android NoScript;
>>> 3. Add-on SDK;
>
> First of all, let me clear what seems to be a qui pro quo I've
> involuntarily induced: I wrote "restartless add-ons" because that's
> their most commonly used name, but in this context I would better have
> used the "bootstrapped add-ons" designation, in orde to prevent the
> false impression that Add-on SDK extensions are not restartless themselves.
>
> Please notice that *Add-on SDK extensions are restartless add-ons*: the
> difference between #2 (bootstrapped) and #3 (SDK) is just the API
> they've got available, i.e. just bare XPCOM for #2 and a pure-JS
> sandboxed abstraction for #3.
>
> Only #1 (XUL/XPCOM legacy add-ons) require a browser restart after
> installation.
> As far as I understand, this should already wipe off most of the worries
> you expressed about the Add-on SDK :)
That's what I imagined :) *Big relief*
>> If I understodd correctly, these were the three options that were
>> already available previously.
>
> Indeed. During the past few months I've been involved in Mozilla's
> e10s/add-ons team, so I've been aware early that all these options were
> going to be deprecated sooner or later, hence my decision to defer any
> implementation commitment, but an actual schedule and details about the
> ultimate replacement have been missing until mid-August, mostly because
> a migration strategy for existing add-ons required careful planning and
> long discussions, both technical and "political". Even now, the
> situation is still in development.
Now I understand better your position. Thank you for taking the time to
mature this decision.
>> This move to WebExtensions indeed sounds interesting from a portability
>> point of view.
>
> Yes it does, even though there won't be a 1:1 mapping between the APIs,
> but more like a "shared core" intersection plus browser-dependent
> customizations reflecting the peculiarities of each browser and the
> expectations of its own user base (e.g. Mozilla will neglect those APIs
> whose main purpose is integrating with Google service, while is
> committed to make the features needed by the most popular current
> extensions available "natively" on the long run).
> Also, different browsers are going to use different formats and signing
> protocols, therefore cross-browser development will require at least
> some repackaging step.
Yes, that's how I understood it.
>> So the dilemma we're facing here is to find the proper technology to
>> use in order to be compatible with Electrolysis (FF43) while not being
>> able to write it in WebExtensions (no ETA). Sounds like a pretty bad
>> time to start writing new Firefox extensions :)
>
> That's the biggest elephant in the room at this moment, indeed,
> especially if you've got ESR compatibility as a requirement :(
> Things should get more exciting (very exciting, I believe) as soon as
> both the WebExtensions API and its native.js mechanism are supported in
> all stable Firefox versions, which unfortunately seems to be about one
> year away.
>
>> I understand that Firefox wants to deprecate XUL/XPCOM, so we're left
>> with option 2. restartless, and 3. Add-on SDK. But how do you choose
>> Add-on SDK from these two:
>
> Simple: non-SDK bootstrapped (restartless) add-ons can work without XUL,
> but still depend on XPCOM heavily, therefore they're not gonna outlive
> the XUL ones.
>
> Add-on SDK extensions are basically restartless add-ons themselves, but
> they run in a sandbox providing them with a rich high-level API
> available as CommonJS modules, and under certain constraints (i.e. not
> using XPCOM "super powers" which are currently available but are gonna
> be deprecated as well) are automatically compatible with Electrolysis,
> while bootstrapped ones require a considerable additional effort to
> achieve the same compatibility.
> In fact, the announcement states that Add-on SDK extensions will be
> supported for the foreseeable future as long as they don't call
> require('chrome'), i.e. as long as they don't touch XPCOM directly.
There's another fact that I didn't get initially: Add-on SDK are
automatically compatible with Electrolysis. Everything is clear now!
>> - Do you need to restart the browser after installing a Add-on SDK
>> extension? If so, then we probably need to rethink our wireframe,
>> rethink what happens in browser with no history like Tor Browser, etc.
>
>
Re: [Tails-dev] Update on Firefox extension
On 31/08/2015 20:55, sajolida wrote:
> Giorgio Maone:
>
>> The main roadblock was Mozilla finalizing its add-ons migration strategy
>> to the Electrolysis (e10s) multi-process & sandboxing architecture.
>> Without an ultimate public decision, which has been deemed "imminent"
>> for all the past month (see
>> https://labs.riseup.net/code/issues/8567#note-7 ), it was hard to even
>> decide which of the 4 different technical approaches to develop Firefox
>> add-ons was the best for this project:
>>
>> 1. XUL/XPCOM, like desktop NoScript;
>> 2. restartless, like Android NoScript;
>> 3. Add-on SDK;
First of all, let me clear what seems to be a qui pro quo I've
involuntarily induced: I wrote "restartless add-ons" because that's
their most commonly used name, but in this context I would better have
used the "bootstrapped add-ons" designation, in orde to prevent the
false impression that Add-on SDK extensions are not restartless themselves.
Please notice that *Add-on SDK extensions are restartless add-ons*: the
difference between #2 (bootstrapped) and #3 (SDK) is just the API
they've got available, i.e. just bare XPCOM for #2 and a pure-JS
sandboxed abstraction for #3.
Only #1 (XUL/XPCOM legacy add-ons) require a browser restart after
installation.
As far as I understand, this should already wipe off most of the worries
you expressed about the Add-on SDK :)
> If I understodd correctly, these were the three options that were
> already available previously.
Indeed. During the past few months I've been involved in Mozilla's
e10s/add-ons team, so I've been aware early that all these options were
going to be deprecated sooner or later, hence my decision to defer any
implementation commitment, but an actual schedule and details about the
ultimate replacement have been missing until mid-August, mostly because
a migration strategy for existing add-ons required careful planning and
long discussions, both technical and "political". Even now, the
situation is still in development.
>
> This move to WebExtensions indeed sounds interesting from a portability
> point of view.
Yes it does, even though there won't be a 1:1 mapping between the APIs,
but more like a "shared core" intersection plus browser-dependent
customizations reflecting the peculiarities of each browser and the
expectations of its own user base (e.g. Mozilla will neglect those APIs
whose main purpose is integrating with Google service, while is
committed to make the features needed by the most popular current
extensions available "natively" on the long run).
Also, different browsers are going to use different formats and signing
protocols, therefore cross-browser development will require at least
some repackaging step.
> So the dilemma we're facing here is to find the proper technology to
> use in order to be compatible with Electrolysis (FF43) while not being
> able to write it in WebExtensions (no ETA). Sounds like a pretty bad
> time to start writing new Firefox extensions :)
That's the biggest elephant in the room at this moment, indeed,
especially if you've got ESR compatibility as a requirement :(
Things should get more exciting (very exciting, I believe) as soon as
both the WebExtensions API and its native.js mechanism are supported in
all stable Firefox versions, which unfortunately seems to be about one
year away.
> I understand that Firefox wants to deprecate XUL/XPCOM, so we're left
> with option 2. restartless, and 3. Add-on SDK. But how do you choose
> Add-on SDK from these two:
Simple: non-SDK bootstrapped (restartless) add-ons can work without XUL,
but still depend on XPCOM heavily, therefore they're not gonna outlive
the XUL ones.
Add-on SDK extensions are basically restartless add-ons themselves, but
they run in a sandbox providing them with a rich high-level API
available as CommonJS modules, and under certain constraints (i.e. not
using XPCOM "super powers" which are currently available but are gonna
be deprecated as well) are automatically compatible with Electrolysis,
while bootstrapped ones require a considerable additional effort to
achieve the same compatibility.
In fact, the announcement states that Add-on SDK extensions will be
supported for the foreseeable future as long as they don't call
require('chrome'), i.e. as long as they don't touch XPCOM directly.
> - Do you need to restart the browser after installing a Add-on SDK
> extension? If so, then we probably need to rethink our wireframe,
> rethink what happens in browser with no history like Tor Browser, etc.
Fortunately that's not the case, since Add-on SDK extensions are
themselves restartless :)
>
> - What's the problem with restartless extensions? Will they become
> deprecated? Do they rely on XUL? Are they not e10s ready? Would they be
> much harder to port to WebExtensions?
All the above, as I already explained, except probably the portability,
which won't be a cakewalk in either case.
However coding with portability in mind is obviously easier now than two
weeks
[Tails-dev] Update on Firefox extension
Hi, Meta: putting tails-ux in copy for the info but please answer on tails-dev only. I wanted to clarify a bit what's going on regarding the development of the Verification Extension (#7552). In terms of specs, I realized that we were not taking into account the case where the download might get interrupted either on the client side by a faulty network connection, either on the server side by a faulty mirror. That's now #9717 and I proposed a mockup: https://labs.riseup.net/code/attachments/download/922/extension-20150828-resume.pdf Tchou, can you have a look (as I couldn't assign the ticket to both you and Maone). In terms of HTML+CSS, we're still waiting for tchou to review and mockup the code on /blueprint/bootstrapping/extension/prototype. That's #9384. And to draft a CSS. That's #9385. Tchou, any ETA on that? In terms of mirror support, we did great progress to disable ETags on all the mirrors. Only one of two still have them but we can replace them pretty much any time if needed. In terms of extension code, Maone told us he would be busy with other extension work over the summer but maybe he's back on track now. Giorgio what's up? Do you have any ETA for a first prototype? Anything blocking you? Just to let you know, we want to do extensive user testing sessions of the whole process (Installation Assistant + Verification Extension) in November. So we need all the pieces to be ready by then. ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Update on Firefox extension
sajolida: https://labs.riseup.net/code/attachments/download/922/extension-20150828-resume.pdf Broken link: https://labs.riseup.net/code/attachments/download/924/extension-20150828-resume.png ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] Update on Firefox extension
On 28/08/2015 17:37, sajolida wrote: In terms of extension code, Maone told us he would be busy with other extension work over the summer but maybe he's back on track now. Giorgio what's up? Do you have any ETA for a first prototype? Anything blocking you? The main roadblock was Mozilla finalizing its add-ons migration strategy to the Electrolysis (e10s) multi-process sandboxing architecture. Without an ultimate public decision, which has been deemed imminent for all the past month (see https://labs.riseup.net/code/issues/8567#note-7 ), it was hard to even decide which of the 4 different technical approaches to develop Firefox add-ons was the best for this project: 1. XUL/XPCOM, like desktop NoScript; 2. restartless, like Android NoScript; 3. Add-on SDK; 4. WebExtensions, the new, future proof, Chromium-like thing (not even disclosed yet until last week, but I was aware of it earlier because I've been working closely with the e10s/add-ons team) This finally happened last week, with this announcement: https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/ More about WebExtensions: https://wiki.mozilla.org/WebExtensions/ https://wiki.mozilla.org/WebExtensions/FAQ As I told intrigeri when we met, I had really hoped to develop our extension with the new API to improve its longevity and make a Chrome porting easy to do and maintain, but unfortunately, as you can also deduce from the links above, the decision have been dragged for so long that we wouldn't be able to support the Tor Browser (based on ESR) for about on year. Furthermore, until my own native.js proposal ( https://discourse.mozilla-community.org/t/proposal-native-js-to-embrace-extend-the-webextensions-api/3457 ) gets implemented ( https://bugzilla.mozilla.org/show_bug.cgi?id=1199718 -- filed just minutes ago), the WebExtensions API is not powerful enough to support our requirements. Therefore the only currently available option ensuring longevity is the Add-ons SDK (AKA Jetpack). I've just received guarantees from Mozilla (in a meeting held today) that they will give us any assistance for our extensions to be supported by any of the foreseeable future Firefox versions. I've already set up a development environment and started hacking. I'm gonna commit something to the git repository next week, and a working prototype most likely by the end of September. Just to let you know, we want to do extensive user testing sessions of the whole process (Installation Assistant + Verification Extension) in November. So we need all the pieces to be ready by then. I'm confident it's going to happen timely. -- G ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
