221–230 of 263 posts
It unfortunately requires an account to use the browser at all. A browser, un no circumstances, should be log-in walled. Seemed like a great user experience as a browser, but unfortunately I uninstalled it as soon as I launched it to a sign in screen.
Why? Not that Arc does this, but in today's modern world, we're two device creatures; a smartphone and a laptop. How do you connect the two if not with some sort of login?
Earlier quoted context omitted.
>I've been hearing about this browser and how excellent it is from real people, or probably-paid articles on tech blogs?
The Youtuber MKBHD has a podcast[0] where they have mentioned that many in their office has switched over to it. I'm not sure I quite understand their enthusiasm for it, but I don't think they're paid shills. [0] https://www.youtube.com/channel/UCEcrRXW3oEYfUctetZTAWLw
maybe not everybody who says arc is good is being paid to say that. but they are all people who accept money to say things like "arc is good". MKBHD included.
I've used Arc probably 90% of the time for the past two months. One thing that I haven't seen mentioned anywhere (even in their literature): it's very lightweight on memory usage. I've noticed recently that Safari uses 1/3 to 2/3 of a gigabyte for each youtube tab, or gmail, or . Arc uses roughly 25% of that. Also, Arc's efficiency as tabs build up seems to grow faster than Safari's although that's harder to quantify…
And I'm not alone either, looking at Reddit & Discord in the past.
Made me also switch away again recently. Would love to see them focus more on that instead of all those gimmicks. (Actually expected that before seeing them ship 1.0.)
Also, the way they handle extensions and especially the recent changes getting rid of the extension bar top right are/were also not great.
Earlier quoted context omitted.
The design of “passwords” on the Mac and iOS doesn’t make it seem like anything is a “safari” password. You save a password to the keychain in safari, and then you go to the “passwords” system preferences panel and you see those passwords. Or the other way around—creating a password from system preferences makes it accessible in browser. It appears on the surface to just be a password app, not a safari bucket. It als…
Safari uses the Apple bucket, that is also exposed through the Apple's Chrome extension and also when you go to System preferences Passwords pane. When you view passwords in Orion, you are also viewing passwords saved on Keychain, just in this case Orion's bucket. There are various system API's that allow apps to read from each other's bucket (obviously all Apple apps have access to Apple's keychain bucket). This is…
Earlier quoted context omitted.
This is great, with the one big annoyance that they don't use the actual native iCloud password keychain (and so, for example, can't interop with how that's also used to auto-fill passwords for apps on iOS, not just websites).
That is a deal breaker for me. I use auto-fill extensively and my browsing is 50/50 Mac and iPad so having a separate set of passwords on Mac and iPad is super annoying.
Earlier quoted context omitted.
Anyone, including you, can check that is not true. That is the beauty of a zero-telemetry claim.
its closed source...
Earlier quoted context omitted.
yes, but you can analyze the traffic from the app if you cared too. the point is that you absolutely can verify their claims.
I’ve worked on projects that logged locally and only transmitted every ~60 days when they detected the right network (eg public wifi). So unless you monitor it continuously and permanently this isn’t true.
Want vertical tabs? Vivaldi. Side bar? Vivaldi. Workspaces? Vivaldi. Mouse gestures? Vivaldi. Vertical space? Vivaldi. Customizable speed dial? Vivaldi. Keyboard commands? Popout mini-browser? Encrypted sync? Page tiling? Chrome extensions? Multiple types of tab groups? Excellent tools for inspection, screenshotting, etc.? Total anonymity? Everything comes up Vivaldi.
And what's more, Vivaldi actually works for the USER. They spoof their ID (due to Google sabotage) that lets us use Bing Chat without switching to Chrome. They don't even ask for your email address, unlike Arc. They'll GIVE you an email system for free. Vivaldi's openly committed to rejecting Google's Manifest v3 that cripples user control over what information is collected by Google and what extensions a user can use in their own browser.
And yet Vivaldi receives virtually no attention or praise. And Arc has been showered with it for years, despite never shipping a product until today. It's... very strange. This browser is everything I could ever dream of, and it doesn't get a fraction of the attention that Firefox, Brave, or Chrome gets.
Link for Vivaldi, from the same people behind the original Opera: https://vivaldi.com
Earlier quoted context omitted.
Safari uses the Apple bucket, that is also exposed through the Apple's Chrome extension and also when you go to System preferences Passwords pane. When you view passwords in Orion, you are also viewing passwords saved on Keychain, just in this case Orion's bucket. There are various system API's that allow apps to read from each other's bucket (obviously all Apple apps have access to Apple's keychain bucket). This is…
While I started this by giving you the plug .. the lack of it being the same password bucket combined with not getting 1Password to play nice, is what prevents me from making daily use, or rolling it out across my engineering employee base. I really like it otherwise.
Earlier quoted context omitted.
As I understand, Arc doesn’t use the UI framework that’s baked into Chromium and instead uses SwiftUI. To facilitate a Windows port, they’re building on existing community work to write a SwiftUI implementation for Windows. Following this if they were to port to Linux they’d probably write a GTK-based SwiftUI implementation, or if they wait for Swift C++ interop perhaps a Qt-based implementation.
> To facilitate a Windows port, they’re building on existing community work to write a SwiftUI implementation for Windows. Can you expand on this? I haven't the foggiest idea how this would work in practice.
The SwiftUI API is mostly "just" a DSL built with result builders[0] and should be reproducible without too much trouble. The harder part is reimplementing all of the behavior concerning diffing, rendering, etc, and actually drawing the widgets. Last I knew, their plan is to use community built WinRT/WinUI Swift bindings (perhaps this[1]) as a starting point to marry native Windows widgets to their recreated API. It may be necessary to write some widgets from scratch though, because there are several types that WinUI currently lacks.
It's a gargantuan task they've taken on, but I'm watching intently because despite being the world's most popular platform, the native Windows dev story is currently pretty underwhelming.
[0]: https://www.swiftbysundell.com/articles/deep-dive-into-swift... [1]: https://github.com/ericsink/SwiftWinRT