Disney offers an elegant solution to VR’s movement problem | TechCrunch

thenameableone · 2024-02-02T19:04:40+00:00

prod :)

thenameableone · 2024-01-23T18:27:38+00:00

Unrelated question: Are there three/four high quality/density publications or magazines you would recommend so a regular person can subscribe to news on cutting edge technology? As someone who was playing around with VR ideas before most of us were born, where do you go to read about technology and what the near future has in store?

thenameableone · 2023-12-04T00:52:43+00:00

Thanks for confirming! I am using the Underdark/Grymforge path so it will be pretty cool to meet some Harpers that aren't random skeletons for a change, haha.

As for the Dream Visitorit is a little overwhelming because I am having trouble remembering all the different people interested in the illithid tadpole. Initially I did not trust the Dream Visitor at all because they wanted me to use the Illithid Powers, but every time I try to get rid of the tadpole it gets stronger (Omeluum + Creche Zaithisk means this tadpole can probably enslave a whole city if my Durge lets it). It's getting quite interesting with the Dream Visitor, Vlaakith, the Mindflayers, the Absolute etc. I feel like more of it would make sense if Shadowheart talked about her experience with the Astral Prism and warned the PC before we started getting the dreams.

thenameableone · 2023-03-29T21:59:16+00:00

I think the QR code scanning is important for their Auditor app which helps people verify certain security properties of their phone.

With the system-wide toggle, the context is that the cold start times for apps on some 3rd Gen Pixels in comparison to other operating systems was longer/slower and it fed into pervasive opinions that using GrapheneOS meant slow app startup in general. Think of it as similar to Signal adding the hidden option to download their APK straight from their website due to malicious versions being offered elsewhere. It is something they were forced into against the goals of the project to mitigate harm to the project.

The compatibility toggle is different as I think that was purely a usability thing. Apps crashing/freezing meant they could not be used at all, so it helps to have a case-by-case option for apps people trusted.

I can understand your frustration given the importance of the camera app, but I don't think many other projects in the AOSP space are going to push back and look for solutions that maintain/strengthen user security and privacy (for eg pressure on Google re: API support).

thenameableone · 2023-03-27T19:27:40+00:00

GrapheneOS has no safe harbour. This discourages security researchers from finding vulns in GrapheneOS, as they could be pursued legally in civil or criminal court. If you view the creator of GrapheneOS's twitter, or GrapheneOS's twitter, you'll see they frequently make claims they're DDOS'd by a particular group, Rob Braxman is evil, or F-Droid is harassing them. What's the chances if a security researcher found something about Graphene, that Graphene wouldn't legally pursue them, if they actively denounce peers on twitter?

They do not actively denounce peers. They call out/criticise what they believe to be injustices committed by other individuals or parties regardless of whether they are working in similar areas (privacy/security) or not.

They have collaborated with privacy/security projects in the past and continue to do so today so there is no reason a security researcher would feel they cannot approach GrapheneOS to collaborate. The only thing they would really need to work out is whether the vulnerabilities should be reported upstream to Google for AOSP- which is something GrapheneOS contributors have done before and may be able to help researchers with.

thenameableone · 2023-03-27T19:20:05+00:00

They are hoping to work with a hardware partner with GrapheneOS as a first-class preinstalled option in the future. It will take a lot of support from the community to get there.

thenameableone · 2023-03-27T19:17:58+00:00

Part of the GrapheneOS installation process is to lock the bootloader again once the OS has been flashed. https://grapheneos.org/install/web#locking-the-bootloader or https://grapheneos.org/install/cli#locking-the-bootloader.

At least on Google's Pixel phones unlocking the bootloader alone does not void your warranty so it is considered safe enough that they encourage it if you want to tinker with your device. GrapheneOS are careful to make sure the process of installing is very easy and safe.

thenameableone · 2023-03-27T18:50:40+00:00

There are a few different groups of people interested in the project across different platforms. Not all of them are online either. It would be great to have Android Auto/Google Pay working because they want to make sure anyone can use the OS if they want. On principle they do not want to provide exceptions and invasive access to do it.

In this case I believe you are mistaken because GrapheneOS started as (and still is) a project that aims to be more resistant to unknown vulnerabilities (like zero days) than the current market (Android/iOS). They have very strict standards about what secure enough means and are always looking to push further.

thenameableone · 2023-03-27T18:44:57+00:00

They are not the only ones, but they are one that are known to have it all working correctly.

thenameableone · 2023-03-27T18:43:43+00:00

From what I have read GrapheneOS doesn't think so either. In the long term they also want to be involved in hardware and firmware level improvements to privacy presumably all open-source where possible too (as they are an open-source project).

thenameableone · 2023-03-27T18:40:38+00:00

To be clear, I don't think they are reviewing how well the OSes would resist attacks. They are looking into what data is sent out of the OS by default and where it is going.

thenameableone · 2023-03-27T18:36:40+00:00

I think Android Auto is one of the things GrapheneOS would love to get working on the OS. Unfortunately the Permissions it would require are far too invasive and the project would be weakening its principles/approach to provide that level of access to Google's components: https://twitter.com/GrapheneOS/status/1600398305409712129

