473,326 Members | 2,127 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

Stupid Audit Tricks

Lee
Just wanted to rant about people who think it's a good idea
to restrict user input.

I just copied and pasted my 8 character Confirmation Code
into a commercial web site and clicked "Go".

It whined that the Confirmation Code was invalid.

Comparing the value I had copied from to the field I had
pasted into, I saw that it had truncated the last character.

The Copy operation had included a leading space, and since
the field only allowed 8 characters, it kept the space and
dropped the last character of the Code.

That's bad user interface design.

The field should have accepted my input blindly and then
stripped whitespace and audited the remaining value.
--

Aug 27 '07 #1
24 2387
On Mon, 27 Aug 2007 10:09:25 -0700, Lee wrote:
Just wanted to rant about people who think it's a good idea
to restrict user input.

I just copied and pasted my 8 character Confirmation Code
into a commercial web site and clicked "Go".

It whined that the Confirmation Code was invalid.

Comparing the value I had copied from to the field I had
pasted into, I saw that it had truncated the last character.

The Copy operation had included a leading space, and since
the field only allowed 8 characters, it kept the space and
dropped the last character of the Code.

That's bad user interface design.

The field should have accepted my input blindly and then
stripped whitespace and audited the remaining value.
Actually that's a bad cut and paste operation on your part... things that
are different aren't the same.

--
I told you this was going to happen.

Aug 27 '07 #2
Lee wrote:
The field should have accepted my input blindly and then
stripped whitespace and audited the remaining value.
I totally agree. Humans (in my comprehensive survey of one, i.e. me) are
always adding leading and trailing whitespace. And you're right that
white*space* has to be stripped; about 10% of the time the trailing
character is a tab.

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk
Aug 27 '07 #3
Lee
Ivan Marsh said:
>
On Mon, 27 Aug 2007 10:09:25 -0700, Lee wrote:
>Just wanted to rant about people who think it's a good idea
to restrict user input.

I just copied and pasted my 8 character Confirmation Code
into a commercial web site and clicked "Go".

It whined that the Confirmation Code was invalid.

Comparing the value I had copied from to the field I had
pasted into, I saw that it had truncated the last character.

The Copy operation had included a leading space, and since
the field only allowed 8 characters, it kept the space and
dropped the last character of the Code.

That's bad user interface design.

The field should have accepted my input blindly and then
stripped whitespace and audited the remaining value.

Actually that's a bad cut and paste operation on your part... things that
are different aren't the same.
Of course it was, but bad cut and paste operations that
include extra spaces are invisible to the user. The web
page can easily detect them, and should. Instead, it
leaves the user trying to add the 8th character, and having
the field block it, for no obvious reason.

That's bad user interface design.
--

Aug 27 '07 #4
On Mon, 27 Aug 2007 14:31:14 -0700, Lee wrote:
Ivan Marsh said:
>>
On Mon, 27 Aug 2007 10:09:25 -0700, Lee wrote:
>>Just wanted to rant about people who think it's a good idea to
restrict user input.

I just copied and pasted my 8 character Confirmation Code into a
commercial web site and clicked "Go".

It whined that the Confirmation Code was invalid.

Comparing the value I had copied from to the field I had pasted into,
I saw that it had truncated the last character.

The Copy operation had included a leading space, and since the field
only allowed 8 characters, it kept the space and dropped the last
character of the Code.

That's bad user interface design.

The field should have accepted my input blindly and then stripped
whitespace and audited the remaining value.

Actually that's a bad cut and paste operation on your part... things
that are different aren't the same.

Of course it was, but bad cut and paste operations that include extra
spaces are invisible to the user. The web page can easily detect them,
and should.
That is a matter of opinion.
Instead, it leaves the user trying to add the 8th character, and having
the field block it, for no obvious reason.
No... the user in question is trying to add a ninth character as he's
already pasted eight characters into the field.

There absolutely IS a reason. An eight character field is an eight
character field. Not to mention this isn't a javascript gripe it's pure
browser interpretation of HTML where the max field length of the input
field is set to eight. Setting it to eight prevents the user from flooding
the field and protects against possible code injection.
That's bad user interface design.
That, again, is a matter of opinion. I'd say it's a user issue and has
nothing to do with design. What if the field is supposed allow whitespace?
For that matter, exactly how many unintentionally pasted characters should
the interface be designed to handle for it to be "good" interface design?
At what level of user incompetence does a design turn from "bad" to
"good"?

Id's say learn to use you mouse properly.

--
I told you this was going to happen.

