search

nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
Other
2.07k stars 624 forks source link

NVDA Remote Control #4390

Open nvaccessAuto opened 10 years ago

nvaccessAuto commented 10 years ago

Reported by blindbhavya on 2014-08-14 17:06 Just like there is a feature in JAWS named JAWS Tandum, there could be a feature in NVDA named NVDA Tandum. I presume that you have sufficient knowledge about JAWS Tandum to decide whether you can/should implement such a feature in NVDA. However, for reference if you need some more information I will copy paste the JAWS Tandum Guide here.

nvaccessAuto commented 10 years ago

Comment 1 by briang1 on 2014-08-15 11:38 I would also imagine that the Freedom Scientific name and guide to this is their copyright, and thus we could hardly call it that or reproduce their guide without permission. However, The real challenge for screenreaders would be to have a way of using a computer remotely, where the remote computer did not have to have a screenreader installed on it. I have heard many people say that with nvda on both machines, and using team viewer with audio redirected over the link, it is possible to control a remote machine as it stands. However some lag is experienced and also some operations need input from the remote user. I don't know what the nvda team's thoughts on this are, but I'm almost certain a ticket similar to this about remote access was raised, but I can't find it!

nvaccessAuto commented 9 years ago

Comment 2 by Palacee_hun on 2015-04-28 10:35 A free plugin is under development that will provide remote functionality for NVDA through various popular remote protocols. Currently the plugin is in initial beta testing for a closed group consisting of people who have donated more than $100 in the fundraising campaign. The homepage of the plugin is [http://nvdaremote.com] where you can track its progress and you can already find some demo podcasts. I fancy this plugin will provide tandem facilities discussed in this ticket once launched.

Changes: Changed title from "NVDA Tandum" to "NVDA Tandem"

nvaccessAuto commented 8 years ago

Comment 3 by Palacee_hun on 2015-09-15 21:43 The plugin described in comment:2 is already downloadable, and is free and open source. I think it provides the requested tandem functionality quite well.

ehollig commented 7 years ago

@bhavyashah, is the addon that can be accessed from http://nvdaremote.com what you were looking for in this particular ticket?

LeonarddeR commented 7 years ago

@JCSTeh: is there still a desire to include NVDA Remote or parts of it in NVDA Core? If not, we can safely close this.

bhavyashah commented 7 years ago

Yes @ehollig, and this ticket can be safely closed unless @jcsteh is in favour of incorporating NVDA remote into core.

On 7/26/17, Leonard de Ruijter notifications@github.com wrote:

@JCSTeh: is there still a desire to include NVDA Remote or parts of it in NVDA Core? If not, we can safely close this.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/4390#issuecomment-318112391

-- Best Regards Bhavya Shah

Blogger at Hiking Across Horizons: https://bhavyashah125.wordpress.com/

Contacting Me E-mail Address: bhavya.shah125@gmail.com Follow me on Twitter @BhavyaShah125 or www.twitter.com/BhavyaShah125 Mobile Number: +91 7506221750

derekriemer commented 7 years ago

There's already https://github.com/nvaccess/nvda/issues/3564

jcsteh commented 7 years ago

3564 is more about RDP and Citrix. While related, it's not quite the same thing.

Ideally, I think it'd be nice to have NVDA Remote functionality in core. However, the fact that the NVDA Remote add-on exists and works extremely well makes this very low priority.

LeonarddeR commented 6 years ago

Given the recent quirks that occur with NVDA Remote and the WX Python 4 transition, I think that it might be good to reconsider the priority to integrate a remote solution in to NVDA's core. CC @bramd @josephsl

Adriani90 commented 5 years ago

@michaelDCurran, @feerrenrut I understand that during 2019 there will be a Project regarding this Feature. Do you think the priority is now higher for this?

LeonarddeR commented 5 years ago

In #9263: people expressed their concerns with having NVDA Remote in core.

@drsooom wrote:

For security reasons I wouldn't prefer this. A NVDA add-on can be even faster updated instead of NVDA itself. And a quick reaction on new (security related) bugs is highly necessary for this type of add-ons.

The problem with the current NVDA Remote add-on is that it is pretty low on maintenance. Furthermore, it contains lots of code that monkeypatches NVDA's core. While monkeypatching can be avoided by creating the proper extension points, this would require tight cooperation between NVDA core developers and add-on developers. An integration into NVDA's core ensures that the NVDA remote service is always compatible with the version of NVDA used by the user.

I'm tempted to disagree with your opinion about the advantage of an add-on with regard to security. I actually consider the fact that NVDA Remote is an add-on to be a disadvantage in this case. IN the case that the remote system is integrated in NVDA and it needs a security update, it can easily be distributed to people as part of an NVDA update. IN the current situation where there is no add-on updater in the core of NVDA, people need to be aware of the security issues and update their add-on manually. In the latter case, it is very likely that people will miss these security updates. The same happened when NVDA updated to WX Python 4 and people started filing issues about NVDA remote's incompatibility with NVDA 2018.3 while there was already a compatible version of NVDA Remote. Furthermore, I do not recall any security related bugs that required updating NVDA remote as soon as possible.

DrSooom commented 5 years ago

Furthermore, I do not recall any security related bugs that required updating NVDA remote as soon as possible.

That's because security experts and mass media don't care on screenreaders security at all because only "a few thousands" users are effected. I also never heard something about the SightCity, which should be "the world‘s biggest exhibition for Aids for the Blind and the Visually Impaired" (quote from their website), in the mass media and even not at IT news sites on the web. By the way, an audit for the complete NVDA source code would be appreciated – but I guess that this will cost too much.

Back to the NVDA Remote Access add-on: Isn't it part of the add-on updater yet? If this is the case, then there should be no issue later on after the add-on updater has included into NVDA.

but if I understood you correctly, this add-on is using quite a lot of functions from the NVDA core, so it has to be updated regularity, right? But this is now also the case after NVDA 2019.1 has released. So your argument regarding this point isn't one, because you can say the same for nearly all existing add-ons. And in the future all add-ons must be updated twice a year because of the new add-on update check mechanism – as far as I understood it correctly.

Just a few more questions: Why isn't the add-on "Golden Cursor" implemented in NVDA yet? Why you prefer to implement the add-on "NVDA remote Access" instead of "Golden Cursor" or other add-ons? How many users are using and really need the "NVDA Remote Access" add-on?

The whole thing wouldn't be such a huge problem if it's completely disabled by default and if it needs admin privileges to enable it. Otherwise the risks when implementing it would be too high.

Adriani90 commented 5 years ago

Would be an option that NV Access overtakes the addon remote access and maintains it for the future? Then, security issues are not a problem because both NVDA and remote access still remain splited. However, it is very important in the future to have this remote functions maintained on a regular basis. People are relying on it at work places and this is crucial for them to continue their jobs. So please give this a bit more attention. We do not get responses from the initial developers of the remote addon and my perception is that they react far too slow to the NVDA core changes like Python 3 and so on. cc: @feerrenrut, @josephsl, @JulienCochuyt, @codeofdusk, @derekriemer, etc.

DrSooom commented 5 years ago

@Adriani90: Please read this wiki article and then you might understand how much work the whole migration process from Python 2 to Python 3 is. Therefore I wouldn't suggest companies to update to the very first "stable" version of NVDA, which will be 2019.3, because I guess that plenty of new bugs will be found after releasing the very first stable version.

Nikita34196 commented 5 years ago

Hello. I contacted the developers of nvdaremote with a question about the support of python3, but the answer was never received. It is best to consider integrating nvdaremote into the nvda core.

Adriani90 commented 5 years ago

We have lots of users which wrote to them but no answer. It is not a matter of huge work here, because as we know there are also many automatic porting tools out there and then you can just focus on correcting things. And they could write to the addons mail list if help is needed. There are enough people who would be able to help. We had the same problem when we contacted them regarding compatibility flags in manifest and so on. The communication seems laggy and it takes too much time to get some updates from them. But now with the Python 3 migration it is really important to have this addon working as soon as possible.

Adriani90 commented 5 years ago

Hopefully someone from @NVDARemote is able to read this treat and to give us some updates on future maintenance and so on. This would be really helpful. Thanks.

zstanecic commented 5 years ago

Cc @tspivey

JulienCochuyt commented 5 years ago

Here at Accessolutions, we also would strongly advocate in favor of the remote access functionality being integrated into NVDA core. cc @frederic-brugnot

feerrenrut commented 5 years ago

To clarify the stance from NV Access: We are aware that NVDA remote is not currently compatible with alpha builds, we also understand that many people rely on NVDA Remote, and will not be able to use NVDA 2019.3 until NVDA Remote is made compatible. Our preference would be to have a functional version of NVDA Remote available before the release of NVDA 2019.3, however, our focus must be on stability of the core first.

Exactly how we will address this is dependent on many factors that we are currently considering. NVDA Remote will soon become an area of focus for us.

Thanks for your patience 😄

LeonarddeR commented 5 years ago

Given NVDA Remote will have the attention of NV Access later this season, I think we could use this issue to describe/propose what an ideal remote solution would look like. NVDA Remote has been there for years, and though it is very functional, there have been some security concerns. Relevant issues about this are https://github.com/NVDARemote/NVDARemote/issues/129, https://github.com/NVDARemote/NVDARemote/issues/96. There is a pull request that implements end to end encryption, but honestly, I"m not convinced that this implementation is the right way to go.

Rebuilding NVDA Remote from the ground up has the following benefits:

JulienCochuyt commented 5 years ago

Re screen sharing: Would the vision framework help in that matter? I agree there are workarounds, but nothing as effective as if the feature was included.

Could we also consider supporting an official server version? I do not know much which ones are used out there. We are using jmdaweb/NVDARemoteServer on Docker which is fine, but overall not that stable in the long run.

LeonarddeR commented 5 years ago

No, the vision framework has nothing to do with screen sharing, only with screen manipulation. It doesn't do screen capturing.

May be the ability to transfer screen shots (i.e. enhanced clipboard transfer) could help here. It isn't that difficult to capture the screen within NVDA, in fact, that is what the OCR feature does as well.

My main concern is the impact of a video feed on the overall performance of the system. I consider JAWS Tandem to be very slow in comparison with NVDA Remote, which might have to do with either screen sharing, the connection being routed over an American server or VNC overhead. I don't know.

JulienCochuyt commented 5 years ago

Performance is of course a major concern. I guess we could manage some frame rate limitations to ensure proper reactivity. Having the ability to visually pinpoint an inaccessible control on a remote GUI is a huge plus, but we for sure do not need HD video streaming.

DrSooom commented 5 years ago

@JulienCochuyt: You can't compare the resolution of a video with the resolution of a desktop. If you shrink the full screen from 2560x1440 to 1280x720 you won't be able to read any text because it's totally blurry. It's the same if you change the zoom scale of the window to 80 % in UltraVNC Client – if I memorize correctly. (It's really a long time ago I played a little bit with UltraVNC.) And Microsoft's Remote Desktop Service/Connection/Protocol (RDP) works also different to UltraVNC – and it has plenty really serious security vulnerabilities. See: BlueKeep, CVE-2019-0708 and CVE-2019-1181.

Therefore I suggest another remote tool for screen sharing before adding that specific complex feature to NVDA Remote. And of course: NVDA Remote should only be offered as an add-on – and never get part of NVDA itself. My comment is still valid.

JulienCochuyt commented 5 years ago

You can't compare the resolution of a video with the resolution of a desktop.

All apologies for the obviously-abusive-wording-wannabee. My point was that we do not need performance costly high frame rates. A (not shrunk) image once every core pump would already be a huge plus.

it has plenty really serious security vulnerabilities.

Weakness of other products ought to be considered a lesson, not a threat. The current NVDA remote implementation is also quite vulnerable, but revamping it is a great opportunity to nail this and at last offer a feature we can arguably deploy in rigorous corporate environments.

Therefore I suggest another remote tool for screen sharing before adding that specific complex feature to NVDA Remote.

There might be (or not) complexity in the implementation, but there ought to be no complexity at all for the controlled end user.

And of course: NVDA Remote should only be offered as an add-on – and never get part of NVDA itself.

I strongly disagree with you on that matter. I guess we can at least agree on disabling the feature in secure mode, though. The more beginner a user is, the more straight forward instructions it needs. Having to guide by phone a user towards downloading an add-on and then configuring the remote access is pretty tedious at times. Here at Accessolutions, we even went a step further in simplifying the process for the NVDA installations we manage ourselves: A single (convoluted) keyboard shortcut sends us (after a due confirmation prompt) a remote access link to directly connect and assist.

DrSooom commented 5 years ago

I guess we can at least agree on disabling the feature in secure mode, though.

No, not really because the Secure Mode of NVDA also disable plenty other stuff, which is required in normal usage. Therefore the only way I see right now is to bundle NVDA with the NVDA Remote add-on, but it's disabled by default. Sadly issue #10133 must be fixed before thinking about this step. And issue #8274 should be fixed too.

JulienCochuyt commented 5 years ago

bundle NVDA with the NVDA Remote add-on

This means either distributing portable copies or self signed installers. It does not help at all in providing remote support to the random user who installed an official release.

Sadly issue #10133 must be fixed before thinking about this step.

10133 still lacks a proper confirmation. See https://github.com/nvaccess/nvda/issues/10131#issuecomment-526662049

If it ever gets confirmed, this would actually be an argument for having a properly controllable core feature rather than an add-on you potentially cannot fully disable.

And issue #8274 should be fixed too.

Are you sure of the issue number? "Copying settings to secure screens gives a warning about addons even when they are all disabled." This does not seem related to revamping NVDA Remote add-on nor integrating it into NVDA core.

Maybe should we first concentrate on designing a properly secured remote connexion and agreeing on a defined feature scope.

At a glance, I would vote for, in order of preference:

JulienCochuyt commented 5 years ago

NVDARemote/NVDARemote#129

This issue is another good argument to a take-over by NV Access or a similar organisation that can afford a code certificate and engage its reputation on signing the code.

NVDARemote/NVDARemote#96. There is a pull request that implements end to end encryption

Generating a proper fresh client certificate AND keeping track of servers certificates for identity check is of major importance. E2E would allow remote parties to ensure a compromised server cannot take control or access any sent information, but only if parties identities are kept track of and checked as well. For this, I guess we should move from a single password - which is technically an unsecured private chat room id - to an ID / password pair a la TeamViewer.

but honestly, I"m not convinced that this implementation is the right way to go.

Is the implementation itself problematic or do you mean you would be in favor of a brand new protocol stack based on Google Protocol Buffers?

Please note I'm stating here "servers certificates" with a meaningful plural form: Depending on your location, accessing nvdaremote.com can be too slow for a proper use. Furthermore, we already deploy custom servers in corporate environment for internal use. Users of laptops must then change their server of choice when moving in and out.

Regarding an officially supported server distribution: I guess it should also implement https://portcheck.nvdaremote.com/port/.

DrSooom commented 5 years ago

Issue #8274 is only valid if NVDA Remote would be distributed as an add-on. If it's part of the NVDA Core, it would be of course totally irrelevant.

btw: What do you think about Skype Screen Sharing as a workaround? I know that some companies don't allow Skype, but private end users, which most of them already have a Microsoft account, could use it at no additional charge.

Furthermore, if you want to have the screen sharing feature in NVDA Remote itself, you should also think about only transferring updated sections of the screen. So only the currently active window would be primary captured and shared and the rest of the desktop screen would be fixed until something happens there. This would reduce the necessary bandwidth. Using H.265 instead of H.264 could also help – or maybe not if older hardware is used. Just some thoughts.

JulienCochuyt commented 5 years ago

btw: What do you think about Skype Screen Sharing as a workaround?

All approaches based on a second software that I can think of come with almost the same burden:

Plus, on corporate environments, firewalls often block ports other than 80 and 443 but sometimes do not block traffic in these when they can't identify the protocol. For these situations, we use a NVDA Remote server deployed on port 80. We can't apply the same technique with common screen sharing software.

you should also think about only transferring updated sections of the screen.

I fear this could lead to difficulties in using pointing devices and/or nasty side effects, but this is nevertheless an interesting proposal.

This leads to two additional features in the scope:

Talking about bandwidth: With an officially supported server distribution, we could try to enroll a few additional patronage nodes. If we move to E2E, these nodes could be interconnected with no security concerns, and the fastest path between the connected parties would be much more easy to find. Then, users would still have to deal with ID/pass pairs, but have the obvious benefit of a much more responsive solution.

XLTechie commented 5 years ago

On Sat, 31 Aug 2019, Julien Cochuyt wrote:

  • While NVDA is already there, you most often have to deal with downloading the second software, which can be blocked by corporate policies.

While I agree about Skype, and with your entire point here, isn't this also a good argument for not including remote in core at all? Might some corporate policies disallow NVDA entirely, because of its remote access capabilities? Even if able to be completely disabled by commandline or other policy mechanism, it could interfere with update distribution.

This leads to two additional features in the scope:

  • Extend clipboard sharing to copying files, not only text.

If you're going to do that, you will definitely need end to end encryption. Any SSL tunnel should be sufficient. In fact, even without this, any solution that does not implement encryption of transferred data, files, screens, speech strings, or whatever else, is likely to suffer much in public acceptance.

  • If we get screen sharing: Quick and easy way to toggle the feature from the controlling side, in order to spare bandwidth.

Agreed. I personally still like the screen shotting idea more than trying to incorporate screen sharing.

Talking about bandwidth: With an officially supported server distribution, we could try to enroll a few additional patronage nodes. If we move to E2E, these nodes could be interconnected with no security concerns, and the fastest path between the connected parties would be much more easy to find.

Why do we even need a server beyond the setup phase, in most cases? It should be possible to:

  1. Reach out to the server via a port.

  2. Have the remote machine do the same.

  3. Have the server negotiate authentication secrets for each of them.

  4. Have one of the machines reach out to the other via a pre-heated port, which should get around most firewall problems. I know we used to do this with OpenVPN and UDP all the time, and if I remember right the same procedure can be made to work with TCP as well. I think that's practical. Especially if we incorporate an off the shelf encryption layer like OpenVPN.

  5. If the first machine can't establish the connection, let the second try.

  6. If still no connection is established, let the server continue as intermediary.

Then, users would still have to deal with ID/pass pairs, but have the obvious benefit of a much more responsive solution.

Why ID and pass, and why pairs?

Solutions like the Apple support screen sharing system and others, require only that the user to be controlled enter a single password on the device to allow connection. Since we won't have a previously available authentication like they do, we could use a server generated secret sent to each participant, and a four-six digit ephemeral code sent to the controlling party, which the controlled party must enter.

XLTechie commented 5 years ago

On Sat, 31 Aug 2019, Julien Cochuyt wrote:

  • Extend clipboard sharing to copying files, not only text.

On this point, i will add that by default (though it should be able to be configured away), this should prompt the controllee with every file that the controller wants to copy.

JulienCochuyt commented 5 years ago

isn't this also a good argument for not including remote in core at all? Might some corporate policies disallow NVDA entirely, because of its remote access capabilities? Even if able to be completely disabled by commandline or other policy mechanism, it could interfere with update distribution.

I honestly doubt so. NVDA, as all screen reader software I can think of, can already be considered as a key-logger and there is nothing an organisation can do about this. Remote Control, on the other hand, can easily be blocked with a firewall. Also, don't forget that NVDA already has some kind of built-in Remote Control: The Remote Python Console. You hardly can provide remote assistance with it but, once enabled, you can easily use it to collect information such as key strokes or files. NVDA, in that matter, would not get banned wherever Jaws is authorized.

  • Extend clipboard sharing to copying files, not only text.

If you're going to do that, you will definitely need end to end encryption. Any SSL tunnel should be sufficient. In fact, even without this, any solution that does not implement encryption of transferred data, files, screens, speech strings, or whatever else, is likely to suffer much in public acceptance.

Just to be sure things are clear: The current NVDA Remote add-on already encrypts its transmissions between the clients and the server. It fails to do it in a strong manner as certificates are not regenerated, but it does. By E2E, I mean encrypting transmissions between the two clients. That is, in a way the server cannot inspect the info sent nor take control itself.

I personally still like the screen shotting idea more than trying to incorporate screen sharing.

Screen shots are useful, but you hardly can use a pointing device with this solution.

  1. Have one of the machines reach out to the other via a pre-heated port, which should get around most firewall problems.

Thanks for pointing this out. This is a P2P technique used by Skype among many others. It relies on a security weakness commonly found in routers. For the best or the worse, some routers fix this weakness, and pre-heating ports is of no use for TCP. Nevertheless, if the fastest path is P2P as it often is the case, yes, it should be preferred.

Why ID and pass, and why pairs?

We indeed do not have a previously available authentification. The proposed ID could here come in handy to reach a controlled user for the first time. After a first successful connection, the other party can keep track of the certificate associated with each ID to avoid usurpation, and the whole password thing could even be dropped as ID check is available thanks to the unique certificates. One thing to keep in mind is that the ID can only be unique to one server unless servers are linked.

Solutions like the Apple support screen sharing system and others,

If I'm not wrong, they all use some kind of ID, like an Apple ID, a server generated ID or a phone number.

a server generated secret sent to each participant

I am not sure I am getting your point here. Could you please clarify the use of this secret?

and a four-six digit ephemeral code sent to the controlling party, which the controlled party must enter.

If the controlled party has to enter an ephemeral validation code, one cannot setup a home computer to be freely accessed on the go. I guess this is a reasonable use case, and I know of several people doing so with the existing add-on. Thus, I guess the password, be it generated and ephemeral or not, should be entered on the controlling side

DrSooom commented 5 years ago

Also, don't forget that NVDA already has some kind of built-in Remote Control: The Remote Python Console. You hardly can provide remote assistance with it but, once enabled, you can easily use it to collect information such as key strokes or files.

Please see issue #8515 and #8880 as well as PR #9517 and the chapter "Remote Python Console" in the NVDA Developer Guide.

Any SSL tunnel should be sufficient.

At the moment you can only use TLS 1.2 or TLS 1.3. SSL 3.0, TLS 1.0 and TLS 1.1 are deprecated (next year). Source: https://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development

And regarding clipboard/file sharing: These options should be disabled by default and if they are needed, their state should only be changeable while no remote access is running. Otherwise the client user can copy everything from and to the server.

XLTechie commented 5 years ago

On Mon, 2 Sep 2019, Daniel Mayr wrote:

  Any SSL tunnel should be sufficient.

At the moment you can only us TLS 1.2 or TLS 1.3. SSL 3.0, TLS 1.0 and TLS 1.1 are deprecated (next year). Source:

I am aware, I was using SSL generically. I guess I should have said "any encrypted tunnel that is based on a protocol that hasn't been deprecated recently, which we can probably obtain by wrapping off the shelf software".

And regarding clipboard/file sharing: These options should be disabled by default and if they are needed, their state should only be changeable while no remote access is running. Otherwise the client user can copy everything from and to the server.

A good point.

JulienCochuyt commented 5 years ago

And regarding clipboard/file sharing: These options should be disabled by default and if they are needed, their state should only be changeable while no remote access is running. Otherwise the client user can copy everything from and to the server.

(By "client" and "server", I guess you mean "controlled" and "controlling".) I disagree. Clipboard text sharing is already in NVDA Remote add-on for years and this is not why its currently unsecure. When you give remote access - and you only should do so to a fully trusted party - the person in control can already copy thing back and forth and even break your system and the like. It should be considered just as if you stand up from your chair and invite someone else at your keyboard: Risky and helpful. The point in including file copy support to the clipboard sharing feature is just a matter of leveraging something you can already do to something you can easily do. My target use case is to ease copying a file to the controlled computer - like a software update package or a diagnosing tool - not the other way around, but I really see no harm in either way.

XLTechie commented 5 years ago

Julien Cochuyt wrote:

(By "client" and "server", I guess you mean "controlled" and "controlling".)

I'm sure he did. Those are certainly my preferred terms. Server has a very specific use in this conversation, and neither of those is it.

Clipboard text sharing is already in NVDA Remote add-on for years and this is not why its currently unsecure.

I have no objection to clipboard text/graphics exchange, for what that's worth. However personally I do think each file transaction operation should be confirmed by the controlled user, unless that feature is disabled by checkbox and heavy warning.

When you give remote access - and you only should do so to a fully trusted party - the person in control can already copy thing back and forth and even break your system and the like. It should be considered just as if you stand up from your chair and invite someone else at your keyboard: Risky and helpful.

Yes, but the key word there is "give". We can not be sure that this system will never be cracked and misused by some bad actor. So adding an extra check for files seems reasonable to deal with that situation.

My target use case is to ease copying a file to the controlled computer - like a software update package or a diagnosing tool - not the other way around, but I really see no harm in either way.

There is harm in both ways.

  1. Controlling computer copies a piece of malware onto the controlled, in such a way that it runs next time the machine reboots, thus obscuring the source.

  2. Controlling computer copies private files from the controlled in order to obtain some information. We already had an add-on believed to be acting this way (now blacklisted).

The point is, we shouldn't be so confident in our own security model, that we neglect reasonable protections on already established connections.

JulienCochuyt commented 5 years ago

The point is, we shouldn't be so confident in our own security model, that we neglect reasonable protections on already established connections.

You are of course very right in this matter. Nevertheless, I think we should keep in mind that as soon as you give "keyboard" access, you are already fully exposed to the risks you mention.

Again, copying a file back and forth is already feasible with the current solution, it just is harder as it could be for the end user.

For the record, my current method of copying a file to a controlled machine with restricted access to the Internet: Simply open a Python console, feed a variable with a base64-encoded version of your file, and then save the decoded version on disk. If the clipboard text sharing was disabled, an attacker could have a bot type in the content instead. If the Python console was disabled, an attacker could have used any other scripting mechanism already available on the system to achieve the same result.

IMHO, securing a system is making unwanted actions technically unfeasible, not just making them uselessly unfriendly for the end user.

bhavyashah commented 4 years ago

A series of comments from several people last year indicated a great deal of interest in integrating remote functionality into NVDA core. Also, https://github.com/nvaccess/nvda/issues/4390#issuecomment-521164424 suggested that this would become an area of focus for NV Access too. The purpose of this comment is not to add something substantive to the rich discussion that has already taken place, but to just ping this ticket since it has been a while.

LeonarddeR commented 4 years ago

The problem with this proposal is time. Now NVDA Remote works with NVDA versions on Python 3, it is likely to get no attention in the near and more distant future, until something breaks.

seanbudd commented 2 months ago

@coderabbitai can you please create a summary of the issue discussion so far

coderabbitai[bot] commented 2 months ago

[!TIP] For best results, initiate chat on the files or code changes.

@seanbudd, here's a summary of the discussion on the GitHub issue regarding the integration of remote functionality into NVDA:

Main Themes and Discussion Points:

  1. Remote Functionality Similar to JAWS Tandem:

    • The initial request was for a feature similar to JAWS Tandem, which led to discussions about the feasibility and desirability of such functionality in NVDA.

  2. NVDA Remote Add-on:

    • An NVDA Remote add-on was developed and released, providing the requested tandem functionality. This add-on is open source and has been available for download, addressing the initial request effectively.

  3. Integration into NVDA Core:

    • There have been ongoing discussions about whether to integrate the NVDA Remote functionality directly into the NVDA core. The main arguments for integration include streamlined updates and ensuring compatibility with NVDA updates. The main arguments against focus on security concerns and the flexibility of updating an add-on separately from the core NVDA updates.

  4. Security Concerns:

    • Security has been a significant concern throughout the discussion, with various participants noting the potential risks of integrating remote access functionality directly into NVDA. Concerns were raised about the ease of updating security features in an add-on versus the core program.

  5. Future Directions and Action Points:

    • While the add-on serves the current needs, there is a recognized desire from parts of the community and some NVDA developers to explore the possibility of integration into the core, especially to address issues like compatibility and maintenance. However, no definitive plans have been made, and the discussion indicates a need for careful consideration of security implications.

This summary captures the essence of the lengthy discussions and the various viewpoints presented. If there are specific details or aspects you would like to explore further, please let me know!