I tried this out today and it doesn't seem to work for me, because it only considers relative urls to be "internal." If the urls are full urls (https://domain:port/...) then it won't work. It seems like it should be able to use window.location to work out that these full urls are also "internal" as well.
Thanks for the report! This is now fixed in v1.4.4.
µJS now resolves URLs using the native URL constructor and compares origin against window.location.origin. This means all same-origin URLs are correctly recognized as internal:
- Absolute URLs: https://domain:port/page
- Relative URLs: ../page.html, page.html
- Local paths: /page (already worked)
Hash-only links (#section) are intentionally left to the browser for native anchor scrolling.
Thanks for the report! Using fully absolute URLs for internal links is not a very common pattern, and this hadn't been raised before. That said, it's a valid and interesting use case, I'll add it to the roadmap. In the meantime, using root-relative URLs (starting with /) is the recommended approach.
Why would AI generate source code? Why not generate binaries directly if no one will read it?
These days, I worry less about my code containing slop, and more about dependencies I use becoming slopped. I worry about AWS, having a great track record pre-AI-layoffs, now having outages three times in as many months. I can eschew the slop in my own projects, but as this article points out, we all use code and frameworks that we didn't write.
It might go that way - skip the higher level languages or an AI fit to purpose language. Right now we want to have a comfort feeling for being able to read the code if we need to. I would love to see a study of a year ago the percentage of code reviewed vs today’s AI generated code
>We, collectively, only have ourselves to blame, and now it's too late.
No, "we" really don't. I wrote software. It's free. You're welcome to use it, or not. Nobody is forcing my software on you. You are not allowed to tell me that the software I wrote, for free, and gave to you, for free, needs to have features that I don't care about.
You have an LLM now. I'm obsolete now, right? Do it. Build your nerfed distro, and make it popular. Oh, yeah... there isn't a single solitary disto built by an LLM, is there? Not even one. Wow. I wonder why...
I’m not sure why you’re bringing up LLMs at all. I’m very anti-AI, so you’re barking up the wrong tree.
Either way, your first paragraph is irrelevant. If your local law says that your software needs to obey some law, then it has to, and that’s that. You can whine all you want about privacy and freedom, but the law is the law.
Because lawyer types don't seem to understand they need us to write this for them and we can just say no.
>If your local law says that your software needs to obey some law, then it has to, and that’s that.
No, how it works is I continue writing free software and you're welcome to continue not using it. Take me to court with your law, and then be ready to pay legal fees and damages when I win because the law isn't constitutional on multiple grounds.
That's forced labor. I'm not required to write a line of code to please anyone. It's free software with no warranty. They have LLMs, let's see them build it. :)
Well, that's a 13th Amendment issue not a 1st Amendment one, but, in any case, its not forced if it doesn't direct who does the work to create the functionality, only requires you to have the functionality provided if you are doing some other activity, it is more of an in-kind tax. [0] (Now, if you want to make an argument that when the activity it is conditioned on is expressive that that makes it a 1A violation as a content-based regulation when the condition is tied to the content of the expressive act, that is a better 1A argument, that might actually have some merit against many of the real uses of, say, age verification laws; but “if I am doing this activity, I must either create or acquire and use software that has a specified function” is not, in general, a 1A violation.)
[0] It's not really that other than metaphorically, either, any more than every regulation of any kind is an “in-kind tax”, but its far closer to that than “forced labor”.
I can't really imagine stopping at a restaurant for a "snack" in the US, everything takes so much time. Even "fast" food is a 10 minute wait at a drive thru. Nevermind the absurd tip culture where the server/cashier now is offended by a 20% tip.
Lol, no, according to graphene, an aux jack is a security problem. So is a microsd. But the hole punch with the camera pointed at your face, that's just fine.
When my current phone dies, I'm basically returning to a dumb phone with a removable battery. Now that Xperia dropped open source, every phone out there is terrible and I just don't want any of them. Anything that would support a ROM has features to make my skin crawl.
Their hardware requirements do not say this, where'd you get that idea? Graphene has stated they'll work with the Motorola team on supporting their devices, starting with the successors of the Razr foldable and the signature line, but there really hasn't been any talk about how additional peripherals like aux would be a no-go. USB is also a security concern, which is why they give you the option to disable it outright, disable data or disable until after-first-unlock. I don't see what would keep them from implementing this for aux, although since it's unidirectional I'm not sure if it even makes sense to compare aux to USB. They've supported pixels with aux ports in the past, and I don't think it's inclusion would be a blocking criteria.
The comment about the camera is also kinda misguided. They zero out the camera input if you disable it, unlike traditional android. You can have a camera toggle in your quick settings and keep it disabled literally all the time. Enabling it when you bring up any camera related app takes either pin or biometrics, having the hardware here really shouldn't be a concern since you can look at how the code handling it works yourself.
I'm not trying to convince you to use a pixel or a Motorola phone, do what you want, but at least be informed about stuff like this when you state things as if they are facts.
> I don't see what would keep them from implementing this for aux, although since it's unidirectional
No electric circuit is unidirectional. Beyond the pause/play and volume commands that it supports (edit: and mic as mentioned in a sibling comment), Graphene would probably reason it's an easy way to externally read voltage levels and so an unnamed entity can mount side channel attacks with backdoored headphones
> since it's unidirectional I'm not sure if it even makes sense to compare aux to USB
Most phone aux support microphones and acting as an antenna for FM radio reception. I don't see how either could be used for a security exploit however.
>but there really hasn't been any talk about how additional peripherals like aux would be a no-go.
It's water under the bridge. You're NEVER getting a Graphene phone that supports a microsd. It won't happen. The AUX jack, you will biligerently be told to get a USB DAC or otherwise you are an old man yelling at clouds.
Graphene and Motorola will work together by happy accident. Tell ya what though, if they make a GrapheneOS phone with 3.5mm, dual sim, microsd, and >no notch or hole punch< and I will buy it. I won't even care how much it costs. All the Xperias I've owned were among the most expensive phones on the market.
It's unlikely for the Razr line to support microsd since those are foldables, and flagships like the signature line generally tend not to, but nowhere on their hardware requirements list does it say that a potentially supported device cannot have a microsd card slot, thats just wrong. There is nothing about a memory slot that would make the phone less safe inherently, they already support USB drives, internal emmc memory isnt that much more crazy than that, right? I just think its super weird to be like preemtively mad at them for an imagined aversion to supporting hardware that doesnt exist.
I get that the people involved with the project can be a little prickly when you ask them for advice about stuff, but what do you expect them to do here? They support the devices they do not out of some sort of adherence to a skewed model of security, they actually genuinely need the hardware to be able to do all of the things they ask for, which currently literally only the pixel line offers.
If a manufacturer like Sony who tends to do aux, microsd slots and no holepunch cameras were to adapt to their hardware standards (https://grapheneos.org/faq#future-devices) there would likely be an effort by people to get these supported, its not the lack of will from the devs, its the lack of support from phone manufacturers that has kept the line of supported devices constrained to pixels.
It sounds bizarre to me that an analog aux port is a security problem and that bluetooth audio is not, or that the phone's built in microphone is not. I never want to use bluetooth and tbh I've sometimes wanted a phone with no microphone, so that if I wanted to make a phone call I'd have to plug in my wired headset. That gets rid of the microphone as a listening device.
I haven't found a >=2025 phone (I started looking in the summer) with a headphone jack that I can actually use more conveniently than a tablet. Everything now requires two hands, not counting warrantyless china phones like the jelly star, or ones with a chipset that would have been considered fast in 2018
As for the camera, a webcam sticker seems much more convenient than needing to mess with the hardware internals
Sorry, that wasn't clear: I meant any phone that I can purchase as of 2025. I was looking for several months and made a decision about 2 months ago. A second-hand Pixel was a big compromise but I don't see another option
Do you also have thoughts to add or am I supposed to read and respond to 2000 words of material here?
The reason I'm looking at specs is not because I have no idea what I need. Not sure if there's another possible reading or if the link insinuates that. The software I use (e.g.: OsmAnd) is noticeably faster on more modern systems and was downright sluggish on my previous phone. I could buy my current chipset again, it's doable for now, but neither fluent nor future-proof. The chip's inefficiency also means it's completely empty after 2.5 hours of use (while I'm out mapping, taking notes, recording positions and sometimes pictures, listening to music... I ask a lot of the battery), whereas newer chips can do the same work with less energy
I also need a modern chipset for accurate GNSS. The phone I get from work has dual-frequency GNSS and makes razor sharp traces which are much more usable for my mapping hobby, especially in urban or forested areas or behind coated windows like trains or cars (car navigation isn't that niche, my current phone does a pretty poor job at that)
But yeah, let's not focus on specs. Who cares about any of this right? That's what I'd say if I sold a really basic phone
> Except there is also a microphone.
Respond to the person above. Hardware toggles wasn't my argument but theirs. Great that your librem has this but the thread is about GrapheneOS
Edit: lol that was yourself. You posted about a camera toggle, not me or anyone else
> Do you also have thoughts to add or am I supposed to read and respond to 2000 words of material here?
The idea is that relatively low specs do not necessarily mean low performance. It depends on the software a lot. For example, SXMo provides a smooth experience with maps and Youtube even on a Pinephone. The battery life may be a problem though.
> the thread is about GrapheneOS
The subthread you started is about a phone "with a headphone jack that I can actually use more conveniently than a tablet", so I thought I could intervene with some other options. I might be wrong though.
Does it? My banking works in any browser that supports javascript, and chatting has been possible on desktops (and laptops etc.) longer than it has on phones
Citation needed. A lot of dumb phones still only support 2g, for example, and you need to watch out that you don't buy a model that won't work anymore when carriers take that off the air. No smartphone hardware has that issue
I don't have social media accounts that require personally identifying information. If some place like here starts requiring it, I just won't come back.
