I have an MS Access 2016 application that will have a number of users who will have their Trust Center Settings set at different levels.
The form that I have set to come up automatically at start-up just has text that prompts a user to enable all content before continuing and a single 'Continue' button.
In testing this I first had my Trust Center Settings to "Disable all macros with notification". When I brought up the app, I got the Yellow Bar allowing me to enable content.
I then set the Trust Center Settings to "Enable all Macros". I brought the app down and then back up and got no Yellow Bar.
I then set the Trust Center Settings to "Disable all Macros without notification". When I brought the app down and back up I got no Yellow Bar, and I was able to execute my macros. I was hoping that the macros wouldn't work so I could continue testing for all different user security settings.
What is happening? Has my app somehow gotten on a Trusted Documents list? If so, I don't know where to look for that as there is nothing listed on the Trusted Documents dialog in MS Access.
Thanks to Andre for referring me to the Jcutrer.com site. I am only answering this question myself because I have been chastised in the past for letting a question go unanswered for longer than a day, and Andre has not posted his comment as an answer.
In brief:
Even if your Macro Trust Settings are set to "Disable all macros with notification", once you enable macros for a particular app, that app will be added to the list of Trusted Documents in your registry.
Once an app has been added to the list of Trusted Documents, regardless of your Macro Trust Settings, the macros will automatically be enabled when you bring that app up at a later date.
The Trust Settings list for MS Access is stored in the registry here:
HKEY_CURRENT_USER\Software\Microsoft\Office<Office Version>\Access\Security\Trusted Documents\TrustRecords
There are similar locations for other MS Office apps like Excel
All you need to do is go to that location in the registry, identify the app by it's file path and name, and delete that value from the registry. The next time you bring up the app it will do so in accordance with your Macro Trust Settings, e.g. if you have set it to "Disable all macros without notification" then your macros will be disabled.
Whine: Once again my question has been marked as having been insufficiently researched before posting. I tried many things in the code, and completely familiarized myself with the Trust Settings interface available to me through the File > Options interface. I searched for some time on Stack Overflow for an answer. I googled for quite some time as well. All to no avail.
In the end, the answer was in a place that was not obvious. If I had known enough to look into the registry or know that MS would willy-nilly mark an app as a Trusted Document just because I enabled the macros once, then I obviously wouldn't have posed the question.
It seems that in order for someone to be considered to have researched a question sufficiently, they basically had to come within a hair's width of the answer. What message does it send to insinuate that users are too stupid or too lazy to do a sufficient amount of work before posting on Stack Overflow?
Related
According To Scott Hanselman's blog post you can disable "reply-all" in your emails with a macro. I have tested this and it is also possible to disable this action with the developer tools in that are built into outlooks form editor.
It obviously only works in Outlook desktop to outlook desktop scenarios. However, when I inspect the email body or use outlookspy I can't see any thing in the message or exchange responses that would indicate that "reply-all" is disabled.
How is it possible for the receiver's client to know that reply-all is disabled? I expected some header, hidden attachment or even some trickery of exchange server, but I can't seem to find anything that explains what could be happening. I would like to replicate this functionality (in my internal corporate network) making "reply"/"reply-all"/"forward" disabled for all of our automated messages, truly making "no-reply" mean NO REPLY.
Disabling various actions on a message only works locally - the recipients do not see that information and their email client would be under no obligation to honor that request even if it was present.
You can of course use Information Right Management (https://learn.microsoft.com/en-us/exchange/policy-and-compliance/information-rights-management?view=exchserver-2019), but it is not quite the same.
I spend a good part of my day in meetings in Google Meet (to be clear, meet.google.com). Periodically, I accidentally hit refresh or close the wrong browser tab, and it's the Meet tab that I'm closing, which of course means that I'm accidentally leaving the meeting.
Web pages have a basic function that enables the browser to ask "Are you sure you want to leave?" or similar question. Is possible to enable this option via Meet settings or via other browser settings? If not, then can this be added via extension (though lower preference for this option)?
Hi I have a really simple program, just a webbrowser control and one line of code.
Webbrowser1.navigate "www.sspcrs.ie/sha2"
This gives a vb scripting error/exception about being unable to create a certenroll object.
If I go to the same url in internet explorer there is no problem.
For what's it worth I have tried varying the security settings in internet explorer but it does not seem to make any difference.
In the fail situation the vb script on the page tries about 3 different ways to create a cert object and then if there is an error in all three puts up an error message suggesting that activex objects be allowed and turning of protected mode.
In the success situation a Web Access dialog appears asking the user if they are willing to "allow this site to perform a digital certificate operation".
My app needs the 'always' location permission. Apple complicated location permission options if apps ask for 'always' directly, so I started asking for 'while using' and then 'always'. This gives the user a first dialog, for 'while using', with buttons of 'Don't Allow' and 'Allow', which is great. However, I'd like the next dialog to have these same buttons (assuming they allow 'while using'), and I was getting this before my upgrade to iOS 11 Beta 5 (I'm not sure - I might have skipped a couple betas).
With iOS 11 Beta 5, I see complicated button text (like 'While using the app' and 'Always' instead of 'Don't Allow'/'Allow') EVEN IF the 'while using' permission is already granted.
I want to give users the simpler options. I think users read these permission dialogs about as often as they read EULAs, and that if it's not a simple allow/don't allow, most will just pick a random option instead of reading, and my app won't have the permission it needs.
Is this possible with the latest iOS 11 Beta? And will it be possible in the final iOS 11? I thought this was what Apple was suggesting - here's some advice (from https://m.rover.io/wwdc-2017-update-significant-updates-to-location-permissions-coming-with-ios-11-41f96001f87f):
For those seeking always permission levels, Apple is now recommending a new permission flow which is essentially a two-phased approach. The first phase or initial onboarding, should only ask for ‘when in use’ permissions...
The dialog stays the same for iOS 11.
With requestWhenInUseAuthorization() iOS will present these options:
If the user allowed location access while in use and you later ask to always access location with requestAlwaysAuthorization(), iOS will present these options. You are already getting the benefit here that Don't Allow Any Access is not offered:
If you ask for requestAlwaysAuthorization() right away before asking for requestWhenInUseAuthorization(), iOS will present these options:
So solve your problem, it is advisable to not just request the iOS dialogs but prepare the user with your own pre-dialog. Only request the iOS dialogs when you are sure that the user will accept. This will lower the chances that a user denies access this time, but maybe would have allowed access in other circumstances. Once the user denies, you cannot request the iOS dialogs anymore.
On a general note:
I think users read these permission dialogs about as often as they
read EULAs
Frankly said, that should not be the fundamental assumption on which we develop app workflows and govern user privacy.
Tech companies and the public discourse are increasingly focusing on user privacy. Giving choices is clearly not enough, part of the job is educating users that granting their location 24/7 to some possibly unknown hobby developer or a company in a country with unknown data protection laws is not the same as clicking Yes on an EULA. Also legal changes require that sharing of such sensitive information as your live location cannot be hidden somewhere in an EULA but must be explicitly opted-in by the user.
Thankfully the efforts of companies like Apple ensure responsible access to user data for developers to build great features. This can only be done by giving the choice to the users through conspicuous prompts like the one you are referring to. Because the alternative could be no data sharing or higher hurdles by law.
Update March 2018
To emphasize on the point made above: The recent lack of trust in tech regarding data privacy (Facebook & Cambridge Analytica) confirmed how important is it to understand the responsibility that comes with personal data. The result will be more external regulation - and rightly so. The conclusion for designing data access permission workflows can only be to inform and educate users and to transparently disclose what data is used for what purpose and give an easy to access option to un-share / delete data.
Update May 2018
With the European Union's General Data Protection Regulation (GDPR) coming into effect, it also became mandatory that you need to communicate information about how you process personal data in a way that’s concise, transparent, intelligible, easily accessible and in clear and plain language.
we have a COM add-in that we use in MS Office application like Word and Excel.
That COM add-in has exposed few APIs to use, which we use for customization.
Problem is - Any user can access the APIs and that is causing security problems.
we dont want that to happen, we want to give access to VBA editor to only few peoples.
Is there any way - to disable VBA editor, without disabling VBA, because we want to use other Macros and Add-ins.
Thanks in advance!
PS - I tried hiding 'Developer' tab from toolbar but anyone who knows shortcut (ALT-F11), can still use it.
If one of the requirements of the COM Add-In is restricted access, the solution shouldn't be to disable anything than can access it. The answer should be to fix the add-in itself. An easy way to do it would be to define a user group that can use the add-in, and then just make the add-in check to verify the user is a member of that group. That should be simple to implement and simple to maintain.
The VBA Password Protection does not actually protect you from people reading the file. It's incredibly simple to remove the protection.
One alternative is to obfuscate the COM API as well as the VBA (so that, even if people can read the code, it would be difficult to figure out what's going on). Apple has done this in the past (e.g. isYoMamaWearsCombatBootsSupported -- https://github.com/JaviSoto/iOS7-Runtime-Headers/commit/6ccf9c4526992fec0dc414d48e4a3f7446e9822f#L10R61)
Can't you add a password to view/edit code? then at least they can't see your api and should prevent them from opening the editor.
Right click the project in the VBA project window and select 'properties' to add a password to that project in the Protection tab.