@kieran Yes, we discussed the track button issue before; I just felt that it deserved to be on the list because it should be considered as a shipping option.
Hopefully the plugin mic on Librem 14 will be wired to the same mechanical kill switch as the environmental mic. It’s architecturally obvious but easily forgotten.
More slow cores would indeed be lovely. More fan noise necessitated by overpowered CPUs – not so much. So I’ll take whatever I can get within a miserly TDP envelope, ECC or not. Bonus points if there’s an option to buy it with underclocked memory as poor man’s ECC.
Whoever solves the MAC problem, be it in hardware or software, would be a hero, but it can’t be a solution where the wifi powers up and in any way broadcasts its default address before later pretending to be something else. I hope Purism puts some deep thought into this. It’s a major selling point.
All in all, thanks for the detailed feedback. I’m more optimistic now about the next spin of this laptop.
I agree with most of the things. Particularly, the screen is absolutely magnificent.
The camera is not super great, though, not as crappy as the one in the Acer laptop I had before this and some other laptops I’ve used.
I find it more blue-ish. Would have preferred purple myself, but…
Nah. I kind of like the feel of the keyboard. And love how it actually has a numpad unlike many other small keyboards. And the F-buttons work as F-buttons and are not some weird media keys b default. No really glaring inconsistencies—e.g. my Asus laptop has a dedicated “home” key but not an “end”! this is so frustrating.
Another thing I like about the keyboard is that it’s easy to clean. There are no ridges (besides the outer bevel) for dirt to get stuck behind or between.
I do agree with this. Would have been nice to have this under the Fn-arrows instead of sound volume setting.
It could be more user friendly but this is possible with some network-manager deep settings. We discussed this at some point here: PureOS default hostname?
The thing is, you want to be able to set this on a per network basis, to avoid running head-first into MAC filters.
Isn’t this a direct consequence of the tamper-resistant sealing? Can have it one way or the other
Keyboard illumination with any sort of blue component is philosophically incompatible with nighttime computer use, as it destroys melatonin and inhibits sleep. So does the screen, and much moreso, but that can be managed with one of the various blue dampeners available on Linux.
Definitely, we need PgUp, PgDn, Home, and End. If there’s no space for dedicated keys, then at least Fn+(arrow). Another option is to make it so that Shift+(NumPad) doesn’t toggle the NumLock state, so you can actually have Shift+Home work as “select to start of line”, for instance, instead of reverting to “7”. Surely, there’s a software solution to that, but I have no idea how to implement it.
Thanks for the link back to the discussion about MAC manipulation via the network stack. I do think there needs to be a straightforward interface for toggling MAC randomness, be it in a mechanical switch or via the UI. Again, the software approach is tricky because it needs to happen before the MAC address can be broadcast, as could happen for a variety of reasons during startup. I don’t care if this breaks all the MAC filters out there. Let the IT people discover that it’s misguided policy.
I guess you’re right about the electronics stench. At least it goes away after a week or so. (And one could just run high workloads overnight to accelerate the proecss.) Tamper-resistance takes priority.
TIL this is a thing at all On my (Ubuntu) desktop’s keyboard this goes only one way. When in number mode, Shift-Key selects home, arrows instead. When in arrow mode, Shift doesn’t enable numbers. On the Purism it’s as you say. Weird.
Yes, you have a point, though the added complication of having to design custom WIFI hardware and firmware is a hard sell. In the long run hopefully WiFi is available as open hardware and this will be less of an obstacle. Integrating a FPGA based SDR that happens to be able to handle WiFi would be kind of badass—but is expensive and might run into regulatory issues in some countries…
Mind that everything the card actually does: enabling the antenna, scanning for available networks, connecting to a network, is initiated from software. In many network drivers it’s even the software side that takes the MAC from the card’s EEPROM and sets it.
So then the software side does have a window where a MAC can be set without chance of the original identifier leaking. But it does have to be carefully designed—which would be true for a hardware solution as well!
I understand their side as well. Even on a large home network it’s nice to be able to know what devices are active, say to be able to diagnose bandwidth issues when my boyfriend’s new game console is trying to exfiltrate terabytes of data
Randomizing MAC seems to be something one’d want 1) before connecting to any network, and 2) for public networks. So having said that, maybe having it on by default isn’t a bad idea for privacy.
I don’t think that works. If the HKS works as advertised then the WiFi will be dead as a dodo. So you can’t send it any commands e.g. to override the MAC address. As soon as you flip the HKS, and give power to the WiFi, it could in theory leak its MAC address.
So as far as I can see, three safe options are:
the WiFi card has non-volatile storage for an overridden MAC address that can be rewritten many thousands of times
the WiFi card guarantees not to transmit anything after power on until the operating system has had a chance to configure a random MAC address - but as noone controls the firmware of the WiFi card it would be difficult to accept such a guarantee
the WiFi card powers up with no MAC address (let’s say 00:00:00:00:00:00) and simply doesn’t have a realistic address to leak until the operating system sets the MAC address - but the WiFi card does provide some means of at least supplying to the operating system (at least) the top three bytes of the MAC address.
@vmedea Good find! That page you linked has all the details on how to fix the issue. Would be nice if the next PureOS spin just enabled the “Microsoft” behavior by default.
@Dwaff Don’t worry. Less bluish hues on the keyboard LEDs won’t make you fall asleep! It’s more that they won’t inhibit sleep. This is a serious issue that Apple, Android, and others have tackled pretty well.
@vmedea@kieran Thanks for bringing up all these annoying nuances around MAC initialization and randomization. This is a MAJOR privacy issue that needs attention and deep thought from Purism. I trust that they’re reading your analysis and considering the tradeoffs. Ultimately, I would think that software-defined radio would be the answer, simply because it promises to do for wifi modules what FPGAs did for ASIC design. But I realize we’re not there yet, and for the time being, prefab wifi modules are still the norm, which constrains the solution space and introduces the potential race conditions above. Random MAC by default would be so lovely.
@kieran Kudos for finding out that Librem 14 will already have my microphone wish list item. My motivation to invest in some other brand of laptop is decaying by the day.
Do note though @vmedea’s comment above that SDR for WiFi may run into regulatory issues, either now or in the future by the time “we” could get it working.
I agree, mostly, with the keyboard, fan, and memory part. As for keypad with buttons? It’s 2020, trackpad buttons went away with the physical keyboards on phones. It’s also visually horrendous; Jony Ive would be horrified. Since it’s mentioned to look at how other vendors do it, that should include the trackpad, too - which many don’t use anymore.
As for keyboard color, I’d opt for a softer blue or red for an easier transition from looking at the keyboard to the screen - since there are odd key placements. Aesthetically, orange contrasting in the dark is like a karate chop to the eyes.
I don’t mind PureOS, but I prefer another distro - which works fine. I wish I could update the BIOS without having to log into PureOS. If I have to do it from another distro, I usually have to pull the update line out of the script to run it. Otherwise, it fails for the reason “${software} isn’t installed”.
@kieran The answer to regulatory issues is to receive the laptop in a less regulated country. Of course, doing that virtually guarantees shipping interdiction (per Snowden), and I’m not totally sold on the concept that glitter nail polish is a sufficiently robust countermeasure. It’s something to consider in the context of MAC randomization. That’s why I would accept a hardcoded selection list of nonneighboring MACs as a fallback. I don’t see how that could be a problem, at all, considering that MAC ranges are assigned on a per-vendor basis. It would likely be worth Purism joining an industry consortium just for this purpose, if necessary.
@tzoi516 There are good security reasons for having trackpad buttons, mainly with regards to the elimination of misinterpreted gestures, such as dangerous middle-click-paste that can’t always be disabled, which result in unwanted behavior. I’m only proposing it as a build option, as trackpads are cheap and often interchangeable.
Note though that my comment about regulatory issues was specifically and exclusively referring to SDR. There may be other regulatory issues with changing the MAC address - although I don’t think that is the main focus of the authorities at the current time. (I think the main focus is the IMEI.)
while testing an external usb-C (3.0) to RJ-45 (10/100/1000 ethernet NIC) addapter i had to call my ISP to be able to access the www again (when reverting to the integrated LibremMini NIC for www access)
@kieran That’s an important distinction, and I suspect you’re right, simply because harvesting MACs requires hacking all firmware for all routers on an ongoing basis (big boys’ club only), whereas harvesting IMEIs just requires sending Uncle Boris and his brass knuckles down to the local telecommunication company headquarters. So for fck’s sake, let’s have as much randomness as possible, provided that it still looks like a credible address from a real manufacturer. Fine by me if it’s disabled by default.
Just a side note… I discovered that the mechanical switch behavior is different for camera/mic vs. wifis. While the wifi switch will kill all wifi devices plugged in, the camera/mic switch won’t cut off a USB mic – just the onboard. I don’t consider this a design flaw, necessarily, but it’s an asymmetry to be aware of.
Try opening at least a 13v3 at the corners. You can’t even get a grip despite in the middle. I for myself always acted carefully with my laptop. Never physically stressed it. Always opened in the middle. When the left hinge broke loose at the display-side i even managed to quickly stop the movement after only opening the lid for well less than 10cm. So after experiencing a broken lid myself, i can not agree with your assumption. The reason in my case were either: Increasing resistance in the hinge itself and/or weakened fixpoint in the display (plastics i assume).
But i think, it’s nothing to worry about. On one hand Purism’s support is(was for me) top notch for such a small company. On the other hand - if i remember right - Purism changed the manufacturer once problems were observed.
@kieran Yes, the wifi kill switch kills USB wifi, but the mic kill switch doesn’t kill USB mics. Obviously killing specific classes of USB devices is a software thing, so there’s a good second of latency involved. It’s weird to have this USB policy schism, but it is what it is.
@ajlok Thanks for the update. I’m glad that they’re aware of this and seem to be taking mitigation action.
It sounds like a specification or implementation bug/feature to me.
That said, it is more complicated to software kill a USB device because a single USB device can have multiple functions. You aren’t killing USB devices by class. You are killing endpoints/interfaces of USB devices by class.
For example, on the computer I am sitting on at the moment, there is a USB device that combines a speaker and a microphone and a volume control. So at the USB level, it shows up, at the very least, as a sound source and a sound sink. If the operating system wanted to kill the source source (the mic), it can’t just disable the whole USB device - and ideally it would kill the mic while ensuring that there was no disruption at all on the speakers.
@kieran Well said. I know better and should have been more pedantic. But yeah, it looks like inconsistent policy design. Way below other privacy enhancements, though, in terms of priority. I want my random network addresses, dammit.
On my (Ubuntu) desktop’s keyboard this goes only one way. When in number mode, Shift-Key selects home, arrows instead. When in arrow mode, Shift doesn’t enable numbers. On the Purism it’s as you say. Weird.
