Logging and diagnostics


Status
Not open for further replies.
Hi all,

So I had an intresting shower thought tonight as a framework/plugin/implementation (ill refer to this set as implmentations) provider for SQRL (I currently lead the .net core asp.ner middleware effort) it went a little like this:

As a implmentation provider id like to gather diagnostics from the applications using the implementation so I can analyse bugs and issues if any happen throughout all the deployments.

Now that might sound fine to some and incredibly not ok to others (This is my stance on this right now), it's also not somth8ng I'm planning on doing in the ASP.net middleware (it open source you can check here https://github.com/TechLiam/SQRL-For-Dot-Net-Standard) although I'm currently adding logging that will only exist for the application not sent to a central location bit is probably why I thought about this.

So as implmentations such as the WordPress plugin by @kalaspuffar the Asp.net core middleware by myself @TechLiam and others (Sorry I don't have a list and I'm on my phone) start entering into the ecosystem of the web what could diagnostics data mean.

So pros and cons time from the point if view of doing it:

Pros
  • Critical errors would be reported directly to the implementation provider
  • Attacks on the SQRL ecosystem could be assesed and quantified
  • Attacks could be blocked if not patches quicker
Cons
  • Deanonamisation of users activity given enough data and sites use your implementation and you log the right kind of data e.g. IP address and time and maybe location.
  • More traffic generated and bandwidth issues
  • Fake logs could be reported

Ok so those are my thoughts on this matter I would suggest that although yes it would be grate to have the ability to analyse SQRL logins/authentication it would not be an ethical thing to do especially if the data could be deanonimised which would be very easy given a natural logging data set such as IP address, date/time and other key information.

As developers of implmentations this might become a pressure we come under to provide. As application developers I think we have a duty to check and verify the implmentations we use don't violate are users trust. As users we want to know are privacy is protected.

I know one of the key drivers for @Steve when he started designing SQRL was to try and protect users privacy.

Anyone got any thoughts on this?

Anyway that ends my ramble for now please talk away

P.s. this might have been talked about in the past but it's worth going over again as new people have joined the conversation (including myself) and the implmentations are been distributed now.
 

Vela Nanashi

Well-known member
May 19, 2018
715
123
I am not entirely sure what you want with this, but if you want to have logging it is usually when something is behaving badly. So if you can have a setting that can be enabled (off by default) by the server administrator, that will then fire logging off into a file or to one of the emails they set, with parameters requested by them, like if they don't want to log certain parts of the data just the parts they feel comfortable logging, then I see no harm adding it, as long as it is off by default in the plugins.

Also I think it is best to log to a file most of the time, or use the platform specific way to report errors, like putting those errors into the server log. A server admin who uses the plugin can then go fetch those lines and give them to developer for bug fixing.

I would personally not be comfortable with phone home behavior in the plugin, that is enabled by default, except one single thing, and that is if the plugin does check for updates, then doing so without personally identifiable information, that is fine.

Also if you do implement logging that sends log information, you should document it very clearly what exactly it will send back, and preferably have options to prune that down to exactly what the server administrator is comfortable with.

You could also add anonymizing steps if you really do need some way to distinguish between ip for instance but without being able to track it, one way I think you can do that is to use a hmac that the server admin can set up the key for, and the key would never be sent to developer, that way any collected anonymized information will be only useful in the scope of the server, while it has that same key, or between servers that share the same one.
 
I am not entirely sure what you want with this, but if you want to have logging it is usually when something is behaving badly. So if you can have a setting that can be enabled (off by default) by the server administrator, that will then fire logging off into a file or to one of the emails they set, with parameters requested by them, like if they don't want to log certain parts of the data just the parts they feel comfortable logging, then I see no harm adding it, as long as it is off by default in the plugins.

Also I think it is best to log to a file most of the time, or use the platform specific way to report errors, like putting those errors into the server log. A server admin who uses the plugin can then go fetch those lines and give them to developer for bug fixing.

I would personally not be comfortable with phone home behavior in the plugin, that is enabled by default, except one single thing, and that is if the plugin does check for updates, then doing so without personally identifiable information, that is fine.

Also if you do implement logging that sends log information, you should document it very clearly what exactly it will send back, and preferably have options to prune that down to exactly what the server administrator is comfortable with.

You could also add anonymizing steps if you really do need some way to distinguish between ip for instance but without being able to track it, one way I think you can do that is to use a hmac that the server admin can set up the key for, and the key would never be sent to developer, that way any collected anonymized information will be only useful in the scope of the server, while it has that same key, or between servers that share the same one.
I would like to take each paragraph one by one.

I fully agree that any logging should be configurable by the server administration and that and implementation of SQRL shouldn't require it.

I agree that it is best to log locally to the application in a configurable manner what ever that may be.

I fully agree with the stance of a phone home beavures been wrong other in the case you raise of updating.

I don't agree that relying on documentation to report what is logged is good enough although right they should it is down to server administrators to ensure this as well to protect there users.

I beleave you are right there are ways to do the gathering of diagnostic data in a correct manner (hmac keys by the server) however when specific pressures are leveraged against implementation providers (not I say when not if) it may become a concern.

In short this thread is a thought exercise on a potential and likely future and I was intrested in people's takes on it.
 

Vela Nanashi

Well-known member
May 19, 2018
715
123
Now you have my thoughts :) I think it is a good idea to consider these things.

