Even ubuntu can't keep themselves from smacking you in the face with a full-page cookie acceptance pop-up that illegally fails to provide an opt-out. Sad.
"Please don't complain about website formatting, back-button breakage, and similar annoyances. They're too common to be interesting. Exception: when the author is present. Then friendly feedback might be helpful."
I respectfully disagree this time. This is neither "website formatting", nor "back-button breakage", i.e. generally not a presentation issue.
This is the Ubuntu website being deliberately annoying about their tracking choices in the hopes that you just click "Accept all" and be done with it.
And I really don't know why Ubuntu specifically needs tracking when you just want to read an article on their blog, and personally think it's worthy of discussion.
The issue is that it's "shouting into the void". Nobody who can do anything about it is here to read it and heed the feedback, so it's just rage in the HN thread, making it a less pleasant place for everyone here, but without any benefit.
The whole reason for having the exception to that rule, being that the author is active in the thread, is that you can address the feedback to them and they can possibly do something about it.
Outside of that, you're better off sending an email or tweet to the company, rather than venting here.
But the same applies to many, many other discussions on HN. They may seem like shouting into the void, and then they may either stay that way, or garner enough of a critical mass to reach someone relevant--at a minimum they create discourse in our society.
So why single this one out? I understand why the cited rule exists: Broken website formatting or back-button breakage is indeed not interesting to discuss, mainly also because it's a nuisance problem with one specific site, and therefore indeed rather futile to discuss without the maintainer of the site actually present.
But this issue here is not just a nuisance problem of a broken website, it's an intentional choice by Ubuntu to apply unnecessary tracking to readers of their blog articles, and top it up with some dark patterns to coax their reads into accepting that. It's both something with much more intent than a broken website, and a systemic issue in our industry.
The site’s guiding principle is “intellectual curiosity”. That’s why Dang “singles out” your comment (which he’s not really doing, he often pulls people up for off-topic rage commenting).
> But the same applies to many, many other discussions on HN
You’re conflating your style of comment with posted articles, where the author explores a topic, discusses it in depth and proposes a solution. And sure, sometimes those kinds of articles convey some anger or stir some in the reader. But they still have to gratify intellectual curiosity to be considered good HN content.
It wasn't my comment, it was someone else's comment. I just disagree with this decision in particular, for the stated reasons, which also elaborate on why I think this would have been a valuable topic of discussion. dang can choose to incorporate that (e.g. if indication is that others feel the same), or ignore it.
Did you try disabling Javascript? The page looks fine in text-only browser I use. Does need Javascript to convey the information. As users, we cannot control what web developers choose to do with websites, but we can control what software we use to make HTTP requests and read HTML.
It's worse than that. There is an opt-out, but you have to scroll down on the full page modal, even though there's no indication that you can scroll. It's not incompetence; it's malice.
I get a scroll bar on the modal on Firefox, Chrome, and Safari. Are you sure there isn't something wrong with your browser, or with a plugin you are using?
The modal was perfectly sized to not show the opt out in a mobile browser. Mobile browsers tend not to show scrollbars, instead relying on context clues to indicate there's more content. To me, it seems like the modal was specifically designed to not have any context clues indicating more content, such as by having what seems to be a uniform margin of whitespace visible in the default scroll position. And remember, most traffic is mobile.
It sounds like you're saying it's sized to not show the opt out without scrolling even on desktop, which makes it seem even more like the sizing is completely intentional.
Even if it's minor, this is an excellent article because it accompanies the change with clear instructions on how to fix suspected issues or to revert the change, in a manner that even a relative layperson on a Linux system could follow.
I totally thought they were turning on homed with encryption by default, and was _super_ excited. I've been toying with doing that myself and having someone go first would be great.
If this encryption is still the same as it used to be a couple of years ago (encfs, IIRC), it's good they aren't. I stumbled on that multiple times before I learned not to turn this shit on. Every time on a new installation (which doesn't happen that often, so it's natural I was forgetting) I chose "do encrypt" option (because why not?), it was working perfectly fine long enough for me to settle in, and then one day I would be downloading some books via torrents, and torrent wouldn't proceed because of "filepath too long" (which was very confusing, because how could that be on Ext4, given it's perfectly fine for other peers, who must be on NTFS, most likely), and I had to spend time disabling encfs (I guess it wasn't that easy either: creating a new user was the quickest option) in order for things to start working.
So, finally I learned just not to use file-based encryption, except for minor stuff like dropbox directory.
I misunderstood your post. Of course full disk encryption is vital for security. My point was that without secure boot you can't be sure that software asking for your password is legitimate. Typical setup consists of unencrypted boot partition with Linux kernel which asks for password. You can't be sure that this Linux kernel was not patched, but Secure Boot helps to ensure that.
i had the exact same thought. i was diving into this with popcorn in hand thinking this is what it was about. i can't remember the scope of this but i remember reading about it sometime ago--regardless, if this was indeed systemd, it would have been the nail in the coffin for me to go full freebsd.
It is in fact an simple change to UMASK in /etc/login.defs. The default value is different between various Linux distributions and in fact Unix systems as a whole depending on the "pedigree". On the multiuser systems the default tends to be 022 (ie. 755 permission bits => read and execute to everyone), on "internet server" systems 033 (ie. execute to everyone, such that finger and http://foo.bar/~quux/ works) and 077 on workstation unix systems (ie. $HOME is completely private). And I have strong feeling that the whole story about "systems shared by family" is just PR spin as that setting is simply default in upstream Debian...
Well to be more precise they're saying that "use-cases like multiple family members sharing a single PC" are quaint - by contrast with "the modern era of cloud computing and IoT". A charitable reading would perhaps count it a fair observation that an increase in computing ubiquity has led to most machines, even workstations, being single-user.
Ubuntu should develop shadow accounts - the user will log in to a completely different account of the same login depending on password. That is if someone forces you to log in you could use different password and pretend it is your stuff.
You dont need it now but in the future it could be crucial to have some enclave of freedom. Also when the drive is encrypted it is not possible to tell how much data it really contains.
Second account will have a different login so when referenced with other metadata it may tell that it is not in fact your main account. Not sure why people are opposed to measures that increase privacy?
I’ve heard good things about pop os. Have you tried and liked any of the others? It was a bit unnerving to have my Firefox windows change all of a sudden due to upgrade.
Pop OS is great. I've used it when I need a laptop to Just Work quickly, and I have a non-technical family member who has been using it for about 2 years now with zero issues.
Pop OS is great. Of course I had some issues with UEFI stuff (since they don't use GRUB) but their website had great tutorials for NVMe SSDs.
And you have flatpak instead of snap (so no snap folder in your case).
But most importantly, they have a killer tiling extension for Gnome. It is superb.
I left Ubuntu because of snap - and I don't see myself going back. It's funny, I feel like eventually every distribution has to do something to irritate long-term users, but endear themselves to others. It's part of a weird growth phase.
Currently I'm on Manjaro. I went through my post-Ubuntu cycle and looked into Gentoo, Mint, Solus, and FreeBSD again. Basically Manjaro made running Arch painless. I'm happy enough for now.
> This change now means that in the future if an attacker were to exploit some previously unknown vulnerability in a given system service that is running as a separate user, they would then not be able to access the data of any other user (both human or system service) on the system.
If the attacker can already access arbitrary files on your box, I don't think simple unix permissions will save you
All I am saying is that security is like onion layers, and unix permissions are the last layer probably. If the attacker penetrated through all the other layers, chances are that unix permissions will not save you.
Former pentester here. It was often the case that we were able to penetrate a box as a low-level user account, and the way we escalated was to search ~/.bash_history of an admin account.
chmod'ing the homedir would've prevented that. Unix happens to be pretty good about directory permissions.
Interesting idea - make it so all your passwords start with the same four characters (say Ab54) - (it's hard to get good passwords you can safely type at a prompt anyway) and then have a script that searches your history/log files for strings beginning with the Ab54 characters and replacing them with XXXX or similar.
All sorts of horrible side effects can immediately be identified.
BTW: The only issue I‘ve come across was that the pulseaudio user daemon couldn’t initialize during login (because it started before fscrypt unlocked home dir). There is an easy workaround for Ubuntu 20: https://github.com/google/fscrypt/issues/270
Hi! Author of fs-crypt dropping in from the interwebs.
I also created eCryptfs, which was Ubuntu's original home directory encryption technology, with lots of additional distro integration work by Dustin Kirkland. Unfortunately I had to make some compromises when going with the stackable model, and that caused some problems.
I took the lessons I learned from that first attempt and created fs-crypt as a sort of atonement. I think I got a lot more right on my second attempt at file-base encryption in Linux. At least, it's good enough to be the technology that now encrypts Android storage.
The problem with Linux supporting stuff forever is that some things really need to be retired once a better solution has come along. However so long as there are eCryptfs users out there, I don't think it's going to ever go away at this point.
Around 16.04 if you enabled encryption during installation, you got ecryptfs home directories - later (18.04?) they changed to encrypting the entire disk.
In some ways, encrypting the entire disk is more secure.
To me, user accounts have always seemed like the more reasonable approach to sandboxing vs. cloning the universe to run a single program in a container.
Most of my systems have a user for myself, and one or two other users like `sketchy` or `test` or something for programs that I trust enough to run, but don't trust enough to not fuck up my home directory in some way (including modifying startup scripts, which IMHO should probably require sudo to edit, even for a normal user).
If the program is really sketchy and you're worried about it doing something like exfiltrating ~/Documents/taxes, then private home directories would definitely seem like a good default. You can always have an explicitly shared area like /home/shared/$user that defaults to public.
Me too, I have on each system at least 6 users just for myself. I'm also an Ubuntu user at moment, and I change also the access rights for the home directory just for the user each time. I used SuSE before and they allways had just user access for the user.
I run such less trusted programs on other machines. The privilege elevation attack surface is just too big on a normal Linux system.
That's why I think intra-user isolation is better. I would feel so much better if my browser could just access its settings, the download directory, and read access outside my home directory (for libs and such).
Isn't SELinux supposed to provide exactly this functionality?
The tricky part are the profiles afaik. But this could be solved with some concentrated community effort I guess.
I think AppArmor does something similar (I don't know the differences to SELinux in detail, so if someone like to clarify please go ahead). I remember I've seen some AppArmor related stuff regarding Firefox (and LibreOffice I think) in Ubuntu. So seems not much is missing to have at least an sandboxed web browser out-of-the-box on a Linux desktop.
SELinux can and does do exactly this, depending on the configuration. What you'll most often see is that applications covered will have rules that allow it to access a subset of the user's home content (xdg cache, data, etc.) that allow that application to function, and SELinux will use UBAC rules to ensure that user A's instance of that application cannot access the data of user B's.
Profiles are indeed tricky though, and generally something I would consider more easily implemented as just logging in as a different user.
I can't speak much about AppArmor since I'm not too familiar with it.
SELinux can do this--think of it as a second layer of security that is checked after the normal DAC checks (e.g., process uid vs file permissions) succeed.
> I would feel so much better if my browser could just access its settings, the download directory, and read access outside my home directory (for libs and such).
I regularly have to both download files to other directories than my Download folder and upload files from other directories, such a restriction would break a lot of existing use cases.
The optimal way to achieve this would be to have the file / save picker a completely separate process, which then passes a token to the browser, which the browser then exchanges at some sort of "broker" process that returns a handle to the file.
Agree, users are a good start, also systemd for example provide ways to run a process on its own file system too, readonly, etc... I guess virtualization or containers is needed because of the unknowns bugs, bad use of technology and /or not being able to harness a system very well with non sandboxing methods.
Too bad Red Hat is going the opposite direction with their Toolbox container management project, sharing your entire home dir with every container but not explicitly documenting this:
99 comments
[ 3.1 ms ] story [ 182 ms ] threadhttps://news.ycombinator.com/newsguidelines.html
This is the Ubuntu website being deliberately annoying about their tracking choices in the hopes that you just click "Accept all" and be done with it.
And I really don't know why Ubuntu specifically needs tracking when you just want to read an article on their blog, and personally think it's worthy of discussion.
The whole reason for having the exception to that rule, being that the author is active in the thread, is that you can address the feedback to them and they can possibly do something about it.
Outside of that, you're better off sending an email or tweet to the company, rather than venting here.
So why single this one out? I understand why the cited rule exists: Broken website formatting or back-button breakage is indeed not interesting to discuss, mainly also because it's a nuisance problem with one specific site, and therefore indeed rather futile to discuss without the maintainer of the site actually present.
But this issue here is not just a nuisance problem of a broken website, it's an intentional choice by Ubuntu to apply unnecessary tracking to readers of their blog articles, and top it up with some dark patterns to coax their reads into accepting that. It's both something with much more intent than a broken website, and a systemic issue in our industry.
> But the same applies to many, many other discussions on HN
You’re conflating your style of comment with posted articles, where the author explores a topic, discusses it in depth and proposes a solution. And sure, sometimes those kinds of articles convey some anger or stir some in the reader. But they still have to gratify intellectual curiosity to be considered good HN content.
Why don’t you try writing an article like that?
It sounds like you're saying it's sized to not show the opt out without scrolling even on desktop, which makes it seem even more like the sizing is completely intentional.
So, finally I learned just not to use file-based encryption, except for minor stuff like dropbox directory.
EDIT: Looks like LUKS is supported now, which is nice:
https://wiki.archlinux.org/index.php/Systemd-homed#LUKS_home...
You need either full disk encryption, or something like dm-verity for that.
Then again checks foil hat, that’s what you want us to believe ;)
Because small increased of privacy should not result in huge usability decrease.
1. Create a file in your home called .hidden with one line "snap" to hide it in the file browser.
2. You can add --hide=snap to your ls alias to hide folders by that name.
If the attacker can already access arbitrary files on your box, I don't think simple unix permissions will save you
chmod'ing the homedir would've prevented that. Unix happens to be pretty good about directory permissions.
Welp. Yes, I misremembered that specific example.
Still, you’d be amazed how often people leave json credentials in their homedir that can be used to pivot to e.g. S3.
Another reason I don’t sudo and instead ssh
All sorts of horrible side effects can immediately be identified.
I also created eCryptfs, which was Ubuntu's original home directory encryption technology, with lots of additional distro integration work by Dustin Kirkland. Unfortunately I had to make some compromises when going with the stackable model, and that caused some problems.
I took the lessons I learned from that first attempt and created fs-crypt as a sort of atonement. I think I got a lot more right on my second attempt at file-base encryption in Linux. At least, it's good enough to be the technology that now encrypts Android storage.
The problem with Linux supporting stuff forever is that some things really need to be retired once a better solution has come along. However so long as there are eCryptfs users out there, I don't think it's going to ever go away at this point.
In some ways, encrypting the entire disk is more secure.
https://talldanestale.dk/2020/04/06/zfs-and-homedir-encrypti...
Hope general zfs support will improve in the installer, though. As well as automation and tooling around automatic snapshots.
Most of my systems have a user for myself, and one or two other users like `sketchy` or `test` or something for programs that I trust enough to run, but don't trust enough to not fuck up my home directory in some way (including modifying startup scripts, which IMHO should probably require sudo to edit, even for a normal user).
If the program is really sketchy and you're worried about it doing something like exfiltrating ~/Documents/taxes, then private home directories would definitely seem like a good default. You can always have an explicitly shared area like /home/shared/$user that defaults to public.
That's why I think intra-user isolation is better. I would feel so much better if my browser could just access its settings, the download directory, and read access outside my home directory (for libs and such).
The tricky part are the profiles afaik. But this could be solved with some concentrated community effort I guess.
I think AppArmor does something similar (I don't know the differences to SELinux in detail, so if someone like to clarify please go ahead). I remember I've seen some AppArmor related stuff regarding Firefox (and LibreOffice I think) in Ubuntu. So seems not much is missing to have at least an sandboxed web browser out-of-the-box on a Linux desktop.
Profiles are indeed tricky though, and generally something I would consider more easily implemented as just logging in as a different user.
I can't speak much about AppArmor since I'm not too familiar with it.
You could probably use Qubes OS instead.
It's been a while, though. But now I'm also spoiled with Sway. Haven't checked if I can keep Sway on qubes.
I regularly have to both download files to other directories than my Download folder and upload files from other directories, such a restriction would break a lot of existing use cases.
The optimal way to achieve this would be to have the file / save picker a completely separate process, which then passes a token to the browser, which the browser then exchanges at some sort of "broker" process that returns a handle to the file.
https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734
https://github.com/containers/toolbox/issues/183