Hacker News Reader

Comment by ho_schi | Hacker News Reader

Why I should...

   * Remove a background "online"?
   * Write a resume "online"?
   * Create an E-mail signature "online"?[1]
   * Create a profile picture "online"?
   * ...

Operating systems are happily executing programs on your computer, quick, autonomous and reliable. The first in the list which makes sense is Jitsi.

Here some personal recommendations:

    * Use GIMP or KRITA
    * Use LibreOffice or Latex with moderncv[2] (We're on hackernews, right?)
    * Use your E-Mail application and plaintext!
    * Again GIMP or use included tools of the application or network (Signal and other provide it)
    * For polls you can use often included features of messengers (e.g. reactions in Signal) or non-commercial sites [3]

[1] Please use plaintext

[2] https://github.com/moderncv/moderncv

[3] https://terminplaner4.dfn.de

View on HN

Because of the sandboxing browsers provide.

The barrier to install native software should be very, very high. It is like having unprotected sex with someone. There needs to be a high level of trust and a long term commitment.

Using a website on the other hand is like exchanging a few nice words. You can do that with a stranger, without much risk.

It is also easier to handle. A website can be bookmarked and usually loads in a second or so.

Websites are also easy to customize. Usually you can bookmark individual pages directly. Often with the parameters you regularly need. You can zoom in and out of the interface. You can customize the HTML and CSS and even the functionality via bookmarklets.

And you can link to websites and everybody - independent of their OS - can instantly use it.

>Using a website on the other hand is like exchanging a few nice words

This is absolutely not true if you're supposed to upload (possibly private) images to some random server for e.g. background removal.

Sure, the words you exchange are now known to the other party.

But a native app can upload anything it wants anywhere. Not just the images you processed but anything it can access on your computer.

Good points on both sides.

But I am absolutely still in the camp that trusts Gimp way more than uploading photos to a random website.

> Good points on both sides.

All the points are true, so we need to dig a little deeper and be more specific about what is at issue here.

Online and Native are quite different trust and utility models.

Web applications protect the execution environment owned and managed by the user. They do so at the cost of compromising some of the user's data, which must usually be processed remotely. The protection applies to most of the user's data. This trust tradeoff is iterated/ongoing, so that benefits and harms accrue over time.

Native applications make a one-off trust transaction. "Is it safe to install on my device?". In the win situation the benefit is speedy and safe processing of all the user's data for all future time. If the user is tricked, then the loss is catastrophic, exposing potentially all of the user's data, perhaps silently/undetectably for considerable future time.

That's a very simplified and perhaps naive distinction. Despite the pressures of surveillance capitalism, some web services are honest, TLS and GDPR work, and some users are sensible about what they share online. On the flip side we are seeing that devices come pwned from the factory, at the hardware or firmware level, which makes a nonsense of the whole "endpoint security" paradigm.

> If the user is tricked, then the loss is catastrophic, exposing potentially all of the user's data, perhaps silently/undetectably for considerable future time.

For offline users we also have malware detection and firewalls.

Stopping outgoing connections can be be really effective, bjt of course: if one has doubts one probably shouldn't install.

> Sure, the words you exchange are now known to the other party

... and their business partners, and their business partners, and so on. That's a lot of ToS to go through just to check who gets a copy of my data.

Gimp may have access to my computer, but I would be shocked if it were to upload a single file without my permission.

That's because GIMP has decades of reputation.

But if you search for GIMP online and land on TotallyFreeGimp.com and click Download Now, all bets are off.

> But a native app can upload anything it wants anywhere.

can you exhibit one single instance of this happening in for instance Debian or Arch official packages

> Using a website on the other hand is like exchanging a few nice words. You can do that with a stranger, without much risk.

Considering surveillance capitalism and all the trackers these commercial websites have, it's more like dating a spy that tries to know you better. The risk you take is that the small amount of data you give to them will be linked to the huge amount of data they already have on you.

yet in my life I need a lot more hands to count the number of times visiting some website caused problems, vs something bad happening due to installing $OPEN_SOURCE_SOFTWARE (exactly zero times to me)

> The barrier to install native software should be very, very high.

No, the barrier that the software must leap to do awful things to your computer should be very high.

Folks complain about the secure enclave, the signing requirements, the notarization, sandboxes, etc. But those are all barriers on the producer side. App stores help mitigate this. Folks don't think twice about downloading an iOS app from the app store (I do, but I'm not normal -- I hate apps). Look at the hoops Apple had to, and continues to, go through to keep applications from unknowingly looting the user.