Edit: also I agree that server administrators / users of plugins should check the code they are going to implement on their servers, it is their responsibility to do so. Though I also know a lot of sites just import scripts that they can't even read from all over the place, and feel comfortable using them on their sites, subjecting the users to the whim of anyone they import anything from.

I mean even this forum uses ajax.googleapis.com and code.iconify.design, something I dislike, I would rather the site admin downloaded the source files, checked that they behave as they expect, then serve a local copy of them, from their own servers. Since not doing so means any of those sites can subject the user to whatever they want, whenever they want. Unless I am missing something.

But that is just me taking the TNO all the way, or rather I like to place trust where I want to place it, I trust Steve more than I trust google or whomever iconify is :)
 
Last edited:
  • Like
Reactions: TechLiam

AlanD

Well-known member
May 20, 2018
123
23
Rutland, UK
One of the benefits of SQRL is that it gives the server no secrets to hold ( lose). Thus whilst any logging might have some tracking benefit, at least we know that it is not possible to log the user's private keys in the server as they are never sent.

From a privacy point of view, I dislike logging, however from a systems support view, I understand the need for it sometimes. I think that any logging in the server implementations MUST be configurable ( with the default being off or very low), perhaps the data to log should be the server internal session ID rather than the IP address to preserve anonymity as far as possible.
 

Alan M Cameron

Well-known member
I feel there is a fundamental question not being asked here.
Should SQRL anonymous users be allowed to comment on or contribute to a website?
If yes, there is a risk that the site might be taken over by trolls, spammers etc. unless other measures are taken which are not the function of SQRL to police..
If no, what is the point of the website. There are some good answers - a news site, a publicity site etc.

This leads back to the original question should logging of the presence of an SQRL user be done since there is no record of who the SQRL user is or was.

A commercial provider of a website which allows anonymous SQRL logins gets a benefit of not having to worry about keeping the users data secret. This could be a benefit in reducing the dictates of GDPR Observance.
 
I feel there is a fundamental question not being asked here.
Should SQRL anonymous users be allowed to comment on or contribute to a website?
If yes, there is a risk that the site might be taken over by trolls, spammers etc. unless other measures are taken which are not the function of SQRL to police..
If no, what is the point of the website. There are some good answers - a news site, a publicity site etc.

This leads back to the original question should logging of the presence of an SQRL user be done since there is no record of who the SQRL user is or was.