Aug 27 '07 #5
On Tue, 28 Aug 2007 00:02:04 +0200, Thomas 'PointedEars' Lahn wrote:
Ivan Marsh wrote:
>[...] An eight character field is an eight character field. Not to
mention this isn't a javascript gripe it's pure browser interpretation
of HTML where the max field length of the input field is set to eight.

True, therefore ...
>Setting it to eight prevents the user from flooding the field and
protects against possible code injection.

... this is utter nonsense.
As always, your input is irrelevant.

--
I told you this was going to happen.

Aug 27 '07 #6
Lee
Ivan Marsh said:
>
On Mon, 27 Aug 2007 14:31:14 -0700, Lee wrote:
>Ivan Marsh said:
>>>
On Mon, 27 Aug 2007 10:09:25 -0700, Lee wrote:

Just wanted to rant about people who think it's a good idea to
restrict user input.

I just copied and pasted my 8 character Confirmation Code into a
commercial web site and clicked "Go".

It whined that the Confirmation Code was invalid.

Comparing the value I had copied from to the field I had pasted into,
I saw that it had truncated the last character.

The Copy operation had included a leading space, and since the field
only allowed 8 characters, it kept the space and dropped the last
character of the Code.

That's bad user interface design.

The field should have accepted my input blindly and then stripped
whitespace and audited the remaining value.

Actually that's a bad cut and paste operation on your part... things
that are different aren't the same.

Of course it was, but bad cut and paste operations that include extra
spaces are invisible to the user. The web page can easily detect them,
and should.

That is a matter of opinion.
Yes, just as "the user shouldn't be confused by the interface"
is a matter of opinion. There aren't too many people willing to
argue that it's an incorrect opinion, though.

>Instead, it leaves the user trying to add the 8th character, and having
the field block it, for no obvious reason.

No... the user in question is trying to add a ninth character as he's
already pasted eight characters into the field.
There is no *obvious* reason. The user can't see the space.
The user didn't choose to include the space. Microsoft made that
judgment for him.

A user interface design that allows any situation in which the
user is scratching their head wondering why it won't allow their
input is bad. This is not rocket science, or even controversial
among people who've made any study of man-machine interfaces.

I post it to the Javascript newsgroup because we are frequently
asked how to "prevent the user from entering...". With very few
exceptions, any attempt to prevent the user from entering anything
they believe is reasonable is a bad design. You should accept
what they give you and, if it's not what you want, explain that
fact to them. Again, this is a very basic user interface design
principle. You certainly can't hide behind the idea of protecting
yourself from bad data if you know the first thing about programming.
--

Aug 27 '07 #7
Ivan Marsh wrote:
On Tue, 28 Aug 2007 00:02:04 +0200, Thomas 'PointedEars' Lahn wrote:
>Ivan Marsh wrote:
>>[...] An eight character field is an eight character field. Not to
mention this isn't a javascript gripe it's pure browser interpretation
of HTML where the max field length of the input field is set to eight.
True, therefore ...
>>Setting it to eight prevents the user from flooding the field and
protects against possible code injection.
... this is utter nonsense.

As always, your input is irrelevant.
We will see how irrelevant it is the moment someone easily passes more than
8 characters for that field to your server-side script with you not being
prepared for it, especially when the intention of the person is a buffer
overflow or code injection.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Aug 27 '07 #8
Ivan Marsh meinte:
>>Setting it to eight prevents the user from flooding the field and
protects against possible code injection.
>... this is utter nonsense.
As always, your input is irrelevant.
Let's face it: It's correct.

Why should a maxlength attribute provide "protection"? Maxlength
supports the user by giving an intrinsic feedback, that's all.

"Code injection"... I can override the maxlength, I can have standalone
scripts feeding the server.
With the same logic, you could also suggest to use hidden inputs for
storing classified data, since it won't be displayed.

Gregor
--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum
Aug 27 '07 #9
On 28 , 00:50, Ivan Marsh <anno...@you.nowwrote:
That's bad user interface design.

That, again, is a matter of opinion. I'd say it's a user issue and has
nothing to do with design. What if the field is supposed allow whitespace?
For that matter, exactly how many unintentionally pasted characters should
the interface be designed to handle for it to be "good" interface design?
At what level of user incompetence does a design turn from "bad" to
"good"?

Id's say learn to use you mouse properly.
I agree with you, must always be reasonable balance between the
complexity/importance of the problem and complexity of the solution.
Especially, if the problem is far-fetched...

Aug 28 '07 #10
Ivan Marsh wrote:
On Tue, 28 Aug 2007 00:02:04 +0200, Thomas 'PointedEars' Lahn wrote:
>Ivan Marsh wrote:
>>[...] An eight character field is an eight character field. Not to
mention this isn't a javascript gripe it's pure browser interpretation
of HTML where the max field length of the input field is set to eight.
>True, therefore ...
>>Setting it to eight prevents the user from flooding the field and
protects against possible code injection.
>... this is utter nonsense.