The most criminal thing, historically, done by Windows over the ages was simply requiring EVERYTHING to be "admin". You couldn't install Minesweeper without typing in your password. So, everyone, naturally, automatically, does so without a second thought. They're conditioned that this is OK.

It's not OK. It was never OK. The whole idea of having to do that, type in your password to install software, should have a big red, DO NOT DO THIS, bouncing and dancing bear around it.

The Mac has always had less of this. Seems most of the exploits require users to download software and give it admin privileges. Yea, Don't Do That.

Of course, the problem is the culture. It would be nice to not have to Caveat Emptor every darn thing under the assumption that it's horribly dangerous. It would be nice to grab a plum off a display and eat it without having to vet the vendor. But, bad actors, rampant bad actors, and rampant "good actors" behaving badly, have proven that we just don't live in that kind of world.

Installing "safe" software, should be simple.

We have an ecosystem where running nontrusted software can be relatively safe... it's just on the web.

Legacy desktop OSes don't have the permissions models that make this easily achievable outside the browser. Even the mobile platforms are only slowly evolving (I want this app to access ONLY this folder or that picture, not all my user files).

Frankly I would never trust users to be able to differentiate between sane and unnecessary permissions. If you make everything super granular or repetitive it's just going to lead to banner blindness (yes, damn it Google, I want this hiking app to know precisely where I am... I told you the last seven times you asked). Or on iOS, having to enter my longass Apple password just to download a free app whenever the fingerprint scanner doesn't work (which is usually). Even without security concerns, native apps are a pain in the ass.

The web is nice in that most of the sandboxing is invisible unless you need special sensor permissions (location, mic, camera, etc.) and so the user never gets bugged about it. Or has to worry about platform idiosyncrasies, disk space, versions, etc. In many ways the web is a superior app delivery platform. Why bother installing "safe" software when you can just run it in a sandbox without any installation or prompts at all? What Java and .NET tried to do back in the day now just happens, sight unseen, in browser windows.

Unfortunately there are problems with running it on the web (and many problems with its design, and problems with implementations), as well as problems with native permission models of some systems, too.

For example, it is not very good working for: command-line with pipes, non-Unicode character encodings, non-USB devices, non-HTTP(S) protocols, working local files without internet connection, interaction with other local programs in a good way, etc.

Permissions need not be asking every time (if user will configure it to always allow or deny or other settings), and need not only be "allow"/"deny"; for example, if it requests the camera access then the user might enter a command to use instead, which might access the camera (possibly with filters such as fault simulation), or do something else such as returns a still picture (which you can use if you do not have a camera, for example), and this can be "wired" by the user configuration if not wanted to enter every time.

Disk space is going to matter for any program that stores files, although one which is designed well will allow the end user to specify a disk quota for this program if desired, and will also allow specifying default disk quotas in the manifest, in order that you can use it without needing to know about these things and manually set them up, too.

I had tried to make the specification of "VM3" which is meant to, among other things, solve these problems. A program can be install or just run, and all I/O must use extensions, which makes both extensible capabilities and highly user configurable capabilites. The same is true for program entries (e.g. command-line, GUI, etc). There are also some other minor things I had done differently due to I think being better than what some other designs are working.

I think that kind of computing will become more and more the realm of specialists (devs, computer scientists, whatever) doing their work, with specialized tools and permissions models. For 99.9% of regular people, there is no reason to expose them to so much unnecessary complexity.

Just like with supply pipelines, most people don't need to care or know about information pipelines... they just want to consume the thing they're there to get, whether it's refined petroleum or some unit of information.

