This, to my eyes, is key in order to stay within the safety features that the Safe network provides. One should be able to copy external links to the clipboard and do whatever they like with it outside of the safe browser, or the safe browser could provide a way to call an external browser using context menu. ( like, right mouse button or hovering pops a dialog saying "open this link with (xyz) browser ? , xyz being defined in preferences. ).
Other than these features, http requests to the legacy internet should be ignored by the code.
Very pleased to see that someone takes the plunge !
Creating a full-fledged module other than copies of the FS, will require a deep immersion into the BEAKER code, as well as support from the author that is currently not possible, therefore, within the given timeframe and budget that seems unlikely. This will also require a code processing, as well as his careful study, which is quite difficult to do, given the reluctance to help by the author.
We are all for @PaulFrazee being rewarded for your efforts on this portion; if you have the time and the community thinks it is worth it at this stage to fund. If you are interested, please include what would be required to complete this portion with regard to time and cost.
I do not know yet how it is implemented in BEAKER. We will follow up on this at a later time. Any suggestions on this section that will stream line our work would be greatly appreciated.
See above
This is implemented in Launcher API on TOKENS and AUTH level tokens are stored in encrypted form in a cookie.
On Startup
They will be stored in encrypted form in the cookies, if BEAKER allows you to work with cookies.
Yes, they will be stored in cookies.
9.I agree. But I do not know yet how it is implemented in the Beaker.
Agreed
The browser will communicate with LAUNCHER through the API as a standalone application.
###Conclusion
The implementation of all the above will require dense exploring Beaker code and dense work with the author of the Beaker Browser, so with designated budget and time this is not possible (Deep study of Beaker code alone may require a month and attempts to make modifications that will not result in the failure of his work as documentation sparse - it will be a re-engineering project. Therefore, the implementation of which is more complex than the FS module fork with the ability to work with the API instead of the file system in the budget and deadlines would be impossible.
Based on @PureF assessment the community can decide on how deep to go down this rabbit hole. It seems there is monetary support, but maybe we should put these extensive work items as additional stretch goals (First up) and let the crowd decide. I will do my best to connect with @PaulFrazee to get him on board with this build and make sure he is fully compensated for his time and efforts. @frabrunelle do you have any connection with the developer?
I suggest if an HTTP request happens in the main frame (i.e. top level as though you clicked a link), you ask the user whether he wants to open it in his primary browser with an option to never ask again for this site or to never ask again ever (of course, settings can be changed in a settings area).
Cookie makes little sense for a desktop app. Local storage is probably decent. Local sqlite would probably be fine too. Granted since you do login handshake on startup, in memory is probably fine for the auth info, just may not be reasonable for cross-process persistence such as permissions/settings.
Again, cookies make little sense as a storage mechanism for a desktop app.
I think itās probably not fair for me to ask these things ahead of time. I will just take a peek at the code when implemented.
I want to update the community on where I am at with this project. I did this proposal because we were less than a week out from a vote and nothing was posted.
Even though Iām out some cash and time spent hiring different devs to research the project and provide the technical components of the proposal(s) and commit to developing itāI have also been working on a bigger total Brave Browser customization with larger firm (Did not work out)ā I am considering closing this proposal and putting my full support behind @joshuef and his impressive proposal.
I am very encouraged by his commitment to the community and level of technical understanding of what needs to be built nowā¦and he can do it cheaper; I think his stretch goals and cost are also amazing. I wanted to put my thoughts out there, since this will leave us with one really strong SAFE browser proposal.
Definitely takes a strong person to admit things like this and do what you think is best for the community overall. Removed ego from the entire equation to make sure the best project comes to life
And thank you for being the first proposal, and getting the energy going in this area.
Yeah, you can count me in too ofc. More resources in one place sounds great in this context - you all seem very capable, so probably better to cooperate than compete in this case. Props to all concerned. Just tell me where to send the money.
I read in the SAFEr browser thread about the Brave browser. Seems to me like a better alternative if itās true as it says that it supports not only desktop OSs but also Android and iOS. Also, one would want all the capabilities of Chromium which iirc the Brave browser is based on.