As always, your input is irrelevant.
It's not irrelevant - your statement was incorrect the way it was
formulated. I think it's a good habit to use MAXLENGTH, but it gives
you no protection against the things you mention. The only useful
check on string length (in regard to security issues) must be
performed at server.

Then, for injection attacks, use the same filters that you used when
the password was generated (a common check is e.g. alphanumeric +
underscore, which should set you safe).

Most kinds of buffer overflows / flooding cannot be prevented anyhow
if the attacker is persevering enough.

--
Bart

Aug 28 '07 #11
Lee
Ivan Marsh said:
>So you have an onChange handler on every input field you use just in case
someone pastes information incorrectly into the field? Seems like a waste
of time and bandwidth to prevent a non-issue to me... but I guess that's
just me.
I hope you stretched first, before jumping to that conclusion.
You could hurt yourself.

I have onChange handlers on fields where it will save the user
time/effort/frustration to have the value audited on the spot,
rather than waiting until they hit the Submit button.
--

Aug 28 '07 #12
On Tue, 28 Aug 2007 14:31:42 -0700, Lee wrote:
Ivan Marsh said:
>>So you have an onChange handler on every input field you use just in
case someone pastes information incorrectly into the field? Seems like a
waste of time and bandwidth to prevent a non-issue to me... but I guess
that's just me.

I hope you stretched first, before jumping to that conclusion. You could
hurt yourself.

I have onChange handlers on fields where it will save the user
time/effort/frustration to have the value audited on the spot, rather
than waiting until they hit the Submit button.
....and you're suggesting I'm jumping to conclusions? What magical
algorithm do you use to determine those fields?

--
I told you this was going to happen.

Aug 28 '07 #13
Lee
Ivan Marsh said:
>
On Tue, 28 Aug 2007 14:31:42 -0700, Lee wrote:
>Ivan Marsh said:
>>>So you have an onChange handler on every input field you use just in
case someone pastes information incorrectly into the field? Seems like a
waste of time and bandwidth to prevent a non-issue to me... but I guess
that's just me.

I hope you stretched first, before jumping to that conclusion. You could
hurt yourself.

I have onChange handlers on fields where it will save the user
time/effort/frustration to have the value audited on the spot, rather
than waiting until they hit the Submit button.

...and you're suggesting I'm jumping to conclusions? What magical
algorithm do you use to determine those fields?
I'm sorry, I confused you with that guy with years of UI experience.
--

Aug 28 '07 #14
On Tue, 28 Aug 2007 15:23:34 -0700, Lee wrote:
Ivan Marsh said:
>>
On Tue, 28 Aug 2007 14:31:42 -0700, Lee wrote:
>>Ivan Marsh said:

So you have an onChange handler on every input field you use just in
case someone pastes information incorrectly into the field? Seems like
a waste of time and bandwidth to prevent a non-issue to me... but I
guess that's just me.

I hope you stretched first, before jumping to that conclusion. You
could hurt yourself.

I have onChange handlers on fields where it will save the user
time/effort/frustration to have the value audited on the spot, rather
than waiting until they hit the Submit button.

...and you're suggesting I'm jumping to conclusions? What magical
algorithm do you use to determine those fields?

I'm sorry, I confused you with that guy with years of UI experience.
Okay... so you've abandoned convention, standardization and consistency...
employed a method of development you can't explain and you're going to
make cracks at me?

Grow up.

--
I told you this was going to happen.

Aug 29 '07 #15
Lee
Ivan Marsh said:
>
On Tue, 28 Aug 2007 15:23:34 -0700, Lee wrote:
>Ivan Marsh said:
>>>
On Tue, 28 Aug 2007 14:31:42 -0700, Lee wrote:

Ivan Marsh said:

>So you have an onChange handler on every input field you use just in
>case someone pastes information incorrectly into the field? Seems like
>a waste of time and bandwidth to prevent a non-issue to me... but I
>guess that's just me.

I hope you stretched first, before jumping to that conclusion. You
could hurt yourself.

I have onChange handlers on fields where it will save the user
time/effort/frustration to have the value audited on the spot, rather
than waiting until they hit the Submit button.

...and you're suggesting I'm jumping to conclusions? What magical
algorithm do you use to determine those fields?

I'm sorry, I confused you with that guy with years of UI experience.