A commercial provider of a website which allows anonymous SQRL logins gets a benefit of not having to worry about keeping the users data secret. This could be a benefit in reducing the dictates of GDPR Observance.
I guess my point with this thread was if the SQRL implementation (e.g. a plugin or middleware) starts sending details to a centralised place unbeknown to the website admin or the users of the site.

On the GDPR there will be an interesting law suit here when it happens as really you can identify the user there for you have a legal requirement to provide the user with the data you have and depending on the request and subsections of the GDPR law remove/delete the data. As someone who has the "pleasure" of having to know the GDPR law in some detail I can't see any court understanding or accepting that a SQRL user is different to any other type of user, especially if the user can provide the IDK they wish to get the stored information about to you in there request. Under the GDPR act you would have to show reasonable effort to find the users data anyway but with that you'd have no choice. From a data leak point of view depending on what other data you have about your user there may be course for fines if it can be shown that users privacy is lost.
 

Alan M Cameron

Well-known member
I take your point about GDPR knowledge, it must be greater than mine. However the point is whether the website allows anonymous SQRL users. As I understand it the SQRL user can be authenticated but the resulting IDK is only stored while being authenticated or until the user agrees to provide the website with identifying details. Which is then the subject to all the intricacies of the GDPR but without the details being provided the website can say the user is not known as no details have been provided.
 
I take your point about GDPR knowledge, it must be greater than mine. However the point is whether the website allows anonymous SQRL users. As I understand it the SQRL user can be authenticated but the resulting IDK is only stored while being authenticated or until the user agrees to provide the website with identifying details. Which is then the subject to all the intricacies of the GDPR but without the details being provided the website can say the user is not known as no details have been provided.
Some what we could say that yes minimal data is stores but taking the GDPR law at its hart if you store any identifiable information the you have to respect the ind8viduals wishes with that data e.g. storing that a user logged in so storing the IDK.

My main concern with this thread is more that the SQRL implementation as a plug and play feature might have a bad actor who has changed it in a none clear way to send data to a central point allowing them to track you over different sites allowing a profile to be built.
 

AlanD

Well-known member
May 20, 2018
123
23
Rutland, UK
I guess my point with this thread was if the SQRL implementation (e.g. a plugin or middleware) starts sending details to a centralised place unbeknown to the website admin or the users of the site.
I would argue that any SQRL implementation MUST NOT send details to any centralised place. To do so would be a contravention of GDPR unless the user was aware that this data is being sent and had given informed consent.

If the server implementation has the ability to log if required, e.g. for diagnostics, troubleshooting etc, and the company is running a distributed network of SQRL servers and needs to amalgamate these logs, it can do it outside SQRL.
 
I would argue that any SQRL implementation MUST NOT send details to any centralised place. To do so would be a contravention of GDPR unless the user was aware that this data is being sent and had given informed consent.

If the server implementation has the ability to log if required, e.g. for diagnostics, troubleshooting etc, and the company is running a distributed network of SQRL servers and needs to amalgamate these logs, it can do it outside SQRL.
I agree fully it can only lead to bad things if an implementation was to do this.

My main point was a less than legal entity making a widely used implore.tation do this. A software suply attack if you will.
 

AlanD

Well-known member
May 20, 2018
123
23
Rutland, UK
I take your point about GDPR knowledge, it must be greater than mine. However the point is whether the website allows anonymous SQRL users. As I understand it the SQRL user can be authenticated but the resulting IDK is only stored while being authenticated or until the user agrees to provide the website with identifying details. Which is then the subject to all the intricacies of the GDPR but without the details being provided the website can say the user is not known as no details have been provided.
It depends on the level of logging/trackability that exists on the site. If a site gets a GDPR request, with a supplied public key for that site, all that they may be able to respond, in the absence of detailed logs, is "Yes a user with that public key has connected to our site at least once. We don't have any more information."
 
Status
Not open for further replies.