Re: [Tails-dev] extension specification
Giorgio Maone: On 15/05/2015 18:14, sajolida wrote: So we could instead embed the minimum version of the extension required (maybe div id=extension-version1.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. That would be perfect, yes. Cool, I updated the blueprint accordingly with commit 4b63f6c. -- 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.
Re: [Tails-dev] extension specification
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-version1.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-version1.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
___
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] extension specification
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-version1.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.
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.
--
Giorgio Maone
https://maone.net
___
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] extension specification
Oops, I didn't meant to answer this in private. Answering back to the list... Giorgio Maone: On 07/05/2015 18:12, sajolida wrote: Hi Giorgio, A few days ago we finished a wireframe of the extension that we believe is a good start for you to work on. It might still change slightly as we continue discussing small details of it. See https://labs.riseup.net/code/attachments/download/759/extension-20150430.fodg. Looks great, thank you! I'm glad you like it. We also updated the blueprint with some more implementation information. https://tails.boum.org/blueprint/bootstrapping/extension/ See the sections: - Non goals - User scenario and wireframe - Integration in the web assistant - Initial browser detection - Checksum verification - Data source Regarding initial browser detection, I can also provide the JavaScript for browser sniffing and browser-specific web content provision if needed. Yes, that's what we had in mind :) So I'll try to specify that a bit better once we have a prototype of the page to work on. Does all this sounds reasonable to you? Yes it does. Cool! I think that what we need to work on together now is to specify which HTML tools (div, class, etc.) you will need in the code of those web pages to be able to do your stuff. Then tchou and I will start writing the HTML code for those pages. I'd actually feel more comfortable with you providing the HTML written the way you prefer best from a web authoring standpoint, and me developing my interaction code around the structure you come up with, bending it to my needs only if really necessary (e.g. by adding a missing id or class attribute) Ok, so our next step is to work on a prototype of the page. Before you can start coding for real we'll also need a name for the extension. We'll try to sort this out quickly, see #9295. Feel free to comment on the latest proposals. I cast my vote for Download and Verify Tails: unambiguous and future-proof, in case should the verification process change. Yeah, everybody likes this one. We also want to ask you whether you think we should have some written contract for your work with the specifications, deadlines, conditions, and so on. We don't usually do that when we work amongst ourselves but if you require one we can maybe get something. Informal email exchanges like this and the ones you initially contacted me with will work just fine, thank you. Ok. Otherwise, at least regarding the deadlines we'll have to deliver the web assistant to Hivos by the end of the year but we'll do several iterations before that and it would be great to have something on which we can do user testing let's say before July. Does that sound reasonable to you? I'm currently very busy with the Firefox transition to the Electrolysis multi-process architecture (enhancing security through low-privilege content sandboxing), and specifically with adapting NoScript to it and helping developers of other popular and complex add-ons who are facing the same challenges. Therefore, end of July or beginning of August is more realistic IMO, even though I'll do my best to prototype it ASAP. Yeah, that will work for us too. We wanted to do some user testing at a conference in June but we won't have all the rest perfectly ready neither so we'll just test whatever we have. On the upside, you're guaranteed of being provided with an Electrolysis-ready add-on, rather than testing something earlier which only later is found to cause troubles in multi-process Firefox. Nice. I should inform myself better about Electrolysis :) -- 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.
Re: [Tails-dev] extension specification
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
Re: [Tails-dev] extension specification
On 07/05/2015 18:12, sajolida wrote: Hi Giorgio, A few days ago we finished a wireframe of the extension that we believe is a good start for you to work on. It might still change slightly as we continue discussing small details of it. See https://labs.riseup.net/code/attachments/download/759/extension-20150430.fodg. Looks great, thank you! We also updated the blueprint with some more implementation information. https://tails.boum.org/blueprint/bootstrapping/extension/ See the sections: - Non goals - User scenario and wireframe - Integration in the web assistant - Initial browser detection - Checksum verification - Data source Regarding initial browser detection, I can also provide the JavaScript for browser sniffing and browser-specific web content provision if needed. Regarding the data source, we need to know whether YAML works for you as we already create very similar YAML files for the automatic upgrades. It works for me, no problem. May I just ask, though, why YAML and not, for instance, JSON? Does all this sounds reasonable to you? Yes it does. I think that what we need to work on together now is to specify which HTML tools (div, class, etc.) you will need in the code of those web pages to be able to do your stuff. Then tchou and I will start writing the HTML code for those pages. I'd actually feel more comfortable with you providing the HTML written the way you prefer best from a web authoring standpoint, and me developing my interaction code around the structure you come up with, bending it to my needs only if really necessary (e.g. by adding a missing id or class attribute) If that's relevant for you, note that we will most likely use bootstrap for the CSS of those pages. So for example the progress bar would have this markup: http://getbootstrap.com/components/#progress That's fine. Before you can start coding for real we'll also need a name for the extension. We'll try to sort this out quickly, see #9295. Feel free to comment on the latest proposals. I cast my vote for Download and Verify Tails: unambiguous and future-proof, in case should the verification process change. In all your work, it's also important to keep in mind that we'll try to have a similar extension for Chrome at least very soon. I don't know if you can make coding decisions that are more portable than others, but we should do that as much as possible. Yes I can and I had already planned to. We should also try to make the code as little Tails specific as possible. Of course it will be Tails specific as a first implementation, but we'd like to keep the Tails specific bits at least easy to factor out later on if other distros want to reuse our design and make it more generic. That was my idea too, I don't like to waste potentially reusable stuff. We also want to ask you whether you think we should have some written contract for your work with the specifications, deadlines, conditions, and so on. We don't usually do that when we work amongst ourselves but if you require one we can maybe get something. Informal email exchanges like this and the ones you initially contacted me with will work just fine, thank you. Otherwise, at least regarding the deadlines we'll have to deliver the web assistant to Hivos by the end of the year but we'll do several iterations before that and it would be great to have something on which we can do user testing let's say before July. Does that sound reasonable to you? I'm currently very busy with the Firefox transition to the Electrolysis multi-process architecture (enhancing security through low-privilege content sandboxing), and specifically with adapting NoScript to it and helping developers of other popular and complex add-ons who are facing the same challenges. Therefore, end of July or beginning of August is more realistic IMO, even though I'll do my best to prototype it ASAP. On the upside, you're guaranteed of being provided with an Electrolysis-ready add-on, rather than testing something earlier which only later is found to cause troubles in multi-process Firefox. Ah, and we took it for granted but your code will be public, GPL, and all from (almost) the beginning, right? Sure thing! Maybe we should create you a repo on git-tails.immerda.ch. Why not? -- 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.
Re: [Tails-dev] extension specification
Hi Giorgio, Giorgio Maone wrote (08 May 2015 21:29:44 GMT) : May I just ask, though, why YAML and not, for instance, JSON? We already have quite some code to generate, update and validate YAML documents with a very similar purpose and content. Sticking to YAML would allow us to re-use some of this code. Besides, we're using YAML in way more places than JSON in Tails currently, so that's also what we know best in-house. Maybe we should create you a repo on git-tails.immerda.ch. Why not? Please send tails-sysadm...@boum.org, in an OpenPGP-signed email: - your preferred user name there (ma1, just like on Redmine to keep things simple?) - a SSH public key And then the repo will be created in a few days, when I get some credentials of mine back (or earlier if my team-mate beats me to it). Cheers, -- intrigeri ___ 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] extension specification
Hi, sajolida wrote (07 May 2015 16:12:52 GMT) : We also updated the blueprint with some more implementation information. https://tails.boum.org/blueprint/bootstrapping/extension/ Impressive. I took a look and pushed a few nitpicking changes. A few comments and suggestions follow: 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 :) 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. 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. Cheers, -- intrigeri ___ 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.
[Tails-dev] extension specification
Hi Giorgio, A few days ago we finished a wireframe of the extension that we believe is a good start for you to work on. It might still change slightly as we continue discussing small details of it. See https://labs.riseup.net/code/attachments/download/759/extension-20150430.fodg. We also updated the blueprint with some more implementation information. https://tails.boum.org/blueprint/bootstrapping/extension/ See the sections: - Non goals - User scenario and wireframe - Integration in the web assistant - Initial browser detection - Checksum verification - Data source Regarding the data source, we need to know whether YAML works for you as we already create very similar YAML files for the automatic upgrades. Does all this sounds reasonable to you? I think that what we need to work on together now is to specify which HTML tools (div, class, etc.) you will need in the code of those web pages to be able to do your stuff. Then tchou and I will start writing the HTML code for those pages. If that's relevant for you, note that we will most likely use bootstrap for the CSS of those pages. So for example the progress bar would have this markup: http://getbootstrap.com/components/#progress Before you can start coding for real we'll also need a name for the extension. We'll try to sort this out quickly, see #9295. Feel free to comment on the latest proposals. In all your work, it's also important to keep in mind that we'll try to have a similar extension for Chrome at least very soon. I don't know if you can make coding decisions that are more portable than others, but we should do that as much as possible. We should also try to make the code as little Tails specific as possible. Of course it will be Tails specific as a first implementation, but we'd like to keep the Tails specific bits at least easy to factor out later on if other distros want to reuse our design and make it more generic. We also want to ask you whether you think we should have some written contract for your work with the specifications, deadlines, conditions, and so on. We don't usually do that when we work amongst ourselves but if you require one we can maybe get something. Otherwise, at least regarding the deadlines we'll have to deliver the web assistant to Hivos by the end of the year but we'll do several iterations before that and it would be great to have something on which we can do user testing let's say before July. Does that sound reasonable to you? Ah, and we took it for granted but your code will be public, GPL, and all from (almost) the beginning, right? Maybe we should create you a repo on git-tails.immerda.ch. -- 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.