Okay... so you've abandoned convention, standardization and consistency...
employed a method of development you can't explain ...
No, I haven't done any of those things, unless you think that
consistency means adding audits to all fields, whether or not
it makes sense. What I do is *think* about the fields, and
whether or not the values are going to be well known to the
user (name, address, etc) or some value they could easily
confuse with another (confirmation number in place of
reservation number, for example), and provide immediate audits
only in those cases where the feedback is likely to be helpful
to the user.

The convention and standard that you seem to be missing is
that client-side auditing in general, and per-field auditing
in particular exist *only* for the convenience of the user.
--

Aug 29 '07 #16
Lee
Ivan Marsh said:
... employed a method of development you can't explain ...
It also occurs to me that if you've been doing a job for 25
years and haven't internalized enough of the process that you
"just know" some things, you're not welcome on my team.
--

Aug 29 '07 #17
On Wed, 29 Aug 2007 11:21:05 -0700, Lee wrote:
Ivan Marsh said:
>... employed a method of development you can't explain ...

It also occurs to me that if you've been doing a job for 25
years and haven't internalized enough of the process that you
"just know" some things, you're not welcome on my team.
You don't have a team.

--
I told you this was going to happen.

Aug 29 '07 #18
Ivan Marsh said the following on 8/29/2007 2:26 PM:
On Wed, 29 Aug 2007 11:21:05 -0700, Lee wrote:
>Ivan Marsh said:
>>... employed a method of development you can't explain ...
It also occurs to me that if you've been doing a job for 25
years and haven't internalized enough of the process that you
"just know" some things, you're not welcome on my team.

You don't have a team.
Lee may, or may not, have a "team" but some people lack tickets to the game.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Aug 29 '07 #19
On Wed, 29 Aug 2007 17:35:12 -0400, Randy Webb wrote:
Ivan Marsh said the following on 8/29/2007 2:26 PM:
>On Wed, 29 Aug 2007 11:21:05 -0700, Lee wrote:
>>Ivan Marsh said:

... employed a method of development you can't explain ...
It also occurs to me that if you've been doing a job for 25
years and haven't internalized enough of the process that you
"just know" some things, you're not welcome on my team.

You don't have a team.

Lee may, or may not, have a "team" but some people lack tickets to the game.
Trust me... it's something I "just know".

--
I told you this was going to happen.

Aug 29 '07 #20
Lee
Ivan Marsh said:
>
On Wed, 29 Aug 2007 17:35:12 -0400, Randy Webb wrote:
>Ivan Marsh said the following on 8/29/2007 2:26 PM:
>>On Wed, 29 Aug 2007 11:21:05 -0700, Lee wrote:

Ivan Marsh said:

... employed a method of development you can't explain ...
It also occurs to me that if you've been doing a job for 25
years and haven't internalized enough of the process that you
"just know" some things, you're not welcome on my team.

You don't have a team.

Lee may, or may not, have a "team" but some people lack tickets to the game.

Trust me... it's something I "just know".
Confirming your lousy judgment.
Any comments on the actual content?
--

Aug 30 '07 #21
On Mon, 27 Aug 2007 at 10:09:25, in comp.lang.javascript, Lee wrote:
>Just wanted to rant about people who think it's a good idea
to restrict user input.

I just copied and pasted my 8 character Confirmation Code
into a commercial web site and clicked "Go".

It whined that the Confirmation Code was invalid.

Comparing the value I had copied from to the field I had
pasted into, I saw that it had truncated the last character.

The Copy operation had included a leading space, and since
the field only allowed 8 characters, it kept the space and
dropped the last character of the Code.

That's bad user interface design.

The field should have accepted my input blindly and then
stripped whitespace and audited the remaining value.
First, you're implying that the Confirmation Code was supplied by the
web server or the system behind it. Can you be certain that spaces are
not significant?

Second, the code is a security feature. Perhaps the designers decided
that it should be input very carefully. It might be a genuine design
decision, even if not what you would do.

Third, a better solution is to have a 12 character field and let any
redundant whitespace characters be discarded in the server.

Incidentally, my credit card has a space between each group of four
digits, but web servers won't accept the spaces. Grrrrr.

John
--
John Harris
Aug 30 '07 #22
Lee
John G Harris said:
>
On Mon, 27 Aug 2007 at 10:09:25, in comp.lang.javascript, Lee wrote:
>>Just wanted to rant about people who think it's a good idea
to restrict user input.

I just copied and pasted my 8 character Confirmation Code
into a commercial web site and clicked "Go".

It whined that the Confirmation Code was invalid.

Comparing the value I had copied from to the field I had
pasted into, I saw that it had truncated the last character.

The Copy operation had included a leading space, and since
the field only allowed 8 characters, it kept the space and
dropped the last character of the Code.

