Do ARM chips have ME or PSP equivalents? It would be great to be able to buy a new machine and use something like coreboot without having to use hacks to disable ME.
Arm sells barebones CPU cores which can be used to create more complex processors like complete SoCs. When I mean barebones, I mean the traditional core with branch predictors, instruction fetchers, writebacks, etc.
Intel and AMD sell an entire System-on-a-Chip disguised as a CPU processor. Their CPU is much more than a CPU core: they contain an entire system in there.
If you want to make a comparison, it is more correct to compare the Snapdragon and the Exynos chips to the off-the-shelves CPUs that Intel and AMD sell.
Arm only sells technologies that enable other companies to create a final product, it doesn't impose those kind of "management systems" and binary blobs.
It would be fair to mention that TrustZone, the equivalent technology, is built into the cores/ISA. They also do distribute software related to the TrustZone, albeit not a full TEE solution.
TrustZone is not an equivalent technology to ME/PSP. TrustZone is a technology for providing hardware isolation and ME/PSP are co-processors that manage the entire CPU socket (the Ryzens and the i9s)
Yes, AMD's PSP is actually licensed from ARM, its why there is a small ARM Cortex CPU on AMD's CPUs and APUs. The first few times they tried adding it on did not go well FYI, so they disabled this small chunk of silicon at the factory.
In 2013 AMD successfully fabricated a CPU with said ARM Cortex core embedded, thus that was the first year they actually offered their PSP. AMD had similar problems with their APU's for a number of years IIRC, whereby making a single chip with both CPU and GPU on it had poor yields with a high percentage of dead chips.
If the next Mac Pro doesn’t utterly blow me away I’ll take a dual-CPU POWER9 system into serious consideration. My only concern is drivers for suitably powerful GPUs.
Unfortunately it's not as easy to answer. Intel and AMD manufacture their own chips which means they can put their backdoors into all their products. However with ARM they license their IP and other companies make their chips.
This means some companies have hidden proprietary code in their bootloaders. For example the Samsung Exynos have a range of ARM chips, but to boot them you must use their bootloader, which may contain spyware, backdoors or surveillance systems. You can not see the source code for this bootloader and have no way of auditing what it actually does.
Rockchip is another company that makes ARM chips, and can be considered mostly free [1]. As with all hardware it's very hard to know what's going on inside, but all the code to boot into Linux (minus the optional GPU) on a Rockchip product is open source and can be audited/compiled by anyone.
ARM also have TrustZone [2] that allows you to run applications in a "secure" (or separate) space. It doesn't run on a separate chip, but runs on the ARM chip, separating memory and instructions from the operating system. (Don't quote me but...) I believe you don't actually have to use TrustZone. The instructions/documentation for it doesn't appear to be available to the public, however if you don't upload a blob for TrustZone, with Rockchip it simply won't use it and will run everything on the same level. (Note this is true for Rockchip, but again depending on who is manufacturing the ARM chip, they may force you to use TrustZone).
Unlike with Intel ME and AMD PSP, if you don't want to use their ME, you have no choice. If you remove the blob your system won't boot (or will restart after 30 minutes for some older models).
This means if ARM TrustZone is compromised you can remove it and continue on as normal. But if ME and PSP are compromised you are at the will of Intel and any agency it may have colluded with.
While we're on the subject of free and open source code, note that with (most) ARM chips, the GPU is closed source just like the Intel ME. Again, the difference is if you don't want to use the GPU, you can just not upload the blob, and use the CPU without the GPU. There are some movements being made to open the GPU [3], but it's still a long way off.
TrustZone is essentially an ISA extension, similar to Intel's TXT and SGX to provide a trusted execution environment. You can trivially avoid it by never running any of the related instructions.
It's more of an extra address bit and processor mode. It doesn't have related instructions like TXT and SGX, but instead is structured more like a hypervisor.
OK, so there's the one instruction to do a system call that hits secure mode. It's equivalent to svc or hvc, but hits EL3 (secure mode) rather than EL2 (hypervisor mode) or EL1 (supervisor mode).
It's very very different than the dozen or so instructions to setup TXT or SGX that sits off to the side of the main OS rather than running like a super hypervisor. If you're going to compare it to something, it's way more like SMM on x86.
Source: I've ported a kernel to EL3 (secure mode).
The closed boot loader is a red herring. Unless you have the underlying RTL source the hardware could do anything - no secret boot loader required. Open source without open hardware is a false sense of security.
Every moderately complex SoC will have something like ME or PSP. The most recent big boy ARM SoC that I can think of without something like that was the iMX6. Even SiFive's newer U54-MC RISC-V SoC has a little "monitor core".
SoC power management, system bringup, and maintenance tasks are complicated enough these days to warrant a full small core tacked onto the side. These cores are necessary, and aren't going away. Complaining about them being there is just pissing into the wind. Complain about what they're used for and the closed source nature of their code.
> SoC power management, system bringup, and maintenance tasks are complicated enough these days to warrant a full small core tacked onto the side. These cores are necessary, and aren't going away. Complaining about them being there is just pissing into the wind.
There's a vast difference between such a core being used solely for bringup/power management/housekeeping and it having a network connection to the outside and being used for "remote management" (and running with godawfully insecure parsing code, at that).
Check out what the ME disable stuff does. It just removes some of the binaries from the thing's uKernel that are the non boot services. The ME is required for system bringup.
> However, while Intel ME can't be turned off completely, it is still possible to modify its firmware up to a point where Intel ME is active only during the boot process, effectively disabling it during the normal operation, which is what me_cleaner tries to accomplish.
My understanding is that it's what controls power sequencing, QPI bringup, and RAM bringup, so the main cores can't come up without it or something like it.
Just like the similar cores you see in pretty much every ARM SoC.
They can have it, as ARM TrustZone. This is an independent ARM chip and is in fact used in the AMD PSP. I don't know if some or all of these laptop SoCs would have one, though. Some (most?) Android phones have one (see: https://googleprojectzero.blogspot.com/2017/07/trust-issues-...)
ARM TrustZone isn’t a chip at all, and it’s not a thing that an SoC could have. It’s just another operating mode of an ARM processor. It’s more analogous to x86’s SMM than to PSP or ME. TrustZone is also fully documented AFAIK.
So the real question is: will the laptops let end users replace the TrustZone kernel?
There's a lot of SoC specific stuff moving over into the Arm Trusted Firmware that sits below the TZ kernel. The upstream ATF is BSD licensed, so while some chips have open source implementations, others might only exist as blobs.
It's possible to build out SoCs that require a closed-source blob that runs on one of the ARM cores, doing basically all the same jobs a PSP or ME does.
I'm a bit confused as to why adguard is being targeted here, but things like Disconnect.me which also use a "fake" VPN are not. Can anyone shine some light on this?
I've often wondered if we could open up private clinics in Canada for Americans where we charge reasonable rates. Kind of start a medical tourism industry by the border.
Thailand has a fairly large medical tourism industry - a number of hospitals in Bangkok are considered world-class (if not world-leading). I know a few people who just go there once a year for a weekend for their annual check-up, since the difference in price from doing it in a decent private hospital in Hong Kong can cover the cost of flights and accommodation, plus you get a weekend in Bangkok which is nice...
While many would not be able to afford a trip to Canada, I would think there would still be a sizeable number who live within 1-2h from the border who could drive there for non-emergency care.
>The security issue, which the security firm refers to as the Firebase vulnerability
IMO, calling the vulnerability the "Firebase vulnerability" makes it seem like it's a problem on Firebase's side. But is it really their problem? At what point do we start blaming the developers instead of the service?
If the following quote from the article is true, it seems like Firebase is not making security easy for developers: "One of the most popular backend database technologies for mobile apps, Firebase does not secure user data by default. It does not warn developers when data is not secure and does not provide third-party encryption tools either. To ensure data is secure, app builders need to specifically implement user authentication on all database tables and rows, but that rarely happens,"
Google shouts at you, about 500 times, to secure your Firebase instance. Tutorials are thrown at developers left and right, and the docs mention it again and again.
And the security system is super simple to implement. If the built in language is too hard, a simplified templating language is also provided.
The plaintext password thing just confuses me. One of Firebase's big draws is integration with their auth system. Why in the world is anyone storing passwords in Firebase? Unencrypted?
How many times do we need to go through issues like this before people realize that just yelling louder has no effect? Services like this should simply not function at all until basic things like a password are put in place.
The fact that this was not the default since the inception of the service is inexcusable. Sadly, too many other projects still take the approach of yelling at people in some document somewhere instead of forcing security by default.
I’m guessing because most developers have no training in web security. Using Firebase as an authentication tool, you’re not supposed to have access to users passwords — unless you are specifically parsing for it and storing them into the database after account creation.
Firebase used to be open by default, (to ease the dev experience, presumably), but sometime around the Google acquisition became private-by-default. It also warns you incessantly when your security rules are too open.
I suspect (hope?) most of the apps still using it insecurely came from before the acquisition by Google.
It seems obvious to most people on HN that you'd have to secure user data to only be accessible by that user but I've found many young mobile devs to not grasp these 'backend' basics which is unfortunate.
In a way I blame this on Apple/Google for making their platforms convoluted enough that people have to spend years learning how to develop Android and iOS but not have a proper understanding of the web services powering APIs.
Thought about this some more and it's definitely not just Google/Apple's fault per se but the respective mobile communities strongly push technology churn a la JS frameworks. Except in Androids case it's, getting your architecture right, using MVP, dissecting Dagger and dependency injection, learning kotlin, learning rxjava, learning MVI because mvp isn't good enough anymore.
Eventually you just get caught up in this constant flurry of learning more without actually learning anything
It’s due to laziness. Most of the times when I looked up how to implement a feature via Firebase — such as public profiles — there were instructions on implementation and on what new rules to add.
It’s either that or the developer simply doesn’t understand the abstraction of Firebase. You can easily check if the rules work by loading up your browser console and trying to access different branches of data with varying credentials.
If your software can be configured in an insecure manner, that's what people will do.
There are so many developers out there that every possible mistake will be made. The easier the mistake is to make, the more common it will be. If the mistake requires the developer to perform an action to avoid it, it will be ubiquitous.
In 2018, security can no longer be an afterthought. Your product must be secure out of the box. Insecure configurations must be hard or impossible to set up.
You can't offer an insecure "development mode", because that is what people will use in production.
(PS: Of course it is also the developers fault. But that is no excuse for the vendor. There are lots of incompetent developers out there. Confused developers are not an exception. Your product must be secure even if people don't read the documentation)
I like what CIRA (the .ca registration authority) does. The default is for them to hide your contact information. You have to opt-in to make it public.
They then handle all communications people want to send to you. More registration authorities should take stances like this.
Me: Are people who are not Canadian citizens able to purchase/register .ca domains? I've read that a Canadian phone number is needed for registration. Additionally, can a non-Canadian citizen get CIRA's WHOIS privacy for their domain?
Their Response: Thanks for getting in touch with CIRA, [redacted]. CIRA has 18 Canadian Presence categories, we require full contact information when an individual or a business is registering a .CA domain name. That doesn't mean you have to be in Canada to hold a .CA domain, many Canadian live all over the world and registered .CA domain names. A non Canadian could hold a .CA domain name but that would require them to either register a Canadian Trade Mark, Canadian Corporation, or hold a Permanent Resident card. The WHOIS information is "masked" or "privacy protected" when the .CA category of "Canadian Citizen - Individual" is selected.
So it looks like WHOIS privacy is not easily available if one isn't a Canadian citizen. I still like the model, however.
I like how people responsible for .pl (Poland) domain handle this. First of all, they list only very basic data, with no names, addresses, etc. when you query their whois. To see the full data, you have to go to their website and type the captcha, which filters out at least some of the bots. But even there they display the data if it belongs to a company, they won't show any details if it's registered to a private person.
Seems like it's the same for .eu domains, and (I think) some other EU countries. For private persons you only see the email, and that's after entering the captcha.
Not sure why you are saying this, when the site uses a "usual" captcha (that can probably be solved easily, but that's another thing): https://www.dns.pl/cgi-bin/en_whois.pl
Huh. This is great! Might be a NameCheap (my registrar) limitation. The way it's worded in the management page on NameCheap is that DNSSEC is not supported for .ca period. Definitely something I'll look into. Thanks!
Probably. I had to move to baremetal.ca to get DNSSEC support, and even then I had to email the info to their tech support team as the web interface didn't support it
Also not an expert, but since videos are transcoded as key-frames and changes applied to those key frames, I don't think it's as simple as segmenting something like a CSV. Transcoding is probably required just for the segmentation process. Putting it back together might be easier, but the final output file might also be larger because of overhead.
The segmentation code is keyframe-aware, so it only splits along keyframe edges. In other words: requesting segments of 30 seconds each probably won't get you segments that are exactly 30 seconds long. Still, there could be plenty of other obstacles I'm not aware of.
Just to add onto this, there's a whole field of people who design things with human psychology in mind. For example, when you got onto Twitter, they _could_ show you how many notifications you have right away, but they implemented an artificial delay so you stare at it intently and when it finally shows you feel gratification [1].
So while a design may not make sense right away, there may be other factors at play.
One important thing to not about some of these points is that they don't have to be made easy for users. For example, in relation to "Abilty it export data", there doesn't necessarily need to be a feature on the website for it to be compliant. They simply need to do it if you ask. So if that means having someone manually run a query to get a data dump every time someone asks, it's still considered compliant.
Of course that doesn't actually scale. That's why most all the big players are providing export features.
At my job we do it semi-automatic; i.e. there are automatic export tools, but emails are sent forth and back first.
This is because we've received only a handful of requests and because there isn't an automatic system for the extra layer of authentication comparable to answering an email with a token in it.
Come to think of it, this places an even bigger value on email: You can probably get all of someone's private data from external sites once you have their email. As if it wasn't a big enough part of stealing someone's identity already; now you can properly steal people's pasts!
That can't be the whole story though. In general, a regulation stipulating that a business provide a feature can't allow businesses to make it arbitrary difficult for a user to use that feature, since that would defeat the public policy behind the regulation.
I suspect that the line here will be decided in some court.
> I suspect that the line here will be decided in some court.
Sure. At the end of the day though people shouldn't be using GDPR as an excuse to avoid making stuff or launching their projects. As long as you make a reasonable effort to do what people are asking for via email then you're probably not going to be the test case.
Yes, making things _arbitrarily_ difficult would probably go against the spirit of the law, even if it technically complied with it. But as Alex3917 pointed out, as long as a company responded to GDPR requests by email in a timeline in accordance with the law, they would be safe.
Indeed, I noticed this in Google's GDPR terms and conditions I was required to agree to yesterday. Long story short, Google will charge you to delete your data, which I thought was against the spirit of the GDPR law:
"Google may charge a fee (based on Google’s reasonable costs) for any data deletion under Section 6.1.2(a). Google will provide Customer with further details of any applicable fee, and the basis of its calculation, in advance of any such data deletion."
Oh! I totally missed that. Thank you for the correction.
Not meaning to be argumentative, but is there a reference for that beyond Article 12 Section 5? (I probably missed that too.) But that section seems to suggest you can only charge a fee (or even decline to act) if the requests are unfounded or repeatedly excessive:
"Where requests from a data subject are manifestly unfounded or excessive, in particular because of their repetitive character, the controller may either:
charge a reasonable fee taking into account the administrative costs of providing the information or communication or taking the action requested; or
refuse to act on the request.
(Google's clause was opting to charge for any deletion request that is not yet automated.)
Can't that be a violation in the eyes of GDPR? If they don't give users a simple button, then can't that be argued to be not giving the user the ability to export data. The problem I have with GDPR is that there's so much open to interpretation.
Articles 15 and 17 (dealing with deletion and access) both contain a provision where if the request is unfounded or excessive, you may charge a reasonable fee. You cannot charge a fee for compliance with standard requests, and "reasonable" is something that would likely be argued in court.
If you have an email address you can give users for privacy requests and a promised turnaround time (we will respond to all privacy messages in 7 days) you're OK.
If you clicked the link and found the amount of information they have on your surprising, and now feel a bit violated, then good; you should.
You'll probably try to do a bit of research and try to figure out how to opt out of all this and protect yourself. And you should. But you shouldn't just stop there.
Many of the people who are reading this right now are responsible for designing and implementing systems that collect massive amounts of data. I implore you to not just think about your own privacy moving forward, but the privacy of your users. Security and privacy should be two of your top level concerns when designing systems, not just tack-ons.
Simply hating of Google/Facebook/$$$Corp for invading your privacy and not doing anything to rememdy the general poor state of privacy in the modern connected world when you have the power to do so is hypocritical.
Next time you're given a project that has PII and the security user story gets deprioritized, raise it as an issue. Aside from being the right thing to do, many places, such as Canada and California, are looking at GDPR-like regulations. So it makes sense to do it now instead of later.
And if you're going to argue that it's hard, and it's time consuming, and you're a startup just trying to get on their feet so you can't be bothered, then consider that you may be part of the reason we find ourselves in this sorry state.