All tools are built up from layers of primitives, like a car is made up of components and nuts and bolts and such, but drivers don't need to know or care how its ECU or ICE works. I think the web / mass-market computing is similar... it just doesn't (and I'd argue shouldn't) matter to most people. It's the difference between engineering for other engineers and designing for end-users, two related but ultimately separate concerns.

That's right. Let us add here Linux. It did always separated users and process and software is maintained by distributions, which you trust. Nowadays more important, it supports control-groups which separate the actual applications. Therefore Flatpak and Docker.

The idea of notarization and entitlements on MacOS is good. Maybe it is a lack of knowledge and experience on my side but the documentation needs improvement. I miss a good HowTo presenting manual usage of tools for notarization and entitlements. Apples seems to expect usage of XCode which is often not the case. Especially MacOS isn't able to report missing entitlements which required a lot time. Generally Apples stuff often doesn't provide status messages and valuable logs. I expected MacOS to show the message "App Bundle Foo is missing entitlement Bar". Also the Apple support didn't noticed that.

> having unprotected sex

Ah yes, the Jargon File said things about that: http://catb.org/jargon/html/S/SEX.html

> SEX: /seks/ 1. Software EXchange. A technique invented by the blue-green algae hundreds of millions of years ago to speed up their evolution, which had been terribly slow up until then. Today, SEX parties are popular among hackers and others (of course, these are no longer limited to exchanges of genetic software). In general, SEX parties are a Good Thing, but unprotected SEX can propagate a virus.

Why install software, if I can do this quickly in a browser, especially if I need to do this only once?

Not to mention the fact that the browser is very well sandboxed and security hardened.

> browser is very well sandboxed and security hardened.

But the back-end of a browser-only tool may not be. And it may not be online the next time you go to use it. Or it may lose or sell your data.

Sure, there's a confidentiality issue with whatever data you upload, but there's low risk of the rest of the data on your system being compromised.

Very … well … sandboxed … browsers?

Ummm, there’s Spectre in JavaScript.

And everywhere else? Although it does present a risk to sandboxed environments, Spectre is not a sandboxing issue, it's a CPU bug.

Semantic, shemantic; Risk remains the same.

The risk is very much not the same. Running native code is much higher risk, compared to running JS inside a browser.

The list of bad things a web app can do is a strict subset of the list of bad things a native app can do (after all, the web browser is just another a native app).

While it is true, there are problems with customization and other features; a better sandboxed environment will be needed which e.g. can use command-line, better ability to control and make connections/interactions with other programs in the computer, locally storing file (even using without internet connections), etc. The web browser / HTML is, I think, not a very well designed sandboxed environment, really.

Notably if JavaScript can access a file system then all bets are off.

I think you're confused, browsers don't require server custody of your data. browser vs app isn't the meaningful distinction

Even just in the first example of removing a background, it is very intuitive how to do it using the website listed. But GIMP, for all it's improvements in recent years, does not make it nearly as intuitive, fast, and easy for a brand-new user to remove a background. And being presented with that UI would be intimidating for a lot of users compared to using a single-purpose website with a specific workflow.

Because websites change the rules when they get popular.

A lot of people would rather use a single use web site than install a program and learn how to use it. There may be valid reasons to download and install a program but I can't even convince anyone to install a password manager so if my friends ask me how to remove a background on a pick I'm more likely to point them to a website than a program.

In short, because dedicated developers making one-off projects that do one thing well (a la the Unix philosophy) can serve it over the internet easier than making standalone cross-platform apps.

RemoveBG, for example, does a FAR better job (in less than a second) than manual lassoing, feathering, etc. Eventually Photoshop added a similar feature, but not until RemoveBG and its ilk were on the web for a few years. I'm not sure if GIMP has similar auto-bg removal, or if it works as well... but even if it did, it's still more of a learning curve than "upload picture and push remove". Even after two decades of Photoshop usage, it's still faster for me to use RemoveBG to create, say, a new Slack emoji... often I can finish before Photoshop even finishes loading.

