Don't open HTTP(s) links by default

[joshuef]

Currently

Any HTTP/S request is blocked within the SAFE Browser, but opens your default browser automagically.

This may well be abused to deanonimize users.

Wanted

At the base level: Not to open HTTP/S links automatically.

Show a notification w/ option to open a link? (We'd need this while we have the invite server eg.)

Other considerations,

We should inform the user that there's a request. And of the (potential) dangers of a clearnet request.

We may want to consider:

• Blocking more than X notifications / requests from a page?
• Wording for any notifications/alerts
• Allow opening of links by default if a user initiated the process? (eg by clicking a link)
• A setting to block all HTTP/S notifications altogether. (Should that be default)
• A setting to allow HTTP/S requests by default
• Do we allow other protocols to be opened by their default handler? Is that a separate notification check?
• Enable a whitelist of sites to open automatically? (And management of said list)
• .... more things...

@JimCollinson @shankar2105 FYI.

[bochaco]

I can imagine this to be exposed to the user in a similar way as Firefox shows you and allows you to handle content blocking from each site:

[happybeing]

What would be legitimate reasons for a page/app being able to automatically trigger opening another browser (or a dialogue prompting the user to allow it)? Let's be strict at least to start with and try to keep it to really good reasons, rather than say, to direct to a website that has relevant info since that can be done in another way.

So are there any important use cases?

Hmm, none spring to mind. Everything I'm imagining comes down to convenience for user or developer. What am I missing?

[joshuef]

@theWebalyst I'm not sure you're missing anything, TBH.

It comes down to being able to opt-into a more seamless clearnet experience(in some sense), and if we want to offer that at all.

Maybe a user want's that option, so why not offer it if you can (and it's not on by default?), to make using Safe Browser more pleasant...

---

There's more reason for that to be needed w/ Safe Browser while no other options for browsing are available. But even then... do we want to compromise on security?

It's a whole lot to consider.... And maybe worth asking first what the SAFE Browser is and is not... maybe that helps us figure out what features we'll include or no.

[happybeing]

Any chance we could have a base 'httpAction' setting ASAP, and make it accessible as an API?

This would be really useful with Solid apps. I almost have them so you can run them on SAFE without making any changes to the app - just using a fork of solid-auth-client. If I had API control over SB http action, it would be really nice because they can open all sorts of garbage that can be blocked without breaking them (e.g. access to Google fonts, service workers etc).

If I could disable http through the experimental API, people should be able to build a Solid app and put it on web or SAFE and it would just work so long as it is reasonably well behaved. This is still a WIP, but I pretty much have this working and it would be a great demo. Cheers! 🙏

[joshuef]

@theWebalyst I'm not sure what you're asking for here. Can you elaborate a bit.

The ability to enable HTTP reqs? Or control the filter via an API?

happy to help if we can! Sounds pretty rad for SOLIDifying things

[happybeing]

Sorry for not being clearer! I'd the ability to block http(s) and have nothing happen (except maybe a message in the browser window console). So I'm suggesting an experimental API setting which an app can set to control that behaviour. It can have other settings too of course, so maybe:

httpBehaviour ( HTTP_BLOCK | HTTP__OPEN_DEFAULT_BROWSER | HTTP_PERMIT_ALL )

Initially I would like HTTP_BLOCK to be the default in case I can't set it early enough in my code. We can play with variations later.

An HTTP_PERMIT_FILTERED setting might allow provision of whitelist/blacklist, but all I'm interested in for now is blocking all action for http(s) as a default.

[joshuef]

I've mooted the idea of a whitelist before, though I don't really like it, it may be convenient for now (for the invite server eg).

I'm not sure handing off this control to an application makes sense. But certainly options at the browser/settings level could make sense.

In terms of getting anything into the browser before we go through some proper UX design of things, I think just blanket blocking/whitelist makes sense (though even with that... do you enable blocking of localhost resources?), anything more might be putting the cart before the horse.

---

@bochaco @JimCollinson any opinions on removing the current behaviour of defaulting to opening HTTP links the the standard browser?

(But for the invite link, for convenience I'd guess).

[happybeing]

I have my fork of solid-auth-client working, but before going public about it I would like:

• SAFE Browser production build: by default, silently block http(s) except invite server, but with console warning so we can track http requests.
• SAFE Browser dev build: as above, but also allow http://localhost
• SAFE Browser dev build: window.eval() support enabled (issue Don't open HTTP(s) links by default #619)

If this could be sneaked into the next release that would be awesome - we can then go public about running the same Solid app on Web and SAFE, and Solid devs can easily try this out. Seriously though, I do appreciate you have other priorities, so as and when is fine too. 😸

[hunterlester]

Extending this issue to also cover migration from current notification UI to antd component.