intrigeri:
> sajolida wrote (07 May 2015 16:12:52 GMT) :
>> The v1 part of the URL corresponds to the version of the extension.
>
> I would suggest giving its own versioning to the URL scheme used by
> the extension, instead of re-using the extension's versioning.
> Otherwise, we'll have to maintain more parallel copies of the same
> files on our website, and then it'll require tools and automation, and
> then someone will have to write the code and review it and make it
> good enough, and then there will be bugs and maintenance burden, etc.,
> you know the drill => the less often that URL scheme version changes,
> the better.
>
> Five minutes later, on second thought: or perhaps the idea is to only
> support *one* version of the extension at a given time? If that's the
> case, then the extension will need to detect when it's not supported
> anymore (how?), and to tell the user about it, and then it'll have to
> violate the "must not embed any user-visible string in its code"
> principle. Food for thought :)
Thanks for pushing this discussion forward. Unfortunately, it seems like
we're not there yet...
Let's consider that someone, who already has some version of the
extension installed, lands on the page to download the ISO image (see
the wireframe, our idea was to have all this on a same page = under the
same URL). Let's say it's called /download or whatever the website leads to.
I can see different cases here:
A. The user has the latest version of the extension and the extension
works fine with this version of the page. Nothing to do, we should go
ahead and show the download button (slide 9 of the latest wireframe):
https://labs.riseup.net/code/attachments/download/764/extension-20150505.fodg
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?
- 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? Let's say /download/v0.5? Why not. We should
maybe propose to update the extension to its latest version instead.
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".
This wouldn't break the rule of "user-visible string in its code" since
all those strings are on the page, shown or hidden either by the browser
and extension detection code on the page or by the extension itself.
I feel like the need for an updated version in case of security issue is
maybe even stronger than the need for backward compatibility with
previous versions (as Firefox checks for updates once per day). So we
need something else on top of the mere URL versioning. We need to be
able to enforce a given version of the extension on the page. And then,
why not use this same mechanism to only support one version of the
extension?
I think that the case of Tails Upgrader (where you used URL versioning)
is quite different from ours. In the case of Tails Upgrader, the
software itself, installed on a USB stick, was deciding which URL to
fetch, and expecting to find something compatible there.
In the case of the extension, the user, through the website and the
assistant, lands on some page. And from there, the extension must be
able to do its work. The URL is not hard-coded in the extension and the
extension doesn't care about which URL it's running from.
Does that make sense?
>> ISO DESCRIPTION FILE
>
> Just a semi-random suggestion: perhaps including a link to the release
> notes would give more flexibility in the future. E.g. it might be nice
> to point users at the release notes while they're downloading the ISO
> in order to do a full upgrade. Perhaps that can be handled on the
> website side. Well, it's cheap to stuff this info to the IDF (!), and
> doing it now may avoid having to deal with an IDF format change in the
> future, so if it were me, I would just do it.
That's now
https://labs.riseup.net/code/issues/9386.
> My only remaining comment is that the threat model doesn't mention
> attacks, from inside the browser, on the web page that does the
> verification. Of course, I know you're still waiting for feedback from
> security experts in this field, so my suggestion may seem premature.
>
> However, it seems to me that the entire design of this new bootstrap
> process relies on the integrity of web pages retrieved from our web
> site and displayed in a web browser, so perhaps it's not too early to
> clarify that we don't try to protect against this specific type
> of attacks.
>
> And then, the feedback you'll get will allow us to assess how big
> a risk it really is, even if it's probably too late for it to
> substantially affect the entire new bootstrapping process as it has
> been designed.
Added in e8d315d.
--
sajolida