That's bad user interface design.

The field should have accepted my input blindly and then
stripped whitespace and audited the remaining value.

First, you're implying that the Confirmation Code was supplied by the
web server or the system behind it. Can you be certain that spaces are
not significant?
This is the space before the code. If it's significant,
there's an even worse design problem.
>Second, the code is a security feature. Perhaps the designers decided
that it should be input very carefully. It might be a genuine design
decision, even if not what you would do.
It would be a very bad design decision. You don't make it
more difficult for the user just to ensure that they enter
the data carefully. You use valid and reasonable audits.
>Third, a better solution is to have a 12 character field and let any
redundant whitespace characters be discarded in the server.
Client-side audits are good when they make things easier for
the customer. It's probably easier for them to be told that
they left off a digit immediately, instead of waiting until
after they've submitted the form. By then they may have
closed whatever they're copying it from.
>Incidentally, my credit card has a space between each group of four
digits, but web servers won't accept the spaces. Grrrrr.
Yep. That's bad design.
--

Aug 31 '07 #23
On Thu, 30 Aug 2007 at 22:55:48, in comp.lang.javascript, Lee wrote:
>John G Harris said:
<snip>
>>Third, a better solution is to have a 12 character field and let any
redundant whitespace characters be discarded in the server.

Client-side audits are good when they make things easier for
the customer. It's probably easier for them to be told that
they left off a digit immediately, instead of waiting until
after they've submitted the form. By then they may have
closed whatever they're copying it from.
<snip>

Note that I'm suggesting that the form field should be longer than the
longest Code value. In your case the copy-pasted Code would have gone to
the server unchanged and been accepted as correct. There is nothing
useful any client code could do. Adding unnecessary code to a web page
wastes developer time, adds yet more places where a bug could creep in,
and is at risk of suffering from variant browser problems.

John
--
John Harris
Sep 1 '07 #24
Lee
John G Harris said:
>
On Thu, 30 Aug 2007 at 22:55:48, in comp.lang.javascript, Lee wrote:
>>John G Harris said:

<snip>
>>>Third, a better solution is to have a 12 character field and let any
redundant whitespace characters be discarded in the server.

Client-side audits are good when they make things easier for
the customer. It's probably easier for them to be told that
they left off a digit immediately, instead of waiting until
after they've submitted the form. By then they may have
closed whatever they're copying it from.
<snip>

Note that I'm suggesting that the form field should be longer than the
longest Code value. In your case the copy-pasted Code would have gone to
the server unchanged and been accepted as correct. There is nothing
useful any client code could do.
Client-side code could catch the case where the user omits a digit
without making the user wait until it's been caught on the server.
--

Sep 2 '07 #25

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
by: Raphael Gluck | last post by:
Hi, Is it possible for one to program one's pages as such that when a database table is updated over the web, via a form, that an e-mail confirmation is sent to a specified address, notifying...
2
by: Keith | last post by:
Hi I am developing an ASP application which will interact with a SQL database. A requirement of the application is that there is a full audit trail of any modifications to data. I am...
0
by: Me | last post by:
Hi... A much lamented question, I guess.. I'm trying to create a simple audit trail. log the changes to an SQL 2000 table, so that they are written into a mirror table. The entire record, only...
3
by: Me | last post by:
Hi... A much lamented question, I guess.. I'm trying to create a simple audit trail. log the changes to an SQL 2000 table, so that they are written into a mirror table. The entire record, only...
3
by: Zlatko Matiæ | last post by:
Hello. I tried to implement audit trail, by making an audit trail table with the following fileds: TableName,FieldName,OldValue,NewValue,UpdateDate,type,UserName. Triggers on each table were...
1
by: Byrocat | last post by:
We're going to be enabling the audit facility on some of our DB2 servers in the future, and I need some basic information on how large I can expect the log to grow. I've already been warning NOT...
0
by: JohnO | last post by:
Thanks to Serge and MarkB for recent tips and suggestions. Ive rolled together a few stored procedures to assist with creating audit triggers automagically. Hope someone finds this as useful as...
6
by: Parag | last post by:
Hello, I have been assigned the task to design the audit trail for the ASP.NET web application. I don't know what the best practices for such audit trails are. Our application one dedicated user...
0
by: Santiago Cassina | last post by:
Hi list. I just want to send to you an sql file containing tools for audit the UPDATE and DELETE statements in a database by saving all the modifications made by a network/system/database user. I...
1
by: melissamuse | last post by:
I am using an MS Access 2002 database to track user login information. I have copied Allen Browne's audit log and removed the references to the error handling. So far, on all of my forms (for 7...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.