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 _______________________________________________ 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.
