Feature #12003
Set a warning message in RCs and alpha releases
90%
Description
https://www.reddit.com/r/tails/comments/5f5kwl/tails_30alpha1_is_fucking_amazing/
tl;dr: some users seem to have migrated to Tails 3.0~alpha1 for what seems to me like real usage, not for testing purposes.
spriver suggested that “we should have a custom background image for alpha/testing releases which is saying blahablah this is dangerous”. We could generate such an image at build time if the conditions are right, e.g. we are building from a tag with -alpha
or -rc
in it.
Subtasks
Related issues
Related to Tails - Feature #15768: Use desktop background to warn users when their Tails needs to be updated | Confirmed | 2018-08-06 | |
Related to Tails - |
Resolved | 2018-02-15 | |
Related to Tails - Feature #14544: Spend software developer time on smallish UX improvements | In Progress | 2018-08-31 | |
Related to Tails - |
Confirmed | 2018-11-11 | |
Blocks Tails - Feature #16209: Core work: Foundations Team | Confirmed |
History
#1 Updated by nodens 2016-11-29 09:27:03
I think it should really be stating that this is unsafe, we can make that funny as well but the point needs to be made.
Suggestions on #tails-dev:
- big scary text: “YOU ARE NOT ANONYMOUS. YOU ARE ALONE. TESTING PURPOSE ONLY”
- maybe with uncle Sam pointing the finger to the user, with the fce of Don^Wfuture president of the USA
This was half meant as a joke but it drives the point home while still being funny (not sure about puting the face, that could be asking for trouble, but the uncle Sam is a good one)
Cheers!
#2 Updated by sajolida 2016-11-29 13:21:34
For Feature #10508 I used a red background: https://git-tails.immerda.ch/tails/plain/config/chroot_local-includes/usr/share/tails/desktop_wallpaper.png?h=feature/10508-ux-testing-iso.
Maybe we could add a warning icon. I would also change the Syslinux menu to make clear this is a testing version from the very start.
I would avoid culturally or politically connoted jokes as we want our user base is very diverse and not everybody will receive the message in the same way.
#3 Updated by intrigeri 2016-12-03 20:15:01
- Target version deleted (
Tails 2.10)
Anyone who wants to make it happen, please assign this to yourself.
#4 Updated by emmapeel 2016-12-22 11:23:49
- Subject changed from Set scary background image in alphas to Set a warning message in RCs and alpha releases from Tails 3.0 on
- Assignee set to intrigeri
- Target version set to Tails_3.0
We talked about this on our December Contributors meeting.
We realised that we were being too scary when giving ISO images for testing to the users, and that the ISOs could sometimes have bugs but they are passing all the security tests, at least on the Release Candidates (RC) or Tails 3.0~alpha1.
So maybe there are some bugs but not security issues.
We decided to change the background to grey and add a warning saying:
> “Hey, you are running Tails 3.0 alpha. It is safe to use but might still be broken in many ways. Report any problems to tails-testers@boum.org” and a grey background.
#5 Updated by sajolida 2016-12-23 18:38:51
The phrasing I gave during the meeting was just an example :) Maybe this is a bit better:
You are running Tails 3.0 alpha which is a testing version. It should be safe to use but might still be broken in many ways. Report any problems to tails-testers@boum.org."
#6 Updated by intrigeri 2016-12-23 20:57:28
Thank you!
#7 Updated by intrigeri 2017-02-06 19:21:58
If I got it right, we want the warning to be displayed as part of the desktop wallpaper. This sounds OK to me, but after attending the “Rebooting Firefox Nightly” talk at FOSDEM, I’ve had other ideas about how to adjust how a running Tails system could have communication specifically aimed at users or alpha/beta/RC:s. The idea is to get this specific public more involved in our QA process, and more generally in our community. Remember: the power-users of today may be the contributors of tomorrow :)
E.g. it would be nice to let them know what’s new, what might be broken, and what we particularly need feedback about. Firefox Nightly does that with:
- A dedicated blog.
- What they call “snippets”, that are small bits of text displayed below the search entry form, in the middle of the browser’s homepage. It’s kinda like the good ol’ “Did you know?” dialog from the 90’s, but less intrusive and non-blocking. I don’t think we have any good, existing way to do that in our Desktop (perhaps the Greeter would be a better place to display such info by the way), so let’s ignore it for now. I’m looking after low-hanging fruits here.
I propose that we piggy-back on our custom browser homepage. We could have that homepage display additional content when loaded from a non-stable releases. It could display:
- Some text on top, communicating whatever we want to non-stable release users. This could include the warning this ticket is about and additional information and requests, as suggested above. It serves the same purpose as the “snippets”. I would simply hard-code this additional text in the custom homepage source file, not bothering with inlines (and their bugs wrt. translation). If anyone wants to do it in a more fancy way, e.g. with JavaScript that displays/hides stuff depending on some URL parameter, be my guest (another URL parameter passing the version could be even better, so we display content depending on the running version; we would not pass this parameter in stable releases); non-blocking, can be done later. This content needs to be kept up-to-date; we don’t have to do anything when we don’t feel like it, apart of dropping obsolete chunks of text, so it’s work we can do if, and when, we feel like it.
- The same content as the normal homepage, because there’s no reason that users of non-stable releases don’t get that.
- If/when we ever want, additional blog posts specifically aimed at users of non-stable releases. I’m not counting on us writing such blog posts any time soon, but it’s good to have room for it :)
Thoughts, opinions?
I’m asking here and now because I’d rather do all that directly, than implementing the wallpaper-based solution now, only to dump it to the trash later if/when we do what I’m proposing here. I don’t think the solution I propose requires more work than the wallpaper-based one, it makes me more enthusiastic, and we can update the content displayed to users whenever we want, without waiting for the next ISO to be published, so I’m all for it.
#8 Updated by intrigeri 2017-02-10 17:30:32
- Assignee changed from intrigeri to sajolida
anonym, sajolida: what do you think about my last proposal on this ticket? (ETA: I would like to implement this during the next Stretch sprint.)
#9 Updated by intrigeri 2017-05-20 07:11:24
- Target version changed from Tails_3.0 to Tails_3.1
Too late for 3.0~ => postponing.
#10 Updated by sajolida 2017-08-06 10:23:25
- Assignee deleted (
sajolida) - Target version changed from Tails_3.1 to Tails_3.2
So you are proposing to have a custom homepage instead of a grey wallpaper and a notification, right?
I’m fine with both:
- The grey wallpaper and the notification will be noticed even without starting the browser and will always remain visible (at least in the activities overview, new desktops, etc.).
- The custom homepage allows for more dynamic content but is less visible.
Maybe they are complementary actually.
Note: for the wallpaper option, if the message is printed directly in the wallpaper we won’t have translations. Why wouldn’t a (translated) notification be enough?
#11 Updated by intrigeri 2017-09-01 12:59:39
- Status changed from Confirmed to In Progress
- Target version deleted (
Tails_3.2) - % Done changed from 0 to 10
- Type of work changed from Discuss to User interface design
#12 Updated by intrigeri 2017-09-01 13:02:11
- Assignee set to sajolida
We didn’t reach an agreement in time for me to implement this during the “porting to Stretch” cycle (which was the main reason why we wanted to do this quickly), and brand new ideas are still being proposed (by myself and sajolida), so I’m dropping the target version and calling it something that needs UX design instead and is not ready to be implemented.
> So you are proposing to have a custom homepage instead of a grey wallpaper and a notification, right?
Yes.
> Note: for the wallpaper option, if the message is printed directly in the wallpaper we won’t have translations.
I think this is incorrect: we would generate the wallpaper programmatically so it could easily be i18n’ed and l10n’ed.
> Why wouldn’t a (translated) notification be enough?
I don’t know (I’ve already documented the reasons why I prefer a web-based approach, so I won’t repeat myself :).
#13 Updated by sajolida 2018-08-11 09:47:26
- related to Feature #15768: Use desktop background to warn users when their Tails needs to be updated added
#14 Updated by sajolida 2018-08-14 09:19:45
- Target version set to Tails_3.10.1
#15 Updated by huertanix 2018-08-22 21:17:38
Related to this issue, I’ve proposed setting the desktop wallpaper color to a dark red, with a lighter internationally-recognizable warning symbol (⚠), for older versions of Tails. Check out: https://labs.riseup.net/code/issues/15768.
#16 Updated by sajolida 2018-09-18 02:21:58
- Assignee changed from sajolida to intrigeri
- QA Check set to Info Needed
- Feature Branch set to web/12003-custom-home-for-rc
Going back to this very old proposal.
Yeah, let’s have a custom /home for RCs and alpha releases! :)
What’s not super clear for me from Feature #12003#note-7 is:
- The mechanism to point people to this custom /home. Is the plan to encode, let’s say @/home/3.0~rc1 in the image for 3.0~rc1?
- The content (in terms of ikiwiki directives) of this page so we get both
- The custom content relevant for this test release
- The usual content from /home (as mentionned in
Feature #12003#note-7)
Would something like web/12003-custom-home-for-rc work?
My web/12003-custom-home-for-rc breaks the “Tor check” button so we should fix Bug #15312 at the same time as this ticket.
#17 Updated by sajolida 2018-09-18 02:22:15
- related to
Bug #15312: "Tor check" button is badly aligned and looks buggy added
#18 Updated by sajolida 2018-09-18 02:27:02
- blocks
Feature #15392: Core work 2018Q2 → 2018Q3: User experience added
#19 Updated by intrigeri 2018-09-18 07:44:09
- Assignee changed from intrigeri to sajolida
- QA Check changed from Info Needed to Dev Needed
> Going back to this very old proposal.
> Yeah, let’s have a custom /home for RCs and alpha releases! :)
Woohoo! :)
> What’s not super clear for me from Feature #12003#note-7 is:
> * The mechanism to point people to this custom /home. Is the plan to encode, let’s say @/home/3.0~rc1 in the image for 3.0~rc1?
Yes, I would encode at ISO build time a custom home page URL when we’re not building a final release. This way, users who we’ve asked to test a nightly build also get the warning.
But I would not bother maintaining multiple /home/$VERSION
pages. I would instead always use the same home page e.g. /home/alpha
. In the vast majority of cases we have only one call for testing alive at a given time. They should be listed (with pointers to instructions for testing) on top of that home page. Most of the time there would be nothing there; during the freeze for a major release we would point to the current RC’s call for testing; and sometimes we would point to a call for testing sent to tails-testers@.
> * The content (in terms of ikiwiki directives) of this page so we get both
> The custom content relevant for this test release
> The usual content from /home (as mentionned in Feature #12003#note-7)
I would hard-code on top of the page a general warning about the running Tails not being an official release + whatever we currently want to display to users of non-stable releases (see above for examples).
> Would something like web/12003-custom-home-for-rc work?
I’d rather avoid nested inlines until the corresponding bug in ikiwiki is fixed, so for now, just duplicate what we have in wiki/src/home.html
and insert the additional, non-stable-specific content on top.
#20 Updated by sajolida 2018-09-19 19:34:49
- blocked by deleted (
)Feature #15392: Core work 2018Q2 → 2018Q3: User experience
#21 Updated by sajolida 2018-09-19 19:38:37
- Assignee changed from sajolida to intrigeri
- Target version changed from Tails_3.10.1 to Tails_3.12
- QA Check changed from Dev Needed to Info Needed
Actually, it’s not clear to me that it fits in my core work responsabilities (and if so, maybe not more than FT, RM, or whoever writes the calls for testing).
I wrote a quick prototype to clarify what we were talking about but I’m not sure I should be the one to finish implementing this.
The next RC is for 3.12, so let’s at least reschedule this.
#22 Updated by intrigeri 2018-11-17 12:25:19
- related to Feature #14544: Spend software developer time on smallish UX improvements added
#23 Updated by intrigeri 2018-11-17 12:35:01
- QA Check deleted (
Info Needed) - Type of work changed from User interface design to Website
> QA Check changed from Dev Needed to Info Needed
(Not sure what info I’ve been asked but failed to provide, so dropping this.)
I’ll try to work on this, if time allows, during one of our Buster sprints: I’d like it to be ready when we’ll release a public Tails 4.0~betaN.
Remaining work to do includes:
- website: make the website ready for this, based on sajolida’s PoC + my feedback
- code: adjust the homepage at ISO build time or at boot
- contributors doc: integrate this into our release process (and possibly release notes guidelines: even if our tech writers are not responsible for all calls for testing, we — at least I — may use that doc when putting out a RC or call for testing)
- tech writing / UX design / whatever we want to call it as long as someone better at me reviews my draft: write the additional text needed for this custom home page
Dear sajolida, I won’t bother you (with the part I’ll need your help for) before the other bits are ready, in order to avoid you spending valuable time on this before being 100% sure it’ll be actually used :)
#24 Updated by sajolida 2018-11-21 15:30:18
- related to
Bug #16117: Change warning about virtual machine pop-up time of appearance added
#25 Updated by intrigeri 2018-12-02 21:58:33
- Subject changed from Set a warning message in RCs and alpha releases from Tails 3.0 on to Set a warning message in RCs and alpha releases
#26 Updated by intrigeri 2019-01-10 20:01:51
- Target version changed from Tails_3.12 to Tails_3.14
#27 Updated by intrigeri 2019-04-08 07:13:47
- Target version changed from Tails_3.14 to Tails_3.15
#28 Updated by intrigeri 2019-05-23 16:49:48
intrigeri wrote:
> # website: make the website ready for this, based on sajolida’s PoC + my feedback
Done but I still need to salvage translations after the refactoring done in commit:e2c799fe710bafa3f02141fd3219b579d857c336. Also, we’ll need to update ikiwiki.setup
on our production website accordingly.
> # code: adjust the homepage at ISO build time or at boot
TBD
> # contributors doc: integrate this into our release process (and possibly release notes guidelines: even if our tech writers are not responsible for all calls for testing, we — at least I — may use that doc when putting out a RC or call for testing)
Drafted something. Likely it won’t be clear enough for my fellow RMs but I’ll only learn about what exactly is unclear once they try it.
> # tech writing / UX design / whatever we want to call it as long as someone better at me reviews my draft: write the additional text needed for this custom home page
As written earlier here, I’ll ask help from sajolida here only once I’m done with the other bits.
#29 Updated by intrigeri 2019-05-24 08:54:19
- Assignee changed from intrigeri to sajolida
- QA Check set to Ready for QA
- Feature Branch changed from web/12003-custom-home-for-rc to web/12003-custom-home-for-rc, feature/12003-custom-home-for-rc+force-all-tests
>> # website: make the website ready for this, based on sajolida’s PoC + my feedback
> Done but I still need to salvage translations after the refactoring done in commit:e2c799fe710bafa3f02141fd3219b579d857c336.
Done.
> Also, we’ll need to update ikiwiki.setup
on our production website accordingly.
Done and deployed, to avoid this blocking the merge of web/12003-custom-home-for-rc into master.
>> # code: adjust the homepage at ISO build time or at boot
> TBD
Done on feature/12003-custom-home-for-rc+force-all-tests. I’ve built an ISO and I confirm that the home page is https://tails.boum.org/home/testing/ when I login in English, and https://tails.boum.org/home/testing/index.fr.html when I login in French.
Of course, the homepage will yield a 404 error until web/12003-custom-home-for-rc is merged into master. And then I’ll have to update the automated tests on feature/12003-custom-home-for-rc+force-all-tests (it’s too impractical to do this before web/12003-custom-home-for-rc is live).
>> # tech writing / UX design / whatever we want to call it as long as someone better at me reviews my draft: write the additional text needed for this custom home page
> As written earlier here, I’ll ask help from sajolida here only once I’m done with the other bits.
I’ve done everything I could do before web/12003-custom-home-for-rc is merged into master ⇒ @sajolida, please review, fine-tune phrasing as you wish (see commit messages for why I had to diverge from your various proposals, that did not work well once combined with each other), and merge into master. Ideally, I’d like this to be merged by June 16, so we can take benefit from it when we publish a first alpha during the next Buster sprint.
Then reassign to me and I’ll finish the code side of things :)
#30 Updated by intrigeri 2019-06-02 14:42:54
- Status changed from In Progress to Needs Validation
#31 Updated by sajolida 2019-06-02 19:57:19
- Status changed from Needs Validation to Resolved
- % Done changed from 10 to 100
Applied in changeset commit:tails|2c7355a24e8d2478e9006413465b8858d6bd9dce.
#32 Updated by sajolida 2019-06-02 19:57:42
- Status changed from Resolved to In Progress
- Assignee changed from sajolida to intrigeri
- % Done changed from 100 to 10
All good, I merged into master!
https://tails.boum.org/home/testing/
I’m sorry you had to deal with the weird “Tor check” button that I’ll probably kick out of there for Bug #15312.
I wouldn’t have done the extra work to make the donation message work on /home/testing as well but it’s good that you did it :)
Do you have to do anything else before closing this ticket?
#33 Updated by intrigeri 2019-06-07 09:31:44
@sajolida, see commit:3329d12c38e1b88405fd83b7e3f0f1c8a1967255 and fix it up if I guesses your intent wrong :)
#34 Updated by intrigeri 2019-06-07 09:35:05
- Feature Branch changed from web/12003-custom-home-for-rc, feature/12003-custom-home-for-rc+force-all-tests to feature/12003-custom-home-for-rc+force-all-tests
- Type of work changed from Website to Code
> Do you have to do anything else before closing this ticket?
Yes (documented in comments above).
#35 Updated by sajolida 2019-06-07 09:46:43
> @sajolida, see commit:3329d12c38e1b88405fd83b7e3f0f1c8a1967255 and fix it up if I guesses your intent wrong :)
Good catch!
#36 Updated by intrigeri 2019-06-07 11:10:18
- Status changed from In Progress to Needs Validation
- Assignee changed from intrigeri to anonym
Actually, there’s no test suite update to do, so anonym or
segfault, please review and merge into stable :)
#37 Updated by anonym 2019-06-11 13:13:44
- Status changed from Needs Validation to Fix committed
- % Done changed from 10 to 100
Applied in changeset commit:tails|1fb2f34bcfa060858effe0870ea7dcac74dbd60a.
#38 Updated by anonym 2019-06-11 13:20:54
- Status changed from Fix committed to In Progress
- Assignee changed from anonym to intrigeri
- % Done changed from 100 to 90
I’ve merged this, but I have one tiny code nitpick/question:
+ if [ "${TAILS_DISTRIBUTION}" = UNRELEASED ] \
+ || [ "${TAILS_CHANNEL}" = alpha ]; then
+ HOMEPAGE="${HOMEPAGE}testing/"
Why not || [ "${TAILS_CHANNEL}" != stable ]
instead? Seems more correct in general, and future-proof if we ever would find the need for a “beta” channel or similar. Am I missing some corner case?
@intrigeri, if you agree with this change, consider it already ACKed by me so you can just push yourself and close this ticket.
#39 Updated by intrigeri 2019-06-14 11:00:58
> Why not || [ "${TAILS_CHANNEL}" != stable ]
instead?
@anonym, because we never explicitly set TAILS_CHANNEL to stable during our build. We only ever set it to “alpha”. “stable” is the default.
#40 Updated by anonym 2019-06-14 12:46:10
intrigeri wrote:
> anonym, because we never explicitly set TAILS_CHANNEL to stable during our build. We only ever set it to “alpha”. “stable” is the default.
Ok. Then || [ "${TAILS_CHANNEL:-stable}" != stable ]
would work, but whatever. :)
#41 Updated by intrigeri 2019-06-18 07:05:46
- Status changed from In Progress to Fix committed
> Then || [ "${TAILS_CHANNEL:-stable}" != stable ]
would work, but whatever. :)
Right ⇒ done.
#42 Updated by intrigeri 2019-06-18 07:05:48
- blocks Feature #16209: Core work: Foundations Team added
#43 Updated by intrigeri 2019-06-18 07:06:24
- Assignee deleted (
intrigeri)
#44 Updated by intrigeri 2019-07-03 08:06:12
- Status changed from Fix committed to Resolved
- Target version changed from Tails_3.15 to Tails_3.14.1