BOL is a hack that
only an administrator can implement so you can consider it safe from a security viewpoint. But if you don't trust your administrator there are many other more direct ways the administrator could mess with your application and data without implementing
BOL.
The one benefit
BOL has over other injection techniques is that once implemented it applies to the whole
application.
IOL only applies to the
table it is implemented on and
SW applies to either the
entire account or an
individual dbid. depending on how the
scope is set when registered.
My guess is that eventually QuickBase will probably support some way of supporting user supplied JavaScript and we will not need to rely on hacks that only an administrator can implement.
Any of these techniques (
IOL,
BOL and variats) could break overnight if some code a QuickBase developer checked changed something. I think the word is that they are not going to make a breaking change.
Service Workers probably
can't be blocked by QuickBase in the current architecture because the browsers don't yet support the relevant header (this is bleeding edge stuff) .
Content Security Policyhttps://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/worker-srcThere is a big opportunity for QuickBase to support Service Workers through
CloudFlareWorkers..
The bottom line is that I would encourage you and everyone else to engaged in a healthy dialog with QuickBase over your needs the technical features that are available. I think they are receptive.