Our mission is to give everyone the power to customize their technology to have the perfect UX. Our first product is a low-code browser extension builder (open-source under AGPLv3)
We recently raised a 3.5M seed from New Enterprise Associates (NEA)
Our mission is to give everyone the power to customize their technology to have the perfect UX. Our first product is a low-code browser extension builder (open-source under AGPLv3)
We recently raised a 3.5M seed from New Enterprise Associates (NEA) and some incredible angel investors including Tableau co-founder Chris Stolte and DataRobot CEO Dan Wright
Open positions:
- Product UI/UX lead (UI/UX designer who can code)
- Community/education lead
- Senior Backend Engineer - API/platform lead
- Senior Front-end Engineer
Our mission is to make it possible for everyone to customize the web to fit the way they work. (Think browser extensions and userscripts, but using sharable lego blocks)
Come be a founding engineer at a company backed by a leading VC and execs of major AI, business intelligence, and edutech companies
Open positions:
- Senior Front-end Engineer
- Senior Backend Engineer - Platform Lead
- Mid-Level Web Designer/Developer
Not an expert on this part, but I'd imagine that problem isn't having an API, it's more that running native executables is the problem if you can't sandbox them or limit their resource consumption. Also, relative to running Javascript, their base resource utilization per tab is significantly worse (especially for Java or .NET-based ones that have a base resource utilization from the VM)
The safety/stability issue comes from the fact that plug-ins (e.g., NPAPI) are native executables
Browsers started dropping support for plug-ins around 2015. However, plug-ins actually held on longer than you might think. Firefox didn't completely drop support for Flash until the beginning of this year
The timeline of browser extensibility is quite fascinating. There's really not a single place that covers all of it, so I decided to research my own timeline/history:
- Consumer web browsers (1993-)
- Plug-ins (1995-2015ish)
- User Style Sheets (1998-2019)
- Bookmarklets (1998–)
- Browser Extensions (1999–)
- Mozilla XUL (1997–2017)
- Alternative Browser Distributions (2004–)
- Userscripts (2005–)
- Converging on the WebExtensions API (2017–)
- Manifest V3 (2021–)
- No/Low-Code Browser Extension Builders (2021–)
What is the goal of this group since the current WebExtensions standard is already supported by almost every major web browser? If seems their goal is already complete.
Ok… but the following topics in your list have nothing to do with an API specification, which is what they say their goals is on the Goals section:
>
“A few UI differences between chrome's extension popup and firefox's one means you'll need to potentially leave out features for one browser.
- UX differences between browsers means you'll need to write extra code, and maybe a few extra tutorials.
- Huge huge difference between publishing on chrome vs on firefox
- Safari requires xcode, and therefore macos to publish”
Bottom line is I don’t think there is going to be an api standard around “distribution and publishing areas”
Plus, you probably still need a Mac or a virtualized Mac (for automated tests, for example) because you’ll want to test your extension with Safari to ensure it works correctly.
I don’t get your comment. You just confirmed that, indeed, you need a specific computer to publish Safari extension, which isn’t the case for Firefox and Chrome extensions.
It is a limitation and it’s completely unnecessary for the end user.
If they’re so lazy to have a extensions-specific store they could at least offer an automatic wrapper that they run before publishing. I should not need XCode anywhere in my build to publish web extensions.
But you need Safari to test the extension and Safari only has these extensions on a Mac? This is Apple’s way of avoiding their store getting cluttered with extensions that haven’t been tested to work on Safari. And yes, it also encourages developers to buy Macs. It can do both…
Can you explain what you mean by “literal dumpster fire” because this doesn’t align with my own experience. I’ve used it for purchasing a number of apps recently and I saw nothing eyebrow-raising. So long as the app you want has been uploaded to the store, it works perfectly fine.
That’s true of pretty much any App Store that isn’t strictly invitation only. If you have an app follows Apple’s rules, it gets listed. Whereas Steam, by comparison, exercises editorial control over all of its content. The solution for a better Mac App Store would require Apple to be similarly dictatorial about content.
In that sense I agree with you; personally I think it was a mistake of Apple to have the Mac App Store so closely mirror the iOS App Store. They should have made it a more aggressively curated experience.
And before anyone claims u can just buy time on a cloud Mac... The cost for these and requirement from Apple for a min. period of 24 hours rental (something to do with Mac stadium?) mean you're funneled towards making the $2000 "investment" in a iDevice.
If you can't afford to cross-browser test, and you don't have a Mac, I'm not sure why you're building an extension for a Mac-only browser then? Someone has to test it on a Mac, register for a certificate with Apple, etc. In the end, buying a Mac is the easy part?
And there are services like https://www.browserstack.com/docs/automate/selenium/add-plug... where you can basically rent Mac VMs on cheap monthly plans. Or GitHub Actions, as I pointed to earlier, has a free tier with free minutes on an automated Mac terminal.
On one side Apple says they now offer a compatible API, on the other side you’re telling me dropping a minimum of $800 on a computer (+$100 annually) to release a free extension is the easy part.
BrowserStack would be a good solution to test it, but unfortunately you also need a lot of preparation and XCode-specific knowledge to even get to a testable point, which you don’t get unless you own a Mac.
The browsers that Apple claims to be compatible with don’t require anything more than WinZip.
Apple added requirements for their store to publish extensions, yes. They also added more privacy prompts. If you don’t test on MacOS in Safari, how would you know if your extension works correctly?
Why not ask Apple to release macOS for any computer like Windows on x86? Why not ask for Safari to be published for and API compatible with Windows as on macOS? Why not ask Apple to ship Windows since mac-only APIs would be problematic?
Fact is, Apple requiring a Mac to publish for a Mac-only browser is not a problem. It’s not even true. You can code sign for Mac from Linux[1], as I understand it. Worst case, a third-party service will step in to handle packaging and publishing the way we already do for cross-platform native apps and yet Apple will continue to expect devs to test on their Apple devices.
I can run Firefox or Chrome on my Mac so it’s not like I’m missing out if you choose to not develop an extension for Safari and test it in Safari. I feel like you’re arguing that testing isn’t required if you have the right web standards, which is pretty much always false when there are privacy or other implementation details that vary by browser…
Chrome published the WebExtensions API, not Mozilla. Whether or not it’s a standard is another question, you could call it a defacto standard, but Chrome definitely implemented the api that they published.
Except Apple who don’t have the incentive of browser advertising and are currently selling privacy as one benefit of choosing their hardware (and by extension their software and browser [safari])
Mozilla make money from Google deals and so have outside incentives to not rock the boat too hard on this detail.
As always its about control. Its a fight against general computing.
The goal is deprecation of "remote code" execution, where "remote" means remote to Vendor, but local to user, aka anything not shipped and signed by the extension store.
Yep, the first style manager extension was released in 2005 (Stylish). Style manager extensions are a much more frictionless way to manage and share styles
I suppose you could link to the adoption and decline of methods of running code local (instead of remote) such as JavaScript, Adobe Flash, etc.
But I also think its interesting to note how browsers became suits including a chat and mail client (protocols such as POP3, SMTP, IMAP, NNTP, IRC, FTP, etc) to focusing on WWW only (HTTP). Heck at some point browsers even had LDAP support for things like bookmarks and settings.
According to the spec, Bookmarklets should actually be exempt from a site's CSP. The reason is that the user's preferences should take precedence over a site's preferences
And as far as I can tell, they should be. They're a natural intermediate step between nothing and extensions, and there's not really security problems they have that extensions don't.
If there's a problem here, it's that browsers (some, at least) aren't following the spec.
Yeah, what? I actually have a client that relies on these for some stuff I wrote for them, guess this means I'll have to rework it, but if they represent a security concern then I guess that's all there is to it
They don't represent any more of a security concern than an extension, or even a browser.
The real reason they'll stop working (if they do stop working) is that it would be extra work for browser vendors to maintain and "pfft, power users? what are those"
As others have noted, according to spec, it's not supposed to but in practice at least some browsers apply the CSP to them.
Something I'm not clear on is whether the CSP spec says it shouldn't apply to any bookmarklet or if it only shouldn't apply to bookmarklets that don't request resources from other domains. That is, CSP shouldn't prevent a bookmarklet's own code from doing things like adding/removing attributes to elements but if the bookmarklet tries to load other files (more JavaScript, CSS files, images, etc.) then the page's CSP should apply.
To me, if a browser extension can run, a bookmarklet should also be able to run; a difference is the bookmarklet will only run once when it's clicked and will always clear from memory when a new page is requested.
Both extensions and bookmarklets pose some risk to the user but it's a worthwhile trade-off. If bookmarklets started to become a problem (remote resources being replaced will malware), maybe restrictions would be necessary, like all links to remote resources requiring valid subresource integrity hashes.
A browser's built-in Reader Mode (Safari, Mac and mobile, Firefox, Edge's Immserive Reader, Chrome has one behind a feature flag) can be very helpful when they work. A better solution is probably one of the browser extensions, like Stylus [0], that enable not just a single user stylesheet but the ability to have custom stylesheet's on a per-domain basis. On top that personal customization, they can load stylesheets others have already created and shared on userstyles.org [1].
What if you could customize any web app to provide the perfect user experience?
Open positions (learn more at https://careers.pixiebrix.com/positions):
Email careers@pixiebrix.com. We're Series A startup backed by NEA. Fully remote within ±3 hours of Eastern Time