For resumes, I use Kickresume all the time because they make the process FAR easier than creating a similar thing from scratch in Illustrator, InDesign, or Word. Unlike a dumb template, the resume websites understand the "semantics" of a resume (as in, this section is your employment history, this is your skills, this is your references) and can theme them intelligently, such as displaying skills as numbers, stars, progress bars, or words ("Advanced", "Beginner"), or easily reformatting the dates for you. Then it saves all your resumes, one per employer, in its own easy to use cloud storage. When submitting a bunch of applications (because I'm not fancy enough to have a huge personal network), it takes the time-per-resume from hours down to minutes. It's a huge timesaver.

Email signature: Agreed, HTML sigs are overkill.

Profile picture: Again, like RemoveBG, it's so much easier to use this than having to learn a vector graphics program, manipulating/centering circles, adding strokes and fills, figuring how to properly place text inside a shape (THIS circle, not that one, and flowing this way, not that!), etc.

There's nothing wrong with desktop apps for complex use cases (Office is still way better on the desktop than on the web, for example) but for one-offs, having an easy web app to go to and get the job done in a few seconds is waaaaaaay easier.

Not all of us on HN are ideological purists. No way I'm going to bother with LibreOffice and the JVM and Latex just to make a resume when a website can have it done in 5-10 min in a WYSIWYG and zero learning curve.

What if you want a "one thing" simple program to be used by command-line (with pipes), though? What if you want to work without internet connections, too? Interaction with other programs (specified by user)? Use local display options for GUI? etc? HTML is not very good for that, I think. (While you can make local HTML files that work without internet connection, it isn't very well for some kinds of uses. And, this does not solve any of the other issues that I had mentioned, too.)

> command-line (with pipes)

Most people just wouldn't. You're still free to use imagick or gd if you, yourself, want to, but RemoveBG is a far better choice for most users.

> What if you want to work without internet connections, too?

Then you have to find special tools for that, because it's a less and less common scenario. But the online-only tool is still useful if you're online 99% of your work life anyway.

> local display, GUI, other uses cases, etc.

Yes, absolutely you're right, there will always be cases where tool X doesn't fit edge case Y for user Z. But the web is the "good enough" option for an overwhelming majority of situations, and I'd argue the preferred option over a desktop app for many use cases -- everything from background removal to Google Docs.

Web apps can (and have) replaced email, office tools, encyclopedias, disc drives, etc. because they are so low-barrier, even if they don't have 100% feature parity with the older tools. Simplicity is very attractive, and quite valuable, for people who don't need all the power user features.

You're already making the assumption that people use desktop or laptop systems and can actually install software; what if they don't have administrator access? What if they're using a chromebook? What if they're on mobile? What if they don't know Latex? And LibreOffice is kinda... ugly and slow in my opinion.

They're low-barrier alternatives to the options you provide, and that's absolutely fine.

Heck, a pencil worked great back when I was a kid!

As someone who has to deal with IT security, I will never install anything local if I can avoid it.

Therefore upload the resume online on a random site? Which is the most sensible data and a security breach. There tough requirements on companies regarding handling your resumes for reasons.

I understand the concern, but looking at LinkedIn suggests this is not a threat model the vast majority of users are bothered by.

Your ignoring that most people have linked in accounts. A resume isn't exactly secret information.

RemoveBG is very good at what it does, and it certainly would be nice if there was an offline version. However, there isn't, and I don't think you'll find an offline tool that comes close in terms of quality of result.

There are cases were privacy of data isn't a real concern - e.g. you're about to publish the resulting file anyway. If you need to keep your data private, then sure, don't pipe it through an online tool. But that doesn't mean the usescases aren't there.

>However, there isn't, and I don't think you'll find an offline tool that comes close in terms of quality of result.

There is: https://github.com/danielgatis/rembg

This is great, but again does not come close in terms of quality of result.

Take the lion example from the readme: https://raw.githubusercontent.com/danielgatis/rembg/master/e...

The alpha blending of the fur around the edges is way off.

Compare to RemoveBG results: https://i.imgur.com/Jt2ICsD.png

Unfortunately it won't let me export in full-res without creating an acount, but the fur is handled properly.

Resume is understandable, if there are themes to choose from (kinda like Overleaf).

Why? Because 99% of the world's population prefers it.

Reply on news.ycombinator.com