Giorgio Maone:
> On 12/05/2015 18:54, sajolida wrote:
>>
>> B. It's not the latest version of the extension. This version is
>> incompatible with the version of the page. We can't go forward or
>> otherwise stuff won't work:
>>
>> - How can we detect that? Through a version number in the URL as you
>> are proposing? Wouldn't a version number in the code of the page be more
>> simple?
>
> I vote for a version string at a fixed location (<div
> id="ui-version">1.0</div>) of the HTML.
> Of course, we can keep it user-invisible via CSS (#ui-version { display:
> none }).
>
>> - Then what do we do once we detected that incompatibility? Redirect
>> to a compatible version of the page that we're keeping on the website
>> for backward compatibility?
>
> The extension can detect the incompatibility and ask the user that if
> she wants to proceed by upgrading the downloader first ([Upgrade
> Downloader] / [Abort]).
> On [Upgrade Downloader], the extension forces its own upgrade to be
> performed quietly (with no further prompts / warning unless something
> goes wrong, e.g. if AMO's SSL certificate is bogus) and goes on with the
> download+verify process.
>
>> C. It's not the latest version of the extension. This version is
>> compatible with the version of the page but we did a security upgrade of
>> the extension and we want to force people to update. In that case, we
>> need something on the page that says which version of the extension is
>> expected and asks for an upgrade if it doesn't match. That would be a
>> different version of slide 3 but to "update" instead of "install".
>
> Same as B above.
That works for me. But then why not use the version of the extension
instead of the version of the HTML code (aka 'ui')?
Because in the case we issue a security update on the extension only
(the HTML code is not modified), then how does the outdated version of
the extension knows that it needs upgrade?
So we could instead embed the minimum version of the extension required
(maybe <div id="extension-version">1.0</div> or something like this).
Then the extension would know if it's outdated, even if the HTML code of
the page didn't change drastically, and display the first screen
accordingly.
I'm making here a difference between what would be the version of the
page and the version of the extension because intrigeri pointed this out
while proposing to have version numbers for the URL. But in the proposal
that I'm doing now, there won't actually be a proper version number for
the page, only for the extension.
> Of course all of this is particularly relevant for those who have
> automatic add-ons updates disabled, such as Tor Browser users AFAIK.
> "Regular" Firefox users would usually receive the most recent version of
> the extension silently and timely through AMO.
My understanding is that Tor Browser also upgrades its extension as
usual (except Torbutton and Tor Launcher), see:
https://lists.torproject.org/pipermail/tbb-dev/2015-April/000258.html
Ah, and for your curiosity, I started to type some draft HTML code for
that page. Dumping the strings we had in the wireframe and adding some
ids and classes. It's in a blueprint too:
https://tails.boum.org/blueprint/bootstrapping/extension/prototype
But it doesn't make much sense yet until tchou adds some CSS and
bootstrap to it.
--
sajolida
