S

spirit

Seems like all video playback has stuttering audio or audio that just stops playing. Also, YouTube.com at least seems to has some issues with freezing. Having trouble reproducing it consistently. Didn't have this issue in Orion 0.99.111-beta (WebKit 613.1.12).

Steps to reproduce:
Go to any site with video and play the video unmuted. Sites I've tried:

• YouTube.com
• peacocktv.com
• rightthisminute.com
• twitter.com

Expected behavior:
Audio doesn't stutter.

Orion, OS version; hardware type:
Orion 0.99.111.2-rc (WebKit 614.1.2)
macOS 12.2 (21D49)
MacBook Pro (15-inch, 2018)

Image/Video:

We are preparing a new "Recommended extensions" screen and want to know which extensions are working in Orion and are being used by our users.

Edit: Please also note if the extension is fully working.

Thanks!

Currently, the address and invocation character/keyword fields are only accessible via the edit bookmark dialog. This makes the feature very difficult to discover. Even for users who have used similar features in the browsers, this is an unintuitive place to look for it.

The minimum ask is that the address and invocation character/keyword fields are exposed in the "Add this page to..." (add bookmark) dialog, perhaps initially hidden under a "More Options" or "Search Options" button that reveals these fields when clicked.

Original card: https://orionfeedback.org/d/1548-duckduckgo-style-custom-bang-searches/5
Sibling card: https://orionfeedback.org/d/1602-search-invocation-keywords-think-ddgs-bang-searches-should-be-managed-long-with-search-engines

I appreciate that we can add custom search engines, but it'd be great if we could add custom DuckDuckGo-style !bang searches. Of course, using a prefix like DDG does may cause complications. Instead, how about just adding an optional keyword field in the manage search engines dialog. When the user types the keyword in the address bar, there can be a prompt to hit tab to switch to searching with the search engine represented to the keyword instead of the default search engine.

For example, I work with a JW Player's media hosting service quite a bit. A common task is to look up a video by its unique ID in the JW Dashboard. It requires a log in and would include the account number I use with them. The configuration could look something like this:

Name: JW Dashboard
Search URL template: https://dashboard.jwplayer.com/p/<account_ID>/media/%s
Suggestion URL template: <blank>
Keyword: jwd

And then in use it'd look like

jwd <tab> 1234abcd <enter>

which would take me to

https://dashboard.jwplayer.com/p/<account_ID>/media/1234abcd

• The Orion FAQ claims that other browsers offer only an illusion of privacy, but Orion itself (alongside Firefox, Chrome, Brave, so on...) offer no tangible protection against rogue/malicious extensions.
  • Widely used and trusted (at the time) extensions have gone rogue before, Stylish for example, started data collecting for every page accessed, to then sell that data to advertisers and "public data" collectors. Others like Nano Defender, used the data for themselves to hijack logins.

Read "Why Johnny can't tell if he is compromised" by Thomas Dullien, the points it makes gets across quick and easy; this is the rationale these suggestions revolve around. The underlying purpose of these suggestions: to lessen the issue of an inherent lack of trust within extensions, by shifting some of the trust to the user of the Orion browser.

The suggestions:

• 1. The permission system for extensions
  • Prompting the same way macOS does for sensitive permissions is likely easiest for users, beyond that I don't know what to suggest.
• 2. Have a rogue extension blacklist as a supplement to the extension permission system; all extensions must be verified by this in order to install, with the option to override this being intentionally cumbersome (macOS's Gatekeeper does this for unknown Applications). By cumbersome, I'm thinking of replicating how macOS has you open Security & Privacy to allow a system extension; Orion would tell you where this is, maybe even open to it.
  • If an internet connection cannot be established to verify the extension signatures, Orion would state this situation and not allow installation of that extension.
  • Idea being to not entirely trust Orion's extension permission system, as it being bypassed is a possibility.
  • This also prevents some user error that the less tech literate would be susceptible to committing, given they attempt installing a blacklisted (rogue) extension.
• 3. Provide the tools to tell if an extension is rogue.
  • Log as much as possible that's important, with each event timestamped. Domains and IPs (alongside ASNs if it helps) would be a good start, as that's what I've seen rogue extensions require (when they actually don't need this). Hopefully the logging can also catch a rogue extension escaping to the internet through hijacking a different installed extension.
  • This should be an easy to learn (and use) feature by default, but not restricted enough to be security theatre.

Need a microphone indicator when a website is using your microphone.

It should be shown on the left of the sound icon preferably.

State Partitioning

For background, see Brave blog post or Mozilla post

These are about preventing the sharing of any kind of state between two sites, which can provide a conduit between them for tracking or correlation of a user.

Test is to attempt to do a set from one first-party domain, then do a read from a different first party domain - there should be no sharing of state between the domains in these tests. The obvious trade-off is you lose benefits from caching on first visit to a site, and likely use more storage space on-disk with caches of the same content per-site (unless you build a smart overlay that then has a shared cache, but denies knowledge of an entry until it's cached... Which would be a bit complex to build I suspect).

Clicking the titles of tests on https://privacytests.org/ gives a small description of each, and clicking on a tick/cross shows the JS code used to do a test (generally).

In a loose priority order:

Delta against Safari

(These should be reasonably feasible, and are implemented in other browsers)
[ ] localStorage
[ ] XHR cache
[ ] CSS cache
[ ] Fetch cache
[ ] Font cache
[ ] iframe cache
[ ] image cache

Delta against the "ideal"

[ ] Favicon cache
[ ] prefetch cache

Navigation Tests

Delta against the "ideal"

[ ] sessionStorage (basically a per-tab session storage API that persists if you visit another site in the same tab) - this should be easy enough, as it should just be like visiting a site in a fresh tab.

HTTPS upgrading

(Trade-offs being that it attempts to load everything over HTTPS, which could result in a lot of failed requests, most likely)

There's an HTTPS mode in Orion, it didn't seem to pass this test for some reason, and I had it enabled for the test.

Delta against ideal world

[ ] Plain HTTP site
[ ] Auto-upgrade the URL bar entry to HTTPS where possible
[ ] Auto-upgrade clicked hyperlinks where possible
[ ] Auto-upgrade images in pages where possible

Other

There appears to be some standard called GPC that they look for implementation of.

A couple of other misc ones that maybe don't make sense to implement:

[ ] Blob URL (this seems a bit excessive to not permit them to be used at all, if that's what is being suggested... It's not clear)
[ ] document.referer (cross-domain, only the main domain is passed as referer, but I assume the test looks for an empty referer to be sent. Would this break sites?)

Most of the rest of the "gaps" look to be quite subjective, and would be for avoiding fingerprinting, while trading off compatibility with websites, so are probably worth revisiting separately.

https://www.webmproject.org/detect/ reports pic related (not supported) are there any plans to support WebM playback in the future?

Thanks, browser is off to a great start.

Safari and Chrome-based browsers offer the option to interact with the downloads straight from the browser.

What I mean by this is, in e.g. Safari you're able to click on the downloaded file to interact with it. You may move it to Desktop, open it with the browser, etc. See the video below(safari):

Let me know if this feature needs further clarification.

Steps to reproduce:
Open Orion and browse, leave it open for days, quit and relaunch.

Expected behavior:
uBlock Origin should autoupdate to the latest version but does not (both from Firefox and Chrome store). I have to uninstall and then reinstall it. It's my only extension which the developer updates frequently, so I can't tell if other extensions are affected (Simple Translate, e.g.)

Orion and macOS:
Orion 0.99.108.1-beta (Webkit 613.1.10)
Mojave 10.14.6 (18G9323)

Image/Video: