For Ethernet, MAC addresses are 48 bits long.
582 karma · joined July 25, 2011
I built Farseer Physics Engine 3.0, SimpleS3 and about 25 other open source projects. Check them out over at https://github.com/genbox
I am also the founder and director of Chronos, a platform for investigating large-scale security incidents using forensics techniques.
And yes, I think that an HTTP POST to Microsoft's Windows Terminal team saying "UserUsedTerminalInInterative = true" is not a privacy issue, nor is it spying.
Can you explain to me how this information hurt users of Windows Terminal? If it indeed is spying, it should be possible to demonstrate how it is used for hostile purposes or why such an innocuous piece of information must be kept a secret.
Until then, I think it is fair for the Windows Terminal team to collect such basic telemetry for their software
Each of the calls you link to sets a boolean here: https://github.com/microsoft/terminal/blob/57c3953aca49f68ac...
It does not transmit what you copy, search for or when you clicked/resized/closed the window. It simply stores a true/false value saying "feature X was used". In some cases, like with find/replace, it also stores the average length of things you searched for. That is a common way for developers to get an idea if performance characteristics due to the longest common substring problem[1]
You are trying to spread misinformation here to make Microsoft look like a bad guy. There is nothing sinister going on here, it is just ordinary metric collection.
But don't take my word for it. Take for example the "we can see it log every time you resize a console window" statement. In the link it calls SetWindowSizeChanged()[2] which again calls SetUserInteractive()[3] and it just sets a boolean to true.
So there is no "log every time it resize a console window". It simply sets a variable to true, which presumably the Windows Terminal dev team use to see how many users use the console with interactive sessions.
[1] https://en.wikipedia.org/wiki/Longest_common_substring_probl...
[2] https://github.com/microsoft/terminal/blob/57c3953aca49f68ac...
[3] https://github.com/microsoft/terminal/blob/57c3953aca49f68ac...
If you feel like a bunch of developers getting info about how many times the world clicks on a button hurts you personally, then don't install it. Calling it a privacy issue it taking it too far.
Understanding systems, algorithms, design patterns etc. takes time. Nobody ever starts out writing a solution that incorporates things they don't know. That's why we have education, training, certificates etc. to rectify that and have people start out with some sort of foundation instead of from scratch.
It is rare I come across something I would classify as _good engineering_. It is mostly just crap.
Only artisans put any value into being succinct, using appropriate algorithms and data structures. Everyone else struggle with getting it to work. I think that paradigm covers just about any field of engineering out there.
That is not enough energy to even penetrate the skin, much less the skull. The amount of energy the article talks about is 1000x that amount and for an extended amount of time.
A lot of travelers experience headache after flying. Blood pressure changes, blocked sinuses, CO2 accumulation, change in sleep cycles etc. can all contribute.
Source: degree in technical medicine
Never has my professional life been distilled to such an accurate description.
There is nothing in Secure Boot that prevent people from running their own software. You can update the Secure Boot DB/DBX with whatever you want. Yes, the certificates expire - my computer was bought 4 years ago and Microsoft's UEFI CA will expire in 4 years. At that point I will probably have bought a new computer, but if I have not, I can update the certificate to the new one they released.
Secure Boot is very much an improvement over non-secure booting, and Authenticode signing is an extension of that security to enable signed-only software to run.
UEFI with Secure Boot enabled will only load the stage 1 bootloader if it is signed with the firmware trusted certificate. We don't know if this component is malicious, we just know it is signed by the certificate.
The stage 1 bootloader (shim) will then be responsible for loading the next component (stage 2 bootloader). It will only boot the component if it is signed with a trusted (chosen by the user/distro) certificate.
The bad guys can't insert themselves into this process, as they either have to be trusted by the UEFI firmware (protected by an owner password), signed by Microsoft (to replace the shim) or be signed by the distro's certificate.
As long as the chain is unbroken it is secure.
As for Windows packages, there are several "package" systems:
- AppInstaller (winget): A SHA256 hash is included in the application manifest. I might be wrong, but I do not believe the manifests are signed afterwards. Packages are verified upon installation.
- MSIX packages: They are signed and timestamped with a publisher certificate. They are verified upon installation.
- Executables: Not really packages as such, but PS1 scripts and .EXE executables support Authenticode signatures. They are verified upon execution.
As for Linux, there are several package systems:
- DPKG/DEB: Built-in support for verification with hashes generated at install time. Packages can be GPG signed for stronger security, but it is disabled by default. Repository metadata is often GPG signed.
- RPM: Like DEB above it supports verification with MD5. It also has GPG integration. I believe it is disabled by default as well.
Linux does unfortunately not have support for signatures of ELF executables.
Everyone can load their own signing keys into firmware. However, if you want something that "just works", Microsoft signs a package called Shim[1] that can be loaded on most computers due to the pre-loaded keys.
A relationship with Microsoft is not needed in any way or form to have Secure Boot.
[1] https://distrowatch.com/search.php?pkg=shim&relation=lessequ...
I'll also add that Amazon Key Management Service, Azure Key Vault, and Google Key Management Service store several hundred million private keys combined with no leaks so far (they are non-exportable and access is audited)
It is very rare that we see malware signed by a publisher's certificate, which is why it is in the news every time it happens.
I'm of course ignoring the fact that a lot of Linux distros still do not have Secure Boot enabled by default, and therefore do not enforce any kernel driver signing policy.
It is an age old conundrum that people seem to struggle with a lot. As part of my previous profession, I've security reviewed hundreds of open source libraries. They fall into 3 categories:
1. The libraries/applications that have either had a really security conscious developer behind it or a very rocky past such that it was given an extraordinary amount of attention security wise. These account for about 1% of software
2. The "normal" libraries/applications that nobody care about with regards to security. As long as the code works everyone keeps using it. They are often insecure by default, but the lack of attention by SME means they wont be judged. They account for 80% of software.
3. The horrid ones. Built-in code execution as a feature. Authentication systems with more critical bugs that you can possibly image. We never talk about these because... well, we could spend months on polishing a turd. Nobody dares to publicly speak up and say "don't ever use X, Y and Z" for fear of the repercussions. They account for the rest of software.
GitLab used to be in category 2, but got moved into 1 about two years ago when security professionals started to give it attention.
As to your feeling, 99% of software have security issues, some worse than others. We rarely talk about them.
- Andrew Lock: https://andrewlock.net/
- Steve Gordon: https://www.stevejgordon.co.uk/
- Scott Helme: https://scotthelme.co.uk/
- Phil Haack: http://haacked.com/
Yes, browsers have removed the green trust bar.
Yes, ordinary users have to click on small buttons and manually check against different conventions used by CAs (naming, extensions, OID variants).
However, saying that EV provides no extra security not entirely true. At least if we look outside the end-users of a website.
It is also used for: - High security applications that have to ensure their services are trustworthy - As confidence/trust factors in cyber threat intelligence (if you don't want to get blocked on a false positive, EV is your friend) - In domain name research when trying to establish ownership - In machine learning models as an indicator of verifiable trust - Protects against website copying used in phishing campaigns
I'm focusing on HTTPS here as EV is much more relevant in PKI systems.
EV should be affordable, relevant, have good UX and provide identity security for end-users of browsers, but it is not. Until that changes, most website owners should not buy it.
I believe it is PayPal because DigiCert say it is (with EV). That is much better than no validation - which is the default.
Domains are not identities. They are a reference to an organization. PayPal owns more than 100 domains. Not only did DigiCert validate the organisation through various procedures (e-mail, paystub, id), but the validation is also asserted through a X500 name, which is cryptographically signed in the X509 certificate. So there is no way for others to spoof the identity.
Attackers can easily copy the HTML/CSS/JS the website to look and feel exactly like PayPal. Then they can go to Lets Encrypt and get a certificate, which offers no assertion on their identity, other than "Attackers own the domain paypal.xom.com" (a domain they purchased to spoof PayPal).
In that case, the EV certificate is the _only_ way you can check if it is really PayPal.
Let's Encrypt is not a solution for trust. It is an attempt at getting as many people to adopt HTTPS as possible. There used to be 3-4 free certificate authorities which all had their problems (processes, security, uptime etc.) and Lets Encrypt is outperforming them all.
We still need to understand issues around identity, which can only be solved with verification and trust. X509 is encryption keys + trust and LE has much weaker trust guarantee than an EV.
I don't think it is hard to imagine an increase in throughput for disk encryption due to less time spent in the RNG.
The use of RDRAND was especially overzealous. The problem is always finding the line between retaining entropy and performance - in this case (without having done the statistics) I believe you have done the right thing.
If I wanted to contribute an entropy mixer not based on CRC32 (as the current one is) that is much faster, includes test vectors and entropy analysis - where would be a good place to start?
LINQ's First() correctly returns a non-nullable type: https://source.dot.net/#System.Linq/System/Linq/First.cs,11
FirstOrDefault() correctly returns a nullable type: https://source.dot.net/#System.Linq/System/Linq/First.cs,33
typeof(type).Name is MemberInfo.Name, which is also not nullable: https://source.dot.net/#System.Private.CoreLib/MemberInfo.cs...
I checked both .NET 5 and .NET 6. They have identical nullability.
Likewise on Linux and macOS for that matter. Every aspect of IT have fans of varying degrees from "I use it as a tool" to "I can't imagine anyone using anything other than X".
Fact of the matter is that people try these things with a very non-scientific mindset, as such they are strongly affected by confirmation-bias. So when they switch OS, they are likely talk about things they feel personally affect them, and there is no way you can disagree with them, because it is their personal perspective.