g_p

119 ms·

721.
by g_p 6y ago
> Apple could create a "kid mode" that you can enable on your less technical family members, it could require someone else to authorize "unsafe" activity. There are solutions and is obvious that if the solution is for
722.
by g_p 6y ago
Secure boot has, for the most part, prevented the underlying system from being compromised by malware that can run before boot (and therefore hide itself from the OS). I don't think we can really prove a negative here, but it means no
723.
by g_p 6y ago
Secure boot will ensure the bootloader binary itself is signed, but won't do anything for the config itself for obvious reasons. I was working on a high assurance scenario though, so I think my meaning of tamper resistance differed sig
724.
by g_p 6y ago
Totally agreed on the reduced cruft - when I was modifying the codebase I felt quite comfortable with the code and it's readability. Despite it being someone else's code, it was understandable and intuitive and I felt at home with
725.
by g_p 6y ago
I think you're right here, and I worry we are overly compartmentalizing security away from engineering. Ideally you should be both. One of the issues I see is that (at least in my experience), security isn't too bad to get up to s
726.
by g_p 6y ago
I'll second this. So few organisations have dedicated security people at the time they need it most! Since we're on HN, it is maybe worth looking at startups, and how few early stage ones build with security in mind at the time. I
727.
by g_p 6y ago
I see where you're coming from here - to my mind there's 3 issues here. 1 - The increased complexity of the UEFI stack having many components, and no good simple explanation of it to bring people up to speed with (at least that I&
728.
by g_p 6y ago
Honest question - is it really significantly easier to prevent tampering with systemd-boot? I had a look at this recently, and ended up having to modify the source (admittedly quite easily though) to avoid relying on important parameters in
729.
by g_p 6y ago
For anyone looking at how to mitigate against this, a "defence in depth" approach using grub-mkstandalone [1] has always been wise. If you're building an appliance-style system, or just want to prevent abuse of Grub features
730.
by g_p 6y ago
Regarding 3, I think a lot of this stems from ARM not using standardised interfaces with discovery of peripherals. Historically, board configuration ended up "compiled into" kernels and bootloaders. Device Tree (DTB) has made this
731.
by g_p 6y ago
There's actually precedent for this - sci-gen got papers accepted in IEEE and Springer publications, through peer review, and they had to investigate their back catalogue to look for others. Given the propensity for academic writing to
732.
by g_p 6y ago
For anyone wanting to try this, it is pretty straightforward - first install noise-suppression-for-voice (AUR package available, binaries available via Github releases). You want to have librnnoise_ladspa.so and librnnoise_lv2.so available.
733.
by g_p 6y ago
Another issue I've seen is people using their device's built-in speaker and microphone (to form a loopback-fest) that the onboard echo cancellation tries its best to deal with. I think there's certainly a part around "bu
734.
by g_p 6y ago
Agreed, but now this has piqued my interest in a good way. Having two instances loaded might be a bit confusing as you say - I imagine it would need to be something like "NoiseTorch for Recording" and NoiseTorch for Playback. I&#x
735.
by g_p 6y ago
Looks excellent and keen to delve into the code a bit. One quick question since you'll clearly know the codebase - do you think this could easily be adapted to create a "playback-side" noise filter? Use-case rationale here is
736.
Facebook can no longer rely on Standard Contractual Clauses for US data transfer(noyb.eu)
3 points by g_p 6y ago|0 comments
737.
by g_p 6y ago
Indeed - standardisation is adopted as it helps drive more handset sales and stimulate consumer demand. But standardisation is eschewed even in 4G and 5G when it comes to the equipment deployment - everyone is trying to build their "mo
738.
by g_p 6y ago
I was involved in designing a POC that proved this many years ago now (but after Doze appeared on Android, causing power saving issues). Note this was all for Android though, and I think Apple's restrictions make it very difficult to d
739.
by g_p 6y ago
Indeed, PGP smartcards should work too, as should cards using the open-source ISOApplet. I also played around with tpm2-pkcs11 last year and it worked nicely, and has support on a lot of devices like the XPS (which works really well on Linu
740.
by g_p 6y ago
Yes - as the other commenter mentioned there are some docs from Yubico. Also worth looking at PKCS11, as this lets you do HTTPS clent certificate authentication, as well as SSH. And it's all standardised too under the PKCS11 standard,
741.
by g_p 6y ago
For anyone interested in a standardised/Linux-compatible version of this, check out PKCS11 tokens. Smartcards can and do implement this spec, and if you use PKCS11, the secret is used from the token to sign an SSH login (for example),
742.
by g_p 6y ago
I've seen something not too far from this done in rural areas in the UK. It's not illegal - in fact, it receives public money via broadband vouchers! Direct-burying of fibre in the countryside is cheap, doesn't require permis
743.
by g_p 6y ago
Sounds like a home cinema system is also affected by a similar issue - https://eu.community.samsung.com/t5/Audio-Video/HT-J4500-hom... First thought coming to mind is if this is indeed a bad firmware update as som
744.
by g_p 6y ago
The EU's new antitrust investigation [1] might be close enough to a monopoly suit, just likely to be slower and more drawn out. It had the desired effect against Internet Explorer though last time around, I guess. Relevant quote from i
745.
by g_p 6y ago
I think the point here is that on iOS, compiling/running/making it work requires an entitlement (i.e. permission) that is granted only to those who are signatories to Apple's agreement on getting access to the Covid API. See
746.
Apple Rejects Appeal of Email App That Blasted Store Rules(bloomberg.com)
41 points by g_p 6y ago|37 comments
747.
by g_p 6y ago
Interesting - every version I've looked at to date still creates a form of "infected list". You could try bloom filters but at risk of many false positives, at a time you really don't want false positives. Looking at the
748.
by g_p 6y ago
I think the difference here is that Apple is the only retailer for someone to install an app onto an iOS device. It prohibits anyone else from setting up a retailer, through policy-based (not technical) restrictions. You cannot install an
749.
by g_p 6y ago
Apple's claims of a "free ride" frankly seem ludicrous. There seem to me to be 3 issues at hand here. 1. The magnitude of the 30% charge, and the level of justification this has. 2. The ability for Apple to itself be a provid
750.
by g_p 6y ago
And the EU has opened an antitrust investigation on this precise topic (and on their reserving the NFC hardware for their own payments service, which also extracts a fee, as I understand). This strikes me as textbook antitrust matters, that

More ›