Hacker News new | ask | show | jobs
by elmerfud 489 days ago
This seems like a very close-minded response from someone who has hubris that doesn't really understand leaks and attacks. None of this prevents accidental leaks or social engineering attacks All it does is interfere with people who want to have more choice in what they do because it is impossible for you to know everyone's situation or use case. You are only preventing screen sharing That's it nothing else and you cannot make a claim that it's doing anything beyond that. So like every copy protection scheme and DRM scheme that has ever been devised it only inconveniences legitimate users doing legitimate things and doesn't slow down or prevent any bad actor from doing bad things.

When you begin to view your users as the enemy by instituting manipulation and control over their use you set yourself up for a hostile relationship with your user base. When your company is big enough and you've locked in your market that does work for a while.

1 comments

Thanks for sharing your perspective—I really appreciate it. In hindsight, I should have given more weight to the "Any better approaches?" part of the original post. I fully acknowledge that my proposal involves trade-offs and isn't a one-size-fits-all solution.

That said, I’d like to explore how we might achieve security by design without sacrificing user experience. First, let’s agree on one core principle: if a user decides to share their screen, the OS should treat that choice uniformly across all apps—meaning it must always share the entire screen.

Given that, let's think about other ideas to address the risk scenario: a user might unwittingly share their screen with an adversary and then start a top-secret chat, accidentally leaking sensitive information. Ideally, users handling top-secret data would be exceptionally cautious, but in practice, mistakes happen.

Here's an alternative approach: a "Secret Chat Room" feature, that would rely upon OS checks, explicitly authorized by the user. Think of it as akin to physical secret meeting rooms with soundproof walls and Faraday cages—places where sensitive conversations are truly isolated. When a user enters such a room, they'd see a prompt like:

    You are now entering a Secret Chat Room.
    This room is designed to ensure that no eavesdropping (such as keystroke logging, microphone tapping, or unauthorized screen sharing) is occurring.
    To proceed, please authorize the OS to perform an integrity check. You’ll be allowed in only if this check is successful.
To preserve privacy and avoid penalizing users with poor security practices, the OS would return only one bit of information:

    1: The user authorized the check AND it succeeded.
    0: Either the user did not authorize the check OR the check failed.
This binary signal prevents the app from knowing whether a failure was due to a deliberate user choice or a technical issue, thus providing plausible deniability.

What do you think about this approach? I'd love to hear your thoughts on refining it further to balance robust security with a seamless user experience.