Yannick, I would possibly recommend trying to release it as a chrome
extension, but, mention the issue with eval in the description, and open
a form of channel for suggestions from any technical end-user?
Besides that, can't really think of any other better solution, off-hand
at the moment.
Jacob Kruger
+2782 413 4791
"Resistance is futile...but, acceptance is versatile..."
On 2022/11/13 11:37, Yannick Daniel Youalé wrote:
Hi everybody,** To leave the list, click on the immediately-following link:-
I am Yannick Youalé, the developper of the WebAccessibilizer, the web
script to make web pages more accessible.
I want today to make a point on the development of that tool, and
maybe ask you advises on what path to follow.
If you were careful on this list, there was some message in which I
was talking about my current work on trying to build a crome
extension for the WebAccessibilizer.
It went well, but at some point I am facing some issues.
As I've already revealed, development of chrome extension nowourdays
are submited to limitation not existing before.
Particularly the ability to use the eval function of the javascript.
You will agree that this limitation could be really anoying for
scripts trying to embed a kind of user script system based on
javascript.
In order to know how that functionnality is handle by other chrome
extensions with similar goal, I have downloaded the source code of
tamper monkey.
Even if the code of tamper monkey is mainly obfuscated, I could have
been able to notice effectively that no classical eval javascript
function is used inside.
However, I had not have enough courage to really inspect the 500ko of
that obfuscated code to exactly know what the tip there is.
This is wy after, I took the bull by its horns and tryed to find a
solution with my own means.
I finally find a way to execute user's personalized javascript, that
essentially consist in playing with both context present in the web
page.
This is the procedure:
1. the chrome extension create a new invisible textarea element in the
dom of the current web page.
2. It write the javascript code that has to be executed as value of
that invisible textarea.
3. The chrome extension create a div with an innerHTML of a link with
an onClick attribute in the dom of that page.
The trick here is that onClick attribute will declare an eval
function, asking for the value in the invisible textarea previously
created
4. Then the chrome extention will perform a click event on the link
within the div previously created.
So, the reason wy it works is because the link containing the eval
function has not been created in the context of the chrome extension,
but instead by the innerHTML method in the context of the current
page.
This juggling makes that limitations in the chrome extension context
can not block the execution of the eval function.
With that, I am now able to execute user script in the
WebAccessibilizer, despite the manifest 3 of the chrome extensions
policy.
But, unfortunately, you can imagine that if I write this e-mail today
is because I've faced some further issues with the execution of those
user scripts.
So, during my tests, since about three weeks, I have noticed that this
trick to make the eval function work is efficient on almost all web
sites
They are just two web sites where my new procedure failed.
gmail.com and outlook.com.
The reason of those failures in each time for those web sites was a
very strict content security policy, that was not granting unsafe eval
functions.
So, in other words, with those two pages, the eval function was
forbidden either in the chrome context or in the page context.
In the same time I remark that tamper monkey has no problem to execute
its user scripts on thos two web sites.
A very disturbing fact for the WebAccessibilizer, that should normally
be able to do the same I think.
What I have to do now?
Let me present some options:
1. To not worry and just to release that version of the chrome
extension of the WebAccessibilizer?
Even if it is not perfect for now, in the future I will maybe find
ways to tackle above problems?
Note that I am not even sure that the chrome web store will eventually
validate this way of executing eval function.
2. Try to find a way to parse the javascript?
A very big job to achieve in fact, if I want to handle every situations.
3. Create a kind of scripting language?
But the same problem with the previous solution remains.
However, with this one, one advantage is that I could make some
checking about security expected issues.
4. Find another solution?
Maybe you have another way of doing things to propose me?
What do you think?
What your programming instinct tells you to advise me?
If I may jump on a related topic, talking about the opportunity to
publish the source code of the WebAccessibilizer on github, I finally
agree.
However I think I have first to decide in what direction the
WebAccessibilizer should go before doing it.
There are Too much modification made between the classical version of
the WA and the chrome extension version.
Thank you in advance for any suggestion or remark.
I think it was Arthur C. Clarke that said:
"Magic is just a science we don't yet understand."
Yannick Daniel Youalé
From Cameroon, in central Africa.
** To leave the list, click on the immediately-following link:-
** [mailto:program-l-request@xxxxxxxxxxxxx?subject=unsubscribe]
** If this link doesn't work then send a message to:
** program-l-request@xxxxxxxxxxxxx
** and in the Subject line type
** unsubscribe
** For other list commands such as vacation mode, click on the
** immediately-following link:-
** [mailto:program-l-request@xxxxxxxxxxxxx?subject=faq]
** or send a message, to
** program-l-request@xxxxxxxxxxxxx with the Subject:- faq
