How safe is BOL technique?

  • 0
  • 1
  • Question
  • Updated 3 months ago
  • Answered
Hi Dan,

I have been reading the BOL technique and it appears it is built on the concept of probably hacking, for the lack of a better word "vulnerability" or open patch within quickbase. Is that true ? If so, do you think that technique will be around for long ? 
I know the alternate is the SW technique. The only issue i see with that technique is that it prompts the user for participation and hence we are at their mercy. 

Given the issue with the user having to opt in for SW, i was looking for an alternate way to have branding change done across the application and the only one that seems to come close is the BOL. But i am worried on the logevity of the solutions. 

What are your thoughts on the subject ? 

Thanks!!
Photo of Systems BVI

Systems BVI

  • 530 Points 500 badge 2x thumb

Posted 10 months ago

  • 0
  • 1
Photo of Ⲇanom the ultimate (Dan Diebolt)

Ⲇanom the ultimate (Dan Diebolt), Champion

  • 26,522 Points 20k badge 2x thumb
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 Policy

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/worker-src

There 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.
(Edited)
Photo of Ⲇanom the ultimate (Dan Diebolt)

Ⲇanom the ultimate (Dan Diebolt), Champion

  • 26,522 Points 20k badge 2x thumb
>The only issue i see with that technique is that it prompts the user for participation and hence we are at their mercy. 

BTW this is not true. I coded some scripts to ask the user for permission only to provide visibility that I was using a Service Worker. Normally a website would never ask for permission. I guarantee you that  there are Service Workers registered on your computer from sites you visited. Surprise yourself and see what Service Workers your machine has acquired due to casual browing:

chrome://serviceworker-internals/

I have a dozen Service Workers registered on a machine I reformatted last night.
(Edited)
Photo of Joshua Tate

Joshua Tate

  • 1,016 Points 1k badge 2x thumb
Yer i dont tell my users, they just have it register and update based on conditions i set.