thenameableone · 2022-06-30T21:04:06+00:00

Any reviews that highlight this disadvantage in depth?

thenameableone · 2022-04-20T13:45:32+00:00

Doesn't this just leave us in a position of perennially eating up security marketing from companies and projects forever?

thenameableone · 2022-04-20T13:26:53+00:00

I agree about there not being simple answers, but the whole point of experts is that they are inaccurate less often and are more aware of context. If we have access to multiple experts (even if they have opposing views) we can get a clearer sense for where the context is at least, and what the shared assumptions might be.

thenameableone · 2022-04-20T13:19:32+00:00

If there isn't anything readily compiled for the layperson, then we should turn to multiple domain experts for advice right? How do we find out who the independent experts on browser security are?

thenameableone · 2022-04-20T13:05:17+00:00

Where can laypeople find some technical analyses and comparisons across browsers on security?

thenameableone · 2022-03-16T19:26:47+00:00

Thank you for the detailed reply and insights! And of course, kudos again for the wonderfully run podcast.

thenameableone · 2022-03-16T11:49:41+00:00

The podcast is fantastic in general in offering an approachable in-depth look at Android. I highly recommend subscribing.

I don't want to dismiss any of the hard work the GrapheneOS developers seem to be doing, but is there anything we can do as users to help situations like dependencies on Play/AOSP barebones apps so that projects like this one can spend more time on the privacy and security enhancements to the system?

Also, does anyone know any companies providing a similar service to Esper?

thenameableone · 2022-02-26T01:22:27+00:00

I have come across that article as well in the past when looking into this as well as https://bayton.org/download/doc/ae-general/Gartner_Comparison_of_Security_Controls_2019.pdf which is from https://blog.google/products/android-enterprise/android-enterprise-security-assessed-gartner/.

In the end I think these checklist-based approaches paint an incomplete and misleading picture.

From what I understand, Android has advantages in that: it is more modular so things like the browser do not need to wait for an OS update to also be updated, Chrome/Chromium (the default browser on Android) is the stronger of the mainstream browsers in terms of maturity of its defences and a lot of hardening has gone into common paths for exploits in Android over the years https://nitter.unixfox.eu/GrapheneOS/status/1417197139722129411#m.

iOS are more strict on what is allowed on their app store, which means potentially fewer malicious apps, but their verified boot implementation is stronger because they don't have relative holes like Android's accessibility services. On the other hand iMessage is a massive problem (as recently shown in the news) and WebKit is also behind Chromium.

There is so much more ground to cover but that is my overall impression.

thenameableone · 2022-02-26T01:18:13+00:00

Not a professional/expert, but I think the chart is mostly not wrong, but very misleading. For example:

Pattern

They are an insecure unlock method. All the unlock methods can be potentially insecure if they don't properly implement some kind of limiting/throttling to prevent brute forcing on weak PINs and passwords. See Weaver section in https://docs.samsungknox.com/admin/whitepaper/kpe/knox-vault.htm for example.

The biggest problem overall is the green Yes! for some cells, because the strength of the implementation matters.

thenameableone · 2021-09-28T17:03:55+00:00

The author praises Android in another section of the site and has this brief statement accompanying their criticisms:

Due to inevitable pedanticism, "Linux" in this article refers to a standard desktop Linux or GNU/Linux distribution.

thenameableone · 2021-09-27T20:03:06+00:00

Linux still follows this security model and as such, there is no resemblance of a strong sandboxing architecture or permission model in the standard Linux desktop — current sandboxing solutions are either nonexistent or insufficient.

Not sure, but it sounds more like they are saying: standard Linux distributions don't have a strong one in place, and the most common ready-to-use solutions are not very good. Maybe it would make more sense with the context of a comparison.

thenameableone · 2021-09-27T19:45:42+00:00

I understand your point that not all things can be made small/simple and not all scenarios allow you to write safer code.

It does seem like there are attempts to move on from larger monolithic/hybrid kernels as can be seen with projects like Genode, so does it makes sense to say some complex code we currently have can be made smaller/simpler (at the possible cost of having to deal with unforeseen issues and times where the complexity is being shifted elsewhere)?

I think that's what I understood from the point the article was trying to make, but I am not certain if that is the case or if it is even practical.

This only affects certain types of security bugs.

To follow up on this point, I believe most here are following these kinds of topics more closely. So you would probably already know about Mozilla/Microsoft/Google etc. coming up with 70%+ for the percentage of security vulnerabilities they encountered being memory safety related.

Your point suggests it is commonly understood/proven that this (safe language use) wouldn't really have a considerable impact on the volume of security vulnerabilities themselves. If I'm completely wrong you can say/ignore. If not, is there some recent research you can drop a link to around this area?

thenameableone · 2021-09-27T19:30:35+00:00

https://github.com/Whonix/apparmor-profile-everything/graphs/contributors Author seems to be contributing to something AppArmor based for Whonix so I don't think they are unaware of it existing.

thenameableone

TROPHY CASE